数据传输加密方式总结
一般来说，HTTP数据交互过程中，数据都是以密文形式传输的，数据加密也就成了目前web中比较常见的部分
对称加密
采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。
这种加密算法也是比较常见的，好处就是密钥在并不进行数据传输，一旦黑客获取到你的密钥，那么你的数据就会泄露，甚至说数据传输过程中会被篡改
例子：
微信支付的签名算法
原始数据：
appid：wxd930ea5d5a258f4f
mch_id：10000100
device_info：1000
body：test
nonce_str：ibuaiVcKdpRxkhJA
其中的sign就是加密后的签名
而加密算法就是：
1、对参数按照key=value的格式，并按照参数名ASCII字典序排序如下
stringA="appid=wxd930ea5d5a258f4f&body=test&device_info=1000&mch_id=10000100&nonce_str=ibuaiVcKdpRxkhJA";
此处就是把需要传输的数据进行连接处理，也就是最基础的混淆
2、第二步：拼接API密钥：
stringSignTemp=stringA+"&key=192006250b4c09247ec02edce69f6a2d" //注：key为商户平台设置的密钥key sign=MD5(stringSignTemp).toUpperCase()="9A0A8659F005D6984697E2CA0A9CF3B7" //注：MD5签名方式
也就是将对称的密钥key以同样方式添加到需要传输的数据后面，然后对数据进行MD5或者SHA256等不可逆加密算法进行处理加密，此时得到的结果就是签名数据。
3、最后要做的就是把签名添加到需要发送的数据后面
<xml> <appid>wxd930ea5d5a258f4f</appid> <mch_id>10000100</mch_id> <device_info>1000</device_info> <body>test</body> <nonce_str>ibuaiVcKdpRxkhJA</nonce_str> <sign>9A0A8659F005D6984697E2CA0A9CF3B7</sign> </xml>
此时接收方在获取到数据之后，通过相同的步骤对除前名以外的数据进行计算获取签名，然后对比双方的签名，签名相同则数据有效，签名不同说明数据被篡改过，直接返回失败。
这种方式的好处在于算法简单有效，坏处就是一旦密钥泄露，攻击者就可以在网关或者路由端拦截修改数据，进行数据破坏。
当然微信支付这种只是通过对称加密方式生成密钥，还可以通过标准算法对传输的数据进行完整的加密，这种理解起来比较简单，就不进行多说了。
当然这微信支付只是把对称加密用于签名验证上，数据传输之间还是明文传输
非对称加密
非对称加密算法需要两个密钥来进行加密和解密，这两个秘钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
发送者通过私钥对数据进行加密，然后接收者通过公钥进行解密，当然，私钥个公钥之间是有一定算法规范的。当然这种加密方式还是比较简单的那种，双方我用私钥进行加密，然后你用公钥就可以解密，双方不对称的密钥，这就是比较完善的数据传输方式，但是因为中间设计到私钥公钥转换的过程，所以大数据量的时候转换会比较慢，所以一般数据没必要通过这种方式进行加解密。
混合加密
混合加密的方式就是保密性非常高的那种了，因为前面两种对称或者非对称都是基于密钥的情况下进行处理的，一旦固定的密钥被泄露，那么数据就会被破解（当然这种情况概率非常小），混合加密就是充分的运用两种不同的加密方式进行混合使用。
举例：假设A和B进行数据传输：
A发送数据给B
1、 A生成一个随机数，假设是123456，先将这个随机数进行非对称加密发送给B；
2、 B得到到A的密文之后，通过公钥解密获取到明文，然后自己生成一个随机数假设是ABCDEF，然后将这个随机数通过非对称加密发送给A；
3、 A得到B的密文，解密得到ABCDEF，然后跟之前的123456进行随机算法排序，假设是123456ABCDEF，这样就得到了一个合成密钥，我们通过这个密钥对要发送的数据进行对称加密，发送给B；
4、 B通过相同的排序算法，得到对称加密的密钥，然后对A传过来的数据进行解密，得到明文。
这种方法的好处显而易见，真正数据进行传输的密钥每次都在改变，实际双方都确认的是数据排序算法，当然这个算法也是可以进行进一步的优化的，在这里就不做过多深入的了解了；从效率上讲，这个算法其实是比较尴尬的，虽然对称加密这部分效率明显比非对称加密效率高，但是由于中间多了一次HTTP请求，所以，总的来看，效率反而降低了。这种加密方式还是适合于那些对于数据保密性非常严格的情况下使用的，一般来说不太建议使用，因为多一次HTTP请求所耗费的资源确实有点大。
