文章目录
- 一. 概述
- 二. nginx与client的长连接
- 1. keepalive_timeout指令
- 2. keepalive_requests指令
- 场景分析
- 三. 保持和server的长连接
- 1. location设置
- 场景分析
- 2. upstream设置
- 3. 场景分析
- 场景1:
- 场景2:
- 场景3:
一. 概述
当使用nginx作为反向代理时,为了支持长连接,需要做到:1. 从client到nginx的连接是长连接; 2. 从nginx到server的连接是长连接。
从HTTP协议的请求过程中,对于client,nginx扮演着HTTP服务器端的角色;对于服务器端(在nginx中upstream中配置的server),nginx扮演着HTTP客户端的角色。
二. nginx与client的长连接
为了在client和nginx之间保持长连接,有两个要求:
- client发送的HTTP请求要求keep alive
- nginx设置上支持keep alive:默认情况下,nginx已经自动开启了对client连接的keep alive支持。
一般场景可以直接使用,但是对于一些比较特殊的场景,还是有必要调整个别参数。需要修改nginx的配置文件nginx.conf:
http {keepalive_timeout 120s 120s;keepalive_requests 10000;
}
1. keepalive_timeout指令
keepalive_timeout指令的语法:
Syntax: keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s;
Context: http, server, location1. 第一个参数设置keep-alive客户端连接在服务器端保持开启的超时值。值为0会禁用keep-alive客户端连接。默认75s一般情况下也够用,对于一些请求比较大的内部服务器通讯的场景,适当加大为120s或者300s。2. (可选的)第二个参数在响应的header域中设置一个值“Keep-Alive: timeout=time”。第二个参数通常可以不用设置。
2. keepalive_requests指令
使用语法:
Syntax: keepalive_requests number;
Default: keepalive_requests 1000;
Context: http, server, location;该指令首次出现在版本0.8.0中。在版本1.19.10之前,默认值为100。1.参数的作用
>一个TCP(keep-alive)连接上最多执行多少个HTTP请求。
>当达到这个参数设置的最大值(默认是1000)时,则nginx会强行关闭这个长连接,
>逼迫客户端不得不重新建立新的长连接。注意:
定期关闭连接是为了释放每个连接的内存分配。
因此,设置过高的最大请求数可能导致过多的内存使用,这是不推荐的。
场景分析
这个参数往往被大多数人忽略,因为大多数情况下当QPS(每秒请求数)不是很高时,默认值100凑合够用。但是,对于一些QPS比较高(比如超过10万QPS,甚至达到30万,50万甚至更高) 的场景,默认的1000就不适用了。因为此时会频繁创建长连接。
出现频繁的关闭、创建连接:
当QPS=10万/s时,客户端每秒发送10万个请求(通常建立有多个长连接),每个连接只能最多跑1000次请求,意味着平均每秒钟就会有100个长连接因此被nginx关闭。同样意味着为了保持QPS,客户端不得不每秒中重新新建100个连接。
大量的TIME_WAIT
如果用netstat命令看客户端机器,就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效)。因此对于QPS较高的场景,非常有必要加大这个参数,以避免出现大量连接被生成再抛弃的情况,减少TIME_WAIT。
三. 保持和server的长连接
1. location设置
为了让nginx和server(upstream块中的servers)之间保持长连接,典型设置如下:
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_set_header Host $Host;proxy_set_header x-forwarded-for $remote_addr;proxy_set_header X-Real-IP $remote_addr;add_header Cache-Control no-store;add_header Pragma no-cache;proxy_http_version 1.1; // 这两个最好也设置proxy_set_header Connection "";client_max_body_size 3072k;client_body_buffer_size 128k;}}
}
location中的两个参数:
proxy_http_version 1.1; proxy_set_header Connection "";
- HTTP协议中对长连接的支持是从1.1版本之后才有的,因此最好通proxy_http_version指令设置为"1.1";
- 代表来自client的请求Connection header会被清理。清理 Connection 头可以确保代理层完全控制连接的生命周期。
场景分析
假设client和nginx之间是短连接,nginx和upstream之间可以开启长连接。这种情况下必须清理来自client请求中的Connection header,如果不清理,则会将client的header传递过来导致不能开启长连接。
2. upstream设置
upstream设置中,有个参数要特别的小心,就是这个keepalive。
nginx keepalive语法:
Syntax: keepalive connections;
Default: —
Context: upstream
keepalive参数作用
connections参数设置每个worker进程与upstream server建立的最多空闲 的keepalive连接数量。当这个数量被突破时,最近使用最少的连接将被关闭。
特别提醒:keepalive指令不会限制一个nginx worker进程到upstream服务器连接的总数量。connections参数应该设置为一个足够小的数字来让upstream服务器来处理新进来的连接。
3. 场景分析
场景描述
有一个HTTP服务,作为upstream server接收请求,响应时间为100毫秒。如果要达到10000 QPS的性能,就需要在nginx和upstream服务器之间建立大约1000条HTTP连接。nginx为此建立连接池,然后请求过来时为每个请求分配一个连接,请求结束时回收连接放入连接池中,连接的状态也就更改为idle。
我们再假设这个upstream服务器的keepalive参数设置比较小,比如常见的10.
场景1:
假设请求和响应是均匀而平稳的,那么这1000条连接应该都是一放回连接池就立即被后续请求申请使用,线程池中的idle线程会非常的少,趋进于零。
我们以10毫秒为一个单位,来看连接的情况:
- 每10毫秒有100个新请求,需要100个连接
- 每10毫秒有100个请求结束,可以释放100个连接
- 如果请求和应答都均匀,则10毫秒内释放的连接刚好够用,不需要新建连接,连接池也不空闲。
场景2:
回到现实世界,请求通常不是足够的均匀和平稳,为了简化问题,我们假设应答始终都是平稳的,只是请求不平稳:
- 假设此时10毫秒内只有50个请求。此时连接池内有50个空闲连接。注意看keepalive=10的设置,这意味着连接池中最多容许保留有10个空闲连接。因此nginx不得不将这50个空闲连接中的40个关闭,只留下10个。
- 再下一个10个毫秒,有150个请求进来,有100个请求结束任务释放连接。150 - 100 = 50,空缺了50个连接,减掉前面连接池保留的10个空闲连接,nginx不得不新建40个新连接来满足要求。
我们可以看到,在短短的20毫秒内,仅仅因为请求不够均匀,就导致nginx在前10毫秒判断空闲连接过多关闭了40个连接,而后10毫秒又不得不新建40个连接来弥补连接的不足。
场景3:
假设请求是均匀的,而应答不再均匀,前10毫秒只有50个请求结束,后10毫秒有150个:
- 前10毫秒,进来100个请求,结束50个请求,导致连接不够用,nginx为此新建50个连接
- 后10毫秒,进来100个请求,结束150个请求,导致空闲连接过多,ngixn为此关闭了150-10=140个空闲连接
小结
现实世界中请求往往不均匀,服务器处理请求的时间也不平稳,当qps很高时,就会在短时间内导致两种非常矛盾现象: 1. 连接不够用,造成新建连接;2. 连接空闲,造成关闭连接。从而使得总连接数出现反复震荡,不断的创建新连接和关闭连接,使得长连接的效果被大大削弱。
涉及的主要设置keepalive的最大空闲连接数。毕竟连接池中的1000个连接在频繁利用时,出现短时间内多余10个空闲连接的概率实在太高。因此为了避免出现上面的连接震荡,我们将keepalive设置为200,300,就可以非常有效的缓冲请求和应答不均匀。
keepalive参数设置方法:比如前面10000 QPS和100毫秒响应时间就可以推算出需要的长连接数量大概是1000. 然后将keepalive设置为这个长连接数量的10%到30%。
比较懒的同学,可以直接设置为keepalive=1000之类的,一般都OK的了。
参考:
https://www.jianshu.com/p/142b35998947