【 总结 】Tcp Keepalive 和 HTTP Keepalive 详解

TCP Keepalive

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

Tcp Keepalive存在的作用

1.探测连接的对端是否存活
            在应用交互的过程中,可能存在以下几种情况:
            (1)客户端或服务器意外断电,死机,崩溃,重启。
            (2)中间网络已经中断,而客户端与服务器并不知道。

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

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

            

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

  常见应用故障场景:

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

  TCP保活报文交互过程   

            

TCP保活可能带来的问题
        1.中间设备因大量保活连接,导致其连接表满
            网关设备由于保活问题,导致其连接表满,无法新建连接(XX局网闸故障案例)或性能下降严重
        2.正常连接被释放
            当连接一端在发送保活探测报文时,中间网络正好由于各种异常(如链路中断、中间设备重启等)而无法将该保活探测报文正确转发至对端时,
            可能会导致探测的一方释放本来正常的连接,但是这种可能情况发生的概率较小,另外,一般也可以增加保活探测报文发生的次数来减小这种情况发生的概率和影响。

HTTP Keepalive

Httpd守护进程,一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout,和Apache的KeepAliveTimeout。
    这个 keepalive_timout时间值意味着:一个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_timout时间情况下,一个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-alvie,可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单,相较而言,启用keep-alive,
    建立的tcp连接更少了,自然要被关闭的tcp连接也相应更少了。

时间: 2024-10-31 19:06:39

【 总结 】Tcp Keepalive 和 HTTP Keepalive 详解的相关文章

马哥教育第二十天TCP及socket通信原理详解、http协议、httpd

1.tcp.udp是一种传输协议,实现进程地址标记,套接字是一个虚拟设备,用来表明主机上的某个进程      常用端口:0-1023:管理员才有权限使用,永久地分配给某应用使用      注册端口:1024-41951:只有一部分被注册,只要确保主机上没有进程使用该端口.      动态端口或私有端口:41952-65535:由内核分配临时端口,如果临时端口不够可以通过修改内核参数修改临时端口范围       /proc/sys/net/ipv4/ip_local_port_range:定义两个

OSI七层与TCP/IP五层网络架构详解

OSI和TCP/IP是很基础但又非常重要的网络基础知识,理解得透彻对运维工程师来说非常有帮助. (1)OSI七层模型 OSI中的层 功能 TCP/IP协议族 应用层 文件传输,电子邮件,文件服务,虚拟终端 TFTP,HTTP,SNMP,FTP,SMTP,DNS,Telnet 表示层 数据格式化,代码转换,数据加密 没有协议 会话层 解除或建立与别的接点的联系 没有协议 传输层 提供端对端的接口 TCP,UDP 网络层 为数据包选择路由 IP,ICMP,RIP,OSPF,BGP,IGMP 数据链路

TCP/IP中TIME_WAIT状态详解

TIME_WAIT状态原理: 通信双方建立连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个ACK确认,然后就会进入TIME_WAIT状态,再停留2MSL,就会进入CLOSED状态. 接下来我们看一张图,来说明这一过程: 上图是TCP"四次挥手"的过程,相信你们都会很了解,下面我们来说说为什么要存在TIME_WAIT状态 TIME_WAIT状态存在的理由如下: (1)可靠地实现TCP全双工连接的终止 TCP协议在关闭连接的四次挥手中,最终的

TCP/IP数据包格式详解-包括数据链路层的头部

图中括号中的数字代表的是当前域所占的空间大小,单位是bit位. 黄色的是数据链路层的头部,一共14字节 绿色的部分是IP头部,一般是20字节 紫色部分是TCP头部,一般是20字节 最内部的是数据包内容 黄色部分:链路层 目的MAC:当前step目的主机的mac地址 源MAC:当前step的源主机的mac地址 类型:指定网络层所用的协议类型,通常是IP协议,0x0800 绿色部分:网络层,这里用的是IP包头格式 版本:记录数据报属于哪一个版本的协议,如IPv4或IPv6 首部长度:指明IP头部长度

Nagle 算法(TCP中用于拥塞控制)详解

算法适应的情况和原理 在广域网上,小分组会增加拥塞的可能性,一种简单且好用的方式是使用Negla算法. 该算法要求一个TCP连接上最多只能有一个未被确认的未完成的小分组,在该分组的确认到来之前不发送其他的小分组.相反,TCP收集这些少量的分组,并在确认到来之时以一个分组的形式发送出去.这样,就能够减少网络中小分组的数量,提高数据包的利用率. 算法优势:自适应,确认到达的越快,数据发送也就越快. 关闭算法 有时也需要关闭该算法.一个典型的例子是X窗口服务器,小消息(例如鼠标移动)不能缓存发送,因为

Linux 网络编程——TCP 和 UDP 数据报格式详解

TCP 报文格式 TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的.可靠的.基于字节流的传输层通信协议. TCP 报文段的报头有 10 个必需的字段和 1 个可选字段.报头至少为 20 字节.报头后面的数据是可选项. 1)源端口(16位) 标识发送报文的计算机端口或进程.一个 TCP 报文段必须包括源端口号,使目的主机知道应该向何处发送确认报文. 2)目的端口(16位) 标识接收报文的目的主机的端口或进程. 3) 序号(也叫序列号)(32位) 用

TCP/IP三次握手详解

原文:http://www.cnblogs.com/CBDoctor/archive/2012/10/17/2727073.html 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接. 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认: 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态: 第

TCP三次握手原理详解

TCP/IP协议不是TCP和IP这两个协议的合称,而是指因特网整个TCP/IP协议族. 从协议分层模型方面来讲,TCP/IP由四个层次组成:网络接口层.网络层.传输层.应用层. TCP协议:即传输控制协议,它提供的是一种可靠的数据流服务.当传送受差错干扰的数据,或举出网络故障,或网络负荷太重而使网际基本传输系统不能正常工作时,就需要通过其他的协议来保证通信的可靠.TCP就是这样的协议.TCP采用"带重传的肯定确认"技术来实现传输的可靠性.并使用"滑动窗口"的流量控制

第二十天 TCP 及socket通信原理、http协议及web服务、httpd核心配置详解

一.TCP及socket通信原理详解 二.http协议及web服务原理(一) 三.http协议及web服务原理(二) 四.httpd核心配置详解 1.tcp.udp是一种传输协议,实现进程地址标记,套接字是一个虚拟设备,用来表明主机上的某个进程      众所周知:0-1023:管理员才有权限使用,永久地分配给某应用使用(由IANA分配)      注册端口:1024-41951:只有一部分被注册,分配原则上非特别严格.      动态端口或私有端口:41952-65535:由内核分配临时端口,

python中的tcp示例详解

python中的tcp示例详解  目录 TCP简介 TCP介绍 TCP特点 TCP与UDP的不同点 udp通信模型 tcp客户端 tcp服务器 tcp注意点 TCP简介 TCP介绍 TCP协议,传输控制协议(英语:Transmission Control Protocol,缩写为 TCP)是一种面向连接的.可靠的.基于字节流的传输层通信协议,由IETF的RFC 793定义. TCP通信需要经过创建连接.数据传送.终止连接三个步骤. TCP通信模型中,在通信开始之前,一定要先建立相关的链接,才能发