TCP keep-alive翻译

Posted 2020-09-11 菜菜

 

原文链接:

http://www.freesoft.org/CIE/RFC/1122/114.htm
http://www.freesoft.org/CIE/RFC/1122/index.htm

实现TCP的人或许会包含 "keep-alives" 在它们实现的TCP中,虽然keep-alive不是普遍被接受。如果keep-alive被包含,应用程序必须能够为每个连接打开或者关闭keep-alive,默认一定是关闭状态。
Keep-alive报文仅在一定时间间隔内没有收到数据或者确认报文时才被发送,时间间隔必须能够配置,默认的时间间隔必须不小于俩个小时。

记住TCP传播不包含数据的ack报文是不可靠的是十分重要的,因此,如果keep-alive机制被实现,
if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection(没看懂).
然后,为了兼容错误的TCP实现,它可能被配置成发送一个包含垃圾八元组的keep-alive报文。

讨论

当连接空闲时,keep-alive机制定期的探测连接的另一方，即使它(发起探测的一方)没有数据要发送,TCP标准文档没有包含keep-alive机制,因为它会导致如下问题。
1：网络临时的错误的时候，导致一个良好的连接被断掉
2：浪费没有必要的带宽（如果没有人使用这个连接,谁会去管连接是否还是好的）
3：浪费钱

一些TCP实现包含keep-alive机制,为了确认一个空闲的连接依旧是活跃的(可用的),发送一个探测报文,为了引出对方的响应。
探测报文一般包含SEG.SEQ=SND.NXT-1(自己的TCP序号减一)，探测报文可能还包含或不包含一个垃圾(无用的)八元组。
注意,在一条安静的连接中,SND.NXT(探测方下一个发送的字节序号)=RCV.NXT(被探测方希望收到的序号)，所以当前的SEG.SEQ(探测报文中包含的TCP序号)将在窗口外。
因此，这个探测报文导致接收方返回一个ack(确认)报文来确认当前的连接还是存活的,
如果对等方已经放弃这个连接(由于网络改变,或者网络崩溃),
接收方将响应一个RST报文，而不是响应一个ack报文。

不幸运的是,一些不规范的实现不响应(SEG.SEQ=SND.NXT-1)的报文,除非这个报文包含数据。
Alternatively, an implementation could determine whether a peer responded correctly to keep-alive packets with no garbage data octet.（没看懂）

A TCP keep-alive mechanism should only be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if
a client crashes or aborts a connection during a network failure.
（好像是说服务器没必要为一个死了的客户端耗费资源）

原文

4.2.3.6 TCP Keep-Alives

 

Implementors MAY include "keep-alives" in their TCP implementations, although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection, and they MUST default to off.

Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours.

It is extremely important to remember that ACK segments that contain no data are not reliably transmitted by TCP. Consequently, if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection. An implementation SHOULD send a keep-alive segment with no data; however, it MAY be configurable to send a keep-alive segment containing one garbage octet, for compatibility with erroneous TCP implementations.

 

DISCUSSION:
A "keep-alive" mechanism periodically probes the other end of a connection when the connection is otherwise idle, even when there is no data to be sent. The TCP specification does not include a keep-alive mechanism because it could: (1) cause perfectly good connections to break during transient Internet failures; (2) consume unnecessary bandwidth ("if no one is using the connection, who cares if it is still good?"); and (3) cost money for an Internet path that charges for packets.

Some TCP implementations, however, have included a keep-alive mechanism. To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains SEG.SEQ = SND.NXT-1 and may or may not contain one garbage octet of data. Note that on a quiet connection SND.NXT = RCV.NXT, so that this SEG.SEQ will be outside the window. Therefore, the probe causes the receiver to return an acknowledgment segment, confirming that the connection is still live. If the peer has dropped the connection due to a network partition or a crash, it will respond with a RST instead of an acknowledgment segment.

Unfortunately, some misbehaved TCP implementations fail to respond to a segment with SEG.SEQ = SND.NXT-1 unless the segment contains data. Alternatively, an implementation could determine whether a peer responded correctly to keep-alive packets with no garbage data octet.

A TCP keep-alive mechanism should only be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure.