想开发一款带有视频通话/共享屏幕功能的产品？那WebRTC是你必须要知道的！

作为一名技术爱好者，我总是对各种协议、各种功能感兴趣，两周前我想为我的开源项目ChatCraft集成视频通话功能，我就开始了对应技术的研究，然后我盯上了WebRTC。在这个研究过程中，我恶补了大量有关WebRTC的知识，并在最后，成功实现了视频通话功能。我想，我这次尝试值得分享。所以就这样……如果你还感兴趣，那就继续看下去吧！

这篇文章是实战的前置文章，在这篇文章中一起来学习WebRTC的相关知识吧！

什么是WebRTC

网页即时通信（Web Real-Time Communication），是一个支持浏览器（不局限于浏览器，例如在App中使用，只需要自己实现音频、视频的采集，传输即可）进行实时语音对话或视频对话的API。简单来说，有了WebRTC我们可以通过一些简单的API就可以给浏览器和App提供实时通信（RTC）的功能。
而在 WebRTC 推出之前，开发实时音视频交互应用的成本高昂且技术挑战多·，包括音视频编解码、数据传输、延迟、丢包、抖动、回声处理…等问题。现在就简单了，例如视频通话时，音频因为环境或其他问题导致的有噪声、回声干扰，如果不做处理，用户体验会很差，而WebRTC提供了 3A 算法 + NetEQ，让实时环境中的声音处理及互动体验得到了大幅的提升。

WebRTC主要用来做什么

WebRTC是不局限于浏览器的，只要使用设备的IP链接可到达，且符合WebRTC规范的就可以互相连接。所以，能应用的领域就非常多。举几个现在常见的例子：

共享桌面
视频/语音聊天
视频会议
云端游戏
P2P网络加速
…

看到这里，相信你已经对WebRTC有了一个最基础的基本概念了，知道它会出现在什么应用场景下，如果你还感兴趣的话，那就让我们揭开它神秘的面纱吧！

在WebRTC中发生了什么？

让我来通过一个场景小故事，告诉你在WebRTC中发生了什么~

故事开头： 从前，在一个数字世界里，有两个神秘的实体，它们分别被命名为A和B。A是一位智慧的编码者，B则是一位梦想的解码者。

过程： A和B都拥有着珍贵的信息，但它们需要一种安全的方式来分享这些信息。于是，A开始寻找通向B的神秘通道。它穿越虚拟的网络山川，寻找能够连接到B的公共路径。A仔细检查自己的数字身份，确保自己可以被其他实体识别。同时，它还检查了自己的数字路由器，确保可以传递信息给B。

与此同时，B也在为这次神秘相遇做准备。它同样寻找通向A的路径，准备好自己的数字身份和路由器。A和B收集了大量信息，包括加密方式、安全参数和视频编解码器，这些信息构成了他们的“SDP”。

结尾： 最终，A和B通过一种数字化的方式传递了会话信息。这个方式可以是通过电子邮件、虚拟信使，甚至是通过传送门。WebRTC并不关心具体的传递方式，只要信息能够从A到B，它们就可以开始他们的数字通信之旅。一旦A和B交换了SDP，它们就像魔法般实现了真正的点对点通信。不再需要第三方干涉，它们可以直接建立连接，分享彼此的智慧和梦想。最终，A和B通过最优的数字路径找到了彼此，这就是WebRTC的神奇之处。

WebSocket和WebRTC的区别是什么？

熟悉WebSocket的朋友到这里就会发现了，好像他们都是转发消息。如果你也这么想，那恭喜你，你已经熟悉了WebRTC的一小点部分。WebRTC其实也使用了WebSocket，用于搭建WebRTC的信令机制，但是因为WebRTC是端到端连接，在WebSocket连接建立结束后，就不再需要额外服务器。那它们之间到底有什么区别呢？我们分别从设计理念和实现区别来看。

设计理念

- WebSocket主要用于IM聊天应用。
- WebRTC是为高质量音视频实时通信设计的。

实际区别

- WebRTC使用UDP协议，而WebSocket使用TCP协议。
- WebRTC提供的浏览器端到端通信比WebSocket提供的服务延迟更低。

WebRTC用到了哪些技术？

WebRTC其实就是一组其他技术的集合体，这里面包含了许许多多的协议、技术点，想在文章中分析完所有的技术点不太现实，我们来讲点关键的！

NAT（Network Address Translation）

网络地址转换，这个技术相信大部分看文章的朋友都有在大学期间学习过，用来解决IPv4地址短缺的问题。所谓的网络地址转换，就是把内网地址转换成可以访问外网的地址。那和WebRTC有什么关系呢？关系大了！WebRTC是P2P方式，我们需要找到对方的ip，点对点的连接。如果对方有一个公开的IP地址，那么连接过程将不会有什么问题。因为会像连接一个网页服务一样，把端口和IP都提供给对方后，我们和它就可以直接进行连接了。但在大多数情况下，它都是隐藏在公共网络之后的，我们无法直接连接。

对NAT网络地址转换的运行原理感兴趣的朋友可以自行学习，就不在本文展开了。

NAT 的转换方式主要有四种，而WebRTC默认支持三种网络扩展的方式，对其他的方式并不友好，且大部分的网络地址转换都是通过以下三种方式：

一对一 NAT（完全圆锥型 NAT）
IP 受限型 NAT
端口受限型 NAT

STUN和TURN

而网络地址转换过程主要依赖于两种协议，即会话穿越工具（STUN）和中继NAT穿越工具（TURN）。

STUN服务器的作用是帮助设备发现自己的公网IP地址和端口。它是非常轻量级的，通常位于公共网络上，并且有一个简单的任务：就是检查终端传入请求的IP地址（躲在NAT后面的程序），并将该地址作为响应发送回去。这个过程使得WebRTC A端为自己获得一个可公开访问的地址，然后通过信令机制将其传递给B端（或其他端）以建立直接链接。

然而，STUN不能在所有情况下都工作，特别是当NAT防火墙的策略比较严格时，例如在刚才讲NAT的时候没有提到的第四种方式——对称 NAT（Symmetric NAT），在这种环境下必须使用 TURN！TURN服务器实际上扮演了媒体流的中继角色，将数据从发送端传到接收端。这代表着：所有的通信内容都要经过 TURN 服务器的转发，导致TURN服务器的维护成本比较高，所以我们可以发现，基本上没有免费给用户使用的TURN服务器。

想创建TURN服务器可以参考： https://github.com/coturn/coturn

ICE框架

当客户端和服务端媒体协商完成后，需要开始建立网络连接，它会STUN和TRUN协议完成工作。之后，我们就会从A端到B端之间的路径有了非常多的选择，ICE框架就是为了更好的处理这些路径而提出的。ICE会获取所有可用的通信路径，并将其作为"候选者"。这些路径可能包括本地IP地址以及STUN和TURN服务器提供的地址等。然后，ICE将收集到的所有地址放入SDP（会话描述协议） 中，并将其发送到对方。对方通过解析SDP来了解我们提供的重要信息。

SDP

在前面我们说到了SDP（会话描述协议），那它的作用主要是什么呢？SDP只是一种数据格式，而且它是WebRTC中最重要的几个概念之一。它的设计目的是将用户产生的SDP送至其他端，怎么发送的它不管，当A端想要开始一个通话时，它就会创建一个包含了自己可接受的媒体格式、网络信息、安全选项和其他信息的offer，然后发送给B端。收到offer的B端会回复一个answer，包含了它决定使用的媒体和网络参数。我们开发者也可以自定义SDP的内容。