零窗口事件的标注
Wireshark 的分析引擎把接收侧背压拆成几个可过滤的事件：tcp.analysis.zero_window 表示接收端通告窗口为 0，tcp.analysis.window_full 表示发送方已用满对端允许的窗口，tcp.analysis.window_probe 则是发送端在零窗口期间发出的探测。吞吐曲线上出现明显掉坑时，先按这几个字段确认是不是接收侧缓冲打满。
基本信息
| 适用工具 | Wireshark 3.x / 4.x |
|---|---|
| 核心字段 | tcp.analysis.zero_window / window_full / window_probe |
| 辅助字段 | tcp.window_size 查看窗口字段原值 |
| 取数前提 | 报文需覆盖事件前后，中途开始的抓包难以还原因果 |
| 配套图表 | TCP Stream Graphs 的 Throughput 图 |
典型使用场景
- 吞吐骤降时确认是否为接收端缓冲被打满
- 长连接周期性卡顿，统计零窗口出现的时刻与持续时长
- 区分「接收端读得慢」与「网络丢包」这两类吞吐问题
- 评估接收缓冲或应用并发是否需要调整
- 验证调优后零窗口事件是否减少
常用示例
常用示例
tcp.analysis.zero_window # 接收端通告零窗口
tcp.analysis.window_full # 发送方已用满对端窗口
tcp.analysis.window_probe # 发送端的窗口探测
tcp.window_size == 0 && tcp.flags.ack == 1
ip.dst == 10.0.0.9 && tcp.analysis.zero_window # 限定接收端事件含义对照
| 事件字段 | 含义 | 后续动作 |
|---|---|---|
| zero_window | 接收端通告窗口为 0 | 检查接收应用读取是否阻塞 |
| window_full | 发送方已占满对端窗口 | 确认接收端窗口是否长期偏小 |
| window_probe | 发送方主动探测 | 观察探测间隔与恢复耗时 |
| window_update | 窗口恢复为正值 | 记录从归零到恢复的时长 |
零窗口是接收端应用慢的直接证据，把结论归到网络侧通常方向就错了。
长时间零窗口可能触发中间设备拆链，长连接业务排查时要同时核对设备侧会话老化参数。
补充要点
- 先确定零窗口是哪一端通告的，再决定去看哪一侧的应用日志
- 窗口反复归零又恢复，说明应用读取呈间歇性阻塞
- 窗口长期偏小但从未归零属于缓冲配置问题，与零窗口是两类情况
- 同一会话两个方向分别统计，避免把一侧的问题算到另一侧
把零窗口事件的时刻导出后与应用日志时间戳对齐，是定位到具体处理阶段的常用做法。