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