TCP协议中有长连接和短连接之分。短连接环境下，数据交互完毕后，主动释放连接； 双方建立交互的连接，但是并不是一直存在数据交互，有些连接会在数据交互完毕后，主动释放连接，而有些不会，那么在长时间无数据交互的时间段内，交互双方都有可能出现掉电、死机、异常重启，还是中间路由网络无故断开、NAT超时等各种意外。 当这些意外发生之后，这些TCP连接并未来得及正常释放，那么，连接的另一方并不知道对端的情况，它会一直维护这个连接，长时间的积累会导致非常多的半打开连接，造成端系统资源的消耗和浪费，为了解决这个问题，在传输层可以利用TCP的保活报文来实现，这就有了TCP的Keepalive（保活探测）机制。 Tcp Keepalive存在的作用 探测连接的对端是否存活 在应用交互的过程中，可能存在以下几种情况： 客户端或服务端意外断电，死机，崩溃，重启。 中间网络已经中断，而客户端与服务器并不知道。 利用保活探测功能，可以探知这种对端的意外情况，从而保证在意外发生时，可以释放半打开的TCP、 连接。 防止中间设备因超时删除连接相关的连接表 中间设备如防火墙等，会为经过它的数据报文建立相关的连接信息表，并未其设置一个超时时间的定时器，如果超出预定时间，某连接无任何报文交互的话，中间设备会将该连接信息从表中删除，在删除后，再有应用报文过来时，中间设备将丢弃该报文，从而导致应用出现异常，这个交互的过程大致如下图所示: 这种情况在有防火墙的应用环境下非常常见，这会给某些长时间无数据交互但是又要长时间维持连接的应用(如数据库)带来很大的影响，为了解决这个问题，应用本身或TCP可以通过保活报文来维持中间设备中该连接的信息，(也可以在中间设备上开启长连接属性或调高连接表的释放时间来解决。 常见应用故障场景: 某财务应用，在客户端需要填写大量的表单数据，在客户端与服务器端建立TCP连接后，客户端终端使用者将花费几分钟甚至几十分钟填写表单相关信息，终端使用者终于填好表单所需信息后，点击“提交”按钮，结果，这个时候由于中间设备早已经将这个TCP连接从连接表中删除了，其将直接丢弃这个报文或者给客户端发送RST报文，应用故障产生，这将导致客户端终端使用者所有的工作将需要重新来过，给使用者带来极大的不便和损失。 TCP保活报文交互过程 TCP保活的交互过程大致如下图所示: TCP保活可能带来的问题： 中间设备因大量保活连接，导致其连接表满，网关设备由于保活问题，导致其连接表满，无法新建连接(XX局网闸故障案例)或性能下降严重 正常连接被释放 当连接一端在发送保活探测报文时，中间网络正好由于各种异常(如链路中断、中间设备重启等)而无法将保活探测报文正确转发至对端时，可能会导致探测的一方释放本来正常的连接，但是这种可能情况发生的概率较小， 另外，一般也可以增加保活探测报文发生的次数来减少这种情况发生的概率和影响。 TCP Keepalive协议解读 下面协议解读，基于 RFC1122#TCP Keep-Alives （注意这是协议的解读站在协议的角度） TCP Keepalive 虽不是标准规范，但操作系统一旦实现，默认情况下须为关闭，可以被上层应用开启和关闭。 TCP Keepalive必须在 没有任何数据（包括ACK包）接收之后的周期内才会被发送，允许配置，默认值不能够小于2个小时 不包含数据的ACK段在被TCP发送时没有可靠性保证，意即一旦发送，不确保一定发送成功。系统实现不能对任何特定探针包作死连接对待 规范建议keepalive保活包不应该包含数据，但也可以包含1个无意义的字节，比如0x0。 SEG.SEQ = SND.NXT-1，即TCP保活探测报文序列号将前一个TCP报文序列号减1。SND.NXT = RCV.NXT，即下一次发送正常报文序号等于ACK序列号；总之保活报文不在窗口控制范围内 有一张图，可以很容易说明，但请仔细观察Tcp Keepalive部分： TCP Keepalive 需要注意的点（协议层面） 不太好的TCP堆栈实现，可能会要求保活报文必须携带有1个字节的数据负载 TCP Keepalive应该在服务器端启用，客户端不做任何改动；若单独在客户端启用，若客户端异常崩溃或出现连接故障，存在服务器无限期的为已打开的但已失效的文件描述符消耗资源的严重问题。 但在特殊的NFS文件系统环境下，需要客户端和服务器端都要启用Tcp… Continue reading TCP Keepalive机制刨根问底