第1章：TLS协议概述与握手流程

说实话，TLS 这玩意儿，干我们这行的天天打交道。但你真的清楚它每一步在干什么吗？我见过不少同事遇到握手失败，第一反应就是重启服务——结果连问题根因都没找到。这章我们先从根上捋一捋。

1.1 TLS 是什么？从哪来？到哪去？

TLS（Transport Layer Security），说白了就是 HTTP 的安全外套。它继承自 SSL，最初由 Netscape 搞出来的。SSL 1.0 没公开就废了，SSL 2.0/3.0 陆续暴露了一堆漏洞，于是 IETF 接手，改名 TLS。到现在主要版本是 TLS 1.2（2008）和 TLS 1.3（2018）。

它的核心作用就两个：

• 身份认证——确保你连的是真服务器，不是钓鱼的
• 加密通信——信道上跑的内容，别人截了也看不懂

你想想看，没有 TLS，你在网上输的密码、信用卡号，就像在明信片上写一样。我记得早期在电商公司，有一次压测发现某接口响应特别慢，查了半天，问题出在 TLS 握手阶段——证书链太长，来回走了好几轮。从那以后，我对握手流程就特别敏感。

1.2 完整握手——TLS 1.2 的经典三步

TLS 1.2 的完整握手通常需要 2-RTT（两个来回）。流程大致如下：

1. ClientHello：客户端发送支持的 TLS 版本、密码套件列表、随机数
2. ServerHello：服务器选好版本和套件，发回自己的随机数 + 证书
3. 证书验证：客户端校验证书链（CA 签名、有效期、域名等）
4. Pre-Master Secret：客户端生成一个随机密钥，用服务器公钥加密后发给服务器
5. ChangeCipherSpec + Finished：双方各自算出会话密钥，然后发 Finished 消息确认切换加密

这里有个坑：证书链的长度直接影响握手速度。我在项目中遇到过，某客户使用了四级证书链（根 CA→中间 CA1→中间 CA2→服务器证书），每次握手多出好几 KB 的数据，Wi-Fi 环境下延迟飙到 200ms+。后来我们建议缩短到两级，问题解决。

1.3 简化握手——TLS 1.3 的 1-RTT 与 0-RTT

TLS 1.3 重新设计了握手协议，把大部分协商逻辑放到第一轮就做完。完整握手只有 1-RTT，还支持 0-RTT 会话恢复。

来看看对比：

项	TLS 1.2	TLS 1.3
RTT 次数（全新握手）	2-RTT	1-RTT
密钥协商方式	RSA/DHE/ECDHE（可协商）	强制 ECDHE
密码套件数量	30+ 种	5 种（删除了所有不安全套件）
证书加密	明文传输证书	证书加密传输（防嗅探）
会话恢复	Session ID / Session Ticket（需 1-RTT）	PSK + 0-RTT（可能 0-RTT）

TLS 1.3 的握手步骤简化成：

1. ClientHello：直接发给对方支持的密码套件+密钥共享（Key Share，比如 ECDHE 参数）
2. ServerHello + 证书 + Finished：服务端选好套件，完成密钥协商，直接开始加密
3. 客户端 Finished：验证握手完整性

说白了，就是把原来需要两轮干的事，硬塞进一轮里。我最早接触 TLS 1.3 是在一个物联网项目里，设备端 CPU 性能弱，2-RTT 的 TLS 1.2 握手动不动就超时。切到 1.3 后，握手延迟从 300ms 降到 80ms，效果非常明显。

1.4 握手流程总览图

下面这张图帮你一眼看清 TLS 1.2 和 TLS 1.3 握手阶段的核心差异。红色箭头是额外 RTT，绿色是优化后的路径。

1.5 避坑：参数调优前，先理解握手机制

很多人一上来就调密码套件、改超时时间，结果越调越慢。为什么？因为你不清楚握手阶段到底哪些环节消耗 CPU、带宽、时间。

• CPU 大头：非对称加密（证书验证、密钥交换）。EC（椭圆曲线）相比 RSA 运算量小很多，我建议优先选 ECDHE。
• 带宽大头：证书链长度。每多一级证书，多 1~2 KB 传输。移动网络下代价尤其大。
• 延迟大头：RTT 次数。TLS 1.2 完整握手至少 2 RTT，加上 TCP 的 1 RTT，总耗时 3 RTT。优化方向：用 TLS 1.3 或启用会话恢复。