HTTPS 原理浅析：一次握手背后发生了什么

浏览器地址栏那个锁形图标背后，是一场在几十毫秒内完成的协商：双方素未谋面，要在这个短暂的窗口里确认身份、商定密钥、建立加密通道。TLS 握手解决的正是这类问题——如何在一条不可信的信道上，安全地完成一次”密钥交换 + 身份认证”。把这次握手拆开看，很多线上故障的排查思路会清晰很多。

一、为什么需要混合加密

直接全用非对称加密不行：公钥运算太慢，传输大量数据（网页、图片、接口响应）时开销不可接受。直接全用对称加密也不行：对称密钥本身怎么安全地送到对方手里，又回到了老问题。

TLS 的解法是取两者之长：用非对称加密完成身份认证和密钥协商，用协商出的对称密钥（也叫会话密钥）加密后续的应用数据。握手阶段是非对称的部分，握手完成之后，数据流走的其实是高速的对称加密。

非对称部分的关键是密钥交换算法。早期常见的做法是用服务器的证书公钥加密一个预备主密钥；现代做法（ECDHE）基于椭圆曲线 Diffie-Hellman 做临时密钥交换：双方各出一份临时密钥材料，各自算出同一个共享密钥，但窃听者只看到公开的交换材料，推不出最终密钥。临时交换还带前向保密特性——即使服务器长期私钥将来泄露，历史流量也无法被解开，因为每段会话的密钥都独立且用完即弃。

二、证书链与 CA：身份是怎么被信任的

密钥交换解决”别人听不懂”，证书解决”对方是不是我以为的那台服务器”。否则中间人完全可以自己生成一对密钥冒充目标站点——加密依然成立，只是加密的对象换成了攻击者。

证书的信任模型是层级背书：服务器证书由某个 CA（证书颁发机构）签名，CA 又由更上层的 CA 签名，一路追溯到内置在操作系统或浏览器里的根证书。验证时客户端逐级检查签名有效性、域名是否匹配、有效期是否在范围内，这条路径就是证书链。

常见的证书文件形态，服务器侧通常部署的是”服务器证书 + 中间证书”拼成的链文件，根证书由客户端本地自带，不需要也不该由服务器下发。链不完整是最典型的部署故障之一：浏览器自己的证书库里恰好有那份中间证书时看起来正常，换台设备就报不受信任。

三、SNI 与 ALPN：握手里的两处细节

一台服务器、一个 IP 上挂多个站点时，有两个扩展字段在幕后做分发：

SNI（服务器名称指示）：客户端在握手早期就声明要访问的域名，服务器据此选择返回哪张证书。没有 SNI，共享 IP 的多证书托管无从谈起。代价是 SNI 明文传输，路径上的观察者能看到访问的域名（流量仍加密）。
ALPN（应用层协议协商）：双方在握手里顺便协商后续用什么协议，典型的是让 HTTP/2 生效的标识。协商结果决定连接上跑的是 HTTP/1.1 还是 HTTP/2。

这两个字段本身不提供安全性，但直接影响”能不能建立正确的连接”，排查多站点证书错配、HTTP/2 未生效时常常要从它们入手。

四、握手性能：减少往返是关键

TLS 握手的成本主要在往返次数（RTT）和证书验签的计算上。在延迟高的链路上，多一次往返的代价远大于本地多做几次密码学运算。

优化手段围绕”减少往返、复用状态”展开：

会话恢复（Session Resumption）：老机制是 Session ID / Session Ticket，客户端重连时带上凭据，跳过完整的密钥交换。
TLS 1.3 的改进：握手往返从 2-RTT 压到 1-RTT，并支持 0-RTT 恢复（重连时第一批数据可以随首个报文发出）。0-RTT 数据不具备前向保密、还存在重放风险，所以只适合幂等的请求，这一点在使用时要心里有数。
握手前的准备：DNS 解析、TCP 连接建立、TLS 握手是串行的，预解析域名、复用长连接、合理配置连接池，都能把感知延迟降下来。

TLS 1.3 顺带精简了算法套件，移除了 CBC、RC4、静态 RSA 密钥交换等一批老旧机制，既提速也减少了配置出错的空间。

五、常见配置坑

排查”打不开、提示不安全、部分设备异常”这类问题，高频原因基本集中在下面几项：

现象	常见原因	处理方向
提示证书过期	证书到期未续签，或自动续签任务挂了	监控到期时间，自动续签后校验加载
部分设备不受信任	中间证书链缺失	部署完整链（叶证书 + 中间证书）
浏览器提示”不安全”	页面里混入了 http:// 的子资源	全站资源走 https 或相对协议
旧设备连不上	服务端禁用了对方支持的算法/版本	合理配置密码套件与协议版本下限
域名不匹配	证书覆盖的域名与访问域名不一致	检查 SAN 列表与通配符范围

混合内容（mixed content）值得单独说：主页面是 https，但脚本、图片、iframe 用 http 加载，浏览器会标记页面为不安全，被动混合内容（图片）在新版本浏览器里还可能直接被拦截。前端资源引用最好统一用 https 或相对路径，同时留意第三方脚本自带的 http 引用。

证书续签是运维里的高频翻车点：自动续签流程本身成功，不代表站点加载的还是新证书——中间的 reload / 重启没生效，线上继续用着旧证书直到过期。续签之后应当主动验证一次实际生效的证书指纹与有效期，别只看续签脚本的返回值。

六、上线前的几项自检

新站点或改完 TLS 配置后，值得按固定清单过一遍：证书有效期与域名范围是否覆盖所有入口（含裸域与 www）；中间证书是否完整；是否只保留了需要的协议版本与密码套件；HSTS 是否已开启并理解它的缓存副作用；页面源码里是否还残留 http 资源引用。这几项覆盖了实际故障里的绝大多数成因，剩下的是长期运维问题——把证书到期时间纳入监控告警，比记住任何一次事故都更省力。

理解握手的结构之后，很多”玄学问题”其实都有确定的位置：拿不到对的证书是 SNI/链的问题，握手慢是往返和恢复策略的问题，页面不安全是混合内容的问题。协议是固定的，故障总落在某一个环节上。把每次故障归位到握手的某一步，日积月累就是一份属于自己的排障地图。