HTTP协议
超文本传输协议，属于应用层，基于 TCP
通过请求/响应的方式，在客户端和服务端之间通信
缺点：完全以明文方式传递信息，不做任何加密，信息很可能被某个中间人恶意截获或篡改，因此不安全。
针对HTTP协议的不安全进行改进
版本1：采用对称加密
约定一个随机生成的密钥，通信过程中发送和接收方都是用该密钥来加密和解密。
存在的问题：约定加密方式和密钥的通信是明文，如果密钥被拦截，中间人仍可以解密后续所有通信内容。
版本二：非对称加密传输密钥，对称加密传递信息
由于对称加密中，密钥的约定采用的是明文，所以使用非对称加密为密钥的传输做一层额外的保护。
非对称加密：一组秘钥对包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，公钥解密。
版本二的基本步骤：
①首先传输非对称加密的公钥
②使用接收到的公钥对对称加密的密钥进行加密
③利用非对称加密的私钥解开公钥的加密，得到对称加密的密钥，之后可以进行对称加密通信
相比版本一的改进：在通信过程中，即使信息被截获，但是由于其并不知道非对称加密的私钥是什么，所以无从获取对称加密的密钥是什么
版本二仍存在的不足：中间人截获非对称加密的公钥后，自己另外生成一对非对称加密的公钥私钥，用自己生成的公钥代替捕获的公钥发送出去。接受方会使用错误的非对称加密的公钥对对称加密的密钥进行加密，中间人再次捕获加密后的对称加密的密钥，用私钥进行解密获得对称加密的密钥
版本一的根本问题是以明文的方式传递对称加密的密钥，没有做任何加密处理。
版本二的根本问题是无法确定用于加密对称加密密钥的公钥是否真正来自服务端（有可能被中间人替换过）
版本三：引入第三方CA
引入第三方CA的目的是解决判断非对称加密的公钥是否来自服务端的问题
版本三的基本流程：
①服务端把非对称加密的公钥发给证书颁发机构，向证书颁发机构申请证书
②证书颁发机构拥有一对公钥私钥。机构利用自己的私钥来加密服务端发来的非对称加密的公钥，并且通过服务端网址等信息生成一个证书签名。证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给服务端
3 当客户端向服务端请求通信时，服务端不再直接发送公钥，而是把自己向证书颁发机构申请的证书发送给客户端。
4 客户端收到证书后，首先验证证书的真伪。各大浏览器和操作系统已经维护了所有权威认证机构的名称和公钥。客户端只需要知道是哪个机构颁发的证书，就可以从本地找到对应的机构公钥，解密出证书签名。
客户端按照同样的签名规则，自己生成一个证书签名，如果两个签名一致，说明证书是真的。
验证证书为真后，使用机构公钥解密出服务端的非对称加密的公钥。
至此保证客户端获取的非对称加密的公钥是服务端发送的非对称加密的公钥，余下步骤可以按照版本二进行。
HTTPS协议
版本三引入第三方机构就是HTTPS的主体思想。
HTTPS在HTTP协议的基础上增加了SSL安全层。认证流程就是在SSL层中完成的。
