TCP 连接断开之后，为什么对端需要 10 分钟往上才能知道？

Question

我在研究『rabbitmq 消费者为什么需要心跳』

找了一篇东西：How does rabbitmq heartbeat work

其中一个答案提到一个概念：

from the RMQ Heartbeat documentation:

Network can fail in many ways, sometimes pretty subtle (e.g. high ratio packet loss). Disrupted TCP connections take a moderately long time (about 11 minutes with default configuration on Linux, for example) to be detected by the operating system. AMQP 0-9-1 offers a heartbeat feature to ensure that the application layer promptly finds out about disrupted connections (and also completely unresponsive peers). Heartbeats also defend against certain network equipment which may terminate "idle" TCP connections.

This isn't a request to a queue or stubbed message. This is a TCP/IP connection with packets sent across in a specific format for the heartbeat.

If you want the real details, you can read the AMQP 0.9.1 Specification, section 4.2.1 and 4.2.7 with errata on how RabbitMQ corrects for errors in the specification, as well.

翻译一下：

大概意思就是说，基于 tcp 自己的心跳机制，延迟太大了，对端要知道出毛病了，需要十几分钟才能发现。

我对 TCP 的了解相对比较匮乏

我不明白，这里为什么需要十几分钟对端才能知道？

• 如果是 A 发出『四次挥手』主动要求分手，B 应该是立刻知道，而不是需要十几分钟才知道，对吧？
• 如果是 A 和 B 之间的网线被人剪断了，才需要十几分钟才能知道对方已经『不可达』了是吗？

Answer 1

这里说的十分钟 ，不是在传输层 层面上的十分钟，而是mq自己的心跳保活等保活时间是十分钟。
例如一次心跳成功了，那么在十分钟之内的心跳信息即使都失败了，仍然算是“活”的状态。过了十分钟后才算“亡”。这个应该是可以配置的。

Answer 2

心跳机制是用来侦测网络是否正常的，和连接双方正常关闭没什么联系。

tcp连接建立之后，如果在某个时刻网络故障了，需要分两种情况讨论：

• 情况1：双方一直有保持通讯，则网络故障很快就会被侦测到（报文的定时器超时）
• 情况2：极端情况下，双方三次握手后完全不进行通讯，则大家都无法知道网络是否正常，这时候需要有一种心跳机制（tcp keepalive）来侦测。tcp keepalive在linux上的默认值是7200秒，即如果双方都没有数据来往的话，需要2小时之后才能知道网络有故障。

所以说传输层的的侦测手段是非常粗糙的，为了更快知道网络的情况，需要应用层有自己的心跳机制来侦测。此时应用层的心跳包就是tcp层的正常数据包，让tcp连接上一直有数据流通，变成了上面的情况1，这样即使应用之间没有业务数据交换也能较快知道传输层是否健康了