给自己做一个备忘，写的很简单。就是记录一下我理解的流程。
http传输的是明文，意味着在整条网络链路上，你发送的东西类似于广播，拦截者可以轻易的篡改你发送的内容，然后发给接收者。
比如 王牌对王牌里的传音游戏，从头到尾传的都是没有任何校验的数据，中间的任何篡改，后面的都无法校验，最后的接收者只能一脸懵逼，心里虽然怀疑却也没有办法。
那就需要对传输的数据有个保护的措施。最直接的方式就是加密。将数据装进小黑盒，中间人打不开，只有通信双方才能打开它。
加密就是有解密。那双方都需要手握一对加解密的密钥。这样双方的数据才能加密传输且双方能够正确解密。
好了，那问题来了。这对密钥该如何告知双方呢？密钥也是数据，也存在着明文传输的风险。那好，我们就给这些密钥加密。
那给密钥加密的密钥又该如何安全传输呢？他们也是数据，也存在着明文传输的风险......
感觉像是陷入了死循环。
所以，给密钥加密的密钥我就明文传输！不加密了！
流程如下：
服务器给客户端发送密钥加密密钥的明文L，客户端收到后，将产生的密钥K用L进行加密，发送给服务器，服务器解密后，则获取到密钥K，自此双方可以安全的通信了。
这里会有一个明显的问题：密钥加密密钥L怎么能明文传输呢？这样线路上传输的用L加密的K不就很容易被别人解密了吗？
所以我们要让密钥加密密钥L虽然是明文，但中间人截获了L，但用L解不了L加密的K。
这不就是非对称密钥了吗？密钥加密密钥L就是公钥，私钥在服务器端存着。
但这样还有个问题
公钥明文传过去，中间人虽然不能用它进行解密K，但完全可以篡改它或者完全替换，用自己的密钥传给客户端，客户端用中间人的密钥加密了K发出去，这样中间人就完全截获了这个通信用的k密钥。
所以说，最后一个关键，就是如何让明文传输的密钥加密密钥L不能被篡改和替换。
答案就是数字签名+证书！
数字签名解决了公钥被篡改的问题：
公钥+证书其他的内容算出hash，用私钥加密hash得到签名。这样，你篡改任何明文数据，你是算不出签名的，因为你没有服务器的私钥。客户端用证书里的明文公钥解密签名，拿到hash1。再用证书里的hash算法算一下证书的明文得到hash2，hash1和hash2相等，则证明证书没被篡改。
没被篡改也不意味着公钥没有问题，因为整个证书可以连窝端啊，直接中间人换一套自己的证书上去。客户端被蒙在鼓里。所以需要解决证书的信任问题。
证书解决了整个公钥被替换的问题：
那证书怎么解决信任问题呢？就是要给证书加一个防伪标签。和人民币一个道理，要有一个可信任的权威机构进行颁发。https的证书的办理需要一整套正规的流程，填写一些个人信息。这就杜绝了中间人去申请到这些证书，毕竟他们见不得光。申请下证书干违法的事，等于裸奔，一清二楚。
证书里有一条证书的信任链，最顶层就是根证书，是安装在系统或浏览器里的。根证书签发中层证书颁发机构，中层再颁发具体的证书。层层验证，就可证明证书的合法性。
所以说，证书的出现解决了 公钥被篡改，公钥被伪造的可能性。
这样，公钥(密钥加密密钥)是安全的，那通过公钥传输的加密密钥也就是安全的，只有服务器能解密。
这样，双方就在一个安全的环境里进行密文通信啦。
