Wireshark TS | 传输文件慢问题

问题背景

来自于朋友分享的一个案例,反馈服务器给客户端传输 8M 左右的文件时,需要 30 多秒,而在同一局域网下的另一台客户端访问服务器,传输同一个文件速度很快,只需要几秒,速度上差异较大。

我们就此问题讨论分析了下,其中有一些现象确实比较特别,就此分享下。


问题信息

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

λ capinfos "client slow.pcapng"
File name:           client slow.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   16 k
File size:           20 MB
Data size:           19 MB
Capture duration:    80.048161 seconds
First packet time:   2022-05-28 19:09:33.167685
Last packet time:    2022-05-28 19:10:53.215846
Data byte rate:      248 kBps
Data bit rate:       1986 kbps
Average packet size: 1172.93 bytes
Average packet rate: 211 packets/s
Strict time order:   True
Capture hardware:    Intel(R) Core(TM) i7-9700 CPU xxx
Capture oper-sys:    64-bit Windows 10 (2009), build 22000
Capture application: Dumpcap (Wireshark) 3.4.6 (v3.4.6-0-g6357ac1405b8)
Number of interfaces in file: 1
Interface #0 info:
                     Name = \Device\NPF_{xxx}
                     Description = 以太网
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = 64-bit Windows 10 (2009), build 22000
                     Number of stat entries = 1
                     Number of packets = 16943

λ

客户端为 win 10 64 位系统,通过 wireshark 捕获数据包,捕获时长 80s,数据包数量 16k,文件大小 20MB,平均速率约 1.986Mbps。

专家信息中出现数据分段未被捕获到、疑似重传以及 DUP ACK 的现象,考虑到数量较多,初步推测疑似出现了丢包问题。

Wireshark TS | 传输文件慢问题_第1张图片


Wireshark TS | 传输文件慢问题_第2张图片


问题分析

客户端行为

考虑到客户端反馈的问题和传输速度相关,简单看下 I/O Graphs ,基本在 2Mbps 左右。观察到服务器向客户端一共传输了 19M 字节,基于传输文件 8M 的大小,以及其中在 40秒左右出现的大概 2 秒完全无速度的传输间隔,猜测是客户端尝试进行了 2 次文件下载。

Wireshark TS | 传输文件慢问题_第3张图片

Slow-04

TCP Stream Graphs 中的 Time Sequence(tcptrace) 分析,粗看图示如下

Wireshark TS | 传输文件慢问题_第4张图片

放大显示后,会看到一种有规律的传输现象,每次随着慢启动开始, MSS 逐步增长,达到出现丢包(红圈标注以红短线显示),也就是出现了拥塞,此时会停顿下来,大约有 250ms 没有数据传输(红色箭头标注),之后开始又是慢启动再一次重复,一轮又一轮。

Wireshark TS | 传输文件慢问题_第5张图片

MSS 增长示意图

Wireshark TS | 传输文件慢问题_第6张图片

重传分段,以 250 ms 左右来看的话,基本上是属于超时重传现象了。

Wireshark TS | 传输文件慢问题_第7张图片


数据包分析

回到实际数据包,可以看到是使用 TLSv1.2 协议进行传输,根据 TCP 三次握手的结果,可知 RTT 约在 33ms,MSS 为 1436 。

Wireshark TS | 传输文件慢问题_第8张图片

在出现丢包的前一次传输中,可以看到服务器一共发送了共 10 个 TCP 分段,长度为 1383 字节,TLS 数据字段长度 1329 字节,在此并不是一个完整的 MSS 1460 字节。

Wireshark TS | 传输文件慢问题_第9张图片

疑似丢包和超时重传的完整数据包,图示如下:

Wireshark TS | 传输文件慢问题_第10张图片

主要现象分析:

  1. 在 No.100 和 No.99 之间出现了疑似丢包,提示TCP Previous segment not captured,根据 Seq 99027 和 Seq 93711 相差 5316 字节,为 4 个 1329 字节,确认在此丢失了 4 个 TCP 分段;
  2. client 在 No.110 回复了 SACK ,其中 ACK 93711 标记所需丢失的分段,SLE=99027 SRE=112317 标记已收到的分段;
  3. 之后数据包的交互,产生了 client 触发出两次 TCP Dup ACK,注意仅有两次,所以未能使 server 触发快速重传;
  4. server 经过 250ms 左右才超时重传了 Seq 93711 分段,以及之后的三个分段。

Wireshark TS | 传输文件慢问题_第11张图片

Wireshark TS | 传输文件慢问题_第12张图片

之后的丢包问题依旧,所产生的问题现象类似,因为无法满足三次 TCP Dup ACK的情况,所以每次都无法达到快速重传的条件,每一次超时重传都大概在 250ms,发生了总共 82 次,也就是 20.5 秒的时间处于空闲等待时间,所以说此次传输慢的问题,引起的根因是丢包,而造成最终速度慢的原因,确是由于不断产生出来的超时重传累积使然


深度分析

至此,其实对于传输文件慢的根因已经分析得出,下一步需要解决的就是如何定位找到发生丢包的点了。为什么还会有深度分析?实际上这也是在数据包分析中,我觉得能不断学习不断提高的地方,就是多观察多思考。

以下些问题点,是一些特殊而暂未有明确答案的地方。

  1. TCP MSS

其实在 TCP 三次握手协商中,已明确了 MSS 为 1436 字节,包括在之后的 TLS 握手时也现了 1490 最大长度的数据包(1436 + 54),但在后面的数据包传输阶段,却是以 1383(1329+54)字节为一个 TCP 分段在传输,而这种交互同时增长的方式,像是 MSS 变成了 1329 字节。

真实答案:未知。

猜测答案:server 应用层控制的字节发送行为,以及更有可能的一个答案见 4 。

  1. TCP DUP ACK

实际在上述问题的分析中,只是阐述了现象,只有两次 DUP ACK,因此无法触发快速重传。但仔细观察的同学是否有会这样的疑问,在 No.100 之后的不连续 Seq TCP 分段,为什么没有触发客户端连续产生 DUP ACK ?而仅仅是在 No.110 处产生了一个 SACK。

需要在此注意的是时间,No.100 - No.109 Server 传输的 TCP 分段是连续无任何时间间隔的情况下一瞬间进入,所以 client 未能响应乱序包而立马生成 ack ,最后可以理解是合并生成了一个 SACK。这在之后的数据包传输过程中,都是同一个现象,分段连续无任何时间间隔的进入。

当然也会有同学有疑问,这仅仅是 win10 普通客户端,全 0 无任何时间间隔的更可能只是捕获时间精度的问题,所以在此我把它定义仍是个未定论的问题。

真实答案:未知。

猜测答案:win10 特殊乱序情况下 dup ack 的不发送。

Wireshark TS | 传输文件慢问题_第13张图片

  1. TCP 超时重传

可能又会有同学注意到,为什么超时重传的 4 个数据包,No.116、No.118-No.120 会有 30ms 左右,也就是一个 RTT 的间隔。在这里有实际的答案,就是在 No.99 和 No.100 之间所丢包的 4 个 TCP 原始分段,并不是在同一个 RTT 内发送出来的。

No.116 这一个重传分段的原始分段,是跟随 No.99 之后,在上一个 RTT 内由 Server 一起发出;No.118-No.120 这三个重传分段的原始分段,是在 No.100 之前,跟 No.100 一起在这一个 RTT 内由 Server 一起发出。

因此产生了 No.116、No.118-No.120 4 个 TCP 超时重传分段的时间间隔。

真实答案:需 server 侧跟踪文件最终验证。

猜测答案:server TCP 分段的发送行为引起。

Wireshark TS | 传输文件慢问题_第14张图片

  1. TCP SACK

在之后的丢包现象中,也出现了一个奇怪的 SACK 现象。在 No.273 和 No.274 之间显示丢失 2 个 TCP 分段之后,client No.284 SACK 标明了 SLE=291732 SRE=305022,也就是说确认收到了 No.274 和 No.275,包括之后的 No.286 和 No.288 SACK 都再次表明收到了这两个分段。

但是在 server 进行超时重传丢失的 2 个分段 No.287 和 No.289 之后,同样重传了 No.290 和 No.291,而这两个分段的 Seq Num 分别对应的就是 No.274 和 No.275,在这里意味着 server 未到正常收到 sack,或者收到忽略了这些 sack。之后 server 以 No.292 回复了一个 DSACK,说明了 SLE=291732 SRE=294390 属于重复。

实际上从丢包来看,很难理解连续 3 个 sack 都丢失的情况,而且在此期间是有正常的数据包交互,因为未能有 server 的捕获,所以只能猜测是 server 未正常收到 sack。

真实答案:未知。

猜测答案:结合上面 1 的 MSS 变化,我觉得更有可能是在 server 侧或是中间存在某类设备(代理或是安全设备),双向修改了 MSS 为 1436,而实际上 server 的 mtu 实际为 1329,同时该设备在 NAT 转换的时候,可能修改了 Seq,但是未转换 TCP OPS 里的 SLE 和 SRE,造成了 server 忽略了 SACK 。

Wireshark TS | 传输文件慢问题_第15张图片

问题总结

综上所说,在缺少对全局环境了解以及 server 侧数据包跟踪文件的情况下,有些问题确实无法得出准确答案,但这并不妨碍我们对数据包文件的一系列分析,其中一些特殊现象展开研究下来,也会不断夯实 TCP 基础知识点。

你可能感兴趣的:(NetShark,wireshark,网络,tcp/ip,网络协议,tcpdump)