一次 HTTPS 握手，到底发生了什么？

每天在浏览器地址栏看到小锁头，你有没有想过：这把"锁"到底是怎么锁上的？一次完整的 HTTPS 握手只发生在几百毫秒内，却包含了一场精密的协商仪式。搞懂它，能帮你快速定位证书过期、混合内容拦截等线上问题。

一、先有 TCP，再谈加密

HTTPS 的本质是 HTTP + TLS。任何加密协商开始之前，客户端和服务器必须先完成 TCP 三次握手，建立可靠的传输通道。TLS 握手的所有消息，都承载在这条 TCP 连接之上。也就是说，一次 HTTPS 请求至少经历"TCP 握手 + TLS 握手"两个阶段。

二、ClientHello：客户端先自报家门

客户端发出 ClientHello，携带三样东西：支持的 TLS 版本（如 TLS 1.2、TLS 1.3）、支持的密码套件列表、一个随机数 Client Random。这个随机数会在后面参与会话密钥的计算，保证每次连接的密钥都不一样。

三、ServerHello 与证书：服务器亮明身份

服务器回复 ServerHello：确认使用的 TLS 版本和密码套件，附上自己的随机数 Server Random，然后把数字证书发送过来。证书里包含服务器公钥、绑定的域名、有效期和 CA 的数字签名。

客户端拿到证书后要做三件事：第一，验证证书链能否追溯到系统信任的根 CA；第二，核对证书中的域名与当前访问的域名是否一致；第三，检查证书是否在有效期内。任何一项不通过，浏览器都会弹出醒目的安全警告。

四、密钥交换：从非对称切换到对称

身份确认后，双方要协商出后续通信用的对称会话密钥。TLS 1.2 的经典做法是：客户端生成预主密钥，用服务器公钥加密后发过去；TLS 1.3 则普遍采用 ECDHE 密钥交换，实现前向保密——即便服务器私钥将来泄露，历史会话内容也无法被解密。

双方拿到相同的预主密钥后，结合 Client Random 和 Server Random，通过伪随机函数推导出完全一致的会话密钥。此后所有 HTTP 报文都用对称加密传输：既安全，又比非对称加密快得多。

五、会话复用：别让握手每次都从头来

完整握手需要 2 个 RTT，对延迟敏感的场景并不友好。TLS 支持会话复用：服务器把会话参数加密成 Session Ticket 发给客户端，下次连接时客户端直接携带 Ticket，1 个 RTT 就能恢复会话，首字节时间明显缩短。

排查小技巧

1. 用 curl -v https://example.com 可以看到完整的握手过程、证书链和协商出的密码套件；
2. 证书过期是最常见的线上故障之一，建议对证书有效期做监控告警，至少提前 30 天续签；
3. 开启 HSTS 可以强制浏览器只使用 HTTPS，避免首次访问被中间人降级为 HTTP。

理解了握手流程，再遇到"证书不受信任""混合内容被拦截"这类报错，你就能一眼定位到问题出在证书验证、密钥协商还是传输加密的哪一个环节。