Nginx对上游服务器使用keepalive的使用

一、引言：别让 Nginx 成为“短连接制造机”

当 Nginx 作为反向代理时，它位于客户端和后端应用服务器（如 Tomcat, Node.js, PHP-FPM）之间。一个常见的性能陷阱是：Nginx 与后端服务器之间的连接默认是短连接！

这意味着，对于每一个来自客户端的请求，Nginx 都会：

1. 与后端服务器进行一次完整的 TCP 三次握手。
2. 转发请求并接收响应。
3. 立即进行 TCP 四次挥手 关闭连接。

而后端服务器处理 TCP 连接的开销通常远大于 Nginx。在高并发场景下，这种“用完即弃”的模式会导致：

• 后端服务器 CPU 飙升：大量时间花在处理连接建立/关闭上。
• Nginx 本地端口耗尽：产生海量 TIME_WAIT 连接。
• 整体吞吐量急剧下降。

upstream keepalive 机制正是为解决此问题而生。它允许 Nginx 与后端服务器之间复用 TCP 连接，将 Nginx 从“短连接制造机”转变为高效的“连接管理者”。

💡 核心价值：
正确配置 upstream keepalive，是释放 Nginx 反向代理全部性能潜力的关键一步，能带来数倍的 QPS 提升！

二、工作原理：Nginx 的上游连接池

upstream keepalive 并非简单地开启一个开关，而是建立了一个智能的连接池。

1. 核心流程

1. 请求到来：Nginx 收到一个需要转发给后端的请求。
2. 池中寻觅：Nginx 检查其 upstream 连接池，看是否有空闲的、指向目标后端的 KeepAlive 连接。
3. 复用 or 新建：
   • 如果有空闲连接，则直接复用，发送请求。
   • 如果没有，则新建一个 TCP 连接。
4. 归还连接：请求处理完毕后，如果后端响应支持 KeepAlive，Nginx 不会关闭这个连接，而是将其放回连接池，供后续请求使用。
5. 池满或超时：当连接池已满，或者连接空闲时间过长，Nginx 会清理掉这些连接以释放资源。

2. 关键特性

• 每个 Worker 独立：连接池是按 Nginx 的 worker 进程隔离的。总的最大空闲连接数 = keepalive * worker_processes。
• 仅缓存空闲连接：keepalive 指令定义的是空闲连接的数量上限，而不是总连接数。活跃的连接不受此限制。

三、核心配置：三步开启上游 KeepAlive

要让 upstream keepalive 生效，必须同时配置以下三个部分，缺一不可。

第一步：在upstream块中定义连接池大小

upstream backend {
    # 为每个 worker 进程缓存 32 个空闲的 keepalive 连接
    keepalive 32;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

• keepalive 32: 这是最核心的指令。数字 32 表示每个 worker 进程最多可以缓存 32 个空闲的、与后端服务器的 HTTP/1.1 KeepAlive 连接。

第二步：在location块中强制使用 HTTP/1.1

server {
    location / {
        proxy_pass http://backend;
        # 必须设置！强制 Nginx 使用 HTTP/1.1 与后端通信
        proxy_http_version 1.1;
    }
}

• proxy_http_version 1.1: KeepAlive 是 HTTP/1.1 的默认行为。如果不显式指定，Nginx 默认使用 HTTP/1.0 与后端通信，而 HTTP/1.0 默认是短连接。

第三步：清除干扰性的Connection头

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        # 必须设置！清除从客户端带来的 Connection 头
        proxy_set_header Connection "";
    }
}

• proxy_set_header Connection "": 客户端可能会发送 Connection: close 或 Connection: keep-alive。如果不清理，这个头部会被透传给后端，可能干扰 Nginx 与后端之间 KeepAlive 连接的建立。将其设为空字符串，可以确保 Nginx 完全掌控与后端的连接行为。

四、深度调优：如何确定keepalive的最佳值？

keepalive 的值并非越大越好，需要根据业务场景精确计算。

1. 计算公式

一个经验公式是：
每个后端所需连接数 ≈ (QPS / 后端数量) * 平均响应时间(秒)

2. 实战案例

假设你的系统指标如下：

• 总 QPS: 2000
• 后端服务器数量: 4 台
• 平均响应时间 (RT): 50ms (0.05秒)

计算过程：

1. 每台后端承受的 QPS = 2000 / 4 = 500
2. 每台后端所需的连接数 = 500 * 0.05 = 25

因此，keepalive 的值应略大于 25，比如设置为 32。

3. 监控与验证

• 监控 TIME_WAIT: 使用 ss -tan state time-wait | wc -l 命令。配置生效后，TIME_WAIT 连接数应大幅下降。
• 观察后端负载: 后端服务器的 CPU 使用率（特别是 system CPU）应该显著降低。
• 压测对比: 使用 wrk 或 ab 工具进行压测，对比开启前后的 QPS 和延迟。

五、常见陷阱与避坑指南

1.只配了upstream keepalive，忘了proxy_http_version

这是最常见的错误。结果是，Nginx 依然使用 HTTP/1.0 与后端通信，keepalive 指令完全失效。

2.后端服务器不支持 KeepAlive

确保你的后端应用（如 Tomcat）也配置了合理的 keepAliveTimeout 和 maxKeepAliveRequests。如果后端主动关闭连接，Nginx 的连接池就失去了意义。

3.连接池大小不足

如果 keepalive 值设置过小，在高并发下，连接池会频繁地创建和销毁连接，无法达到复用的效果，性能提升有限。

4.与proxy_next_upstream的交互

当 proxy_next_upstream 触发重试时，Nginx 会关闭当前连接并尝试下一个服务器。这属于正常行为，但需注意它会影响连接池的利用率。

六、结语

到此这篇关于Nginx对上游服务器使用keepalive的使用的文章就介绍到这了,更多相关Nginx 上游服务器使用keepalive内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！