由于http协议是明文传输数据，数据的安全性没有保障。为了改进这种明文传输协议，https诞生了。
https是在应用层和传输层之间，增加了一层ssl加密。对于加密，请往下看：
1、对称加密
每次在发送数据之前，服务器先生成一把密钥，然后先通过明文传输的方式将密钥传递给客户端。之后服务器给客户端传送数据的时候，会用着把密钥对数据进行加密，客户端收到加密数据之后，用刚刚收到的密钥对数据进行解密。
弊端：（1）密钥在传输的过程中容易被人截取； （2）客户端并不知道与自己建立连接的服务器是不是真的目标服务器。
那么，如何把密钥安全的传给客户端呢？这就要看非对称加密了。
2、非对称加密
客户端和服务器各自都拥有两把钥匙，一把钥匙是公开的，称为公钥；一把是保密的（只有自己本人知道），叫做私钥。
用公钥加密的数据，只有对应的私钥才能解密；用私钥加密的数据，只有对应的公钥才能解密。
如此，服务器在给客户端传输数据的过程中，可以用客户端明文传输给他的公钥进行加密，然后客户端收到后，再用自己的私钥进行解密。客户端给服务器发送数据的时候，也采用相同的方式，这样就能保证数据的安全传输了。
但是，非对称加密的加密时间是对称加密的上百倍。如果一直采用非对称加密来进行数据的传输，速度会比较慢，如何改进？
3、对称加密+非对称加密结合
用非对称加密的方式去传输对称加密的密钥，这样可以保证对称加密的密钥可以安全的交付给对方。
（也就是
1、客户端先把非对称加密的公钥，明文传输给服务器；
2、服务端在接到密钥之后，会生成一把用于对称加密的密钥；
3、服务器用之前接到的公钥对刚刚生成的密钥进行加密，然后传输给客户端；
4、客户端通过自己的密钥对服务器传过来的被公钥加密过的密钥进行解密；）
此时，服务端和客户端就都拥有了一把用于对称传输的密钥，而且这个密钥是没有被截取风险的。
但是，这样就能确保万无一失了吗？
如果你的回答是“是”，那你就太嫩了。
如果在步骤一的时候，公钥被第三方截取，之后客户端与第三方走完了上述的四个步骤，建立了对称加密的传输。第三方再和服务器走完上面的四步。如此，第三方拥有了和客户端进行对称传输的密钥，以及和服务器传输的密钥。而这个第三方的存在，服务器和客户端都没办法察觉到。
怎么办？关键问题就是客户端不知道和自己建立连接的是不是真的目标服务器。那么，我们需要在建立连接的时候，对服务器的身份进行验证。https加密的过程，闪亮登场了
数字证书
我们需要一个大家都认可的认证中心（CA）
服务器产生数字证书的过程：
1、服务器在给客户端传送公钥的过程中，会把公钥以及服务器的个人信息通过哈希算法（这个算法以后研究一下）生成信息摘要。
2、之后服务器利用CA提供的私钥对信息摘要进行加密，来形成数字签名。
3、将没有经过哈希算法处理的个人信息以及公钥，和数字签名合并在一起，形成数字证书。
客户端拿到数字证书之后：
1、就会利用CA提供的公钥对数字证书里面的数字签名进行解密来得到信息摘要
2、然后对数组证书里面的服务器公钥以及服务器的个人信息进行hash得到另一份信息摘要。
3、最后把两份信息摘要进行对比，如果一样，则证明是服务器。
如此，保证服务器的公钥就安全的交给客户端了。
那么CA向客户端提供的公钥以及向服务器提供的私钥又是从哪来的？
服务器需要向认证中心去申请证书，客户端也会内置这些证书。
当客户端收到服务器传来的数据数字证书时，会在内置的整数列表里，查看是否有解开该数字特征的公钥。