前言
来自朋友分享的一个案例，也在 Wireshark 交流群里和群友做了些简单的讨论，由于对直播架构、直播工作原理以及应用软件等实在是不熟悉，所以并没有得到一些稍微深入点的答案。而我也表达了一些简单的想法，譬如说从数据包分析的层面去尝试解析类似问题，实际上是不合适的，一方面专业技术和原理不懂，没法深入，光靠猜是找不到根因的，另一方面应用协议千千万，做不到所有都懂，数据包分析在这些场景下一般只能看到现象，更多就是猜测的答案。
从解决问题来看，我建议还是从相关专业性下手，了解下原理，琢磨下应用软件的设置，进行各类调试优化，我觉得比分析茫茫多看不太懂的数据包有用多了，就像我自己是网络专业，拿动态路由协议 OSPF 建立不了邻居的故障来说，我第一时间肯定从 OSPF 建立邻居的必要性条件下手，琢磨配置上的问题，我肯定不会考虑还要上手抓个 OSPF 协议包，研究协议交互哪出问题，这样就本末倒置了。
所以本篇文章只是从一个数据包分析的爱好者角度，浅谈些数据包上的现象和些许问题，没有直播卡顿、直播慢、直播丢帧的根因，更没有这些问题的解决方法，不感兴趣的就不用往下看了。
数据包信息
数据包跟踪文件基本信息如下：
λ capinfos 直播丢帧_anon.pcapng
File name: 直播丢帧_anon.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Number of packets: 50 k
File size: 50 MB
Data size: 49 MB
Capture duration: 57.695636 seconds
First packet time: 2024-08-19 22:16:13.824266
Last packet time: 2024-08-19 22:17:11.519902
Data byte rate: 849 kBps
Data bit rate: 6794 kbps
Average packet size: 980.05 bytes
Average packet rate: 866 packets/s
SHA256: c27a2d853d073e2523de3b2a80b0305935ac703b87c7c0bd52046c0d7aad00e2
SHA1: 9be5fae84de4152c4a433185596e5ea4eb4851d6
Strict time order: True
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 = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Number of stat entries = 0
Number of packets = 50000
数据包通过 Wireshark 所捕获，原始数据包跟踪文件较大，根据 IP 通讯对做了一定过滤，同时大致浏览了数据包现象，仅截取了部分数据包，这样在 Wireshark 使用分析上会更加快捷。数据包数量 50K 个，文件大小 50MB ，捕获时长约 57.7 秒，平均速率 6794 kbps，并经过 TraceWrangler 匿名化软件所处理。
专家信息如下，有 Malformed Packet、DSACK、DUP ACK、疑似虚假重传、快速重传、重传等等问题。其中重传、 DUP ACK、DSACK 和 Window update 相关数据包数量较多，这需要进一步分析。
问题分析
首先说直播问题，反馈直播卡顿，直播应用软件显示如下，丢帧（丢弃的帧）很多，显示的通讯信号强度一格很差。也是之前提到的，对于直播原理、应用软件的不熟悉，像是码率 11Mb/s 具体是什么速率，丢帧的判断是基于什么等等，都是不清楚的，只能再从数据包方面做进一步分析。
数据包跟踪文件展开详细信息如下，起始一般可以重点关注的就是 TCP 三次握手信息，像是 IRTT、MSS、TS 时间戳、WS 等等，很多信息都可以在这三个数据包中得到。像本次案例的 IRTT 72ms、传输 MSS 1412、支持 WS、SACK 等。
至于应用协议 RTMP，没有太多了解，但既然是 TCP 传输，可以简单从 TCP 层面分析一波，首先关注其中 DUP ACK、DSACK、重传等问题。
可以看到对于客户端所发送的数据，服务器响应了 Dup ACK，DUP ACK 产生的原因可能是乱序或者丢包，而这里是一个乱序情况，为什么这样说？可以结合 No.361 ACK Num 以及 SACK 信息判断，ACK Num 217901 说明收到了 217901 之前所有的数据段，SLE 219805 SRE 219813 说明收到了 219805-219813 的数据段，但是 217901-219805 的数据段没收到，而 No.362 紧接着的 ACK Num 即为 219813，说明收到了 219813 之前的所有的数据段，立马补齐了。
这说明数据段在传输过程中发生了乱序，后一个数据段先到让服务器响应了 Dup ACK，前一个数据段后到让服务器响应 ACK 确认收全数据，而不是丢包的情况继续产生 Dup ACK。
而之后所有单独的 Dup ACK 都是类似的现象，说明乱序仅发生在两个数据段之间，小问题，没什么影响。
那么继续往下看出现两个 Dup ACK 的地方，会有什么不同的现象。
可以看到对于客户端所发送的数据，服务器接连产生了四个 SACK No.1464-1467，表明可能丢包或者乱序，也和之前一样的是 No.1468 ACK 确认了 1099839 之前所有的数据分段，说明是发生了乱序而不是丢包，只不过乱序的数据段比较多，也在其中触发出了 No.1465-1466 两个 Dup ACK。
继续看 No.1470-1472 三个重传数据包，这个实际上是由于客户端收到 SACK 后所触发出来的快速重传，而这些数据包在之前已经出现过，所以 Wireshark 标记成 [TCP Spurious Retransmission] 疑似重传。
而这样类似的现象在之后会出现很多，本质原因就是乱序的数据段多了，就会触发出 SACK，紧接着客户端就会触发产生重传数据，是为避免可能的丢包所产生的重传，但是实际上又不是丢包情况，久而久之客户端的传输效率就降低了，进而在应用上显示出来就是传输速率变慢。
另一方面根据用户反馈，网络上传带宽可达到 80Mbps（非实际真实端到端通道传输能力），再加上数据包所抓的 IRTT 72ms，那么理论上的估算 BDP 在 720KB，而数据包文件中的 BIF 最大不到 72K，同时接收窗口上限也远未达到，所以综合判断下来，速率上不去，更多是在发送端上的问题，要么受限于不断的重传影响（实际上又是对端接收数据段乱序影响），要么发送端应用限制，譬如码流大小设置，当然由于不懂直播，错了当我没说。🤣
问题总结
限于知识面，确实只能浅谈下数据包现象，实际上反映在直播应用上，是否一定能对应问题现象，还需要进一步的测试，但像是应用上反馈的丢帧，从数据包上来说，实际上是乱序（此处较真）~
