问题背景

来自于同事咨询的一个办公网网络问题，说是监控出来的客户端 ACK 时延极其大，感觉奇怪，就来互相探讨一下。

而大概的背景就是，近期优化公司办公网运营，基于科来 NPM 回溯设备对网络进行了相关监控分析，其中有涉及客户端 ACK 时延的一个指标（这里的客户端指的是办公接入客户端，或是电脑，或是手机，又或是其它设备），因为抓包点在办公网核心交换机，所以也就是服务器端数据从核心交换机到客户端，客户端响应的 ACK 再到核心交换机，这样一个来回时延的数据问题。

问题信息

数据包跟踪文件信息主要如下：

λ capinfos dy.pcapngFile name:           dy.pcapngFile type:           Wireshark/... - pcapngFile encapsulation:  EthernetFile timestamp precision:  nanoseconds (9)Packet size limit:   file hdr: (not set)Packet size limit:   inferred: 64 bytes - 1444 bytes (range)Number of packets:   23 kFile size:           2910 kBData size:           32 MBCapture duration:    122.474566398 secondsFirst packet time:   2023-12-11 09:37:09.503482522Last packet time:    2023-12-11 09:39:11.978048920Data byte rate:      263 kBpsData bit rate:       2104 kbpsAverage packet size: 1377.05 bytesAverage packet rate: 191 packets/sSHA256:              93e5afa57f9124dcce078479c4fdf8ed73c8672675a26b1d83e30522c288d250SHA1:                07b4a34e13d8c420940dd374128d6cc3f300e11cStrict time order:   TrueCapture application: Editcap (Wireshark) 4.2.0 (v4.2.0-0-g54eedfc63953)Capture comment:     Sanitized by TraceWrangler v0.6.8 build 949Number of interfaces in file: 1Interface #0 info:                     Encapsulation = Ethernet (1 - ether)                     Capture length = 2048                     Time precision = nanoseconds (9)                     Time ticks per second = 1000000000                     Time resolution = 0x09                     Number of stat entries = 0                     Number of packets = 23400

数据包文件通过 NPM 回溯分析下载，并根据 IP 通讯对做过特定过滤，且经过 TraceWrangler 匿名化软件处理。捕获总时长 122.47 秒，数据包数量 23k 个，速率 2104 kbps 。

1. 关于 TraceWrangler 匿名化软件简介，可以查看之前的文章《Wireshark 提示和技巧 |  如何匿名化数据包》

2. 另外一个比较特别的地方是 Packet size limit: inferred: 64 bytes - 1444 bytes (range) ，通常来说根据 snaplen 做截断，应该是一个统一的数值，也就是所有的数据包捕获长度应该是一样的，而不是一个范围值，这里估计是 NPM 回溯分析设备所处理设置的原因。

专家信息如下，有 Malformed Packet、DSACK、DUP ACK、疑似虚假重传、快速重传、重传等等问题。其中重传、 DUP ACK 以及 Window update 相关数据包数量较多，这需要进一步分析。

会话信息如下，基本是 server 向 client 传输数据，约 2Mbps。

问题分析

数据包跟踪文件展开详细信息如下，起始一般可以重点关注的就是 TCP 三次握手信息，像是 IRTT、MSS、TS 时间戳、WS 等等，很多信息都可以在这三个数据包中得到。

像本次案例的 IRTT 9.6ms、传输 MSS 1382、支持 WS、TS、SACK 等。

其中在 No.4 数据包标识的一个 Malformed Packet 问题，是匿名化软件处理时产生的一个小问题，原始数据包文件中是正常的。话说是抖音应用，客户端是手机 🤔 。。。

直奔问题点，同事的疑问来自于科来 NPM 回溯系统分析统计结果，其中客户端 ACK 时延最大达到了 6 秒之多。

在梳理其中问题数据包时，发现不少数据包的重传现象一致，以下就只取了一个问题时间点作为说明（并非客户端ACK时延最大的一个点），该客户端 ACK 时延大约在 1.8 秒左右。

注：科来的客户端ACK时延，指的是一个客户端不带负载的ACK包与其确认的服务器带负载的数据包时间差。

初步分析如下：

1. No.15381（包括之前）- No.15385，为服务器端传输的数据分段，其中除了最后一个 No.15385 数据包外，其余均为一个 MSS 1382 标准分段（包含数据负载 1370 + 时间戳 12 ）的数据包；

2. No.15386 - No.15396，为客户端对于收到的服务器数据分段的 ACK 数据包；

3. No.15397，为服务器产生的一次超时重传，也就是 No.15385 的重传，至于为什么会产生这次重传，原因在之后分析（问题点一）；

4. No.15398，为客户端所发 ACK，ACK Num 为 19830167，也就是确认了服务器最后一个数据分段，此处也比较特殊，也在之后分析（问题点二）；

5. No.15399 - No.15400，同样为客户端的 ACK，标记为 Window Update，说明仅是客户端窗口变化所发的更新包；

6. ... 之后忽略

此处有点意思的是，对于 Wireshark 的 ACK 确认时延计算逻辑，算的是 No.15398 与 No.15385 之间的时间差，也就是 0.072800954 秒，也就是用 No.15398 ACK 数据包和最起始的数据分段 No.15385 相比，而不是和最后一次重传的数据分段 No.15397 相比。

对比科来 ACK 确认时延计算逻辑，时延是用 ACK 数据包和 No.15397 来做相减，也就是 ACK 相较最后一个重传数据分段，也就是相邻数据分段的时间差。

当然在这个点上，这只是不同网络协议分析工具的算法不同而已，ACK 数据包计算的对象，一个是和最原始数据包，另一个是和最后一次重传的数据包，两者我觉得都有一定道理。

而回到同事的问题点，NPM 系统回溯所展现的问题，客户端 ACK 时延大约在 1.8 秒左右，这个 1.8 秒就比较讲究了，而在上上图实际我也提前标注出来了（黄色圆框），No.15399 与上一个数据包 No.15398 的时间差就在 1.8 秒左右，那么所以结合上一个计算逻辑，科来实际上计算的客户端 ACK 时延是 No.15399 和 No.15397 两者之间的时间差，也就是 1.816983333 秒。

为什么呢？为什么不用 No.15398 这个 ACK 数据包呢？？？实际上在咨询科来工程师之后，得到的答案实际上也是因为算法逻辑，也就是上面的问题点二，No.15398 比较特殊，它是一个带有 TCP Option 字段的数据包。在科来的算法中，当 ACK 数据包中带有 TCP Option 字段时该 ACK 排查在外不计算，因此最终是用 No.15399 这个不带负载的 ACK 包和 No.15397 这个最新的重传数据包，这两者之间的时间差来作为客户端 ACK 时延。

因此在众多类似 No.15397 这种重传的问题产生后，最终统计出来的数据中，最大的一个客户端 ACK 时延就达到了 6 秒之多，这就感觉客户端的接入网络质量很差一样，像是手机客户端无线网络质量很差。。。但实际情况却并非如此。

当然说到办公网络运营，首先终端环境很复杂，像是手机所产生的网络访问，一方面和接入网络质量有关，另和使用上也有关，譬如切换应用，或者手机锁屏等等动作，数据包上就会产生不一样的问题现象，所以针对像是办公网络的监控，我觉得还是挺复杂的，哪些监控指标真正有用处，还是相当有讲究的，此处研究不多，就不再展开了。

当然说到科来关于 ACK 数据包中带有 TCP Option 字段时该 ACK 排查在外不计算的逻辑，这里我也不是太能理解，有科来的兄弟能帮忙解释下否，是不是有特殊的场景确实需要这样做。

继续分析

解决完客户端 ACK 时延统计大的问题后，就再回到之前的两个问题：

1. No.15397 的重传数据包是怎么产生的；

2. No.15398 是个什么样的 ACK。

仍是之前的数据包截图，基于以下几点，判断 No.15397 是一个 TLP（Tail Loss Probe）控制发送的重传数据包。

1. 首先没有任何丢包迹象；

2. 其次 RTO 200ms+，No.15397 相较 No.15385 仅过去了 68ms 就产生了重传现象；

3. 最后 No.15385 这个数据分段所处的位置，是服务器端所传输多个数据分段中的最后一个。

参考网络上关于 TLP 的一个定义：Tail Loss Probe (TLP) 是一个发送端算法，主要目的是使用快速重传取代RTO超时重传来处理尾包丢失场景。在一些WEB业务中，如果TCP尾包丢失，如果依靠RTO超时进行重传会带来比较大的延迟，进而影响用户体验。如果一个TCP连接没有在一段时间内没有收到ACK报文，TLP会强制传输还没有收到ACK确认的报文里面的最后一个报文或者未发送的新报文(传输的这个报文就叫做loss probe)。

问题总结

案例只是简单分析了一下应用 TLP 重传的数据包现象和相关过程，对于 TLP 或者还有 RACK 并没有展开详细说明，后续会找时间看能否模拟出更多场景来做进一步说明和测试。

问题参考

https://www.rfc-editor.org/rfc/rfc8985.html

https://www.cnblogs.com/lshs/p/6038581.html

https://www.cnblogs.com/lshs/p/6038592.html

往期推荐

1. Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

2. Wireshark 提示和技巧 | a == ${a} 显示过滤宏

3. Wireshark TS | 防火墙空闲会话超时问题

4. Wireshark TS | 循序渐进看系统访问偶发失败

5. 网络设备 MTU MSS Jumboframe 全解

后台回复「TT」获取 Wireshark 提示和技巧系列 合集

后台回复「TS」获取 Wireshark Troubleshooting 系列 合集

如需交流，可后台直接留言，我会在第一时间回复，谢谢！

原文始发于微信公众号（Echo Reply）：Wireshark TS | 应用 TLP 重传案例