WebRTC 及点对点网络通信机制

2019年8月31日 171次阅读 来源: Troland

原文请查阅
这里，略有删减，本文采纳
学问同享签名 4.0 国际许可协定同享，BY
Troland。

这是 JavaScript 事情道理第十八章。

概述

作甚 WebRTC ？起首，字面上已给出了关于这一手艺的大批信息，RTC 即为及时通信手艺。

WebRTC 填补了网页开辟平台中的一个重要空缺。在以往，只要诸如桌面谈天顺序如许的 P2P 手艺才可以完成及时通信而网页不可。然则 WebRTC 的涌现改变了这一状态。

WebRTC 本质上许可网页顺序竖立点对点通信，我们将会在随后的章节中举行引见。我们将议论以下主题，以便向开辟者周全引见 WebRTC 的内部组织：

  • 点对点通信
  • 防火墙和 NAT 穿透
  • 信令，会话及协定
  • WebRTC 接口

点对点通信

每一个用户的网页浏览器必需根据以下步骤以完成经由历程网页浏览器举行的点对点通信：

  • 赞同最先举行通信
  • 晓得怎样定位另一个点
  • 绕过平安和防火墙限定
  • 及时传输一切多媒体通信信息

尽人皆知，基于浏览器的点对点通信的最大应战之一即怎样定位和竖立与另一个网页浏览器举行通信的网络套接字以举行双向数据传输。我们将会战胜竖立与此种网络衔接相干的难题。

每当网页顺序须要数据或许静态资本，会直接从相应的效劳器猎取，仅此而已。然则，假如若想要经由历程直接衔接用户的浏览器来竖立点对点的视频谈天就不可以，因为别的浏览器并非一个已知的网页效劳器，所以用户不晓得须要竖立视频谈天的 IP 地点。所以，须要更多的手艺以竖立 p2p 衔接。

防火墙和 NAT 穿透

平常电脑是不会被分派一个静态大众 IP 地点的。缘由是电脑是位于防火墙和网络接见转换装备(NAT) 背面的。

一个 NAT 装备会把防火墙内的私有 IP 地点转换为一个大众 IP 地点。关于平安和有限的可用大众 IP 地点来讲，NAT 装备是必需的。这也是为何开辟者的网页顺序不可以把当前装备算作具有一个静态大众 IP 地点的缘由。

让我们来了解下 NAT 装备的事情道理。当开辟者处于一个企业网中然后加入了 WIFI，那末电脑将会被分派一个只存在于 NAT 背面的 IP 地点。假定是 172.0.23.4。但是，关于外部而言，用户的 IP 地点会是相似 164.53.27.98 如许的。那末，外部会把一切请求看做来自 164.53.27.98 而 NAT 装备会保证来自于目的用户电脑的请求的相应数据返回到相应的内部 172.0.23.4 IP 地点的电脑。这得归功于映射表。注重到除了 IP 地点，网络通信还须要通信端口。

跟着 NAT 装备介入个中，浏览器须要晓得举行通信的目的浏览器对应的机械 IP 地点。

这个就须要用到 NAT 会话穿透顺序(STUN)和 NAT 穿透中继转发效劳器。为运用 WebRTC 手艺，开辟者须要请求 STUN 效劳器以取得其大众 IP 地点。这就彷佛你的电脑请求长途效劳器，讯问长途效劳器提议查询的客户端 IP 地点。长途效劳器会返回对应的客户端 IP 地点。

假定这一历程希望顺遂，那末开辟者将会取得一个大众 IP 地点和端口，如许就可以示知别的点怎样直接和你举行通信。同理，这些点也可以请求 STUN 或 TURN 效劳器以取得大众 IP 地点然后示知其通信地点。

信令，会话和协定

前述网络信息检索历程只是更大的信令话题的一部分，在 WebRTC 中，它是基于 JavaScript 会话构建协定(JSEP)范例的。信令触及网络检索和 NAT 穿透，会话竖立及治理，通信平安，媒体功用元数据和调制及毛病处置惩罚。

为了让通信顺遂举行，节点必需肯定元数据当地媒体环境(比方分辨率和编码才能等)和网络可用的顺序主机网络地点。WebRTC 接口内里没有集成重复传输这一重要信息的信令机制。

WebRTC 范例并没有划定信令且没有在接口中完成是为了可以越发天真地运用别的手艺和协定。信令和处置惩罚信令的效劳器是由 WebRTC 顺序开辟者掌握的。

假定开辟者基于浏览器的 WebRTC 顺序运用之前所说的 STUN 效劳器猎取其大众 IP 地点，那末，下一步即和别的点举行协商和竖立网络会话衔接。

运用恣意一个特地运用于多媒体通信的信令/通信协定初始化会话协商和通信衔接。该协定担任治理会话和中缀的划定规矩。

会话初始协定(SIP) 是协定之一。多亏了 WebRTC 信令的天真性，SIP 并非唯一可供运用的信令协定。所选的通信协定必需和被称为会话形貌协定(SDP)的运用层协定兼容，SDP 被运用于 WebRTC。一切的多媒体指定元数据都是经由历程 SDP 协定举行数据传输的。

恣意试图和别的点举行通信的点(比方 WebRTC 顺序)都邑天生交互式衔接竖立协定(ICE)候全集。候全集示意一个可供运用的 IP 地点，端口及传输协定的鸠合。注重，一台电脑可以具有多个网络接口(有线和无线等)，因而可以具有多个 IP 地点，每一个接口分派一个 IP 地点。

以下为 MDN 上描写这一通信交流的图示：

《WebRTC 及点对点网络通信机制》

竖立衔接

每一个节点起首猎取之前所说的大众 IP 地点。以后动态竖立「信道」信令数据来检索别的节点而且支撑点对点协商及竖立会话。

这些「信道」不可以被外部检索和接见到且只能经由历程唯一标识符来接见。

须要注重的是因为 WebRTC 的天真性且事实上信令竖立顺序并没有在范例中指定，运用的手艺差别，「信道」的观点和运用会有些许异同。事实上，一些协定并不请求「通道」机制来举行通信。

本篇文章将会假定存在「信道」。

一旦两个或许更多的点衔接到雷同的「信道」上，节点就可以举行通信和协商会话信息。这一历程和宣布/定阅形式有些许相似。大体上，初始点运用诸如会话初始协定(SIP)和 SDP 的信号协定发出一个「offer」的包。提议者守候衔接到指定「通道」的吸收者的「answer」应对。

一旦吸收到应对，会最先挑选和协商由各个节点天生的最优交互衔接竖立谐和候选(ICE)集。一旦选定了最优 ICE 候全集，特别是确认了一切节点通信所请求的元数据，网络路由(IP 地点和端口)及媒体信息。如许就会完整竖立及激活节点间的网络套接字会话。紧接着，每一个节点竖立当地数据流和数据通道端点，然后，末了运用恣意双向通信手艺来传输多媒体数据。

假如确认最优 ICE 候选的历程失利了，如许的状况常常发作于运用的防火墙和 NAT 手艺，后备运用 TURN 效劳器作为中继转发效劳器。这一历程主如果运用一台效劳器作为中心序言，然后在节点间转发传输数据。请注重这不是真正的点对点通信，因为真正的点对点通信是节点之间直接举行双向数据传输。

每当运用 TURN 作为后备通信的时刻，每一个节点将没必要晓得怎样衔接并传输数据给对方节点。相反，节点只须要晓得在会话通信时期及时发送和吸收多媒体数据的大众 TURN 效劳器。

须要重点明白的是这仅仅只是一个失利庇护和末了手腕。TURN 效劳器须要相称硬朗，具有高贵带宽和壮大的处置惩罚才能及处置惩罚潜伏的大批数据。因而，运用 TURN 效劳器会显著增加分外的开支和庞杂度。

WebRTC 接口

WebRTC 中包含三种重要接口：

  • 媒体捕获和流－许可开辟者接见诸如麦克风和网络摄像机的输入装备。该接口许可开辟者猎取麦克风或许网络摄像机媒体流。
  • RTCPeerConnection－开辟者及时传输猎取的视频和音频流到另一个 WebRTC 端点。开辟者运用这些接口衔接当地机械和长途节点。该接口供应竖立到长途节点的衔接，保护和看管衔接及封闭不再活泼的衔接的要领。
  • RTCDataChannel－该接口许可开辟者传输恣意数据。每一个数据通道都和 RTCPeerConnection 有关。

我们将离别引见这三类接口。

媒体捕获和流

媒体捕获和流接口常常被称为媒体流接口或许流接口，该接口支撑音频或许视频数据流数据，处置惩罚音视频流的要领，与数据范例相干的束缚，异步猎取数据时的胜利和毛病回调及 API 挪用历程当中触发的事宜。

MediaDevices 的 getUserMedia() 要领提醒用户受权许可运用媒体输入装备，竖立一个包含指定媒体范例轨道的媒体流。该媒体流，可包含诸如视频轨道(由诸如摄像机，视频录制装备，屏幕同享效劳等硬件或许假造视频源所竖立)，音频轨道(与视频相似，由诸如麦克风，A/D 转换器等的物理或许假造音频源所竖立)且有多是别的范例轨道。

该要领返回一个 Promise 并剖析为 MediaStream 对象。当用户谢绝受权或许没有可用的婚配媒体资本，promise 会离别返回 PermissionDeniedError 或许 NotFoundError。

可以经由历程 navigator 对象接见 MediaDevice 单例：

navigator.mediaDevices.getUserMedia(constraints)
.then(function(stream) {
 /* 运用流 */
})
.catch(function(err) {
 /* 处置惩罚毛病 */
});

注重这里须要传入 constraints 对象以指定返回的媒体流范例。开辟者可以举行种种设置，包含运用的摄像头(前置或后置)，帧频次，分辨率等等。

从版本 25 起，基于 Chromium 的浏览器已许可经由历程 getUserMedia() 猎取的音频数据赋值给音频或许视频元素(但须要注重的是媒体元素默认值为空)。

可以把 getUserMedia作为网页音频接口的输入节点：

function gotStream(stream) {
    window.AudioContext = window.AudioContext || window.webkitAudioContext;
    var audioContext = new AudioContext();
    // 从流竖立音频节点
    var mediaStreamSource = audioContext.createMediaStreamSource(stream);
    // 把它和目的节点举行衔接让本身聆听或由别的节点处置惩罚
    mediaStreamSource.connect(audioContext.destination);
}

navigator.getUserMedia({audio:true}, gotStream);

隐私限定

因为该接口可以致使显著的隐私题目，范例在关照用户和权限治理方面临 getUserMedia() 要领有异常明白的划定。在翻开诸如用户网页摄像头或许麦克风的媒体输入装备的时刻getUserMedia() 必需老是猎取用户的受权。

浏览器可以供应每一个域名受权一次的权限功用，但必需最少第一次讯问受权，然后用户必需指定受权的权限。

关照中的划定规矩一样重要。除了可以存在别的硬件指示器，浏览器还必需显现一个窗口显现运用中的摄像头或许麦克风。纵然当时装备没有举行录制，浏览器必需显现一个提醒窗口提醒已受权运用哪一个装备作为输入装备。

RTCPeerConnection

RTCPeerConnection 示意一个当地电脑和长途节点之间的 WebRTC 衔接。它供应了衔接长途节点，保护和看管衔接及封闭不再活泼的衔接的要领。

以下为一张 WebRTC 图表展现 了 RTCPeerConnection 的角色：

《WebRTC 及点对点网络通信机制》

从 JavaScript 方面看 ，图中须要明白的重要方面即 RTCPeerConnection 把庞杂的底层内部结构的庞杂度笼统为一个接口给开辟者。WebRTC 所运用的编码和协定为纵然在不稳定的网络环境下依然可以竖立一个尽量及时的通信而做了大批的事情：

  • 包丧失恢复
  • 覆信消弭
  • 网络自适应
  • 视频发抖缓冲
  • 自动增益掌握
  • 噪声削减和压抑
  • 图象「洁净」

RTCDataChannel

不仅仅是音视频，WebRTC 还支撑及时传输别的范例的数据。

RTCDataChannel 接口许可点对点交流恣意数据。

该接口有很多用处，包含：

  • 游戏
  • 及时文本谈天
  • 文件传输
  • 分布式网络

该接口有几项功用，充分利用 RTCPeerConnection 并竖立壮大和天真的点对点通信：

  • 运用RTCPeerConnection 竖立会话
  • 包含优先级的多个并发通道
  • 牢靠和不牢靠音讯通报语义
  • 内置平安(DTLS)和音讯梗塞掌握

语法和已有的 WebSocket 相似，包含有 send() 要领和 message 事宜：

var peerConnection = new webkitRTCPeerConnection(servers,
    {optional: [{RtpDataChannels: true}]}
);

peerConnection.ondatachannel = function(event) {
    receiveChannel = event.channel;
    receiveChannel.onmessage = function(event){
        document.querySelector("#receiver").innerHTML = event.data;
    };
};

sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false});

document.querySelector("button#send").onclick = function (){
    var data = document.querySelector("textarea#send").value;
    sendChannel.send(data);
};

因为通信是直接在浏览器之间举行的，所以 RTCDataChannel 会比 WebSocket 更快纵然是运用中继转发效劳器(TURN)。

WebRTC 现实运用

在现实运用中，WebRTC 须要效劳器，但这很简单，因而会发作以下步骤：

  • 用户各自检索节点然后交流诸如名字的概况。
  • WebRTC 客户端顺序(点)交流网络信息。
  • 点交流诸如视频格式和分辨率的媒体信息。
  • WebRTC 客户端顺序穿透 NAT 网关 和防火墙。

换句话说，WebRTC 须要四种范例的效劳端功用：

  • 用户检索和通信
  • 发信号
  • NAT/防火墙穿透
  • 中继转发效劳器以防点对点通信失利

ICE 运用 STUN 协定及其扩大 TURN 协定来竖立 RTCPeerConnection 衔接来处置惩罚 NAT 穿透和别的网络变化。

如前所述，ICE 是用来衔接诸如两个视频谈天客户的节点协定。一最先，ICE 会试图运用最低的可以的网络耽误即运用 UDP 来直接衔接节点。在这一历程当中，STUN 效劳器只要一个使命:让位于 NAT 以后的节点可以找到其大众地点和端口。开辟者可以检察一下可用的 STUN 效劳器(Google 也有一堆) 名单。

《WebRTC 及点对点网络通信机制》

检索衔接候选

若 UDP 失利，ICE 尝试 TCP，先 HTTP 后 HTTPS。假如直接衔接失利-特别状况下，因为企业 NAT 穿透和防火墙-ICE 运用中心(转发) TURN 效劳器。换句话说，ICE 起首经由历程 UDP 运用 STUN 效劳器来直接衔接节点，若失利则后备运用 TURN 中继转发效劳器。「检索衔接候选者」指的是检索网络接口和端口的历程。

《WebRTC 及点对点网络通信机制》

平安性

及时通信顺序或许插件可以形成几种平安题目。比方：

  • 未加密媒体或许数据有可以会在浏览器之间或许浏览器和效劳器之间被盗取。
  • 顺序有可以在未经用户受权赞同的状况下纪录和分发音视频。
  • 可疑软件或许病毒有可以会跟着表面上无害的插件或许顺序一同装置。

WebRTC 有几种要领用来处理如上题目：

  • WebRTC 完成运用诸如 DTLS 和 SRTP 的平安协定。
  • 包含信令机制在内的一切 WebRTC 组件都是强迫加密的。
  • WebRTC 不是一个插件：其组件运转于浏览器沙箱当中且不是在一个零丁的历程当中，不须要零丁装置组件且跟着浏览器晋级而更新。
  • 摄像头和麦克风必需显式受姑且当摄像头或许麦克风运转时，必需在用户窗口中有所显现。

关于须要完成一些浏览器之间及时通信流功用的产物而言，WebRTC 是一个令人难以置信和壮大的手艺。

参考资料：

    原文作者：Troland
    原文地址: https://segmentfault.com/a/1190000018351375
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞