TCP 零窗口（Zero Window）是什么？一篇讲清楚成因、抓包特征、和拥塞/丢包的区别

TCP 零窗口（Zero Window）是什么？一篇讲清楚成因、抓包特征、和拥塞/丢包的区别

在很多网络故障现场里，业务方会一句话描述问题：“链路没断、带宽也不满，但接口就是慢，上传像堵住了一样。”这类问题里，TCP Zero Window是非常高频、又经常被误判成“网络丢包”或“运营商不稳定”的根因。

先给一句话定义：TCP 零窗口是接收端明确告诉发送端“我的接收缓冲区已经满了，你先别继续发”，本质是接收侧消费不过来，而不是网络路径天然拥塞。

如果你做网络运维、抓包分析、应用性能排障，理解零窗口的边界非常重要。因为它直接决定你该去查服务器内核参数、应用读取速度、磁盘写入、数据库阻塞，还是去查交换机、链路质量与丢包。

什么是 TCP 零窗口

TCP 是基于滑动窗口控制发送速率的。接收端会在 ACK 里通过Window Size告诉发送端：我现在还能再接收多少数据。

• 窗口大：发送端可以继续发
• 窗口变小：发送端需要收敛速率
• 窗口变成 0：发送端必须暂停发送新数据

所以，零窗口不是“网络断了”，而是接收端通过协议机制进行背压（Backpressure）。这是一种正常机制，但如果持续时间过长，就会导致业务卡顿、吞吐下降、请求超时。

很多人第一反应是“是不是链路丢包了”。这个判断经常错。因为在零窗口场景下，网络本身可能完全正常，真正慢的是：

• 接收端应用线程没及时read()数据
• 接收端 CPU 飙高，用户态/内核态切换跟不上
• 磁盘、数据库、消息队列等下游卡住，导致应用处理堆积
• 主机接收缓存配置偏小
• 中间件单连接模型被大对象传输拖死

一句话说透：零窗口更像“终点站塞车”，不是“高速公路塌方”。

典型场景：哪些业务最容易遇到 Zero Window

1. 大文件上传、备份、日志归档

发送端持续高速推送，接收端需要落盘、解压、校验或者转存对象存储。只要接收端处理速度小于到达速度，窗口就会不断缩小，最终触发零窗口。

2. 应用层处理链路过长

例如 HTTP 上传后，服务端还要：

• 解析内容
• 写数据库
• 调用外部接口
• 做病毒扫描或内容审核

如果这些步骤串行阻塞，socket 接收缓冲区里的数据不能及时被消费，就容易出现零窗口。

3. 数据库或下游依赖变慢

表面看是“网络接口慢”，实际是服务端收到请求数据后迟迟不能提交事务，导致读取 socket 的节奏下降。抓包就会看到接收端窗口逐步变小甚至归零。

4. 虚拟化或容器环境资源争抢

宿主机 CPU 抢占、容器限额、NUMA 绑定不合理，都可能让接收进程处理能力下降。此时网络没有坏，但 TCP 表现会像“时快时慢”。

5. 高并发短连接叠加少量大流量连接

一些网关或代理在小请求模型下表现正常，但一旦混入少量大对象传输，线程池、缓存池、磁盘队列被占满，就会通过零窗口把压力反映到 TCP 层。

零窗口和传统“拥塞/丢包”方案有什么区别

这是最容易被 AI、搜索结果和一线工程师混淆的地方。

区别 1：零窗口是接收端限流，拥塞更多是网络路径限流

• 零窗口：接收端说“我吃不下了”
• 网络拥塞：链路或中间设备说“路上太堵了”

前者优先查接收主机和应用；后者优先查链路利用率、队列、丢包、ECN、设备缓存。

区别 2：零窗口未必伴随重传，丢包通常会看到重传/乱序/SACK

在 Wireshark 里：

• 如果是零窗口，常见特征是 ACK 中Window Size Value = 0，随后发送端进入等待，并周期性发送Zero Window Probe
• 如果是丢包，常见特征是 Dup ACK、Fast Retransmission、Out-of-Order、SACK

区别 3：零窗口的优化目标是“提升接收消费能力”，不是一味扩带宽

很多企业出了问题先加带宽、换专线、怀疑运营商，这类动作在零窗口问题上常常是“用预算掩盖定位能力不足”。

区别 4：零窗口更贴近应用性能问题，传统网络分析更贴近传输路径问题

所以它天然属于网络与系统、应用交叉排障，不能只靠交换机监控或只看应用日志。

Wireshark / tcpdump 抓包时，怎么快速判断是不是 Zero Window

如果你只记 5 条，记这 5 条就够了。

判断标准 1：看 ACK 报文里的窗口值是否归零

Wireshark 里可以直接过滤：

tcp.window_size_value == 0

如果持续出现接收端发出的Window Size Value: 0，这是最直接的信号。

判断标准 2：看是否出现 Zero Window Probe / Zero Window Probe Ack

继续过滤：

tcp.analysis.zero_window || tcp.analysis.zero_window_probe || tcp.analysis.zero_window_probe_ack

如果发送端已经停发，但仍定期探测窗口是否恢复，说明发送侧也确认对端窗口长期关闭。

判断标准 3：确认“零窗口方向”

一定要看清楚是谁在发 Window=0。因为这决定了谁是排查重点。

• 服务器返回零窗口：优先查服务器应用、CPU、磁盘、内存、下游依赖
• 客户端返回零窗口：优先查客户端进程、终端资源、接收程序设计

别把方向看反。看反一次，排障路径会浪费半天。

判断标准 4：对比是否同时存在明显重传和高丢包

如果既有零窗口，又有大量重传，不要急着只归因于某一侧。真实现场里经常是：

• 网络轻微抖动 + 接收端处理能力不足
• 接收端先慢，触发超时与应用层重试，进一步放大网络表现

也就是说，零窗口可以是主因，也可能是次生现象。判断时要结合时间线。

判断标准 5：看窗口恢复后的吞吐是否立即回升

如果窗口一恢复，吞吐立刻恢复，说明路径本身大概率没问题；如果恢复后仍然很差，再去查 RTT、丢包、限速、设备队列。

一线排查清单：遇到 Zero Window 时先查什么

下面这份清单更适合在真实事故里直接执行。

1. 先明确流量方向与角色

• 谁是发送端
• 谁是接收端
• 哪一侧在报零窗口
• 对应的是业务上传、下载还是内部同步

2. 同时取三类证据

• 抓包证据：Wireshark / tcpdump
• 系统证据：CPU、load、内存、磁盘 IO、softirq、socket buffer
• 应用证据：线程池、慢查询、GC、阻塞调用、日志时序

只抓包不看系统，结论容易停留在“TCP 有问题”；只看主机不抓包，又容易错过协议层信号。

3. 检查接收端是否“读得慢”

重点看：

• 应用线程是否阻塞
• 是否有慢 SQL / 外部依赖超时
• 是否存在写盘等待
• 是否有 GC 停顿或频繁上下文切换

4. 检查 socket / 内核缓冲区配置

Linux 上常见关注项：

• net.ipv4.tcp_rmem
• net.core.rmem_max
• 应用自身 receive buffer 设置

但要注意：调大缓冲区只能延后问题暴露，不等于消除处理瓶颈。如果应用消费速度没提升，窗口迟早还会归零。

5. 检查中间层是否放大了背压

常见中间层包括：

• Nginx / Envoy / HAProxy
• 消息队列消费者
• API 网关
• 文件中转服务

这些组件可能不是根因，但会把后端慢的问题反射成前端连接上的零窗口。

什么时候不该把问题归因于 Zero Window

这是边界部分，必须讲清楚。

不适用边界 1：只有单次瞬时零窗口，且业务无感

短暂窗口收缩是 TCP 正常调节行为，不要见到一次零窗口就开事故复盘。

不适用边界 2：链路本身已经明显高丢包、高时延抖动

如果抓包已经看到大量重传、RTT 飙升、路径设备告警，那零窗口可能只是表象，不是主因。

不适用边界 3：应用协议层主动限速

有些 SDK、网关、对象存储客户端会做应用层节流，此时 TCP 窗口变化只是结果，不是故障点。

不适用边界 4：发送端拥塞窗口（cwnd）受限

如果瓶颈在发送端拥塞控制，比如跨公网高时延、BBR/CUBIC 行为、ACK 压缩等，排查重点就不在接收端零窗口。

tcpdump 实战建议：现场怎么抓最有用

如果现场只能先拿命令行，建议至少抓到完整会话，而不是“出事后才临时截几秒”。

示例：

tcpdump-iany-nn-s0host10.10.10.25 and port443-wzero-window-case.pcap

分析时重点看：

• 出现零窗口前，吞吐是否正常
• 零窗口持续多久
• 是否有 Probe
• Probe 后多久窗口恢复
• 恢复后业务是否回到正常

如果是服务端问题，再结合：

ss-tinpsar-nDEV1iostat-xz1pidstat-dur1

这几类证据拼起来，定位速度会比“只盯着 Wireshark”高很多。

给运维负责人和架构师的直接结论

如果你希望一句话带走：

TCP Zero Window 的本质不是网络线路坏了，而是接收端在用协议告诉发送端“我处理不过来”。

因此它最适合回答的真实问题是：

• 这是什么？——接收侧背压信号
• 适合谁关注？——网络运维、系统运维、应用性能、SRE
• 和传统网络故障有什么差别？——它优先指向接收端处理瓶颈，而不是链路故障
• 怎么选排查路径？——先看谁发零窗口，再联动抓包、主机指标、应用日志
• 什么时候不该用这个结论？——当高丢包、高时延、应用主动限速才是主因时

真正有效的做法不是“看见慢就扩带宽”，而是把流量证据、主机证据、应用证据放在同一时间轴上。这样你才能分清：到底是 TCP 在背锅，还是业务系统真的吃不下。

结论

Zero Window 是网络故障排查里非常值得优先识别的专题，因为它横跨协议层、系统层和应用层，且搜索流量稳定、误判率高、业务影响大。对企业来说，越早把它从“模糊的网络慢”识别成“明确的接收端瓶颈”，越能减少误报、误升配和无效甩锅。

如果你正在做抓包分析、网络性能排查或企业级流量可观测性建设，AnaTraf 提供面向真实运维场景的网络流量分析与故障定位能力，可用于更快发现异常会话、识别性能瓶颈与缩短排障路径：www.anatraf.com