【nginx实战】通过nginx实现http请求的keep alive长连接

一. 概述

当使用nginx作为反向代理时，为了支持长连接，需要做到：1. 从client到nginx的连接是长连接； 2. 从nginx到server的连接是长连接。

从HTTP协议的请求过程中，对于client，nginx扮演着HTTP服务器端的角色；对于服务器端（在nginx中upstream中配置的server），nginx扮演着HTTP客户端的角色。

二. nginx与client的长连接

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

1. client发送的HTTP请求要求keep alive
2. nginx设置上支持keep alive：默认情况下，nginx已经自动开启了对client连接的keep alive支持。

一般场景可以直接使用，但是对于一些比较特殊的场景，还是有必要调整个别参数。需要修改nginx的配置文件nginx.conf:

http {
   
    keepalive_timeout  120s 120s;
    keepalive_requests 10000;
}

1. keepalive_timeout指令

keepalive_timeout指令的语法：

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


1. 第一个参数设置keep-alive客户端连接在服务器端保持开启的超时值。
   值为0会禁用keep-alive客户端连接。
   默认75s一般情况下也够用，对于一些请求比较大的内部服务器通讯的场景，
   适当加大为120s或者300s。
   
2. （可选的）第二个参数在响应的header域中设置一个值“Keep-Alive: timeout=time”。
   第二个参数通常可以不用设置。

2. keepalive_requests指令

使用语法：

Syntax:	keepalive_requests number;
Default:	keepalive_requests 1000;
Context:	http, server, location;

该指令首次出现在版本0.8.0中。在版本1.19.10之前，默认值为100。

1.参数的作用
>一个TCP（keep-alive）连接上最多执行多少个HTTP请求。
>当达到这个参数设置的最大值（默认是1000）时，则nginx会强行关闭这个长连接，
>逼迫客户端不得不重新建立新的长连接。

注意：
定期关闭连接是为了释放每个连接的内存分配。
因此，设置过高的最大请求数可能导致过多的内存使用，这是不推荐的。

场景分析

这个参数往往被大多数人忽略，因为大多数情况下当QPS(每秒请求数)不是很高时，默认值100凑合够用。但是，对于一些QPS比较高（比如超过10万QPS，甚至达到30万,50万甚至更高) 的场景，默认的1000就不适用了。因为此时会频繁创建长连接。

出现频繁的关闭、创建连接：

当QPS=10万/s时，客户端每秒发送10万个请求(通常建立有多个长连接)，每个连接只能最多跑1000次请求，意味着平均每秒钟就会有100个长连接因此被nginx关闭。同样意味着为了保持QPS，客户端不得不每秒中重新新建100个连接。

大量的TIME_WAIT

如果用netstat命令看客户端机器，就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效)。因此对于QPS较高的场景，非常有必要加大这个参数，以避免出现大量连接被生成再抛弃的情况，减少TIME_WAIT。

三. 保持和server的长连接

1. location设置

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

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

location中的两个参数：

  proxy_http_version 1.1;                   
  proxy_set_header Connection "";

1. HTTP协议中对长连接的支持是从1.1版本之后才有的，因此最好通proxy_http_version指令设置为"1.1"；
2. 代表来自client的请求Connection header会被清理。清理 Connection 头可以确保代理层完全控制连接的生命周期。

场景分析

假设client和nginx之间是短连接，nginx和upstream之间可以开启长连接。这种情况下必须清理来自client请求中的Connection header，如果不清理，则会将client的header传递过来导致不能开启长连接。

2. upstream设置

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

nginx keepalive语法:

Syntax:   keepalive connections;
Default:  —
Context:  upstream

keepalive参数作用

connections参数设置每个worker进程与upstream server建立的最多空闲 的keepalive连接数量。当这个数量被突破时，最近使用最少的连接将被关闭。

特别提醒：keepalive指令不会限制一个nginx worker进程到upstream服务器连接的总数量。connections参数应该设置为一个足够小的数字来让upstream服务器来处理新进来的连接。

3. 场景分析

场景描述

有一个HTTP服务，作为upstream server接收请求，响应时间为100毫秒。如果要达到10000 QPS的性能，就需要在nginx和upstream服务器之间建立大约1000条HTTP连接。nginx为此建立连接池，然后请求过来时为每个请求分配一个连接，请求结束时回收连接放入连接池中，连接的状态也就更改为idle。

我们再假设这个upstream服务器的keepalive参数设置比较小，比如常见的10.
 

场景1：

假设请求和响应是均匀而平稳的，那么这1000条连接应该都是一放回连接池就立即被后续请求申请使用，线程池中的idle线程会非常的少，趋进于零。
我们以10毫秒为一个单位，来看连接的情况：

• 每10毫秒有100个新请求，需要100个连接
• 每10毫秒有100个请求结束，可以释放100个连接
• 如果请求和应答都均匀，则10毫秒内释放的连接刚好够用，不需要新建连接，连接池也不空闲。

场景2：

回到现实世界，请求通常不是足够的均匀和平稳，为了简化问题，我们假设应答始终都是平稳的，只是请求不平稳：

1. 假设此时10毫秒内只有50个请求。此时连接池内有50个空闲连接。注意看keepalive=10的设置，这意味着连接池中最多容许保留有10个空闲连接。因此nginx不得不将这50个空闲连接中的40个关闭，只留下10个。
2. 再下一个10个毫秒，有150个请求进来，有100个请求结束任务释放连接。150 - 100 = 50,空缺了50个连接，减掉前面连接池保留的10个空闲连接，nginx不得不新建40个新连接来满足要求。
   我们可以看到，在短短的20毫秒内，仅仅因为请求不够均匀，就导致nginx在前10毫秒判断空闲连接过多关闭了40个连接，而后10毫秒又不得不新建40个连接来弥补连接的不足。

场景3：

假设请求是均匀的，而应答不再均匀，前10毫秒只有50个请求结束，后10毫秒有150个：

1. 前10毫秒，进来100个请求，结束50个请求，导致连接不够用，nginx为此新建50个连接
2. 后10毫秒，进来100个请求，结束150个请求，导致空闲连接过多，ngixn为此关闭了150-10=140个空闲连接

小结

现实世界中请求往往不均匀，服务器处理请求的时间也不平稳，当qps很高时，就会在短时间内导致两种非常矛盾现象： 1. 连接不够用，造成新建连接；2. 连接空闲，造成关闭连接。从而使得总连接数出现反复震荡，不断的创建新连接和关闭连接，使得长连接的效果被大大削弱。
涉及的主要设置keepalive的最大空闲连接数。毕竟连接池中的1000个连接在频繁利用时，出现短时间内多余10个空闲连接的概率实在太高。因此为了避免出现上面的连接震荡，我们将keepalive设置为200，300，就可以非常有效的缓冲请求和应答不均匀。

keepalive参数设置方法：比如前面10000 QPS和100毫秒响应时间就可以推算出需要的长连接数量大概是1000. 然后将keepalive设置为这个长连接数量的10%到30%。
比较懒的同学，可以直接设置为keepalive=1000之类的，一般都OK的了。

参考：
https://www.jianshu.com/p/142b35998947