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

图片版本

RTCQuicTransport 是一个新的 Web 平台 API，可让您使用 QUIC 协议与远程对等方交换任意数据。它适用于点对点用例，因此可与独立的 RTCIceTransport API 搭配使用，通过 ICE 建立点对点连接。数据会以可靠且有序的方式传输（如需详细了解无序和不可靠传输，请参阅下文中的部分）。由于它是一种通用的双向数据传输，因此可用于游戏、文件传输、媒体传输、消息传递等。

为什么？

强大的低级数据传输 API 可让应用（例如实时通信）在 Web 上执行新操作。您可以在此 API 之上构建自己的解决方案，突破点对点连接的限制，例如解锁自定义比特率分配旋钮。未来，对编码媒体的进一步支持甚至可以让您使用低级控件构建自己的视频通信应用。WebRTC 的 NV 工作旨在朝着更低级别的 API 发展，因此尽早进行实验非常有价值。

为什么选择 QUIC？

QUIC 协议非常适合实时通信。它基于 UDP 构建，具有内置加密、拥塞控制功能，并且可进行多路复用，而不会出现队头阻塞。RTCQuicTransport 提供与 RTCDataChannel API 非常类似的功能，但使用 QUIC 而不是 SCTP 作为传输协议。由于 RTCQuicTransport 是一个独立的 API，因此它没有 RTCPeerConnection API（包括实时媒体堆栈）的开销。

如何做到？

API 概览

该 API 有 3 个主要抽象：RTCIceTransport、RTCQuicTransport 和 RTCQuicStream。

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。

客户视角：

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 仅支持可靠且有序地发送数据，但可以通过其他方式实现不可靠/无序传送。对于无序传送，您可以在单独的串流中发送小块数据，因为数据在串流之间没有排序。对于不可靠的传送，可以发送小数据块，并将 finish 设置为 true，然后在超时后对流调用 reset()。超时时间应取决于在丢弃数据之前希望进行多少次重传。

时间

源试用将从 Chrome 73 版开始，并将持续到 M75 版。此后，源试用期将结束。根据反馈和兴趣，我们将做出适当的更改，然后发布该 API、继续对该 API 进行新的来源试用，或停用该 API。

相关内容在哪里？

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

还有什么？

反馈

来源测试的主要目标之一是从开发者那里收集反馈。我们对以下内容感兴趣：

• 此 API 可为您提供哪些功能？
• 与其他数据传输 API（WebSocket 或 WebRTC 的 RTCDataChannel）相比，此 API 有何改进？它可以如何改进？
• 性能
• API 工效学

注册参与源代码试用

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

Web 规范

草稿规范在源试用中已超出 API 的范围，包括：

• 与 WHATWG 串流更契合的单向串流
• 停用重传
• （即将推出）数据报

我们有意实现完整规范及其他规范（包括 WHATWG 串流支持），但希望先听取您的反馈！

安全

QUIC 握手中的安全性是通过使用预共享密钥来建立加密的点对点 QUIC 连接来强制执行的。此密钥需要通过安全的非正规渠道进行信号传递，并保证机密性和完整性。请注意，该密钥将会公开给 JavaScript。

主动攻击

与仅需要完整性来进行证书指纹信号传递的 DTLS-SRTP 不同，进行预共享密钥信号传递需要完整性和机密性。如果 PSK 遭到破解（例如，被信号通道中的服务器破解），活跃攻击者可能会对 QUIC 握手发起中间人攻击。

当前状态

实用链接

• 更多文档
• 公开说明文
• 跟踪 bug
• 请求源试用令牌
• 如何使用来源试用令牌
• 关于 RTCQuicTransport 问题的讨论
• 关于 RTCIceTransport 问题的讨论