Idle Connection Management and

今天在实验RST中断TCP连接的时候遇到的一个问题：

当发送RST后，会因为TCP Keeplive而连接继续，数据照常传输，没有阻断成功。

查了一下资料：

Idle Connection Management and "Keepalive" Messages

One final connection management issue in TCP is how to handle an idle connection; that is, a TCP session that is active but that has no data being transmitted by either device for a prolonged period of time. The TCP standard specifies that the appropriate action to take in this situation is… nothing. The reason is that, strictly speaking, there is no need to do anything to maintain an idle connection in TCP. The protocol is perfectly happy to allow both devices to stop transmitting for a very long period of time, and then simply resume transmissions of data and acknowledgment segments when either has data to send.

However, just as many people become “antsy” when they are on a telephone call and they don’t hear anything for a long while, there was concern on the part of some TCP implementors that a TCP connection that was idle for a very long while might mean that the connection had been broken.

Thus, TCP often includes an “unofficial” feature that allows a device with a TCP link to periodically send a null segment containing no data to its peer on the connection. If the connection is still valid, the other device responds with a segment containing an acknowledgment; if it is not, the other device will reply with a connection reset segment as described above. These segments sometimes called TCP “keepalive” messages, or just “keepalives”. They are analogous to .

The use of these messages is quite controversial, and therefore, not universal. Those who are opposed to them argue that they are not really necessary, and that sending them represents a waste of internetwork bandwidth and a possible additional cost on metered links (those that charge for each datagram sent.) Their key point is that if the connection is not presently being used, it doesn’t matter if it is still valid or not; as soon as the connection is used again, if it has broken in the mean time, TCP can handle that using the reset function mentioned above.

Worse, sending a “keepalive” can in theory cause a good TCP session to be unnecessarily broken. This may happen if the “keepalive” is sent during a time when there is an intermittent failure between the client and server, a failure that might otherwise have corrected itself by the time the next piece of “real” data must be sent. In addition, some TCP implementations may not properly deal with the receipt of these segments.

Those in favor of using “keepalives” point out that each TCP connection consumes a certain amount of resources, and this can be an issue especially for busy . If many clients connect to such a server and don’t terminate the TCP connection properly, the server may sit for a long time with an idle connection, using system memory and other resources that could be applied elsewhere.

Since there is no wide acceptance on the use of this feature, devices implementing it include a way to disable it if necessary. Devices are also programmed so they will not terminate a connection simply as a result of not receiving a response to a single “keepalive”. They may do so if they do not receive a reply after several such messages have been sent over a period of time.

总的来说，这个Keeplive是一项非官方的技术，它本身也是有争议的。
Keeplive就是在TCP连接没有数据传输的时候，不是直接断开连接，而是不断的发送空数据包，只是为了保持TCP的连接，理论上提供很好的TCP传输会话。
对于一个负载比较重的服务器来说，保持大量的TCP连接会加重服务器的负担。