本文主要是介绍Wireshark TS | 应用传输丢包问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
问题背景
仍然是来自于朋友分享的一个案例,实际案例不难,原因也就是互联网线路丢包产生的重传问题。但从一开始只看到数据包截图的判断结果,和最后拿到实际数据包的分析结果,却不是一个结论,方向有点跑偏,所以记录下本篇。
问题信息
开局的数据包截图大概就如下,一堆超时重传信息,问题是什么,不熟悉的可能直接就说是丢包了,像我稍微熟悉的,一眼感觉就像是互联网常见的 MTU 问题,客户端发送的数据包 Len 2760 也就是 2 个 MSS 1380 的大小,在中间传输过程中碰到了 MTU 问题, 以至于 1380 大小的数据包被丢弃,因此产生了众多超时重传。
基于以上截图,初始结论就是互联网线路问题,根因是 MTU 。但总有意外的事发生,等我拿到了实际数据包仔细分析,虽然还是互联网线路产生的丢包问题,但根因却不是 MTU 了,初始结论错误。
数据包跟踪文件信息主要如下:
λ capinfos 1220.pcapng
File name: 1220.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Packet size limit: inferred: 54 bytes
Number of packets: 40
File size: 4264 bytes
Data size: 37 kB
Capture duration: 14.583142 seconds
First packet time: 2023-12-18 07:35:28.365933
Last packet time: 2023-12-18 07:35:42.949075
Data byte rate: 2553 bytes/s
Data bit rate: 20 kbps
Average packet size: 931.10 bytes
Average packet rate: 2 packets/s
SHA256: 096e0919a13f8ff2c0b8b4691ff638c14345df621ecd9157daa3b3ce3447b88c
SHA1: 3267274c4fce576dde3446d001372b9b34f15717
Strict time order: True
Capture application: Editcap (Wireshark) 4.2.0 (v4.2.0-0-g54eedfc63953)
Capture comment: Sanitized by TraceWrangler v0.6.8 build 949
Number of interfaces in file: 1
Interface #0 info:Encapsulation = Ethernet (1 - ether)Capture length = 262144Time precision = microseconds (6)Time ticks per second = 1000000Time resolution = 0x06Number of stat entries = 0Number of packets = 40
客户端通过 Wireshark 捕获数据包,捕获时长 14.58s,数据包数量 40 个,文件大小 4.264 字节,平均速率约 20kbps,总体上来说速率很低。数据包经过 Editcap 编辑和 TraceWrangler 处理,一方面是改了文件格式,另一方面就是重要的匿名。
关于 TraceWrangler 匿名化软件简介,可以查看之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》
专家信息如下,数据包总数 40 的情况下,疑似重传数据包数量就有 12 个,该 TCP 连接的质量可想而知。
问题分析
首先是 TCP 三次握手,客户端和服务器各自所通告的 MSS 为 1460 和 1380 ,两者取小为 1380 ,所以最后传输遵循的最大 TCP 分段就是 1380。另 IRTT 0.027269 秒,同时支持 SACK 和 WS 。
客户端 192.168.38.134 所发送的数据,在直到产生问题的 No.18 Len 2760 之前,数据包长度还是小分段 213、129、105、737 等,这也确实容易第一眼给人错觉,像是 No.18 之后 MSS 1380 的数据分段发生了 MTU 问题造成丢包重传。
我们将数据包分成三段,No.1-3 TCP 三次握手,No.4-16 正常数据交互,No.17 以及之后为问题点,重点分析。
分析全过程如下:
- No.17-22 均为客户所发送的数据分段,除了 No.17 Len 683 较小分段外,其他均为 1 或 2 个 MSS 1380 分段;
- 经过一个 RTT 时间,服务器端返回的 No.23 ACK Num 969 仅仅确认了 No.17 ,紧接着的 No.24 即判断为 TCP Dup ACK,因为它的 ACK Num 仍为 969,并携带有 SACK 标识 SLE 7869,SRE=9249。此处关键,代表说明确认收到了客户端所发送的 Seq Num 969 之前以及 Seq Num 7869-9249 之间的数据,意味着服务器端还是收到了一个 9249-7869=1380 MSS 大小的数据分段,所以并不是初始结论,超出了中间路径 MTU 大小而造成所有 MSS 1380 大小的数据包被丢弃;
- 但问题仍是中间互联网线路中间发生了丢包,哪些数据分段丢失了?No.18-20 , Seq Num 969 - 7869 之间的数据。 由于客户端收到了 No.24 SACK ,所以紧接着进行了 No.25-26、No.28-29 的快速重传,考虑到拥塞窗口减小的缘故,只重传了 Seq Num 969 - 6489 的数据,而 Seq Num 6489 - 7869 并未发送。期间也收到了一个客户端 No.27 SACK,确认又收到了一个 Seq Num 9249 - 10629 =1380 MSS 大小的数据分段;
- 不幸的是,经过一个 RTT 时间,服务器端返回的 No.30 SACK 仅确认了 Seq Num 2349 之间的数据,也就是相较之前,只多确认收到了一个 MSS 1380 的数据分段,而 SLE,SRE 没有任何变化,说明之前重传的数据包又发生了丢包;
- 此时拥塞窗口继续减小,客户端仅发送了一个 No.31 的新数据分段,以及再次重传了 No.32 Seq Num 为 2349 的数据分段,因为 No.30 代表缺失了 Seq Num 2349 - 7869 之间的数据;
- 服务器返回的 No.33 SACK 继续仅多确认了一个 MSS 1380 大小的数据,ACK Num 为 3729,客户端再次重传 No.34-35;
- 之后 No.34 - No.40 ,客户端进行了多次超时重传,超时时间明显不断翻倍,此时不管是中间互联网线路持续丢包,还是服务器端因长时间等待已释放连接,总之不再有确认返回。
问题总结
整个分析过程中因为多出了 SLE SRE 的缘故,判断出的问题根因也发生了变化,并非 MTU 问题。而最终经朋友反馈,应用传输丢包问题的原因就是运营商线路丢包,符合实际数据包现象(丢失的数据分段无规律可言),毕竟数据包从不说谎。
这篇关于Wireshark TS | 应用传输丢包问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!