长连接基础：先了解为什么要保持长连接，http的长连接历史。
长连接实战：接着如何分析如何通过nginx设置长连接。如果不恰当的设置长连接，会出现什么问题。

一. http的长连接历史

HTTP是属于应用层（七层）的协议，传输层（四层）使用的是TCP协议，所以HTTP的长连接和短连接，其本质就是TCP的长连接和短连接；
HTTP是一个无状态的面向连接的协议，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态，但无状态不代表HTTP不能保持TCP连接；
TCP建立连接和断开连接是需要三握四挥的，也就说HTTP连接的建立与断开是消耗资源的。

接下来正式了解下http长短连接模型

1. HTTP短连接模型

短连接的基本逻辑与特点
HTTP 短连接模型是最早期的模型，也是 HTTP/1.0 的默认模型。在早期，HTTP 使用一个简单的模型来处理这样的连接。这些连接的生命周期是短暂的：每发起一个请求时都先有一次TCP握手，然后创建一个新连接，并在收到应答时立即关闭。

持续的短连接是耗时、耗费资源的
实际上，TCP 协议握手本身就是耗费时间的，所以 TCP 可以保持更多的热连接来适应负载。短连接破坏了 TCP 具备的能力，新的冷连接降低了其性能。

长短连接的设置

在 HTTP/1.0 中如果没有指定 Connection协议头，或者是值被设置为 close就会启用短连接模型，要在 HTTP/1.0 中启用长连接模型，需要在协议头中指定Connection: Keep-Alive ，不过并不建议这样操作。

而在 HTTP/1.1 中，默认使用长连接模型，只有当 Connection被设置为 close 时才会用到这个短连接模型，协议头都不用再去声明它(但是一般还是会把它加上，以防万一因为某种原因要退回到 HTTP/1.0 )。

 

2. HTTP长连接模型

长连接的趋势
后来，网页需要请求的资源越来越多，短连接模型显然已经十分吃力了。因为短连接有两个比较大的问题：创建新连接耗费的时间尤为明显（三次握手很耗费时间），另外 TCP 连接的性能只有在该连接被使用一段时间后(热连接)才能得到改善。因此在HTTP/1.1中引入了长连接模型。

在 HTTP/1.1 之前，长连接也被称为keep-alive 连接。
一个长连接会保持一段时间，重复用于发送一系列请求，节省了新建 TCP 连接握手的时间，还可以利用 TCP 的性能增强能力（ing）。当然这个连接也不会一直保留着：连接在空闲一段时间后会被关闭(服务器可以使用 Keep-Alive 协议头来指定一个最小的连接保持时间)。

长连接的缺点：资源占用问题
使用长连接本质上是因为当不断地三次握手建立连接所消耗的资源大于维持连接所需要的资源。

当处于空闲状态时，它还是会消耗服务器资源。如果空闲较长，可以使用非长连接，即尽快关闭那些空闲的连接，也能对性能有所提升。

二. nginx作为代理时实现HTTP长连接

当我们配置Nginx作为代理服务器的时候，想要支持HTTP长连接，需要client到Nginx和Nginx到server（nginx中upstream配置的server）都是长连接，因为此时Nginx既是client的server也是server的client。

多个HTTP请求通过复用TCP连接，会达到以下效果：

1. 减少握手次数
2. 通过减少并发连接数减少了服务器资源的消耗
3. 降低TCP拥塞控制的影响

 

1. nginx与client的长连接

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

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

 

1.1. keepalive_timeout指令

语法：用户一个HTTP请求连接完成以后，最多经过timeout时间，如果还是没有新的请求，就会关闭连接

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

 

1.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。

 

2. 保持和server的长连接

2.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.2. upstream设置

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

nginx keepalive语法:

Syntax:   keepalive connections;
Default:  —
Context:  upstream

keepalive参数作用

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

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

 

* 场景分析

场景描述

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

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

场景1

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

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

场景2

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

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

场景3

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

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

 

小结

现实世界中请求往往不均匀，服务器处理请求的时间也不平稳，当qps很高时，就会在短时间内导致两种非常矛盾现象： 1. 连接不够用，造成新建连接；2. 连接空闲，造成关闭连接。从而使得总连接数出现反复震荡，不断的创建新连接和关闭连接，使得长连接的效果被大大削弱。

keepalive参数设置方法：比如前面10000 QPS和100毫秒响应时间就可以推算出需要的长连接数量大概是1000. 然后将keepalive设置为这个长连接数量的10%到30%。

 

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