前言
观察是知识的重要来源,网络数据包分析就比较强调注意力,要用心去看,很多时候也能因此学到更多的知识点。
还是之前提到的关于数据包跟踪文件的整理问题,这次又发掘出一个关于缓慢的 Web 服务器的案例。
问题信息
数据包跟踪文件基本信息如下:
$ capinfos SlowWeb.pcapng
File name: SlowWeb.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Number of packets: 26
File size: 9220 bytes
Data size: 7795 bytes
Capture duration: 3.258294 seconds
First packet time: 2018-03-10 05:45:17.155473
Last packet time: 2018-03-10 05:45:20.413767
Data byte rate: 2392 bytes/s
Data bit rate: 19 kbps
Average packet size: 299.81 bytes
Average packet rate: 7 packets/s
Strict time order: True
Capture application: Sanitized by TraceWrangler v0.6.8 build 949
Capture comment: Sanitized by TraceWrangler v0.6.8 build 949
Number of interfaces in file: 1
Interface #0 info: ...
$
跟踪文件通过匿名化工具处理,并删除了部分信息。
数据包跟踪文件应该为 Wireshark 所直接捕获,数据包数量 26 个,平均速率 19 kbps,专家信息所显示的一些问题包括疑似重传和 TCP 会话使用相同端口等。
问题分析
实际数据包完整信息如下:
SYN 重传
首先可以看到的就是客户端 SYN
不断的重传现象,以源端口 54130、54131 和 54132 不断尝试发起到 Web 服务器 HTTP 80 的请求,但是此时 Web 服务器并无任何响应,这样的情况有可能是无路由到服务器、防火墙过滤了或者服务器过载无响应等等。也由于 TCP SYN 的重传,使用的是同一个 TCP 源端口,所以在 Wireshark 会提示 TCP Port numbers reused
。
此处 TCP SYN 重传的规律如下,重传时间间隔为 1s,TCP Stream 0、1、2 均保持一致,这里说明了什么? 可以推断出捕获数据包的系统为 macOS
。
一般来说,不同版本的操作系统 SYN 超时重传时间和重传次数会有所不同,简要如下:
- Linux
超时重传时间有 1 秒和 3 秒,目前主流为 1 秒,重传次数一般为 5 次或 6 次,而每次超时等待的时间是上一次的 2 倍,规律为第一次超时重传是在 1 秒后,第二次超时重传是在 2 秒后,第三次超时重传是在 4 秒后,第四次超时重传是在 8 秒后,第五次是在超时重传 16 秒后,第六次是在超时重传 32 秒后。
- Windows
超时重传时间一般为 3 秒,重传次数 2 次 ,同样超时等待的时间是上一次的 2 倍。
- macOS
macOS 很少关注,偶尔测试了如下现象。超时重传时间应该为 1 秒,重传次数 10 次 ,前 5 次每次间隔 1 秒,后 5 次每次超时等待的时间是上一次的 2 倍,2 4 8 16 32 秒。
SlowWeb
但是实际上从 No.10 开始,发现 Web 服务器开始回应 SYN/ACK 了,以下仍以 TCP Stream 0 为例说明
客户端 SYN 以 1s 间隔连续重传了 2 次,在 No.8 SYN 到达 Web 服务器后,服务器响应了 No.10 SYN/ACK ,客户端继而回应 ACK,至此完成 TCP 三次握手。但实际上以客户端和 Web 服务器 IP 来看,是属于同一个 VLAN 内,两者之间的 IRTT 却高达 281ms ,结合之前的 SYN 不断重传现象,基本可判断为 Web 服务器性能问题,过载造成响应缓慢。
之后的 HTTP 交互过程中 Web 服务器依然处理缓慢,客户端 No.12 GET 请求,经过 478ms 之后才收到服务器的 HTTP 响应 200 OK(此处连 TCP 协议层面的 Delayed ACK 都未曾发出,也就是理论上的 40ms 或 200ms 间隔时间);客户端 No.19 GET 请求 png 图片, 同样经过 437ms 之后才收到服务器的 HTTP 响应 200 OK(PNG) 。
No.20 所提示的 [BoundErrorUnreassembled Packet],原因是 HTTP 分析时关闭了 TCP 协议的 Allow subdissector to reassemble TCP streams 选项,使得未能正常重组 TCP 分段。
问题总结
此案例虽然简单,但分析下来仍然有些知识点在内,像是 SYN 重传间隔时间和次数(判断不同操作系统以及 RFC 实现)、专家提示(TCP Port numbers reused 和 BoundErrorUnreassembled Packet 的含义)和 Delayed ACK 等等。
感谢阅读,更多技术文章可关注个人公众号:Echo Reply ,谢谢。