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

  • 移动互联网架构以及数据传输剖析已关闭评论
  • 115,085 views
  • A+
所属分类:编程开发

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

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

  • 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

 

 

  • 我的微信
  • 微信扫一扫
  • weinxin
  • 微信公众号
  • 微信公众号扫一扫
  • weinxin
avatar