1. 以 EAS 为基础猜测微信协议
--mycinbrin@gmail.com

2. 目录
●
长轮询
●
Microsoft Exchange Active Sync
●
对微信协议的猜测

3. 基础知识：长轮询
下页有文字说明下页有文字说明

4. ●
左：轮询
– 客户端每隔两秒问服务器：＂有无消息？＂
– 服务器立刻回答：＂无＂或＂有，数据是＊＊＊＂
●
右：长轮询
– 客户端问服务器：＂两秒之内告诉我有无消息？＂
– 服务器 hold 住这个连接最多两秒，若在两秒之内有
消息，将消息返回，否则在两秒的时候返回＂无消息
＂．
– 之后在客 端收到户 response 的瞬 ，再 一个同间 发
第一 一 的 求，并等待 秒．如此循 ．步 样 请 两 环
●
上页有图

5. ●
长轮询是实现 http 服务器推送的主要方式．
●
在有线网中，那个＂两秒＂可能很长，甚至无限
长．但在移动网中，由于 http 连接可能会被超时
掐断，因此是两分钟 (?, 不太确定 ) ，应该是媒
体所言＂微信的心跳频率＂．
●
如果有 tcp 就更方便，可以直接写 socket ，不需
要 long-polling, 但 wap 网只有 http ．
●
在 webIM 中常用． ( 看过人人网的代码，是
long-polling, 据说新浪私信和 webqq 也是．）
●
在接下来的 eas 和微信 sync 中有涉及．

6. EAS 协议
EAS 协议本来用处是向移动端同步邮件．
●
分为 foldersync （同步文件夹目录，即邮箱内有
哪几个文件夹？）和 sync （每个文件夹内有哪
些文档？）两部分．
●
以下主要分析 sync ．

7. 会话例
●
Client: synckey=0 // 第一次 key 为 0
●
Server: newsynckey=1235434 // 第一次返回新 key
●
Client: synckey=1235434 // 使用新 key 查询
●
Server: newsynckey=1647645,data=*****// 第一次查询，得到新
key 和数据
●
Client: synckey=1647645
●
Server: newsynckey=5637535,data=null // 第二次查询，无新消
息
●
Client: synckey=5637535
●
Server: newsynckey=8654542, data=****// 第三次查询，增量同
步

8. 要点解析
●
上页中的相邻请求都是隔固定时间的，如两分钟
●
客户端每次使用旧 key 标记自己的状态
●
服 端 次将新务 每 key 和 量数据一起返回增
●
key 是递增的，但不要求连续
●
客户端自行决定 polling 还是 long-polling
– 请求的某个参数决定服务器是否立即返回
●
服务端如何维护，或如何实现，微软并未说明

9. 关于微信协议
●
其实是两部分，上面接收，下面发
送．如我所分割．五条箭头从上到
下：
●
１．用 long-polling 实现服务器推
送信令通知
●
２．使用上次的 synckey 来请求
●
３．得到新的 synckey 和数据
●
４．用户发消息， http post 请求
●
５．服务器回应，表示发送成功

10. 微信一些问题的解析
●
在消息的机制设计上延续了微信团队的邮件传
统．
●
至少在异步消息（文字和语音留言）上，是通过
服务器做中转．
●
视频聊天应该是 UDP 打洞 p2p