协商决定上层跑什么协议
应用层协议协商在握手中完成：客户端给出一份候选协议列表，服务端从中选一个并在自己的握手报文中确认。选中结果决定了后续报文按哪个协议解析，也决定了抓包工具用哪套解码器。常见的取值是 HTTP/2 与 HTTP/1.1。判断时要以服务端确认的那一项为准——客户端的列表只表达意愿；双方没有交集时，握手可能直接失败，也可能按实现回落到默认协议。
基本信息
| 适用平台 | Wireshark / tshark 解析的 TLS 握手 |
|---|---|
| 字段 | tls.handshake.extensions_alpn_str |
| 常见取值 | h2、http/1.1 |
| 判读要点 | 只有服务端确认的取值才是最终结果 |
典型使用场景
- 页面实际走的是哪个协议版本，确认与预期是否一致
- 改造升级后验证是否真的切换到新协议
- 排查抓包工具按错误协议解析导致的字段缺失
- 对比不同客户端的协议支持能力
- 定位中间设备改写协商结果造成的行为不一致
- 为性能对比测试固定协议版本提供依据
观察要点
观察要点
tls.handshake.extensions_alpn_str contains "h2"
# 客户端握手: 候选列表，例如 [h2, http/1.1]
# 服务端握手: 确认选中的一项，例如 [h2]
# 无交集时可能握手失败，也可能回落到默认协议
# 抓包工具的解析层次按协商结果自动选择，选错会导致字段读不到观察项逐项读法
| 观察项 | 含义 | 异常表现 |
|---|---|---|
| 客户端候选列表 | 支持的协议意向 | 列表缺失说明客户端未声明 |
| 服务端确认项 | 本次最终使用的协议 | 与列表无交集会出现回落或失败 |
| 后续报文解析 | 按确认项选择的解码方式 | 解码不符说明协商结果被改写 |
| 协议版本与表现 | 是否与业务预期一致 | 不一致需查中间设备或配置 |
抓包工具会根据协商结果自动选择解析层次，若协商字段被改写，后续解码可能整段读不到，遇到「字段突然都没了」先查这里。
中间设备改写协商结果会造成前后端对协议认知不一致，表现为部分请求行为异常而非全部失败。