linux tcp空闲连接时间,什么时候TCP连接被认为是空闲的？

cnicutar..

17

我有一个连接,数据只以相当高的速率从服务器发送到客户端.

然后你永远不会看到Keepalive.当电线"静音"时发送Keepalive.RFC1122有一些解释re keepalive.

即使没有数据要发送,当连接空闲时,"保持活动"机制会定期探测连接的另一端.

回到你的问题:

其他一些消息来源表示这是连接空闲的时间,但它们没有进一步定义这意味着什么.

这是TCP在等待"hoy!还活着吗？"之前等待的时间.

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

7200

换句话说,你一直在使用TCP连接,它很棒.但是,在过去的2个小时里,没有任何东西要发送.假设连接仍然存在是否合理？假设中间的所有中间盒仍然具有关于您的连接的状态,这是否合理？意见各不相同,Keepalive不属于RFC793.

TCP规范不包括它可能的保持活动机制:(1)在瞬时Internet故障期间导致完美的连接断开; (2)消耗不必要的带宽("如果没有人使用连接,谁在乎它是否仍然好？")

为了测试keepalive,我们拔掉了客户端网卡上的电缆.

这不是测试keepalive.这是测试您的TCP重新传输策略,即TCP尝试传递消息的次数和频率.在Linux机器上,这(可能)最终测试net.ipv4.tcp_retries2:

如何在杀死活动TCP连接之前重试.RFC 1122表示限制应该超过100秒.这个数字太小了.默认值15对应于13-30分钟,具体取决于RTO.

TCP用户超时控制在强制关闭连接之前传输的数据可能保持未确认的时间.

回到问题:

在重传期间不发送保持活动探测是否正确

这是有道理的:TCP已经试图从另一个对等方引出响应,空的keepalive将是多余的.

特定于Linux的(2.4+)选项可影响keepalive

TCP_KEEPCNT 丢弃连接之前TCP应发送的最大keepalive探测数.

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

TCP_KEEPINTVL 各个keepalive探测器之间的时间(以秒为单位)

特定于Linux的(2.6.37+)选项可影响TCP用户超时

TCP_USER_TIMEOUT 在TCP强行关闭连接之前,传输数据的最大时间(以毫秒为单位)可能仍未被确认.

因此,例如,您的应用程序可以使用此选项来确定连接在没有连接时存活多长时间(类似于您的NIC拔出示例).例如,如果你有理由相信客户会回来(也许他们关闭了笔记本电脑的盖子？参差不齐的无线接入？)你可以指定12小时的超时,当他们回来时,连接仍然会起作用.