TCP Analysis Flags 之 TCP Spurious Retransmission

媒介

默认情况下，Wireshark 的 TCP 解析器会跟踪每个 TCP 会话的状态，并在检测到问题或潜在问题时提供额外的信息。在第一次打开捕获文件时，会对每个 TCP 数据包进行一次分析，数据包按照它们在数据包列表中出现的顺序进行处置惩罚。可以通过 “Analyze TCP sequence numbers” TCP 解析首选项启用或禁用此功能。
TCP 分析展示

在数据包文件中进行 TCP 分析时，关于 “TCP Spurious Retransmission” 一样平常是如下表现的，包括：

• Packet List 窗口中的 Info 信息列，以 [TCP Spurious Retransmission] 黑底红字进行标注；
  
• Packet Details 窗口中的 TCP 协议树下，在 [SEQ/ACK analysis] -> [TCP Analysis Flags] 中界说该 TCP 数据包的分析说明。
  

   

• 考虑到 TCP 乱序、重传场景的复杂性，专家信息在重传的判定上，前面都会有一个(suspected)，表现疑似，说明并不是百分百正确，属于 Note 留意。
  
• 另在专家信息中，对于 TCP Spurious Retransmission 标志位分析同时会增加两种 Note，包括 Spurious Retransmission 和 Retransmission。
  

  TCP Spurious Retransmission 界说

文档中关于 TCP Spurious Retransmission 的界说看起来简朴，但实际考虑到 TCP 乱序、重传场景的复杂性，在 TCP 分析中对于 TCP Spurious Retransmission 是与 TCP Out-Of-Order、TCP Fast Retransmission、TCP Retransmission 等在一起判定标志乱序或重传类型，而在不少场景还会有判定堕落的问题，固然 Wireshark 考虑到这种情况，也有手动修正的选项，这恰好也侧面证明了上面的说法，关于 TCP 乱序、重传的复杂性。
TCP Spurious Retransmission 的界说如下，当以下全部条件都为真时设置：

• SYN 或者 FIN 标志位设置
  
• 不是 Keep-Alive 数据包
  
• TCP 段长度大于零
  
• 该 TCP 流的数据已被确认，也就是说，反方向之前的 LastACK Num 已被设置
  
• 该数据包的 Next Seq Num 小于或即是反方向之前的 LastACK Num
  

替换 Fast Retransmission 、Out-Of-Order 和 Retransmission。

1. Checks for a retransmission based on analysis data in the reverse direction. Set when all of the following are true:
3. The SYN or FIN flag is set.
4. This is not a keepalive packet.
5. The segment length is greater than zero.
6. Data for this flow has been acknowledged. That is, the last-seen acknowledgment number has been set.
7. The next sequence number is less than or equal to the last-seen acknowledgment number.
9. Supersedes “Fast Retransmission”, “Out-Of-Order”, and “Retransmission”.

复制代码

  联合实际源码+场景，文档中界说有错误，第1个条件(SYN 或者 FIN 标志位设置)和第3个条件(TCP 段长度大于零)应该是或的关系，而不是与的关系。
  详细的代码如下，总的来说这段代码是 Wireshark 中 TCP 分析模块的一部门，用于检测和标识 TCP 数据包中的各种重传类型。它的主要功能是根据当前数据包的序列号、长度、标志位以及之前收到的 TCP 数据包的信息，判定当前数据包是否属于重传，如果是则进一步确定它属于哪种重传类型。
根据分析 TCP 数据包的各种特征，对重传数据包进行分类，有助于更好地理解 TCP 连接中的重传行为，对于诊断网络问题很有资助。在打扫了 KeepAlive 数据包后，如果全部下述条件均满足，则以为该数据包是一个虚伪重传包。

• 检查 TCP 段巨细是否大于 0；
  
• 检查反方向之前的 LastACK Num 是否不为 0；
  
• 检查数据包的 Next Seq Num（seq+seglen）是否小于或即是反方向之前的 LastACK Num。
  

1.     /* RETRANSMISSION/FAST RETRANSMISSION/OUT-OF-ORDER
2.      * If the segment contains data (or is a SYN or a FIN) and
3.      * if it does not advance the sequence number, it must be one
4.      * of these three.
5.      * Only test for this if we know what the seq number should be
6.      * (tcpd->fwd->nextseq)
7.      *
8.      * Note that a simple KeepAlive is not a retransmission
9.      */
10.     if (seglen>0 || flags&(TH_SYN|TH_FIN)) {
11.         gboolean seq_not_advanced = tcpd->fwd->tcp_analyze_seq_info->nextseq
12.                 && (LT_SEQ(seq, tcpd->fwd->tcp_analyze_seq_info->nextseq));
14.         guint64 t;
15.         guint64 ooo_thres;
17.         if(tcpd->ta && (tcpd->ta->flags&TCP_A_KEEP_ALIVE) ) {
18.             goto finished_checking_retransmission_type;
19.         }
21.         /* This segment is *not* considered a retransmission/out-of-order if
22.          *  the segment length is larger than one (it really adds new data)
23.          *  the sequence number is one less than the previous nextseq and
24.          *      (the previous segment is possibly a zero window probe)
25.          *
26.          * We should still try to flag Spurious Retransmissions though.
27.          */
28.         if (seglen > 1 && tcpd->fwd->tcp_analyze_seq_info->nextseq - 1 == seq) {
29.             seq_not_advanced = FALSE;
30.         }
32.         /* Check for spurious retransmission. If the current seq + segment length
33.          * is less than or equal to the current lastack, the packet contains
34.          * duplicate data and may be considered spurious.
35.          */
36.         if ( seglen > 0
37.         && tcpd->rev->tcp_analyze_seq_info->lastack
38.         && LE_SEQ(seq + seglen, tcpd->rev->tcp_analyze_seq_info->lastack) ) {
39.             if(!tcpd->ta){
40.                 tcp_analyze_get_acked_struct(pinfo->num, seq, ack, TRUE, tcpd);
41.             }
42.             tcpd->ta->flags|=TCP_A_SPURIOUS_RETRANSMISSION;
43.             goto finished_checking_retransmission_type;
44.         }
45.     ...
46.     }
48. finished_checking_retransmission_type:

复制代码

  

• next expected sequence number，为 nextseq，界说为 highest seen nextseq。
  
• lastack，界说为 Last seen ack for the reverse flow。
  

  Packetdrill 示例

根据上述 TCP Spurious Retransmission 界说和代码说明，通过 packetdrill 模拟在收到对一个数据分段 ACK 已确认的情况下，仍然再次重传同一个数据分段即可，就会以为是 TCP Spurious Retransmission 。

1. # cat tcp_spurious_retrans.pkt
2. 0   socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
3. +0  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
4. +0  bind(3, ..., ...) = 0
5. +0  listen(3, 1) = 0
7. +0 < S 0:0(0) win 16000 <mss 1460>
8. +0 > S. 0:0(0) ack 1 <...>
9. +0.01 < . 1:1(0) ack 1 win 16000
11. +0 accept(3, ..., ...) = 4
12. +0 < P. 1:21(20) ack 1 win 15000
13. +0 > . 1:1(0) ack 21 <...>
14. +0 < P. 21:41(20) ack 1 win 15000
15. #

复制代码

经 Wireshark 展示如下，可以看到满足判定条件后，No.6 标识 [TCP Spurious Retransmission] ，是因为客户端发送的数据分段 No.4 Seq Num 1 + Len 20，已由服务器 No.5 ACK 21 确认收到了该数据分段，但是在之后客户端又再次发送了同样一个数据分段 No.6 Seq Num 1 + Len 20，此时 Wireshark 就会以为 No.6 是虚伪重传，而 No.7 是一次重复确认。

实例

关于 TCP Spurious Retransmission 的实例，实际日常抓包中不算少见，是一种比力好理解的 TCP 分析标志。在差别的场景中，也会伴生着出现像是 TCP Dup ACK 、TCP ACKed unseen segment、TCP Previous segment not captured 等信息。

• TCP Spurious Retransmission + TCP Dup ACK
  

一个 ACK 响应慢的的场景，根据 Length 54 长度，可知该数据包跟踪文件是在客户端捕获，IRTT 为 45.7ms，但在客户端收到服务器端 No.181 的数据分段后，理论应该最多几 ms 内说响应 ACK，但是直到 209ms 之后才复兴 No.182 ACK，此时在服务器端已产生了超时重传，也就是 No.183，所以在客户端收到 No.183 同样的一个数据分段后，即标识为 [TCP Spurious Retransmission] , 而此次客户端不到 1ms 就响应了 ACK，也就是 [TCP Dup ACK]。

• TCP Spurious Retransmission + TCP ACKed unseen segment
  

一个 ACK 丢失的场景，根据客户端 No.6 数据包 ACK Num 9 可知已经收到了服务器端发送的 Seq Num 9 之前的全部数据分段，但往上到 No.4 却没有看到相关数据分段，固然只是没有捕获到，实际上客户端已收到，因此 No.6 标识成 [TCP ACKed unseen segment] ，但为什么看到了 No.6 ACK 了，服务器端仍然重传了 No.7 。实际上这是抓包点的问题，或者说此数据包跟踪文件不是在服务器端上抓的，譬如在中间端抓取，捕获到了 No.6 ACK，但是这个 ACK 再往服务器去传输时丢失了，因此服务器在没收到 ACK 的情况下，重传了 No.7 Seq Num 1 + Len 8 的数据分段，也因此被标识成 [TCP Spurious Retransmission]。

• 错误的 TCP Spurious Retransmission
  

错误的 TCP 虚伪重传场景，如下所示，No.5-6 发送端所发送的数据分段，因个别未捕获到，标识为 [TCP Previous segment not caputred] ，但接收端 No.9 的 ACK Num 9881 说明已确认接收了序号 9881 之前的数据段，但在 No.11 发送端又重新发送了 Seq Num 4940 + Len 1368 的数据分段，因此符合条件，标识为 [TCP Spurious Retransmission] 。

一切看起来挺合理，但为什么说是判定错误呢？凡事深想一层，干活多做一步，再瞅瞅 ip.id ，你会发现有些问题。发送端 No.11 的 ip.id 为 29559，这不是应该是在 No.4 和 No.5 之间的一个数据包嘛，所以呢，No.11 不是重传，它是原本的数据分段，也因此它应该被标识成 [TCP Out-Of-Order] 。

但是为什么会出现如许的情况，乱序的数据段出现在了 ACK 确认之后，虽然不是完全确认抓包的情况，但根本上可以猜测是互换机镜像或者 TAP 出了问题，更有可能是后者造成的乱序。
总结

考虑到数据包会出现乱序、重传等各类差别的场景，产生 TCP Spurious Retransmission 的情形自然也是五花八门，详细问题详细分析。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。