nginx Keepalive

你说得非常准确！看来你关注的是 Nginx 内部的 keepalive 配置，而不是高可用集群工具 Keepalived 软件。这两者虽然名字很像，但完全是两个维度的技术：

• Keepalived (软件)：解决的是服务器挂没挂的问题（高可用/VIP 漂移）。

• Nginx keepalive (指令)：解决的是连接复用效率的问题（长连接/性能优化）。

既然你提到了客户端到 Nginx，以及 Nginx 到后端（Upstream）的连接池，我们可以从这两个链路来看看它是如何压榨性能的：

1. 客户端到 Nginx 的长连接

这是最常见的场景。默认情况下，HTTP/1.1 协议支持长连接。

• 原理：浏览器请求一个网页后，TCP 连接不会立即断开，而是保持一段时间，用来继续请求该页面上的图片、JS 等资源。

• 核心配置：

  • keepalive_timeout 65;：客户端连接保持 65 秒，超时没新请求就断开。

  • keepalive_requests 100;：一个 TCP 连接最多承载 100 个请求，超过后强制断开重连，防止内存泄漏。

• 收益：减少了每个小资源请求都要进行的 TCP 三次握手 耗时。

2. Nginx 到后端的连接池 (Upstream Keepalive)

这是高并发场景下优化最明显的地方。如果 Nginx 作为反向代理，默认情况下它对后端（如 Tomcat, PHP-FPM, Python）的每个请求都会发起新的 TCP 连接。

• 痛点：在高 QPS 场景下，Nginx 所在的服务器会产生海量的 TIME_WAIT 状态连接，导致端口耗尽，响应变慢。

• 原理：Nginx 在 upstream 块中维护一个空闲连接池。请求处理完后，TCP 连接不关闭，而是放入池子给下一个请求复用。

• 关键配置：

  Nginx

  upstream backend_server {
      server 127.0.0.1:8080;
      keepalive 32; # 关键：连接池中保留的最大空闲连接数
  }
  

• 收益：

  • 降低延迟：省去了发往后端服务器的握手时间。

  • 保护后端：避免后端服务因为频繁创建/销毁线程而崩溃。

3. 为什么它对高并发至关重要？

我们可以用数据对比一下两种模式的损耗：

⚠️ 一个容易踩的坑

在配置 upstream keepalive 时，如果你用的是 HTTP/1.1，必须在 location 块中添加两行配置，否则长连接不会生效：

location / {
    proxy_http_version 1.1;         # 必须显式指定 1.1
    proxy_set_header Connection ""; # 清除客户端传来的 Close 头
    proxy_pass http://backend_server;
}

你目前是在为现有的系统做性能压测优化吗？如果你遇到了 TIME_WAIT 过高的问题，我可以帮你看看具体的内核参数该怎么配合 Nginx 调整。