webrtc（webrtc sfu）

本篇文章给大家谈谈webrtc，以及webrtc sfu对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享webrtc的知识，其中也会对webrtc sfu进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、WebRTC概念简介
• 2、WebRTC介绍
• 3、WebRTC基本概念（一）
• 4、用webrtc视频聊天方便吗？还需要什么技术？
• 5、WEBRTC基本概念

WebRTC概念简介

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

WebRTC能让web应用和站点之间选择性地分享音视频流。在不安装其它应用和插件webrtc的情况下，完成点对点通信。
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地址，路由不允许直接连接其webrtc他节点。
ICE使用STUN或者TURN服务（或者同时使用两者）来建立连接。

参考 ICE | rfc8445

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

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

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 （Web Real-Time Communication),一个可以让用户用自己流量实现音视频实时通信的框架（APIs),支持浏览器（Firefox、Chrome、Opera）以及iOS、Android 原生系统（Poor WP,默哀）。对于觉得带宽贼贵又需要实现用户之间音视频通信的公司来说，这是一个大大的福利。本系列文章会从WebRTC基本概念慢慢说起。

官方介绍：

按照传统的通信流程，是这样的：
如下图所示，数据发送端和接收端都需要通过公网服务器进行转发（因为发送端和接收端通常都做了NAT，彼此并不知对方实际位置）。
e.g.：犹如一个中国人和一个外国人，他们彼此不懂对方的语言，不知道对方的地址，但是中间有一个邮局知道对方的地址，因为对方都在邮局做了注册地址并且获取了同一个编号，那么如果他们之间需要互相通信的话，就需要和邮局联系，邮局会进行翻译并发往同一编号的对应地址。 但是这中间就会产生一个问题，这时候如果有多个中国人和多个外国人都要进行通信，那么邮局的工作量就会越来越大，当他们的通信超过原有邮局人手可处理规模时，邮局要么扩招（需要钱）要么延缓发送（会造成延迟，甚至丢失信件）。

时间关系，以下内容不再举例说明，需要网络基础的同学才能继续观看。

在真实世界的网络中，因为IPv4的地址个数问题，我们基本都是采用NAT连接的：

STUN服务器提供的功能十分简单，它让使用者获取自己所在的公网地址和在NAT中所映射端口号，这个服务有什么用呢？当使用者知道自己所在公网地址以及内部NAT映射端口时，它便可以讲自己的公网地址和端口号通知对方，这样对方就可以在茫茫大网中找到自己。
在以往统计中，WebRTC通过STUN建立连接的成功率为86%。

TURN [2] 是一个client-server协议。TURN的NAT穿透方法与 STUN 类似，都是通过取得应用层中的公有地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互，并要求TURN server产生"relay port"，也就是relayed-transport-address。这时TURN server会建立peer，即远端端点（remote endpoints），开始进行中继（relay）的动作，TURN client利用relay port将资料传送至peer，再由peer转传到另一方的TURN client。

用webrtc视频聊天方便吗？还需要什么技术？

webrtc视频聊天方便的，但不支持大规模的人员共同视频聊天，这是它的弊端，可以试试接入ZEGO即构科技的音视频 sdk，他们支持32路以上的实时音视频，闪聊、多人视频会议、在线教育等场景，技术和声誉都很好的。【点击免费试用，0成本启动】
webrtc是一个支持网络浏览器进行实时语音对话或视频对话的软件架构。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被包括进万维网联盟的W3C推荐标准。webrtc提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。
想要了解更多关于webrtc的相关信息，推荐咨询ZEGO即构科技。即构科技有限公司是为开发者提供高品质实时音视频、实时语音、互动直播和IM即时通讯等服务的公司。核心团队成员有超过20年的互联网和音视频技术开发经验，以及亿量级海内外用户运营服务能力。专注于实时音视频领域，致力提供全世界范围内最清晰稳定实时的语音视频服务，已服务4000+企业，适用于游戏、娱乐社交、在线教育、在线医疗、远程会议、智能硬件等多种用户场景。

WEBRTC基本概念

AIMD英文全称：Additive Increase Multiplicative Decrease。TCP/IP模型中webrtc，属于[运输层]webrtc，为webrtc了解决[拥塞控制]的一个方法webrtc，即：加性增，乘性减，或者叫做“和式增加，积式减少”。

  aimd controller是TCP底层的码率调节概念，但是WebRTC并没有完全照搬TCP的机制，而是设计webrtc了套自己的算法。
  如果处于Incr状态，增加码率的方式分为两种：一种是通信会话刚刚开始，相当于TCP慢启动，它会进行一个倍数增加，当前使用的码率乘以系数，系数是1.08；如果是持续在通信状态，其增加的码率值是当前码率在一个RTT时间周期所能传输的数据速率。
  如果处于Decrease状态，递减原则是:过去500ms时间窗内的最大acked bitrate乘上系数0.85,acked bitrate通过feedback反馈过来的报文序号查找本地发送列表就可以得到。
aimd根据上面的规则最终计算到的码率就是基于延迟拥塞评估到的bwe bitrate码率。

WebRTC在发送端收到来自接收端的RTCP RR报文，根据其Report Block中携带的丢包率信息，动态调整发送端码率As。

基于延迟的码率控制运行在接收端，WebRTC根据数据包到达的时间延迟，通过到达时间滤波器，估算出网络延迟m(t)，然后经过过载检测器判断当前网络的拥塞状况，最后在码率控制器根据规则计算出远端估计最大码率Ar。然后，通过RTCP REMB报文返回Ar等到发送端。

发送端综合As、Ar和预配置的上下限，计算出最终的目标码率A，该码率会作用到Encoder、RTP和PacedSender等模块，控制发送端的码率。

  GCC算法充分考虑丢包率和延迟对码率的影响，在实时通讯应用(如视频会议)中能够发挥良好效果。然而，在某些特定应用场景下(比如实时在线编辑)，GCC算法的表现不太让人满意，主要体现在它应对峰值流量的能力上，具体表现在：
1）算法一开始基于Increase状态增加码率，当检测到Decrease状态时调用Ar[t(i)] = Alpha * Rr[t(i)]，这个时候实时码率Rr(ti)可能远小于Ar[t(i-1)]，这样在后续过程中Ar处于较低水平；此时若有视频关键帧冲击，则数据包大量在PacedSender的队列中排队，造成较大排队延迟。
2）基于1）中论述的情况，码率估计模块反馈给Codec的编码码率很低，但编码器需要编码关键帧时，内部的码率控制模块控制出的最小码率仍然大于反馈码率。这两种情况都会造成较大的发送端排队延迟，进而在接收端造成较大的JitterBuffer延迟，最终导致端到端延迟到达500ms的水平，这在实时在线编辑应用中是无法容忍的。
基于此，Google官方从WebRTC M55开始引入新的码率估计算法，把所有码率计算模块都移动到发送端，并采用全新的Trendline滤波器，基于码率探测机制快速准确地估计出实时码率。

WebRTC在评估延迟差的时候不是对每个包进行估算，而是采用了包组间进行延迟评估，这符合视频传输（视频帧是需要切分成多个UDP包）的特点，也减少了频繁计算带来的误差。那么什么是包组呢？就是距包组中第一个包的发送时刻t0小于5毫秒发送的所有的包成为一组，第一个超过5毫秒的包作为下一个包组第一个包。 关于webrtc和webrtc sfu的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 webrtc的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于webrtc sfu、webrtc的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。