从Wireshark抓包实战看TCP的‘自动重传’：如何用Go-Back-N和Selective Repeat解决丢包问题

从Wireshark抓包实战看TCP的‘自动重传’：如何用Go-Back-N和Selective Repeat解决丢包问题

在网络通信中，数据包的丢失是不可避免的，特别是在弱网或高延迟环境下。TCP协议通过自动重传请求（ARQ）机制确保数据的可靠传输，而Wireshark这样的抓包工具则为我们提供了观察和分析这些机制实际运作的窗口。本文将带你深入TCP的重传世界，通过真实抓包案例，解析Go-Back-N和Selective Repeat这两种关键重传策略的差异与应用场景。

1. TCP重传机制基础与Wireshark观察

TCP的可靠性建立在确认应答和超时重传两大机制之上。当发送方发送一个数据段后，会启动一个重传计时器。如果在指定时间内没有收到接收方的确认（ACK），发送方会认为数据丢失并触发重传。

在Wireshark中，我们可以通过以下特征识别重传包：

• Packet列显示"[TCP Retransmission]"标记
• Sequence number与之前发送的包相同
• Time since last frame明显大于常规间隔

一个典型的停止等待ARQ在Wireshark中的表现如下：

No. Time Source Destination Protocol Length Info 1 0.000000 192.168.1.2 192.168.1.3 TCP 66 5000→6000 [SYN] Seq=0 2 0.000100 192.168.1.3 192.168.1.2 TCP 66 6000→5000 [SYN, ACK] Seq=0 Ack=1 3 0.000200 192.168.1.2 192.168.1.3 TCP 66 5000→6000 [ACK] Seq=1 Ack=1 4 0.000300 192.168.1.2 192.168.1.3 TCP 1466 5000→6000 [PSH, ACK] Seq=1 Ack=1 Len=1400 5 1.500000 192.168.1.2 192.168.1.3 TCP 1466 [TCP Retransmission] 5000→6000 [PSH, ACK] Seq=1 Ack=1 Len=1400

这个抓包示例显示，初始数据包（No.4）在1.5秒后仍未收到ACK，触发了重传（No.5）。

2. 连续ARQ：提升网络效率的关键

停止等待ARQ虽然简单，但效率低下。连续ARQ通过滑动窗口机制允许发送方连续发送多个数据包而不必等待每个包的确认，大幅提高了信道利用率。

2.1 Go-Back-N (GBN) 策略解析

GBN协议中，发送方维护一个发送窗口，窗口内的包可以连续发送。接收方只按序确认，任何乱序到达的包都会被丢弃。

Wireshark中GBN的典型表现：

1. 发送方连续发送Seq=1,2,3,4,5
2. 包3丢失，接收方只能确认Seq=2
3. 发送方收到ACK=2后，重传Seq=3,4,5

这种"全部重传"的特性在抓包中表现为：

No. Time Source Destination Protocol Length Info 6 0.000000 A B TCP 1466 [PSH, ACK] Seq=1 Len=1400 7 0.000100 A B TCP 1466 [PSH, ACK] Seq=1401 Len=1400 8 0.000200 A B TCP 1466 [PSH, ACK] Seq=2801 Len=1400 9 0.000300 B A TCP 66 [ACK] Ack=1401 10 0.500000 A B TCP 1466 [TCP Retransmission] Seq=2801 Len=1400 11 0.500100 A B TCP 1466 [PSH, ACK] Seq=4201 Len=1400 12 0.500200 A B TCP 1466 [PSH, ACK] Seq=5601 Len=1400

这里Seq=2801的包触发了重传（No.10），尽管Seq=4201和5601可能已经正确传输。

2.2 Selective Repeat (SR) 策略深度剖析

SR协议通过选择性重传解决了GBN的效率问题。接收方会缓存乱序到达的包，并单独确认每个正确接收的包。

在Wireshark中识别SR行为：

• 接收方发送的ACK包含特定序列号而非累积确认
• 发送方只重传丢失的特定包

典型抓包模式：

No. Time Source Destination Protocol Length Info 13 0.000000 A B TCP 1466 [PSH, ACK] Seq=1 Len=1400 14 0.000100 A B TCP 1466 [PSH, ACK] Seq=1401 Len=1400 15 0.000200 B A TCP 66 [ACK] Ack=1 16 0.000300 B A TCP 66 [ACK] Ack=1401 17 0.500000 A B TCP 1466 [TCP Retransmission] Seq=2801 Len=1400 18 0.500100 B A TCP 66 [ACK] Ack=2801

注意这里每个包都获得了独立确认（No.15,16,18），且只重传了丢失的包（No.17）。

3. 滑动窗口：TCP流量控制的核心

滑动窗口机制不仅管理重传，还控制着网络流量。窗口大小决定了发送方可以发送的未确认数据量，它会根据网络状况动态调整。

3.1 窗口大小与网络性能

通过Wireshark的"TCP Window"字段，我们可以观察窗口变化：

No. Time Source Destination Protocol Length Info 19 0.000000 A B TCP 66 Win=65535 20 0.100000 B A TCP 66 Win=32768 21 0.200000 A B TCP 66 Win=16384

窗口缩小通常表明接收方处理能力下降或网络拥塞。

3.2 窗口缩放与高吞吐量

现代TCP实现使用窗口缩放选项（Window Scale）支持更大的窗口：

# 在Linux中查看窗口缩放设置 sysctl net.ipv4.tcp_window_scaling

典型值为2-14，将窗口大小从65KB扩展到1GB。

4. 实战：Wireshark分析重传场景

4.1 配置Wireshark过滤规则

针对重传分析的关键过滤表达式：

tcp.analysis.retransmission # 显示所有重传包 tcp.analysis.out_of_order # 显示乱序包 tcp.analysis.duplicate_ack # 显示重复ACK

4.2 常见重传模式识别

1. 超时重传：

   • RTO（Retransmission Timeout）后触发
   • 间隔时间呈指数增长（1s, 2s, 4s, 8s...）

2. 快速重传：

   • 收到3个重复ACK后触发
   • 通常在更短时间内发生

3. 选择性ACK（SACK）：

   • TCP选项字段包含SACK信息
   • 允许接收方告知发送方哪些块已接收

4.3 性能优化建议

基于抓包分析的实际调优经验：

1. RTO调整：

# Linux中修改最小RTO（默认为1s） echo 200 > /proc/sys/net/ipv4/tcp_rto_min

2. 重传策略选择：

• 高延迟网络：优先考虑SR策略
• 低带宽网络：GBN可能更节省资源

3. 缓冲区设置：

# 调整TCP接收窗口大小 sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456' sysctl -w net.ipv4.tcp_wmem='4096 16384 4194304'

在实际网络调试中，我发现结合Wireshark的时序图和TCP流图能快速定位重传根源。特别是在处理视频流等实时应用时，理解这些重传机制对优化QoS至关重要。