问题背景

网络数据包分析工作做久了，习惯性的就会存有一堆的跟踪文件，不及时整理的话，下次再看到有的跟踪文件就完全记不起来是什么情况了。😂 两眼墨黑

本次案例就是如此，跟踪文件名 client-fast-retrans.pcapng，乍看名字是关于快速重传的案例，准备分类重新存放的时候顺手打开了下，不瞅还好，一瞅还发现了一个 Wireshark TCP Analysis 的问题，故分享记录下。

问题信息

数据包跟踪文件基本信息如下：

$ capinfos client-fast-retrans.pcapng
File name:           client-fast-retrans.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   27
File size:           17 kB
Data size:           17 kB
Capture duration:    0.311468 seconds
First packet time:   2015-06-02 22:11:59.655051
Last packet time:    2015-06-02 22:11:59.966519
Data byte rate:      54 kBps
Data bit rate:       436 kbps
Average packet size: 629.70 bytes
Average packet rate: 86 packets/s
SHA256:              6ee7b5061a54bc22b44fe5bdbd10d7f0fcc2fdb63dd45f9bbf3327eefb15a191
RIPEMD160:           cd8614df4aa3316508290308c4b875459b9a9419
SHA1:                42704ab0674942a2cfcd77404784c7409b67283c
Strict time order:   True
Capture application: Editcap 2.6.13
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 27
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

1. 文件应该为 tcpdump 所捕获，之后在 windows 上通过 editcap 所修改过；
2. 数据包数量 27 个，平均速率 436 kbps；
3. 从数据包捕获时间来看是在 2015-06-02 。（😉 说明该跟踪文件来自互联网收集）

因为跟踪文件数据包数量总共就 27 个，专家信息所显示的一些问题像是重传或是快速重传的数量也就只 1 个。

问题分析

实际数据包分析，TCP 三次握手主要如下

完整数据包信息如下

跟踪文件为一个 HTTP 交互，在 TCP 三次握手正常建立连接后，客户端进行了 HTTP GET 请求了一个大小为 100MB 的 bin 文件，服务器响应 HTTP 200 OK ，之后正常传输文件。

首先说到一个常谈的问题，如何判断该跟踪文件的捕获点是哪？

1. IRTT，IRTT 为 0.103362s ，从 TCP 三次握手 SYN-SYN/ACK-ACK 的时间差值，初步判断捕获点为客户端或靠近客户端的地方；
2. Length ，首先可以看的是纯 ACK 数据包的长度，但是因为客户端和服务器端通过 TCP 三次握手协商下来的结果是均支持 TCP OPT 时间戳，所以纯 ACK 数据包的长度并不是 54 字节，无法根据小于 60 字节的情况判断是在客户端上所捕获，辅助判断无效；
3. TTL，其次查看 TTL ，客户端的 TTL 为 64 ，仍是一个 Linux 系统始发值，因为有可能在客户端所连接的二层接入交换机上所捕获（TTL 也是 64），所以辅助判断也无效。

该跟踪文件最后只能判断是在客户端或靠近客户端的二层交换环境上所捕获。

关于如何判断跟踪文件的捕获点，有兴趣的同学可以查看之前一篇完整的文章《捕获点之 TCP 三次握手》。

回到数据包快速重传问题，主要信息如下

初看下来好像和普通的快速重传现象没什么区别，初步分析过程：

1. 服务器所发的数据包 No.20 前丢了一个 TCP 分段 Seq 9577 ，所以 No.20 标记为 TCP Previous segment not captured ；
2. 客户端回应第一个 No.21 DUP ACK 确认还要 Seq 9577 分段（原 ACK 在 No.19）；
3. 服务器下一个数据包 No.22 仍不是 TCP 分段 Seq 9577；
4. 因此客户端回应第二个 No.23 DUP ACK 确认继续要 Seq 9577 分段；
5. 此时服务器像是因为 DUP ACK 的原因触发了快速重传，发送了 No.24 Seq 9577 数据包，因此 Wireshark 在此标记为 TCP Fast Retransmisson 。

所以感觉像是 Wireshark 判断为快速重传确实合情合理，但是细细一琢磨，会发现里面有些问题：

1. IRTT，IRTT 为 0.103362s ，说明客户端和服务器端 RTT 约为 103ms，如果捕获点在客户端，No.24 和 No.23 之间的时间差值仅为 71ns。试问从客户端发出 No.23 到服务器收到 No.23 之后触发快速重传，再到客户端所捕获，这个 71ns 的时间完全不符合现实；
2. DUP ACK，DUP ACK 的数量仅为 2 个，根据 RFC 2581 描述，触发快速重传是需要三个 DUP ACK 的，而在此跟踪文件仅有 2 个 DUP ACK，并不符合条件。

但为什么 Wireshark 会判断为快速重传，这个自然是 Wireshark TCP 分析的逻辑，TCP Fast Retransmission 部分说明如下（有兴趣的同学也可以直接查看源代码）。在以下条件完全满足的情况下，Wireshark 会标记为快速重传，用以替代乱序或重传。

TCP Fast Retransmission
Set when all of the following are true:

This is not a keepalive packet.
In the forward direction, the segment size is greater than zero or the SYN or FIN is set.
The next expected sequence number is greater than the current sequence number.
We have more than two duplicate ACKs in the reverse direction.
The current sequence number equals the next expected acknowledgement number.
We saw the last acknowledgement less than 20ms ago.

Supersedes “Out-Of-Order” and “Retransmission”.
1
2
3
4
5
6
7
8
9
10
11

从以上条件来看，一是 Wireshark 没有考虑上下文数据包时间差值的问题，所以忽略了 RTT 问题；二是 Wireshark 考虑到可能有 DUP ACK 丢失的情况下出现，所以在 >=2 个 DUP ACK 的时候就会判断为成快速重传，但这个绝对不是真正的 TCP 快速重传实现（必须满足 3个 DUP ACK）。

那么 No.24 数据包不是快速重传的话，它到底是什么？肯定不会是超时重传，那么它就只能是乱序。拿着乱序的逻辑重新去梳理该交互过程，是完全正确的。

1. 服务器所发的数据包 TCP 分段 Seq 9577 发生乱序，并未在 No.20 之前到达；
2. 服务器所发的数据包 No.20 前因为没有 TCP 分段 Seq 9577 ，所以 No.20 标记为 TCP Previous segment not captured ；
3. 客户端回应第一个 No.21 DUP ACK 确认要 Seq 9577 分段（原 ACK 在 No.19）；
4. 服务器下一个数据包 No.22 仍不是 TCP 分段 Seq 9577；
5. 因此客户端回应第二个 No.23 DUP ACK 确认继续要 Seq 9577 分段；
6. 此时服务器所发的数据包 TCP 分段 Seq 9577 乱序后姗姗来迟，因此 Wireshark 正确的判断应该在此标记为 TCP Out-Of-Order。

也可以利用 IP.ID 加以佐证，No.24 的 IP ID 为 49749 ，在 No.20 和 No.22 之前，因此乱序无疑。

再次看看科来分析器是如何判断的，准确的判断为 乱序 。👏 国产之光~

问题总结

目前 Wireshark 的使用版本为 Version 3.6.3 (v3.6.3-0-g6d348e4611e2) ，暂没有深究是否是一个 BUG，还是说可以提一个增强功能给 Wireshark，更或许 Wireshark 认为此 TCP 分析实现逻辑是有它自己的道理的。因为确实数据包的世界太多各种各样的现象，一切皆有可能。

---

感谢阅读，更多技术文章可关注个人公众号：Echo Reply ，谢谢。