[微信协议分析] 多媒体
声明：微信客户端协议是二进制协议而且加密，难以分析协议具体编码格式，我不做逆向工程。只是简单抓包分析业务的实现流程，在这里记录下来用于参考学习，并不是破解协议。
语音片断
语音片断的发送、接收都是通过长连接分包进行:
发送：语音录制过程中，客户端每2秒发一次，每次2.5K左右
接收：服务器将语音分片文件整体当成一条消息，和文本消息一样的方式推送
总结，语音分片发送和文本相差不大，只是语音因为体积较大，录制过程中会同时上传操作，加快发送速度，取消时，删除已上传部分即可。
图片、视频片断、小视频
都是文件类型，相同处理方式：
发送：https短连接，不走长连接，所有发送完后SyncKey 会通过长连接回推
接收：通过长连接接收图片的缩略图、视频截图 +下载地址，用户点击图片时，走https下载原图、视频文件
实时对讲
长连接用于对讲会话的建立和维护信令传输，语言通过UDP中转。
测试的两个客户端都在同一个路由器下面，但数据流量都是通过140.206.160.179 上海联通的服务器做中转，也就是没有做p2p直传。
对讲机同时只有一个人说话，多人同时说话需要做混音、降噪、回声消除等，对讲机的音质应该会更可控吧
二人音视频
会话建立过程应该和SIP 差不多，通过长连接发起会话邀请-回铃-接听-数据传输
不同的是，二人音视频会走p2p，而且在发起邀请后就开始打洞，并且在对方接听前，也会不断的传输udp包，应该是探测p2p路径的可靠性和速率。
udp的路径选择：
– 对于微信，音视频通话服务器带宽成本会特别高，p2p能节省巨大成本
– p2p一般都要比服务器中转要好，但 p2p 建立较为耗时，所以在邀请阶段就开始p2p打洞
– p2p速率也并不一定要比服务器中转好，最好在通话过程中，也能动态切换使用的链路
版权声明：本文为lulu原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。