1.对数据进行加密：https = http + ssl/tls 目前都叫tls 不叫ssl了<br>
加密方案
1.客户端主动去像服务端获取密钥，服务端返回密钥，之后进行通信（密钥要先在网络传递一次，可能被劫持了） 不可靠
2.非对称加密（服务端产生两把钥匙，分别是公钥和私钥，将公钥发给客户端） 客户端发送消息的时候 通过公钥加密，服务端通过私钥解密。 中间有可能公钥被劫持了，但是公钥无法解密内容 （单向） 如果想实现双向？ 分别两方都有一对钥匙,这导致性能不好
3.混合加密： 考虑用两种加密方式来实现， 第一次我们通过非对称加密，让服务端把自己的公钥交给客户端 （公钥不怕劫持，因为劫持到公钥是无法解密的），客户端生成一个会话密钥（随机值） 用服务器的公钥加密这个随机值（只能服务端解密），服务端收到加密后的内容，进行解密拿到了这个随机值 （双方都有了一个随机值了）后面可以通过对称加密通信。 第一次你访问服务端的时候可能访问的不是真正的服务端（中间商）
4.通过证书来确定对方的身份是正确的 （找个公安局，发个身份证 ，我就知道我是我了） 给公钥增加认证<br>通过证书让公钥变得可信任，客户端向服务端要证书，服务端通过ca机构(ca机构有两把钥匙 公私钥)生成一个证书 （服务器：公钥，过期：xxx） 。 将生成的证书通过ca机构的私钥来进行加密，发送给客户端。客户端收到证书后（内置了ca机构的公钥，可以解密），这样就可以顺利的拿到对方的公钥，而且能确定对方身份<br>缺陷：问题在于证书比较大，直接私钥加密，公钥解密浪费性能。 我们将证书进行摘要（摘要的结果很短）用ca的私钥对这个摘要进行加密。 客户收到后会采用摘要算法对内容再次进行摘要，用内置的ca机构的公钥解密出摘要的结果。 看一下两个摘要是否一致，一致说明内容没有被篡改 <br> 为了解决直接加密证书的问题，就变成了对证书进行摘要，再将摘要的结果私钥进行签名。客户端采用公钥来解密签名。获得了证书的摘要结果。再次对证书的内容进行摘要，如果摘要结果一致，则说明证书可信
整个https的过程就是 先采用非对称加密，来传递公钥，之后通过对称加密来进行解析。
