自从开始写科普类文章，我感觉已经一发而不可收拾了?
公司在开会好无聊→_→就写一下 http 请求的整个流程和 https 的原理吧。
http 请求要经过三个部分
1 客户端 就是用户
2 网络提供商 例如电信网通
3 服务端 网站数据存放的地点
打个比方，在浏览器地址栏中输入 http://www.example.com
这是个人类能看懂的名称，但是在网络上并不靠这个区分计算机，而是靠 ip 地址
用户浏览器首先在本地缓存中查找这个域名对应的 ip ，如果找不到就交给系统，系统首先会在 hosts 中查找对应的 ip ，找不到的话，就会请求 DNS 服务器
在连接网络的时候，如果用户不手动设置，会自动使用网络运营商分配的 DNS 服务器。
如果 DNS 服务器也没有该域名的缓存，则会向上一级 DNS 服务器请求，假设全都没有，则最后会递归到根域名服务器，全球只有 13 组根域名服务器。根域名服务器不存储 ip 地址，只存储其他的 DNS 服务器。
打个比方， http://www.example.com 提交到根域名服务器之后，他会说 以 .com 结尾的都归 A 管，然后找到 A ，A说，以 http://example.com 结尾的都归 B 管，然后找到 B ，B 会告诉你 http://www.example.com 的 ip 地址
所谓的 DNS 污染，就是 DNS 服务器不返回正确的 ip 地址，比如 http://www.example.com 的 ip 地址是 192.168.1.1 ，DNS 告诉你是 192.168.1.2
，你也不知道→_→
知道了 ip 地址以后，浏览器就会请求该 ip 地址。
而请求的数据，经过好多个路由 从你家里的路由器开始，到运营商的路由，再往上，到最顶上以后再往下。就跟 DNS 查询差不多。最后才到达服务器。服务器返回的数据也如此。
由于 http 请求是明文的，因此这条链路上的任意一个路由，都可以任意修改数据，没有任何安全可言。
然后 HTTPS 就诞生了。在这里要提到对称加密和非对称加密。
对称加密 数据使用 A 密钥加密，变成加密后的数据，加密后的数据使用 A 密钥解密，变成数据。
这里就存在一个问题，由于 HTTP 是明文，如果采用对称加密，那么如何传输密钥？如果也通过不加密的 HTTP 链路传输，别人知道了密钥，还是能随便改数据。
非对称加密 数据使用 A 密钥加密，变成加密后的数据，然后加密后的数据经过 B 密钥解密，变成明文。然后相反的，数据经过 B 加密以后，也能通过 A 解密。这样只要服务器把 A 密钥公布到网上，别人就能使用 A 密钥加密，然后服务器使用 B 密钥解密，就行了，这样中间的不法分子即使知道 A 密钥，也没办法随便修改数据。
不过由于非对称加密速度太慢，所以一般实现都是，使用非对称加密加密密钥，然后使用新的密钥进行对称加密的通讯。
但是，这里还有一个问题。
假如中间人把 A 密钥拦截下来，把数据拦截下来，把数据解密，然后把数据用自己的非对称密钥加密后，跟自己的密钥一起发过去，最后数据还是会在中间人这里中转，相当于没什么卵用。
为了防止这种情况，必须保证自己收到的密钥就是服务器发出的密钥而不是中间人的密钥。
在这里就会涉及到证书→→说的稍微简单点
服务器把自己的域名，ip，公钥放在一起，用非对称加密加密上，发送过去
理论上来说这样还是能被上述方法拦截
然后再加密，理论上还是被拦截
一直加密，虽然说不管加密多少层都是会被拦截的，但是这边目的不是为了不被拦截，而是为了减少数目。
打个比方，世界上有一亿个网站，假如每100个网站共用一个密钥加密，再每一百个密钥共用一个密钥加密，最后就只剩一个需要信任的公钥了。
而这一个需要信任的公钥是内置在操作系统中，内置在浏览器中，不经过网络发布。
只要确定了这个公钥值得信任，那以他加密的下属的100个公钥也值得信任了，以此类推。最后就知道这个域名是不是对应这个 ip ，是不是对应该网站的公钥。顺便也解决了 DNS 的污染问题。
这个链路就叫做证书信任链。
不过在实际情况中，并不是只有一个跟 CA，一般都有很多，而且不同浏览器，不同操作系统内置的跟 CA也不一定一样，但是大部分还是一样的，所以说，上次 Chrome 觉得 某根 CA 乱发证书，所以把它从Chrome证书库里吊销掉了→→
大概就这么多，手机打字好麻烦，有时间再查漏补缺，加加图改改错什么的。
