高效排障：详解TCP零窗口不同情况与处置建议

LeeeM

前一阶段我们分析了解了关于TCP异常标记“重传“相关的内容，从故障层面来拆分，”重传“通常是网络层面的原因造成。

上篇内容《高效排障：详解“乱序”根因及处置，无惧问题乱中有序》说了TCP异常流量标记“乱序”的几种常见场景及解决方案，接下来我们一起来了解几个与主机性能层面有关的TCP异常流量标记，分别是TCP Window Full（TCP窗口满）、TCP ZeroWindow（TCP零窗口）、TCP ZeroWindowProbe（TCP零窗口探测，简写为ZWP）、TCP Keep-Alive（TCP保活）。

图1

TCP Window Full

如图1所示，序号为135的报文被标记为“TCP Window Full“，这是CSNAS根据算法通过TCP会话双方的通信过程计算得出来的结果，该标记能够帮助流量分析者了解：在服务器发送完序号为135的报文后，客户端的接收窗（即接收缓存，同时也等于服务器的发送窗）已经满了，无法再继续向客户端发送，需要等待客户端更新窗口之后才能继续发送。

TCP ZeroWindow

图2

序号为136的报文被标记为“TCP ZeroWindow“，又叫做”零窗口“。图2为图1中序号为136报文的解码视图，其中TCP首部的”窗口大小“字段值为0，该报文由客户端发送，表示此时客户端的接收窗口已满，无法再接收。

当产生这种情况时，服务器不再向客户端发送数据，而是等待客户端处理数据，等待窗口（缓存）空出来之后再继续发送。那么问题来了，客户端何时更新窗口呢？根据RFC9293中的建议，TCP在满足如下条件时通告窗口更新：

接收缓存大小 – 已接收未处理字节 – 通告出去的接收窗大小 >= min(Fr*接收缓存大小， 接收方允许最大分段大小)，其中Fr是一个分数，推荐值为1/2。

即，当缓存剩余空间 >= min(接收缓存大小/2，接收方允许最大分段大小)，满足这个条件时，TCP才会更新窗口大小。但考虑这样一种情况，如果窗口更新报文丢失了怎么办呢？那发送方岂不是永远都无法知道窗口已经更新了吗？因此，还需要一个机制来触发接收方被动的发送窗口更新报文。

TCP ZeroWindowProbe(ZWP)

根据RFC9293中的规范，TCP必须支持零窗口探测（ZWP）。即使接收方窗口为0，发送方也必须定期传输至少1字节的新数据或者重传，用于探测窗口。这种传输行为至关重要，这样一旦接收方窗口发生变化，发送方能够知道。同时还规范，即使接收窗口为0，接收方收到TCP报文分段也必须发送确认和窗口为0的分段。当出现接收方0窗口，当发送方的重传周期到达（RTO），则发送0窗口探测 (ZWP) 分段，应当（should）呈指数级增加探测报文之间的时间间隔。

TCP ZWP报文的原理和指导规范有了，那么具体是如何实现的呢？关于这个问题，在互联网上有两种说法：

1、TCP ZWP报文使用上一个报文的Next Seq+1为序列号，以此来表示这是一个特殊的报文；

2、使用IP首部的总长度字段来表示TCP负载为1字节；

遗憾的是只找到了第二种说法的报文实例。

关于第一种说法，并没有见到任何实例，并且从理论上与TCP序列号设计规范不符，因此表示暂不相信。

图3

图3是图1中序号为137报文的解码视图。是上述第二种说法的实例。关注TCP确认位和IP总长度41字节两个字段值。

以太网规范定义了最小帧长为64字节，在以太网首部14字节、IP首部20字节、TCP首部20字节的情况下，仍需在TCP负载部分填充6字节padding才满足64字节最小帧长。

如此一来，如何表明该报文携带了1字节的TCP负载用于表明是一个ZWP呢？这个原理沿用了我们平常计算TCP负载大小的办法，即使用IP报文总长度（41） – IP首部长度（20） – TCP首部长度（20）。于是可知，该报文携带TCP确认位和1字节数据，因此被标记为TCP ZWP报文。

TCP Keep-Alives（保活）

序号为137、138的报文内容除IPID不一样之外，其它内容一致，被识别为保活报文。

关于保活机制，在TCP相关规范中(参考RFC9293)表示为可选设计。规范中表示：应当发送一个没有数据的保活报文，但是出于对错误TCP实现的兼容，也可能可以配置发送1字节的垃圾数据。

TCP ZeroWindowProbeAck(ZWP确认)

零窗口探测确认。根据相关规范，即使接收窗口为0，接收方收到TCP报文分段也必须发送确认和窗口为0的分段。因此收到ZWP报文也不例外，接收方必须发送确认报文以回应。

图4

正如图4所示，这是一个ZWP确认报文，为图1中序号为139报文的解码视图。与ZWP报文不同的是，这是一个针对ZWP报文的确认报文，且窗口大小值为0。

在当前场景下，发送方将根据时间规则稳定的发送ZWP报文，直至接收方满足通告窗口更新条件，更新了窗口大小后，才会继续发送数据。

除此之外，在某些实现中，还会考虑会话最大保持时间，一旦接收方超过设定时间仍未更新窗口，则认为出现了错误，从而强制断开会话，以避免会话“卡住“，长时占用资源。

那么，什么情况下会出现TCP接收窗满，即“零窗口“的情况呢？

主机性能不足

客户端发送“零窗口“标记或服务器发送“零窗口“标记，分别表示客户端或服务器主机性能不足，导致TCP缓存中的数据未被及时处理。

建议排查主机性能方面资源，如CPU、内存、磁盘空间等。

分析TCP交易时序图是运维人员和流量分析工程师的“日常”。了解科来网络分析系统TCP流分析视图中TCP交易时序图的TCP异常流量标记，能够做到在分析TCP流量时事半功倍。及时的定位故障层面，定位故障节点，定位故障根因。

免费易用的流量分析工具下载

扫码关注公众号

更多网络分析技术、技巧、干货分享

- End -