【转载】TCP保活(TCP keepalive)

下图是我遇到tcp keepalive的例子:

以下为转载:

TCP保活的缘起

双方建立交互的连接,但是并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会,那么在长时间无数据交互的时间段内,交互双方都有可能出现掉电、死机、异常重启等各种意外,当这些意外发生之后,这些TCP连接并未来得及正常释放,那么,连接的另一方并不知道对端的情况,它会一直维护这个连接,长时间的积累会导致非常多的半打开连接,造成端系统资源的消耗和浪费,为了解决这个问题,在传输层可以利用TCP的保活报文来实现。

TCP保活的作用

1, 探测连接的对端是否存活
        在应用交互的过程中,可能存在以下几种情况:
(1), 客户端或服务器端意外断电、死机、崩溃、重启
(2), 中间网络已经中断,而客户端与服务器端并不知道
        利用保活探测功能,可以探知这种对端的意外情况,从而保证在意外发生时,可以释放半打开的TCP连接。

2, 防止中间设备因超时删除连接相关的连接表

中间设备如防火墙等,会为经过它的数据报文建立相关的连接信息表,并为其设置一个超时时间的定时器,如果超出预定时间,某连接无任何报文交互的话,中间设备会将该连接信息从表中删除,在删除后,再有应用报文过来时,中间设备将丢弃该报文,从而导致应用出现异常,这个交互的过程大致如下图所示:

这种情况在有防火墙的应用环境下非常常见,这会给某些长时间无数据交互但是又要长时间维持连接的应用(如数据库)带来很大的影响,为了解决这个问题,应用本身或TCP可以通过保活报文来维持中间设备中该连接的信息,(也可以在中间设备上开启长连接属性或调高连接表的释放时间来解决,但是,这个影响可能较大,有机会再针对这个做详细的描述,在此不多说)。

常见应用故障场景:

某财务应用,在客户端需要填写大量的表单数据,在客户端与服务器端建立TCP连接后,客户端终端使用者将花费几分钟甚至几十分钟填写表单相关信息,终端使用者终于填好表单所需信息后,点击“提交”按钮,结果,这个时候由于中间设备早已经将这个TCP连接从连接表中删除了,其将直接丢弃这个报文或者给客户端发送RST报文,应用故障产生,这将导致客户端终端使用者所有的工作将需要重新来过,给使用者带来极大的不便和损失。

TCP保活报文格式:

1, TCP keepalive probe报文

我们看到,TCP保活探测报文是将之前TCP报文的序列号减1,并设置1个字节,内容为“00”的应用层数据,如下图所示:

发送keepalive probe报文之前的TCP报文

 TCP keepalive probe报文

2, TCP keepalive ACK报文

TCP保活探测确认报文就是对保活探测报文的确认, 其报文格式如下:

TCP keepalive ACK报文

TCP保活报文交互过程

TCP保活的交互过程大致如下图所示:

TCP保活可能带来的问题

1, 中间设备因大量保活连接,导致其连接表满

网关设备由于保活问题,导致其连接表满,无法新建连接(XX局网闸故障案例)或性能下降严重
2, 正常连接被释放

当连接一端在发送保活探测报文时,中间网络正好由于各种异常(如链路中断、中间设备重启等)而无法将该保活探测报文正确转发至对端时,可能会导致探测的一方释放本来正常的连接,但是这种可能情况发生的概率较小,另外,一般也可以增加保活探测报文发生的次数来减小这种情况发生的概率和影响。

TCP保活的设置

一般而言,保活探测主要在服务器端实现,如果应用层有相应的保活机制时,传输层的TCP保活就可以不用。

在windows系统中,我们可以通过修改注册表等来达到开启、调整保活相关
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
KeepAliveInterval 
项:Tcpip\Parameters
数值类型:REG_DWORD - 时间(以毫秒为单位)
有效范围:1 - 0xFFFFFFFF
默认值:1000(1 秒)
说明:此参数确定在收到响应之前,保活重传之间的时间间隔。一旦收到一个响应,将由 KeepAliveTime 值重新控制在下一次保活传输之前的延迟。如果经过 TcpMaxDataRetransmissions 指定的重新传输次数后仍无响应,将放弃连接。 
KeepAliveTime 
项:Tcpip\Parameters
数值类型:REG_DWORD - 时间(以毫秒为单位)
有效范围:1 - 0xFFFFFFFF
默认值:7,200,000(两个小时)
说明:此参数控制 TCP 试图通过发送保活数据包来验证空闲连接是否仍然保持的次数。如果远程系统仍然可以连接并且正在运行,它就会响应保活传输。默认情况下不发送保活数据包。应用程序可以在连接上启用此功能。

关于Linux、HP UNIX、IBM AIX、SUN solaris等系统keepalive参数的设置和修改,请大家自行百度谷歌,在此我就不做简单搬砖的事情了。

时间: 2024-10-13 21:04:15

【转载】TCP保活(TCP keepalive)的相关文章

TCP 保活功能 KEEPALIVE

转载:http://www.vants.org/?post=162 TCP保活(TCP keepalive) 作者:易隐者 发布于:2012-10-15 11:30 Monday 分类:网络分析 TCP保活的缘起 双方建立交互的连接,但是并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会,那么在长时间无数据交互的时间段内,交互双方都有可能出现掉电.死机.异常重启等各种意外,当这些意外发生之后,这些TCP连接并未来得及正常释放,那么,连接的另一方并不知道对端的情况,它会一

TCP心跳 | TCP keepAlive(转)

应用层对于每个socket采用如下函数来开启 keepalive机制,其参数将采用系统上述配置. setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive)); 注意:keepalive是一个TCP协议包,并不是应用层数据包,意即通过recv等函数从应用层上是无法获得该协议包.可通过抓包工具来看. ===================================================

TCP漫谈之keepalive和time_wait

TCP是一个有状态通讯协议,所谓的有状态是指通信过程中通信的双方各自维护连接的状态. 一.TCP keepalive 先简单回顾一下TCP连接建立和断开的整个过程.(这里主要考虑主流程,关于丢包.拥塞.窗口.失败重试等情况后面详细讨论.) 首先是客户端发送syn(Synchronize Sequence Numbers:同步序列编号)包给服务端,告诉服务端我要连接你,syn包里面主要携带了客户端的seq序列号:服务端回发一个syn+ack,其中syn包和客户端原理类似,只不过携带的是服务端的se

java中TCP之TCP实现

java中TCP之TCP实现 代码均来自计算机网络教材 此为服务器端代码 package server; import java.io.BufferedReader; import java.io.DataOutputStream; import java.io.IOException; import java.io.InputStreamReader; import java.net.ServerSocket; import java.net.Socket; public class TcpS

C/C++网络编程中的TCP保活

原博客:http://blog.csdn.net/weiwangchao_/article/details/7225338 Linux环境下的TCP Keepalive参数设置 为什么说是系统默认值的呢?因为有这样几个值,我们并没有手动设置,是采用的系统默认值.即, 多长时间发送一次保活心跳? 如果没有返回,多长时间再重试发送? 重试几次为失败? 如果是Linux操作系统,这三个值分别为 # cat /proc/sys/net/ipv4/tcp_keepalive_time 7200 # cat

闲说HeartBeat心跳包和TCP协议的KeepAlive机制

很多应用层协议都有HeartBeat机制,通常是客户端每隔一小段时间向服务器发送一个数据包,通知服务器自己仍然在线,并传输一些可能必要的数据.使用心跳包的典型协议是IM,比如QQ/MSN/飞信等协议. 学过TCP/IP的同学应该都知道,传输层的两个主要协议是UDP和TCP,其中UDP是无连接的.面向packet的,而TCP协议是有连接.面向流的协议. 所以非常容易理解,使用UDP协议的客户端(例如早期的“OICQ”,听说OICQ.com这两天被抢注了来着,好古老的回忆)需要定时向服务器发送心跳包

TCP保活定时器

TCP有Keepalive功能,它和HTTP的Keepalive功能目的不一样.TCP服务器希望知道客户端是否崩溃.重新启动或者中间路由不通.保活定时器就提供这种功能. 在进一步介绍TCP的保活定时器前,先了解一个概念:长连接和短连接.(TCP是长连接) 长连接:建立一个连接,多个请求复用这个连接,最后再关闭连接. 短连接:建立一个连接,传输一个请求,然后关闭连接. 当服务器发送探测报文时,客户端可能处于4种不同的情况:仍然正常运行.已经崩溃.已经崩溃并重启了. 由于中间链路问题不可达.在不同的

Tcp协议的keepalive功能

L:128 原文地址:https://www.cnblogs.com/jackey2015/p/10643463.html

[TCP/IP]TCP的三次握手和四次挥手

概述 总结一下TCP中3次握手过程,以及其原生的缺陷 引起的SYN Flood的介绍 1.TCP连接建立--三次握手 几个概念: seq:序号,占4个字节,范围[0,4284967296],由于TCP是面向字节流的,在 一个1个TCP连接中传送字节流中国的每一个字节都按照顺序编号,此外序号是循环使用的 ACK: 仅当ACK=1时确认字段才有效,当ACK=0时确认字段无效,并且TCP规定,在连接建立后所有的传送报文段都必须要把ACK置为1 SYN:同步序列号,用来发起一个连接.当SYN=1而ACK