TCP 零窗口：连接还活着，数据为什么停了

一边是连接状态显示一切正常，一边是数据迟迟没有动静。同一个请求，直连时几秒就能完成，换成代理链路后却卡在半路。不少人在这类问题里翻来覆去排查，最后都会碰到同一个概念：零窗口。

零窗口是 TCP 的暂停键

先说接收窗口是什么。TCP 的每个方向都有一块接收缓冲区，缓冲区还剩多少空间，就是接收窗口的数值。发送方能发多少数据，取决于窗口还剩多少，而不是想发多少就发多少——这是 TCP 流量控制的起点，也是它保护慢速接收方的方式。

当接收方处理不过来，缓冲区被占满，接收窗口就变成了零。这时发送方会停下来，不再发出新的数据。连接本身并没有断开，只是进入了一个”等待对方腾地方”的状态。此刻从外部看，连接在线、状态正常，可数据就是不动。

等接收方处理完一部分数据、腾出空间，会主动发一个窗口更新通知；发送方收到后恢复发送，传输继续。暂停、等待、恢复，这个循环就是 TCP 的流量控制，它保证发送速度快的设备，不会把处理速度慢的那一端淹没。

代理链路里，零窗口更容易出现

直连时只有一段连接，接收窗口由目标端自己掌控，情况相对简单。走代理后，客户端到代理、代理到目标端是两段相互独立的连接，各自维护自己的接收窗口。只要其中一段的窗口归零，整条链路的数据流就会停下来。

中间代理除了转发，还要做解析、排队、缓冲。当它的处理速度跟不上数据到达的速度时，它自己的接收窗口会先一步归零，于是出现一种典型现象：客户端的数据已经发到了代理，代理也收下了，却迟迟没有往目标端送。

TCP 为窗口归零内置了应对机制：发送方会定期发出很小的探测包，确认对方是否已经恢复。排查时如果看到连接里有周期性的小包，往往是零窗口探测在工作，说明链路正处于暂停状态。这个机制保证了两端不会在窗口归零后互相干等，也让”连接正常但传输停滞”成为可以观察到的状态。

实际业务里，零窗口最常见于两类场景。一类是大文件或持续数据流：接收端一边接收一边落盘，落盘速度跟不上到达速度，缓冲区很快被占满。另一类是慢速业务：目标端处理每个请求都要等待外部响应，窗口里的数据消化得慢，发送端只能频繁暂停。两类场景的共同点是：问题不在”连接通不通”，而在”处理跟不跟得上”——这也决定了排查时该看处理速度，而不是反复检查连接本身。

问：零窗口能彻底避免吗？答：不能，但它不该成为常态。处理能力充足的链路、合理设置的超时与缓冲，能让窗口归零只是转瞬即逝的插曲。对代理链路来说，窗口状态的恢复速度，本身就是出口质量的一部分——连接活着只是表象，数据一直流动才是真正的健康。