WebRTC 探索

吃饱很舒服

已于 2022-12-09 00:43:09 修改

阅读量452

点赞数

分类专栏：文档资料文章标签： webrtc

于 2022-12-09 00:42:09 首次发布

本文链接：https://blog.csdn.net/honghuazu/article/details/128246023

版权

文档资料专栏收录该内容

1 篇文章 0 订阅

订阅专栏

参考链接:

WebRTC技术详解: WebRTC技术详解_hzbooks的博客-CSDN博客
音视频同步原理: WebRTC音视频同步原理与实现|可以用webrtc来做视频直播吗？ - 知乎
Licode github: GitHub - lynckia/licode: Open Source Communication Provider based on WebRTC and Cloud technologies
NAT（Network Address Translation），是指网络地址转换 -- nat（网络地址转换）_百度百科
WebRTC信令服务器原理 -- WebRTC信令服务器原理 - 知乎
红遍视频技术圈的webRTC，到底是什么？ -- 红遍视频技术圈的webRTC，到底是什么？
WEBRTC之P2P通信原理 -- 【Android音视频开发】【033】WEBRTC之P2P通信原理_命运之手的博客-CSDN博客_webrtc p2p原理

cdn, pcdn, p2p 概念 – 2684亿狂欢背后，是它在让你流畅剁手

前言

整理了下 WebRTC 的常见知识点, 记录下, 后续面试用...

背景

2010年，谷歌用6820万美刀（折合人民币4亿8千万）收购了Global IP Solutions（GIPS）公司。次年6月公布webRTC开源项目。

谷歌的意思很明确：我买了GIPS，大家随便用，不收钱。

不得不叹服，有钱就是任性。如果谷歌爸爸如果不开源GIPS的技术，坐着收专利费，1~2年即可回本，3~5年就能躺赚几个亿，大步迈入小康社会。

10年前，QQ使用的就是GIPS的语音引擎，一般这种引擎会根据客户端数目来定价，按年结算。当时QQ的用户至少也有好几亿，按照每人1元算，一年GIPS就能收到几个亿的专利费。

谷歌爸爸放着这么多钱不赚，图个啥？有句话这么说：世界上有两种人，制定规则的人和服从规则的人，而谷歌明显是想做前者。

事实证明，谷歌爸爸的确眼光独到。靠着开源webRTC，谷歌不仅成为了技术标准的制定者之一，还纷纷获得主流浏览器厂商支持。随后，webRTC被部署到数百万的终端设备中。

时间来到了2017年11月，公布webRTC开源 6 年后，W3C WebRTC 1.0 草案正式定稿。

Chrome、Firefox、Safari、Edge 等主流浏览器都已经支持 WebRTC，浏览器之间无插件化的音视频互通已经成为一种可能。

WebRTC 是什么

参考: 百度百科 WebRTC_百度百科

WebRTC (Web Real-Time Communications) 是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。WebRTC 包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下，创建点对点（Peer-to-Peer）的数据分享和电话会议成为可能。

WebRTC 可以用来干什么

音视频通信已经不仅限于社交软件的应用。webRTC普及使得教育直播、在线医疗、企业培训等垂直场景应用蓬勃发展。

2018年底，谷歌宣布Project Stream，使用串流技术在Chrome上玩《刺客信条：奥德赛》。随后，webRTC团队成员转发了这个测试页面。

可以确信的是，这个项目使用了部分webRTC的技术。这意味着什么？就是我可以拿起身边的iPad、手机，就可以在网页上面玩几千元PC才可以运行的3A大作。（比如荒野大镖客2、GTA等等）

在将来，我们可以想象一下。在基于webRTC构建的世界中，所有终端建立连接的过程是统一的，只要终端之间开放了通道，就可以建立实时通信。

比如，微信与WhatsApp能建立视频通话，就像你在中国用手机，给美国朋友家里的座机打电话。甚至你还可以用微信连接到汽车的屏幕，提前放音乐、开空调。

WebRTC 信令服务器原理

WebRTC信令服务器原理 - 知乎

首先我们先看下面蓝色的发起端和接受端，这个发起端和接受端如果想传递媒体数据的时候，它有两个信息是必须要经过信令服务器交换之后才能进行通信的，这个两个信息。第一个就是媒体信息，它是通过SDP来表述。可以简单的理解，我们双方要通信，你的编解码的器是什么，比如说我现在可以进行视频传输，我的编码是H264，那么对方也要告诉我你的编解码器能不能支持H264的码，比如我们给你传过去H264的码，你说只能解H265的，那肯定双方之间就没法通信了。所有这个信息是必须要传递的。
此外你是否支持视频是否支持音频，你们的编码方式是什么，这些信息是通过SDP给它描述出来，通过信令服务器，首先客户端要将这个SDP信息发送到服务端，服务端再中转，中转到另一端，大家已经知道了为什么要通过信令服务器进行中转，因为这个时候相互之间还没有进行连接，相互之间还不知道对方的存在。那这是第一个要传递的信息，
第二个要传递的信息是网络信息，大家知道WebRTC最终之间尽可能通过P2P进行传输，那在他们连接之前，他们如何发现对方呢？也是通过信令服务器，首先你要将所有网络相关的信息传到服务器，那么这个服务器在帮你交换到对端，那对端拿到你的信息之后，才知道我们是在同一个局域网内，那就直接通过P2P就传输好了。那如果不在同一个网络内，那我要通过P2P穿越，看看之间能不能打通，这里面又分了好几种类型，对于对称是肯定打通不了，对于非对称的那就可以尝试打通，打通之后，他们之间才能进行通信。如果打通不了，还要通过服务端进行中转。所以这个信令服务器最基础的要传输媒体相关的信息进行交换，第二个是网络相关的信息要进行交换，
再有第三个就是你的具体的业务，加入房间，离开房间，禁言，将对方禁止发言，或者给对方权限让他发言等等有很多信令，可以根据自己的业务模型去设置。

WEBRTC之P2P通信原理

【Android音视频开发】【033】WEBRTC之P2P通信原理_命运之手的博客-CSDN博客_webrtc p2p原理

P2P通讯

上面我们提到了内网服务端口映射，这是一种NAT主动开放端口，供外部网络访问的情景

还有一种情景是P2P，即点对点通讯，这种业务是无法事先预知的，所以NAT不可能提前就为每台主机开好端口

当NAT没有开放端口时，外部网络是无法访问到内网主机的

此时就用到了一项新的技术，NAT穿透，又叫NAT打洞

NAT穿透

NAT穿透，又叫NAT打洞

顾名思义，就是NAT跳过默认的端口映射表，单独开一个渠道，供外网主机和内网主机间进行通讯

实际就是NAT设备临时添加了一条访问规则，允许特定IP特定端口的程序，通过该规则访问内网程序

访问规则的格式为，内网IP : 内网端口 - 外网IP : 外网端口

由于一个内网的主机，无法知道另外一个内网主机的IP和端口，所以还必须通过一个中转服务器来交换各自的

P2P通讯连接建立流程

两个需要通过进行通讯的内网客户端，分别将自己的外网地址注册给一个具有公网地址的中转服务器

中转服务器将两个客户端的外网地址分别告知给对方

两个客户端分别给对方发送一个UDP数据包，俗称打洞包

发送过打洞包后，两端的NAT服务，就可以分别为对方添加专用的访问规则

两端都添加了打洞规则之后，就可以通过NAT相互访问了

CDN是如何工作的

如此庞大的一个网络，是怎么实现和用户的沟通呢？

就从我们经常看的公众号文章来说，如果使用了CDN加速，一般要走这3步：

第一步

用户点击了公众号某篇文章，说：“我要看这篇文章。”

本地DNS服务器找了一下硬盘，发现没有这篇文章的缓存数据，就跟CDN说：“我这里搞不定，需要你帮忙一下。”

CDN：“收到，我跟总司令（全局负载均衡设备）说一下，稍等。”

第二步

总司令找到了副司令，即用户地区所在的中转站（区域负载均衡设备），说：“帮我查查哪些节点离这个用户最近，顺便这些服务器上有没有存这篇文章。”

第三步

很快，副司令找到了存储文章内容的服务器（缓存服务器）地址，返回给了总司令。

总司令把服务器地址给用户：“你去这个地方，找这个人看看。如果他手上没有这篇文章，他自己会找到源头，然后整理好材料给你的（向上一级缓存服务器请求内容，追溯到网站的源服务器，把内容拉到本地）。”

用户和CDN沟通的过程，就是先从CDN中查找，找不到再访问服务器，实在找不到再升级查找。

别看上面的过程有点复杂，实际上服务器响应速度是毫秒之间，我们几乎感受不到整个过程，内容就已经加载完毕了。

学习视频

音视频高级开发系统学习视频: 【免费】FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发-学习视频教程-腾讯课堂

其他

1.音画同步问题
2.之前协议有: HLS, RTMP/HTTP-FLV, 现有协议:
延迟时间: HLS: 延迟10秒, RTMP 5-10秒, UDP 3秒, RTC 1秒或更小
RCP, RTMP 延迟高, 现在使用 UDP 实现
推流: 1. H5终端, webrtc 推流, 2.OBS RTMP 推流