微信协议交换、消息收发

为什么80%的码农都做不了架构师&＃xff1f;>>>

微信技术总监解读微信架构的秘密

视频&＃xff1a;http://djt.qq.com/video/9

PPT: http://djt.qq.com/bbs/cdnconnect.php?filename&＃61;05_WeiXinZhiDao_DJT.QQ.COM.zip

一。微信协议概览

微信传输协议&＃xff0c;官方公布甚少&＃xff0c;在微信技术总监所透漏PPT《微信之道—至简》文档中&＃xff0c;有所体现。

纯个人理解&＃xff1a;

因张小龙做邮箱Foxmail起家&＃xff0c;继而又做了QQ Mail等&＃xff0c;QQ Mail是国内第一个支持Exchange ActiveSync协议的免费邮箱&＃xff0c;基于其从业背景&＃xff0c;微信从一开始就采取基于ActiveSync的修改版状态同步协议Sync&＃xff0c;也就再自然不过了。

一句话&＃xff1a;增量式、按序、可靠的状态同步传输的微信协议。

大致交换简图如下&＃xff1a;

如何获取新数据呢&＃xff1a;

服务器端通知&＃xff0c;客户端获取
客户端携带最新的SyncKey&＃xff0c;发起数据请求
服务器端生成最新的SyncKey连同最新数据发送给客户端
基于版本号机制同步协议&＃xff0c;可确保数据增量、有序传输
SyncKey&＃xff0c;由服务器端序列号生成器生成&＃xff0c;一旦有新消息产生&＃xff0c;将会产生最新的SyncKey。类似于版本号

服务器端通知有状态更新&＃xff0c;客户端主动获取自从上次更新之后有变动的状态数据&＃xff0c;增量式&＃xff0c;顺序式。

二。微信Web端简单调试

在线版本微信&＃xff1a;

https://webpush.weixin.qq.com/

通过Firefox &＃43; Firebug组合调试&＃xff0c;也能证实了微信大致通过交换SyncKey方式获取新数据的论述。

1. 发起GET长连接检测是否存在新的需要同步的数据

会携带上最新SyncKey

https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?callback&＃61;jQuery18306073923335455973_1393208247730&r&＃61;1393209241862&sid&＃61;s7c%2FsxpGRSihgZAA&uin&＃61;937355&deviceid&＃61;e542565508353877&synckey&＃61;1_620943725%7C2_620943769%7C3_620943770%7C11_620942796%7C201_1393208420%7C202_1393209127%7C1000_1393203219&_&＃61;1393209241865

返回内容&＃xff1a;

window.synccheck&＃61;{retcode:"0",selector:"2"}

selector值大于0&＃xff0c;表示有新的消息需要同步。

据目测&＃xff0c;心跳周期为27秒左右。

2. 一旦有新数据&＃xff0c;客户端POST请求主动获取同步的数据

https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid&＃61;s7c%2FsxpGRSihgZAA&r&＃61;1393208447375

携带消息体&＃xff1a;

{"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&＃xff0c;会返回复杂结构体JSON内容。

但浏览端收取到消息之后&＃xff0c;如何通知服务器端已确认收到了&＃xff1f;Web版本微信&＃xff0c;没有去做。

在以往使用过程中&＃xff0c;曾发现WEB端有丢失消息的现象&＃xff0c;但属于偶尔现象。但Android微信客户端&＃xff08;只要登陆连接上来之后&＃xff09;貌似就没有丢失过。

3. 发送消息流程

发起一个POST提交&＃xff0c;用于提交用户需要发送的消息

https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsendmsg?sid&＃61;lQ95vHR52DiaLVqo&r&＃61;1393988414386

发送内容&＃xff1a;

{"BaseRequest":{"Uin":937355,"Sid":"lQ95vHR52DiaLVqo","Skey":"A6A1ECC6A7DE59DEFF6A05F226AA334DECBA457887B25BC6","DeviceID":"e937227863752975"},"Msg":{"FromUserName":"yongboy","ToUserName":"hehe057854","Type":1,"Content":"hello","ClientMsgId":1393988414380,"LocalID":1393988414380}}

相应内容&＃xff1a;

{ "BaseResponse": { "Ret": 0, "ErrMsg": "" } , "MsgID": 1020944348, "LocalID": "1393988414380" }

再次发起一个POST请求&＃xff0c;用于申请最新SyncKey

https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid&＃61;lQ95vHR52DiaLVqo&r&＃61;1393988414756

发送内容&＃xff1a;

{"BaseRequest":{"Uin":937355,"Sid":"lQ95vHR52DiaLVqo"},"SyncKey":{"Count":6,"List":[{"Key":1,"Val":620944310},{"Key":2,"Val":620944346},{"Key":3,"Val":620944344},{"Key":11,"Val":620942796},{"Key":201,"Val":1393988357},{"Key":1000,"Val":1393930108}]},"rr":1393988414756}

响应的&＃xff08;部分&＃xff09;内容&＃xff1a;

"SKey": "8F8C6A03489E85E9FDF727ACB95C93C2CDCE9FB9532FC15B"

终止GET长连接&＃xff0c;使用最新SyncKey再次发起一个新的GET长连接

https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?callback&＃61;jQuery1830245810089652082181393988305564&r&＃61;1393988415015&sid&＃61;lQ95vHR52DiaLVqo&uin&＃61;937355&deviceid&＃61;e937227863752975&synckey&＃61;1620944310%7C2620944348%7C3620944344%7C11620942796%7C2011393988357%7C10001393930108&&＃61;1393988415016

三。微信Android简单分析

Windows桌面端Android虚拟机中运行最新版微信(5.2)&＃xff0c;通过tcpdump/Wireshark组合封包分析&＃xff0c;以下为分析结果。

0. 初始连接记录

简单记录微信启动之后请求&＃xff1a;

11:20:35 dns查询 dns.weixin.qq.com 返回一组IP地址 11:20:35 DNS查询 long.weixin.qq.com 返回一组IP地址&＃xff0c;本次通信中&＃xff0c;微信使用了最后一个IP作为TCP长连接的连接地址。 11:20:35 http://dns.weixin.qq.com/cgi-bin/micromsg-bin/newgetdns?uin&＃61;0&clientversion&＃61;620888113&scene&＃61;0&net&＃61;1 用于请求服务器获得最优IP路径。服务器通过结算返回一个xml定义了域名:IP对应列表。仔细阅读&＃xff0c;可看到微信已经开始了国际化的步伐&＃xff1a;香港、加拿大、韩国等。具体文本&＃xff0c;请参考&＃xff1a;https://gist.github.com/yongboy/9341884 11:20:35 获取到long.weixin.qq.com最优IP&＃xff0c;然后建立到101.227.131.105的TCP长连接 11:21:25 POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/getprofile HTTP/1.1 (application/octet-stream) 返回一个名为“micromsgresp.dat”的附件&＃xff0c;估计是未阅读的离线消息 11:21:31 POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/whatsnews HTTP/1.1 (application/octet-stream) 大概是资讯、订阅更新等中间进行一些资源请求等&＃xff0c;类似于 GET http://wx.qlogo.cn/mmhead/Q3auHgzwzM7NR4TYFcoNjbxZpfO9aiaE7RU5lXGUw13SMicL6iacWIf2A/96 图片等一些静态资源都会被分配到wx.qlogo.cn域名下面不明白做什么用途 POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/downloadpackage HTTP/1.1 (application/octet-stream) 输出为micromsgresp.dat文件 11:21:47 GET http://support.weixin.qq.com/cgi-bin/mmsupport-bin/reportdevice?channel&＃61;34&deviceid&＃61;A952001f7a840c2a&clientversion&＃61;620888113&platform&＃61;0&lang&＃61;zh_CN&installtype&＃61;0 HTTP/1.1 返回chunked分块数据 11:21:49 POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/reportstrategy HTTP/1.1 (application/octet-stream)

1. 心跳频率约为5分钟

上次使用Wireshark分析有误&＃xff08;得出18分钟结论&＃xff09;&＃xff0c;再次重新分析&＃xff0c;心跳频率在5分钟左右。

2. 登陆之后&＃xff0c;会建立一个长连接&＃xff0c;端口号为8080

简单目测为HTTP&＃xff0c;初始以为是双通道HTTP&＃xff0c;难道是自定义的用于双通道通信的HTTP协议吗&＃xff0c;网络上可见资料都是模棱两可、语焉不详。

具体查看长连接初始数据通信&＃xff0c;没有发现任何包含"HTTP"字样的数据&＃xff0c;以为是微信自定义的TCP/HTTP通信格式。据分析&＃xff0c;用于可能用于获取数据、心跳交换消息等用途吧。这个后面会详谈微信是如何做到的。

2.0 初始消息传输

个人资料、离线未阅读消息部分等通过 POST HTTP短连接单独获取。

2.1 二进制简单分析

抽取微信某次HTTP协议方式通信数据&＃xff0c;16进制表示&＃xff0c;每两个靠近的数字为一个byte字节&＃xff1a;

微信协议可能如下&＃xff1a;

一个消息包 &＃61; 消息头 &＃43; 消息体

消息头固定16字节长度&＃xff0c;消息包长度定义在消息头前4个字节中。

单纯摘取第0000行为例&＃xff0c;共16个字节的头部:

00 00 00 10 00 10 00 01 00 00 00 06 00 00 00 0f

16进制表示&＃xff0c;每两个紧挨着数字代表一个byte字节。

微信消息包格式&＃xff1a; 1. 前4字节表示数据包长度&＃xff0c;可变值为16时&＃xff0c;意味着一个仅仅包含头部的完整的数据包&＃xff08;可能表示着预先定义好的业务意义&＃xff09;&＃xff0c;后面可能还有会别的消息包 2. 2个字节表示头部长度&＃xff0c;固定值&＃xff0c;0x10 &＃61; 16 3. 2个字节表示谢意版本&＃xff0c;固定值&＃xff0c;0x01 &＃61; 1 4. 4个字节操作说明数字&＃xff0c;可变 5. 序列号&＃xff0c;可变 6. 头部后面紧跟着消息体&＃xff0c;非明文&＃xff0c;加密形式 7. 一个消息包&＃xff0c;最小16 byte字节

通过上图&＃xff08;以及其它数据多次采样&＃xff09;分析&＃xff1a;

0000 - 0040为单独的数据包
0050行为下一个数据包的头部&＃xff0c;前四个字节值为0xca &＃61; 202&＃xff0c;表示包含了从0050-0110共202个字节数据
一次数据发送&＃xff0c;可能包含若干子数据包
换行符\n&＃xff0c;16进制表示为0x0a&＃xff0c;在00f0行&＃xff0c;包含了两个换行符号
一个数据体换行符号用于更细粒度的业务数据分割是否蒙对&＃xff0c;需要问问做微信协议的同学
所有被标记为HTTP协议通信所发送数据都包含换行符号

2.2 动手试试猜想&＃xff0c;模拟微信TCP长连接

开始很不解为什么会出现如此怪异的HTTP双通道长连接请求&＃xff0c;难道基于TCP通信&＃xff0c;然后做了一些手脚&＃xff1f;很常规的TCP长连接&＃xff0c;传输数据时(不是所有数据传输)&＃xff0c;被wireshark误认为HTTP长连接。这个需要做一个实验证实一下自己想法&＃xff0c;设想如下&＃xff1a;

写一个Ping-Pong客户端、服务器端程序&＃xff0c;然后使用Wireshark看一下结果&＃xff0c;是否符合判断。

Java版本的请求端&＃xff0c;默认请求8080端口&＃xff1a;

/*** Ping Client* &＃64;author nieyong*/ package com.learn;import io.netty.bootstrap.Bootstrap; import io.netty.buffer.ByteBuf; import io.netty.buffer.PooledByteBufAllocator; import io.netty.channel.ChannelFuture; import io.netty.channel.ChannelHandlerContext; import io.netty.channel.ChannelInboundHandlerAdapter; import io.netty.channel.ChannelInitializer; import io.netty.channel.ChannelOption; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.SocketChannel; import io.netty.channel.socket.nio.NioSocketChannel;import java.util.concurrent.TimeUnit;class PingClientHandler extends ChannelInboundHandlerAdapter { private final ByteBuf firstMessage;public PingClientHandler() { firstMessage &＃61; PooledByteBufAllocator.DEFAULT.buffer(22);// weixin 16 byte&＃39;s header firstMessage.writeByte(0); firstMessage.writeByte(0); firstMessage.writeByte(0); firstMessage.writeByte(16);firstMessage.writeByte(0); firstMessage.writeByte(16);firstMessage.writeByte(0); firstMessage.writeByte(1);firstMessage.writeByte(0); firstMessage.writeByte(0); firstMessage.writeByte(0); firstMessage.writeByte(6);firstMessage.writeByte(0); firstMessage.writeByte(0); firstMessage.writeByte(0); firstMessage.writeByte(1);// just for /n firstMessage.writeByte(&＃39;\n&＃39;); // 1 byte// footer 16 byte String welcome &＃61; "hello"; // 5 byte firstMessage.writeBytes(welcome.getBytes()); }&＃64;Override public void channelActive(ChannelHandlerContext ctx) { ctx.writeAndFlush(firstMessage); }&＃64;Override public void channelRead(final ChannelHandlerContext ctx, final Object msg) throws Exception { ctx.executor().schedule(new Runnable() { &＃64;Override public void run() { ctx.channel().writeAndFlush(msg); } }, 1, TimeUnit.SECONDS); }&＃64;Override public void channelReadComplete(ChannelHandlerContext ctx) throws Exception { ctx.flush(); }&＃64;Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { System.err.println("Unexpected exception from downstream :" &＃43; cause.getMessage()); ctx.close(); } }public class PingClient {private final String host; private final int port;public PingClient(String host, int port) { this.host &＃61; host; this.port &＃61; port; }public void run() throws Exception { EventLoopGroup group &＃61; new NioEventLoopGroup(); try { Bootstrap b &＃61; new Bootstrap(); b.group(group).channel(NioSocketChannel.class) .option(ChannelOption.TCP_NODELAY, true) .handler(new ChannelInitializer() { &＃64;Override public void initChannel(SocketChannel ch) throws Exception { ch.pipeline().addLast(new PingClientHandler()); } });ChannelFuture f &＃61; b.connect(host, port).sync();f.channel().closeFuture().sync(); } finally { // Shut down the event loop to terminate all threads. group.shutdownGracefully(); } }public static void main(String[] args) throws Exception { String host &＃61; "127.0.0.1"; int port &＃61; 8080;if (args.length &＃61;&＃61; 3) { host &＃61; args[0]; port &＃61; Integer.parseInt(args[1]); }new PingClient(host, port).run(); } }

C语言版本的服务器程序&＃xff0c;收到什么发送什么&＃xff0c;没有任何逻辑&＃xff0c;默认绑定8080端口&＃xff1a;

/*** nieyong&＃64;youku.com* how to compile it:* gcc pong_server.c -o pong_server /usr/local/lib/libev.a -lm */ #include #include #include #include #include #include #include #include #include "../include/ev.h"static int server_port &＃61; 8080;struct ev_loop *loop; typedef struct { int fd; ev_io ev_read; } client_t;ev_io ev_accept;static void free_res(struct ev_loop *loop, ev_io *ws);int setnonblock(int fd) { int flags &＃61; fcntl(fd, F_GETFL); if (flags <0) return flags;flags |&＃61; O_NONBLOCK; if (fcntl(fd, F_SETFL, flags) <0) return -1;return 0; }static void read_cb(struct ev_loop *loop, ev_io *w, int revents) { client_t *client &＃61; w->data; int r &＃61; 0; char rbuff[1024]; if (revents & EV_READ) { r &＃61; read(client->fd, &rbuff, 1024); }if (EV_ERROR & revents) { fprintf(stderr, "error event in read\n"); free_res(loop, w); return ; }if (r <0) { fprintf(stderr, "read error\n"); ev_io_stop(EV_A_ w); free_res(loop, w); return; }if (r &＃61;&＃61; 0) { fprintf(stderr, "client disconnected.\n"); ev_io_stop(EV_A_ w); free_res(loop, w); return; }send(client->fd, rbuff, r, 0); }static void accept_cb(struct ev_loop *loop, ev_io *w, int revents) { struct sockaddr_in client_addr; socklen_t client_len &＃61; sizeof(client_addr); int client_fd &＃61; accept(w->fd, (struct sockaddr *) &client_addr, &client_len); if (client_fd &＃61;&＃61; -1) { fprintf(stderr, "the client_fd is NULL !\n"); return; }client_t *client &＃61; malloc(sizeof(client_t)); client->fd &＃61; client_fd; if (setnonblock(client->fd) <0) err(1, "failed to set client socket to non-blocking");client->ev_read.data &＃61; client;ev_io_init(&client->ev_read, read_cb, client->fd, EV_READ); ev_io_start(loop, &client->ev_read); }int main(int argc, char const *argv[]) { int ch; while ((ch &＃61; getopt(argc, argv, "p:")) !&＃61; -1) { switch (ch) { case &＃39;p&＃39;: server_port &＃61; atoi(optarg); break; } }loop &＃61; ev_default_loop(0); struct sockaddr_in listen_addr; int reuseaddr_on &＃61; 1; int listen_fd &＃61; socket(AF_INET, SOCK_STREAM, 0); if (listen_fd <0) err(1, "listen failed"); if (setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuseaddr_on, sizeof(reuseaddr_on)) &＃61;&＃61; -1) err(1, "setsockopt failed");memset(&listen_addr, 0, sizeof(listen_addr)); listen_addr.sin_family &＃61; AF_INET; listen_addr.sin_addr.s_addr &＃61; INADDR_ANY; listen_addr.sin_port &＃61; htons(server_port);if (bind(listen_fd, (struct sockaddr *) &listen_addr, sizeof(listen_addr)) <0) err(1, "bind failed"); if (listen(listen_fd, 5) <0) err(1, "listen failed"); if (setnonblock(listen_fd) <0) err(1, "failed to set server socket to non-blocking");ev_io_init(&ev_accept, accept_cb, listen_fd, EV_READ); ev_io_start(loop, &ev_accept); ev_loop(loop, 0);return 0; }static void free_res(struct ev_loop *loop, ev_io *w) { client_t *client &＃61; w->data; if (client &＃61;&＃61; NULL) { fprintf(stderr, "the client is NULL !!!!!!"); return; }ev_io_stop(loop, &client->ev_read); close(client->fd); free(client); }

这里有一个现场图&＃xff1a;

可以尝试稍微改变输出内容&＃xff0c;去除换行符“\n”&＃xff0c;把端口换成9000&＃xff0c;试试看&＃xff0c;就会发现Wireshark输出不同的结果来。

2.3 结论是什么呢&＃xff1f;

若使用原始TCP进行双向通信&＃xff0c;则需要满足以下条件&＃xff0c;可以被类似于Wireshark协议拦截器误认为是HTTP长连接&＃xff1a;

使用80/8080端口&＃xff08;81/3128/8000经测试无效&＃xff09; 也许8080一般被作为WEB代理服务端口&＃xff0c;微信才会享用这个红利吧。
输出的内容中&＃xff0c;一定要包含换行字符"\n"

因此&＃xff0c;可以定性为微信使用了基于8080端口TCP长连接&＃xff0c;一旦数据包中含有换行"\n"符号&＃xff0c;就会被Wireshark误认为HTTP协议。可能微信是无心为之吧。

3. 新消息获取方式

TCP长连接接收到服务器通知有新消息需要获取
APP发起一个HTTP POST请求获取新状态消息&＃xff0c;会带上当前SyncKey 地址为&＃xff1a;http://short.weixin.qq.com/cgi-bin/micromsg-bin/reportstrategy HTTP/1.1&＃xff0c;看不到明文
APP获取到新的消息&＃xff0c;会再次发起一次HTTP POST请求&＃xff0c;告诉服务器已确认收到&＃xff0c;同时获取最新SyncKey 地址为&＃xff1a;http://short.weixin.qq.com/cgi-bin/micromsg-bin/kvreport&＃xff0c;看不到明文
接受一个消息&＃xff0c;TCP长连接至少交互两次&＃xff0c;客户端发起两次HTTP POST请求
具体每次交互内容是什么&＃xff0c;有些模糊
服务器需要支持&＃xff1a;状态消息获取标记&＃xff0c;状态消息确认收取标记。只有被确认收到&＃xff0c;此状态消息才算是被正确消费掉
多个不同设备同一账号同时使用微信&＃xff0c;同一个状态消息会会被同时分发到多个设备上

此时消息请求截图如下&＃xff1a;

4. 发送消息方式

发送消息走已经建立的TCP长连接通道&＃xff0c;发送消息到服务器&＃xff0c;然后接受确认信息等&＃xff0c;产生一次交互。

小伙伴接收到信息阅读也都会收到服务器端通知&＃xff0c;产生一次交互等。

可以确定&＃xff0c;微信发送消息走TCP长连接方式&＃xff0c;因为不对自身状态数据产生影响&＃xff0c;应该不交换SyncKey。

在低速网络下&＃xff0c;大概会看到消息发送中的提示&＃xff0c;属于消息重发机制
网络不好有时客户端会出现发送失败的红色感叹号
已发送到服务器但未收到确认的消息&＃xff0c;客户端显示红色感叹号&＃xff0c;再次重发&＃xff0c;服务器作为重复消息处理&＃xff0c;反馈确认
上传图片&＃xff0c;会根据图片大小&＃xff0c;分割成若干部分&＃xff08;大概1.5K被划分为一部分&＃xff09;&＃xff0c;同一时间点&＃xff0c;客户端会发起若干次POST请求&＃xff0c;各自上传成功之后&＃xff0c;服务器大概会合并成一个完整图片&＃xff0c;返回一个缩略图&＃xff0c;显示在APP聊天窗口内。APP作为常规的文字消息发送到服务器端
上传音频&＃xff0c;则单独走TCP通道&＃xff0c;一个两秒的录制音频&＃xff0c;客户端录制完毕&＃xff0c;分为两块传输&＃xff0c;一块最大1.5K左右&＃xff0c;服务端响应一条数据通知确认收到。共三次数据传输。
音频和纯文字信息一致&＃xff0c;都是走TCP长连接&＃xff0c;客户端发送&＃xff0c;服务器端确认。

四。微信协议小结

发布的消息对应一个ID&＃xff08;只要单个方向唯一即可&＃xff0c;服务器端可能会根ID判断重复接收&＃xff09;&＃xff0c;消息重传机制确保有限次的重试&＃xff0c;重试失败给予用户提示&＃xff0c;发送成功会反馈确认&＃xff0c;客户端只有收到确认信息才知道发送成功。发送消息可能不会产生新SyncKey。
基于版本号&＃xff08;SynKey&＃xff09;的状态消息同步机制&＃xff0c;增量、有序传输需求水到渠成。长连接通知/短连接获取、确认等&＃xff0c;交互方式简单&＃xff0c;确保了消息可靠谱、准确无误到达。
客户端/服务器端都会存储消息ID处理记录&＃xff0c;避免被重复消费客户端获取最新消息&＃xff0c;但未确认&＃xff0c;服务器端不会认为该消息被消费掉。下次客户端会重新获取&＃xff0c;会查询当前消息是否被处理过。根据一些现象猜测。
总体上看&＃xff0c;微信协议跨平台&＃xff08;TCP或HTPP都可呈现&＃xff0c;处理方式可统一&＃xff09;&＃xff0c;通过“握手”同步&＃xff0c;很可靠&＃xff0c;无论哪一个平台都可以支持的很好
微信协议最小成本为16字节&＃xff0c;大部分时间若干个消息包和在一起&＃xff0c;批量传输。微信协议说不上最简洁&＃xff0c;也不是最节省流量&＃xff0c;但是非常成功的。
若服务器检测到一些不确定因素&＃xff0c;可能会导致微启用安全套接层SSL协议进行常规的TCP长连接传输。短连接都没有发生变化

以上&＃xff0c;根据有限资料和数据拦截观察总结得出&＃xff0c;啰啰嗦嗦&＃xff0c;勉强凑成一篇&＃xff0c;会存在一些不正确之处&＃xff0c;欢迎给予纠正。在多次

五。附录

Microsoft Exchange Active Sync协议&＃xff0c;简称EAS&＃xff0c;分为folderrsync(同步文件夹目录&＃xff0c;即邮箱内有哪几个文件夹)和sync&＃xff08;每个文件夹内有哪些文档&＃xff09;两部分。

某网友总结的协议一次回话大致示范&＃xff1a;

Client: synckey&＃61;0 //第一次key为0 Server: newsynckey&＃61;1235434 //第一次返回新key Client: synckey&＃61;1235434 //使用新key查询 Server: newsynckey&＃61;1647645,data&＃61;*****//第一次查询&＃xff0c;得到新key和数据 Client: synckey&＃61;1647645 Server: newsynckey&＃61;5637535,data&＃61;null //第二次查询&＃xff0c;无新消息 Client: synckey&＃61;5637535 Server: newsynckey&＃61;8654542, data&＃61;****//第三次查询&＃xff0c;增量同步

上页中的相邻请求都是隔固定时间的&＃xff0c;如两分钟
客户端每次使用旧key标记自己的状态&＃xff0c;服务端每次将新key和增量数据一起返回。
key是递增的&＃xff0c;但不要求连续
请求的某个参数决定服务器是否立即返回

网页版&＃xff1a;请求sync

Remote Address:101.227.131.107:443 Request URL:https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?skey&＃61;%40crypt_9d8701a_f204b64656015a7f443f93f205cf300f&callback&＃61;jQuery18305112716106232256_1408758017484&r&＃61;1408759718398&sid&＃61;wX205zFq194BSWgk&uin&＃61;1543895480&deviceid&＃61;e332282535847305&synckey&＃61;1_622457458%7C2_622458321%7C3_622458304%7C11_622457803%7C201_1408759529%7C1000_1408755736&_&＃61;1408759718399 Request Method:GET Status Code:200 OK Request Headersview source Accept:*/* Accept-Encoding:gzip,deflate,sdch Accept-Language:zh-CN,zh;q&＃61;0.8,en;q&＃61;0.6 Connection:keep-alive COOKIE:ptui_loginuin&＃61;24310247; lv_irt_id&＃61;5834d0f4739e45237a0babe53bb25d48; pt2gguin&＃61;o0024310247; uin&＃61;o0024310247; skey&＃61;&＃64;nNtzDnsWb; ptisp&＃61;ctc; RK&＃61;pI8K3SSgaz; ptcz&＃61;7e77bcbdd43d84b42d1aecace2c70ea7918b90f679fae6c4320dc3610f44494b; pgv_info&＃61;ssid&＃61;s7626563765; pgv_pvid&＃61;1130740238; o_COOKIE&＃61;24310247; pgv_pvi&＃61;6056579072; pgv_si&＃61;s1338950656; wxstaytime&＃61;1408757408 Host:webpush.weixin.qq.com Referer:https://wx.qq.com/ User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 Query String Parametersview sourceview URL encoded skey:&＃64;crypt_9d8701a_f204b64656015a7f443f93f205cf300f callback:jQuery18305112716106232256_1408758017484 r:1408759718398 sid:wX205zFq194BSWgk uin:1543895480 deviceid:e332282535847305 synckey:1_622457458|2_622458321|3_622458304|11_622457803|201_1408759529|1000_1408755736 _:1408759718399 Response Headersview source Access-Control-Allow-Origin:* Content-Length:43 Content-Type:text/Javascript