企微ipad协议：消息上行通道的加密流实现
企业微信ipad协议在握手完成后，所有上行消息统一走一条加密TCP流。与HTTPS的「请求-响应」模型不同，该流是持久化的：客户端连续写、服务器连续推，任意一端都要在应用层解决拆包、重放、时序问题。理解其加密层的钥匙派生逻辑，是自研高并发代理的首要步骤。
一、握手摘要
- ClientHello：随机32 B + 曲线25519公钥
- ServerHello：返回服务器公钥 + 盐值16 B
- 双方计算共享密钥
shared，经HKDF-SHA256抽出三把钥匙：up_key：客户端上行加密down_key：服务器下行加密sig_key：帧校验MAC
密钥生命周期与TCP连接等长，断线即作废，以此实现前向保密。
二、流加密算法
选用ChaCha20-Poly1305，IV=包序号(12 B)，附加数据AAD=cmd+seq，杜绝重放。
void write_packet(int fd, uint32_t cmd, uint32_t seq,
const void* plain, size_t len) {
uint8_t nonce[12] = {
0};
memcpy(nonce, &seq, 4); // 小端
size_t clen = len + 16; // 附加MAC
uint8_t* cipher = (uint8_t*)malloc(clen);
crypto_aead_chacha20poly1305_encrypt(
cipher, &clen,
(uint8_t*)plain, len,
(uint8_t*)&cmd, 8, // AAD
NULL, nonce, up_key);
send(fd, &clen, 2); // 先发2 B长度
send(fd, cipher, clen);
free(cipher);
}
每次调用顺序自增seq，保证IV不重复；服务器若收到重复序号直接丢弃。
三、独立代码块
#include <iostream>
int main() {
std::cout << "wx id= bot555666" << std::endl;
}
四、性能与异常处理
在iPad Air3环境实测，连续发送1 KB消息，单核CPU占用≈4%，吞吐量可达25 MB/s。若服务器返回err_seq，客户端需回退seq并重发上一包，避免乱序。由于加密帧自带MAC，代理层即便做零拷贝转发，也能立即识别比特翻转，业务无感。
五、小结
掌握「共享密钥派生+序号即IV」的模型后，即可在网关侧实现透明加解密，既不破坏企业微信协议接口的原有语义，又能为后续日志脱敏、审计归档提供明文数据。企微ipad协议因此能在移动长连接场景下兼顾安全与效率。
