使用 WebRTC 数据通道在浏览器之间发送数据

在两个浏览器之间发送数据以进行通信、游戏或文件传输可能是一个相当复杂的过程。 它需要设置服务器并支付费用来中继数据，并可能将其扩展到多个数据中心。 在这种情况下，可能会出现高延迟，并且很难将数据保密。

这些问题可以通过使用 WebRTC 来缓解 RTCDataChannel用于将数据直接从一个对等点传输到另一个对等点的 API。 本文介绍了如何设置和使用数据通道的基础知识，以及当今网络上的常见用例。

要充分利用本文，您需要了解 RTCPeerConnection API，以及对 STUN、TURN 和信号如何工作的理解。 有关更多信息，请参阅 WebRTC 入门 (link:https://www.html5rocks.com/en/tutorials/webrtc/basics/)。

为什么是另一个数据通道？

我们有 WebSocket (link:https://www.html5rocks.com/en/tutorials/websockets/basics/)、 AJAX (link:https://www.html5rocks.com/en/tutorials/file/xhr2/)和 服务器发送事件 (link:https://www.html5rocks.com/en/tutorials/eventsource/basics/)。 为什么我们需要另一个沟通渠道？ WebSocket 是双向的，但所有这些技术都是为与服务器之间的通信而设计的。

RTCDataChannel 采取不同的方法：

• 它与 RTCPeerConnection API，支持点对点连接。 这可以降低延迟——没有中间服务器和更少的“跃点”。
• RTCDataChannel 使用 流控制传输协议 (link:https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)(SCTP)，允许可配置的交付语义——乱序交付和重传配置。

RTCDataChannel 现已在 Google Chrome、Opera 和 Firefox 的桌面和 Android 上提供 SCTP 支持。

警告：信令、STUN 和 TURN

WebRTC 支持点对点通信，但它仍然需要服务器用于 信令 交换媒体和网络元数据以引导对等连接。 WebRTC 处理 NAT 和防火墙：

• ICE 框架 (link:https://www.html5rocks.com/en/tutorials/webrtc/basics/#ice)，用于在对等点之间建立可能的最佳网络路径。
• STUN 服务器 (link:https://www.html5rocks.com/en/tutorials/webrtc/basics/#stun)确定每个对等点的可公开访问的 IP 和端口
• TURN 服务器 (link:https://webrtc.org/getting-started/turn-server)如果直接连接失败并且需要数据中继，则有关 WebRTC 如何与服务器一起用于信令和网络的更多信息，请参阅 现实世界中的 WebRTC：STUN、TURN 和信令 (link:https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/)。

能力

这 RTCDataChannel API 支持一组灵活的数据类型。 该 API 旨在完全模仿 WebSocket，并且 RTCDataChannel 支持 字符串 (link:https://www.w3.org/TR/webrtc/" title="W3C DOMString 规范)以及 JavaScript 中的一些二进制类型，例如 Blob (link:https://www.w3.org/TR/webrtc/" title="W3C Blob 规范)、 ArrayBuffer (link:https://www.w3.org/TR/webrtc/" title="W3C ArrayBuffer 规范)和 ArrayBufferView (link:https://www.w3.org/TR/webrtc/" title="W3C ArrayBufferView 规范)。 这些类型在处理文件传输和多人游戏时会很有帮助。

RTCDataChannel 可以工作在不可靠和无序模式（类似于用户数据报协议或UDP）、可靠和有序模式（类似于传输控制协议或TCP）和部分可靠模式：

• 可靠有序的模式保证了消息的传输，也保证了消息的传递顺序 。 这需要额外的开销，因此可能会使此模式变慢。
• 不可靠和无序模式不能保证每条消息都到达另一端，也不保证它们到达那里的顺序 。 这消除了开销，使这种模式工作得更快。
• 部分可靠模式保证消息在特定条件下的传输，例如重传超时或最大重传次数 。 消息的顺序也是可配置的。

在没有丢包的情况下，前两种模式的性能大致相同。 但是，在可靠和有序模式下，丢失的数据包会导致其他数据包在其后面被阻塞，并且丢失的数据包在重新传输并到达时可能已经过时。 当然，可以在同一个应用程序中使用多个数据通道，每个通道都有自己的可靠或不可靠语义。

提供的有用表格 High Performance Browser Networking (link:https://www.oreilly.com/library/view/high-performance-browser/9781449344757/)是 Ilya Grigorik (link:https://www.igvita.com/" title="Ilya Grigorik 的网站)：

接下来，您将学习如何配置 RTCDataChannel 使用可靠有序或不可靠无序模式。

配置数据通道

有几个简单的demo RTCDataChannel 在线的：

• simpl.info RTCDataChannel(link:https://simpl.info/dc)
• WebRTC 示例 传输文本(link:https://webrtc.github.io/samples/src/content/datachannel/basic/)
• WebRTC 示例 传输文件(link:https://webrtc.github.io/samples/src/content/datachannel/filetransfer/)

在这些示例中，浏览器与自身建立对等连接，然后创建数据通道并通过对等连接发送消息。 然后它正在创建一个数据通道并沿着对等连接发送消息。 最后，您的消息出现在页面另一侧的框中！

开始使用的代码很短：

const peerConnection = new RTCPeerConnection();

 // 在此处使用您的信号通道建立您的对等连接
 常量数据通道 =
   peerConnection.createDataChannel("myLabel", dataChannelOptions);

 dataChannel.onerror =（错误）=> {
   console.log("数据通道错误：", error);
 };

 dataChannel.onmessage = (事件) => {
   console.log("得到数据通道消息：", event.data);
 };

 dataChannel.onopen = () => {
   dataChannel.send("Hello World!");
 };

 dataChannel.onclose = () => {
   console.log("数据通道关闭");
 };
 

这 dataChannel对象是从已经建立的对等连接创建的。 它可以在信号发生之前或之后创建。 然后，您传入一个标签以将此通道与其他通道和一组可选配置设置区分开来：

常量 dataChannelOptions = {
   ordered: false, // 不保证顺序
   maxPacketLifeTime: 3000, // 以毫秒为单位
 };
 

也可以添加一个 maxRetransmits 选项（失败前尝试的次数），但您只能指定 maxRetransmits 或 maxPacketLifeTime，不能同时指定两者。 对于 UDP 语义，设置 maxRetransmits至 0 和 ordered 至 false，有关详细信息，请参阅这些 IETF RFC： 流控制传输协议 (link:https://tools.ietf.org/html/rfc4960" title="IETF RFC 4960)和 流控制传输协议部分可靠性扩展 (link:https://tools.ietf.org/html/rfc3758" title="IETF RFC 3758)。

• ordered: 数据通道是否保证有序
• maxPacketLifeTime：尝试重传失败消息的最长时间
• maxRetransmits：尝试重传失败消息的最大次数
• protocol：允许使用子协议，它向应用程序提供元信息
• negotiated: 如果设置为 true，则取消在另一端自动设置数据通道，提供您自己的方式在另一端创建具有相同 ID 的数据通道
• id：允许您为频道提供自己的 ID，该 ID 只能与 negotiated调成 true)

大多数人需要使用的唯一选项是前三个： ordered，maxPacketLifeTime 和 maxRetransmits。使用 SCTP (link:https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol" title="维基百科关于 SCTP 的文章)（现在被所有支持 WebRTC 的浏览器使用）可靠和有序是默认的。 如果你想从应用层完全控制，使用不可靠和无序是有意义的，但在大多数情况下，部分可靠性是有帮助的。

请注意，与 WebSocket 一样， RTCDataChannel 当连接建立、关闭或错误，以及从其他对等方接收到消息时触发事件。

安全吗？

所有 WebRTC 组件都必须加密。 和 RTCDataChannel，所有数据都使用 数据报传输层安全 (link:https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security" title="维基百科关于 DTLS 的文章)(DTLS) 进行保护。 DTLS 是 SSL 的衍生产品，这意味着您的数据将与使用任何基于 SSL 的标准连接一样安全。 DTLS 已标准化并内置于所有支持 WebRTC 的浏览器中。 有关详细信息，请参阅 Wireshark 维基 (link:https://wiki.wireshark.org/DTLS)。

改变你对数据的看法

处理大量数据可能是 JavaScript 的痛点。 正如 Sharefest (link:https://github.com/Peer5/ShareFest)指出的，这需要以一种新的方式来思考数据。 如果您要传输的文件大于可用内存量，则必须考虑保存此信息的新方法。 这就是 FileSystem API (link:https://www.html5rocks.com/en/tutorials/file/filesystem/)发挥作用的地方，如下所示。

构建文件共享应用程序

现在可以通过以下方式创建可以在浏览器中共享文件的 Web 应用程序 RTCDataChannel。建在上面 RTCDataChannel 意味着传输的文件数据是加密的，不会触及应用提供商的服务器。 此功能与连接到多个客户端以实现更快共享的可能性相结合，使 WebRTC 文件共享成为网络的有力候选者。

成功传输需要几个步骤：

• 1. 在 JavaScript 中读取文件 (link:https://www.html5rocks.com/en/tutorials/file/dndfiles/)File API (link:https://www.html5rocks.com/en/tutorials/file/dndfiles/)。
  2. 在客户端之间建立对等连接 RTCPeerConnection。
  3. 在客户端之间创建数据通道 RTCDataChannel。

尝试通过以下方式发送文件时需要考虑几点 RTCDataChannel：

• 文件大小： 如果文件大小相当小并且可以作为一个 Blob 存储和加载，则可以使用 File API 加载到内存中，然后通过可靠的通道按原样发送文件（但请记住，浏览器对最大值施加了限制传输大小）。 随着文件大小变大，事情变得越来越棘手。 当需要分块机制时，文件块被加载并发送到另一个对等点，伴随着 chunkID元数据，以便对等方可以识别它们。 请注意，在这种情况下，您还需要先将块保存到离线存储（例如，使用 FileSystem API），然后仅当您拥有完整的文件时才将其保存到用户的磁盘。
• 块大小： 这些是应用程序中最小的数据“原子”。 需要分块，因为当前存在发送大小限制（尽管这将在未来版本的数据通道中修复）。 当前最大块大小的建议是 64KiB。

一旦文件完全传输到另一端，就可以使用锚标签下载：

函数保存文件（blob）{
   常量链接 = document.createElement('a');
   link.href = window.URL.createObjectURL(blob);
   link.download = '文件名';
   链接.click();
 };
 

上的这些文件共享应用程序 PubShare (link:https://pubnub.github.io/rtc-pubnub-fileshare/)和 GitHub (link:https://github.com/Peer5/ShareFest)使用这种技术。 它们都是开源的，并且为基于 RTCDataChannel。

所以，你可以做什么？

RTCDataChannel 为构建文件共享、多人游戏和内容交付应用程序的新方法打开了大门。

• 如前所述的对等文件共享
• 多人游戏，与其他技术（如 WebGL）配对，如 Mozilla 的 BananaBread 所示(link:https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/)
• 内容交付被 PeerCDN (link:https://techcrunch.com/2013/12/17/yahoo-acquires-peercdn/)，这是一个通过对等数据通信交付 Web 资产的框架

改变构建应用程序的方式

您现在可以通过使用高性能、低延迟的连接来提供更具吸引力的应用程序 RTCDataChannel，等框架 PeerJS (link:https://peerjs.com/)和 PubNub WebRTC SDK (link:https://github.com/pubnub/webrtc)使 RTCDataChannel 更容易实现，并且 API 现在已广泛支持跨平台。

的出现 RTCDataChannel 可以改变您对浏览器中数据传输的看法。

Find out more

• Getting started with WebRTC(link:https://www.html5rocks.com/en/tutorials/webrtc/basics/)
• WebRTC in the real world: STUN, TURN, and signaling(link:https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/)
• WebRTC and Web Audio resources(link:https://bit.ly/webrtcwebaudio)
• Peer-to-peer Data API(link:https://www.w3.org/TR/webrtc/)
• IETF WebRTC DCP Draft(link:https://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-04)
• How to send a File Using WebRTC Data API(link:https://bloggeek.me/send-file-webrtc-data-api/)
• 7 Creative Uses of WebRTC’s Data Channel(link:https://bloggeek.me/webrtc-data-channel-uses/)
• BananaBread(link:https://developer.mozilla.org/en/demos/detail/bananabread)