连接管理：为什么第二次请求往往更快

你可能遇到过这种现象：第一次打开一个接口要等一会儿，紧接着再请求同一个接口，哪怕响应内容没变，第二次却明显更快。

很容易想到缓存，但缓存不是唯一答案。即使服务端每次都重新计算，第二次请求也可能省掉 DNS 查询、TCP 建连、TLS 握手，还可能直接拿到连接池里已经“热起来”的连接。真正传输 HTTP 消息之前，网络已经做了不少准备工作。

这时另一个反直觉的问题来了：既然不关连接更快，为什么不把所有连接永远留着？

因为连接不是一根没有成本的虚线。操作系统要为它保存套接字状态和收发缓冲区，程序要占用文件描述符，负载均衡器和防火墙也要记录连接状态。连接留得太少，会反复支付建连成本；留得太多，又会把内存、端口和并发配额耗在没有工作的连接上。

所以连接管理真正要解决的，不是“要不要长连接”这一个开关，而是四个连续的问题：什么时候建立、怎样复用、何时判定失效、出了问题如何观察。HTTP/1.1、HTTP/2 和 HTTP/3 给出的答案不同，但背后的权衡始终没变。

先把一次请求的延迟拆开

浏览器或后端客户端请求一个 HTTPS 地址时，常见路径大致是：解析域名、选择地址、建立传输连接、完成安全握手、发送 HTTP 请求、等待服务端处理、接收响应。并不是每次请求都会完整走完这条路径。

可以用下面这个近似式理解首次请求的时间花在哪里：

如果下一次请求成功复用现有连接，前面几项可能大幅缩短：

这里多了一个容易被忽略的量：连接池排队时间 $T_{queue}$。当池里的连接或可用流已经被占满，请求虽然不用自己建连，却要等别人归还连接。于是“复用率很高”并不自动等于“延迟很低”，还要看池是否饱和。

第二次更快不一定全是连接复用

DNS 缓存、TLS 会话恢复、服务端缓存、JIT 预热、磁盘页缓存都可能让第二次请求变快。排查时不要只看一个总耗时。至少要把 DNS、TCP、TLS、连接池等待、首字节和完整下载分开记录，才能知道优化落在哪一段。

TCP 如何建立和关闭连接

HTTP/1.1 和 HTTP/2 通常运行在 TCP 上。TCP 向应用提供可靠、有序、双向的字节流。它不会替 HTTP 标记“这是请求头”“这里是响应体”，只负责让字节按顺序到达。HTTP 自己必须解决消息边界和请求响应匹配。

三次握手到底确认了什么

常见的主动连接过程是：

• 客户端发送带有 SYN 的报文，给出自己的初始序列号。
• 服务端回复 SYN + ACK，确认客户端的序列号，同时给出自己的初始序列号。
• 客户端再发送 ACK，双方进入已建立状态。

这不只是“互相打三次招呼”。双方借此确认路径可达，建立序列号空间，并协商最大报文段、窗口扩大等 TCP 选项。正常情况下，从客户端发出 SYN 到收到 SYN + ACK，至少经历一个网络往返时间。HTTPS 还要建立加密上下文，因此首次请求对远距离网络尤其敏感。

关闭不是固定四个独立报文

教材常把 TCP 关闭叫作“四次挥手”，这个说法便于记忆，却容易让人以为关闭永远恰好出现四个包。

TCP 的两个方向可以独立关闭。一方发送 FIN，表示“我不会再发送数据”，对方确认这个 FIN；对方处理完剩余数据后，也发送自己的 FIN，再由最初一方确认。确认与 FIN 可以合并，双方也可能几乎同时关闭，所以抓包里不一定总是四个彼此分开的报文。

如果程序需要优雅结束，就要先停止接收新请求，等待或取消在途请求，发送剩余响应，再关闭连接。直接用 RST 重置连接更像“立即作废”，未读数据和未完成请求可能一起丢失。

TIME_WAIT 不是系统忘了回收

主动关闭的一方通常会进入 TIME_WAIT。这段等待主要有两个作用：如果最后一个确认丢失，还能再次确认对方重发的 FIN；同时让旧连接中迟到的报文在网络里消失，避免它们被误认成相同端点组合上的新连接数据。

看到大量 TIME_WAIT，先别急着缩短内核计时器。它常常是在告诉你“程序正在频繁主动建连和关连”。更稳妥的排查顺序是：先看连接是否本可复用，再看客户端端口、文件描述符和连接创建速率是否真的形成瓶颈，最后才考虑操作系统级参数。

三种“保活”不要混在一起

连接相关的“保活”至少有三种含义：

• HTTP 持久连接：一个传输连接承载多次请求和响应。
• TCP keepalive：连接长时间空闲后发送探测，帮助发现已经消失的对端或路径。
• 应用层心跳：由 WebSocket、消息协议或业务自己定义，既能判断链路，也能表达应用是否仍可工作。

TCP 本身不会天然、及时地告诉应用“空闲对端还活着”。TCP keepalive 通常默认间隔很长，而且一次探测无响应也不能立刻证明连接已死。对需要几十秒内发现故障的系统，应用层超时或心跳往往更直接。

延迟确认为什么有时让小请求变慢

TCP 收到数据后不一定立刻单独发一个 ACK。接收方可以稍等一小段时间，看看能否把确认信息捎在反向数据上，或者一次确认多个完整报文段。这样能减少纯 ACK 包，也能降低主机处理大量小包的开销。

标准限制确认不能被过度延迟，但没有规定所有系统都使用同一个固定毫秒数。具体等待策略由操作系统、网络状态和报文模式共同决定。因此，看到一次几十毫秒的停顿，不能仅凭数值就断定是延迟确认。

ACK 和 HTTP 响应不是同一件事

ACK 是 TCP 层对“这些字节已经收到”的确认，HTTP 响应是应用层处理请求后的结果。服务端可以在生成响应数据时顺便确认客户端发来的请求字节，并不需要先等一个单独 ACK 再开始业务处理。

真正容易出问题的是多个优化策略的组合。例如，发送方启用了 Nagle 算法，手里已有少量未确认数据时会暂缓继续发送小块数据；接收方又在等待更多数据后再发 ACK。两边各自都在减少小包，组合起来却可能制造额外等待。

TCP_NODELAY 不是“关闭延迟确认”

TCP_NODELAY 控制的是发送端的 Nagle 行为，不是接收端的延迟确认。打开它可以让小块数据更快交给 TCP 发送，但也可能制造更多小包，增加协议头、CPU 和网络设备的负担。

更好的第一步通常是检查应用写入方式：能一次写完的请求头不要拆成十几次小写入；能批量编码的响应不要每生成几个字节就刷新；对真正需要低延迟的小消息，再结合抓包和系统指标判断是否调整套接字选项。

持久连接靠消息边界才能安全复用

HTTP/1.1 默认使用持久连接。除非一方明确声明 Connection: close，同一条连接在一次响应结束后可以继续承载后续请求。它省下了反复建连和安全握手的成本，也让拥塞控制有机会沿用已经积累的网络状态。

但“连接没关”不代表“连接一定能复用”。复用之前，客户端必须知道当前响应究竟在哪里结束。

为什么必须读完响应体

HTTP/1.1 是有序字节流，没有每个请求自带的独立通道。如果客户端只读了响应头，没有消费完响应体，就把连接放回池里，下一位使用者读到的开头很可能是上一个响应剩下的数据，而不是自己的响应。

所以客户端库通常要求以下两者之一：

• 完整读取响应体并正确关闭响应对象，让连接回到空闲池。
• 明确放弃复用并关闭连接，避免残留字节污染下一次请求。

响应边界可以由长度、分块编码或特殊状态语义确定。只有靠“关闭连接”才能确定结束的响应，关闭后自然无法再次复用。这也是消息 framing 与连接管理紧密相连的原因。

Connection 是逐跳字段

Connection 描述当前这一跳的连接行为。经过代理时，客户端到代理和代理到上游是两条不同连接，代理不能把逐跳连接选项当作端到端业务字段原样转发。

这也解释了一个常见误会：浏览器显示“保持连接”，不代表浏览器真的与最终应用进程共享同一个套接字。中间可能经过 CDN、负载均衡器和反向代理，每一跳都有自己的连接池、空闲超时和关闭策略。

连接池是在复用和排队之间做选择

连接池的基本动作很简单：按目标和协议策略保存可复用连接，请求到来时先借一条，完成后再归还。难点全在边界条件。

连接不能随便跨目标借用

池通常至少要考虑目标地址、代理、安全参数和协议能力。一个连接已经绑定到特定对端和加密上下文，不能仅因为端口相同就借给任意主机。某些协议允许在满足证书、地址和服务器声明等条件时合并连接，但这应由成熟客户端实现判断，业务代码不要自行猜测。

HTTP/1.1 池和 HTTP/2 池不一样

在不使用流水线的 HTTP/1.1 连接上，同一时刻通常只有一个在途请求。并发增加时，客户端会开多条连接，或者让请求等待空闲连接。

HTTP/2 的一条连接可以同时开放多个流。此时池管理的不只是“还有没有空闲套接字”，而是“现有连接还有没有可用流配额、连接级流控窗口是否充足、是否正在优雅关闭”。把 HTTP/1.1 的“每请求借一条连接”思路原封不动套到 HTTP/2，往往会开出过多连接。

池大小没有脱离场景的最佳值

池太小，请求会在本机排队；池太大，会增加文件描述符、内存、端口、服务端连接状态和握手风暴的风险。HTTP/1.1 可以用一个粗略关系做初始估算：

其中 $\lambda$ 是目标请求速率，$T_{occupied}$ 是一条连接被单个请求占用的平均时长。这个结果只是起点，因为突发流量、尾延迟、重试和上游限额都会改变需要的并发量。HTTP/2 还要把每条连接可并发的流数纳入计算。

空闲连接可能已经悄悄失效

服务端、代理、防火墙或 NAT 都可能先关掉空闲连接。客户端下一次从池里拿到它时，才发现写入失败、收到 EOF 或连接重置。这不是罕见异常，而是复用连接必须面对的正常竞态：服务端决定关闭的同时，客户端可能刚好发送新请求。

客户端需要淘汰失败连接，并谨慎决定是否重试。读取类、幂等请求通常更适合自动重试；创建订单、扣款之类操作即使客户端没收到响应，也不能直接推断服务端没执行。它们需要幂等键或业务去重，而不是盲目再发一次。

一组更实用的池参数

比“是否开启 keep-alive”更值得关注的是：

• 每个目标最多建立多少连接。
• 最多保留多少空闲连接，以及全局空闲上限。
• 请求等待连接的最长时间。
• 空闲连接多久后淘汰。
• 单条连接使用多久或处理多少请求后轮换。
• 建连、TLS 握手和请求各自的超时。
• 服务准备下线时，怎样停止新借用并排空在途请求。

这些参数要成组观察。只增加最大连接数，却不限制排队和重试，可能只是把拥塞从客户端队列推到服务端。

HTTP/1.1 流水线为什么没成为主流

普通的 HTTP/1.1 复用经常是“发一个请求，等完整响应，再发下一个”。流水线允许客户端不等前一个响应就连续发送多个请求，看上去像是用一条连接获得并发。

问题在于 HTTP/1.1 没有给每个请求附带可独立匹配的请求 ID。客户端只能按发送顺序匹配响应，服务端即使并行处理了安全请求，也必须按请求到达顺序发回对应响应。

慢响应会挡住已经完成的快响应

假设客户端依次发出 A、B、C 三个请求。B 和 C 很快处理完，但 A 要查一个很慢的上游。服务端不能先把 B、C 的最终响应发回，否则客户端无法可靠判断每段字节属于哪个请求。于是 B、C 只能在 A 后面等，这就是 HTTP 层的队头阻塞。

流水线还让故障恢复变得棘手。如果连接在中途关闭，客户端必须判断哪些请求服务端可能已经执行、哪些响应只是没有送达。非幂等请求尤其危险，自动重试可能重复产生业务副作用。

再加上历史上的代理、服务器兼容问题，HTTP/1.1 流水线始终没有成为浏览器里的通用并发方案。实践中更常见的是开少量并行 HTTP/1.1 连接，或者直接使用 HTTP/2 的流。

HTTP/2 用流拆开请求响应

HTTP/2 把请求和响应拆成二进制帧，每个请求响应交换关联到一个流。不同流的帧可以在同一条 TCP 连接上交错传输，接收方再按流 ID 组装。

于是前面的 A、B、C 不再依赖一个固定响应顺序。A 的业务处理很慢时，B 和 C 的帧仍可以先通过连接。这解决了 HTTP/1.1 在应用层的响应队头阻塞，也让客户端不必靠开很多 TCP 连接来制造并发。

多路复用不等于无限并发

HTTP/2 同时受多种限制：对端允许的并发流数量、每个流的流量控制窗口、整条连接的流量控制窗口、服务端实际处理能力，以及客户端自己的请求优先级。

如果接收方迟迟不释放连接级窗口，一个流发送大量数据也可能影响其他流；如果客户端一次创建远超服务端能力的请求，排队只是从连接池移动到了流和应用线程池。协议减少了一类阻塞，却没有消灭容量边界。

TCP 丢一个包，为什么所有流仍可能停顿

TCP 向上提供严格有序的字节流。某个 TCP 段丢失后，即使后续段包含的是另一个 HTTP/2 流，TCP 也要等丢失字节重传后才能把后续字节按序交给 HTTP/2。

因此，HTTP/2 解决了 HTTP 层的队头阻塞，没有解决 TCP 层的队头阻塞。在低丢包网络里，一条连接共享拥塞状态通常很高效；在高延迟、易丢包的移动网络中，一次丢包可能让许多活跃流一起短暂停顿。这正是 HTTP/3 改变传输层映射的动机之一。

HTTP/3 把多路复用放进 QUIC

HTTP/3 运行在 QUIC 上。QUIC 通常承载于 UDP，但它不是“不可靠地把 HTTP 扔进 UDP”。可靠传输、丢包恢复、流量控制、拥塞控制、加密握手和多路复用都由 QUIC 在用户态实现。

HTTP/3 的一次请求响应使用一条 QUIC 流。每条流内部仍然可靠、有序；某条流的数据丢失时，其他流中已经到达的数据可以继续交给应用，不必等那条流补齐。这缩小了传输层队头阻塞的影响范围。

QUIC 仍然有拥塞控制

把 QUIC 说成“绕过 TCP 拥塞控制”是不准确的。QUIC 连接仍要根据网络反馈控制整体发送速率，避免把链路压垮。独立流解决的是可靠、有序交付的阻塞范围，不代表每条流都能无视连接容量独自加速。

连接级拥塞、连接级流控、控制流以及头部压缩状态，仍可能让多个请求互相影响。HTTP/3 改善了故障隔离，但它也不是“任何丢包都只影响一个请求”的绝对承诺。

建连更快有前提

QUIC 把传输参数协商与 TLS 1.3 握手结合起来，新连接通常能用较少的串行往返进入可发送应用数据的状态。已经连接过同一服务的客户端还可能使用 0-RTT 发送早期数据。

但 0-RTT 数据存在被重放的可能，服务端也可能拒绝它。会产生副作用的请求不能因为“更快”就随意提前发送，仍要结合请求语义、幂等性和防重放设计。

换网络后连接可能继续，但不是零成本

传统 TCP 连接依赖地址和端口组合。手机从 Wi-Fi 切到蜂窝网络后，本地地址变化，旧 TCP 连接通常无法继续。

QUIC 使用连接 ID 识别逻辑连接，因此可以在地址变化后验证新路径并迁移连接。迁移不等于瞬间无缝：新路径要做可达性验证，RTT 和拥塞控制状态也要适应新的网络。它减少了重新建立完整应用会话的需要，却不会消除网络切换本身的抖动。

超时不是一个数字，而是一组故障边界

“请求超时设成 30 秒”听起来很完整，实际可能漏掉了大部分连接阶段。一次请求至少可能在这些地方卡住：

• 连接池没有可用容量，请求一直等连接。
• DNS 或 TCP 建连迟迟不完成。
• TLS 握手没有进展。
• 连接成功，但对端长时间不发响应头。
• 响应头到了，响应体却持续得过慢。
• 向服务端上传请求体时，对端不再读取。
• 上游返回得慢，导致整个业务截止时间耗尽。
• 连接已经空闲很久，却一直占着本地与服务端资源。

给每一段设置能解释的超时

常见的超时边界包括连接池获取超时、建连超时、TLS 握手超时、响应头超时、单次读写空闲超时、整个请求截止时间和持久连接空闲超时。

它们解决的问题不同。响应头超时适合限制“服务端多久必须开始回答”，读空闲超时适合发现“流式响应是否停止前进”，总截止时间则保证整个调用不会超过上层预算。对大文件下载，固定的总时长可能不合理，持续无进展的空闲超时反而更贴近故障。

下游预算不能大于上游预算

假设用户请求最多允许 2 秒，后端却给数据库 2 秒、第三方接口 2 秒，还准备各重试两次，这个预算从一开始就不成立。更合理的做法是把上层截止时间向下传递，给每一跳留下处理和返回错误的余量。

超时发生后还必须取消在途工作、关闭或丢弃不再安全复用的连接、释放池配额。只向调用者返回错误，却让后台请求继续占连接，会形成“请求都超时了，资源反而越来越满”的连锁故障。

重试会放大连接压力

超时与重试必须一起设计。服务变慢时，立即重试会创建更多请求、争抢更多连接，让原本的排队更严重。生产系统通常需要限制重试次数，使用退避和随机抖动，只对可安全重试的操作自动执行，并设置总重试预算。

监控要能回答连接正在经历什么

连接问题很少只表现为“连接错误”。用户看到的可能是接口尾延迟上升、偶发 502、超时或第一次访问慢。监控需要沿连接生命周期留下线索。

容量指标

至少记录当前活跃连接、空闲连接、正在建立的连接、等待连接的请求数、连接池获取等待时间，以及每个目标的池上限。对 HTTP/2 和 HTTP/3，还要看活跃流、待创建流和对端并发流限制。

如果活跃连接长期顶到上限，同时获取等待时间上升，池很可能已经饱和。若空闲连接很多、复用率却很低，则要检查池键是否过细、空闲超时是否不匹配，或者响应体是否没有正确读完。

阶段耗时

把 DNS、TCP 建连、TLS 握手、连接池等待、首字节和完整响应时间分别统计分位数。平均值会掩盖少量极慢连接，连接问题更应该关注高分位和分布变化。

例如，TCP 建连高分位上升而服务端处理时间稳定，问题可能在网络路径或监听队列；池等待上升但建连很快，说明客户端并发或上游容量配置更可疑；首字节慢而握手稳定，则更像服务端或其依赖变慢。

关闭与错误原因

不要把所有失败都记成 network error。至少区分连接超时、TLS 失败、对端优雅关闭、连接重置、请求截止时间、读写空闲超时、池等待超时、协议错误和本地主动取消。

还要记录新建连接速率、连接复用率、正常关闭与异常关闭数量、TIME_WAIT 趋势、重传和丢包信号，以及 HTTP/1.1、HTTP/2、HTTP/3 的实际协商占比。协议配置写着支持 HTTP/3，不代表真实请求已经在使用它。

给指标保留上下文，但控制标签规模

按目标服务、可用区、协议版本和错误原因拆分通常有用；把完整 URL、用户 ID 或每个远端地址直接做成指标标签，容易造成基数爆炸。高维细节更适合进入追踪和抽样日志，再通过请求 ID 与指标时间段对应。

用一次完整追踪验证连接是否真的复用

下面的 Go 程序会连续请求命令行传入的同一地址，并打印 DNS、建连、TLS、是否复用连接、首字节和总耗时。它会完整读取并关闭响应体，这一步正是让连接能够安全回池的条件。

package main
 
import (
	"crypto/tls"
	"fmt"
	"io"
	"net/http"
	"net/http/httptrace"
	"os"
	"time"
)
 
func main() {
	if len(os.Args) != 2 {
		fmt.Fprintf(os.Stderr, "用法: go run main.go <目标地址>\n")
		os.Exit(2)
	}
 
	transport := &http.Transport{
		MaxIdleConns:        20,
		MaxIdleConnsPerHost: 4,
		IdleConnTimeout:     30 * time.Second,
	}
	defer transport.CloseIdleConnections()
 
	client := &http.Client{
		Transport: transport,
		Timeout:   5 * time.Second,
	}
 
	for attempt := 1; attempt <= 2; attempt++ {
		if err := runOnce(client, os.Args[1], attempt); err != nil {
			fmt.Fprintf(os.Stderr, "第 %d 次请求失败: %v\n", attempt, err)
			os.Exit(1)
		}
	}
}
 
func runOnce(client *http.Client, target string, attempt int) error {
	started := time.Now()
	mark := func(event string) {
		fmt.Printf("第 %d 次 %-14s %8s\n", attempt, event, time.Since(started).Round(time.Millisecond))
	}
 
	trace := &httptrace.ClientTrace{
		DNSStart: func(httptrace.DNSStartInfo) {
			mark("DNS 开始")
		},
		DNSDone: func(info httptrace.DNSDoneInfo) {
			mark("DNS 完成")
			if info.Err != nil {
				fmt.Printf("  DNS 错误: %v\n", info.Err)
			}
		},
		ConnectStart: func(network, addr string) {
			mark("TCP 开始")
			fmt.Printf("  网络=%s 地址=%s\n", network, addr)
		},
		ConnectDone: func(_, _ string, err error) {
			mark("TCP 完成")
			if err != nil {
				fmt.Printf("  TCP 错误: %v\n", err)
			}
		},
		TLSHandshakeStart: func() {
			mark("TLS 开始")
		},
		TLSHandshakeDone: func(_ tls.ConnectionState, err error) {
			mark("TLS 完成")
			if err != nil {
				fmt.Printf("  TLS 错误: %v\n", err)
			}
		},
		GotConn: func(info httptrace.GotConnInfo) {
			mark("取得连接")
			fmt.Printf("  已复用=%t 空闲时长=%s\n", info.Reused, info.IdleTime.Round(time.Millisecond))
		},
		GotFirstResponseByte: func() {
			mark("收到首字节")
		},
	}
 
	req, err := http.NewRequest(http.MethodGet, target, nil)
	if err != nil {
		return err
	}
	req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
 
	resp, err := client.Do(req)
	if err != nil {
		return err
	}
	defer resp.Body.Close()
 
	if _, err := io.Copy(io.Discard, resp.Body); err != nil {
		return err
	}
 
	mark("响应读取完成")
	fmt.Printf("  状态=%s 协议=%s\n\n", resp.Status, resp.Proto)
	return nil
}

运行时给它一个你能访问的测试接口：

read -r -p "请输入测试接口地址: " TEST_URL
go run main.go "$TEST_URL"

如果第二次输出 已复用=true，且没有再次出现 TCP 或 TLS 阶段，说明客户端确实复用了连接。若没有复用，可以依次检查响应是否要求关闭、响应体是否完整读取、服务端是否提前关闭、池的空闲上限是否为零，以及两次请求是否真的落在同一个池键上。

把连接当成有生命周期的共享资源

现在回到开头的问题：第二次请求为什么常常更快？因为它可能继承了第一次请求已经支付的连接成本。但连接没关为什么又会出问题？因为每条闲置连接仍占资源，而且它随时可能被对端或中间设备先行关闭。

HTTP/1.1 用持久连接减少重复握手，却要依赖清晰的消息边界和连接池；流水线试图增加并发，却被固定响应顺序和重试风险限制；HTTP/2 用独立流解决应用层队头阻塞，但仍共享 TCP 的有序字节流；HTTP/3 把流放进 QUIC，缩小丢包阻塞范围，同时保留连接级拥塞控制与容量约束。

真正稳健的连接管理没有一个神奇开关。它需要连接池限制并发，用分层超时划出故障边界，用幂等设计控制重试，再用阶段耗时和关闭原因验证系统实际发生了什么。

下一步进入 Web 服务器内部时，你会看到这些连接怎样被监听套接字接收，又怎样交给进程、线程或事件循环处理。连接管理到这里没有结束，它只是从协议问题变成了服务器资源调度问题。