上周帮朋友公司查一个线上故障：新上线的秒杀系统在流量峰值时，部分安卓 5.0 的老手机打不开下单页，但 iOS 和新安卓机完全正常。抓包一看，问题出在 TLS 握手阶段——服务端默认启用了 TLS 1.3，而那些老设备只支持到 TLS 1.0，中间代理又没做降级透传，直接断连。
协议兼容不是“能连上”就完事
很多人以为只要客户端和服务端都实现了某个协议（比如 HTTP/2），就能稳稳跑起来。其实不然。高并发场景下，协议兼容性会暴露得特别狠：不是连不上，而是连得慢、连得断、连得错。比如 Nginx 默认开启 HTTP/2 后，某些旧版 curl（7.39 以下）发请求会卡在 HEADERS 帧解析，超时后重试，瞬间把连接池打满。
真实踩过的坑
我们曾在线上灰度 HTTP/3 时发现：Wi-Fi 下一切正常，但某款国产千元机在移动网络下频繁 421 错误。查下来是它的 TCP 栈对 QUIC 的 UDP 分片重组有缺陷，服务端一并发多个 Initial 包，它就丢帧。最后方案不是升级手机系统（做不到），而是对这批 UA 做 HTTP/2 回退，并加了连接复用白名单。
常见协议组合雷区
- gRPC（默认 HTTP/2） + Nginx 1.12 以下：不支持 ALPN，必须显式配置 http2 on；
- WebSocket over TLS 1.3 + Java 8u251 以前版本：握手失败率在 QPS > 5000 时飙升至 12%；
- HTTP/1.1 管道化（pipelining） + CDN 缓存节点：多数 CDN 已禁用，但仍有老旧负载均衡器会乱序响应。
这些都不是理论问题，是凌晨三点被叫醒、盯着监控曲线和 access_log 一行行比对才抠出来的。
怎么测才靠谱？
光用 ab 或 wrk 模拟并发不够。得混入真实协议栈指纹：
curl -v --http1.1 --tlsv1.0 https://api.example.com/order > /dev/null 2>&1
curl -v --http2 --tlsv1.2 https://api.example.com/order > /dev/null 2>&1再配合 tc 模拟弱网（丢包 3%、延迟 200ms），看不同协议路径下的成功率和 p99 延迟。我们有个小脚本，自动遍历 12 种 client hello 组合，每种压 30 秒，输出失败率热力图。
协议兼容性不是上线前点个“测试通过”就结束的事。它是每次扩容、每次协议升级、每次引入新中间件时，都得重新掂量的一块硬骨头。