本文章默认读者已经了解Https和http的层级架构，加密算法的概念，如果不知道，需要读者自行搜索下
要说明白Https，需要先看下Https要解决的问题，也就是Http存在哪些问题需要改进
1.http传输面临的3个问题
- 信息明文传输，容易被窃取
- 无法验证服务器身份，容易被伪装的服务器骗取信息
- 没有验证消息完整性，信息可能被篡改
2. https解决明文传输的方法
这个过程用到的加密，加密分为对称加密和非对称加密，区别就是对称加密，加密和解密用同一个密钥， 非对称加密使用不同密钥，这里不过多赘述。
对称加密版本
- 浏览器发送支持的加密方法和一个客户端随机数
- 服务器返回要用的加密方法和一个服务器随机数
- 客户端和服务端都是用随机数和加密方法生成密钥
- 后续数据使用密钥加密
这种方式的问题是这些随机数都可以被黑客拦截，那他就拥有了密钥，就不存在加密了。
非对称加密版本
使用非对称加密，不发送随机数了，我服务器直接算好公钥，私钥，直接把公钥发给你客户端，客户端公钥直接加密，服务器私钥解密
但是这样也会有问题
- 非对称加密效率低，针对大量传输的信息可能会严重影响响应速率
- 只能保证客户端发送信息不被解密，服务器发送只能私钥加密信息，但黑客有机会获取到公钥，直接可以解密服务器发的信息
所以后续改进的方向是数据加密需要使用对称加密，避免效率问题，那么要解决的就是如何保证对称密钥的安全性。
终极版本：对称和非对称混合
对称密钥加密和解密数据，非对称加密和解密"对称密钥"，这样来保证对称密钥不被破解，后续用对称密钥加密和解密数据就做到了安全性和效率的平衡
- 浏览器发送支持的加密方法和客户端随机数
- 服务端返回要是用的加密方法，服务端随机数和公钥(非对称加密的)
- 客户端再生成一个随机数，然后利用非对称加密的公钥加密这个随机数
- 服务端利用私钥解密随机数
- 客户端和服务端利用3个随机数和加密方法生成对称密钥
- 客户端和服务端使用密钥加密和解密
上述就是Https加密和解密的主体思路和方案
但是细心的网友也可以想到，那我伪装成服务器和你浏览器对话，伪装服务器走这一套流程就可以套取客户端的信息，于是就来到Https需要解决的第二个问题，验证服务端身份，解决方案就是借用数字证书
3. Https解决服务端身份验证
看下包含数字证书的过程
可以发现变化不大，区别在于
- 服务器返回的不是公钥而是证书
- 客户端要去验证证书
数字证书里面有什么东西，客户端如何验证证书
- 公钥，也就是非对称加密的公钥
- 证书信息：有超时时间，颁发机构信息，签名算法
- 数字签名：对公钥和证书信息做hash生成的摘要
网友们可以随便点开一个https的网站，在地址栏左边按钮可以查看到他的证书，看下里面有啥东西，这里不过多赘述，可以搜一下查看方法
上面的图也是客户端验证证书的过程，第二步的CA公钥解密，这个CA公钥哪来的，一般情况下是服务器在前面的协商过程一起发下来的，服务器没部署的话，客户端会通过下载获取
客户端通过解密数字签名获取摘要，和公钥，证书信息hash算的摘要做对比，相同就认为合法，同时客户端要验证证书是否被吊销，是否超过有效期，证书是否是合法机构颁发，这样来验证服务器的合法性
4. Https保证信息完整性
这一步其实类似证书验证，每次信息传输，会对信息正常一个摘要，（这个摘要算法就是类似MD5，sha-2的东西，能对不同长度信息生成固定长度的身份字符串，细微的信息变化也会导致生成的身份字符串不一样），发送的时候将摘要一起发送，收到信息后重新对信息进行摘要计算，如果摘要相等就说明信息是完整的
针对数字证书是怎么颁发，数字证书又怎么保证合法性的详细过程，可以参考以下文章，本人的这篇文章也是参考写的，由于他们图做的太好了就直接用了
https:加密过程 segmentfault.com/a/119000002…
数字证书相关 www.cnblogs.com/bala/p/1626…
