写在前面
缘于在 Twitter 上看到的 HTTPS explained with carrier pigeons，作者用很简单的故事就把 HTTP / HTTPS 的传输过程讲解的很清楚，这种精彩诠释应该被更多人看到。
借原文的意思，我重新写了这个故事，加上了一些配图和补充，请品尝 …
PS:
- 如果你想在任何地方使用本文以及文中的插图，请征求我的授权以及注明出处;
- 本文不是一篇直接翻译过来的文章，有些转载后在标题直接加上一个 [译]，表示很不开心，别闹 …
开始
你在 Internet 上的所有活动，其实都可以归类为 往服务器发送数据 以及 从服务器接受数据，也就是你与服务器的通信。原文作者对这个行为给了一个神奇的比喻：有一只信鸽在你与服务器之前传送消息。
同理，我们也把网络活动中的其他基本元素拟人化，这样这个故事才会完美 …
LiLei 跟 HanMeimei 通信，情敌 Jim Green 是个 hacker, 当然，信使自然就是 Polly 了。
接下来，请开始你的表演 …
情窦初开
李雷想告诉韩梅梅：“I LOVE U”，于是李雷写好情书，绑在 Polly 的腿上，让 Polly 去韩梅梅家，韩梅梅拿到情书，呵呵一笑，哦不，娇羞一笑，OK，一次信息传递成功。
有人使坏
然而，喜欢韩梅梅的不止李雷，还有 Jim Green，他半路截取了 Polly，看到“ I LOVE U”，顿生醋意，愤而把消息改成 “F**K OFF” … 当韩梅梅收到信时，爱情的萌芽必然就被扼杀了，因为韩梅梅并不知道李雷发来的消息被半路拦截并篡改了。
加密消息
上次的事情后，李雷花了用了 1024 天向韩梅梅解释，最终让韩梅梅相信是有人在背后捣鬼，于是，他俩这次学乖了，决定把消息加密，俩人约定好，发送时把消息中的字母都向字母表后移 1 位，也就是发送 “J MPWF V”，这时就算 Jim Green 把 Polly 截了也不知道他们的消息是什么意思，只有韩梅梅知道消息解码的规则，她将每个字母对应字母表前移一位就知道原始消息是“ I LOVE U”，掩面娇羞…
插播科普
上面这种加密消息的方式就是对称加密，你知道如何加密，也知道如何解码。然后李雷跟韩梅梅用的字母表偏移的加密方法叫 Caesar cipher, 凯撒加密。现实世界中用的加密算法会更复杂，但是基本原理相同。
假如他们之前没见过
对称加密在只有发送和接收方知道加密算法和密钥的时候，是安全的。但是问题是，如果李雷和韩梅梅在通信之前都没见过，那他们就没法约定加密算法和密钥了。
旁白：那可以先通信一次把通信方式和密码发过去，然后再发消息呗？
然而，Jim Green 又不是傻，看见 Polly 第一次飞过去，拦下来，哦，原来你们要用凯撒加密，密钥是 1 … 上面说了，加密方式只有发送方和接受者知道时是安全的，现在第三个人知道了，不安全了。
他们的通信需要更安全的加密系统 …
PS：在现实中，如果使用对称加密，客户端和服务端都需要保存大量的加密算法和对应的密钥，管理成本巨大且容易泄漏。
让 Polly 抱个密码箱
李雷和韩梅梅想出来了一个复杂的通信流程：
- 李雷先让 Polly 不带情书飞到韩梅梅家；
- 韩梅梅在 Polly 身上绑一个开着的密码箱，密码只有韩梅梅知道，然后让 Polly 飞回去；
- 李雷在 Polly 回来的时候，把情书放进去，把密码箱锁起来，让 Polly 再飞到韩梅梅家；
- 韩梅梅拿到密码箱，打开，拿到情书，掩面娇羞；
Polly 内心旁白，MMP，你们谈个恋爱累死老子了 …
就通过这样的流程，他们安全的谈情说爱，Jim Green 无计可施 …
插播科普
上面这种加密方式是非对称加密，非对称的含义相对于对称来说，就是你即使知道怎么加密的的方式，也不知道怎么解密，对应上面的流程就是李雷锁的密码箱却没办法打开。
术语来讲的话，就是我们熟知的公钥和私钥，服务端将公钥（密码箱）发送给客户端，客户端使用公钥加密信息（锁箱子），服务端接受消息后使用私钥（仅韩梅梅知道的密码）解密。
密码箱安全吗
然而问题还没有结束 …
李雷拿到开着的密码箱，如何确定这个密码箱就是韩梅梅让 Polly 带过来的？Jim Green 能截消息，也能截密码箱然后换成自己知道知道密码的密码箱呀，这样的话，通信同样不安全（即公钥来源的安全性）。
李雷必须要知道箱子是不是韩梅梅的，于是韩梅梅想到一个办法，她在密码箱上签上自己的名字，当李雷拿到盒子的时候，就可以看签名是不是韩梅梅的从而决定是否安全。
然而，还又同样的问题，Jim Green 同样也能伪造签名呀 …
恶魔李雷：妈蛋的，这恋爱老子不谈了！
天使李雷：山无棱天地合乃敢与君绝
天使战胜了恶魔，故事继续 …
公信的证明
我们需要一个被大家信任的人来给他们的密码箱签名从而确保身份的安全，Jesus 保佑你：
- 韩梅梅拿着自己的密码箱去耶稣那，让耶稣帮忙做个认证；
- 耶稣用自己的秘术给密码箱套上一层保护膜，并在保护膜上刻上对这个密码箱的一些个性的说明；
- 韩梅梅把这个包装过的密码箱子让 Polly 带过去；
- 李雷在收到包装过的密码箱后，会虔诚的对着圣经读一遍保护膜上的签名以求证来源的安全性。如果圣经封面还是绿色的，就表示安全，否则，如果变成红色，就表示这个签名不是耶稣刻上去的；
- 确保是安全的签名后，李雷就撕掉保护膜拿到保险箱把情书塞进去；
- Cupid Polly Go …
自己编的故事，哭着也要把它圆下去：
- 耶稣就是 Certification Authority，认证机构，被世人所信仰；
- 服务器把自己的公钥登录到 CA，CA 会用自己的私钥（秘术）给服务器的公钥加密生成签名（个性说明）并颁发证书（保护膜），证书中包含对公钥做的 的签名和服务端的公钥；
- 客户端拿到消息体后，会用浏览器内置的 CA 的公钥（圣经，人人都有）对用私钥做的签名进行验证，如果验证通过表示安全，否则表示不安全。
Polly 好累
对比最初的消息，我们为了安全，本来只用送一封信，却加了一个密码箱和一本证书，运输成本重多了，Polly 累了，不开心了 …
于是，他们决定，消息体还是以凯撒加密的方式传输，然后偏移步长用郑叔签名的保险箱发送，这样就可以平衡消息的安全性和传输的成本问题。
术语解释就是非对称加密会影响传输速度，因为消息体变大了，所以通常综合性能和安全性考虑，会用对称加密消息体，非对称加密用来编码对称加密的密钥。
补充
HTTPS 的相比 HTTP 的安全性提升就是因为安全通信通道的建立，也就是上文故事所描述的过程，但是还有很多对于整体通信很重要的点都没有提到。
接下来这段流程是从阮一峰 图解 SSL / TSL 协议中看到的，对与理解建立 HTTPS 的 Security 的连接会有更好理解。
客户端和服务端建立安全连接的握手过程：
- 客户端给出协议的版本号、一个客户端生成的随机数和客户端支持的加密算法；
- 服务端在客户端给出的加密算法列表中选出一种，并给出数字证书和一个服务端生成的额随机数；
- 客户端确认数字证书的有效性，然后生成一个新的随机数，并使用数字证书中的公钥加密这个随机数；
- 服务端使用私钥解密，获取客户端发来的随机数；
- 客户端和服务端根据约定的加密方法，使用之前的三个随机数，生成对话密钥，这个密钥会用来加密接下来的整个通信过程
结语
故事中通信的过程其实就是原始的 HTTP 到 HTTPS 的演进过程，当然隐藏了真实通信的很多细节，但是大体上描述了原理和部分细节。
去探索更多关于 HTTPS 的原理 & 申请证书改造你的网站吧 …
PS：文中插图皆为蒋老师指导下亲手临摹或绘制的成果 … 蒋老师说，不要署名，画的太丑，丢她的人。哦…
