WebRTC（Web Real-Time Communication）是一个用于浏览器和移动应用程序的技术，允许在不使用插件的情况下实现点对点的音视频通信和数据共享。WebRTC 是一个复杂的技术栈，涉及多个概念，如RTCPeerConnection、Stream、Track、Channel、Source、Sink等概念。以下将对WebRTC的架构、关键概念及连接建立流程进行介绍，帮助读者了解什么是WebRTC。
一、WebRTC架构
WebRTC整体架构从上到下一共分为三层：
最上层是WbeAPI层，这一层是暴露给开发人员的用于开发WebRTC应用的JavaScript API中间的那一层是WebRTC技术最为关键核心的一层，一共包括三个模块，分别是音频引擎、视频引擎以及网络传输最下层是由各厂商自主开发的一层，用于实现音视频的采集和网络IO
音频引擎（VoiceEngine） 负责WebRTC的音频通信，通过一套完整的音频处理框架，解决了音频从外接设备如麦克风读入数据然后再通过网络进行传输的音频处理问题。主要分为两个模块：音频编解码和语音信号处理。其核心是回声消除（AcousticEchoCancceler，AEC）和降噪（NoiseReduction，NR）。回声消除是一种改善声音质量，消除产生的回声或防止其发生的方法。降噪是从信号中去除噪声的过程。音频机制主要分为iSAC和iLBC两大类编解码器。iLBC编解码器该窄带音频编解码器适用于IP上的语音通信。
视频引擎（VideoEngine） 负责WebRTC的视频通信，通过一套完整的视频处理框架，解决了视频从外接设备如摄像头采集数据然后再通过网络传输最后显示视频的视频处理问题。主要分为两个模块：视频图像编解码和视频图像处理。视频图像编解码方面，默认的编解码器是VP8，比较适合实时通信场景下的视频编解码。视频图像处理方面，通过两种方式来保证传输的视频图像的高质量、美观性，一方面，利用视频抖动缓冲器来减小由于抖动和丢包带来的影响，另一方面对采集到的图像进行颜色增强、降噪等处理来提升图像清晰度。
网络传输（Transport） 负责音视频数据的传输，通过一套完整的传输框架，解决了音视频数据的加密传输和防火墙穿透问题。一方面，通过SRTP协议保证音视频数据在加密的状态下进行传输，另一方面，通过整合了STUN和TURN的ICE协议来保证音视频数据可以突破防火墙和NAT网络的限制。
二、关键概念
1. RTCPeerConnection（点对点连接）
RTCPeerConnection 用于建立点对点的实时通信连接。它允许在不同浏览器之间传输音频、视频和数据流。我们把发起 WebRTC 通信的两端被称为对等端，即是 Peer。所谓点对点通信（peer-to-peer）则是说两个客户端直连，发送数据不需要中间服务器，建立成功的连接则称为PeerConnection，而一次 WebRTC 通信可包含多个 PeerConnection。
2. ICE（Interactive Connectivity Establishment，交互式连通性建立）
ICE 不是一种协议，整合了 STUN 和 TURN 两种协议的框架，用于 NAT 和防火墙穿越。ICE通过收集并交换候选者（Candidate）信息，包括IP地址、端口号、协议等，并按优先级尝试连接。
3. STUN（Session Traversal Utilities for NAT，会话穿越实用程序）
STUN 协议用于获取设备的公共 IP 地址和端口。它帮助客户端了解自己的公共网络地址，以便在 NAT 环境中能够正确地进行通信。STUN 主要用于发现和共享 IP 地址和端口信息，并不用于数据转发。
4. TURN（Traversal Using Relays around NAT，NAT 中继穿越）
TURN 协议用于当直接连接不可用时，通过中继服务器转发数据。TURN 服务器充当一个中继角色，将数据从一个对等端转发到另一个对等端。TURN 适用于复杂的 NAT 环境，确保即使在所有直接连接方式都不可用时，依然能够传输数据。
5. Stream（流）
一个 MediaStream 对象表示一组相关的音频、视频或者其他媒体轨道的集合。例如，在一个视频通话中，可能存在一个 MediaStream 包含了音频轨道和视频轨道。
6. Track（轨道）
一个 MediaStreamTrack 表示音频、视频或其他类型的轨道，是 MediaStream 中的基本单元。每个 MediaStream 可以包含一个或多个 MediaStreamTrack。音频轨道包含音频源，视频轨道包含视频源。
7. Channel（通道）
在 WebRTC 中，channel 通常指的是 RTP（Real-time Transport Protocol）通道，用于实时传输音视频数据。每个 MediaStreamTrack 可以使用独立的 RTP 通道进行传输。
8. Source（源）
在 WebRTC 中，MediaStreamTrack 对象通常被称为 “track”，而一个 MediaStreamTrack 的数据源就是 “source”。MediaStreamTrack 可以是音频轨道（AudioTrack）或视频轨道（VideoTrack），它们分别表示音频或视频的输入源。
9. Sink（接收端）
在 WebRTC 中，sink 通常是指用于接收媒体流的端点（local/remote音视频渲染）。在 MediaStream 流的消费端，我们可以使用 MediaStreamTrack 对象创建 MediaStreamTrack 的 sink ，用于接收来自源（Source）的媒体流。
三、连接建立流程
发送 SDP Offer:
当一个 WebRTC 对等端（比如 Peer A）想要发起通信时，它会生成一个 SDP Offer，这个 Offer 包含了有关媒体会话的详细信息，如媒体类型、编解码器、网络参数等。Peer A 将这个 SDP Offer 发送到信令服务器，信令服务器再将其转发给另一个对等端（比如 Peer B）。
接收 SDP Offer 并发送 SDP Answer:
Peer B 接收到 SDP Offer 后，会解析其中的内容，并生成一个 SDP Answer，其中包含 Peer B 对会话的响应信息。Peer B 将 SDP Answer 发送回信令服务器，信令服务器将其转发回 Peer A。
ICE Candidate Discovery:
在 SDP Offer 和 SDP Answer 交换之后，每个对等端开始生成 ICE Candidates。ICE Candidates 包括可能的网络路径，用于穿越 NAT 和防火墙。每个对等端会将其 ICE Candidates 通过信令服务器发送给对方。信令服务器将对等端的 ICE Candidates 转发给另一端的对等端。
测试和建立连接:
一旦双方对 ICE Candidates 进行交换，各个对等端会进行连接性检查，测试这些候选者的有效性。根据测试结果，双方选择最佳的候选者对，建立实际的点对点连接。成功建立连接后，媒体流（如音频、视频）可以通过这个连接进行传输。