7ACE

看图猜故障系列，来自于技术群讨论的又一个问题，数据包如下图，No.4900 原始数据包，No.4901 间隔208ms第一次重传，No.4903 间隔208ms第二次重传。

来自于技术群讨论的一个问题，原话如下： 「讨论个问题，我们都知道tcp的超时重传机制。在超时重传过程中，如第9次重传间隔要等待52s。问题：在52s间隔还没有到，此时上层应用主动放弃了。。。

前言 继续上篇关于《接收数据超出接收窗口》的文章，之前描述的是一个接收窗口满的特殊案例，现象是接收端在接收窗口为 0 的情况下，依然正常接收了数据，最后也说明了是快速路径处理的原因。

前言 之前写了一篇关于《发送数据超出接收窗口》的文章，描述的是测试中无意发现的一个接收窗口满的特殊案例，表面现象是服务器端无视对端接收窗口的限制，发出了超出接收窗口的数据，当然最后还是找到了原因。

前言 来自于测试中无意发现到的一个接收窗口满的案例，特殊，或者可以说我以前都没在实际场景中见过。一开始都没整太明白，花了些精力才算是弄清楚了些，记录分享下。

前言 来自于朋友分享的一个案例，最后定位的原因是光猫问题，而类似这类的设备所产生的网络问题，也曾碰到过两三次，但这一次的数据包现象挺特别，分析思路和过程也有所不同，故记录分享一下。

来自朋友分享的一个案例，也在 Wireshark 交流群里和群友做了些简单的讨论，由于对直播架构、直播工作原理以及应用软件等实在是不熟悉，所以并没有得到一些稍微深入点的答案。

问题背景 来自于学习群里群友讨论的一个数据包跟踪文件，在其中涉及到两处数据包异常现象，而产生这些现象的实际原因是数据包乱序。由于这两处数据包异常，都有点特别，本篇也就其中一个异常现象单独展开说明。

在之前的《虚假的 TCP Spurious Retransmission》文章中曾提到一个错误判断为 TCP Spurious Retransmission，实际为 TCP Out-Of-Order。