webrtc网络传输

Ⅰ WebRTC介绍

1、 WebRTC是什么？
2、 WebRTC能做什么?
3、 常用API
4、 基本原理

WebRTC全称是Web Real-Time communication，是一种实时音视频通讯技术，通过WebRTC可以使浏览器之间建立点对点的连接，并实时传输数据。

通过上述图片可以看到【浏览器M】和【浏览器L】可以在不依余信老赖于Web服务器的情况下点对点实时传输数据。上图中的Web服务器不是用于数据传输，而是用于协助【浏览器M】和【浏览器L】进行连接，进行协助连接的服务器也叫【信令服务器】。

WebRTC主要分为四部分，分别是信令、建立连接、安全加密、数据传输，下面分别介绍四个步骤。

信令是指通信两端基于交换的数据进行协商。通俗的解释就是在互联网中两个浏览器之间如果要进行点对点的数据传输，连接双方需要交换对方的一些基本信息，基本信息包括对方的地址，带宽，数据的编解码格式，是否支持音视频等等信息。

通信双方的基本信息完成交换后，浏览器双方开始坦洞建立连接。在网络中，浏览器双方可能在同一个内网，可能不在同一个内网，中间可能还隔着交换机、路由器，还会存在防火墙。在网络的环境复杂的情况下，通信的双方需要找到一条最佳路径传输数据建立连接。建立连接主要使用的协议就是ICE协议。【ICE协议】又需要依赖【STUN协议】和【TURN协议】。

在WebRTC中，为了保证媒体传输的安全性，引入了【DTLS】作为传输加密协议，DTLS原理和作用类似于SSL/TLS，【DTLS】主要适用于UDP通信过程的加密，SSL/TLS主要适用于TCP通信过程的加密。
在WebRTC中，音视频数据传输是使用RTP协议，然后通过 DTLS 协商出加密密钥之后，RTP 也需要升级为 SRTP，通过密钥加密后进行通信。协议栈如下图所示：

上面说了对数据加密是使用DTLS，传输数据则分为两种情况，一种是传输音视频数据，另一种是传输自定义应用数据。

1、音视频数据传输，主要使用RTP/SRTP、RTCP/SRTCP协议

前面主要对WebRTC做了一个简单介绍，跳过了很多细节，有些地方可能不够严谨，如果有兴趣的读者，可以对技术做进一步研究，比如：
1、信令如何进行协商？
2、传输层用了UDP，UDP本身是不竖升可靠的，那么，音视频数据、自定义用户数据的时序、质量是如何保证的？
3、RTP用来传递音视频数据，为什么还需要有RTCP？
4、SCTP如何从协议层面兼顾传输的效率和质量？如何实现自定义数据的高效传递？
5、ICE协议的完整流程。
6、其他。

Ⅱ WebRTC 的音频网络对抗概述

WebRTC 音频数据处理中，期望可以实现音频数据处理及传输，延时低，互动性好，声音平稳无抖动，码率低消耗带宽少等。在数据传输上，WebRTC 采用基于 UDP 的 RTP/RTCP 协议，RTP/RTCP 本身不提供数据的可靠传输及质量保障。公共互联网这种分组交换网络，天然具有数据包传输的丢失、重复、乱序及延时等问题。WebRTC 音频数据处理的这些目标很难同时实现，WebRTC 的音频网络对抗实现中针对不同情况对这些目标进行平衡。

这里更仔细地看一下 WebRTC 音频数据处理管线，并特别关注与音频网猜桐络对抗相关的逻辑。

前面在 WebRTC 的音频数据编码及发送控制管线 一文中分析了 WebRTC 的音频数据编码及发送控制相关逻辑，这里再来看一下穗铅坦 WebRTC 的音频数据接收及解码播放过程。

WebRTC 的音频数据接收处理的概念抽象层面的完整流程大体如下：

对于 WebRTC 的音频数据接收处理过程， webrtc::AudioDeviceMole 负责把声音 PCM 数据通过系统接口送进设备播放出来。 webrtc::AudioDeviceMole 内部一般会起专门的播放线程，由播放线程驱动整个解码播放过程。 webrtc::AudioTransport 作为一个适配和胶水模块，它把音频数据播放和 webrtc::AudioProcessing 的音频数据处理及混音等结合起来，它通过 webrtc::AudioMixer 同步获取并混音各个远端音频流，这些混音之后的激档音频数据除了返回给 webrtc::AudioDeviceMole 用于播放外，还会被送进 webrtc::AudioProcessing ，以作为回声消除的参考信号。 webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 为播放过程提供解码之后的数据。RTCP 反馈在 webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 中会通过 webrtc::Transport 发送出去。 webrtc::Transport 也是一个适配和胶水模块，它通过 cricket::MediaChannel::NetworkInterface 实际将数据包发送网络。 cricket::MediaChannel 从网络中接收音频数据包并送进 webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 。

如果将音频数据接收处理流水线上的适配和胶水模块省掉，音频数据接收处理流水线将可简化为类似下面这样：

webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 是整个过程的中心，其实现位于 webrtc/audio/audio_receive_stream.h / webrtc/audio/audio_receive_stream.cc ，相关的类层次结构如下图：

在 RTC 中，为了实现交互和低延迟，音频数据接收处理不能只做包的重排序和解码，它还要充分考虑网络对抗，如 PLC 及发送 RTCP 反馈等，这也是一个相当复杂的过程。WebRTC 的设计大量采用了控制流与数据流分离的思想，这在 webrtc::AudioReceiveStream 的设计与实现中也有体现。分析 webrtc::AudioReceiveStream 的设计与实现时，也可以从配置及控制，和数据流两个角度来看。

可以对 webrtc::AudioReceiveStream 执行的配置和控制主要有如下这些：

对于数据流，一是从网络中接收到的数据包被送进 webrtc::AudioReceiveStream ；二是播放时， webrtc::AudioDeviceMole 从 webrtc::AudioReceiveStream 获得解码后的数据，并送进播放设备播放出来；三是 webrtc::AudioReceiveStream 发送 RTCP 反馈包给发送端以协助实现拥塞控制，对编码发送过程产生影响。

webrtc::AudioReceiveStream 的实现中，最主要的数据处理流程 —— 音频数据接收、解码及播放过程，及相关模块如下图：

这个图中的箭头表示数据流动的方向，数据在各个模块中处理的先后顺序为自左向右。图中下方红色的框中是与网络对抗密切相关的逻辑。

webrtc::AudioReceiveStream 的实现的数据处理流程中，输入数据为音频网络数据包和对端发来的 RTCP 包，来自于 cricket::MediaChannel ，输出数据为解码后的 PCM 数据，被送给 webrtc::AudioTransport ，以及构造的 RTCP 反馈包，如 TransportCC、RTCP NACK 包，被送给 webrtc::Transport 发出去。

webrtc::AudioReceiveStream 的实现内部，音频网络数据包最终被送进 NetEQ 的缓冲区 webrtc::PacketBuffer 里，播放时 NetEQ 做解码、PLC 等，解码后的数据提供给 webrtc::AudioDeviceMole 。

这里先来看一下， webrtc::AudioReceiveStream 实现的这个数据处理流水线的搭建过程。

webrtc::AudioReceiveStream 实现的数据处理管线是分步骤搭建完成的。我们围绕上面的 webrtc::AudioReceiveStream 数据处理流程图 来看这个过程。

在 webrtc::AudioReceiveStream 对象创建，也就是 webrtc::voe::(anonymous namespace)::ChannelReceive 对象创建时，会创建一些关键对象，并建立部分对象之间的联系，这个调用过程如下：

webrtc::AudioReceiveStream 通过 webrtc::Call 创建，传入 webrtc::AudioReceiveStream::Config，其中包含与 NACK、jitter buffer 最大大小、payload type 与 codec 的映射相关，及 webrtc::Transport 等各种配置。

webrtc::voe::(anonymous namespace)::ChannelReceive 对象的构造函数如下：

webrtc::voe::(anonymous namespace)::ChannelReceive 对象的构造函数的执行过程如下：

图中标为绿色的模块为这个阶段已经接入 webrtc::voe::(anonymous namespace)::ChannelReceive 的模块，标为黄色的则为那些还没有接进来的模块；实线箭头表示这个阶段已经建立的连接，虚线箭头则表示还没有建立的连接。

在 ChannelReceive 的 () 函数中， webrtc::PacketRouter 被接进来：

这个操作也发生在 webrtc::AudioReceiveStream 对象创建期间。 ChannelReceive 的 () 函数的实现如下：

这里 webrtc::PacketRouter 和 webrtc::MoleRtpRtcpImpl2 被连接起来，前面图中标号为 5 的这条连接也建立起来了。NetEQ 在需要音频解码器时创建音频解码器，这个过程这里不再赘述。

这样 webrtc::AudioReceiveStream 内部的数据处理管线的状态变为如下图所示：

webrtc::AudioReceiveStream 的生命周期函数 Start() 被调用时， webrtc::AudioReceiveStream 被加进 webrtc::AudioMixer ：

这样 webrtc::AudioReceiveStream 的数据处理管线就此搭建完成。整个音频数据处理管线的状态变为如下图所示：

WebRTC 音频数据接收处理的实现中，保存从网络上接收的音频数据包的缓冲区为 NetEQ 的 webrtc::PacketBuffer ，收到音频数据包并保存进 NetEQ 的 webrtc::PacketBuffer 的过程如下面这样：

播放时， webrtc::AudioDeviceMole 最终会向 NetEQ 请求 PCM 数据，此时 NetEQ 会从 webrtc::PacketBuffer 中取出数据包并解码。网络中传输的音频数据包中包含的音频采样点和 webrtc::AudioDeviceMole 每次请求的音频采样点不一定是完全相同的，比如采样率为 48kHz 的音频， webrtc::AudioDeviceMole 每次请求 10ms 的数据，也就是 480 个采样点，而 OPUS 音频编解码器每个编码帧中包含 20ms 的数据，也就是 960 个采样点，这样 NetEQ 返回 webrtc::AudioDeviceMole 每次请求的采样点之后，可能会有解码音频数据的剩余，这需要一个专门的 PCM 数据缓冲区。这个数据缓冲区为 NetEQ 的 webrtc::SyncBuffer 。

webrtc::AudioDeviceMole 请求播放数据的大体过程如下面这样：

更加仔细地审视 WebRTC 的音频数据处理、编码和发送过程，更完整地将网络对抗考虑进来， WebRTC 的音频数据处理、编码和发送过程，及相关模块如下图：

在 WebRTC 的音频数据处理、编码和发送过程中，编码器对于网络对抗起着巨大的作用。WebRTC 通过一个名为 audio network adapter (ANA) 的模块，根据网络状况，对编码过程进行调节。

pacing 模块平滑地将媒体数据发送到网络，拥塞控制 congestion control 模块通过影响 pacing 模块来影响媒体数据发送的过程，以达到控制拥塞的目的。

由 WebRTC 的音频采集、处理、编码和发送过程，及音频的接收、解码、处理及播放过程，可以粗略梳理出 WebRTC 的音频网络对抗的复杂机制：

没看到 WebRTC 有音频带外 FEC 机制的实现。

参考文章

干货|一文读懂腾讯会议在复杂网络下如何保证高清音频

Done.

Ⅲ webrtc服务器需要多少带宽

根据 webrtc-experiment ，opus的最小带宽为6kbit/s，vp8的最小带宽为100kbit/s.因此，总的速度为106kbit/s。【点击免费试用，0成本启动】

webrtc中的带宽自适应算法分为两种：
1、发端带宽控制，原理是由rtcp中的丢包统计来动态的增加或减少带宽，在减少带宽时使用TFRC算法来增加平滑度。
2、收端带宽估算，原理是并由收到rtp数据，估出带宽；用卡尔曼滤波，对每一帧的发送时间和接收时间进行分析，从而得出网络带宽利用情况，修正估出的带宽。两种算法相辅相成，收端将估算的带宽发送给发端，发端结合收到的带宽以及丢包率，调整发送的带宽。

想要了解更多关于webrtc的相关信息，推荐咨询ZEGO即构科技。即构科技有限公司是为开发者提供高品质实时音视频、实时语音、互动直播和IM即时通讯等服务的公司。核心团队成员均来自QQ，有超过20年的互联网和音视频技术开发经验，以及亿量级海内外用户运营服务能力。专注于实时音视频领域，致力提供全世界范围内最清晰稳定实时的语音视频服务，已服务4000+企业，适用于游戏、娱乐社交、在线教育、在线医疗、远程会议、智能硬件等多种用户场景。

Ⅳ WebRTC简介（一）

WebRTC（Web Real-Time Communication）也被称为网络实时通信，是由 Google、Mozilla 和其他公司推动的一个开源项目，它通过 Javascript API 实现无插件的实时通信，以及在不需要中介的情况下在浏览器之间交换任意数据。

WebRTC的优点：

WebRTC技术的诞生，有一个很重要的原因在于，在浏览器实现实时音视频通话，需要依赖相关插件或程序，而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新，因此插件带来的安全风险也相对较大。

在WebRTC诞生之前，开发实时音视频应用的成本是非常高，需要考虑的技术问题很多，如音视频的编解码，数据传输延时、丢包、网络抖动、回音处理和消除等，如果要兼容浏览器端的实时音视频通信，还需要额外安装插件。当然，可以考虑使用第三方成熟技术，比和旦并如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions)，支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS，如Yahoo，AOL，IBM，SKYPE，QQ等。

WebRTC项目的愿景：实时通信web化，让WebRTC成为互联网音视频实时通信的规范，让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信，必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景：

两个不同网络环境的（具备摄像头/麦克风多媒体设备的）客户端（浏览器或APP），要实现点对点的实时音视频对话，难点在哪里？

要实现P2P通信，首先需要了解彼此是否都支持相同的媒体能力，WebRTC默认使用V8编解码器，如果要连接的对方不支持V8解码，如果没有媒体协商过程。那么即使连接成功，把视频数据发给对方，对方也无法播放
比唤迹如：Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264
有一个专门的协议 ，称为Session Description Protocol (SDP)，可用于描述上述这类迟唤信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。

交换数据会通过一个中间服务来完成，在这里，我们称之为信令服务器
在建立P2P连接时，需要交换的信息有：

最理想的场景

然而，在大多数情况下，两个对等端都是各自处于某个局域网之中，相互之间隔着NAT与防火墙

NAT(Network Address Translation)即为网路地址转换协议

局域网-->公网

公网-->局域网

可以借助STUN服务器.，穿越NAT

在NAT四种主要类型中有三种是可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用STUN穿透，这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说，路由器只会接受之前连线过的节点所建立的连线。

可以点对点连接的情况与需要中转的情况（数据来源于Google）

不过在国内大部分局域网无法穿越。

Ⅳ WebRTC概念简介

WebRTC（Web Real-Time Communication）。Real-Time Communication，实时通讯。

WebRTC能让web应用和站点之间选择性地分享音视频流。在不安装其它应用和插件的情况下，完成点对点通信。
WebRTC背后的技术被实现为一个开放的Web标准，并在所有主要浏览器中均以常规JavaScript API的形式提供。对于客户端（例如Android和iOS），可以使用提供相同功能的库。 WebRTC是个 开源项目 ，得到Google，Apple，Microsoft和Mozilla等等公司的支持。2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

WebRTC包括一系列API和相互关联的协议来实现通信。

Voice over Internet Protocol，在网络上传输声音消息的技术。
例如网络音频通话。或者叫做IP电话，宽带电话。使用VoIP技术的一大原因是费用低。

Network address translation，网络地址转换。
NAT能给你的设备一个公共IP地址。一个路由器（router）有一个公共IP地址，每个连接到路由的设备有一个私有的IP地址。
设备发送请求时，会从一个特定端口，通过私有IP发送到路由的公共IP。这样每个设备在网上不需要都有一个公共IP地址，但也能被其它设备发现。

参考 IP Network Address Translator (NAT) Terminology and Considerations

Interactive Connectivity Establishment，互动式连接建立（交互式连通性建立）。
ICE是一套能让web浏览器之间互相连接的框架。通常来说，节点A到B是很难直接相连的。防火墙会阻止连接，设备没有公共IP地址，路由不允许直接连接其他节点。
ICE使用STUN或者TURN服务（或者同时使用两者）来建立连接。

参考 ICE | rfc8445

Session Traversal Utilities for NAT (STUN) ，NAT会话传输工具。
STUN协议能发现告握辩客户端（节点）的公共地址。客户端发送一个请求给网上的STUN服务器，服务器返回客户端的公共地址。不管客户端在路由器的NAT后能否可达。袜缺
STUN为请求者提供了可公开访问的IP地址，它就不再参与对话了。

有些路由器会限制设备与外面其它设备的连接。这意味着即使STUN服务器知道了路由的公共IP地址，也没法建立连接。
这种情况下我们需要使用 TURN 。

Traversal Using Relays around NAT，使用中继绕过NAT传输。
一些路由器使用一种叫“Symmetric NAT”（对称型NAT）的限制。这意味着路由器仅允许之前皮猜连接过的节点（peer）来建立连接。

STUN 提供了一个能让应用（终端，节点）穿过NAT的方法。STUN允许客户端获得一个传输地址（一个IP和端口）来获取其它节点的数据。
然而STUN获取到的地址不一定能被所有节点使用。这些地址是否可用取决于网络拓扑的情况。所以，单独STUN无法提供完整的穿越NAT的方案。

TURN协议允许两个处于NAT环境的主机利用中继进行通讯。客户端能够在TURN服务器上分配资源，与其它客户端（peer）进行通讯。
客户端关联一个TURN服务器的地址（relayed server address）来作为中继。
客户端发送报文给TURN服务，TURN服务使用relayed server address作为源地址向其他客户端中继转发报文。
穿越NAT，这个过程就像是“打洞”。也有人称TURN服务器为“打洞服务器”。

这么看，TURN服务器需要有大的带宽。因此，ICE会优先考虑直接通讯，无法直接通讯情况下会使用TURN。

参考 TURN rfc8656

Session Description Protocol，会话描述协议。

描述多媒体连接内容的协议。例如分辨率，格式，编码，加密算法等等。

实际上，SDP不是个真正的协议。它也是用来描述设备之间连接与传输多媒体的数据格式。

参考 SDP: Session Description Protocol | rfc8866

一些缩写

更多请参考 WebRTC概念简介

Ⅵ WebRTC（四）流媒体传输技术

WebRTC作为一个实时音视频传输技术，实时性是RTC技术的主要评判标准。在整个实时音视频系统中，对实时性影响最大的就是传输层。当今通信技术众多，但是都离不开两个基础的协议，即TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。

众所周知，TCP协议是一个在不可靠的网络上扮羡提供可靠的端对端数据传输协议。为了可靠性，TCP有三次握手、超时重传、流量控制和拥塞控制等机制，这些都都打打影响到了实时性。

虽然UDP不是可靠的传输协议，但是却保证了实时性，并且有极高的自由度。因此WebRTC技术中传输层采用的基于UDP协议的RTP协议（Real-time Transport Protocol，实时传输协议）。

由于UDP是无序传输的，因此RTP协议主要的作用是记录UDP包的序号，方便应用层后续的操作。RTP协议的规范敬缺弊如下图所示。

下面将按照从左到右从上到下的顺序介绍各个字段的具体含义：

RTCP（Real-Time Transport Control Protocol），即实时传输控制协议，它用于为RTP协议的服务质量提供保障，在传输层对音视频流进行同步并且检测网络质量。在进行RTP会话时，发送方和接收方都会周期性地发送RTCP包，该包中包含了已发送的数据包的数量和丢失包的数量等信息。由于RTCP包只包含一些控制信息，因此包的容量比较小，多个RTCP包可以跟随一个UDP一起传输。

RTCP有五种分组类型：

综上所述，RTC协议可以保证数据传输的实时性亮族，RTCP协议可以保证数据传输的可靠性，WebRTC 将上述两个协议进行配合使用的确能在较小的开销内取得优秀的传输效率。