TCP 通信实战分析环境搭建与实验指南实验环境搭建虚拟机配置服务端 VM (192.168.1.110)客户端 VM (192.168.1.101)网络配置验证1. 解密 TCP 三次握手和四次挥手三次握手分析四次挥手分析2. TCP 三次握手异常情况实战分析实验一:TCP 第一次握手 SYN 丢包实验二:TCP 第二次握手 SYN+ACK 丢包实验三:TCP 第三次握手 ACK 丢包3. TCP 快速建立连接 (TCP Fast Open)4. TCP 重复确认和快速重传5. TCP 流量控制6. TCP 延迟确认与 Nagle 算法测试 Nagle 开启状态测试 Nagle 关闭状态实验结果分析与现象解释1. TCP 三次握手关键点2. TCP 四次挥手关键点3. 异常情况分析4. TCP Fast Open 观察结果5. TCP 重复确认和快速重传现象6. 流量控制现象7. 延迟确认与 Nagle 算法交互总结
TCP 通信实战分析环境搭建与实验指南
作为一名 INTJ 型全栈开发专家,我理解深入分析网络协议是构建高效应用的基础。TCP 作为互联网的核心协议,掌握其内部机制对解决性能问题至关重要。我将为您提供一套完整的实验环境和详细步骤,帮助您掌握 TCP 的关键机制。
实验环境搭建
虚拟机配置
我们需要准备两台虚拟机,以 Ubuntu 为例:
服务端 VM (192.168.1.110)
客户端 VM (192.168.1.101)
网络配置验证
在两台机器上都执行下列命令验证连通性:
1. 解密 TCP 三次握手和四次挥手
三次握手分析
在服务端运行:
在客户端运行:
按 Ctrl+C 停止抓包,分析结果:
这里更推荐Wireshark图形化界面分析:

Wireshark 可以⽤时序图的⽅式显示数据包交互的过程,从菜单栏中,点击 统计 (Statistics) → 流量图 (Flow Graph),然后,在弹出的界⾯中的「流量类型」选择 「TCP Flows」,你可以更清晰的看到,整个过程中 TCP 流的执⾏过程:

为什么三次握⼿连接过程的 Seq 是 0 ?实际上是因为 Wireshark ⼯具帮我们做了优化,它默认显示的是序列号 seq 是相对值,⽽不是真实值。
如果你想看到实际的序列号的值,可以按照路径 【编辑Preferences | protocols | TCP | Relative Seq】找到Relative Seq,把它给取消,操作如下:


取消后,Seq 显示的就是真实值了:

可⻅,客户端和服务端的序列号实际上是不同的,序列号是⼀个随机值。
上图三次握手过程可以和TCP三次握手过程结合起来看,可以发现是一致的。
为什么抓到的 TCP 挥⼿是三次,⽽不是书上说的四次?当被动关闭⽅(上图的服务端)在 TCP 挥⼿过程中,「没有数据要发送」并且「开启了 TCP 延迟确认机制」,那么第⼆和第三次挥⼿就会合并传输,这样就出现了三次挥⼿。⽽通常情况下,服务器端收到客户端的 FIN 后,很可能还没发送完数据,所以就会先回复客户端⼀个 ACK 包,稍等⼀会⼉,完成所有数据包的发送后,才会发送 FIN 包,这也就是四次挥⼿了。
四次挥手分析
在服务端运行:
在客户端使用 telnet 连接然后断开:
分析四次挥手过程:
这里更推荐Wireshark图形化界面分析,分析TCP Flow 图:

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 通信实战分析环境搭建与实验指南,涵盖了所有请求的分析场景:
- 解密了 TCP 三次握手和四次挥手的完整过程
- 提供了 TCP 三次握手异常情况的实验方案与分析:
- 使用 iptables 模拟 SYN、SYN+ACK 和 ACK 丢包
- 包含详细的命令和观察方法
- 配置了 TCP 快速建立连接 (TCP Fast Open) 的实验环境
- 实现了 TCP 重复确认和快速重传的模拟与分析
- 搭建了 TCP 流量控制实验场景
- 设计了 TCP 延迟确认与 Nagle 算法交互的实验
指南包含所有必要的命令、配置和结果分析方法,可以直接在两台虚拟机上执行操作。
您可以通过以下命令启动第一个实验:
- Author:felixfixit
- URL:http://www.felixmicrospace.top/article/tcp_communication_analysis_guide
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!







