nginx反向代理时保持长链接

·【场景描述】

HTTP1.1以后，HTTP协议支持持久链接，也就是长链接，优势在于在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟。

若是咱们使用了nginx去做为反向代理或者负载均衡，从客户端过来的长链接请求就会被转换成短链接发送给服务器端。

为了支持长链接，咱们须要在nginx服务器上作一些配置。

   

·【要求】

使用nginx时，想要作到长链接，咱们必须作到如下两点：

1. 从client到nginx是长链接
2. 从nginx到server是长链接

   

对于客户端而言，nginx其实扮演着server的角色，反之，之于server，nginx就是一个client。

   

·【保持和 Client 的长链接】

咱们要想作到Client与Nginx之间保持长链接，须要：

1. Client发送过来的请求携带"keep-alive"header。
2. Nginx设置支持keep-alive

   

【HTTP配置】

默认状况下，nginx已经开启了对client链接的 keepalive 支持。对于特殊场景，能够调整相关参数。

http { keepalive_timeout 120s;        #客户端连接超时时间。为0的时候禁用长链接。 keepalive_requests 10000;    #在一个长链接上能够服务的最大请求数目。                                                   #当达到最大请求数目且全部已有请求结束后，链接被关闭。                                                   #默认值为100 }

   

大多数状况下，keepalive_requests = 100也够用，可是对于 QPS 较高的场景，很是有必要加大这个参数，以免出现大量链接被生成再抛弃的状况，减小TIME_WAIT。
 

QPS=10000 时，客户端每秒发送 10000 个请求 (一般创建有多个长链接)，每一个链接只能最多跑 100 次请求，意味着平均每秒钟就会有 100 个长链接所以被 nginx 关闭。

一样意味着为了保持 QPS，客户端不得不每秒中从新新建 100 个链接。

   

所以，若是用netstat命令看客户端机器，就会发现有大量的TIME_WAIT的socket链接 (即便此时keep alive已经在 Client 和 NGINX 之间生效)。

   

·【保持和Server的长链接】

想让Nginx和Server之间维持长链接，最朴素的设置以下：

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;                         # 设置http版本为1.1 proxy_set_header Connection "";      # 设置Connection为长链接（默认为no）} } } }

   

【upstream配置】

upstream中，有一个参数特别的重要，就是keepalive。

这个参数和以前http里面的 keepalive_timeout 不同。

这个参数的含义是，链接池里面最大的空闲链接数量。

   

不理解？不要紧，咱们来举个例子：

场景：

有一个HTTP服务，做为upstream服务器接收请求，响应时间为100毫秒。

要求性能达到10000 QPS，咱们须要在nginx与upstream服务器之间创建大概1000条HTTP请求。（1000/0.1s=10000）

   

最优状况：

假设请求很是的均匀平稳，每个请求都是100ms，请求结束会被立刻放入链接池并置为idle（空闲）状态。

咱们以0.1s为单位：

1. 咱们如今keepalive的值设置为10，每0.1s钟有1000个链接

2. 第0.1s的时候，咱们一共有1000个请求收到并释放

3. 第0.2s的时候，咱们又来了1000个请求，在0.2s结束的时候释放

   

请求和应答都比较均匀，0.1s释放的链接正好够用，不须要创建新链接，且链接池中没有idle状态的链接。

   

第一种状况：

应答很是平稳，可是请求不平稳的时候

4. 第0.3s的时候，咱们只有500个请求收到，有500个请求由于网络延迟等缘由没有进来

这个时候，Nginx检测到链接池中有500个idle状态的链接，就直接关闭了（500-10）个链接

5. 第0.4s的时候，咱们收到了1500个请求，可是如今池里面只有（500+10）个链接，因此Nginx不得不从新创建了（1500-510）个链接。

若是在第4步的时候，没有关闭那490个链接的话，只须要从新创建500个链接。

   

第二种状况：

请求很是平稳，可是应答不平稳的时候

4. 第0.3s的时候，咱们一共有1500个请求收到

可是池里面只有1000个链接，这个时候，Nginx又建立了500个链接，一共1500个链接

5. 第0.3s的时候，第0.3s的链接所有被释放，咱们收到了500个请求

Nginx检测到池里面有1000个idle状态的链接，因此不得不释放了（1000-10）个链接

   

形成链接数量反复震荡的一个推手，就是这个keepalive 这个最大空闲链接数。

上面的两种状况说的都是 keepalive 设置的不合理致使Nginx有屡次释放与建立链接的过程，形成资源浪费。

   

keepalive 这个参数设置必定要当心，尤为是对于 QPS 要求比较高或者网络环境不稳定的场景，通常根据 QPS 值和 平均响应时间能大体推算出须要的长链接数量。

而后将keepalive设置为长链接数量的10%到30%。

   

【location配置】

http { server { location / { proxy_pass http://backend; proxy_http_version 1.1;                         # 设置http版本为1.1 proxy_set_header Connection "";      # 设置Connection为长链接（默认为no） } } }

HTTP 协议中对长链接的支持是从 1.1 版本以后才有的，所以最好经过 proxy_http_version 指令设置为 1.1。

HTTP1.0不支持keepalive特性，当没有使用HTTP1.1的时候，后端服务会返回101错误，而后断开链接。

   

而 "Connection" header 能够选择被清理，这样即使是 Client 和 Nginx 之间是短链接，Nginx 和 upstream 之间也是能够开启长链接的。

   

【另一种高级方式】

http { map $http_upgrade $connection_upgrade { default upgrade; '' close; }    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_connect_timeout 15;       #与upstream server的链接超时时间（没有单位，最大不能够超过75s） proxy_read_timeout 60s;           #nginx会等待多长时间来得到请求的响应 proxy_send_timeout 12s;           #发送请求给upstream服务器的超时时间    proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } } }

   

http里面的map的做用是：

让转发到代理服务器的 "Connection" 头字段的值，取决于客户端请求头的 "Upgrade" 字段值。

若是 $http_upgrade没有匹配，那 "Connection" 头字段的值会是upgrade。

若是 $http_upgrade为空字符串的话，那 "Connection" 头字段的值会是 close。

   

【补充】

NGINX支持WebSocket。

对于NGINX将升级请求从客户端发送到后台服务器，必须明确设置Upgrade和Connection标题。

这也算是上面状况所很是经常使用的场景。

HTTP的Upgrade协议头机制用于将链接从HTTP链接升级到WebSocket链接，Upgrade机制使用了Upgrade协议头和Connection协议头。

为了让Nginx能够将来自客户端的Upgrade请求发送到后端服务器，Upgrade和Connection的头信息必须被显式的设置。

   

【注意】

在nginx的配置文件中，若是当前模块中没有proxy_set_header的设置，则会从上级别继承配置。

继承顺序为：http, server, location。

   

若是在下一层使用proxy_set_header修改了header的值，则全部的header值均可能会发生变化，以前继承的全部配置将会被丢弃。

因此，尽可能在同一个地方进行proxy_set_header，不然可能会有别的问题。

   

·【参考】

Nginx中文官方文档： http://www.nginx.cn/doc/

测试参考文档： https://www.lijiaocn.com/问题/2019/05/08/nginx-ingress-keep-alive-not-work.html

keep-alive参考文档： https://wglee.org/2018/12/02/nginx-keepalive/