WebRTC实战
我们都知道浏览器本身不支持相互之间建立信道进行通信，都需要通过服务器进行中转。比如现在有两个客户端—甲、乙，他俩想要进行通信，首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时，甲先将消息发送到服务器上，服务器对甲的消息进行中转，发送到乙处，反过来也是一样。这样甲与乙之间的一次消息要通过两段信道，通信的效率同时受制于这两段信道的带宽。同时这样的信道并不适合数据流的传输，如何建立浏览器之间的点对点传输，一直困扰着开发者。因此WebRTC应运而生。
WebRTC旨在允许JavaScript应用程序创建包含音频和视频流以及用于任意数据的数据通道的实时连接；创建这些连接以直接链接两个用户的浏览器，而不必要求任何支持WebRTC协议的中间服务器。并且WebRTC通过实现MediaStream，通过浏览器调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频。同时WebRTC是一个非常优秀的多媒体框架，且支持跨平台（支持Android、IOS），能够使得Android和IOS设备作为终端设备能够像浏览器一样，进行即时通信。
WebRTC vs WebSockets
WebRTC与WebSockets有一个显著的区别：Websockets通过TCP工作，WebRTC通过UDP工作。事实上，WebRTC是SRTP协议，具有一些附加功能，如STUN、ICE、DTLS等和内部VoIP功能，如自适应抖动缓冲、AEC、AGC等。因此，Websocket是为可靠的通信而设计的，如果您想发送任何必须可靠发送的数据，它是一个不错的选择。当您使用WebRTC时，传输的数据流是不可靠的。一些数据包可能会在网络中丢失。如果你发送关键数据，例如金融处理，这是很糟糕的，同样的问题是理想的，当你发送音频或视频流，一些帧可能会丢失，没有任何明显的质量问题。如果你想通过WebRTC发送数据通道，你应该有一些前向纠错算法来恢复数据，如果一个数据帧在网络中丢失。
WebRTC架构
下面是WebRTC的基础架构图：
整体架构分为应用层和核心层。应用层提供实现相关业务逻辑Api，核心层提供应用层需要的核心API。其中核心层分为四层：
- 第一层为C++ API，其中最主要的是PeerConnection，这个接口需要重点学习和掌握。
- 第二层为Session层，为上下文管理层，应用里的音频和视频及非音视频的数据处理逻辑都可以在这层进行。
- 第三层为引擎和传输层，包括音频引擎和视频引擎，以及音视频的传输，这也是整个架构中最重要的一层。
- 第四层与硬件相关，包括音视频的采集和网络的IO。
注意，WebRTC的核心层无视频的渲染，所有的渲染都需要应用层自行实现。并且第三层中主要包含以下模块：
- Voice Engine（音频引擎模块）：包含编码能力、音频缓冲Buff（防网络抖动）、回音消除（实时连麦关键点）。
- Video Engine（视频引擎模块）：包含编码能力（如VP8）、视频缓冲、图像增强。
- Transport（传输模块）：传输协议在底层使用UDP，上层使用的RTP（为安全起见增加SRTP），还有P2P机制，包括STUN、TURN和ICE。
我们知道WebRTC要解决的是两个浏览器之间如何进行实时音视频互动的问题。从底层来看，就是要解决两个点之间如何进行高效的网络传输。这就涉及要很多重要的传输协议，请参阅 《Network-Notes》。
Links
