前言
微信可調研點很多，這里僅僅從協議角度進行調研，會涉及到微信協議交換、消息收發等。所謂“弱水三千，只取一瓢”吧。
雜七雜八的，有些長，可直接拉到最后看結論好了。
一。微信協議概覽
微信傳輸協議，官方公布甚少，在微信技術總監所透漏PPT《微信之道—至簡》文檔中，有所體現。
純個人理解：
因張小龍做郵箱Foxmail起家，繼而又做了QQ Mail等，QQ Mail是國內第一個支持Exchange ActiveSync協議的免費郵箱，基于其從業背景，微信從一開始就采取基于ActiveSync的修改版狀態同步協議Sync，也就再自然不過了。
一句話：增量式、按序、可靠的狀態同步傳輸的微信協議。
大致交換簡圖如下：
_thumb.png "Image(9)")
如何獲取新數據呢：
- 服務器端通知，客戶端獲取
- 客戶端攜帶最新的SyncKey，發起數據請求
- 服務器端生成最新的SyncKey連同最新數據發送給客戶端
- 基于版本號機制同步協議，可確保數據增量、有序傳輸
- SyncKey，由服務器端序列號生成器生成，一旦有新消息產生，將會產生最新的SyncKey。類似于版本號
服務器端通知有狀態更新，客戶端主動獲取自從上次更新之后有變動的狀態數據，增量式，順序式。
二。微信Web端簡單調試
在線版本微信：
https://webpush.weixin.qq.com/
通過Firefox + Firebug組合調試，也能證實了微信大致通過交換SyncKey方式獲取新數據的論述。
1. 發起GET長連接檢測是否存在新的需要同步的數據
會攜帶上最新SyncKey
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?callback=jQuery18306073923335455973_1393208247730&r=1393209241862&sid=s7c%2FsxpGRSihgZAA&uin=937355&deviceid=e542565508353877&synckey=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請求主動獲取同步的數據
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid=s7c%2FsxpGRSihgZAA&r=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提交，用于提交用戶需要發送的消息
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsendmsg?sid=lQ95vHR52DiaLVqo&r=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
https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid=lQ95vHR52DiaLVqo&r=1393988414756
發送內容：
{"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}
響應的（部分）內容：
"SKey": "8F8C6A03489E85E9FDF727ACB95C93C2CDCE9FB9532FC15B"
-
終止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
三。微信Android簡單分析
Windows桌面端Android虛擬機中運行最新版微信(5.2)，通過tcpdump/Wireshark組合封包分析，以下為分析結果。
0. 初始連接記錄
簡單記錄微信啟動之后請求：
11:20:35 dns查詢
dns.weixin.qq.com
返回一組IP地址
11:20:35 DNS查詢
long.weixin.qq.com
返回一組IP地址，本次通信中，微信使用了最后一個IP作為TCP長連接的連接地址。
11:20:35
http://dns.weixin.qq.com/cgi-bin/micromsg-bin/newgetdns?uin=0&clientversion=620888113&scene=0&net=1
用于請求服務器獲得最優IP路徑。服務器通過結算返回一個xml定義了域名:IP對應列表。仔細閱讀，可看到微信已經開始了國際化的步伐：香港、加拿大、韓國等。
具體文本，請參考：https://gist.github.com/yongboy/9341884
11:20:35
獲取到long.weixin.qq.com最優IP，然后建立到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”的附件，估計是未閱讀的離線消息
11:21:31
POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/whatsnews HTTP/1.1 (application/octet-stream)
大概是資訊、訂閱更新等
中間進行一些資源請求等，類似于
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=34&deviceid=A952001f7a840c2a&clientversion=620888113&platform=0&lang=zh_CN&installtype=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分析有誤（得出18分鐘結論），再次重新分析，心跳頻率在5分鐘左右。
2. 登陸之后，會建立一個長連接，端口號為8080
簡單目測為HTTP，初始以為是雙通道HTTP，難道是自定義的用于雙通道通信的HTTP協議嗎，網絡上可見資料都是模棱兩可、語焉不詳。
具體查看長連接初始數據通信，沒有發現任何包含"HTTP"字樣的數據，以為是微信自定義的TCP/HTTP通信格式。據分析，用于可能用于獲取數據、心跳交換消息等用途吧。這個后面會詳談微信是如何做到的。
2.0 初始消息傳輸
個人資料、離線未閱讀消息部分等通過 POST HTTP短連接單獨獲取。
2.1 二進制簡單分析
抽取微信某次HTTP協議方式通信數據，16進制表示，每兩個靠近的數字為一個byte字節：
微信協議可能如下：
一個消息包 = 消息頭 + 消息體
消息頭固定16字節長度，消息包長度定義在消息頭前4個字節中。
單純摘取第0000行為例，共16個字節的頭部:
00 00 00 10 00 10 00 01 00 00 00 06 00 00 00 0f
16進制表示，每兩個緊挨著數字代表一個byte字節。
微信消息包格式： 1. 前4字節表示數據包長度，可變 值為16時，意味著一個僅僅包含頭部的完整的數據包（可能表示著預先定義好的業務意義），后面可能還有會別的消息包 2. 2個字節表示頭部長度，固定值，0x10 = 16 3. 2個字節表示謝意版本，固定值，0x01 = 1 4. 4個字節操作說明數字，可變 5. 序列號，可變 6. 頭部后面緊跟著消息體，非明文，加密形式 7. 一個消息包，最小16 byte字節
通過上圖（以及其它數據多次采樣）分析：
- 0000 - 0040為單獨的數據包
- 0050行為下一個數據包的頭部，前四個字節值為0xca = 202，表示包含了從0050-0110共202個字節數據
- 一次數據發送，可能包含若干子數據包
- 換行符\n，16進制表示為0x0a，在00f0行，包含了兩個換行符號
- 一個數據體換行符號用于更細粒度的業務數據分割 是否蒙對，需要問問做微信協議的同學
- 所有被標記為HTTP協議通信所發送數據都包含換行符號
2.2 動手試試猜想，模擬微信TCP長連接
開始很不解為什么會出現如此怪異的HTTP雙通道長連接請求，難道基于TCP通信，然后做了一些手腳？很常規的TCP長連接，傳輸數據時(不是所有數據傳輸)，被wireshark誤認為HTTP長連接。這個需要做一個實驗證實一下自己想法，設想如下：
寫一個Ping-Pong客戶端、服務器端程序，然后使用Wireshark看一下結果，是否符合判斷。
Java版本的請求端，默認請求8080端口：
C語言版本的服務器程序，收到什么發送什么，沒有任何邏輯，默認綁定8080端口：
這里有一個現場圖：
可以嘗試稍微改變輸出內容，去除換行符“\n”，把端口換成9000，試試看，就會發現Wireshark輸出不同的結果來。
2.3 結論是什么呢？
若使用原始TCP進行雙向通信，則需要滿足以下條件，可以被類似于Wireshark協議攔截器誤認為是HTTP長連接：
- 使用80/8080端口（81/3128/8000經測試無效） 也許8080一般被作為WEB代理服務端口，微信才會享用這個紅利吧。
- 輸出的內容中，一定要包含換行字符"\n"
因此，可以定性為微信使用了基于8080端口TCP長連接，一旦數據包中含有換行"\n"符號，就會被Wireshark誤認為HTTP協議。可能微信是無心為之吧。
3. 新消息獲取方式
- TCP長連接接收到服務器通知有新消息需要獲取
- APP發起一個HTTP POST請求獲取新狀態消息，會帶上當前SyncKey 地址為：http://short.weixin.qq.com/cgi-bin/micromsg-bin/reportstrategy HTTP/1.1，看不到明文
- APP獲取到新的消息，會再次發起一次HTTP POST請求，告訴服務器已確認收到，同時獲取最新SyncKey 地址為：http://short.weixin.qq.com/cgi-bin/micromsg-bin/kvreport，看不到明文
- 接受一個消息，TCP長連接至少交互兩次，客戶端發起兩次HTTP POST請求
具體每次交互內容是什么，有些模糊
- 服務器需要支持：狀態消息獲取標記，狀態消息確認收取標記。只有被確認收到，此狀態消息才算是被正確消費掉
- 多個不同設備同一賬號同時使用微信，同一個狀態消息會會被同時分發到多個設備上
此時消息請求截圖如下：
4. 發送消息方式
發送消息走已經建立的TCP長連接通道，發送消息到服務器，然后接受確認信息等，產生一次交互。
小伙伴接收到信息閱讀也都會收到服務器端通知，產生一次交互等。
可以確定，微信發送消息走TCP長連接方式，因為不對自身狀態數據產生影響，應該不交換SyncKey。
- 在低速網絡下，大概會看到消息發送中的提示，屬于消息重發機制
- 網絡不好有時客戶端會出現發送失敗的紅色感嘆號
- 已發送到服務器但未收到確認的消息，客戶端顯示紅色感嘆號，再次重發，服務器作為重復消息處理，反饋確認
- 上傳圖片，會根據圖片大小，分割成若干部分（大概1.5K被劃分為一部分），同一時間點，客戶端會發起若干次POST請求，各自上傳成功之后，服務器大概會合并成一個完整圖片，返回一個縮略圖，顯示在APP聊天窗口內。APP作為常規的文字消息發送到服務器端
- 上傳音頻，則單獨走TCP通道，一個兩秒的錄制音頻，客戶端錄制完畢，分為兩塊傳輸，一塊最大1.5K左右，服務端響應一條數據通知確認收到。共三次數據傳輸。
音頻和純文字信息一致，都是走TCP長連接，客戶端發送，服務器端確認。
四。微信協議小結
- 發布的消息對應一個ID（只要單個方向唯一即可，服務器端可能會根ID判斷重復接收），消息重傳機制確保有限次的重試，重試失敗給予用戶提示，發送成功會反饋確認，客戶端只有收到確認信息才知道發送成功。發送消息可能不會產生新SyncKey。
- 基于版本號（SynKey）的狀態消息同步機制，增量、有序傳輸需求水到渠成。長連接通知/短連接獲取、確認等，交互方式簡單，確保了消息可靠譜、準確無誤到達。
- 客戶端/服務器端都會存儲消息ID處理記錄，避免被重復消費客戶端獲取最新消息，但未確認，服務器端不會認為該消息被消費掉。下次客戶端會重新獲取，會查詢當前消息是否被處理過。根據一些現象猜測。
- 總體上看，微信協議跨平臺（TCP或HTPP都可呈現，處理方式可統一），通過“握手”同步，很可靠，無論哪一個平臺都可以支持的很好
- 微信協議最小成本為16字節，大部分時間若干個消息包和在一起，批量傳輸。微信協議說不上最簡潔，也不是最節省流量，但是非常成功的。
若服務器檢測到一些不確定因素，可能會導致微啟用安全套接層SSL協議進行常規的TCP長連接傳輸。短連接都沒有發生變化
以上，根據有限資料和數據攔截觀察總結得出，啰啰嗦嗦，勉強湊成一篇，會存在一些不正確之處，歡迎給予糾正。在多次
五。附錄
Microsoft Exchange Active Sync協議，簡稱EAS，分為folderrsync(同步文件夾目錄，即郵箱內有哪幾個文件夾)和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是遞增的，但不要求連續
- 請求的某個參數決定服務器是否立即返回