HTTP Keep-Alive 与连接池实战：TIME_WAIT、端口耗尽和复用率怎么排查

HTTP Keep-Alive 与连接池实战：TIME_WAIT、端口耗尽和复用率怎么排查

摘要：服务端 CPU 和带宽都不高，接口却出现连接超时、偶发 502 或延迟尖峰，常见原因是 HTTP 连接没有复用，客户端连接池配置与服务端 keep-alive 不匹配。本文从 HTTP/1.1 持久连接、HTTP/2 多路复用、TIME_WAIT、临时端口和连接池参数入手，给出可执行的测量和调优方法。

很多性能报告只看 QPS、平均响应时间和带宽，忽略了"每个请求建立了几次 TCP 连接"。一次完整的 HTTPS 请求可能包含 DNS、TCP 三次握手、TLS 握手、请求处理和连接关闭。若客户端每次都新建连接，握手开销会叠加，短请求尤其明显；若连接池无限增长，又会挤占文件描述符和服务端连接额度。

Keep-Alive 不是一个简单的开关，而是客户端、代理、负载均衡和源站共同决定的生命周期。正确做法是先测量连接复用率和关闭原因，再调整池大小、空闲时间、并发策略与协议版本。

一、持久连接解决了什么

HTTP/1.1 默认允许在同一个 TCP 连接上发送多个请求。响应带有明确的 Content-Length、分块编码或连接关闭信号，客户端就能知道消息边界。连接复用省掉后续请求的 TCP 和 TLS 握手，降低延迟与 CPU 消耗，也减少 SYN 包和端口分配压力。

HTTP/1.0 需要 Connection: keep-alive 协商，HTTP/1.1 则默认持久连接，只有显式 Connection: close 才关闭。代理链中每一跳的连接策略可以不同：客户端到代理保持长连接，代理到源站却频繁新建连接，用户仍会看到不稳定的 TTFB。

持久连接不代表连接永远存在。服务端可用 Keep-Alive: timeout=5 告知空闲建议，代理也会按自己的 idle timeout 关闭。客户端必须把"服务端主动关闭"视为正常事件，在幂等请求上重试，在非幂等请求上先判断是否已提交，不能把所有断开都盲目重放。

二、Keep-Alive、连接池与并发

连接池通常包含空闲连接、正在使用的连接和等待队列。maxIdle 控制缓存多少空闲连接，maxTotal 控制总连接上限，maxPerHost 限制单个目标的并发。设置过小会让请求排队或频繁建连，设置过大则会造成服务端连接数、内核内存和 NAT 表膨胀。

连接池应按真实并发和请求耗时估算。若一个目标平均响应 100 毫秒，稳态 100 QPS 大约需要 10 个并发连接才能承载，但要为 p99、重试和突发流量留余量。HTTP/1.1 一个连接上的请求通常受队头阻塞影响，连接数不宜只按平均值计算。

连接池必须有获取连接超时、建立连接超时、读超时和空闲回收时间。没有 acquire timeout 时，请求可能无限等待；没有 idle eviction 时，网络设备已经关掉连接，池里却保留一批失效套接字，导致大量重试。

三、TIME_WAIT 到底是谁留下的

TCP 主动关闭的一方进入 TIME_WAIT，通常持续 2MSL。短连接客户端每次请求都主动关闭，就会在客户端积累大量 TIME_WAIT；如果服务端主动关闭，也可能由服务端承担。TIME_WAIT 的价值是让旧报文过期并确保最后 ACK 可重传，不能简单当作"无用垃圾"。

ss -ant state time-wait | head
ss -s
netstat -an | awk '$6=="TIME_WAIT"{c++} END{print c}'

TIME_WAIT 过多可能耗尽临时端口，表现为 Cannot assign requested address、连接建立失败或延迟突增。但只清理 TIME_WAIT 并不能解决根因；如果客户端仍然为每个请求新建连接，几分钟后还会复现。优先检查 Keep-Alive 和池复用率。

Linux 的端口范围、四元组复用、NAT 映射和内核参数共同决定可用连接数。不同目标 IP/端口可以复用本地端口，同一目标的并发连接则受四元组限制。容器共享宿主机网络栈时，多个服务还会竞争同一临时端口空间。

四、如何测量连接是否复用

应用层日志应记录连接 ID、远端地址、协议版本和连接创建时间。若每条请求日志都伴随新的连接 ID，说明池没有生效。反向代理可以记录 upstream connect time、request time 和 reused connection 标志，帮助区分建连耗时与业务处理耗时。

抓包中，重复出现 SYN、SYN-ACK、ACK 后只跟一个 HTTP 请求，通常表示短连接；同一个 TCP 流上出现多个请求和响应，则发生了复用。curl -v --http1.1 能观察 Re-using existing connection，curl --http2 -v 则可看到 HTTP/2 会话。

要计算复用率，可以用"请求总数减连接创建数，再除以请求总数"。同时统计连接关闭原因：服务端 timeout、代理 reset、客户端池回收和网络错误。只有复用率与关闭原因一起分析，才能判断是配置问题还是对端主动治理。

五、HTTP/2 多路复用的边界

HTTP/2 在一条 TCP 连接上承载多个 stream，避免了 HTTP/1.1 的应用层队头阻塞，但 TCP 丢包仍会阻塞整条连接。连接数并非越少越好，移动网络、跨地域链路和大响应场景可能需要多条 HTTP/2 连接分散丢包影响。

HTTP/2 的 SETTINGS_MAX_CONCURRENT_STREAMS 由对端限制。客户端池里只有一条连接时，如果并发 stream 达到上限，请求仍会排队。负载均衡器对 HTTP/2 到客户端、HTTP/1.1 到源站的协议转换，也会重新引入源站连接池问题。

HTTP/3 基于 QUIC，流之间不会因为单个 TCP 丢包而完全互相阻塞，但握手、连接迁移和服务端 UDP 策略又带来新的观测指标。不要因为启用了 HTTP/2 或 HTTP/3 就删除连接建立、空闲回收和错误重试监控。

六、服务端和代理的超时配合

客户端池的 idle timeout 应小于最短的中间设备 idle timeout，或者在复用前发送健康检查。若客户端认为连接还活着，而负载均衡器 60 秒前已关闭，下一次写入会收到 RST，造成一次额外重试。常见做法是客户端空闲 50 秒回收，代理 60 秒回收，源站 75 秒回收，形成由外到内的递增关系。

读超时和连接超时要分开。连接超时过长会拖住连接池，读超时过短则把正常的慢响应误认为故障。对长轮询、下载和普通 API 应设置不同策略，不能用一个全局值覆盖所有请求。

代理的 max_conns、keepalive_requests、keepalive_timeout 和 upstream queue 都会改变复用行为。某些代理为防止单连接资源泄漏，在处理固定请求数后主动关闭；客户端应把这种关闭视为可预测事件，并通过指标确认新建连接率没有异常升高。

七、短连接导致端口耗尽的案例

假设一台应用实例每秒发起 2000 个 HTTPS 请求，每个请求 20 毫秒就完成并主动关闭。临时端口范围只有约 28,000 个时，TIME_WAIT 可能在几十秒内占满可复用空间。即使服务端处理能力充足，客户端仍会报连接失败。

解决顺序应是启用连接池、提高复用率、合并请求、使用 HTTP/2，然后才考虑合理扩大端口范围。扩大端口只是提高上限，无法抵消持续的新建连接。如果存在多目标请求，可以按目标分组建立池，避免某一个慢目标占满全局连接。

重试会放大问题。一次连接失败触发三次快速重试，短时间内新建连接数可能翻倍。应使用带抖动的退避、限制每个请求的重试预算，并把连接错误与业务 5xx 分开统计。

八、连接池与负载均衡的关系

负载均衡器按连接做哈希时，少量长连接可能把流量集中到某几个后端，造成连接数看似很低但后端负载不均。按请求分发的七层代理可以改善分布，却会承担更多连接终止和协议处理成本。

滚动发布期间，旧后端需要排空连接。若代理立即关闭全部连接，客户端会在同一时刻重建大量 TCP/TLS，会产生连接风暴。优雅退出应先停止接收新请求，再等待活跃请求完成，并给出足够的 drain 时间。

服务端扩容也会改变池的连接分布。客户端池固定连接数时，新实例可能很久收不到流量；可以定期刷新 DNS、支持连接迁移或按连接年龄回收，避免连接长期黏在旧节点。

九、TLS 会如何放大建连成本

TLS 1.3 通常只需一次往返，TLS 1.2 可能需要更多往返和证书链验证。跨地域访问时，握手 RTT 直接进入首请求延迟。会话恢复和 0-RTT 可以降低成本，但不能替代连接复用，且 0-RTT 要谨慎处理重放风险。

证书链、OCSP、SNI 和 ALPN 都发生在握手阶段。客户端池如果频繁新建连接，会反复消耗加密 CPU，服务端表现为握手耗时上升而业务处理耗时正常。监控应把 TLS handshake time 从 connect time 和 server processing time 中拆出来。

当客户端与代理之间使用 HTTP/2，而代理到源站每次重新 TLS，用户仍会看到随机的首包延迟。应在两段链路分别统计连接创建、握手和复用情况。

十、排查工具与示例

curl 可以验证单次请求的时间分解：

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}
' https://example.com/

ss -antp 查看连接状态，lsof -p PID | grep TCP 查看进程占用，应用指标记录池等待时间和活跃连接数。压测时要预热连接池，分别测试冷连接、热连接、服务端主动关闭和网络抖动四种场景。

如果只有首次请求慢，检查 DNS、TCP、TLS 和连接预热；如果每隔固定时间出现一次慢请求，检查 idle timeout；如果高并发时排队，检查池上限与对端 stream 限制；如果错误集中在发布或扩容时段，检查连接排空和重建风暴。

十一、监控指标与容量规划

建议监控连接创建速率、复用率、空闲连接数、活跃连接数、池等待时间、TIME_WAIT 数、临时端口使用率、连接错误、TLS 握手耗时和服务端 502。指标要按目标主机、协议版本和实例拆分，否则全局平均会掩盖单一上游故障。

容量规划可以从并发连接反推。用 p95 响应时间乘以目标 QPS 得到基础并发，再叠加重试和突发系数。连接池总量还要受服务端 max connections、负载均衡上限、文件描述符和 NAT 状态表约束。每次调参都应在压测和线上低峰期验证。

外部观测可用 dnspup.com 的网站测速与 Tcping 页面分别确认 DNS、TCP 端口和 HTTP 时间，帮助区分本地连接池问题与公网路径问题。但工具给出的单次结果不能代替应用侧复用率和连接状态指标。

十二、实践建议与结论

优先启用成熟 HTTP 客户端的连接池，明确连接获取、建立、读和空闲回收超时；让客户端 idle timeout 略短于代理；对幂等请求采用有限、带抖动的重试；发布时执行连接排空；对 HTTP/2 关注 stream 上限和 TCP 丢包；对 HTTP/3 单独建立 QUIC 指标。

遇到 TIME_WAIT、端口耗尽或偶发 502 时，先回答三个问题：请求是否复用了连接、关闭是谁发起的、池是否在等待可用连接。只要这三点有日志和指标，调参就会从猜测变成验证。

Keep-Alive 的价值不在于让连接永久存活，而在于用可控的连接生命周期换取更少握手、更低延迟和稳定的资源占用。把应用、代理、负载均衡和内核放在同一条链路上分析，才能同时解决性能尖峰与容量风险。

十三、连接池参数如何从数据推导

连接池大小不应照抄框架默认值。先从访问日志计算每个上游的 QPS、p95 响应时间和突发倍数，再用并发约等于 QPS 乘以响应时间估算基础连接数。例如某上游稳定 300 QPS、p95 为 80 毫秒，基础并发约为 24；若部署在四个实例，每实例至少要能承载约 6 条活跃连接，再为重试和发布排空预留空间。

空闲连接数可以按低峰期请求间隔估算。若低峰每秒只有一个请求而代理 30 秒关闭空闲连接，保留数十条连接没有意义，反而增加服务端资源。高峰期需要快速扩张时，可让池按需创建，并在高峰结束后分阶段回收，避免瞬时关闭造成 TIME_WAIT 风暴。

连接获取超时要小于业务总超时，并把排队时间单独记录。大量请求在池前等待时，服务端可能很空闲，但用户仍然感到慢。日志应同时输出 queued、connect、TLS、write、server 和 read 各阶段耗时。

十四、连接复用与请求语义

连接复用要求正确处理响应体。客户端没有读取完 body 就把连接放回池，下一次请求会读到上一个响应的尾部，许多库因此直接关闭连接。下载接口、流式响应和取消请求要明确标记不可复用或先消费剩余数据。

幂等性也影响重试。GET、HEAD 和部分 PUT 可以在确认连接失败后重试；POST 即使业务看起来无副作用，也可能已经在服务端执行。TLS 握手后断开与请求已发送后断开是不同场景，客户端应根据写入进度和服务端幂等键决定是否重试。

HTTP/2 stream 复用改变了连接数和请求数的关系，但取消 stream、RST_STREAM 和 GOAWAY 都要有监控。收到 GOAWAY 后，客户端应把新请求迁移到新连接，等待旧 stream 完成；如果立即关闭全部连接，会放大重连峰值。

十五、内核与文件描述符容量

每条 TCP 连接至少占用一个文件描述符和内核 socket 内存。连接池上限、线程数、日志文件和数据库连接共同竞争进程的 ulimit -n。当 fd 接近上限时，应用可能先报"打开文件过多"，随后连接池把它包装成普通网络超时。容量评估必须把所有 fd 使用纳入同一张表。

宿主机还受 net.ipv4.ip_local_port_range、conntrack 表和 NAT 设备限制。扩大端口范围前要确认防火墙、监控和合规策略允许，并观察 TIME_WAIT 回收是否造成旧连接误匹配。云 NAT 网关往往按目标四元组提供有限端口，应用实例分片后仍可能在单一目标上耗尽。

通过 pidstat -w、ss -s、进程 fd 统计和 conntrack 计数，可以判断瓶颈在应用、内核还是网络设备。不要在没有数据时直接开启激进的端口复用参数，错误配置会把旧报文风险带入新连接。

十六、故障演练与发布策略

可以在测试环境把代理 idle timeout 调到很短，验证客户端能否在复用前发现失效连接；再限制后端最大连接数，观察池等待和退避；最后模拟节点滚动下线，确认连接排空和重建速率。演练结果应形成阈值，而不是只记录"没有报错"。

发布期间，先停止向旧节点分配新连接，再等待活跃请求和长连接达到排空条件。对 WebSocket、HTTP/2 长 stream 和下载连接要设置最大年龄，防止它们永久阻塞发布。客户端可按连接年龄回收，均匀地把流量迁移到新节点。

如果连接错误突然上升，先降低重试并发和新建连接速率，保护剩余池容量；随后检查代理、负载均衡和源站的关闭原因。恢复后逐步放开限流，避免所有实例同时重建连接。

十七、从指标判断连接池是否健康

健康的连接池通常表现为连接创建速率远低于请求速率，池等待时间接近零，空闲连接在高低峰之间平滑变化，TIME_WAIT 与实例规模成比例。若请求量稳定而连接创建速率周期性尖峰，常见原因是 idle timeout 同时回收、代理滚动重启或 DNS 切换触发全部连接失效。

可以建立三个比值：请求/新连接表示平均复用次数，排队请求/总请求表示池容量压力，连接错误/新建连接表示建连质量。按目标、实例和协议拆分后，调参效果会非常清晰。复用率提高但 p99 变差，可能是单连接队头阻塞；连接数增加但错误率上升，可能超过了对端容量。

最后要把连接池参数版本化。每次修改 maxTotal、idle timeout 或重试策略时，记录生效时间并关联监控图，避免故障复盘时无法解释连接创建率的变化。通过数据和版本共同观察，Keep-Alive 才能成为可管理的容量工具。

十八、从客户端到源站的完整时间线

一次请求至少要标记 DNS 开始与结束、TCP connect、TLS handshake、等待连接池、发送请求、等待首字节、读取 body 和连接归还池的时间。连接池等待不属于网络路径，却经常被统计到总耗时里；如果不拆分，就会误以为公网延迟上升。

代理链需要在每一跳使用唯一的 request ID，并传递连接创建时间或 upstream connection ID。这样可以知道客户端复用了 HTTP/2 stream，代理却为源站新建了连接，还是源站返回慢导致池长期占用。

当用户反馈"偶尔慢"，按 p95、p99 和慢请求样本看连接年龄、关闭原因与重试次数，通常比看平均连接数更有价值。慢样本若集中在连接年龄接近 idle timeout 的请求，优先修正回收策略；若集中在池等待，优先扩容或降低并发重试。

这套时间线也适用于网站测速结果的解释：外部探针能告诉你公网某节点的建连和首包表现，应用指标则能告诉你连接池是否在本机排队。两者结合，才能把性能问题定位到正确一层。

十九、连接池的安全与隔离

连接池复用连接时必须确保目标主机、端口和 TLS SNI 不会被错误共享。多租户代理若只按 IP 建池，可能把一个 Host 的请求发到另一个虚拟站点；TLS 会话恢复也必须绑定正确的 SNI 和证书验证上下文。

不同信任域应使用不同池，避免认证头、代理凭据和 Cookie 在连接或请求封装中串用。连接池清理时要同步清除与连接关联的会话状态，不能只关闭 socket 而留下可复用的认证对象。

性能调优要接受隔离成本。把所有目标合并进一个无限大池看似减少连接，却会让单一慢目标占满资源，也增加故障扩散范围。按目标、租户和协议设置上限，配合熔断和退避，通常更容易维持稳定的尾延迟。

上线后持续观察每个池的复用、排队、关闭和错误，比一次性设定一个"足够大"的连接数更可靠。

二十、结语中的落地动作

排查连接问题时，先抓一组冷连接和热连接的时间线，再查看池等待、连接创建、复用和关闭原因。若热连接明显更快，说明握手成本是主要因素；若热连接仍慢，检查服务端处理、代理排队和 TCP 丢包。调参后重复同一场景，确认指标和用户延迟同时改善。

把连接池配置、内核端口范围、代理超时和重试策略纳入版本控制，发布时自动做小流量回归。任何改变上游地址、协议版本或负载均衡策略的变更，都应重新验证复用率和连接排空。

连接管理的目标是稳定地复用有限资源，并在异常时快速、可控地重建。只要把每个阶段的证据保留下来，TIME_WAIT、端口耗尽和偶发 502 就能从模糊现象变成可计算、可修复的问题。