WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。
首先，他就是API也是协议。
其次，他是 浏览器进行音频与视频通话的API，其实还有屏幕***享的功能。
最后，它现在已经成为W3C标准，两大浏览器厂商已经对他进行了兼容了。< /p>
但是如果我们想使用好webrtc，就得先了解websocket。而对于websocket，大家应该都比较熟悉了，比如社交聊天、多人游戏、和谐编辑、视频会议、基于位置的应用( 地图）、等等需要高实时的场景。我们比较常用的微信、QQ、某些直播软件等等也都是基于websocket实现消息与信令的转发。大家看到这里可能在信令这里迟疑了，
webrtc 是 P2P 的一种技术，什么是 P2P？ 其实就是端对端，就说是你的音频、视频流不经过服务器中转，直接由尾部发送到另一端。
没有经过服务器中转，那么说的时候，如果经过中服务器突然崩溃，是不是通话还能继续？
是的！但是发送音频视频流前，一定 是需要建立P2P连接的，建立连接之前一定需要服务器进行信令转发，这个信令就是通话端点的标识。
而如果想用webrtc实现通话，就得先中转信令、建立 连接。而建立连接的话最好是用websocket进行信令转发的。大家都知道，websocket是一个通道，在这个通道的所有端，都可以收到任何后续的消息流，包括发消息的身份。< /p>
为什么不经过服务器就可以直接获取到对方的视频音频流呢？是因为建立了P2P通道，这个P2P在中转信令的时候就已经通了，传输视频音频流的时候还要 啥服务器啊。这个时候，肯定有小伙伴表示怀疑，音频视频流不通过服务器？是的，我骗了大家，确实要经过服务器，但是只是线上需要服务器转发，如果我们是本地或者是缺少服务器 多台同一局域网的端进行webrtc音频视频流的转发，确实不需要中转服务器，但是线上有可能需要，也可能不需要，这里又涉及到了一个打洞的概念。
我们 平时可能会听到比较??牛x的词汇，什么打洞、内网窥视、NAT浏览，各种高大上的东西，其实也是蛮好理解的。大家都知道，两个不同网络下的相似主机 不可以直接进行通信，而是需要走公网或者说各自的网关。打洞、内网检查、NAT穿越其实就是一个意思，就是利用udp让我们不像同一网络的主机互联，不走公网 网，直接实现连接。有玩过花生壳的同学一定能理解内网这个概念。
本地开发的话，主机连接同一主机，根本不需要内网，就这样 可以直接通信。
线上开发的话，如果能够STUN打洞成功，也不需要中转服务器。但是，有打洞不成功的概率，为什么呢，因为没有走公网，没有给 所以运营商带来收益的同时也带来了通信成本，肯定要限制。国外打洞成功的概率在70%，但国内50%都没有到。
成功，为了防止打洞不成功的情况 ，我们利用TURN中转服务器转发流媒体数据进行最后一个。
另外还有一种方式为逆向连接，也可以帮助我们实现P2P建立，他的原理是必须是一对走公网，也是有局限性的。
coturn 中继服务器由两部分组成 STUN 与 TURN，STUN 帮助我们打洞，TURN 帮助我们转发流媒体数据。
##连接过程
以下所有 API 源到 2021.12.06 为最新
< p> ##我有疑问给大家看看sdp的本质，就是自身的媒体信息和编解码信息
一个提议，一个答案，我们到处都知道对方的 媒体信息与编解码信息，这样我们就要好好商量，我布拉格该用什么方式对你的视频音频流进行解码、渲染。
过程有些繁杂，具体流程小伙伴们可以看一下这 篇文章WebRTC TURN协议初识及turnserver实践。
了解webrtc的音视频采集、桌面采集；
了解websocket和webrtc的整个仓库建立流程；
实现1V1文字传输、视频通话、语音通话、屏幕***共享；
实现视频通话、语音通话、屏幕***共享过程中的截图、录音、录屏及截图 、录音、录屏的在线播放与下载；
将以上功能部署上线；
在这里，我们要对音频视频建立过程画一个基本的流程图。 p>
基本流程图
对于这些信令，我们使用websocket进行转发，这里大家会问，为什么不使用http？
首先，我们要实现的 demo本来就带有发送普通文本消息的功能，就是使用websocket。(长短轮询太老了，性能太差)
其次，第一点可以忽略，http的请求会打回原路 ，A 向服务器请求，绝对不会传向 B。
但是如果我们要使用 websocket 转发信令，就要搞清楚的了解，在同一管道的所有端都会收到一条消息。 ，对于上面流程图来说，其实所有的小箭头都是肢体的。
这个时候，我们可以在节点服务中来控制自适应消息的方向，也可以在客户端来控制，这里 我选择在AB端来控制。
其次，在我们本地开发时，如果使用一台电脑，两个浏览器的形式，websocket文字消息是可以的。但是音视频通话不行，因为不管怎样 是传输通道还是音频视频设备（麦克、扬声器等）都是冲突的。所以，我们可以通过相同的分数，使用有限的电脑解决这个问题。而且，因为webrtc的安全限制，必须使用https（无论是线上） 还是本地）与域名，我们可以通过线上配置https与域名，本地设置浏览器忽略https与配置主机文件映射来解决这个问题。
接下来，我们使用vue和nodejs，可以最 快最简单的实现demo。
废话少说，撕我们！
展示部分代码
这里我使用socket.io这个第三方包， 快速的基础消息，转发信令。（建议大家使用vue-socket.io）可以在组件中收发消息与信令。
将socket-io的websocket建立连接与接收消息，接收信 令放到 vuex 中。
同样，我们在节点服务中，也使用socket-io这个包
对于视频、音频、及屏幕***来说共享，代码都是类似的。 ，举例视频采集。
通过使用getUserMedia，还是我们可以采集到音频视频双轨的媒体流，我们确定一个参数约束，这个参数可以配置（控制采集音频视频）
< p> 将采集到的动态媒体流属性给视频标签，我们自己的画面就显示在网页上。同样，如果音频采集，只需要配置参数约束中的音频为 false 即刻 可以。
电脑屏幕采集，只需要把 getUserMedia 这个 API 替换为 getDisplayMedia 即可。
此时视频端发起端，采集到了媒体流后，发送 apply 信令 给接收端。该信令是询问接收端是否接起视频通话。
如果接起，接收端会采集自己的音视频双轨的媒体流，并初始化对等连接，将媒体流入口 这里，管道监听ICE候选信息如果收集到，就发送给对方，把自己的同意信令回复，回复给视频发起端。
拒绝如果接起，接收端会回复一个拒绝的 信令给视频发起端。
接收端此时接收拒绝，会关闭视频音频流的采集。
接收端此时接收接起，会初始化对等连接， 把自己的媒体流放入这个管道，监听ICE候选信息，如果收集到，就发送给对方。并创建一个offer(此offer包含sdp)，将offer放到本地后，发送offer给接收视频端。< /p>
视频接收端接收到offer，放置自己的远端，并创建一个answer，将answer放置到本地后，发送给视频发起方。
视频接收端接收到
同时，接收和发起端都在监听ICE候选信息，如果收集到，就发送给对方。一但监听到了就将对方的动态媒体流属性 给B，播放出来。
截图：我们可以利用canvas利用相关方法 getContext("2d").drawImage ，实现web层面的图片截取。
录音/录像/录影 屏：使用MediaRecorder将我们的媒体流或者对方的媒体流保存到阵列中。
将保存的静态媒体流分配给视频标签
同理，可以 将音视频流下载下来。
配置webrtc重要的两个条件：域名与https，我们需要配置这两块。
我们的节点服务不仅仅是https+域名，websocket 也需要更加安全的wss协议，我们需要给我们的websocket配置wss。
在前面我们也提过，本地开发及时能够成功，并且有效果，是因为内网是直接通信 的，并没有走公网，也没有实现内网。
如果我们想要在线上实现这个功能，我们必须配置coturn中转服务器。centos内核的配置文章可以参考这篇 ，ubuntu 内核的配置参考本文。
在开发和上线后能够发现以下几个问题。
环境、设备、信号瓶颈、算法不兼容产生的噪音、声学与线路产生的回音、网络拥塞及数据包传输速率不会产生延迟。
我们可以 通过接入一些算法及提高硬件设备质量，来减少噪音回音，降低延迟。
对于噪音，采集时音频可以设置noiseSuppression: true ，可以降低环境及一些设备的噪音。
对于噪音，采集时音频可以设置noiseSuppression: true ，可以降低环境及一些设备的噪音。 >
对于回声，采集音频时可以设置 echoCancellation: true ，可以去除回声。
剩余的替换算法、设备和网络来处理了。
在这 方面的探索，我就到了这个阶段了，大家可以继续研究WebRTC传输是如何保证音频视频服务质量，研究一下成熟应用是如何解决这三大难点的。
大家在视频通话过程中 中，可以使用多种特效。美颜、贴纸等等。
然而在 webrtc 的 web 端领域，视频特效领域是非常潜的。造成这种情况的原因是 js 的性能问题。
比较简单的方法就是利用画布，对我们的视频图层添加一层滤镜，但是在本质上并没有改变媒体流。传输到最后仍然是没有效果的。当然， 我们可以通过websocket控制外部的视频效果，但是由于视频流没有改变，对方如果下载视频流的话，播放出来仍然是没有效果的。
另外一种方案如下，这里我就不多说了 做重复叙述，大家可以思考一下是如何实现的（以下为简单效果与贴纸）。
需要创建n-1个PeerConnection连接，我们因为要与n-1个人进行视频***享 ，每个人都是这样。但是这里会涉及谁主动发出offer的问题。我们可以让新加入的成员向其他n-1个成员发出offer，也可以让n-1个成员向新加入的成员发出offer 。这里我们可以用遍历的方式生成PeerConnection并提供。当然很多人平常就看你服务器顶不顶的住了。
这里我们不知情的使用了多端通信的同业通信方案—— —Mesh，Mesh就是两两种通信从而形成网状结构。除了Mesh这样的通信方案，还有MCU，MCU主要方案是同一空间的所有终端的音视频流进行混合然后发向各个终端，这样服务器的 压力确实是非常巨大的。另外还有SFU通信方案，中转服务器收到某个终端音视频流后，单一转发到其他终端。
经过上面一系列的理解、思考、构建、开发 、部署等等，我们对webrtc有了一些初步的了解和认识。对于这方面的研究与探索我们要继续继续深入下去。因为满足我们的好奇心和求知欲，提升我们这一领域的技术 ，丰富我们完整的知识体系，何乐而不为呢。
最后，以上所有内容均来源于资料、个人实验及个人总结，文中有错误的地方希望大家及时指正。< /p>