前言
来自朋友分享的一个跟踪文件，在此之前这么多的网络数据包分析中还没有碰到这样的案例，个人感觉很特殊，因此记录分享下。
说到看过很多数据包，想起同事的一句玩笑话：天天看你在看数据包，女人喜欢包，你也喜欢包~
🤣 凌乱，无力反驳。
问题分析
跟踪文件的信息比较简单，来自于家庭用户，反馈说是夸克浏览器看视频慢，在现场技术人员的支持下，也抓取了问题发生时的数据包。
快速浏览跟踪文件
一般跟踪文件中的数据包可多可少，少至一个，多至百万。。如果有如此多的数据包，都不说 Wireshark 是否能流畅加载运行，加载起来后如何进行显示过滤以及如何定位分析得到自己想要的信息，确实是一个技术活。
Wireshark 在故障分析方面给了些很好的信息展示，如下会在分组列表视图最右处，基于着色规则显示标记有不同颜色的数据包，像是默认的黑底+红字，就是描述带有 tcp.analysis.flags的 Bad TCP 数据包，像是常见的乱序、重传之类。
上图整个跟踪文件从着色规则上可以看出有很多的问题。也可以在 Wireshark 状态栏的左下角，会有 红色 图标显示，此处代表的就是 专家信息 的汇总信息，也可从 分析 -> 专家信息 处进入。
点击红色图标查看专家信息，如下
跟踪文件接口信息
$ capinfos -I 夸克看视频网速慢.pcapng
File name: 夸克看视频网速慢.pcapng
Packet size limit: inferred: 54 bytes - 1354 bytes (range)
Number of interfaces in file: 1
Interface #0 info:
Name = \Device\NPF_{F60B5ED9-A99A-4C66-9F97-533629F6E07E}
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 7 Service Pack 1, build 7601
Number of stat entries = 1
Number of packets = 4940
定位分析
通过提供的视频服务器 IP，经过显示过滤后的数据包如下
确实在 Client 与 PPS Server 的交互中，存在着大量乱序、（疑似）重传、分段未捕获的信息。而通过观察 Identification（ip.id）字段，首先就可以发现 PPS Server -> Client 方向，存在着大量乱序，以及可能的丢包造成的重传情况。
因为跟踪文件的捕获点是在 Client 处，一般至此的分析可能就会认为是服务器在传输路径中出现了丢包或是严重乱序，而造成的一些重传或者快速重传问题，造成浏览视频时出现慢及卡段现象。
但是如本文的开头所说，这是一个很特殊的案例，真实情况是这样的嘛？
深入分析
进一步细看跟踪文件，在 Client -> PPS Server 方向，也就是本地发送方向，也存在着大量乱序。
这是一个很奇怪的现象，因为跟踪文件的捕获点是在 Client 处，意味着本地即乱序？？？考虑到 Wireshark 的工作原理，在进网卡前捕获数据包，说明客户端系统内核协议栈或者是 winpcap/npcap 可能存在问题。另一个很奇怪的现象是，数据帧的长度。
同样是 Client 的问题，数据帧长度与捕获长度不一致。ACK 正常的数据帧长度也应该为 54 字节，但是会显示为 94 字节，也不仅仅是 ACK，其他带有数据载荷的数据包，数据帧长度应该为 529 字节的，会显示为 1044 字节。
此处的数据帧长度与捕获长度不一致，并不是 snaplen 捕获设置的问题，因为不同的数据包捕获长度不一样。
但是在 PPS Server 所发送的数据包，则一切正常，数据帧长度与捕获长度保持一致，1354 或 1237 字节。
问题总结
综合考虑在 Client 上的异常现象以及两端数据包的对比，本地乱序和数据帧长度的异常，很大可能是客户端系统内核协议栈问题所导致，真是难得一见的案例。
非故障的直接处理方，一两天之后的反馈说是问题已消失，或许是用户重启了电脑恢复了。
