http明文传输
一个http请求会 把请求参数，明文传输过去，服务器也明文返回。
sequenceDiagram
客户端->>服务器: 明文请求
服务器-->>客户端: 明文响应
这时候容易被人拦截并存储所有的请求行为。
sequenceDiagram
客户端->>拦截者: 明文请求
拦截者->>服务器: 明文请求
服务器-->>拦截者: 明文响应
拦截者-->>客户端: 明文响应
拦截者会把所有的拦截信息存储。
传输内容加密
最简单的对称加密，加密密钥、解密密钥一样。这就需要传输密钥。
sequenceDiagram
客户端->>服务器: 首次请求，等待密钥
服务器-->>客户端: 对称加密密钥
客户端->>服务器: 加密后的请求数据
服务器-->>客户端: 解析请求数据，返回加密后的响应数据
同一样的，拦截者还是可以拦截获取对称加密的密钥
sequenceDiagram
客户端->>拦截者: 首次请求，等待密钥
拦截者->>服务器: 首次请求，等待密钥
服务器-->>拦截者: 对称加密密钥
拦截者-->>客户端: 对称加密密钥
客户端->>拦截者: 加密后的请求数据
拦截者->>服务器: 加密后的请求数据
服务器-->>拦截者: 解析请求数据，返回加密后的响应数据
拦截者-->>客户端: 解析请求数据，返回加密后的响应数据
拦截者 获取所有请求行为，获取对称加密密钥，逆转加密解析请求行为。
非对称加密
因为对称加密获取 密钥可以逆转加密获取加密前的数据。 这时候就需要非对称加密。
sequenceDiagram
客户端->>服务器: 首次请求，等待公钥
服务器-->>客户端: 非对称加密公钥
客户端->>服务器: 公钥加密后的请求数据
服务器-->>客户端: 私钥解析请求数据，返回私钥加密后的响应数据
首次请求服务器返回非对称加密公钥，就算拦截者拦截获取了公钥，以及加密后的数据，但是没有私钥，没法解析用户请求行为。但是过程是可以解析服务器的行为的。也有一定的危害。
sequenceDiagram
客户端->>拦截者: 首次请求，等待公钥
拦截者->>服务器: 首次请求，等待公钥
服务器-->>拦截者: 非对称加密公钥，拦截存储公钥
拦截者-->>客户端: 非对称加密公钥
客户端->>拦截者: 公钥加密后的请求数据
拦截者->>服务器: 公钥加密后的请求数据
服务器-->>拦截者: 私钥解析请求数据，返回私钥加密后的响应数据
拦截者-->>客户端: 可以解析私钥加密后的数据，返回私钥加密后的响应数据
还有拦截者可以伪造公钥，这个最后讲。 而且非对称加密非常耗时，性能方面不允许。所以需要非对称加密+对称加密。
对称加密+非对称加密
就是服务器生成一个 非对称加密的公钥私钥，把公钥给客户端，然后客户端生成一个对称加密的密钥，通过公钥加密传给服务器，服务器先用私钥解密 获取对称加密的密钥，后续所有客户端和服务器间的请求都先对称加密加密一下，再用私钥或者公钥加密，这样就算拦截者用公钥解开 服务端的响应，也没发再用对称加密的密钥解密，因为对称加密的密钥是客户端用公钥加密传送给服务器的，所以，只有服务器的私钥能解开。
sequenceDiagram
客户端->>服务器: 首次请求等待公钥
服务器-->>客户端: 返回公钥
客户端->>服务器: 生成对称加密密钥，公钥加密发送
服务器-->>客户端: 私钥解密获取对称加密密钥,告诉客户端
客户端->>服务器: 对称加密请求
服务器-->>客户端: 对称解密请求，对称加密响应
这时候基本没问题了，这时候涉及一个问题，公钥没有被篡改。
https证书
CA证书有公钥私钥，客户端第一次请求的时候会把 服务端的公钥以及网站信息通过hash算法生成消息摘要，CA用证书将它用CA私钥加密，获得签名。客户端用CA公钥解密签名获得消息摘要，然后用签名获得消息摘要与hash算法获得证书的消息摘要对比，确认身份。
