摘要：本文测验一步步复原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秒钟。