想开发一款带有视频通话 / 共享屏幕功能的产品?那 WebRTC 是你必须要知道的!
![想开发一款带有视频通话/共享屏幕功能的产品?那WebRTC是你必须要知道的!](https://static001.geekbang.org/infoq/a0/a0542b0e28b6d4b6a4f7fb02252271c5.png)
作为一名技术爱好者,我总是对各种协议、各种功能感兴趣,两周前我想为我的开源项目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 端(或其他端)以建立直接链接。
![](https://static001.geekbang.org/infoq/7b/7bf6429565e6a69774ed2daf9b9d2929.png)
然而,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 的内容。
![](https://static001.geekbang.org/infoq/6f/6f6da2834dbccc834f965fd6e63afe88.png)
信令交换
如果看了 SDP 交换的过程图,那大家一定看到了中间的信令,信令其实就是一个转发服务,将一个设备端产生的 SDP 通过某种方式传递给想要通信的那方,大部分使用 websocket 或 socket 服务。其实啥方式都不重要,能将 SDP 信息传递给另外一方就可以了。
一个典型的 WebRTC 通信流程
知道了 WebRTC 大部分的技术,那一个典型的 WebRTC 通信流程就出现了!
![](https://static001.geekbang.org/infoq/5a/5a6877cbf76839fdfac95f8cd1cdd1b5.png)
看到这里,我相信你对 WebRTC 已经有了初步了解了,那么在下一篇 WebRTC 的系列文章中,我们来实现一个可以多端视频/语音电话的功能吧!
关于我
Hello,我是 Taxze,如果您觉得文章对您有价值,希望您能给我的文章点个❤️,有问题需要联系我的话:我在这里 。如果您觉得文章还差了那么点东西,也请通过关注督促我写出更好的文章~万一哪天我进步了呢?😝
版权声明: 本文为 InfoQ 作者【编程的平行世界】的原创文章。
原文链接:【http://xie.infoq.cn/article/45e71921cadc389969fa9ad44】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论