在低速网络下，大概会看到消息发送中的提示，属于消息重发机制
网络不好有时客户端会出现发送失败的红色感叹号
已发送到服务器但未收到确认的消息，客户端显示红色感叹号，再次重发，服务器作为重复消息处理，反馈确认
上传图片，会根据图片大小，分割成若干部分（大概1.5K被划分为一部分），同一时间点，客户端会发起若干次POST请求，各自上传成功之后，服务器大概会合并成一个完整图片，返回一个缩略图，显示在APP聊天窗口内。APP作为常规的文字消息发送到服务器端上传音频，则单独走TCP通道，一个两秒的录制音频，客户端录制完毕，分为两块传输，一块最大1.5K左右，服务端响应一条数据通知确认收到。共三次数据传输。
音频和纯文字信息一致，都是走TCP长连接，客户端发送，服务器端确认。
微信协议简单调研笔记如下介绍：
前言
微信可调研点很多，这里仅仅从协议角度进行调研，会涉及到微信协议交换、消息收发等。所谓“弱水三千，只取一瓢”吧。
杂七杂八的，有些长，可直接拉到最后看结论好了。
一。微信协议概览
微信传输协议，官方
公布甚少，在微信技术总监所透漏PPT《微信之道—至简》文档中，有所体现。
纯个人理解：
因张小龙做邮箱Foxmail起家，继而又做了QQ Mail等，QQ Mail是国内第一个支持Exchange ActiveSync协议的免费邮箱，基于其从业背景，微信从一开始就采取基于ActiveSync的修改版状态同步协议Sync，也就再自然不过了。
一句话：增量式、按序、可靠的状态同步传输的微信协议。
大致交换简图如下：
如何获取新数据呢：
服务器端通知，客户端获取
客户端携带最新的SyncKey，发起数据请求
服务器端生成最新的SyncKey连同最新数据发送给客户端
基于版本号机制同步协议，可确保数据增量、有序传输
SyncKey，由服务器端序列号生成器生成，一旦有新消息产生，将会产生最新的SyncKey。类似于版本号
服务器端通知有状态更新，客户端主动获取自从上次更新之后有变动的状态数据，增量式，顺序式。
二。微信Web端简单调试
在线版本微信：
https://webpush.weixin.qq.com/
通过Firefox + Firebug组合调试，也能证实了微信大致通过交换SyncKey方式获取新数据的论述。
1. 发起GET长连接检测是否存在新的需要同步的数据
会携带上最新SyncKey
返回内容：
window.synccheck={retcode:"0",selector:"2"}
selector值大于0，表示有新的消息需要同步。
据目测，心跳周期为27秒左右。
2. 一旦有新数据，客户端POST请求主动获取同步的数据
携带消息体：
{"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提交，用于提交用户需要发送的消息
发送内容：
{"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
发送内容：