1. nginx 优化之 keepalive

1.1. nginx 之 tcp_nopush、tcp_nodelay、sendfile

1.1.1. TCP_NODELAY

你怎么可以强制 socket 在它的缓冲区里发送数据?
一个解决方案是 TCP 堆栈的 TCP_NODELAY 选项。这样就可以使缓冲区中的数据立即发送出去。

Nginx 的 TCP_NODELAY 选项使得在打开一个新的 socket 时增加了 TCP_NODELAY 选项。但这时会造成一种情况:
终端应用程序每产生一次操作就会发送一个包, 而典型情况下一个包会拥有一个字节的数据以及 40 个字节长的包头, 于是产生 4000%的过载, 很轻易地就能令网络发生拥塞。为了避免这种情况, TCP 堆栈实现了等待数据 0.2 秒钟, 因此操作后它不会发送一个数据包, 而是将这段时间内的数据打成一个大的包。这一机制是由 Nagle 算法保证。

Nagle 化后来成了一种标准并且立即在因特网上得以实现。它现在已经成为默认配置了, 但有些场合下把这一选项关掉也是合乎需要的。现在假设某个应用程序发出了一个请求, 希望发送小块数据。我们可以选择立即发送数据或者等待产生更多的数据然后再一次发送两种策略。
如果我们马上发送数据, 那么交互性的以及客户/服务器型的应用程序将极大地受益。如果请求立即发出那么响应时间也会快一些。以上操作可以通过设置套接字的 TCP_NODELAY = on 选项来完成, 这样就禁用了 Nagle 算法。(不需要等待 0.2s)

1.1.2. TCP_NOPUSH

在 nginx 中, tcp_nopush 配置和 tcp_nodelay “互斥”。它可以配置一次发送数据的包大小。也就是说, 它不是按时间累计 0.2 秒后发送包, 而是当包累计到一定大小后就发送。

注: 在 nginx 中, tcp_nopush 必须和 sendfile 搭配使用。

1.1.3. sendfile

现在流行的 web 服务器里面都提供 sendfile 选项用来提高服务器性能, 那到底 sendfile 是什么, 怎么影响性能的呢?
sendfile 实际上是 Linux2.0+以后的推出的一个系统调用, web 服务器可以通过调整自身的配置来决定是否利用 sendfile 这个系统调用。先来看一下不用 sendfile 的传统网络传输过程:
read(file,tmp_buf, len);
write(socket,tmp_buf, len);

硬盘 >> kernel buffer >> user buffer>> kernel socket buffer >>协议栈

1)一般来说一个网络应用是通过读硬盘数据, 然后写数据到 socket 来完成网络传输的。上面 2 行用代码解释了这一点, 不过上面 2 行简单的代码掩盖了底层的很多操作。来看看底层是怎么执行上面 2 行代码的:

1. 系统调用 read() 产生一个上下文切换: 从 user mode 切换到 kernel mode, 然后 DMA 执行拷贝, 把文件数据从硬盘读到一个 kernel buffer 里。
2. 数据从 kernel buffer 拷贝到 user buffer, 然后系统调用 read() 返回, 这时又产生一个上下文切换: 从 kernel mode 切换到 user mode。
3. 系统调用 write() 产生一个上下文切换: 从 user mode 切换到 kernel mode, 然后把步骤 2 读到 user buffer 的数据拷贝到 kernel buffer(数据第 2 次拷贝到 kernel buffer), 不过这次是个不同的 kernel buffer, 这个 buffer 和 socket 相关联。
4. 系统调用 write() 返回, 产生一个上下文切换: 从 kernel mode 切换到 user mode(第 4 次切换了), 然后 DMA 从 kernel buffer 拷贝数据到协议栈(第 4 次拷贝了)。
   上面 4 个步骤有 4 次上下文切换, 有 4 次拷贝, 我们发现如果能减少切换次数和拷贝次数将会有效提升性能。在 kernel2.0+ 版本中, 系统调用 sendfile() 就是用来简化上面步骤提升性能的。sendfile() 不但能减少切换次数而且还能减少拷贝次数。

2)再来看一下用 sendfile() 来进行网络传输的过程:
sendfile(socket,file, len);

硬盘 >> kernel buffer (快速拷贝到 kernelsocket buffer) >>协议栈

1. 系统调用 sendfile() 通过 DMA 把硬盘数据拷贝到 kernel buffer, 然后数据被 kernel 直接拷贝到另外一个与 socket 相关的 kernel buffer。这里没有 user mode 和 kernel mode 之间的切换, 在 kernel 中直接完成了从一个 buffer 到另一个 buffer 的拷贝。
2. DMA 把数据从 kernelbuffer 直接拷贝给协议栈, 没有切换, 也不需要数据从 user mode 拷贝到 kernel mode, 因为数据就在 kernel 里。
   步骤减少了, 切换减少了, 拷贝减少了, 自然性能就提升了。这就是为什么说在 Nginx 配置文件里打开 sendfile on 选项能提高 web server 性能的原因。

综上, 这三个参数都应该配置成 on: sendfile on; tcp_nopush on; tcp_nodelay on;

1.2. nginx 长连接——keepalive

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

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

1.2.1. 保持和 client 的长连接:

默认情况下, nginx 已经自动开启了对 client 连接的 keep alive 支持(同时 client 发送的 HTTP 请求要求 keep alive)。一般场景可以直接使用, 但是对于一些比较特殊的场景, 还是有必要调整个别参数(keepalive_timeout 和 keepalive_requests)。

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

1)keepalive_timeout

语法:

keepalive_timeout timeout [header_timeout];

1. 第一个参数: 设置 keep-alive 客户端连接在服务器端保持开启的超时值(默认 75s); 值为 0 会禁用 keep-alive 客户端连接;
2. 第二个参数: 可选、在响应的 header 域中设置一个值"Keep-Alive: timeout=time"; 通常可以不用设置;

注: keepalive_timeout 默认 75s, 一般情况下也够用, 对于一些请求比较大的内部服务器通讯的场景, 适当加大为 120s 或者 300s;

2)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 个连接。因此, 就会发现有大量的 TIME_WAIT 的 socket 连接(即使此时 keep alive 已经在 client 和 nginx 之间生效)。因此对于 QPS 较高的场景, 非常有必要加大这个参数, 以避免出现大量连接被生成再抛弃的情况, 减少 TIME_WAIT。

1.2.2. 保持和 server 的长连接:

为了让 nginx 和后端 server(nginx 称为 upstream)之间保持长连接, 典型设置如下: (默认 nginx 访问后端都是用的短连接 (HTTP1.0), 一个请求来了, Nginx 新开一个端口和后端建立连接, 后端执行完毕后主动关闭该链接)

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

1)location 中有两个参数需要设置:

http {server {location /  {proxy_http_version 1.1; // 这两个最好也设置proxy_set_header Connection "";}}
}

HTTP 协议中对长连接的支持是从 1.1 版本之后才有的, 因此最好通过 proxy_http_version 指令设置为"1.1";
而"Connection" header 应该被清理。清理的意思, 我的理解, 是清理从 client 过来的 http header, 因为即使是 client 和 nginx 之间是短连接, nginx 和 upstream 之间也是可以开启长连接的。这种情况下必须清理来自 client 请求中的"Connection" header。

2)upstream 中的 keepalive 设置:
此处 keepalive 的含义不是开启、关闭长连接的开关; 也不是用来设置超时的 timeout; 更不是设置长连接池最大连接数。官方解释:

1. The connections parameter sets the maximum number of idle keepalive connections to upstream servers connections(设置到 upstream 服务器的空闲 keepalive 连接的最大数量)
2. When this number is exceeded, the least recently used connections are closed. (当这个数量被突破时, 最近使用最少的连接将被关闭)
3. 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 服务器连接的总数量)

我们先假设一个场景: 有一个 HTTP 服务, 作为 upstream 服务器接收请求, 响应时间为 100 毫秒。如果要达到 10000 QPS 的性能, 就需要在 nginx 和 upstream 服务器之间建立大约 1000 条 HTTP 连接。nginx 为此建立连接池, 然后请求过来时为每个请求分配一个连接, 请求结束时回收连接放入连接池中, 连接的状态也就更改为 idle。我们再假设这个 upstream 服务器的 keepalive 参数设置比较小, 比如常见的 10.

A、假设请求和响应是均匀而平稳的, 那么这 1000 条连接应该都是一放回连接池就立即被后续请求申请使用, 线程池中的 idle 线程会非常的少, 趋进于零, 不会造成连接数量反复震荡。

B、显示中请求和响应不可能平稳, 我们以 10 毫秒为一个单位, 来看连接的情况(注意场景是 1000 个线程+100 毫秒响应时间, 每秒有 10000 个请求完成), 我们假设应答始终都是平稳的, 只是请求不平稳, 第一个 10 毫秒只有 50, 第二个 10 毫秒有 150:

下一个 10 毫秒, 有 100 个连接结束请求回收连接到连接池, 但是假设此时请求不均匀 10 毫秒内没有预计的 100 个请求进来, 而是只有 50 个请求。注意此时连接池回收了 100 个连接又分配出去 50 个连接, 因此连接池内有 50 个空闲连接。
然后注意看 keepalive=10 的设置, 这意味着连接池中最多容许保留有 10 个空闲连接。因此 nginx 不得不将这 50 个空闲连接中的 40 个关闭, 只留下 10 个。
再下一个 10 个毫秒, 有 150 个请求进来, 有 100 个请求结束任务释放连接。150 - 100 = 50, 空缺了 50 个连接, 减掉前面连接池保留的 10 个空闲连接, nginx 不得不新建 40 个新连接来满足要求。
C、同样, 如果假设相应不均衡也会出现上面的连接数波动情况。

造成连接数量反复震荡的一个推手, 就是这个 keepalive 这个最大空闲连接数。毕竟连接池中的 1000 个连接在频繁利用时, 出现短时间内多余 10 个空闲连接的概率实在太高。因此为了避免出现上面的连接震荡, 必须考虑加大这个参数, 比如上面的场景如果将 keepalive 设置为 100 或者 200, 就可以非常有效的缓冲请求和应答不均匀。

总结:
keepalive 这个参数一定要小心设置, 尤其对于 QPS 比较高的场景, 推荐先做一下估算, 根据 QPS 和平均响应时间大体能计算出需要的长连接的数量。比如前面 10000 QPS 和 100 毫秒响应时间就可以推算出需要的长连接数量大概是 1000. 然后将 keepalive 设置为这个长连接数量的 10%到 30%。比较懒的同学, 可以直接设置为 keepalive=1000 之类的, 一般都 OK 的了。

1.2.3. 综上, 出现大量 TIME_WAIT 的情况

1)导致 nginx 端出现大量 TIME_WAIT 的情况有两种:

• keepalive_requests 设置比较小, 高并发下超过此值后 nginx 会强制关闭和客户端保持的 keepalive 长连接; (主动关闭连接后导致 nginx 出现 TIME_WAIT)
• keepalive 设置的比较小(空闲数太小), 导致高并发下 nginx 会频繁出现连接数震荡(超过该值会关闭连接), 不停的关闭、开启和后端 server 保持的 keepalive 长连接;

2)导致后端 server 端出现大量 TIME_WAIT 的情况:

nginx 没有打开和后端的长连接, 即: 没有设置 proxy_http_version 1.1; 和 proxy_set_header Connection “”; 从而导致后端 server 每次关闭连接, 高并发下就会出现 server 端出现大量 TIME_WAIT