以 EAS为基础猜测微信协议

--mycinbrin@gmail.com

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

基础知识：长轮询

下页有文字说明下页有文字说明

● 左：轮询– 客户端每隔两秒问服务器：＂有无消息？＂– 服务器立刻回答：＂无＂或＂有，数据是＊＊＊＂

● 右：长轮询– 客户端问服务器：＂两秒之内告诉我有无消息？＂– 服务器 hold住这个连接最多两秒，若在两秒之内有消息，将消息返回，否则在两秒的时候返回＂无消息＂．

– 之后在客 端收到户 response的瞬 ，再 一个同间 发第一 一 的 求，并等待 秒．如此循 ．步 样 请 两 环

● 上页有图

● 长轮询是实现 http服务器推送的主要方式．● 在有线网中，那个＂两秒＂可能很长，甚至无限长．但在移动网中，由于 http连接可能会被超时掐断，因此是两分钟 (?,不太确定 )，应该是媒体所言＂微信的心跳频率＂．

● 如果有 tcp就更方便，可以直接写 socket，不需要 long-polling, 但 wap网只有 http．

● 在 webIM中常用． (看过人人网的代码，是long-polling, 据说新浪私信和 webqq也是．）

● 在接下来的 eas和微信 sync中有涉及．

EAS协议

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

● 以下主要分析 sync．

会话例● 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=****//第三次查询，增量同步

要点解析● 上页中的相邻请求都是隔固定时间的，如两分钟● 客户端每次使用旧 key标记自己的状态● 服 端 次将新务 每 key和 量数据一起返回增● key是递增的，但不要求连续● 客户端自行决定 polling还是 long-polling

– 请求的某个参数决定服务器是否立即返回● 服务端如何维护，或如何实现，微软并未说明

关于微信协议● 其实是两部分，上面接收，下面发送．如我所分割．五条箭头从上到下：

● １．用 long-polling实现服务器推送信令通知

● ２．使用上次的 synckey来请求● ３．得到新的 synckey和数据● ４．用户发消息， http post请求● ５．服务器回应，表示发送成功

微信一些问题的解析● 在消息的机制设计上延续了微信团队的邮件传统．

● 至少在异步消息（文字和语音留言）上，是通过服务器做中转．

● 视频聊天应该是 UDP打洞 p2p