[微信协议分析] 多媒体

声明:微信客户端协议是二进制协议而且加密,难以分析协议具体编码格式,我不做逆向工程。只是简单抓包分析业务的实现流程,在这里记录下来用于参考学习,并不是破解协议。

 

语音片断

语音片断的发送、接收都是通过长连接分包进行:

发送:语音录制过程中,客户端每2秒发一次,每次2.5K左右

接收:服务器将语音分片文件整体当成一条消息,和文本消息一样的方式推送

总结,语音分片发送和文本相差不大,只是语音因为体积较大,录制过程中会同时上传操作,加快发送速度,取消时,删除已上传部分即可。

 

图片、视频片断、小视频

都是文件类型,相同处理方式:

发送:https短连接,不走长连接,所有发送完后SyncKey 会通过长连接回推

接收:通过长连接接收图片的缩略图、视频截图 +下载地址,用户点击图片时,走https下载原图、视频文件

 

实时对讲

长连接用于对讲会话的建立和维护信令传输,语言通过UDP中转。

测试的两个客户端都在同一个路由器下面,但数据流量都是通过140.206.160.179 上海联通的服务器做中转,也就是没有做p2p直传。

对讲机同时只有一个人说话,多人同时说话需要做混音、降噪、回声消除等,对讲机的音质应该会更可控吧

 

二人音视频 

会话建立过程应该和SIP 差不多,通过长连接发起会话邀请-回铃-接听-数据传输

不同的是,二人音视频会走p2p,而且在发起邀请后就开始打洞,并且在对方接听前,也会不断的传输udp包,应该是探测p2p路径的可靠性和速率。

udp的路径选择:

- 对于微信,音视频通话服务器带宽成本会特别高,p2p能节省巨大成本

- p2p一般都要比服务器中转要好,但 p2p 建立较为耗时,所以在邀请阶段就开始p2p打洞

- p2p速率也并不一定要比服务器中转好,最好在通话过程中,也能动态切换使用的链路

 

posted @ 2015-01-03 19:31  LittlePeng  阅读(5762)  评论(4编辑  收藏  举报