一、实时音视频的架构

实时音视频通信架构主要包括P2P、SFU、MCU三种方式，其中点对点通信通常以P2P优先，P2P走不通的场景再借助于SFU/MCU。

        P2P方式，终端之间点对点的相互收发数据流，音视频流不经过服务器；

        SFU是端侧上传自己的音视频，但是接收多份其他端的用户流，服务器只做选择性转发；

        MCU方式的话，端侧收发各一路流（包含音视频），服务器做合流转发。

对于P2P方式，是最节省服务器带宽成本的，但无法对流进行监控、审核及其他高级处理。

二、P2P的实现难点

        对于点对点音视频通话，点对点监控，P2P可以节省大量的成本，那实现它的技术难点是什么呢？有经验的小伙伴应该猜出来了，对NAT设备穿透（打洞），打洞的成功率和路由器NAT设备的类型有很大关系，通常NAT类型有：全锥NAT、地址受限NAT、端口受限NAT、对称NAT，他们的安全级别依次提升，打洞难度也逐步提高，对于对称NAT则很难打通。好在目前只有企业级路由器会是对称NAT类型的，家用的大多还是比较容易打通的。

三、微信音视频流转测试

        微信作为国民级第一应用，有着巨大数据量，那它会不会出于节省成本的考虑采用P2P方式呢？接下来我们做个简单的测试，

首先，咱们准备一台电脑、一个手机、一台wifi路由器（小米牌），测试分两种场景，分别看下其数据包的流向：

场景一，手机、电脑同时接入到wifi下，通过wireshark抓包，会话统计如下：

 按统计packet进行排序，可以初步确认为服务器（8080端口）和手机（192.168.31.202:34945可以通过手机查看IP地址）

为进一步确认地址，可以在视频通话过程中进行摄像头的关闭或遮挡、音频的关闭开启并记录时间，然后跟IO统计对比

通过上述IO统计可以基本确认地址无误，并可以依次对应的具体的音视频流。

可以看出手机到PC的视频走转发，音频走P2P；PC对手机的视频走P2P，音频走转发。

场景二，手机关闭wifi开启4G、电脑接入wifi，通过wireshark抓包，会话统计如下：

 可以看出手机到PC的视频走转发，音频走P2P；PC对手机的视频走P2P，音频走转发。和手机在wifi场景一一样。

四、结论

      经过家庭网络环境的多次测试，结果均相同，及单端上行音视频必然有一路走转发一路走P2P，有兴趣的朋友也可以多测试下，如果都是这样的话，只能解释马总财大气粗亦或是为了对咱们言行进行净化（不要骂人^_^）  

抓包文件我打包上传至资源池，感兴趣的可以借鉴