支持keep alive长连接【转】

zzhongcy

已于 2022-08-05 15:40:52 修改

阅读量2.1k

点赞数 1

分类专栏： Nginx 文章标签： nginx 服务器运维

于 2022-07-28 17:25:01 首次发布

原文链接：https://skyao.gitbooks.io/learning-nginx/content/documentation/keep_alive.html

版权

Nginx 专栏收录该内容

87 篇文章 35 订阅

订阅专栏

转自：长连接 · Nginx 学习笔记

当使用nginx作为反向代理时，为了支持长连接，需要做到两点：

从client到nginx的连接是长连接
从nginx到server的连接是长连接

从HTTP协议的角度看，nginx在这个过程中，对于客户端它扮演着HTTP服务器端的角色。而对于真正的服务器端（在nginx的术语中称为upstream）nginx又扮演着HTTP客户端的角色。

1 保持和client的长连接

为了在client和nginx之间保持上连接，有两个要求：

client发送的HTTP请求要求keep alive
nginx设置上支持keep alive

1.1 HTTP配置

默认情况下，nginx已经自动开启了对client连接的keep alive支持。

一般场景可以直接使用，但是对于一些比较特殊的场景，还是有必要调整个别参数。

需要修改nginx的配置文件(在nginx安装目录下的conf/nginx.conf):

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

1.2 keepalive_timeout指令

keepalive_timeout指令的语法：

Syntax:    keepalive_timeout timeout [header_timeout];
Default:    keepalive_timeout 75s;
Context:    http, server, location

第一个参数设置keep-alive客户端连接在服务器端保持开启的超时值。值为0会禁用keep-alive客户端连接。可选的第二个参数在响应的header域中设置一个值“Keep-Alive: timeout=time”。这两个参数可以不一样。

注：默认75s一般情况下也够用，对于一些请求比较大的内部服务器通讯的场景，适当加大为120s或者300s。第二个参数通常可以不用设置。

1.3 keepalive_requests指令

keepalive_requests指令用于设置一个keep-alive连接上可以服务的请求的最大数量。当最大请求数量达到时，连接被关闭。默认是100。

这个参数的真实含义，是指一个keep alive建立之后，nginx就会为这个连接设置一个计数器，记录这个keep alive的长连接上已经接收并处理的客户端请求的数量。如果达到这个参数设置的最大值时，则nginx会强行关闭这个长连接，逼迫客户端不得不重新建立新的长连接。

这个参数往往被大多数人忽略，因为大多数情况下当QPS(每秒请求数)不是很高时，默认值100凑合够用。但是，对于一些QPS比较高（比如超过10000QPS，甚至达到30000,50000甚至更高) 的场景，默认的100就显得太低。

简单计算一下，QPS=10000时，客户端每秒发送10000个请求(通常建立有多个长连接)，每个连接只能最多跑100次请求，意味着平均每秒钟就会有100个长连接因此被nginx关闭。同样意味着为了保持QPS，客户端不得不每秒中重新新建100个连接。因此，如果用netstat命令看客户端机器，就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效)。

因此对于QPS较高的场景，非常有必要加大这个参数，以避免出现大量连接被生成再抛弃的情况，减少TIME_WAIT。

1.4 保持和server的长连接

为了让nginx和server（nginx称为upstream）之间保持长连接，典型设置如下：

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;
        }
    }
}

2. upstream设置

upstream设置中，有个参数要特别的小心，就是这个keepalive。

大多数未仔细研读过nginx的同学通常都会误解这个参数，有些人理解为这里的keepalive是设置是否打开长连接，以为应该设置为on/off。有些人会被前面的keepalive_timeout误导，以为这里也是设置keepalive的timeout。

但是实际上这个keepalive参数的含义非常的奇特，请小心看nginx文档中的说明:

Syntax:    keepalive connections;
Default:    —
Context:    upstream

Activates the cache for connections to upstream servers. 激活到upstream服务器的连接缓存。

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed. connections 参数设置每个worker进程在缓冲中保持的到upstream服务器的空闲keepalive连接的最大数量.当这个数量被突破时，最近使用最少的连接将被关闭。

It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open. The connections parameter should be set to a number small enough to let upstream servers process new incoming connections as well. 特别提醒：keepalive指令不会限制一个nginx worker进程到upstream服务器连接的总数量。connections参数应该设置为一个足够小的数字来让upstream服务器来处理新进来的连接。

在这里可以看到，前面的几种猜测可以确认是错误的了：

keepalive不是on/off之类的开关
keepalive不是timeout，不是用来设置超时值

很多人读到这里的文档之后，会产生另外一个误解：认为这个参数是设置到upstream服务器的长连接的数量，分歧在于是最大连接数还是最小连接数，不得不说这也是一个挺逗的分歧......

回到nginx的文档，请特别注意这句话，至关重要：

The connections parameter sets the maximum number of idle keepalive connections to upstream servers connections参数设置到upstream服务器的空闲keepalive连接的最大数量

请仔细体会这个"idle"的概念，何为idle。大多数人之所以误解为是到upstream服务器的最大长连接数，一般都是因为看到了文档中的这句话，而漏看了这个"idle"一词。

然后继续看文档后面另外一句话：

When this number is exceeded, the least recently used connections are closed. 当这个数量被突破时，最近使用最少的连接将被关闭。

这句话更是大大强化了前面关于keepalive设置的是最大长连接数的误解：如果连接数超过keepalive的限制，就关闭连接。这不是赤裸裸的最大连接数么？

但是nginx的文档立马给出了指示，否定了最大连接数的可能：

It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open. 特别提醒：keepalive指令不会限制一个nginx worker进程到upstream服务器连接的总数量。

3. keepalive参数的理解

要真正理解keepalive参数的含义，请回到文档中的这句：

The connections parameter sets the maximum number of idle keepalive connections to upstream servers connections参数设置到upstream服务器的空闲keepalive连接的最大数量

请注意空闲keepalive连接的最大数量中空闲这个关键字。

upstream中，有一个参数特别的重要，就是keepalive。这个参数和之前http里面的 keepalive_requests 不一样。这个参数的含义是，连接池里面最大的空闲连接数量。

不理解？没关系，我们来举个例子：

3.1 场景：

有一个HTTP服务，作为upstream服务器接收请求，响应时间为100毫秒。要求性能达到10000 QPS，我们需要在nginx与upstream服务器之间建立大概1000条HTTP请求。（1000/0.1s=10000）

3.1.1 最优情况：

假设请求非常的均匀平稳，每一个请求都是100ms，请求结束会被马上放入连接池并置为idle（空闲）状态。

我们以0.1s为单位：

1. 我们现在keepalive的值设置为10，每0.1s钟有1000个连接。

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

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

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

3.1.2 第一种情况：应答非常平稳，但是请求不平稳的时候

1.第0.3s的时候，我们只有500个请求收到，有500个请求因为网络延迟等原因没有进来。这个时候，Nginx检测到连接池中有500个idle状态的连接，就直接关闭了（500-10）个连接。

2.第0.4s的时候，我们收到了1500个请求，但是现在池里面只有（500+10）个连接，所以Nginx不得不重新建立了（1500-510）个连接。如果在第4步的时候，没有关闭那490个连接的话，只需要重新建立500个连接。

3.1.3 第二种情况：请求非常平稳，但是应答不平稳的时候

1. 第0.3s的时候，我们一共有1500个请求收到。但是池里面只有1000个连接，这个时候，Nginx又创建了500个连接，一共1500个连接。

2.第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过来的http header，因为即使是client和nginx之间是短连接，nginx和upstream之间也是可以开启长连接的。这种情况下必须清理来自client请求中的"Connection" header。

4.另外一种高级方式

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。

5【补充】

NGINX支持WebSocket。对于NGINX将升级请求从客户端发送到后台服务器，必须明确设置Upgrade和Connection标题。这也算是上面情况所非常常用的场景。HTTP的Upgrade协议头机制用于将连接从HTTP连接升级到WebSocket连接，Upgrade机制使用了Upgrade协议头和Connection协议头。为了让Nginx可以将来自客户端的Upgrade请求发送到后端服务器，Upgrade和Connection的头信息必须被显式的设置。

6【注意】

在nginx的配置文件中，如果当前模块中没有proxy_set_header的设置，则会从上级别继承配置。继承顺序为：http, server, location。如果在下一层使用proxy_set_header修改了header的值，则所有的header值都可能会发生变化，之前继承的所有配置将会被丢弃。所以，尽量在同一个地方进行proxy_set_header，否则可能会有别的问题