泽民博客 ☰ Menu

Tcp Keepalive和HTTP Keep-alive

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



 Tcp Keepalive存在的作用

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



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



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



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



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


连接。



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



        中间设备如防火墙等，会为经过它的数据报文建立相关的连接信息表，并未其设置一个超时时间的定时器，如果超出预定时间，某连接无任何报文交互的话，中间设备会将该连接信息从表中删除，在删除后，再有应用报文过来时，中间设备将丢弃该报文，从而导致应用出现异常            这种情况在有防火墙的应用环境下非常常见，这会给某些长时间无数据交互但是又要长时间维持连接的应用(如数据库)带来很大的影响，为了解决这个问题，应用本身或TCP可以通过保活报文来维持中间设备中该连接的信息，(也可以在中间设备上开启长连接属性或调高连接表的释放时间来解决，但是，这个影响可能较大，有机会再针对这个做详细的描述，在此不多说)。

        常见应用故障场景:

            某财务应用，在客户端需要填写大量的表单数据，在客户端与服务器端建立TCP连接后，客户端终端使用者将花费几分钟甚至几十分钟填写表单相关信息，

        终端使用者终于填好表单所需信息后，点击“提交”按钮，结果，这个时候由于中间设备早已经将这个TCP连接从连接表中删除了，

        其将直接丢弃这个报文或者给客户端发送RST报文，应用故障产生，这将导致客户端终端使用者所有的工作将需要重新来过，给使用者带来极大的不便和损失。　

      TCP保活可能带来的问题

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



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



         2.正常连接被释放



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


HTTP Keepalive
Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout,和Apache的KeepAliveTimeout。



这个keepalive_timeout时间值意味着:一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。



当httpd守护进程发送完一个响应后，理应马上主动关闭响应的tcp连接，设置keepalive_timeout后，httpd守护进程会想说:"再等等吧,看看浏览器还有没有请求过来",这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览器发过来http请求，则关闭这个http连接。



1.在没有设置keepalive_timeout情况下，一个socket资源从建立到真正释放需要经过的时间是:建立tcp连接+传送http请求+php脚本执行+传送http响应+关闭tcp连接



2.设置了keepalive_timeout时间情况下，一个socket建立到释放需要的时间是多了keepalive_timeout时间。


http keep-alive与tcp keep-alive



http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活的更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP连接状况的保险机制。tcp keep-alive保险定时器，支持三个系统内核配置参数:


echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time



echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl



echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes



keepalive是TCP保鲜定时器，当网路两端建立了TCP连接之后，闲置idle(双方没有任何数据发送往来)了tcp_keepalive_time后，服务器内核就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包),则会在tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对方的ack，如果一直没有收到对方的ack，一共会尝试tcp_keepalive_probes次，每次的间隔时间在这里分别是15s、30s、45s、60s、75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。



TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。也就是说，仅当nginx的keepalive_timeout值设置高于tcp_keepalive_time,并且距此tcp连接传输的最后一个http响应，经过了tcp_keepalive_time时间之后，操作系统才会发送侦测包来决定是否要丢弃这个TCP连接。



 一般不会出现这种情况，除非你需要这样做。


keep-alive与TIME_WAIT
使用http keep-alive,可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive,建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。

TCP是一种有连接的协议，但是这个连接并不是指有一条实际的电路，而是一种虚拟的电路。TCP的建立连接和断开连接都是通过发送数据实现的，也就是我们常说的三次握手、四次挥手。TCP两端保存了一种数据的状态，就代表这种连接，TCP两端之间的路由设备只是将数据转发到目的地，并不知道这些数据实际代表了什么含义，也并没有在其中保存任何的状态信息，也就是说中间的路由设备没有什么连接的概念，只是将数据转发到目的地，只有数据的发送者和接受者两端真正的知道传输的数据代表着一条连接。



但是这就说明了一点，如果不发送数据那么是无法断开连接的。正常情况下当TCP的一端A调用了SOCKET的close或者进程结束，操作系统就会按照TCP协议发送FIN数据报文。B端收到后就会断开连接。但是当出现了上文所说的异常情况时：被拔掉网线或者断掉电源，总结起来就是没有机会发出断开的FIN数据报文。那么和A直连的路由设备虽然知道A设备已经断开了，但是路由设备并没有保存连接的状态信息，所以路由设备也就不可能去通知B端A端的断开。而B端没有收到断开的数据报文就会依然保持连接。所以A端拔掉网线或者断掉电源后B端是没办法收到断开连接的通知的。



解决方案
保持连接并不是毫无代价的，如果这种异常断开的连接有很多，那么势必会耗费大量的资源，必须要想办法检测出这种异常连接。
检测的方法很简单，只要让B端主动通过这个连接向A端继续发送数据即可。上文说过，A端异常断开后，和A端直接连接的路由器是知道的。当B端发送的数据经过转发后到达这个路由器后，必然最终会返回B端一个目的不可达。此时B端立刻就会知道这条连接其实已经异常断开了。
但是B端不可能知道什么时候会出现这种异常，所以B端必须定时发送数据来检测连接是否异常断开。数据的内容无关紧要，任何数据都能达到这个效果。这个数据就是我们经常在TCP编程中所说的心跳。



KEEP_ALIVE
TCP协议本身就提供了一种这样的机制来探测对端的存活。TCP协议有一个KEEP_LIVE开关，只要打开这个开关就会定时发送一些数据长度为零的探测心跳包，发送的频率和次数都可以设置



心跳包的发送，通常有两种技术
方法1：应用层自己实现的心跳包
由应用程序自己发送心跳包来检测连接是否正常，大致的方法是：服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包，然后启动一个低级别的线程，在该线程中不断检测客户端的回应， 如果在一定时间内没有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没 有收到服务器的心跳包，则认为连接不可用。



方法2：TCP的KeepAlive保活机制
因为要考虑到一个服务器通常会连接多个客户端，因此由用户在应用层自己实现心跳包，代码较多 且稍显复杂，而利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。 不论是服务端还是客户端，一方开启KeepAlive功能后，就会自动在规定时间内向对方发送心跳包， 而另一方在收到心跳包后就会自动回复，以告诉对方我仍然在线。 因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不开启KeepAlive功 能，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，KeepAlive设置不合理时可能会 因为短暂的网络波动而断开健康的TCP连接。并且，默认的KeepAlive超时需要7,200，000 MilliSeconds， 即2小时，探测次数为5次。对于很多服务端应用程序来说，2小时的空闲时间太长。因此，我们需要手工开启KeepAlive功能并设置合理的KeepAlive参数。



心跳检测步骤：
1客户端每隔一个时间间隔发生一个探测包给服务器
2客户端发包时启动一个超时定时器
3服务器端接收到检测包，应该回应一个包
4如果客户机收到服务器的应答包，则说明服务器正常，删除超时定时器
5如果客户端的超时定时器超时，依然没有收到应答包，则说明服务器挂了


Category linux