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基本概念
AIMD英文全称：Additive Increase Multiplicative Decrease。TCP/IP模型中，属于[运输层]，为了解决[拥塞控制]的一个方法，即：加性增，乘性减，或者叫做“和式增加，积式减少”。
aimd controller是TCP底层的码率调节概念，但是WebRTC并没有完全照搬TCP的机制，而是设计了套自己的算法。
如果处于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（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是网页即时通信的缩写，该程序可以允许用户在网页中进行实时语音通话以及视频通话，如果按照专业的介绍来说，WebRTC是一个音视频处理+即时通讯的开源库。
WebRTC的特点：开源的框架非常大，可以跨平台使用，也可以在浏览器中使用，传输具有时效性以及可以进行音频和视频通话。
WebRTC可以应用的场景：音视频会议、在线教育、照相机、音乐播放器、共享远程桌面、录制、即时通讯工具、P2P网络加速、文件传输工具、游戏以及实时人脸识别。
电脑使用技巧：电脑存放时需要注意的事项：1.关机前笔记本电池应当充满电，关机后取下电源适配器和电池，并分别存放，防止电池两电极短路发热起火，同时也要远离有火源的地方。
2、可以使用塑料密封袋包装，有干燥剂最好放进去，放置于干燥的地方保存。
3、存放时需要单独放置，不能在电脑上方放置其它物品，特别是比较重的物品，放置比较重的物品有可能会损坏电脑屏幕。
