TCP 连接何时被认为是空闲的？

Question

我需要在任何连接上启用 TCP keepalive，现在我正在努力处理我们测试用例的结果。我认为这是因为我不太了解何时发送第一个 keepalive 探测。我在 Linux 上 tcp_keepalive_time 的文档中阅读了以下内容：

最后一个数据包发送（简单的ACKs不被认为是数据）和第一个keepalive探测之间的间隔；之后 连接被标记为需要保持活动，此计数器未使用任何 进一步

其他一些消息来源指出这是连接空闲的时间，但他们没有进一步定义这意味着什么。我还研究了史蒂文斯以找到一个更正式的定义，因为我想知道在考虑重传时“发送的最后一个数据包”实际上意味着什么。

在我的测试用例中，我有一个连接，其中数据仅以相当高的速率从服务器发送到客户端。为了测试 keepalive，我们拔掉了客户端 NIC 上的电缆。我现在可以看到网络堆栈尝试发送数据并进入重传状态，但没有发送保持活动探测。重传时不发送keep alive探针是否正确？

Answer 1

我有一个连接，其中数据仅从服务器发送到客户端 以相当高的速度。

那么你将永远不会看到 keepalives。当“线路保持沉默”时，会发送 Keepalive。 RFC1122有一些解释re keepalives。

“保持活动”机制会定期探测网络的另一端 连接空闲时，即使有 没有要发送的数据

回到你的问题：

其他一些消息来源指出这是连接空闲的时间， 但他们没有进一步定义这意味着什么。

这是 TCP 在戳对端“天哪！还活着？”之前将等待多长时间。

$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200

换句话说，您一直在使用 TCP 连接，而且非常棒。但是，在过去的 2 个小时里，没有任何东西可以发送。假设连接仍然存在是否合理？假设中间的所有中间盒仍然具有您的连接状态是否合理？意见不一，keepalive 不是 RFC793 的一部分。

TCP 规范不包括它的保持活动机制 可能：（1）在瞬态期间导致完全良好的连接中断 互联网故障； (2) 消耗不必要的带宽（“如果没有人 使用连接，谁在乎它是否仍然良好？”）

---

为了测试 keepalive，我们拔掉了客户端 NIC 上的电缆。

这不是在测试 keepalive。这是测试您的 TCP 重传策略，即 TCP 尝试传递您的消息的次数和频率。在 Linux 机器上，这（可能）最终会测试 net.ipv4.tcp_retries2：

在终止活动 TCP 连接之前要重试多少次。 RFC 1122 说限制应该超过100秒。它太小了 数字。默认值 15 对应于 13-30 分钟，具体取决于 RTO。

但RFC5482 - TCP User Timeout Option 提供了更多影响它的方法。

TCP 用户超时控制传输的数据可以保留多长时间 在强制关闭连接之前未确认。

回到问题：

重传时不发送keep alive探针是否正确

这是有道理的：TCP 已经在尝试从其他对等点引出响应，空的 keepalive 将是多余的。

---

Linux 特定 (2.4+) options to influence keepalive

• TCP_KEEPCNT TCP 在断开连接之前应发送的最大保活探测数。

• TCP_KEEPIDLE 如果已在此套接字上设置了套接字选项 SO_KEEPALIVE，则在 TCP 开始发送 keepalive 探测之前连接需要保持空闲的时间（以秒为单位）

• TCP_KEEPINTVL各个keepalive探测之间的时间（以秒为单位）

Linux 特定 (2.6.37+) option to influence TCP User Timeout

TCP_USER_TIMEOUT 中的最大时间量 传输数据之前可能保持未确认的毫秒数 TCP 将强制关闭连接。

因此，例如，您的应用程序可以使用此选项来确定在没有连接时连接可以存活多长时间（类似于您的 NIC 拔出示例）。例如。如果您有理由相信客户会回来（也许他们关上了笔记本电脑的盖子？无线访问不稳定？）您可以指定 12 小时的超时时间，当他们回来时，连接仍然有效。