Nginx反向代理时保持长连接

共计 3933 个字符，预计需要花费 10 分钟才能阅读完成。

【场景描述】

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，否则可能会有别的问题。

：