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