窗口探测判读
接收方通告零窗口之后就暂时无法接收数据，发送方为了知道对方何时腾出空间，会定期发出体积很小的探测报文，这就是窗口探测。抓包上表现为窗口为零期间，同一序列号处反复出现很小的包，探测间隔随退避逐渐拉长。它反映的是接收端应用没有及时把数据读走。
基本信息
| 适用平台 | TCP 协议行为，Wireshark 提供对应分析标记 |
|---|---|
| 过滤方式 | tcp.analysis.window_probe，或窗口为零期间的 tcp.len <= 1 包 |
| 探测间隔 | 随退避递增，与重传超时机制相关 |
| 对照概念 | 窗口填满（发送端视角）与零窗口（接收端通告） |
典型使用场景
- 定位接收端阻塞：持续探测说明接收应用一直没把数据取走
- 区分窗口与丢包：探测包很小且序列号不变，形态与丢包重传不同
- 关联应用状态：与接收端线程栈、垃圾回收日志对照
- 观察恢复过程：窗口恢复后探测立即返回非零窗口并恢复传输
- 长抓包审查：探测包体积小间隔大，容易被当作噪音忽略
观察与过滤
观察与过滤
tcp.analysis.window_probe # 窗口探测包
tcp.window_size == 0 # 接收窗口为零的包
tcp.len <= 1 && tcp.flags.ack == 1 # 体积极小的确认类探测
# 判读：探测间隔随退避递增；窗口恢复后传输立刻继续零窗口期间的现象
| 现象 | 说明 | 下一步 |
|---|---|---|
| 确认报文通告窗口为 0 | 接收方暂时无法接收 | 观察探测与恢复的时间点 |
| 探测间隔逐渐变长 | 按退避策略重试 | 判断是否已接近放弃 |
| 窗口恢复后立即发数据 | 接收端已腾出空间 | 回溯阻塞时长与原因 |
| 连接被重置 | 对端放弃或应用退出 | 结合两端日志确认 |
探测持续很久是接收端应用阻塞的强烈信号，例如线程池被打满、垃圾回收长时间停顿，或者下游依赖卡住。抓包只能给出「什么时候开始堵、堵了多久」，具体原因要到接收端本身去找。
只在单侧抓包时看不到接收端的缓冲区与线程状态，恢复时间只能从探测响应推断，结论要留有余地，必要时在接收端同时抓一份。
零窗口和窗口填满常常同时出现但含义不同：零窗口是接收方明确通告没有空间，窗口填满是发送方发现自己把对方窗口塞满了，后者通常更早出现。