窗口限制吞吐是什么
在高带宽时延积链路上，接收窗口不足会把吞吐直接压到“窗口大小 ÷ 往返时间”的水平。这类情况有个鲜明特征：几乎没有丢包与重传，报文持续发出但发送量受接收窗口更新节奏牵制，通告窗口长期贴在上限附近，Window Full 标记周期性出现。它容易被误判成链路质量问题，因为用户体感就是慢。确认手段是对比加大接收缓冲或窗口缩放设置前后的吞吐：如果吞吐随窗口一起提升，瓶颈就在窗口而不是链路。
基本信息
| 判据 | 无重传、窗口长期贴顶、RTT 稳定 |
|---|---|
| 高发场景 | 高带宽时延积链路、跨地域传输、长肥管道 |
| 相关字段 | tcp.window_size_value、tcp.analysis.window_full |
| 估算参照 | 带宽时延积等于带宽乘以往返时间 |
| 主要调整项 | 接收缓冲大小与窗口缩放选项 |
典型使用场景
- 跨地域传输慢：长肥管道上窗口成为吞吐的硬上限
- 与丢包型慢速区分：先看有没有重传，两类问题的处置完全不同
- 验证窗口缩放：确认握手阶段窗口缩放选项是否协商成功
- 分侧定位：判断限制来自发送侧拥塞窗口还是接收侧通告窗口
- 调优验证：调整缓冲后复测吞吐，确认提升幅度符合预期
核对与估算
核对与估算
tshark -r a.pcap -Y 'tcp.analysis.window_full' | head
# 估算需要的窗口下限
# 带宽 100Mbps 约 12.5MB/s，RTT 40ms
# 12.5MB/s × 0.04s = 500KB，窗口需不小于该值
sysctl net.ipv4.tcp_rmem net.core.wmem_max # 接收缓冲相关参数两类慢速对照
| 类型 | 重传情况 | 窗口表现 | 处置方向 |
|---|---|---|---|
| 丢包型 | 有重传与重复确认 | 不一定贴顶 | 查链路丢包与拥塞控制 |
| 窗口型 | 基本无重传 | 长期贴顶 | 调接收缓冲或确认应用读取速度 |
| 零窗型 | 可能有重传 | 窗口归零 | 优先解决接收侧应用阻塞 |
接收侧应用读取慢同样会让窗口贴顶，需要结合接收侧的内存、CPU 与线程指标才能区分是缓冲参数设置问题还是程序处理能力问题。
窗口缩放在握手阶段协商，协商失败时通告大窗口并不生效；调参之前先确认选项是否真的启用，否则调整会毫无效果。