Http2 · XB 现场笔记

HTTP3 走 UDP，HTTP2 仍走 TCP 兜底

Sat, 12 Feb 2028 00:00:00 +0000

HTTP/3 把 QUIC 跑在 UDP:443 上，值得在意的理由是丢一个包的代价。TCP 连接上所有流共用一个字节流，丢一个段就会挡住它后面所有数据的交付，直到重传到达。QUIC 让每条流各自拥有丢失恢复，同一个丢包只挡住数据真的在那个包里的流。

别扭的地方在于这不是一个开关。客户端必须先知道服务器会说 HTTP/3 才可能去试，而它得知这件事所走的那条路径，恰恰是你想优化的那条。

两种传输，一个端口号

UDP:443 和 TCP:443 属于彼此独立的命名空间，所以一个监听可以同时占住两者。这就是为什么 nginx 的 server 块可以把 listen 443 quic reuseport; 和 listen 443 ssl; http2 on; 并排放着，用同一个端口号同时服务 QUIC 和 HTTP/2。reuseport 比看起来更重要：没有它，第二次绑定 UDP:443 会拿到 EADDRINUSE，而这正是两个 server 块都声称要占用 QUIC 监听时看到的报错。

QUIC 不是「HTTP/2 搬到 UDP 上」。它把传输握手和 TLS 握手合成一趟——一个往返，复用会话时是零个——并且携带一个与地址和端口无关的连接 ID。这个 ID 让连接迁移成为可能，同时也让那些假定一条流永远待在一个五元组上的负载均衡器当场失效。还要记住 QUIC 要求整条路径都能过 UDP：企业网络、机场 Wi-Fi 和部分移动运营商至今仍在整段丢弃 443 端口的 UDP，这正是兜底路径必须一直可用的原因。

Alt-Svc 是客户端得知的方式

对某个源的第一次连接永远是走 TCP 的 HTTP/2，因为客户端此时一无所知。响应里带着一条通告：Alt-Svc: h3=":443"; ma=86400。解析开来就是协议 h3、authority :443、新鲜期 86400 秒，也就是 24 小时。下一次连接该源时客户端会先试 QUIC，所以升级发生在后续某次访问，永远不会发生在第一次。

ma 才是咬人的地方。只要通告还在新鲜期内，客户端每建立一条新连接都会先试 HTTP/3——哪怕 HTTP/3 已经反复失败。把 UDP:443 被中间盒静默丢弃的情形建个模型：客户端在 QUIC 探测超时退避里烧掉 15 秒（1、2、4 再到 8 秒）才回退到 HTTP/2。按每天 20 次访问算，就是每天白白丢掉 300 秒，一直持续到一天后缓存过期。反过来，不等 QUIC 放弃就并行发起 TCP 连接，同一条被阻断的路径 0.1 秒就能出结果。回退的代价是设计选择，不是协议开销。

0-RTT 与连接迁移是两处锋利的边缘

0-RTT 允许回访客户端在第一个飞行包里就发出应用数据，用的是上一会话留下的票据。这些数据可以被重放——抓到那个飞行包的人可以再发一次——所以只有可以安全重复的请求才该放进去。把「创建订单」放在 0-RTT 里，等于预订了一笔重复订单。

连接迁移是另一处。QUIC 用连接 ID 而不是地址来标识连接，所以从 Wi-Fi 漫游到蜂窝网的客户端能保住同一条连接。把一台按五元组做哈希的负载均衡器放在前面，这条继续存在的连接就会落到另一个后端：八个后端的情况下，把同一客户端漫游前后的键算出来，先落到 7 号，再落到 4 号。协议的移动性变成了负载均衡器的问题。

坏掉的样子

第一种失败，是客户端缓存着 Alt-Svc，而网络把 UDP 丢了。它的表象是整整一天里每次导航首字节都很慢，而服务器日志里没有任何异常——QUIC 的 Initial 根本没到，也就没有东西可记。把服务端的 HTTP/3 连接数和客户端感知到的延迟放在一起比；h2 路径健康却出现巨大落差，就是它的特征。缓解办法是缩短 ma、并行竞速 TCP 连接，以及不要在你验证不了的路径上通告 h3。

第二种失败，是连接迁移打坏了会话亲和性。移动客户端在会话中途换地址，HTTP/3 把连接保住了，而此刻接管它的后端没有任何原先那台持有的缓存或会话状态。它的表象是间歇性的认证失败、缓存不命中、上传做了一半，而且只出现在移动端客户端上——这也是它难以复现的原因。按连接 ID 路由，或者把亲和性钉在一个能扛住地址变化的东西上。

快速验证

确认两条路径都真的活着：

curl -sI https://example.com/ | grep -i alt-svc
curl -s --http3-only -o /dev/null -w '%{http_version} %{time_appconnect}\n' https://example.com/
nginx -T 2>/dev/null | grep -nE 'listen .*quic|http3|Alt-Svc'
ss -lun | grep -E ':443\b'

第一条应当打出一条带有限 ma 的 h3 通告。第二条在 UDP 通的时候打出 3 和很小的连接耗时，路径被挡时则直接失败——第一条成功而这里失败，就是典型的中间盒情形。第三条看配置是否真把 QUIC 和响应头接在了一起，第四条证明 443 上确实有一个 UDP 套接字被绑定。

来源

RFC 9114 HTTP/3，HTTP/3 在 QUIC 之上的语义，已核验 2026-09-16。
RFC 7838 HTTP 替代服务，Alt-Svc 头及其新鲜期，已核验 2026-09-16。
ngx_http_v3 模块，nginx 的 QUIC 与 HTTP/3 指令，已核验 2026-09-16。
RFC 9000 QUIC，流级丢失恢复、连接 ID 与 0-RTT，已核验 2026-09-16。

HTTP/2 多路复用消除排队

Sat, 16 Jan 2027 00:00:00 +0000

HTTP/2 通过多路复用解除 HTTP 响应的顺序约束，但不同流仍然共享 TCP 连接及其故障边界。取消就是一个值得单独验证的场景：终止某个请求，不一定需要破坏相邻请求或可复用连接。这是一项有明确作用范围的能力，不能扩写成所有流在任何条件下都互不影响。

流不是底层套接字

HTTP/2 在连接内部标识单条流。RFC 9113 定义的 RST_STREAM 用于终止某条流，既可以表达取消，也可以报告流错误；它并不是重置整个套接字的 TCP reset。只要连接本身仍然可用，实现就可以停止一次交换，同时让其他流继续推进，而不必为每次取消重新建立连接。

这与 HTTP/1.1 的持久连接并不矛盾，后者本来就允许一条连接承载多次交换。HTTP/2 新增的是交错传输与流级生命周期控制，而不是首次发明连接复用。TCP 的有序交付、拥塞控制、连接级 DATA 流控以及服务端资源仍然约束进度；即使一次请求取消没有影响其他流，连接故障也可能同时中断多个请求。

取消还不等于撤销已经完成的业务。服务器可能早已提交事务，或调用了另一个服务。客户端读取正文时得到取消错误，无法证明这些操作没有发生。因此，是否重试仍须依据业务语义、幂等保证或可查询的执行结果，不能仅凭网络层已经取消，就把再次提交认定为安全操作。

收到响应头不代表正文成功

成功状态码出现在正文之前。服务端可以先发送并刷新 HTTP 200，再长时间等待，或者在传输内容时失败。状态、正文完整性和业务结果应分别记录。Client.Do 返回了响应对象，只说明客户端已经拿到响应头，不能据此把整个响应标为读取成功，更不能省略后续读取错误的处理。

Go 的出站请求上下文控制取消；对于入站 HTTP/2 请求，一次取消可以让服务端对应请求的上下文结束，而不需要关闭整条连接。处理函数在等待或访问依赖时，应观察并传递该上下文。运行时不会自动撤销任意业务动作。Client.Timeout 还覆盖响应头到达之后的正文读取，不能把它理解成只约束握手或等候首字节。

坏掉的样子

如果几个请求共用一个父上下文，取消父上下文本来就会影响它们；关闭底层连接也比取消单个请求的范围更大。请求自己的时限应由请求自己的取消范围管理。不能对共享套接字设置整体期限后，又声称产生的超时只作用于一条 HTTP/2 流；排障时必须核对取消信号的真正拥有者。

遗弃正文可能保留资源或占用流控额度。适合完整消费的响应应读完，已经结束或取消的正文也必须关闭。未读数据是否妨碍相邻流，与库的缓冲和窗口更新策略有关。流数量上限、共享连接额度和后端容量仍然存在；一个小实验能成功取消，不代表高负载时也没有相互影响。

快速验证

保存为 cancel_probe.go，使用 Go 1.23 或更新版本运行 go run cancel_probe.go。本地服务使用经过验证的 TLS 1.3 协商 HTTP/2。两个处理函数先刷新 HTTP 200 响应头，再让正文等待。客户端随后只取消第一个请求；另一个响应保持打开，双方都使用同一条被编号的 TCP 连接。

package main

import (
 "context"
 "crypto/tls"
 "errors"
 "fmt"
 "io"
 "net"
 "net/http"
 "net/http/httptest"
 "net/http/httptrace"
 "runtime"
 "sync/atomic"
 "time"
)

type connectionKey struct{}

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 cancelObserved, releaseSurvivor, stop := make(chan struct{}), make(chan struct{}), make(chan struct{})
 var connections, handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 w.Header().Set("X-Connection-ID", fmt.Sprint(r.Context().Value(connectionKey{})))
 w.Header().Set("Content-Type", "text/plain")
 w.WriteHeader(http.StatusOK)
 w.(http.Flusher).Flush()
 switch r.URL.Path {
 case "/cancel":
 select {
 case <-r.Context().Done():
 close(cancelObserved)
 case <-stop:
 }
 case "/survive":
 select {
 case <-releaseSurvivor:
 fmt.Fprint(w, "survived")
 case <-r.Context().Done():
 case <-stop:
 }
 case "/after":
 fmt.Fprint(w, "ready")
 }
 }))
 server.Config.ConnContext = func(ctx context.Context, _ net.Conn) context.Context {
 return context.WithValue(ctx, connectionKey{}, connections.Add(1))
 }
 server.EnableHTTP2 = true
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()
 defer close(stop)
 config := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 check(!config.InsecureSkipVerify, "certificate verification must stay enabled")
 transport := &http.Transport{TLSClientConfig: config, ForceAttemptHTTP2: true, MaxConnsPerHost: 1}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 open := func(ctx context.Context, route string) *http.Response {
 request, err := http.NewRequestWithContext(ctx, http.MethodGet, server.URL+route, nil)
 must(err)
 response, err := client.Do(request)
 must(err)
 check(response.StatusCode == 200 && response.Proto == "HTTP/2.0", "HTTP/2 response required")
 check(response.Header.Get("X-Connection-ID") == "1", "streams must share the first TCP connection")
 check(response.TLS.Version == tls.VersionTLS13 && response.TLS.NegotiatedProtocol == "h2", "TLS 1.3 and h2 required")
 check(len(response.TLS.VerifiedChains) > 0, "verified server certificate required")
 return response
 }
 firstContext, cancel := context.WithCancel(context.Background())
 defer cancel()
 first := open(firstContext, "/cancel")
 survivor := open(context.Background(), "/survive")
 cancel()
 body, readError := io.ReadAll(first.Body)
 closeError := first.Body.Close()
 must(closeError)
 check(errors.Is(readError, context.Canceled) && len(body) == 0, "first stream must report cancellation")
 select {
 case <-cancelObserved:
 case <-time.After(2 * time.Second):
 panic("server did not observe stream cancellation")
 }
 close(releaseSurvivor)
 body, readError = io.ReadAll(survivor.Body)
 closeError = survivor.Body.Close()
 must(readError)
 must(closeError)
 check(string(body) == "survived", "sibling stream must complete")
 var reused atomic.Bool
 var handshakes atomic.Int64
 trace := &httptrace.ClientTrace{
 GotConn: func(info httptrace.GotConnInfo) { reused.Store(info.Reused) },
 TLSHandshakeStart: func() { handshakes.Add(1) },
 }
 after := open(httptrace.WithClientTrace(context.Background(), trace), "/after")
 body, readError = io.ReadAll(after.Body)
 closeError = after.Body.Close()
 must(readError)
 must(closeError)
 check(string(body) == "ready" && reused.Load() && handshakes.Load() == 0, "connection must remain reusable")
 check(connections.Load() == 1 && handled.Load() == 3, "three streams must use one TCP connection")
 fmt.Println("cancel: context canceled; server observes cancellation")
 fmt.Println("survive: body complete on connection 1")
 fmt.Println("after: connection 1 reused, no new TLS handshake")
 fmt.Println(runtime.Version())
}

第一个正文的读取必须返回能匹配 context.Canceled 的错误，且没有正文数据；服务端还必须独立观察到该请求上下文被取消。程序随后才释放相邻请求，让它完整返回 survived。这样，两份已经成功到达的响应头，对应不同的正文结果，同时并没有使用两条独立连接掩盖影响。

第三次请求必须在连接一上返回 ready。GotConn 记录复用，第三次请求的 TLSHandshakeStart 计数保持为零；服务端同时断言只接受一条 TCP 连接，却处理了三个请求。这些证据能够区分“原连接仍然可用”和“客户端悄悄换了一条连接才成功”，不能只根据最后一次请求成功就判定前者。

已核验的 macOS、Go 1.27.0 运行通过全部断言。每次请求限时两秒，等待服务端观察取消另设两秒上限；清理时释放等待中的处理函数。证书验证始终开启，不修改公共服务，也不向系统安装信任根。程序正常结束时，响应正文和本地连接资源均已关闭或回收。

这里检查的是 Go 提供的可观察行为，没有抓包、解码或断言某个具体 RST_STREAM 错误码。协议机制的解释来自 RFC 9113。实验也没有测试丢包、流控耗尽、整条连接失败、生产业务副作用或吞吐量。要提出更强的隔离性和安全重试结论，还需要分别设计相应实验，而不能从这次通过的断言直接外推。

来源

RFC 9113：HTTP/2，流终止、共享流控与 TCP 边界，已核验 2026-09-09。
Go net/http，请求取消、响应正文、连接复用与超时，已核验 2026-09-09。
Go crypto/tls，协议协商与经过验证的证书链，已核验 2026-09-09。

Http2 · XB 现场笔记

HTTP3 走 UDP，HTTP2 仍走 TCP 兜底

两种传输，一个端口号

Alt-Svc 是客户端得知的方式

0-RTT 与连接迁移是两处锋利的边缘

坏掉的样子

快速验证

来源

HTTP/2 多路复用消除排队

流不是底层套接字

收到响应头不代表正文成功

坏掉的样子

快速验证

延伸阅读

来源