TCP 保活功能 KEEPALIVE

转载:http://www.vants.org/?post=162

TCP保活(TCP keepalive)

作者:易隐者 发布于:2012-10-15 11:30 Monday 分类:网络分析

TCP保活的缘起

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

TCP保活的作用

1, 探测连接的对端是否存活

在应用交互的过程中,可能存在以下几种情况:

(1)客户端或服务器端意外断电、死机、崩溃、重启

(2)中间网络已经中断,而客户端与服务器端并不知道

利用保活探测功能,可以探知这种对端的意外情况,从而保证在意外发生时,可以释放半打开的TCP连接。

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

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

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

常见应用故障场景

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

TCP保活报文格式

TCP keepalive probe报文

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

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

2.TCP keepalive ACK报文

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

TCP keepalive ACK报文

TCP保活报文交互过程

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

TCP保活可能带来的问题

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

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

  2. 正常连接被释放

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

TCP保活的设置

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

时间: 2024-08-27 16:59:22

TCP 保活功能 KEEPALIVE的相关文章

【转载】TCP保活(TCP keepalive)

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

TCP漫谈之keepalive和time_wait

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

用python实现wireshark的follow tcp stream功能

长话短说,wireshark有一个follow tcp stream功能,这个功能很方便.美中不足的是提取出的stream 数据没有时间戳等其他信息,在分析数据的延时和丢包问题时就有些力不从心了.这里简单用python实现了一个简单follow tcp stream功能,同时保留了tcp信息. 原理很简单,仍然是基于wireshark,里面有一个Export packet dissection as XML 'pdml' file. 导出来之后的文件内容是这个样子的: <proto name=&qu

Tcp协议的keepalive功能

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

TCP保活定时器

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

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中的长连接和短连接(转载)

原文地址:http://www.cnblogs.com/onlysun/p/4520553.html 当网络通信时采用TCP协议时,在真正的读写操作之前,server与client之间必须建立一个连接,当读写操作完成后,双方不再需要这个连接时它们可以释放这个连接,连接的建立是需要三次握手的,而释放则需要4次挥手,所以说每个连接的建立都是需要资源消耗和时间消耗的 示意图: 长连接: 所谓长连接,指在一个TCP连接上可以连续发送多个数据包,在TCP连接保持期间,如果没有数据包发送,需要双方发检测包以

《TCP/IP详解:卷一》-TCP部分讲解

TCP/IP协议 作者:Danbo 2015-7-2 本文为参考TCP/IP详解卷一,某些知识点加上了作者自己的理解,如有错误,欢迎指正,可以微博联系我! TCP包格式和IP包格式如下: TCP的正常建立与关闭 建立连接 TCP协议提供可靠的面向连接服务,采用三次握手建立连接.第一次握手:建立连接时,客户端发送SYN包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认:第二次握手:服务器收到SYN包,向客户端返回ACK(ack=j+1),同时自己也发送一个SYN包(syn=k),