京东大佬细说：Nginx反向代理时保持长连接，看完直呼“学到了“

前言：

• nginx反向代理，如何通过配置支持从client到server的长连接？
• 如何避免nginx线程池内线程数反复震荡导致性能不稳定的问题？

深入了解nginx，get到nginx的一些性能优化方向。除了了解如何保持长连接，也通过本案例学习到开源中间件的一些常用定位思路和优化方法。

场景描述

HTTP1.1之后，HTTP协议支持持久连接，也就是长连接，优点在于在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。如果我们使用了nginx去作为反向代理或者负载均衡，从客户端过来的长连接请求就会被转换成短连接发送给服务器端。为了支持长连接，我们需要在nginx服务器上做一些配置。

要求

到长连接，我们必须做到以下两点：

i.从client到nginx是长连接

ii.从nginx到server是长连接

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

保持和Client的长连接

我们要想做到Client与Nginx之间保持长连接，需要：

i.Client发送过来的请求携带“keep-alive”header。

ii.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连接 (即使此时keepalive已经在 Client 和 NGINX 之间生效)。

保持和Server的长连接

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

http {
   
     upstream backend {
   
     server  192.168