什么是 WebRTC
2010 年 5 月，谷歌收购了 Global IP Solutions（简称 GIPS），这是一家专注于 VoIP 和视频会议软件的公司，已开发出 RTC 所需的多项关键组件，如编解码器和回声消除技术。谷歌随后将 GIPS 技术开源，并与 IETF 和 W3C 等标准机构合作，以确保行业共识。2011 年 5 月，谷歌发布了一个名为 WebRTC 的开源项目，旨在实现基于浏览器的实时通信。 它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。此后，相关协议在 IETF 的标准化工作以及浏览器 API 在 W3C 的标准化工作持续进行。
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持浏览器或移动应用程序（安卓苹果）进行实时点对点的音频、视频和数据通信的开放标准 API。
WebRTC 的独特之处在于，一旦连接建立，数据便可以直接在浏览器之间实时传输，无需经过服务器。通过绕过服务器，减少了延迟，因为数据不必先发送到服务器，这使得 WebRTC 非常适合用于音频和视频的交换。
WebRTC 如今已嵌入所有现代浏览器中，开发者可以利用 WebRTC 的 JavaScript API 为浏览器用户构建应用程序。当然 WebRTC 现在也被很多编程语言所支持，包括但不限于 C、C++、Go、Java、PHP、JavaScript 等等，因此可以实现跨平台的实时通信方案。
WebRTC 的工作流程
WebRTC 的工作流程比 Websocket、HTTP 协议来说相对复杂一些，它用到了很多个协议一起协同工作。
假设有两个对等方，A和B，他们使用WebRTC进行双向媒体流传输（例如，视频聊天应用）。当A想要呼叫B时，具体流程如下：
生成SDP Offer：A的应用程序首先需要生成一个SDP Offer。SDP（Session Description Protocol）Offer包含了A应用程序想要建立的会话信息，例如使用的编解码器类型、这是音频还是视频会话等内容。SDP Offer不包括ICE候选，而仅包含会话描述信息。
收集ICE候选者：在生成SDP Offer后，A的应用程序会开始收集ICE候选者。为了收集候选者，A的应用程序会向STUN服务器发送请求。STUN服务器返回A的公共IP地址和端口，A的应用程序将这些信息作为候选者添加到ICE候选者列表中。A的应用程序也会收集本地网络的候选信息（如本地IP/端口对）。这些候选者是为了后续的连接性检查。
通过信令通道传递SDP Offer：A生成了SDP Offer和相应的ICE候选者列表后，会通过一个信令通道（如HTTPS、WebSocket等）将SDP Offer传递给B的应用程序。需要注意的是，ICE候选者可以在这一步通过信令通道单独传递，通常是在SDP Offer之后或者与Offer一起传输。
生成SDP Answer：B的应用程序接收到SDP Offer后，进行以下处理：
B的应用程序会生成一个SDP Answer，作为对SDP Offer的回应。
同时，B的应用程序会收集自己的ICE候选者。类似于A的做法，B会向STUN服务器发出请求并收集公共IP地址/端口，形成自己的候选者列表。
通过信令通道传递SDP Answer和ICE候选者：B的应用程序将SDP Answer和自己的ICE候选者列表通过信令通道传递给A的应用程序。
连接性检查和媒体传输：在双方互相交换SDP Offer和Answer后，每个应用程序会开始连接性检查。双方应用程序的ICE协议会使用对方提供的候选IP/端口对，发送STUN请求进行连接性验证。如果请求得到了响应，相关的候选者会被认为是有效的，并标记为可用。
选择最终的IP/端口对：经过一系列的连接性检查后，A和B将协商并选择一个有效的IP/端口对，用于实际的媒体流传输。
使用TURN服务器（如有必要）：如果任何一方的应用程序无法找到一个有效的IP/端口对，则会向TURN服务器发送请求，以获取一个公共的中继地址。TURN服务器返回的中继地址将会用于建立连接，并通过信令通道进行交换。
下方是一个直观的通信过程：
整个 WebRTC 通信过程中会用到如下的服务器：
信令（Signaling）服务器：用于交换信令信息，WebRTC 没有规定交换信令的方式，一般可用的交换方式是 HTTP、Websocket、MQTT 等等。
STUN 服务器：帮助客户端发现它们的公共IP地址和NAT类型，并为点对点连接提供网络信息。
TURN 服务器（可选）：在STUN无法穿透NAT或防火墙时，作为中继服务器转发数据流。TURN服务器提供了一种备用机制，确保即使在极为复杂的网络环境下，WebRTC的点对点连接也能够顺利进行。