Http Keep-Alive和Tcp keepalive介绍

最新推荐文章于 2024-08-22 15:21:22 发布

洪雨

最新推荐文章于 2024-08-22 15:21:22 发布

阅读量5k

点赞数 4

分类专栏：运维文章标签： tcpip gateway nginx tomcat netty

本文链接：https://blog.csdn.net/shy871/article/details/121509606

版权

运维专栏收录该内容

8 篇文章 1 订阅

订阅专栏

Http Keep-Alive和Tcp keepalive介绍

1.TCP连接介绍
- 1.1 建立连接—三次握手
- 1.2 释放连接—四次挥手
2. KeepAlive与Keep-Alive介绍
- 2.1 Http Keep-Alive
- 2.2 Tcp KeepAlive
3.操作系统有关Keepalive参数设置
- 3.1 Linux系统
- 3.2 Windows系统
4.常用服务端配置Keepalive参数
5.参考资料

参与项目中使用springcloud gateway，并结合nacos，做网关实现路由转发以及负载均衡的功能。项目运行一段时间后，出现springcloud gateway服务的TCP连接过多未释放的问题，针对此问题，查阅相关资料，汇总TCP连接、Http Keep-Alive和Tcp Keepalive的基础知识，并结合操作系统windows和linux对keepalive参数的设置问题，最后落到部分常见的应用服务对keepalive参数的配置上，并一次为基础，实践调整springcloud gateway设置keepalive参数并进行了验证有效，其他有关操作系统以及Nginx与Tomcat的设置问题，尚需后续实践过程中进行验证。于此进行记录，以便后续继续研究与验证，也为后来者提供参考借鉴，文中不免疏漏之处，望读者予以指正，不胜感激！

1.TCP连接介绍

为实现数据的可靠传输，TCP要在应用进程间建立传输连接。它是在两个传输用户之间建立一种逻辑联系，使得通信双方都确认对方为自己的传输连接端点。

1.1 建立连接—三次握手

建立连接前，服务器端首先被动打开其熟知的端口，对端口进行侦听。当客户端要和服务器端建立连接时，发起一个主动打开端口的请求（该端口一般为临时端口）；然后进入三次握手的过程。
在这里插入图片描述
第一次握手：建立连接时，客户端发送SYN包(seq=x)到服务器，并进入 SYN_SEND 状态，等待服务器确认；

第二次握手：服务器收到SYN包，必须确认客户的 SYN（ack=x+1），同时自己也发送一个 SYN 包（seq=y），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；

第三次握手：客户端收到服务器的 SYN＋ACK 包，向服务器发送确认包 ACK(ack=y+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。

1.2 释放连接—四次挥手

在这里插入图片描述
1.第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

2.第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

3.第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

4.第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1， Server进入CLOSED状态，完成四次挥手。
此时TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，Client才进入到连接关闭状态。

说明：
2MSL即两倍的MSL，TCP的TIME_WAIT状态也称为2MSL等待状态，当TCP的一端发起主动关闭，在发出最后一个ACK包后,即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置 SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。

如果有大量的连接，每次在连接、关闭时都要三次握手，四次挥手，会很明显会造成性能低下。

2. KeepAlive与Keep-Alive介绍

TCP的KeepAlive和HTTP的Keep-Alive是完全不同的概念，不能混为一谈。实际上HTTP的KeepAlive写法是Keep-Alive，跟TCP的KeepAlive写法上也有不同。

2.1 Http Keep-Alive

Http协议采用“请求-应答”模式，当使用普通模式，即非Keep-Alive模式时，每个请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接；当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

http1.0中默认是关闭的，需要在http头加入”Connection: Keep-Alive”，才能启用Keep-Alive；
http 1.1中默认启用Keep-Alive，如果加入”Connection: close “才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep- Alive连接就看服务器设置情况。

开启Keep-Alive的优缺点：
优点：Keep-Alive模式更加高效，因为避免了连接建立和释放的开销。
缺点：长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。

2.2 Tcp KeepAlive

连接建立之后，如果客户端一直不发送数据，或者隔很长时间才发送一次数据，当连接很久没有数据报文传输时如何去确定对方还在线，到底是掉线了还是确实没有数据传输，连接还需不需要保持，这种情况在TCP协议设计中是需要考虑到的。
TCP协议通过一种巧妙的方式去解决这个问题，当超过一段时间之后，TCP自动发送一个数据为空的报文（侦测包）给对方，如果对方回应了这个报文，说明对方还在线，连接可以继续保持，如果对方没有报文返回，并且重试了多次之后则认为链接丢失，没有必要保持连接。

tcp KeepAlive是TCP的一种检测TCP连接状况的保鲜机制。tcp KeepAlive保鲜定时器，支持三个系统内核配置参数：
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 1800
KeepAlive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置（双方没有任何数据流发送往来）了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分钟足够了。

3.操作系统有关Keepalive参数设置

3.1 Linux系统

tcp_keepalive_time 7200
// 距离上次传送数据多少时间未收到新报文判断为开始检测，单位秒，默认7200s(没必要频繁，浪费资源)。
tcp_keepalive_intvl 75
// 检测开始每多少时间发送心跳包，单位秒，默认75s。
tcp_keepalive_probes 9
// 发送几次心跳包对方未响应则close连接，默认9次。
可通过对下列对应的配置文件进行修改参数：
/proc/sys/net/ipv4/tcp_keepalive_time
/proc/sys/net/ipv4/tcp_keepalive_intvl
/proc/sys/net/ipv4/tcp_keepalive_probes

3.2 Windows系统

KeepAliveTime
KeepAliveTime的值控制系统尝试验证空闲连接是否仍然完好的频率。如果该连接在一段时间内没有活动，那么系统会发送保持连接的信号，如果网络正常并且接收方是活动的，它就会响应。如果需要对丢失接收方的情况敏感，也就是说需要更快地发现是否丢失了接收方，请考虑减小该值。而如果长期不活动的空闲连接的出现次数较多，但丢失接收方的情况出现较少，那么可能需要增大该值以减少开销。
缺省情况下，如果空闲连接在7200000毫秒（2小时）内没有活动，系统就会发送保持连接的消息。通常建议把该值设为1800000毫秒，从而丢失的连接会在30分钟内被检测到。具体操作：
浏览至HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters注册表子键，在Parameters子键下创建或修改名为KeepAliveTime的REG_DWORD值，为该值设置适当的毫秒数。
KeepAliveInterval
KeepAliveInterval的值表示未收到另一方对“保持连接”信号的响应时，系统重复发送“保持连接”信号的频率。在无任何响应的情况下，连续发送“保持连接”信号的次数超过TcpMaxDataRetransmissions（下文将介绍）的值时，将放弃该连接。如果网络环境较差，允许较长的响应时间，则考虑增大该值以减少开销；如果需要尽快验证是否已丢失接收方，则考虑减小该值或TcpMaxDataRetransmissions值。
缺省情况下，在未收到响应而重新发送“保持连接”的信号之前，系统会等待1000毫秒（1秒），可以根据具体需求修改，具体操作：
浏览至HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters注册表子键，在Parameters子键下创建或修改名为KeepAliveInterval的REG_DWORD值，为该值设置适当的毫秒数。

4.常用服务端配置Keepalive参数

4.1 Nginx设置Keepalive

当使用nginx作为反向代理时，为了支持长连接，需要做到两点：

从client到nginx的连接是长连接
从nginx到server的连接是长连接

4.1.1 从 Client 到 Nginx 的连接是长连接

http {
    # 客户端连接的超时时间, 为 0 时禁用长连接。 tcp连接在传送完最后一个响应后，还需要hold住 keepalive_timeout秒后仍没有新的http请求，才开始关闭这个连接
    keepalive_timeout 120s;
    # 在一个长连接上可以服务的最大请求数目, 当达到最大请求数目且所有已有请求结束后, 连接被关闭, 默认为 100, 即每个连接的最大请求数
    keepalive_request 10000;
  }

keepalive_requests：参数的真实含义，是指一个keepalive建立之后，nginx就会为这个连接设置一个计数器，记录这个keep alive的长连接上已经接收并处理的客户端请求的数量。如果达到这个参数设置的最大值时，则nginx会强行关闭这个长连接，逼迫客户端不得不重新建立新的长连接。
大多数情况下当QPS(每秒请求数)不是很高时，默认值100凑合够用。但是，对于一些QPS比较高（比如超过10000QPS，甚至达到30000,50000甚至更高) 的场景，默认的100就显得太低。
简单计算一下，QPS=10000时，客户端每秒发送10000个请求(通常建立有多个长连接)，每个连接只能最多跑100次请求，意味着平均每秒钟就会有100个长连接因此被nginx关闭。同样意味着为了保持QPS，客户端不得不每秒中重新新建100个连接。因此，就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效)。因此对于QPS较高的场景，非常有必要加大这个参数，以避免出现大量连接被生成再抛弃的情况，减少TIME_WAIT。

4.1.2 从 Nginx 到 Server(upstream) 的长连接

为了让nginx和后端server（nginx称为upstream）之间保持长连接，典型设置如下：（默认nginx访问后端都是用的短连接(HTTP1.0)，一个请求来了，Nginx 新开一个端口和后端建立连接，后端执行完毕后主动关闭该链接）

http {
    upstream  BACKEND {
        server   192.168.0.1：8080  weight=1 max_fails=2 fail_timeout=30s;
        server   192.168.0.2：8080  weight=1 max_fails=2 fail_timeout=30s;
        keepalive 300;        // 这个很重要！
    }
server {
        listen 8080 default_server;
        server_name "";
        location /  {
            proxy_pass http://BACKEND;
            proxy_http_version 1.1;         // 这两个最好也设置
            proxy_set_header Connection "";
        }
    }
}

此处keepalive的含义不是开启、关闭长连接的开关；也不是用来设置超时的timeout；更不是设置长连接池最大连接数。官方解释：
The connections parameter sets the maximum number of idle keepalive connections to upstream servers connections（设置到upstream服务器的空闲keepalive连接的最大数量）
When this number is exceeded, the least recently used connections are closed. （当这个数量被突破时，最近使用最少的连接将被关闭）
It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open.（特别提醒：keepalive指令不会限制一个nginx worker进程到upstream服务器连接的总数量）

keepalive: 这个参数是 nginx 连接后端的连接池中的最大空闲连接数, 比如: 设置为 300; 如果 nginx 为了满足请求的 qps; 创建了 1000 个连接的连接池, 这个时候只有 500 个请求过来, 那么 1000- 500 = 500; 那么就会多出 500 个空闲的连接, 那么 500 > 300; 那么 nginx 就会根据这个配置; 断开 200 个请求连接; 那么这个时候就只有 800 个连接的连接池, 如果下次过来了 1000 个请求, 那么 nginx 又会开始创建连接; 所有这个数值的配置要小心配置

4.1.3 Nginx出现大量TIME_WAIT的情况

1）导致 nginx端出现大量TIME_WAIT的情况有两种：
keepalive_requests设置比较小，高并发下超过此值后nginx会强制关闭和客户端保持的keepalive长连接；（主动关闭连接后导致nginx出现TIME_WAIT）
keepalive设置的比较小（空闲数太小），导致高并发下nginx会频繁出现连接数震荡（超过该值会关闭连接），不停的关闭、开启和后端server保持的keepalive长连接；

2）导致后端server端出现大量TIME_WAIT的情况：
nginx没有打开和后端的长连接，即：没有设置proxy_http_version 1.1;和proxy_set_header Connection “”;从而导致后端server每次关闭连接，高并发下就会出现server端出现大量TIME_WAIT

4.2 Tomcat设置Keepalive

浏览器在请求的头部添加 Connection:Keep-Alive，以此告诉服务器“我支持长连接，你支持的话就和我建立长连接吧”，而倘若服务器的确支持长连接，那么就在响应头部添加“Connection:Keep-Alive”，从而告诉浏览器“我的确也支持，那我们建立长连接吧”。服务器还可以通过 Keep-Alive:timeout=10, max=100 的头部告诉浏览器“我希望 10 秒算超时时间，最长不能超过 100 秒”。
在 Tomcat 里是允许配置长连接的，配置 conf/server.xml 文件，配置 Connector 节点，该节点负责控制浏览器与 Tomcat 的连接，其中与长连接直接相关的有两个属性，它们分别是：keepAliveTimeout，它表示在 Connector 关闭连接前，Connector 为另外一个请求 Keep Alive 所等待的微妙数，默认值和 connectionTimeout 一样；另一个是 maxKeepAliveRequests，它表示 HTTP/1.0 Keep Alive 和 HTTP/1.1 Keep Alive / Pipeline 的最大请求数目，如果设置为 1，将会禁用掉 Keep Alive 和 Pipeline，如果设置为小于 0 的数，Keep Alive 的最大请求数将没有限制。也就是说在 Tomcat 里，默认长连接是打开的，当我们想关闭长连接时，只要将 maxKeepAliveRequests 设置为 1 就可以。

Tomcat在server.xml 中的Connector 元素中：
keepAliveTimeout：单位是milliseconds，表示在下次请求过来之前，tomcat保持该连接多久。这就是说假如客户端不断有请求过来，且未超过过期时间，则该连接将一直保持。

maxKeepAliveRequests：最大长连接个数（1表示禁用，-1表示不限制个数，默认100个。一般设置在100~200之间），表示该连接最大支持的请求数。超过该请求数的连接也将被关闭（此时就会返回一个Connection: close头给客户端）。

4.3 Netty设置Keepalive

4.3.1 SO_KEEPALIVE

Socket参数。是否启用心跳保活机制，即连接保活。启用该功能时，TCP会主动探测空闲连接的有效性。

在双方TCP套接字建立连接后（即都进入ESTABLISHED状态）并且在两个小时左右（默认的心跳间隔是7200s即2小时）上层没有任何数据传输的情况下，这套机制才会被激活。

默认值：
Netty默认关闭该功能，即值为：false 。

代码设置：

bootstrap.childOption(ChannelOption.SO_KEEPALIVE, true);

说明：
如果一方已经关闭或异常终止连接，而另一方却不知道，我们将这样的TCP连接称为半打开的。TCP通过保活定时器(KeepAlive)来检测半打开连接。
在高并发的网络服务器中，经常会出现漏掉socket的情况，对应的结果有一种情况就是出现大量的CLOSE_WAIT状态的连接。这个时候，可以通过设置KEEPALIVE选项来解决这个问题。
设置SO_KEEPALIVE选项来开启KEEPALIVE，然后通过TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT设置keepalive的开始时间、间隔、次数等参数。
当然，也可以通过设置/proc/sys/net/ipv4/tcp_keepalive_time、tcp_keepalive_intvl和tcp_keepalive_probes等内核参数来达到目的，但是这样的话，会影响所有的socket。

4.3.2 SpringCloud Gateway设置Keepalive

@Configuration
public class NettyConfig {
    @Bean
    public NettyServerCustomizer nettyServerCustomizer() {
        return httpServer -> httpServer.tcpConfiguration(tcpServer -> {
            tcpServer= tcpServer.option(ChannelOption.SO_KEEPALIVE, true);
            tcpServer = tcpServer.doOnBind(serverBootstrap ->
                    BootstrapHandlers.updateConfiguration(serverBootstrap, "channelIdle", (connectionObserver, channel) -> {
                        ChannelPipeline pipeline = channel.pipeline();
                        pipeline.addLast(new ReadTimeoutHandler(5, TimeUnit.MINUTES));
                    }));
            return tcpServer;
        });
    }
}

5.参考资料

[1] https://www.cnblogs.com/xpfeia/p/10885726.html
[2] https://zhuanlan.zhihu.com/p/51560184
[3] https://blog.csdn.net/tennysonsky/article/details/45622395
[4] http://www.manongjc.com/detail/24-rcqeqovotuetucc.html
[5] https://www.jianshu.com/p/394a7883a139
[6] https://blog.csdn.net/bluetjs/article/details/80966148
[7] http://www.ttlsa.com/windows/parameter-optimization-of-tcp-under-windows-system/
[8] https://www.cnblogs.com/sunsky303/p/10648861.html