http://blog.newxd.com/7235.html

有朋友公司需求如下，手机通过WIFI连接上网，而老板要求，员工使用手机只能上微信，而不能上其他网页和看在线视频。上网搜索了微信使用协议和端口。

微信通过TCP方式来进行通讯。

远程通讯端口范围: 80，443，80,443,8080。

在特征分析中，发现微信会采用HTTP协议进行通讯。

连接的主机（Host）（正则表达式）为：^short\.weixin\.qq\.com，^(mmsns|mmbiz)\.qpic\.cn。

在特征分析中，发现微信会采用TLS协议进行通讯。

连接的TLS主机（正则表达式）为：^(wx|weixin|res\.wx)\.qq\.com。

来源：笨驴技术

安桌手机，可以用tcpdump进行抓包。。分析！！

初步分析结果： 使用80、8080，登陆和交互。 使用：tcp 14000  端口  SCOTTY High-Speed Filetransferscotty-ft   发送语音文件

来源：http://bbs.51cto.com/thread-1031608-1.html

微信、手机QQ网络行为简析

智能手机一部（打开wifi关闭gprs） —-> linux wifi 热点 —-> 公网

仅列出跟微信不同之处

来源：http://noops.me/?p=327

方案设想：只开放以上端口，其他上也是全部开放了，在上网出口处加上网行为管理设备或者软件进行控制，只允许以下正则的网址通行：

^short\.weixin\.qq\.com，^(mmsns|mmbiz)\.qpic\.cn

^(wx|weixin|res\.wx)\.qq\.com

以下是软件实现方式

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

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

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

微信可调研点很多，这里仅仅从协议角度进行调研，会涉及到微信协议交换、消息收发等。所谓“弱水三千，只取一瓢”吧。

杂七杂八的，有些长，可直接拉到最后看结论好了。

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

纯个人理解：

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

大致交换简图如下：

如何获取新数据呢：

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

在线版本微信：

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

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

会携带上最新SyncKey

返回内容：

selector值大于0，表示有新的消息需要同步。

据目测，心跳周期为27秒左右。

携带消息体：

会携带上最新的SyncKey，会返回复杂结构体JSON内容。

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

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

发起一个POST提交，用于提交用户需要发送的消息

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

发送内容：

相应内容：

再次发起一个POST请求，用于申请最新SyncKey

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

发送内容：

响应的（部分）内容：

终止GET长连接，使用最新SyncKey再次发起一个新的GET长连接

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

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

简单记录微信启动之后请求：

上次使用Wireshark分析有误（得出18分钟结论），再次重新分析，心跳频率在5分钟左右。

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

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

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

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

微信协议可能如下：

消息头固定16字节长度，消息包长度定义在消息头前4个字节中。

单纯摘取第0000行为例，共16个字节的头部:

16进制表示，每两个紧挨着数字代表一个byte字节。

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

通过上图（以及其它数据多次采样）分析：

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

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

Java版本的请求端，默认请求8080端口：

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

这里有一个现场图：

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

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

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

此时消息请求截图如下：

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

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

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

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

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

某网友总结的协议一次回话大致示范：