聲明：微信客戶端協議是二進制協議而且加密，難以分析協議具體編碼格式，我不做逆向工程。只是簡單抓包分析業務的實現流程，在這里記錄下來用於參考學習，並不是破解協議。
語音片斷
語音片斷的發送、接收都是通過長連接分包進行:
發送：語音錄制過程中，客戶端每2秒發一次，每次2.5K左右
接收：服務器將語音分片文件整體當成一條消息，和文本消息一樣的方式推送
總結，語音分片發送和文本相差不大，只是語音因為體積較大，錄制過程中會同時上傳操作，加快發送速度，取消時，刪除已上傳部分即可。
圖片、視頻片斷、小視頻
都是文件類型，相同處理方式：
發送：https短連接，不走長連接，所有發送完后SyncKey 會通過長連接回推
接收：通過長連接接收圖片的縮略圖、視頻截圖 +下載地址，用戶點擊圖片時，走https下載原圖、視頻文件
實時對講
長連接用於對講會話的建立和維護信令傳輸，語言通過UDP中轉。
測試的兩個客戶端都在同一個路由器下面，但數據流量都是通過140.206.160.179 上海聯通的服務器做中轉，也就是沒有做p2p直傳。
對講機同時只有一個人說話，多人同時說話需要做混音、降噪、回聲消除等，對講機的音質應該會更可控吧
二人音視頻
會話建立過程應該和SIP 差不多，通過長連接發起會話邀請-回鈴-接聽-數據傳輸
不同的是，二人音視頻會走p2p，而且在發起邀請后就開始打洞，並且在對方接聽前，也會不斷的傳輸udp包，應該是探測p2p路徑的可靠性和速率。
udp的路徑選擇：
- 對於微信，音視頻通話服務器帶寬成本會特別高，p2p能節省巨大成本
- p2p一般都要比服務器中轉要好，但 p2p 建立較為耗時，所以在邀請階段就開始p2p打洞
- p2p速率也並不一定要比服務器中轉好，最好在通話過程中，也能動態切換使用的鏈路