9.1 加密洪流：QUIC 与 HTTP/3 的解剖

9.1 加密洪流：QUIC 与 HTTP/3 的解剖

主流浏览器与服务已大量迁移到 HTTP/3——它脚下的 QUIC 是个把传输层与加密层一起装进 UDP 的协议。对勘验员来说，这意味着两件事：传统"TCP 443 加 TLS"的解剖套路失效一半；但第 4 章的字段功夫与 6.1 节的钥匙机制几乎原样可用。本节讲 QUIC 在解剖台上的样子：可见结构、连接标识、解密沿用，以及加密 DNS 对 53 端口勘验的冲击。

QUIC 是什么形态：一次迁移的对比

先看清楚迁移前后在同一次网页打开中的差别：

# 传统栈：TCP 上的 TLS
$ tshark -r classic.pcapng -Y "tcp.port==443 && tls.handshake.type" -T fields \
    -e frame.number -e tcp.flags.syn -e tls.handshake.type | head -6
3	1	-        <- SYN：先谈传输层
5	1	-        <- SYN+ACK
7	0	-        <- ACK：连接建立，三帧才走到加密层
8	0	1        <- ClientHello：然后谈加密
10	0	2        <- ServerHello
...

# QUIC 栈：UDP 上的加密传输
$ tshark -r modern.pcapng -Y "udp.port==443 && quic" -T fields \
    -e frame.number -e quic.long.packet_type -e quic.version | head -6
4	-	0x00000001   <- Initial：传输与加密同一步起谈
6	-	0x00000001
7	-	0x00000001   <- 同类型多帧：Initial 可跨 UDP 包
9	0	-            <- 短头包：进入一比特标志与连接标识阶段
​

两相对比的要点：QUIC 没有握手前的"裸 TCP"阶段，第一个包（Initial）就同时携带加密协商材料；版本字段 0x1 即 QUIC 版本 1。从勘验视角，QUIC 的报文头大部分是密文——长头包的可见部分只有标志、版本、连接标识与包号的下几位，短头包连版本都不带。

连接标识：新的追流坐标

QUIC 长头包里明文的连接标识（CID）承担了"这条连接是谁"的角色——它独立于地址存在，客户端换网（从无线切到有线、地址变化）后 CID 不变，连接照旧。对勘验的直接意义：

# 按连接标识追流：地址迁移前后一以贯之
$ tshark -r modern.pcapng -Y "quic" -T fields -e frame.number -e ip.src -e quic.scid \
    | head -5
4	192.168.31.14	0x1f2e3d4c5b6a7988
9	192.168.31.14	0x1f2e3d4c5b6a7988
28	10.20.30.40	    0x1f2e3d4c5b6a7988   <- 地址变了 CID 没变：同一连接的迁移
​

第三行的源地址换了、连接标识没换——按五元组思维这是"新连接"，按 CID 思维这是"同一连接的迁徙"。移动端排障（弱网切换、网络迁移）里，这个判定直接决定"连接被重建"与"连接存活"两种截然不同的结论。

解密的沿用与 HTTP/3 的解剖

6.1 节的钥匙机制对 QUIC 原样适用，且浏览器导出的密钥日志里两类钥匙并存：

$ tshark -r modern.pcapng -o "tls.keylog_file:$HOME/tlskeys.log" \
    -Y "http3" -T fields -e http3.frame.type -e frame.number | head -5
0	14     <- HEADERS 帧：请求头
0	21
1	29     <- DATA 帧：请求体
0	34     <- 响应头
​

解密成功后，HTTP/3 的帧结构（头部帧、数据帧、各类控制帧）如 4.3 节的 HTTP/2 一样可筛可导——第 5 章的筛法语言无缝迁移。掌握 QUIC 勘验的最短路径就是：6.1 的钥匙加 9.1 的 CID，其余功夫全是旧知识的平移。

DoH：53 端口的勘验正在失效

加密 DNS（DoH，DNS over HTTPS）把域名解析装进 443 的加密流量里——4.3 节那套"看 53 端口读域名"的观察法对它失效。影响与对策：

# 传统 DNS 观察：明文直读
$ tshark -r dns-era.pcapng -Y "dns" -T fields -e dns.qry.name | head -2
www.example.org
api.example.org

# DoH 环境：53 端口静悄悄，域名藏在解密后的 HTTP/2 里
$ tshark -r doh.pcapng -Y "dns" -T fields -e dns.qry.name | wc -l
0
$ tshark -r doh.pcapng -o "tls.keylog_file:$HOME/tlskeys.log" \
    -Y "http2.headers.authority contains resolver" -c 3
dns-resolver.vendor-a.net
​

对策分两层：有钥匙（终端受控）时解密后照常看；无钥匙时退而求其次——SNI（4.3 节）仍能暴露访问目标，DoH 解析器本身的域名也是明文。观察点在收缩但没归零，这是加密时代的勘验常态：把可看的每一寸明文用到极致。

⚠️ 一个版本相关提醒：QUIC 与 HTTP/3 的解析支持仍在快速迭代，不同版本对同一文件的字段命名与解密成功率有差异。遇到"解不开"先升级（8.2 节的升级先于优化原则），再查密钥与握手完整性（6.1 失败三查照样适用）。

QUIC 勘验清单：现场可用的过滤器与判定

把本节的观察点收进一张随身清单（配合 5.2 节的套路风格）：

# 清点 QUIC 流量：UDP 443 上的 QUIC 包
$ tshark -r modern.pcapng -Y "quic" -T fields -e quic.version | sort | uniq -c
  1841 0x00000001     <- 版本 1，主流
    12 0x00000000     <- 版本协商包：版本谈不拢时的现场

# 版本协商失败后会怎样：看协商包之后有没有回退到 TCP
$ tshark -r modern.pcapng -Y "tcp.port==443 && tls.handshake.type==1" -c 2
# 若紧跟着出现 TCP 上的 ClientHello：客户端回退机制生效，功能未受影响

# HTTP/3 是否真的被用上（解密后）
$ tshark -r modern.pcapng -o "tls.keylog_file:$HOME/tlskeys.log" \
    -Y "http3" -T fields -e http3.frame.type | sort | uniq -c
  412 0     <- HEADERS 帧：应用语义在 HTTP/3 上跑

# QUIC 连接迁移检测：同 CID 不同地址（本节正文的现象）
$ tshark -r modern.pcapng -Y "quic" -T fields -e ip.src -e quic.scid \
    | sort -u | awk '{print $2}' | sort | uniq -c | awk '$1>1'
2 0x1f2e3d4c5b6a7988    <- 这个 CID 出现在两个地址：发生过迁移
​

四条过滤器对应四个判定：QUIC 占比（迁移程度）、版本协商（兼容性）、HTTP/3 生效（灰度验证）、连接迁移（移动端体验）。第 9.1 节的实战框架到此完整：外可见（版本、CID、封装），内可解（钥匙解密后的 HTTP/3 帧）。

常见疑问

**问：QUIC 流量在会话矩阵里显示为什么形态？**UDP 443 的高频短包会话。一个"页面加载"在 TCP 时代是几条长会话，QUIC 时代可能是一条连接上的多个流——矩阵的行数变少、单行包数变多。看到这个形态变化不用慌，用 CID 与流编号（解密后）重新组织视图即可。

**问：网络设备拦 UDP 443 会发生什么？**QUIC 建连失败，多数客户端静默回退到 TCP 443（上面的回退检测正是看这个）。用户"感觉变慢了一点"但说不出为什么——勘验时清点回退比例，就是量化"QUIC 被拦"影响的直接手段。

结案要点

• QUIC 把传输与加密合并进 UDP：Initial 一步起谈，短头包大面积密文。
• CID 是新追流坐标：地址迁移后流不断，五元组思维会误判。
• 钥匙机制原样沿用：解密后 HTTP/3 帧全部可筛，旧功夫平移即可。
• DoH 让 53 端口观察失效：有钥匙解密看，无钥匙用 SNI 顶上。
• 观察点收缩是常态：把每寸明文用到极致。

协议在变，部署环境也在变——下一节把采集功夫搬进容器与实时流水的世界。