TCP 窗口缩放和吞吐量 PCAP 分析:接收窗口、零窗口、窗口满和慢速传输调试
如何分析 TCP 窗口缩放、接收窗口限制、零窗口、窗口满事件、缓慢吞吐量、带宽延迟乘积和数据包捕获证据。
TCP 吞吐量慢并不总是丢包。它可能是接收窗口压力、缺少窗口缩放、套接字缓冲区小、应用程序读取延迟、代理缓冲、VPN 限制或带宽延迟产品不匹配。当速度测试不好但重传不能解释速度下降时，用户搜索“TCP 窗口缩放 pcap”、“TCP 零窗口”、“TCP 窗口已满”、“缓慢下载数据包捕获”、“接收窗口限制吞吐量”和“带宽延迟积 TCP 分析”。
PCAP 手术非常有用，因为吞吐量问题需要保留精确的握手选项、通告的窗口、ACK 时序、有效负载突发、暂停和窗口更新。
TCP 窗口缩放的作用是什么
TCP 窗口字段的大小是有限的。窗口缩放通过在 SYN 交换期间协商缩放因子来允许更大的接收窗口。如果窗口缩放丢失、被禁用、被设备剥离或被误解，则高延迟链路上的吞吐量可能会受到限制。
当延迟很严重时，这一点最为重要：
- 广域网传输。
- VPN 链接。
- 卫星或蜂窝网络。
- 跨区域云流量。
- 远程备份复制。
- 远程文件复制。
- 大量 HTTP 下载。
在本地 LAN 上，较小的接收窗口可能看起来仍然很快。在高延迟路径上，它可能成为瓶颈。
带宽延迟积
带宽延迟乘积描述了必须传输多少数据才能填满路径。高带宽和高往返时间的连接需要更大的窗口。
如果接收窗口太小，发送方必须停止并等待 ACK，而不是保持管道满。
抓包证据：
- 发送方传输直至公布的窗口限制。
- 接收方 ACK 缓慢或通告小窗口。
- 吞吐量形成突发和暂停。
- 重传率很低，但速度仍然很差。
- 应用程序读取数据后会出现窗口更新数据包。
这是接收端或流量控制瓶颈，而不是经典损失。
零窗口
TCP 零窗口意味着接收方通告没有可用的接收缓冲区。在窗口更新到达之前，发送方无法继续发送应用程序数据。
常见原因：
- 接收应用程序的读取速度不够快。
- 服务器超载。
- 客户端在磁盘上已暂停或被阻止。
- 代理缓冲区已满。
- TLS 堆栈受到反压。
- 数据库客户端或文件接收器速度缓慢。
- 数据包捕获在接收器附近进行并显示本地压力。
零窗口不会自动成为网络故障。它通常表明应用程序或主机资源压力。
窗口满
“窗口已满”通常意味着发送方已填满接收方通告的窗口。它可能发生在零窗口之前。发送方已准备好发送更多内容，但流量控制阻止了它。
寻找：
- 长时间运行数据直至窗口边缘。
- 摊位周围没有丢包。
- ACK 没有提前足够的窗口。
- 发送者在等待时暂停。
- 窗口更新之后又是一次爆发。
此模式对于“缓慢上传”和“缓慢下载”支持案例尤其重要。
缺少比例选项
必须在握手期间协商窗口缩放。如果一侧在 SYN 或 SYN-ACK 中不包含窗口缩放选项，则连接稍后无法使用缩放。
证据：
- 同步选项。
- SYN-ACK 选项。
- 窗口比例值。
- 初始接收窗口。
- 有效缩放窗口。
- 剥离选项的中间框行为。
如果在握手之后开始捕获，则比例因子可能未知。这就是为什么支持跟踪应包括完整的 TCP 握手。
捕捉位置很重要
窗口分析取决于捕获的位置。发送方附近的捕获可能会显示与接收方附近的捕获不同的时序。 NAT、VPN、代理和负载均衡器也可以拆分连接。
问题：
- pcap 是在客户端、服务器、防火墙或代理上捕获的吗？
- 这是一个端到端 TCP 连接还是两个代理端连接？
- 序列号是否已翻译？
- ACK 是由接收方还是网络延迟的？
- 代理通告的窗口是否与最终端点不同？
PCAP 手术有助于修剪和比较对话，而不会丢失握手选项。
避免错误的丢包结论
吞吐量仪表板通常归咎于数据包丢失。但如果重传很少，并且发送方在接收窗口反复暂停，那么真正的瓶颈是流量控制。
有迹象表明损失不是主要原因：
- 很少有重传。
- 没有重复的 ACK 风暴。
- 定期窗口更新周期。
- 发件人恰好在广告窗口处暂停。
- 应用层响应缓慢，消耗数据。
本文应针对诸如“慢速 TCP 无数据包丢失”之类的搜索，因为这些用户需要不同的诊断路径。
调试清单
使用此工作流程：
- 保留 SYN 和 SYN-ACK 数据包。
- 记录窗口比例选项。
- 计算有效接收窗口。
- 识别零窗口和窗口更新数据包。
- 确定窗口满期。
- 测量 RTT。
- 将传输中的字节与带宽延迟乘积进行比较。
- 单独检查重传率。
- 注意捕获位置。
- 保持缓慢的间隔和握手。
最终诊断
TCP 窗口缩放和接收窗口问题会导致传输缓慢，但没有明显的数据包丢失。证据在于握手选项、通告的接收窗口、零窗口事件、窗口更新、RTT 和发送方暂停行为。
PCAP 手术有助于保留证明瓶颈是否是网络丢失、接收缓冲区压力、缺少窗口缩放、代理行为或读取速度不够快的应用程序的数据包。