浅谈HTTP，HTTPS

HTTP，HTTPS是既陌生，又熟悉的两个协议

熟悉，是因为我们不管畅游互联网，还是开发过程中，都会接触到的

陌生，是因为我们很多都只是知道可以通过HTTP，HTTPS访问网站，请求后台接口。但是对底层原理并不是很熟悉（当然可能只是我不熟悉哈）

他们的本质是定义了一个客户端和服务器之间数据传输的一个协议

想必很多童鞋都或多或少都了解过，这篇文章的初衷

一是在让自己再重新梳理，加深印象
二是想抛砖引玉，如有不正确的地方，也欢迎大家及时指正

HTTP

在探讨HTTP之前，我们先看看一个生活场景–写信

小明和小红异地恋，相距甚远，只能通过写信的方式，互诉相思之情

想必大家都写过信（这里貌似暴露了年龄），写信的时候我们会有个信封，由信封包着书信

在信封上，我们会写明寄信人姓名，寄信人的地址，收信人的姓名，收信人的地址，邮编

邮差根据这些信息就可以正确地把信送到收信人手上了

就这样过了许久的浪漫岁月，但好景不长

暗恋小红已久的小黄，知道他们两一直在以书信来往

在某一天看了小明对小红的情书以后，脑海突然闪过了一个邪恶的念头，小黄决定篡改小明书信内容

在信中说了小红的坏话，导致小红和小明关系紧张

通过上述列子，我们可以把发送HTTP请求类比成送信。其中邮编好比服务器ip，可以快速定位目标大致地址，寄信人的地址好比API路径，收信人的姓名好比具体的服务接口，收信人信息好比客户端信息

窃听风险（小黄可以看到小明小红的书信内容）
篡改风险（小黄可以修改小明小红的书信内容）
冒充风险（小黄冒充小明辱骂小红）

为了解决以上三种风险，HTTPS应运而生。那什么是HTTPS呢？下面就让我们聊聊HTTPS

HTTPS

这个锁就是SSL/TSL协议，那SSL/TSL协议又是怎么解决窃听风险，篡改风险，冒充风险的呢。

下面我们还是以写信为例

解决窃听风险

小明为了缓解他俩的关系，千里迢迢飞过去找小红，然后当面跟小红解释清楚

并且跟小红商量好一个"规则"，小明以这个"规则"把书信内容打乱或者混淆

小红用这个"规则"恢复书信内容。

这个“规则”就是我们平时所说的密钥

这个行为就是对称加密，对称加密可以解决窃听风险

通过对称加密，他们又过了一段甜蜜光阴，但好景又不长

小黄去小明家里，无意中发现了"规则"，于是乎小黄用规则让书信内容一览无遗

然后篡改了书信内容，用同样的规则打乱或混淆。他们俩关系再陷入紧张

小明不得已又飞过去跟小红澄清"规则"可能已经泄漏了,"固定的对称密钥"终究不安全

于是乎他又想到另外一个好方法

小明就打电话给小红跟她说，以后每次写信之前，小明都会打电话给小红并告诉小红一个"随机数",

然后由小红再告诉小明她的一个"随机数"，最终的"规则"由这两个"随机数"生成。

此次的书信内容就由这个"密钥"加密与解密。这样"密钥"每次都是最新的

此举称为协商密钥，密钥并不是一成不变的，也不会写死在某个地方，而是每次通信前协商好的

解决冒充风险

小黄根据之前的规则，无法复用书信内容，索性就伪造了一份

在信中说明了临时更改了规则，尽量消除小红的疑惑，小红慢慢信以为真

久而久之，书信内容越来越离谱，关系再次恶化

于是小明怒飞过去，看了伪造的书信，看到潦草的字迹，又想到另外一个方法

小明和小红互相收下了对方的"字迹"，下次收到书信时就跟字迹对比，这样就知道是不是对方

此举称为交换凭证，可以解决冒充风险

解决篡改风险

小黄在跟小明的交谈中，无意中得知了他们以字迹辨别真伪，这下让他慌了

为了抱得美人归，立志练好书法，默认小明字迹。慢慢的小黄的字迹越来越像，真伪难分

小明得知书信再次被篡改且字迹相仿，于是绞尽脑汁

决定每次写信之前跟小红说，大概有多少字，书信内容大概描述了什么东西

（这里面有点扯蛋，能打电话说清楚，为啥还要写信呢，权当电话费贵，只能长话短说哈）

这样日后收到书信以后，对比字迹，计算字数，梳理整体脉络

自此小明和小红有情人终成眷属，过上幸福美满生活