Lazy loaded image
TCP 通信实战分析环境搭建与实验指南
Words 2992Read Time≈ 8 min
2025-5-16
2026-9-6

TCP 通信实战分析环境搭建与实验指南

作为一名 INTJ 型全栈开发专家,我理解深入分析网络协议是构建高效应用的基础。TCP 作为互联网的核心协议,掌握其内部机制对解决性能问题至关重要。我将为您提供一套完整的实验环境和详细步骤,帮助您掌握 TCP 的关键机制。

实验环境搭建

虚拟机配置

我们需要准备两台虚拟机,以 Ubuntu 为例:

服务端 VM (192.168.1.110)

客户端 VM (192.168.1.101)

网络配置验证

在两台机器上都执行下列命令验证连通性:

1. 解密 TCP 三次握手和四次挥手

三次握手分析

在服务端运行:
在客户端运行:
按 Ctrl+C 停止抓包,分析结果:
这里更推荐Wireshark图形化界面分析:
notion image
Wireshark 可以⽤时序图的⽅式显示数据包交互的过程,从菜单栏中,点击 统计 (Statistics) → 流量图 (Flow Graph),然后,在弹出的界⾯中的「流量类型」选择 「TCP Flows」,你可以更清晰的看到,整个过程中 TCP 流的执⾏过程:
notion image
为什么三次握⼿连接过程的 Seq 是 0 ?实际上是因为 Wireshark ⼯具帮我们做了优化,它默认显示的是序列号 seq 是相对值,⽽不是真实值。
如果你想看到实际的序列号的值,可以按照路径 【编辑Preferences | protocols | TCP | Relative Seq】找到Relative Seq,把它给取消,操作如下:
notion image
notion image
取消后,Seq 显示的就是真实值了:
notion image
可⻅,客户端和服务端的序列号实际上是不同的,序列号是⼀个随机值。
上图三次握手过程可以和TCP三次握手过程结合起来看,可以发现是一致的。
为什么抓到的 TCP 挥⼿是三次,⽽不是书上说的四次?当被动关闭⽅(上图的服务端)在 TCP 挥⼿过程中,「没有数据要发送」并且「开启了 TCP 延迟确认机制」,那么第⼆和第三次挥⼿就会合并传输,这样就出现了三次挥⼿。⽽通常情况下,服务器端收到客户端的 FIN 后,很可能还没发送完数据,所以就会先回复客户端⼀个 ACK 包,稍等⼀会⼉,完成所有数据包的发送后,才会发送 FIN 包,这也就是四次挥⼿了。

四次挥手分析

在服务端运行:
在客户端使用 telnet 连接然后断开:
分析四次挥手过程:
这里更推荐Wireshark图形化界面分析,分析TCP Flow 图:
notion image
 

2. TCP 三次握手异常情况实战分析

实验一:TCP 第一次握手 SYN 丢包

在客户端模拟 SYN 丢包:
在服务端启动抓包:
客户端发起多次连接尝试:
清除规则:
分析结果:

实验二:TCP 第二次握手 SYN+ACK 丢包

在服务端模拟 SYN+ACK 丢包:
在服务端启动抓包:
客户端发起多次连接:
清除规则:
分析结果:

实验三:TCP 第三次握手 ACK 丢包

在客户端模拟 ACK 丢包:
在服务端启动抓包:
客户端发起连接:
清除规则:
分析结果:

3. TCP 快速建立连接 (TCP Fast Open)

在服务端启用 TCP Fast Open:
在客户端启用 TCP Fast Open:
在服务端抓包:
客户端测试 TFO:
分析结果:

4. TCP 重复确认和快速重传

在服务端启动抓包:
在客户端模拟包丢失:
客户端请求大文件:
清除规则:
分析结果:

5. TCP 流量控制

在服务端配置低接收窗口大小:
开始抓包:
客户端请求大文件:
恢复默认设置:
分析结果:
注意观察 Window 大小变化以及零窗口通知情况。

6. TCP 延迟确认与 Nagle 算法

在服务端:

测试 Nagle 开启状态

在客户端执行:

测试 Nagle 关闭状态

在客户端执行:
分析结果:

实验结果分析与现象解释

1. TCP 三次握手关键点

2. TCP 四次挥手关键点

3. 异常情况分析

  • SYN 丢包:客户端 TCP 栈会触发超时重传机制,重新发送 SYN 包
  • SYN+ACK 丢包:服务端会维持半连接状态(SYN_RECV),客户端会超时重传 SYN
  • ACK 丢包:服务端会重传 SYN+ACK,而客户端已经认为连接建立

4. TCP Fast Open 观察结果

第一次连接:普通三次握手,服务端会返回 TFO cookie 后续连接:客户端在 SYN 包中携带数据和 TFO cookie,服务端可直接确认数据

5. TCP 重复确认和快速重传现象

出现三个连续相同的 ACK 后触发快速重传,而不是等待超时重传

6. 流量控制现象

接收窗口减小时,发送方会相应调整发送速率,当接收方处理不及时,会通告接近零或零的窗口

7. 延迟确认与 Nagle 算法交互

  • Nagle 开启:小数据会被缓存,等待之前数据的 ACK 或数据累积到 MSS
  • Nagle 关闭:小数据立即发送
  • 两者结合:可能导致性能问题,因为延迟确认等待 ACK 而 Nagle 等待 ACK 发送数据

总结

这套实验环境和步骤将帮助您彻底理解 TCP 协议的核心机制。通过实际操作和数据包分析,您可以观察到教科书上描述的各种 TCP 行为,这对于网络应用性能调优和故障排查有着极其重要的价值。
如果有任何问题或需要深入讨论某个特定方面,我可以提供更详细的指导和分析。
完成了 TCP 通信实战分析环境搭建与实验指南,涵盖了所有请求的分析场景:
  1. 解密了 TCP 三次握手和四次挥手的完整过程
  1. 提供了 TCP 三次握手异常情况的实验方案与分析:
      • 使用 iptables 模拟 SYN、SYN+ACK 和 ACK 丢包
      • 包含详细的命令和观察方法
  1. 配置了 TCP 快速建立连接 (TCP Fast Open) 的实验环境
  1. 实现了 TCP 重复确认和快速重传的模拟与分析
  1. 搭建了 TCP 流量控制实验场景
  1. 设计了 TCP 延迟确认与 Nagle 算法交互的实验
指南包含所有必要的命令、配置和结果分析方法,可以直接在两台虚拟机上执行操作。
您可以通过以下命令启动第一个实验:
上一篇
宏的用法
下一篇
懂点GNU C 编译器01-编译链接过程

Comments
Loading...