摘要：本文尝试一步步还原HTTPS的设计过程，以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时，你可以尝试放下已有的对HTTPS的理解，这样更利于“还原”过程。
我们先不了聊HTTP，HTTPS，我们先从一个聊天软件说起，我们要实现A能发一个hello消息给B：
如果我们要实现这个聊天软件，本文只考虑安全性问题，要实现
A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容
如何做到真正的安全？
这个问题，很多人马上就想到了各种加密算法，什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~
而我想说，加密算法只是解决方案，我们首先要做的是理解我们的问题域——什么是安全？
我个人的理解是：
A与B通信的内容，有且只有A和B有能力看到通信的真正内容
好，问题域已经定义好了（现实中当然不止这一种定义）。对于解决方案，很容易就想到了对消息进行加密。
题外话，但是只有这一种方法吗？我看未必，说不定在将来会出现一种物质打破当前世界的通信假设，实现真正意义上的保密。
对于A与B这样的简单通信模型，我们很容易做出选择：
这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。
只要这个密钥S不公开给第三者，同时密钥S足够安全，我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。
但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：
如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥？请读者思考21秒钟。
