在途字节与发送窗口
在途数据量指的是发送方已经发出但还没被确认的字节数，它不能超过拥塞窗口与接收窗口中的较小值。抓包时通过发送流与确认流的推进差，可以近似观察在途量与「发不动」的时刻，也就是发送方被窗口或拥塞控制卡住的瞬间。
基本信息
| 适用平台 | TCP 协议行为，配合 Linux 的 ss 查看内核数值 |
|---|---|
| 约束关系 | 在途数据量不超过拥塞窗口与接收窗口的较小者 |
| 抓包观察 | 时序图上两条线的间距即近似在途数据量 |
| 内核查看 | ss -ti 直接给出拥塞窗口与接收窗口 |
典型使用场景
- 理解发送受限来源：区分拥塞窗口限制与接收窗口限制
- 判断是否发满：间距达到上限后发送暂停，说明受限
- 排查吞吐不足：间距小且抖动，多与丢包或拥塞控制相关
- 与内核指标印证：用实时数值校验抓包推断
- 评估窗口调优效果：调整前后对比在途量曲线
观察方式
观察方式
# 时序图判读
# 两条线之间的间距约等于在途数据量
# 间距达到上限后发送暂停，说明受到限制
ss -ti | grep -E 'cwnd|rwnd' # 直接读取内核侧的窗口数值受限来源判读
| 现象 | 受限来源 | 处理方向 |
|---|---|---|
| 间距到上限后停顿 | 拥塞窗口或接收窗口 | 对照内核数值确认是哪一种 |
| 间距小且抖动明显 | 丢包与拥塞控制 | 看重传标记与丢包率 |
| 间距始终很小 | 请求响应模型本身很小 | 属于正常，不是故障 |
| 接收窗口长期偏小 | 接收端缓冲配置 | 评估是否加大缓冲 |
抓包只能间接估算在途量，精确数值要从内核工具取。把抓包推断与内核的实时数值放在一起看，结论才站得住。
在途量小不一定有问题。小请求响应模型下本来就发不满窗口，此时的在途量由业务形态决定，不是链路能力不足。
拥塞窗口与接收窗口谁更小，决定了当前瓶颈在哪一侧。看到发送停顿之后，先判断属于哪一种限制，再决定查网络还是查接收端。