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