RTCQuicTransport 即将在您附近的源试用 (Chrome 73)

图片版本

RTCQuicTransport 是一个新的网络平台 支持使用 QUIC 与远程对等方交换任意数据的 API 协议。它适用于点对点用例,因此适用于 独立的 RTCIceTransport 通过 API 建立点对点连接, ICE。 数据会按顺序可靠地传输(请参阅下文中的相应部分) 了解有关无序和不可靠)。由于它是通用的 它可用于游戏、文件传输 媒体传输、消息传递等

为什么?

一个强大的低级别数据传输 API 可以让应用(如实时 在网络上开展新事物。您可以基于此 API 构建应用, 创建您自己的解决方案,挑战与同行一起完成的工作极限 连接到对等连接,例如,解锁自定义比特率分配旋钮。在 进一步支持编码媒体 自己的视频通信应用,具有低级别的控件。WebRTC 在 NV 上做出的努力 采用较低级别的 API,尽早尝试这种做法 价值。

为什么选择 QUIC?

QUIC 协议适合用于实时通信。构建于 具有内置加密和拥塞控制, 代码行阻止标头RTCQuicTransport提供的功能非常类似于 RTCDataChannel API,但使用 QUIC(而不是 SCTP)作为传输 协议。由于 RTCQuicTransport 是一个独立的 API,它没有 RTCPeerConnection API 的开销,其中包括实时媒体 堆栈。

如何实现?

常规 API 概览

该 API 有 3 个主要抽象:RTCIceTransportRTCQuicTransportRTCQuicStream

显示 API 架构的 RTCQuicTransport 示意图

RTCIceTransport

ICE 是一种通过互联网建立点对点连接的协议, WebRTC 所采用的语言。该对象提供了一个独立的 API 来建立 ICE 连接。它用作 QUIC 连接的数据包传输, RTCQuicTransport 会在其构造函数中获取它。

RTCQuicTransport

表示 QUIC 连接。它用于建立 QUIC 连接, 创建 QUIC 流。它还显示 QUIC 连接的相关统计信息 。

RTCQuicStream

用于从远程端读取和写入数据。数据流传输 可靠而有序。可通过同一应用创建多个直播 RTCQuicTransport,一旦数据写入流,它就会触发 发送“onquicstream”事件视频流提供了一种 区分同一 QUIC 连接上的不同数据。常见示例 在单独的数据流中发送单独的文件, 不同视频流或不同视频流中不同类型的媒体 RTCQuicStream 是轻量级的,通过 QUIC 连接进行多路复用, 不会导致其他 RTCQuicStream 的开头阻塞。

连接设置

以下是设置点对点 QUIC 连接的示例。 与 RTCPeerConnection 一样,RTCQuicTransport API 需要使用 安全信号通道来协商连接的参数; 包括其安全参数RTCIceTransport在谈判后选择 ICE 参数(ufrag 和密码)以及 RTCIceCandidate

显示 API 架构的 RTCQuicTransport 示意图

客户视角:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
  quicKey: quicTransport.getKey(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, candidate}) => {
  if (iceParams) {
    iceTransport.start(iceParams);
    quicTransport.connect();
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

服务器角度:

const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
  iceParams: iceTransport.getLocalParameters(),
});
iceTransport.onicecandidate = e => {
  if (e.candidate) {
    signalingChannel.send({candidate: e.candidate});
  }
};

// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, quicKey, candidate}) => {
  if (iceParams && quicKey) {
    iceTransport.start(iceParams);
    quicTransport.listen(quicKey);
  } else if (candidate) {
    iceTransport.addRemoteCandidate(candidate);
  }
};

数据传输

可使用 RTCQuicStream API 实现数据传输, 写作:

RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);

正在缓冲

waitFor* 方法返回的 promise 允许在以下情况下缓冲数据: JavaScript 正忙。当 读取缓冲区在接收端变满。发送端有一个写入 缓冲区,从而可以在应用背压时填充该缓冲区, 写入端还有一个 waitForWriteBufferedAmountBelow 方法,用于 允许等待缓冲区中有空间执行写入操作。详细了解 可在后续开发者页面中找到 文档

无序/不可靠

虽然 RTCQuicStream 仅支持按顺序可靠地发送数据, 不可靠/无序的交付可以通过其他方式实现。对于 无序传送,可以在单独的流中发送小块数据 因为数据不会在数据流之间排序。如果交付不可靠, 可以发送小块数据,并将完成设置为 true,然后调用 超时后的针对数据流的 reset()。超时应取决于 在丢弃数据之前需要重新传输多少次。

时间

源试用将从 Chrome 73 版本开始,并将推出 M75 及之前的版本。此后,源试用将 end 的值。根据反馈和您的兴趣,我们会进行适当的更改 然后发布该 API,继续对该 API 的新源试用,或者 停用该 API。

相关内容在哪里?

除 iOS 以外的所有平台中的 Chrome 浏览器。

还有什么?

反馈

源试用的主要目标之一是获得您的反馈。 开发者。我们感兴趣的主题:

  • 此 API 可以为您实现什么目标?
  • 与其他数据传输 API 相比,此 API 有哪些改进 (WebSocket 或 WebRTC 的 RTCDataChannel)?如何改进?
  • 性能
  • API 工效学设计

注册参加源试用

  1. 为您的源请求令牌
  2. 将令牌添加到您的网页,您可以通过两种方式在 您源中的任何网页: <ph type="x-smartling-placeholder">
      </ph>
    • 请向任意网页的标头添加 origin-trial <meta> 标记。例如: 可能如下所示: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • 如果您能配置自己的服务器,也可以在网页上提供令牌 使用 Origin-Trial HTTP 标头。生成的响应标头应 大致如下所示:Origin-Trial: TOKEN_GOES_HERE

网络规范

规范草案已移到 API 源试用阶段之前 包括:

  • 与 WHATWG 直播更相符的单向直播
  • 停用重新传输
  • (即将推出)数据报

我们希望实施完整的规范及其他内容(包括 WHATWG 直播支持),但还想先听听您的反馈!

安全

QUIC 握手中的安全性是通过使用预共享密钥来强制实施的, 建立加密的点对点 QUIC 连接。此密钥需要通过 具有机密性和完整性保证的安全带外信道。 请注意,该键将向 JavaScript 公开。

主动攻击

与 DTLS-SRTP 不同,DTLS-SRTP 只需要完整性来向证书发送信号 指纹,以信号方式表明预共享密钥需要完整性并 机密性。如果 PSK 受到攻击(例如由信号中的服务器) 主动攻击者可能会发动中间人攻击 QUIC 握手。

当前状态

步骤 状态
1. 创建铺垫消息 完成
**2a.RTCQuicTransport 规范 ** **进行中**
**2b.RTCIceTransport 规范 ** **进行中**
**3.收集反馈和在设计上反复改进** **进行中**
4. 源试用 从 Chrome 73 开始!
5. 发布 尚未开始

实用链接