TCP保持活动在TCP零窗口后涉及并错误地关闭连接

Question

我们看到这种模式在通过TCP连接传输数据的两个RHEL 6盒之间发生了很多.客户端发出TCP窗口满,0.2秒后客户端发送TCP Keep-Alives,服务器响应的内容看起来像正确形状的响应.然而,客户端对此不满意,并继续发送TCP Keep-Alives,直到最近9秒后它终于关闭与RST的连接.

尽管RHEL盒具有默认的TCP Keep-Alive配置:

net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75

......声明这应该只发生在2小时的沉默之后.我是否错误地阅读了我的PCAP(可根据要求提供相关数据包)？

下面是Wireshark模式的截图,中间有我自己的包注释.

Answer 1

实际上，这些“保活”数据包并不是用于 TCP 保活！它们用于窗口大小更新检测。

Wireshark 将它们视为保活数据包，只是因为这些数据包看起来像保活数据包。

TCP 保持活动数据包只是一个 ACK​​，其序列号设置为比连接的当前序列号小 1。

（我们假设ip 10.120.67.113指主机A，10.120.67.132指主机B。）在第249511号数据包中，A确认seq 24507484。在下一个数据包（第249512号）中，B发送seq 24507483（24507484-1） ）。

为什么有这么多“keep-alive”数据包，它们有什么用？

A向B发送数据，B回复零窗口大小，告诉A暂时无法再接收数据。为了确保A知道B何时可以再次接收数据，A通过持续定时器一次又一次地向B发送“保持活动”数据包，B用他的窗口大小信息回复A（在我们的例子中，B的窗口大小始终为零）。

并且在计算持久计时器时使用正常的 TCP 指数退避。所以我们可以看到A在0.2s后发送第一个“keep-alive”数据包，在0.4s后发送第二个数据包，在0.8s后发送第三个数据包，在1.6s后发送第四个数据包......

这种现象与TCP流控有关。

Answer 2

源自客户端的数据包中的源 IP 地址和目标 IP 地址与响应数据包中的目标 IP 地址和源 IP 地址不匹配，这表明盒子之间有某些设备正在执行 NAT。了解数据包在哪里被捕获也很重要。客户端本身的数据包捕获可能有助于理解问题。

请注意，如果客户端两个小时或更长时间没有收到数据包，则可以生成 TCP keepalive。根据 RFC 1122，如果客户端未收到来自对等方的保活响应，则客户端会重试保活。连续重试失败后最终断开连接。

NAT 设备通常实施连接缓存来维护正在进行的连接的状态。如果连接大小达到限制，NAT 设备将丢弃旧连接以便为新连接提供服务。这也可能导致这样的情况。

给定的数据包捕获表明数据包很有可能未到达客户端，因此在客户端计算机上捕获数据包将很有帮助。