4. TLS握手协议基础：目的与流程概览
做安全开发的这些年，几乎每个涉及网络通信的项目都会跟TLS握手打交道。很多新手觉得握手就是“来回发几个包”，其实没那么简单。咱们先搞清楚握手到底要解决什么问题，再把整个流程拉一遍。
4.1 握手的目的：没有握手会怎样？
你想想看，如果两个程序直接裸连TCP就开始传数据，会有什么风险？
- 消息被偷看——明文传输，监听一下全知道了。
- 消息被篡改——中间人改一个字节，接收方毫无察觉。
- 身份被冒充——谁都可以说自己是“服务器”，你分不清真假。
TLS握手就是为了解决这三个问题。我个人习惯把它理解成“三件事”：
- 身份验证：确认对方就是它声称的那个人（通常靠证书链）。
- 密钥协商：双方安全地商量出一个对称密钥，中间人拿不到。
- 参数确认：确定用什么协议版本、用什么密码套件。
我在项目中遇到过一件事：有个同事觉得握手太慢，干脆把TLS关掉直接走明文。结果上线第一天就被安全扫描抓到了。嗯，从那以后我再也不敢提这个建议。
核心要点：TLS握手的本质是在不可信的信道上，建立起一个可信的加密会话。没有这一步，后面所有的数据都等于裸奔。
4.2 握手流程概览
一张图胜过千言万语。先看我画的这个经典TLS 1.2全握手流程：
从图上你能看到，一次完整的握手通常需要两个来回（4条消息）。具体每一步做了什么？我习惯把握手拆成四个阶段：
| 阶段 | 主要消息 | 发生了什么 |
|---|---|---|
| 1. 握手发起 | ClientHello | 客户端告诉服务器它支持的最高版本、密码套件列表、随机数等。 |
| 2. 服务器响应 | ServerHello + Certificate + ServerHelloDone | 服务器选定版本和套件，发送自己的证书，并结束第一轮。 |
| 3. 密钥交换 | ClientKeyExchange + ChangeCipherSpec + Finished | 客户端用服务器公钥加密预主密钥，双方推导出主密钥，然后告知对方自己要切换到加密模式了。 |
| 4. 握手完成 | ChangeCipherSpec + Finished（服务器端） | 服务器也切换加密模式，双方确认握手成功，开始传应用数据。 |
小提示：上面画的是全握手（即第一次连接或会话过期时）。如果之前已经握过手且缓存了会话，可以用缩写握手，只需要一次往返（甚至0-RTT），速度会快很多。不过缩写握手的安全粒度没那么细，得看场景取舍。
4.3 我踩过的一个坑
我曾经在一个嵌入式IoT项目里，设备性能很差。按照手册配了一个“安全”的密码套件，结果握手每次都卡在Certificate消息上——证书太大了，设备只有几百KB的内存。后来我把证书链精简到只留叶子证书，并把CA证书预置在设备端，才把握手跑通。
这件事让我养成了一个习惯：每次做TLS握手调优时，先问自己三个问题：
- 我的客户端能处理多大尺寸的证书？
- 握手允许的最大延迟是多少？
- 是否需要支持会话恢复？
注意：不要以为TLS握手是“协议栈帮我搞定的事”。我见过不少项目因为握手参数没配好，导致连接耗时超过10秒，用户体验极差。尤其在高并发场景下，握手阶段的性能往往就是瓶颈。
说白了，TLS握手就是一次安全层面的“相亲”——先自我介绍，亮出信任凭证，然后悄悄商量好密码，最后才敢说悄悄话。理解了这一点，后面学密码套件和扩展字段时，你就知道每个字段是为哪个环节服务的了。