前言
由于之前的文章已经介绍过了HTTP , 这篇文章介绍 HTTPS 相对于 HTTP 做出的改进
开门见山:
HTTPS 是对 HTTP 的加强版
主要是对一些关键信息 进行了加密
一.两种加密方式
1.对称加密
公钥 + 明文 = 密文
密文 + 公钥 = 明文
2.非对称加密
举个例子就好比 小区邮箱
提供一把锁（公钥，是给邮递员的） ，和一把钥匙（私钥，自己吃有）
邮递员把你的信，通过这把锁，锁到你的信箱里（使用公钥加密）
然后你就可以拿着你的钥匙打开邮箱（使用私钥解密）
前提是 锁 和 钥匙 是配对的（也就是公钥和私钥是配对的）
二.HTTPS的工作过程
总的目标：针对HTTP 这里的 header 和 body 进行加密
1.对称加密
但是上图有个很明显的问题，客服务器如果给很多的客户端发对接，那么这些客户端拿的是同一个 密匙 吗？
很明显，必须要求这些客户端的密匙是不一样的，这样彼此才不知道对方的密匙是什么。
那么此时就要求每个客户端的密钥都不同，就需要每个客户端在和服务器进行连接的时候，把自己的密钥生成出来，客户端再通过网络发送给服务器
但是如果黑客把密钥进行了抓取，那么加密操作就形同虚设
那么如何进行解决呢，如果给密钥套上一层密钥可以吗？答案按是不行的，套多少次都会被截取。
2.非对称加密
跟前面说的一样 ， 使用公钥和私钥，也就是对称密钥！！
就是客户端和服务器都生成自己的公钥和私钥
1.客户端给服务器发送一条请求，专门要服务器的公钥
2.服务器把私钥藏好，把公钥给客户端（公钥可能被劫持）， 客户端使用公钥进行加密，再进行传输的时候，即使被黑客进行劫持，但是只有私钥才能解密，而私钥在服务器哪里！
3.服务器手里持有私钥，服务器可以对对称密钥进行解密，然后就可以得到了原始的对称密钥。
这里有个问题：既然已经引入了非对称加密，那么为什么还要引入对称加密呢？
答案就是：效率。每个业务逻辑要求的是不一样的，引入非对称加密势必会影响到整体的性能， 也就是在合适的场景下使用非对称加密。对称加密也有他自己的用武之地。
3.中间人问题
非对称加密其实还有一个比较隐蔽的问题，那就是中间人问题
总的来说就是
- 黑客 把pub1 进行获取 ， 然后使用 自己的 pub 2 发给客户端，
- 客户端信以为真，使用 pub2 进行加密转给了黑客，黑客使用 自己的 pri2 进行解密之后 ， 拿到了关键的对称密钥。
- 还不算完，为了不让服务器发现，黑客还把这个对称密钥使用之前获取的 pub1 加密，发给了服务器。
- 服务器以为是客户端发来的，那么就使用了pri 2 进行解密，得到了对称密钥。
- 此时，三者都有了对称密钥，那么客户端和服务器之间的通信，就非常危险了!
🎈那么如何进行解决呢？
---------->答案就是引入公证机构
服务器再创建的时候，需要先向公证机构进行申请。公证机构根据服务器的一些属性颁发 证书，证书中包含 网站域名，服务器公钥，过期时间，数字签名（被加密后的校验和）等。服务器就会保存好这个证书。
数字签名就是公证机构针对证书中的各个属性，计算出一个校验和，然后使用自己的私钥进行加密。
公证机构会生成自己的公钥和密钥。公钥通过操作系统分发给各个服务器，私钥自己进行保存。
当两者再次进行通信的时候，客户端收到服务器的证书，然后使用内置的公钥进行解密出数字签名，如果发现一致，那么就意味着服务器的证书是公证机构颁发的，是可信的！ 因为服务器的数字签名是通过公证机构的对称密钥进行加密的。
总的来说：
https进行加密：
- 对称加密，加密业务数据
- 非对称加密，加密对称密钥
- "中间人"攻击，发现问题！
- 使用证书，校验服务器的公钥