WebRTC的学习

一、简介

• webrtc 是为浏览器之间提供实时数据传输(Web Real-Time Communication)的javascript API
• 支持 peer-to-peer 音频、视频、数据流传输能力

兼容性

主要的API

getUserMedia : 获取音视频
MediaRecorder: 录制音视频
RTCPeerConnection: 浏览器之间音视频流连接对象
RTCDataChannel: 浏览器数据流连接对象

二、优点

是基于 UDP 的方式，

传输方式：RTC 是半可靠传输，特定情境下可对音视频有损传输，可有效降低延迟

复杂度：RTC方案的复杂很高，涉及一整套的协议设计和QOS保障机制

音视频友好性：RTC 对音视频更友好，可针对音视频做定制化优化

方案完备性：WebRTC 可提供端对端优化方案

理论延迟：WebRTC 方案的延迟可以达到 1 秒以内

支持的编解码有H264、VP8，VP9，AV1、H265

三、应用

淘宝直播就是基于 WebRTC 实现的一秒内的低延迟直播

四、架构图

总体上分为了三层：

一。Your web app层

最上层的带箭头的浅紫色部分是指开发者的应用层，就是指开发者基于webRTC技术规范所开发的应用程序。严格来说这并不属于WebRTC的架构内容。

二。Web API层

深紫色的中间层Web API (Edited by W3C WG)部分表示的是WebRTC开放给应用层开发人员调用的API(主要是JavaScript API 供web端使用),
在这层中开发者无需关心复杂的底层技术，只需了解webRTC的大致流程原理，调其API即可利用WebRTC实现点对点的通讯功能。

三。WebRTC的核心功能层

1.C++API层

绿色部分包裹的浅紫色WebRTC C++ API (PeerConnection)部分，这部分主要是一些C++的接口层，这一层提供了一些 C++ API，主要是供浏览器支持WebRTC规范而调用的API，又比如需要Android上实现webRTC功能就需要编写JNI函数调用这一层API。
这一层的主要作用就是把WebRTC的核心功能暴露出来，如设备管理，音视频流数据采集等，方便各个软件厂商集成到自家应用中，比如浏览器厂商等。

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

2.会话管理层（Session management层）

绿色部分被Session management / Abstract signaling (Session)标注的一层就是会话管理层。
这一层提供了会话功能管理功能，可进行创建会话、管理会话、管理上下文环境等。而这一层又会涉及到各种协议，比如说信令服务器的SDP协议等，主要用于进行信令交互和管理 RTCPeerConnection的连接状态。

3.引擎层

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

第一个模块 Voice Engine(音频引擎)， Voice Engine是一个包含了系列音频处理功能的框架，如音频采集、音频编解码、音频优化（包括降噪、回声消除等）等一系列的音频功能。

• 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则是抑制噪音模块（也就是降噪），如有效的抑制多种噪音（如嘶嘶声，风扇噪音等）。

第二个模块Video Engine(视频引擎），Video Engine是一个包含了系列视频处理功能的框架，如视频采集、视频编解码、根据网络抖动动态修改视频传输质量、图像处理等。

• 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

  Video Jitter Buffer——视频抖动缓冲器，实时视频通信难免会因为网络的原因导致视频的抖动或者视频数据的丢失，
  视频抖动缓冲器依靠独特的算法，有效的解决这类情况对直播会议质量造成较大的影响。

• Image enhancements

  Image enhancements——图像质量增强模块，这个模块是用来做图像处理以提升视频画面质量的，如图像明暗度检测、颜色增强、降噪处理等

第三个模块Transport(传输模块)，在WebRTC中，数据传输除了音视频等流媒体数据之外，还可以传输文件、文本、图片等其他二进制数据，这些功能就是这个模块所提供的。

• SRTP

  SRTP属于传输模块中的内容，在了解SRTP之前我们先来了解一下RTP。

  RTP 是(Real Time Protocol)提供了具有实时特征的、端到端的数据传送服务协议。而我们通常所说的RTCP等则是对RTP的控制协议。

  RTP不像http和ftp等可完整的下载整个影视文件，它是以固定的数据格式在网络上发送数据，如果RTP的头部几个字节表示什么，音频数据或者视频数据包含在RTP中那几个字节中等等。

  在RTP中，并未考虑到数据传输的安全性，比如没有加密功能，所以不符合安全性要求较高的应用需求，因此为了解决此问题，SRTP应运而生。
  SRTP(SecureReal-time Transport Protocol)是在RTP的基础上加入了安全机制的传输协议，SRTP为数据提供了加密、消息认证、完整性保证和重放保护等功能，最大程度保障了数据传输的安全性。
  所以RTP与SRTP的关系大概就是http与https的关系。

• Multiplexing

  Multiple exing，通道复用，即多个流数据传输共用一个通道， 以此提高传输效率。

• 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这些技术。而STUN、TURN和ICE又是使用不同方案进行穿透的

  WebRTC的信令传输可以慢些但需要可靠，而流媒体则实时性优，可以存在丢包、错包；这就意味着需要两套网络传输协议，一套是基于TCP的可靠传输协议用于信令等传输，一套是基于UDP的TRP协议用于实时多媒体数据的传输。其协议栈如下图所示：

  

  ICE（Interactive Connectivity Establishment）协议(RFC 5245)

  STUN（Session Traversal Utilities for NAT）(RFC5389)

  TURN（Traversal Using Relays around NAT）(RFC 5766)

  这三个协议是基于UDP协议建立和维持P2P连接的必要网络组件；

  DTLS（Datagram Transport Protocol）用于P2P双方数据安全传输。

4.驱动层

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

而这些音视频的采集和渲染，网络IO的传输功能，我们都是直接调用各平台提供的相关API即可实现

五、运行流程

标准WebRTC接入的流程：

1.播放端端发送接入请求：通过 HTTP 发送 AccessRequest ，携带播放 URL 和 offer SDP；

2.RTS 收到播放的接入请求后，记录 offerSDP 和 URL ，然后创建 answerSDP，生成一次会话 token 并设置到 SDP 的 ufrag 字段，通过 http 响应发送给客户端。

3.客户端设置 answerSDP，发送 Binding Request 请求，请求中 USERNAME 字段携带 answerSDP 中的 ufrag（即 RTS 下发的 token ）。

4.RTS 收到 Binding Request，根据 USERNAME 中的 token，找到之前 HTTP 请求相关信息，记录用户 IP 和端口。 （借助 Binding Request 的 USERNAME 传递 token 是由于 RTS 是单端口方案，需要根据 UDP 请求中的 token 信息确定是哪个用户的请求。传统的 WebRTC 是根据端口区分用户，RTS 为每个用户设置端口会带来巨大的运维成本）

5.进行标准的DTLS握手，交换SRTP密钥，开始媒体数据传输

相关限制：

• 它不支持直播中常用音频 AAC 编码和 44.1k 采样率。
• 其它不支持视频 B 帧编码特性，多 slice 编码在弱网下也会花屏。
• WebRTC 建联过程耗时过长，会影响秒开体验。

六、demo