在网络请求中，使用http协议在传输过程中数据很容易被人截取，那对数据的加密就显得很重要。在不使用https的情况下应该怎么解决加密问题呢？来一起看一看流行的加密方式。
对称加密和非对称加密
对称加密：解密和加密都使用一个密钥。这样如果在传输过程中，或者在客户端的密钥被泄露，就会存在整个传输内容泄密的情况发生。显然这种加密方式是存在问题的。
非对称加密：非对称加密的加密和解密使用不同的密钥，分为公钥和私钥。公钥和私钥是成对出现的。公钥加密的数据，只有对应的私钥才能解密。私钥加密的程序只有对应的公钥才能解密。一般讲私钥存在服务器，公钥可以存在每个客户端。服务器向客户端发数据，由私钥加密数据，然后由客户端公钥解密。客户端向服务器发数据，由公钥加密，由私钥解密。整个过程中不存在传输密钥的情况，也就不会造成密钥的丢失。
对称加密和非对称加密的对比
- 安全性：
非对称加密依赖一对密钥，不存在传输问题，不易被第三方获取，安全性更高，算法更复杂。对称加密仅依赖一个密钥，安全性低。 - 加密速度：
非对称加密依赖复杂算法，速度较慢，因此只适合加密较短内容。对称加密速度较快，适合加密长数据。
对称加密+非对称加密过程
非对称加密加密速度慢，不适合加密长数据。但是对称加密又存在被截取的风险。那我们将两者结合起来，说今天的正题。这里我们分别使用RSA加密(非对称加密)和AES加密(对称加密)，并结合客户端和服务器通信来说对称加密和非对称加密在具体场景中的使用。
1、首先由客户端去请求服务器的公钥(rsaPublicKey)，由服务器生成密钥对，服务器存公钥(rsaPublicKey)和私钥(rsaPrivateKey)，将公钥发送给客户端；
2、客户端拿到公钥，保存公钥，为下一步发起请求做准备；
3、客户端准备发起请求，首先生成随机aes密钥(aesKey)；
4、客户端使用aesKey对要加密的数据进行对称加密，生成加密数据encryptData；
5、客户端使用ras公钥(rasPublicKey)对aeskey进行加密，得到得到encryptAesKey；
6、客户端正式发起请求，将encryptAesKey放在请求头，将encryptData放在请求体；
7、服务器收到请求，首先拿到请求头的encryptAesKey，使用对应rsaPriavteKey对encryptAesKey解密拿到aesKey；
8、服务器使用aesKey对请求体中的encryptData进行解密，得到明文请求内容；
9、服务器做出响应，将返回数据由aesKey加密，返回给客户端；
-
10、客户端收到服务器响应，由发起请求的aesKey解密返回数据，拿到明文数据。结束一次请求。下次请求从步骤3开始。
到这里，客户端发起请求和服务器响应的过程就结束了。整个过程使用非对称加密提高了数据的安全性，同时使用对称加密来弥补非对称加密不适宜对长数据加密的缺点，两者结合起来使用可以用真香来形容啦！当然，中间有写地方可以根据自己的理解稍加改动，比如步骤1中，这里公钥通过网络发送到了客户端，也可以直接存在客户端。步骤10中，返回数据由aesKey加密返回，也可以通过私钥加密返回，由客户端通过公钥解密拿到明文。
非对称加密模式有两种，ECB(AES/ECB/PKCS5Padding)和CBC(AES/CBC/PKCS5Padding)。ECB模式是分组的模式，CBC是分块加密后，每块与前一块的加密结果异或后再加密。
通过上述方法，提高了数据的安全性。
签名和验签
除了提高数据的安全性之外，好像还有一个问题值得关注，那就是对用户身份的验证。也就是由客户端对数据签名和服务端对数据验签的过程。具体的步骤如下：
- 1、由客户端生成密钥对，并在通讯正式开始前，把公钥交到服务端手里
- 2、每次发出消息，都有客户端的私钥对数据进行加密(这里看需要了，可以是对消息的摘要进行加密，也可以对固定的字符串，但是记住消息加密内容不能过长的原则)得到签名信息和未加密的数据发送给服务端
- 3、服务端在收到消息后首先用客户端之前的公钥对数据进行解密，如果失败了，那身份验证就失败了；如果成功了，再与明文数据对比是否一致，如果一致，就认为身份验证通过了。
可以把加密解密，签名验签结合使用。
