数据传输过程的安全考虑

1. 数据包启用Gip压缩(服务端下行)，节省流量，一般浏览器或httplib支持decode.

2. AES加密解密 

 加密和解密使用同一个key, 双方都保留此key，准确的说需要key和vector(向量)

3. RSA

加密时用public key加密, 解密时用private key解密，密钥是成对的，这样加密方只需要对方的公钥加密，私钥在解密方这里(甲乙双方反过来一样看待)，安全。密钥不可能同时存在一方。

key有1024或2048位，即便同一内容，两次加密结果可能不同，但不影响解密。 

original: c360.pay

aes: vbPaUC/FGy5m4rQ4HO5JUg==

rsa: tsrks2u9Nf5EgA0akKCPj5YK/h9R7lldPyOipozk/XlCpnjhRcjPeSeZfCrIR1WPaMfSRsjanqrmoA5PuTE92cUi1cAx6+UjsVr2BBZKVmIhl2uoLSuIIIDIxp+kAOQ0DYLFHW4QgHlwSjqJjDAeu55ASuXx5D/MjZy3zKOXWqc=

可见AES加密的内容比RSA小很多，但RSA应该更安全些。

4. API接口安全

要有验证，不能直接访问。

cookie或auth sig , 在head增加此参数，根据一定的规则生成，服务端验证，确保这个请求是合法的

**参数加签名** 

所有请求必需有appkey和timestamp 

appkey和appsecret是对应一组(由服务端生成)，传输过程中使用appkey(服务端根据此识别客户端并找出appsecret值)，签名时使用appsecret做hash。

时间戳由客户端带上来，服务端验证如果时差太大刚认为请求无效(重复请求或数据被篡改)

举例：

/api/resource?para1=xxx&para2=xxx

生成签名: hash(para1=xxx&para2=xxx&appkey=xxx&timestamp=148897123456)=fx51lkd8vjkxsksdlk  

注：生成签名的规则及内容自己根据实际情况决定

最终客户端发起的请求如下：

/api/resource?para1=xxx&para2=xxx&appkey=xxx&timestamp=148897123456&sign=fx51lkd8vjkxsksdlk  

服务端收到后检验

a. 检查timestamp值是否合理，如果差值太大，直接response error

b. 根据appkey找到appsecret，和客户端一样的逻辑做hash, 得到的签名和sign参数比较， 如不相等直接response error