Detailed explanation of Tcp Keepalive and HTTP Keepalive

TCP Keepalive

    The origin of Tcp keepalive The
          two parties establish an interactive connection, but there is not always data interaction. Some connections will actively release the connection after the data exchange is completed, and some will not. In a long period of time without data interaction, the
          two parties interact . There may be various accidents such as power failure, crash, abnormal restart, etc. When these accidents occur, these TCP connections will not be released normally in the future. Then, the other party of the connection does not know the situation of the other end, and
          it will always maintain the connection. , long-term accumulation will lead to a lot of half-open connections, resulting in the consumption and waste of end system resources. In order to solve this problem, the TCP keep-alive message can be used at the transport layer to achieve.

    The role of Tcp Keepalive

        1. Detect whether the connected peer is alive
            in the process of application interaction. There may be the following situations:
            (1) The client or server unexpectedly loses power, crashes, crashes, and restarts.
            (2) The intermediate network has been interrupted, and the client and server do not know.

        The keep-alive detection function can be used to detect the unexpected situation of the opposite end, so as to ensure that the half-opened TCP connection can be released when an accident occurs.

        2. Prevent the intermediate device from deleting the connection-related connection table due to timeout. The
            intermediate device, such as a firewall, will establish a related connection information table for the data packets passing through it, and set a timer for the timeout period. If it exceeds the predetermined time, If a connection does not have any packet interaction, the
            intermediate device will delete the connection information from the table. After deletion, when another application packet comes, the intermediate device will discard the packet, resulting in an abnormal application. The process is roughly as follows:

            

 

          This situation is very common in application environments with firewalls, which will have a great impact on some applications (such as databases) that have no data interaction for a long time but need to maintain connections for a long time. In order to solve this problem, the
          application itself Or TCP can maintain the information of the connection in the intermediate device through the keep-alive message, (it can also be solved by enabling the long connection attribute on the intermediate device or increasing the release time of the connection table,
          but this impact may be greater and there is a chance I will describe this in detail, so I won't talk about it here).

  Common application failure scenarios:

              In a financial application, a large amount of form data needs to be filled in on the client side. After the client side establishes a TCP connection with the server side, the client terminal user will spend several minutes or even dozens of minutes filling in the form-related information, and the
            terminal user finally fills in the form . After the required information, click the "Submit" button. As a result, at this time, since the intermediate device has already deleted the TCP connection from the connection table,
            it will directly discard the message or send an RST message to the client, resulting in an application failure. , which will cause all the work of the client end user to be redone, which will bring great inconvenience and loss to the user. 

  TCP keep-alive message interaction process   

            

    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连接也相应更少了。

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326375896&siteId=291194637