优化nginx upstream连接

场景

nginx 通常情况下都是用来当作一个反向代理，通常一个请求都需要经过 client -> nginx -> backend_server 这么几成关系。通常情况下 client -> nginx 使用的 HTTP 1.1 或者 2.0 的协议，keep-alive 复用了 TCP 的连接，减少了 TCP 频发创建和销毁带来的性能损失。但是默认情况下，nginx -> backend_server 是 HTTP 1.0 的协议，并没有复用 TCP 的连接。

开启 upstream keepalive

针对上诉场景的，我们需要使用 nginx upstream keepalive 来优化。

摘录官方文档的说明如下。该参数开启与上游服务器之间的连接池，其数值为每个nginx worker可以保持的最大连接数，默认不设置，即nginx作为客户端时keepalive未生效。

upstream http_backend {
    server 127.0.0.1:8080;
 
    keepalive 256;
}
server {
    ...
 
    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}

下图是nginx upstream keepalive长连接的实现原理。首先每个进程需要一个connection pool，里面都是长连接，多进程之间是不需要共享这个连接池的。 一旦与后端服务器建立连接，则在当前请求连接结束之后不会立即关闭连接，而是把用完的连接保存在一个keepalive connection pool里面，以后每次需要建立向后连接的时候，只需要从这个连接池里面找，如果找到合适的连接的话，就可以直接来用这个连接，不需要重新创建socket或者发起connect()。这样既省下建立连接时在握手的时间消耗，又可以避免TCP连接的slow start。如果在keepalive连接池找不到合适的连接，那就按照原来的步骤重新建立连接。

如果你的连接池的数控制在128，总共线程池内的线程数是128 * nginx worker ，但因为你要应对更多的并发请求，所以临时又加了很多的连接，但这临时的连接是短连接和长连接要看你的nginx版本，我这1.8是长连接，那他如何被收回，两地保证，一点是他会主动去释放，另一点是keepalive timeout的时间。

image