微信協议简单调研笔记.docVIP

聂永的博客 记录工作/学习的点点滴滴。 微信协议简单调研笔记 前言 微信可调研点很多，这里仅仅从协议角度进行调研，会涉及到微信协议交换、消息收发等。所谓“弱水三千，只取一瓢”吧。 杂七杂八的，有些长，可直接拉到最后看结论好了。 一。微信协议概览 微信传输协议，官方公布甚少，在微信技术总监所透漏PPT《微信之道—至简》文档中，有所体现。 纯个人理解： 因张小龙做邮箱Foxmail起家，继而又做了QQ Mail等，QQ Mail是国内第一个支持Exchange ActiveSync协议的免费邮箱，基于其从业背景，微信从一开始就采取基于ActiveSync的修改版状态同步协议Sync，也就再自然不过了。 一句话：增量式、按序、可靠的状态同步传输的微信协议。 大致交换简图如下： 如何获取新数据呢： 服务器端通知，客户端获取 客户端携带最新的SyncKey，发起数据请求 服务器端生成最新的SyncKey连同最新数据发送给客户端 基于版本号机制同步协议，可确保数据增量、有序传输 SyncKey，由服务器端序列号生成器生成，一旦有新消息产生，将会产生最新的SyncKey。类似于版本号 服务器端通知有状态更新，客户端主动获取自从上次更新之后有变动的状态数据，增量式，顺序式。 二。微信Web端简单调试 在线版本微信： / 通过Firefox + Firebug组合调试，也能证实了微信大致通过交换SyncKey方式获取新数据的论述。 1. 发起GET长连接检测是否存在新的需要同步的数据 会携带上最新SyncKey /cgi-bin/mmwebwx-bin/synccheck?callback=jQuery18306073923335455973_1393208247730r=1393209241862sid=s7c%2FsxpGRSihgZAAuin=937355deviceid=e542565508353877synckey=1_620943725%7C2_620943769%7C3_620943770%7C11_620942796%7C201_1393208420%7C202_1393209127%7C1000_1393203219_=1393209241865 返回内容： window.synccheck={retcode:0,selector:2} selector值大于0，表示有新的消息需要同步。 据目测，心跳周期为27秒左右。 2. 一旦有新数据，客户端POST请求主动获取同步的数据 /cgi-bin/mmwebwx-bin/webwxsync?sid=s7c%2FsxpGRSihgZAAr=1393208447375 携带消息体： {BaseRequest:{Uin:937355,Sid:s7c/sxpGRSihgZAA},SyncKey:{Count:6,List:[{Key:1,Val:620943725},{Key:2,Val:620943767},{Key:3,Val:620943760},{Key:11,Val:620942796},{Key:201,Val:1393208365},{Key:1000,Val:1393203219}]},rr:1393208447374} 会携带上最新的SyncKey，会返回复杂结构体JSON内容。 但浏览端收取到消息之后，如何通知服务器端已确认收到了？Web版本微信，没有去做。 在以往使用过程中，曾发现WEB端有丢失消息的现象，但属于偶尔现象。但Android微信客户端（只要登陆连接上来之后）貌似就没有丢失过。 3. 发送消息流程 发起一个POST提交，用于提交用户需要发送的消息 /cgi-bin/mmwebwx-bin/webwxsendmsg?sid=lQ95vHR52DiaLVqor=1393988414386 发送内容： {BaseRequest:{Uin:937355,Sid:lQ95vHR52DiaLVqo,Skey:A6A1ECC6A7DE59DEFF6A05F226AA334DECBA457887B25BC6,DeviceID:e937227863752975},Msg:{FromUserName:yongboy,ToUserName:hehe057854,Type:1,Content:hello,ClientMsgId:1393988414380,LocalID:1393988414380}} 相应内容： { BaseResponse: { Ret: 0, ErrMsg: } , MsgID: 1020944348, LocalID: 1393988414380 } 再次发起一个POST请求，用于申请最新SyncKey /cgi-bin/mmwebwx-bin/