1.HTTP缺点
基于TCP协议，明文传输，消息传输过程中容易被篡改。
2.解决方案
对称加密
对称加密是指发送方和接收方都有自己的秘钥，发送方和接收方需要交换秘钥。
假设A为发送方，B为接收方。
交换秘钥以后，A有秘钥B，B有秘钥A。A发送的是用秘钥A加密的密文，B拿到以后用秘钥A解密。
但是这个过程有可能会被第三方C监听。交换秘钥的过程中C可以都拿到A和B的秘钥，这样C就可以随意篡改输入内容了。
非对称加密
非对称加密的核心是每一方有一个公钥和一个私钥：公钥用来加密，私钥用来解密。
A有公钥A，私钥A。
B有公钥B，私钥B。
A和B需要交换公钥，所以最后
A有公钥A，私钥A，公钥B。
B有公钥B，私钥B，公钥A。
A发送消息时，用B的公钥进行加密,B拿到消息以后用B的私钥进行解密。
如果中间有监听者C，在交换公钥的时候,C可以拿到A和B的公钥，同时把公钥A、B调包，这样A和B拿到的公钥都是C的公钥了。这样，AB传输信息时用的C的公钥，C就可以用自己的私钥解密，然后随意篡改消息了。
这样仿佛无解了，因为总得有一个交换公钥的过程。
HTTPS
既然问题发生在交互公钥的过程，那么防止交换公钥就行了。
为解决这个问题，出现了关于公钥的认证机构，这些认证机构很少，但非常权威，它会和电脑、浏览器等厂商达成信任关系，提前把认证机构的公钥安装到系统中，这样就不会涉及到传输的问题了。
- 首先服务端会生成公私钥对，私钥自己保存。
- 服务端把公钥交给CA，CA用自己的私钥对服务端的公钥进行加密(数字签名)并生成证书。那么这个时候就涉及到一个问题，怎么把CA的公钥交给客户端，一般是内置在操作系统或者浏览器的，就可以认为CA的公钥是可以信任的。
- 客户端拿到证书以后，用CA的公钥对数字证书进行验证(解密后的值和对证书信息hash后值比较是否相等) 如果比较一致的话，说明该数字证书确实是CA颁发的。
在服务端把证书发给客户端的时候，由于中间人没有CA的私钥。
- 假设中间人有CA的公钥，解密得到服务端公钥，由于中间人没有CA的私钥，所以无法对中间人自己的公钥进行加密，随便传一个签名过去，客户端用CA的公钥解密不了，所以认为证书无效。
- 假设修改证书的明文信息，比较hash值也不会校验成功。
当校验成功以后，就可以认为这个证书是可信任的，用CA公钥解密得到服务端公钥，那么就可以生成一个对称秘钥，用服务端的公钥加密这个对称秘钥发给服务端，就算中间人监听到这个对称秘钥，由于没有服务端的私钥，所以也没办法解密拿到这个对称秘钥。这样服务端就可以顺利拿到对称秘钥。后续的通信就可以用这个对称秘钥进行加密了。
