WebRTC初识

WebRTC是什么？

WebRTC名称源于网页即时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网的W3C推荐标准。它通过简单的API为浏览器和移动应用程序提供实时通信（RTC）功能。

WebRTC发展前景

WebRTC虽然冠以Web之名，但是不受限于传统互联网应用或者浏览器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、移动设备（AndRoid或iOS）还是IoT设备，只要IP连接可达到符合WebRTC规范就可以互通。这一点释放了大量智能终端（或运行在智能终端上的APP）的实时通信能力，打开了许多对于实时交互性要求较高的应用场景的想象空间，如在线教育、视频会议、视频社交、远程协助、远程操控等等都是其合适的应用领域。

WebRTC有哪些优点

WebRTC主要应用在实时通信放慢，优点如下：

• Google开源的框架
• 跨平台：可以在Web、Andriod、iOS、windows、MacOS、Linux运行WebRTC应用
• 实时传输：传输速度快，延迟低、适合实时性要求较高的应用场景
• 音视频引擎：强大的音视频处理能力
• 免插件：不需要安装任何插件，打开浏览器即可使用
• 免费：虽然WebRTC技术已经较为成熟，其集成了最佳的音视频引擎，十分先进的Codec，但是Google对于这些技术不收取任何费用
• 强大的打洞能力：WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理
• 主流浏览器支持：Chrome、Safari、Firefox、Edge

WebRTC应用场景

WebRTC的应用场景十分广泛，尤其是在网络越来越发达的当下，音视频会议、在线教育、即时通讯工具、游戏、人脸识别一定是当下和未来发展方向，5G时代的到来必然会引起井喷式的发展。主要应用领域如下所示：

• 音视频会议
• 在线教育
• 照相机
• 音乐播放器
• 共享远程桌面
• 录制
• 即时通讯工具
• P2P网络加速
• 文件传输工具
• 游戏
• 实时人脸识别

WebRTC架构

主要分为三个层次

• 浅紫色 开发者的应用层
• 深紫色 W3C提供的应用层api

• 绿色 该部分为WebRTC核心，该层又分四个部分C++API层、会话管理层、引擎层、驱动层。

  C++API层

  这一层提供了一些 C++ API，主要是供浏览器支持WebRTC规范而调用的API，又比如需要Android上实现webRTC功能就需要编写JNI函数调用这一层API。

主要作用就是把WebRTC的核心功能暴露出来，如设备管理，音视频流数据采集等，方便各个软件厂商集成到自家应用中，比如浏览器厂商等

其中 PeerConnection是该层最核心的一个模块，即对等连接模块；该模块中实现了很多功能，如P2P穿墙打洞、通信链路的建立和优选、流数据传输、非音视频数据传输、传输质量报告和统计等等

会话管理层

提供了会话功能管理功能，可进行创建会话、管理会话、管理上下文环境等。而这一层又会涉及到各种协议，比如说信令服务器的SDP协议等，主要用于进行信令交互和管理 RTCPeerConnection的连接状态。

引擎层

WebRTC核心层中最重、最复杂的一层。而这一层又分为三个小模块，分别是：Voice Engine（音频引擎）、Video Engine（视频引擎）以及Transport（传输模块）

1. 第一个模块 Voice Engine(音频引擎)， Voice Engine是一个包含了系列音频处理功能的框架，如音频采集、音频编解码、音频优化（包括降噪、回声消除等）等一系列的音频功能。
2. 第二个模块Video Engine(视频引擎），Video Engine是一个包含了系列视频处理功能的框架，如视频采集、视频编解码、根据网络抖动动态修改视频传输质量、图像处理等。
3. 第三个模块Transport(传输模块)，在WebRTC中，数据传输除了音视频等流媒体数据之外，还可以传输文件、文本、图片等其他二进制数据，这些功能就是这个模块所提供的。

• iSAC / iLBC Codec 编解码器 iSAC和iLBC是WebRTC内置的音频编码器。其中iSAC是针对VoIP（Voice over Internet Protocol，即基于IP的语音传输）和音频流在宽带和超宽带环境中进行音频传输的编解码器，是WebRTC音频引擎的默认的编解码器，技术成熟，且被广泛应用在各种实时通信软件中；而iLBC则是VoIP在窄带环境中的语音编解码器，在网络丢包较为严重的情况下仍能保持较好通话质量。
• NetEQ for voice 防抖防丢包 NetEQ是网络语音信号处理的组件，这个算法能自适应网络环境的变化，有效的处理因网络抖动而导致数据丢包所造成的音频质量问题，这一技术可谓是当年WebRTC的前身GIPS的看家本领。
• Echo Canceler/Noise Reduction 降噪消除回音 Echo Canceler是处理回声消除模块，能有效的消除采集音频带来的回声影响，比如说在实时音视频通话的过程中，打开手机扬声器的话，本来的需求是录制本人的声音实时发送给对方的，但是由于存在回声，也会把对方说话的声音也录制进去。目前笔者测试发现市场上的一些手机录音的时候本身是自带了回音消除功能，而且Android也提供有相关的API，但是好像大多数情况下，这个API都没起作用，可能是由于厂商兼容性问题，甚至有可能是直接阉割掉这个功能了。因此想要做到录音是全平台适配回声消除功能的话就可以使用WebRTC的这个功能。而iOS平台上的录音是带有回声消除功能的。而Noise Reduction则是抑制噪音模块（也就是降噪），如有效的抑制多种噪音（如嘶嘶声，风扇噪音等）。
• VP8 Codec 视频编解码器 VP8是第八代的On2视频，能以更少的数据提供更高质量的视频，而且只需较小的处理能力即可播放视频，为致力于实现产品及服务差异化的网络电视、IPTV和视频会议公司提供理想的解决方案。其数据压缩率和性能方面比市场上其他编解码器高，其功能特点非常适合实时通信，是WebRTC中默认的视频编解码器。
• VP9 视频编解码器 是Google提供的开源的免费视频codec，是VP8的后续版本，初始开发时命名为下一代开源视频或者VP-NEXT。VP9的开发始于2011年Q3，试图降低VP8的50%的码率而保持相同的质量，另外希望VP9比H.265（ High Efficiency Video Coding）有更好的编码效率。
• Video Jitter Buffer 视频抖动缓冲器，实时视频通信难免会因为网络的原因导致视频的抖动或者视频数据的丢失，视频抖动缓冲器依靠独特的算法，有效的解决这类情况对直播会议质量造成较大的影响。
• Image enhancements 图像质量增强 图像质量增强模块，这个模块是用来做图像处理以提升视频画面质量的，如图像明暗度检测、颜色增强、降噪处理等。
• SRTP (SecureReal-time Transport Protocol)是在RTP的基础上加入了安全机制的传输协议，SRTP为数据提供了加密、消息认证、完整性保证和重放保护等功能，最大程度保障了数据传输的安全性
• Multiplexing 通道复用，即多个流数据传输共用一个通道， 以此提高传输效率。
• P2P STUN+TURN+ICE WebRTC是一种基于P2P的通信技术。而STUN、TURN、ICE这些则是实现P2P的一些关键技术。
• STUN、TURN、ICE又成为NAT穿透，在现实生活中不同局域网中的内外ip是无法直接通信的，比如说局域网A中192.168.2.1与局域网B中192.168.2.2是无法互相直接发送消息的，那么如果要在两个不同的局域网中建立起可以直接通信的通道就得依靠STUN+TURN+ICE这些技术。

驱动层

这部分有Audio Capture/Render（音频的采集和渲染模块）、Video Capture（视频采集模块）和Network I/O（网络IO模块）组成

通话原理

两个不同网络环境的（具备摄像头/麦克风多媒体设备）浏览器，是如何实现点对点的实时音视频对话的？

媒体协商

两个客户端想要创建连接，必须有一个双方都能够访问的服务器（信令服务器）来帮助他们交换连接所需要的信息，一般交换的数据是Session Description Protocol（SDP），这里米啊吗描述了连接双方想要的建立怎样的连接。

信令服务器可以用来交换SDP信息，一般是通过创建Socket连接处理，可以使用node.js，golang等其他技术实现，只要能交换双方信息即可。

SDP协议

// 信令内容
// 版本
v=0
// <username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
o=- 7614219274584779017 2 IN IP4 127.0.0.1
// 会话名
s=-
// 会话的起始时间和结束时间，0代表没有限制
t=0 0
// 表示音频传输和data channel传输共用一个传输通道，通过id进行区分不同的流
a=group:BUNDLE audio video
a=msid-semantic: WMS
// m=audio表示包含音频， 1表示端口，RTP包， SAVPF代表使用srtcp的反馈机制来控制通信过程，111 103 104 0 8 107 106 105 13 126表示支持的编码，与后面的rtpmap对应
m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:W2TGCZw2NZHuwlnf
a=ice-pwd:xdQEccP40E+P0L5qTyzDgfmW
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9c1AHz27dZ9xPI91YNfSlI67/EMkjHHIHORiClQe
// 编码采用的编号，采样率，声道
a=rtpmap:111 opus/48000/2
…

SDP中有关于IP和端口的描述，但是WebRTC技术并没有使用这些内容，那么双方是怎么建立直接的连接呢？这部分需要ICE框架来完成。

网络协商

点对点连接的双方需要了解对方的网络情况，这样才能找到一条互通通讯链路。需要做两个处理

• 获取外网IP地址映射

• 通过信令服务器交换网络信息

  理想的网络情况是每个浏览器的电脑都有一个公网IP，可以直接进行点对点连接，但是现实中每个浏览器是不具备独立的公网IP，基本上都是需要依靠NAT做转换。

NAT

NAT(Network Address Translation, 网络地址转换)，这一技术主要是为了解决IPV4下IP地址匮乏以及避免来自外网的攻击，隐藏并保护网络内部的计算机。随着IPV6的出现这项技术可能逐渐会退出舞台，IPV6的可使用的数量16^4^8,IPV4则是16^2^4。

手机使用数据/WIFI均采用了10.6.0.0/10段的运营商级的NAT地址，属于私有网络，也就是每个运营商是一个大的局域网。

缺点

• 地址转换将增加交换延迟；
• 导致无法进行端到端IP跟踪；
• 导致有些应用程序无法正常运行；

更多了解 https://www.zhihu.com/question/31332694

NAT技术会保护内网地址的安全性，所以这就导致了一个问题，采用P2P连接时，NAT会阻止外网地址的访问（原因是外网访问方不知道设备的具体内网IP），这时我们就得采用NAT穿透技术了。

NAT 穿透技术的答题思路：借助一个公网IP服务器，A与B都往公网服务器发包，那么公网服务器就拿到了A、B的IP/PORT，由于A、B是主动给公网服务器发包，所以公网服务器可以穿透NAT-A、NAT-B并发送信息给A、B。现在公网服务器只需要将A的IP/PORT发送给B，将B的IP/PORT发送给A，这样A、B就知道了彼此的IP/PORT，那么下一次A、B通讯就不会被NAT阻拦。

ICE

互动式连接建立（Interactive Connectivity Establishment），是一种框架，使各种NAT穿透技术（STUN，TURN...）可以实现统一。该技术可以让客户端成功的穿透远程用户与网络之间存在的各类防火墙。

STUN

NA的UDP简单穿越（Session Traversal Utilities for NAT）是一种网络协议，它允许位于NAT后的客户端找到自己的公网地址，查处自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端口，这些信息被用来在两个同时处于NAT路由器之后的逐渐之间建立UDP通信。

即使通过STUN服务器取得了公用的IP地址，也不一定能建立连接，因为不同的NAT类型处理传人的UDP分租的方式是不同的，NAT主要分为四种类型，其中有三种事可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但是大型公司的网络经常采用对称型NAT（双向NAT）则不能使用，这类路由器会穿透NAT部署所谓的「Symmetric NAT」限制。也就是说路由器只会接受你之前连接过的节点所建立的连接。这类网络就需要TURN技术。

TURN

TURN的全称为Traversal Using Relays around NAT（TURN），是STUN/RFC5389的一个拓展，主要添加了Relay功能（转发功能）。如果终端在NAT之后，那么在特定的情景下，有可能是的终端无法与其对等端进行直接的通信，这时就需要公网的服务器作为一个中介，对往来的数据进行转发。

STU和TURN开源项目：coturn https://github.com/coturn/coturn turn [https://github.com/pion/turn
](url)

信令服务器

信令服务器（Signal server）转发彼此媒体信息和网络信息

在基于WebRTC API开发应用（APP）式，可以将彼此的APP连接到信令服务器（Signal server一般建在公或者两端都可以访问到的局域网），借助信令服务器就可以实现SDP媒体信息及Candidate网络信息交换。信令服务器还可以提供房间管理功能、用户列表、用户进入、用户退出、来电接受/拒绝等IM功能。

建立连接

通过ICE框架建立连接的流程

• 连接双方通过第三方服务器来交换各自的SDP；
• 连接双方通过STUN协议从STUN Server获得自己的NAT结构，子网IP和公网IP，端口，这里的IP和端口信息称之为ICE candicate；
• 连接双方通过第三方服务器来交换各自的ICE Candidate，如果连接双方在同一个NAT下那他们仅通过内网Canddate就能建立起连接，如果他们处非对称型NAT下，就需要STUN Server识别出公网Candidate进行通信；
• 如果通过STUN Server发现的公网Candidate仍然无法建立连接，那么就可以判断当前的连接双方至少有一方是处于对称型NAT下，那么此时就需要TURN Server提供 relay服务；
• 连接双方向目标IP端口发送报文，通过SDP中涉及的密钥以及期望的传输内容，建立起加密长连接；

具体连接流程

• A 创建 Offer
• A 保存 Offer（set local description）
• A 发送 Offer 给 B
• B 保存 Offer（set remote description）
• B 创建 Answer
• B 保存 Answer（set local description）
• B 发送 Answer 给 A
• A 保存 Answer（set remote description）
• A 发送 ICE Candidate 给 B
• B 发送 ICE Candidate 给 A
• A、B双方收到对方的媒体流并播放

更多学习地址

https://webrtc.org.cn/

https://rtcdeveloper.com/

https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API