2026-06-02

SNI 与 ALPN——Wireshark 中 TLS 握手与 HTTP/2 协商

分析 TLS 握手中的 SNI 与 ALPN。诊断 Wireshark PCAP 中的 HTTP/2 协商失败、h2 与 http/1.1 回退、ClientHello 扩展、ServerHello ALPN 响应和代理终止问题。

许多“HTTP/2 不工作”事件实际上是 TLS ALPN 协商问题。当端点应该支持 HTTP/2 但流量回落时，用户搜索“TLS ALPN pcap”、“HTTP2 回退到 HTTP/1.1”、“ALPN h2 未协商”、“ClientHello ALPN 扩展”、“ServerHello 选择的协议”以及“为什么我的浏览器使用 HTTP/1.1”。

PCAP 手术很有用，因为 ALPN 证据存在于 TLS 握手中。如果捕获包含 ClientHello 和 ServerHello，您通常可以证明客户端是否提供了“h2”、服务器是否选择了它、代理是否终止了 TLS，或者连接是否从未有机会协商 HTTP/2。

ALPN 的作用

ALPN 表示应用层协议协商。它允许客户端和服务器在 TLS 设置期间就应用程序协议达成一致。

常见的 ALPN 值：

h2 用于基于 TLS 的 HTTP/2。
http/1.1 表示 HTTP/1.1。
专用系统的其他协议标识符。

如果客户端不提供“h2”，服务器就无法选择它。如果服务器不选择“h2”，即使服务器在其他地方支持 HTTP/2，连接也不会使用 HTTP/2。

常见症状

ALPN 故障显示为：

浏览器使用 HTTP/1.1 而不是 HTTP/2。
gRPC 连接失败。
CDN 有效，但 origin 无效。
反向代理降级协议。
负载均衡器终止 TLS 并转发 HTTP/1.1。
移动应用程序显示协议错误。
服务器指标显示没有 h2 流量。
HTTP/2 适用于一个主机名，但不适用于另一个主机名。

这些症状通常在 HTTP 层进行调试，但答案可能在 TLS 协商中。

ClientHello 证据

ClientHello 可以显示客户端是否提供 ALPN 以及它通告的协议。

有用的问题：

是否存在 ALPN 扩展？
优惠包括“h2”吗？
它还包括“http/1.1”吗？
SNI 是否存在且正确？
提供哪个 TLS 版本？
捕获是否在代理终止 TLS 之前进行？

如果 ClientHello 中缺少 h2，则服务器无法选择 HTTP/2。原因可能是客户端库配置、旧的 TLS 堆栈、禁用的 HTTP/2 选项或打开新上游连接的代理客户端。

ServerHello 证据

服务器端应从客户端的 ALPN 列表中选择一种协议。

问题：

服务器仅选择“http/1.1”。
服务器忽略 ALPN 响应。
在 ALPN 选择之前服务器握手失败。
到默认虚拟主机的证书或 SNI 不匹配路由。
TLS 终结器在公共端支持 h2，但不支持上游端。

数据包证据可以将服务器支持与路由和代理行为分开。

SNI 和 ALPN 一起

SNI 和 ALPN 经常相连。 SNI 选择的主机名可以确定应用哪个证书、虚拟主机和协议设置。

失败示例：

客户提供“h2”。
客户端发送错误的 SNI。
服务器返回默认证书。
默认虚拟主机不启用 HTTP/2。
连接回退到“http/1.1”。

在这种情况下，问题不是“HTTP/2 全局损坏”。这是主机名路由。

代理和负载均衡器终止

现代部署通常会拆分 TLS：

client -> CDN or load balancer -> reverse proxy -> origin

gRPC and ALPN

For gRPC troubleshooting, preserve:

Fallback is not always failure

Debug checklist

Use this workflow:

Final diagnosis

用数据包证据回答“SNI 与 ALPN——Wireshark 中 TLS 握手与 HTTP/2 协商”

直接答案是：分析器 label 或应用消息不能单独确定原因。应从 capture point 与 flow direction 开始，证明最后成功的 protocol boundary 和首个失败 boundary。另一位 reviewer 必须能找到支撑句子的 packet、gap 或 interval，并知道什么证据可以否定判断。

把抓包放到路径地图上

记录 client、server，以及中间的 proxy、load balancer、NAT 或 firewall。写明 interface、位置、clock、OS 和可见方向。client 附近的 capture 证明什么到达 client，但不能证明 server 没发送；server 附近只证明该位置的出口。对比两个观察点前，修正 clock offset，并按 flow tuple、TCP sequence 或 transaction ID 对齐。

检查 snap length、dropped packets、offload、capture filter、ring buffer 和开始时间。host 上的 bad checksum 可能是 offload artifact。大 segment 可能来自 GRO/TSO，并非 wire 上的一个 packet。有限文件里缺少 packet，不能在证明观察点本应看到它之前写成 network loss。

按顺序读取边界

边界	成功证据	有效失败证据
Link/IP	direction、addresses、route 一致	ARP/NDP 缺失、ICMP、MTU、asymmetry
TCP	SYN、SYN-ACK、ACK、sequence 正确	retransmission、RST、zero window、timeout
TLS	ClientHello、ServerHello、handshake 推进	alert 或 SNI/ALPN/certificate boundary
Application	完整 request 与对应 response	status、gap 或提前 close
User	response time 或 failure window	stall 对应已证实边界

在第一个没有成功证据的边界停止。TCP 未建立时不要先解释 HTTP。request 到达 proxy 却未出现在 upstream，边界位于 proxy 或其路径；upstream 已收到但 timeout 前没有 response，应通过 ACK 与 bytes 推进区分 application delay 与 network loss。

分开 observation 与 hypothesis

observation 可以指到记录：“client 发送到指定 sequence，sender 重复同一 segment 三次，本观察点没有出现推进 ACK。”hypothesis 是“路径丢失 segment”。另一位置的 capture 或 dropped records 可能否定它。为每个假设写一项支持证据与一项反证。

retransmission 或 duplicate ACK 不能自动分配责任。reordering、loss、capture artifact、receiver delay 会产生相似 label。关联 direction、sequence、ACK、SACK、RTT、window 与 application timing。DNS/DHCP 对齐 transaction ID 与 attempts，HTTP 对齐 request/response，TLS 对齐 handshake direction。

编辑前保全原件

计算 original checksum，并保持原件不变。filter、trim、redaction 在 working copy 上完成。记录 input、operation、时间、前后 packet count、output checksum 与理由。timestamp rewrite 或删除 packets 后，该副本不再适合某些 timing 或 sequence 结论。

addresses 与 identifiers 使用一致 aliases，保持 endpoint 可追踪。不能删除判断所需的 port、direction、length。secret mapping 单独保存。通过抓取与导出范围和 PCAP Surgery 概览检查派生文件。

发布前 QA

title 与 answer 是否回答同一 flow？每个 duration 是否写明 clock 与观察点？首个 failure boundary 是否明确？有没有 alternative explanation？复测是否只改一项？original 是否保留？限制结论：“该文件证明指定 interval 的 client 附近行为，不证明 server 内部执行。”

Semrush 验证的一般词 PCAP analyzer 只由产品页负责。技术博客保持自身问题，不编造 volume 或 KD。

flow 台账与排除实验

围绕“SNI 与 ALPN——Wireshark 中 TLS 握手与 HTTP/2 协商”为每个方向建立一行：endpoint aliases、首末 packet、已发送和已确认 bytes、resets、retransmissions、requests、responses。相同 hostname 不等于同一连接，source port、开始时间、TCP initial sequence 用于区分 sessions。经过 NAT 或 proxy 时记录 flows 的对应关系，不期待 sequence 或 ports 相同。

计算 TCP，不数 labels

追踪 receiver 的 next expected sequence。payload 按长度推进 sequence，SYN 与 FIN 也各占一个编号。较高 segment 到达后持续 Duplicate ACK，支持 loss 或 reordering。SACK blocks 说明哪些 ranges 到达，但不能证明丢失位置。sender 侧看到 retransmission 而 receiver 侧没有，应检查中间 path；sender capture 连 original 都没有，应检查 capture loss 或 offload。

区分 duplicate ACK 后的 fast retransmit 与沉默后的 RTO。比较事前 RTT、advertised window、zero-window probes、burst 与 transfer size。overlap、spurious retransmission、从 flow 中段开始抓取都会改变 analyzer label，label 数量不等于 loss 数量。

用边界测量时间

使用 request first byte、request complete、response first byte、response complete。TTFB 不自动等于 server time。response 前 retransmission 可能增加 network delay；request 已完整 ACK 后长时间沉默更支持 application wait。写明数值、unit、clock、point。

两个观察点先在双方向匹配特征 packet，估算 offset，再使用各文件内部 intervals。clock 不确定时给 range。成功与失败 window 应保持相近 duration 与 load。

协议专项问题

DNS 检查 ID、name、type 与 retry resolver；DHCP 检查同一 client identifier 的 Discover/Offer/Request/ACK；TLS 找各方向最后 handshake message 与 alert；HTTP 识别 4xx/5xx 生成者及 upstream flow；TCP close 识别 FIN/RST sender 与未 ACK bytes。

决定性实验与交付

选择两个竞争 hypothesis 和一个区分实验。另一端 capture 区分 network loss 与 measurement loss；test 中关闭 offload 检查 artifact；固定 path 发送相同 request 检查 intermittency；upstream log 对照 packet boundary 检查 application delay。执行前先写预期。

reviewer 能用 metadata 重复计算、找到同一 boundary 并理解限制，才算验收。交付 original/derived checksums、filter、packet ranges、trim/redaction 操作，以 owner、next action 和可测量 close 条件结束。

复现性复核

从新 connection 使用相同 inputs 与 filters 重复三次。ports 与 initial sequence 可以变化，但 boundary、direction、response pattern 应当重复。完整报告成功与失败。修复只改一个变量，并确认预期 packet behavior 发生变化，而不只是应用消息消失。

在另一设备打开 derived copy。reviewer 应找到 flow aliases、clock、capture point、最后成功、首个失败和 alternative。redaction 后重新搜索 hostname、query、header、sensitive payload，同时保留判断所需 length 与 direction。列出未测范围：反方向、IPv6、reconnect 或其他 load。

最终状态只能是范围内已证明、仍可复现、或因指定 capture 缺失而未决。只验证一个 flow 时不能写成“整个网络已修复”。