很多人知道 HTTPS 比 HTTP 安全，地址栏那把小锁看着也踏实。但你要问它凭啥安全、那把锁是怎么锁上的，多半就说不清了。

这篇我们把 HTTPS 建连的握手过程，一步步流程化地拆开，配上图和比方，争取看完你能自己讲出来。

HTTP 的问题在哪

先搞清楚为啥需要 HTTPS，不然后面全是空谈。

HTTP 传数据是明文的。

明文什么概念？就是你发的账号密码、聊天内容，在网络上是光着身子跑的。中间任何一个节点——路由器、WiFi 热点、运营商——想看，随手就能看到，甚至能改。

这就好比你寄明信片，谁经手谁都能读一遍上面写了啥。

HTTPS 干的事，就是给这张明信片套个上锁的信封。别人经手也只看到一坨看不懂的密文，改也改不了。

那这个“锁”怎么加上去，就是握手过程要解决的。

先补两把钥匙的知识

讲握手前，得先垫一个加密的基础，不然听不懂。加密有两种路子。

对称加密：加密和解密用同一把钥匙。

就像一个保险箱，锁和开都是同一把钥匙。它的好处是快，缺点是——这把钥匙怎么安全地交给对方？你要是在明文网络上把钥匙发过去，不就被人截走了？

非对称加密：一对钥匙，公钥和私钥，成对出现。

• 公钥可以随便公开给任何人
• 私钥自己藏好，绝不外传
• 用公钥锁上的东西，只有对应的私钥能打开

它的好处是解决了“钥匙怎么传”的难题，缺点是慢，不适合加密大量数据。

记住这两把钥匙的脾气，下面就懂 HTTPS 为啥要把它俩搭配着用了。

HTTPS 握手全流程

好，正片开始。先上一张图，把整个握手过程摆出来：

浏览器(客户端)                       服务器
     |                                 |
     |  ① 你好,我要建立安全连接         |
     | ------------------------------> |
     |                                 |
     |  ② 你好,这是我的证书(含公钥)     |
     | <------------------------------ |
     |                                 |
  ③ 验证证书是否可信                    |
     |                                 |
  ④ 生成一把对称密钥                    |
     用服务器公钥把它锁起来             |
     |                                 |
     |  ⑤ 把锁住的对称密钥发过去        |
     | ------------------------------> |
     |                                 |
     |                          ⑥ 用私钥解锁
     |                             拿到对称密钥
     |                                 |
     |  ⑦ 之后双方用这把对称密钥加密通信 |
     | <=============================> |
​

看着步骤不少，其实就干三件事：验明身份 → 交换钥匙 → 开始加密聊天。我们一步步说。

第一步 打招呼

浏览器先发起请求：“你好，我想跟你建立一个安全连接。”

顺带告诉服务器自己支持哪些加密算法，让双方对齐能力。

第二步 服务器亮证书

服务器回应：“你好，这是我的数字证书。”

这个证书里最关键的东西，是服务器的公钥。

证书就像服务器的身份证，用来证明“我确实是你要访问的那个网站，不是冒牌货”。

第三步 浏览器验证书

拿到证书，浏览器不会傻乎乎就信。它要验一验这证书是不是真的。

证书是由权威机构（叫 CA，证书颁发机构）签发的。这个 CA 相当于一个公证处。

浏览器里预装了它信任的那些公证处名单。它检查这张证书是不是这些可信公证处盖过章的、有没有过期、域名对不对得上。

• 验过了：这网站是真的，继续
• 没验过：浏览器直接弹红色警告，就是你偶尔见到的“此网站不安全”

这一步是防假冒网站的关键。光加密不验身份，你可能加密着跟一个骗子聊得火热。

第四步 协商对称密钥

证书验过了，公钥也拿到手了。接下来是最妙的一步。

浏览器自己生成一把对称密钥（就是前面说的那种又快又对称的钥匙）。

然后，它用刚拿到的服务器公钥，把这把对称密钥锁起来。

第五步 把钥匙安全送过去

浏览器把这个用公钥锁住的对称密钥，发给服务器。

这里就是非对称加密发威的地方：这坨东西是用公钥锁的，全世界只有攥着对应私钥的那台服务器能打开。中间就算被人截走，没有私钥也是一坨废码。

于是“钥匙怎么安全传过去”这个死结，就这么解开了。

第六步 服务器解锁拿钥匙

服务器用自己藏着的私钥，把锁住的对称密钥解出来。

到这一刻，浏览器和服务器手里都有了同一把对称密钥，而且这把钥匙从没在网络上明文出现过。

第七步 开始加密通信

握手完成。之后双方所有的数据往来，都用这把对称密钥来加密解密。

又快又安全，皆大欢喜。

为啥要两种加密混着用

讲到这，回头看会发现 HTTPS 玩了个很聪明的组合拳。它把两种加密的优点各取一半。

非对称加密(慢但安全)  →  只用来传那一把对称密钥
对称加密(快但难传钥)  →  用来加密后续的海量数据
​

捋一下这个巧思：

• 对称加密快，适合加密大量数据，但难题是钥匙没法安全传递
• 非对称加密能安全传东西，但太慢，扛不住大量数据

HTTPS 的解法：用非对称加密，专门把那一把对称密钥安全地送过去；钥匙一旦送到，后面海量数据就全交给又快又稳的对称加密。

非对称只在握手时用一下下，用完就退场。剩下的活儿全归对称加密。

慢的只干一点点，快的干大头。两全其美，这就是 HTTPS 设计最精髓的地方。

小结

HTTPS 看着神秘，拆开就三件事，记住这条主线就行：

• 验身份：服务器亮证书，浏览器找可信的 CA“公证处”核验，防假冒
• 换钥匙：浏览器生成对称密钥，用服务器公钥锁住送过去，只有私钥能开
• 聊正事：双方拿到同一把对称密钥，之后数据全用它加密

再记住那个精髓：非对称加密负责安全地传钥匙，对称加密负责高效地传数据，两种混用，各扬所长。

下次再看到地址栏那把小锁，你就知道它背后握了这么一手了。那就带着这张图去理解那把锁吧。