移动互联网架构以及数据传输剖析

上图是一个典型的访问量相对较大的互联网分层架构：

• client：客户端，如手机app，电脑客户端（浏览器等）
• web层：实现满足业务功能
• 缓存：加速访问速度，如memcached、redis等
• 队列：缓冲大数据并发，如rabbitmq、kafka等
• 数据库层：数据持久化，如mysql、hbase等

说白了就是围绕着大量的数据转圈圈，接收数据，处理数据，分析数据，存储数据，返回数据

那么说到数据，就不得不说一下数据传输安全问题了：

数据传输的格式，也就是上下游约定的协议，协议很重要：

• 特定的接口是以二进制形式传输，如rpc,jdbc等，这个就不说了
• 最基本的是http/https服务的自定义数据传输

涉及到重要数据安全性来说，目前微信做的比较好，为什么呢，因为目前大多数企业都在对标或者模仿微信，我这边大概说明一下：

http请求时，客户端传过来的请求参数通过双方确定的字段进行排序后进行md5签名验证，确保是不是合法客户端发过来的消息，（大多数是RSA,证书），然后通过后再从包体中解析自己想要的字段，如下是微信的加密方案详解：

关于加解密方案的详细说明

术语及说明

开启回调模式时，有以下术语需要了解：

1.msg_signature是签名，用于验证调用者的合法性。具体算法见以下'消息体签名'章节

2.EncodingAESKey用于消息体的加密，长度固定为43个字符，从a-z, A-Z, 0-9共62个字符中选取，是AESKey的Base64编码。解码后即为32字节长的AESKey

3.AESKey=Base64_Decode(EncodingAESKey + “=”)，是AES算法的密钥，长度为32字节。AES采用CBC模式，数据采用PKCS#7填充至32字节的倍数；IV初始向量大小为16字节，取AESKey前16字节。具体详见：http://tools.ietf.org/html/rfc2315

4.msg为消息体明文，格式为XML

5.msg_encrypt = Base64_Encode( AES_Encrypt[random(16B) + msg_len(4B) + msg + $CorpID] )，是对明文消息msg加密处理后的Base64编码。其中random为16字节的随机字符串；msg_len为4字节的msg长度，网络字节序；msg为消息体明文；$CorpID为企业号的标识

消息体签名

为了验证调用者的合法性，微信在回调url中增加了消息签名，以参数msg_signature标识，企业需要验证此参数的正确性后再解密。验证步骤：

1.企业计算签名：dev_msg_signature=sha1(sort(token、timestamp、nonce、msg_encrypt))。sort的含义是将参数按照字母字典排序，然后从小到大拼接成一个字符串

2.比较dev_msg_signature和msg_signature是否相等，相等则表示验证通过

在被动响应消息时，企业同样需要用如上方法生成签名并传给微信

加解密方案说明

• 对明文msg加密的过程如下：

msg_encrypt = Base64_Encode( AES_Encrypt[random(16B) + msg_len(4B) + msg + $CorpID] )

AES加密的buf由16个字节的随机字符串、4个字节的msg长度、明文msg和$CorpID组成。其中msg_len为msg的字节数，网络字节序；$CorpID为企业号的CorpID。经AESKey加密后，再进行Base64编码，即获得密文msg_encrypt。

• 对应于加密方案，解密方案如下：

1.对密文BASE64解码：aes_msg=Base64_Decode(msg_encrypt)

2.使用AESKey做AES解密：rand_msg=AES_Decrypt(aes_msg)

3.验证解密后$CorpID、msg_len

4.去掉rand_msg头部的16个随机字节，4个字节的msg_len,和尾部的$CorpID即为最终的消息体原文msg