第2章：TLS握手过程回顾——ClientHello与ServerHello
要排查协议不匹配问题，咱们先得把TLS握手的“开场白”彻底搞清楚。说白了，整个握手就是客户端和服务器互相“亮底牌”的过程。而ClientHello和ServerHello就是第一回合的核心。我见过不少工程师上来就翻协议栈日志，却忽略了这两个消息里最关键的字段，结果绕了一大圈。
2.1 握手概览：从Hello到密钥
TLS握手（以1.2/1.3为例）通常分为这几步：
- 客户端发送
ClientHello——宣布我能用什么版本、支持什么密码套件、有啥随机数。 - 服务器回复
ServerHello——选定版本、密码套件，也扔个随机数。 - 后续交换证书、密钥协商（比如ECDHE）、完成校验等。
- 最后双方生成会话密钥，开始加密通信。
为什么先要回顾这个？嗯，协议不匹配的根源，往往就藏在ClientHello和ServerHello的字段比对里。你想想看，客户端说“我支持TLS 1.2和1.3”，但服务器只认TLS 1.1，那直接就被拒了。或者客户端列的密码套件全是ECDHE，服务器却只支持RSA密钥交换……握手直接挂掉。
核心思路：每次排查不匹配故障，我都习惯先抓包看这两条消息。手里有Hello，心里不慌。
2.2 ClientHello：我在说什么？
先看客户端发出的第一条消息。我用Wireshark抓过N次，里面最值得关注的字段如下：
| 字段 | 含义 | 常见问题 |
|---|---|---|
version | 客户端声明的最高TLS版本（如0x0303代表TLS 1.2） | 版本号太低（比如0x0301/TLS 1.0）会被高版本服务器拒绝 |
random | 32字节随机数，用于密钥派生 | 一般没问题，但重复使用会有安全风险（很少见） |
session_id | 恢复会话的ID | 如果有但不一致，可能导致会话复用失败 |
cipher_suites | 客户端支持的密码套件列表（按优先级） | 列表太窄、或只含老旧套件，与服务器无交集 |
compression_methods | 通常是空（NULL） | 若包含非NULL压缩，部分服务器直接拒绝 |
extensions | 扩展字段，比如SNI（服务器名称指示）、ALPN（应用层协议协商） | 漏传SNI可能导致多域名服务器无法选择正确证书；ALPN不匹配则HTTP/2协商失败 |
拿个真实场景说事。我记得有一次客户反馈连接某金融平台失败，抓包发现ClientHello里的cipher_suites只带了三个：TLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_3DES_EDE_CBC_SHA。而服务器只支持ECDHE_RSA_AES128_GCM_SHA256。结果当然就是握手失败。你想想看，客户端把菜点得太保守了，服务器厨师根本做不了。
实战提示：在ClientHello里，extensions字段尤其重要。比如supported_versions扩展（TLS 1.3时）会覆盖version字段。我见过因为客户端version写0x0303（TLS 1.2）但supported_versions里没列1.3，导致服务器以为客户端不支持TLS 1.3的奇怪踩坑。
2.3 ServerHello：服务器怎么回应的？
服务器收到ClientHello后，会从中选一个版本、一个密码套件，然后发回ServerHello。这个响应长度通常比ClientHello短，但字段简洁有力：
| 字段 | 含义 | 不匹配时的典型表现 |
|---|---|---|
version | 服务器选定的TLS版本 | 如果客户端最低版本高于此值，客户端也会拒绝 |
random | 服务器生成的随机数 | 没问题 |
session_id | 如果恢复会话则回原ID，否则为新ID | 客户端可能因为ID不一致而放弃恢复 |
cipher_suite | 服务器从客户端列表中选中一个密码套件 | 若选中的套件客户端不认识（极少），则客户端Alert |
compression_method | 默认NULL | 非NULL可能触发客户端拒绝 |
extensions | 服务器支持的扩展，比如key_share（TLS 1.3） | 扩展缺失或不一致会中断握手 |
关键的一点是：服务器不能自作主张。它只能从客户端带来的列表里挑。所以如果客户端没带某个版本，服务器返回一个更高的版本，客户端会直接发Alert断开。我遇到过一个安卓客户端因为不支持TLS 1.3扩展，服务器却选了TLS 1.3，结果握手直接卡死。
2.4 协议版本协商的“潜规则”
所有不匹配问题里，版本不匹配占了至少一半。咱们来看看版本协商到底怎么进行的：
- 客户端在
ClientHello.version写它支持的最高版本（比如TLS 1.2）。 - 服务器读这个版本，再结合自己的配置，选一个≤该版本且自己支持的版本。
- 服务器把选中版本写在
ServerHello.version里返回。 - 客户端检查服务器返回的版本是否在自己支持的版本范围内，不是则告警。
这里有坑。举个例子，客户端支持TLS 1.3和1.2，但在extensions.supported_versions里只列了1.2（因为代码写错了）。服务器收到一看version字段是1.2，再查supported_versions也只有1.2，那服务器就以为客户端不支持1.3。这就是经典的“版本降级”或“版本不匹配”假象。我之前排查一个CDN故障时就是靠抓包对比这两个字段才发现问题。
注意：某些老旧客户端会直接在version字段写一个低版本（比如TLS 1.0），但通过supported_versions扩展声称支持更高版本。服务器如果只读version而忽略扩展，就会选择过低版本，导致加密强度不够。
2.5 密码套件协商——从列表到唯一选择
密码套件协商是另一个重灾区。客户端按优先级罗列一套密码套件（例如TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256, ...）。服务器从里面选一个自己支持的。如果客户端列的全是RSA或DH传统套件，而服务器只支持ECDHE+AEAD，那就没有交集，握手失败。
怎么快速定位？我的做法是：先看ClientHello里的cipher_suites长度，很多不匹配都是列表太短（比如只有两三个）。再用服务器支持的列表做交集，要是空集，那问题就简单了——换配置。我曾在某个银行的负载均衡上碰到过，客户端只送了一个TLS_RSA_WITH_AES_256_CBC_SHA，但服务器安全策略要求至少ECDHE，结果就是客户端报handshake_failure。后来我让客户端那边更新了密码套件列表，问题解决。
2.6 一次完整的Hello链路
下面这张图，把ClientHello和ServerHello的流程、关键字段、以及可能的不匹配点串起来了。你对照着看，后续排查时就能快速定位。
2.7 实战排查小技巧
当你遇到协议不匹配故障时，按下面几步走会快很多：
- 抓包：用Wireshark或tshark过滤
tls.handshake.type == 1（ClientHello）和tls.handshake.type == 2（ServerHello）。 - 看版本：比对ClientHello声明的最高版本和ServerHello选中的版本。如果服务器直接没回复（TCP RST），很可能是版本不兼容。
- 看密码套件：用
tls.handshake.cipher_suites获取客户端列表，跟服务器配置的白名单做交集。没有交集就是空集。 - 检查扩展：尤其注意
supported_versions、key_share（TLS 1.3）、signature_algorithms。我遇过服务器要求指定签名算法而客户端没带，导致握手失败。 - 查看错误Alert：如果服务器返回
Alert(40)（handshake_failure）或Alert(70)（protocol_version），就基本定位了。
个人习惯：在代码里加一段日志打印ClientHello的摘要（版本、密码套件数、扩展数），跟服务器端日志对比，很多时候5分钟就能找到问题根源。
好，现在你心里应该有数了。ClientHello和ServerHello就像两个人初次见面互相报名字和特长——各自的“能力清单”对不上，那后面再聊什么都是白搭。后续排查每种具体的不匹配场景（版本、密码、扩展、证书）时，我都会反复强调这两个Hello里的关键字段。你先把这两条消息的解读练得滚瓜烂熟，后面的事就轻松多了。