RTCQuicTransport 即將在您附近的來源試用計畫 (Chrome 73)

什麼？

RTCQuicTransport 是新的網路平台 API，可讓您使用 QUIC 通訊協定與遠端對等端交換任意資料。這項 API 適用於點對點用途，因此會與獨立的 RTCIceTransport API 搭配使用，透過 ICE 建立點對點連線。資料會以可靠且有序的方式傳送 (如要進一步瞭解未排序和不可靠的傳送方式，請參閱下方章節)。由於這是一般性的雙向資料傳輸，因此可用於遊戲、檔案傳輸、媒體傳輸、訊息傳送等。

為什麼？

功能強大的低階資料傳輸 API 可讓應用程式 (例如即時通訊) 在網路上執行新功能。您可以運用 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 與其他資料傳輸 API (WebSocket 或 WebRTC 的 RTCDataChannel) 相比有何優勢？如何改善？
• 成效
• API 人因工程

註冊參加來源試用

1. 為來源要求權杖。
2. 將符記新增至網頁，您可以在來源的任何網頁上提供這項符記，方法有兩種：
   • 將 origin-trial <meta> 標記加入任一網頁的標頭。例如： <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
   • 如果你能設定伺服器，也可以使用 Origin-Trial HTTP 標頭在網頁上提供符記。產生的回應標頭應如下所示：Origin-Trial: TOKEN_GOES_HERE

網路規格

在來源試用中，規格草案已超前 API，包括：

• 與 WHATWG 串流更為一致的單向串流
• 停用重傳
• (即將推出) 資料包

我們很樂意實作完整規格和其他內容 (包括 WHATWG 串流支援)，但希望先聽聽你的意見！

安全性

系統會使用預先共用金鑰建立加密的 P2P QUIC 連線，藉此確保 QUIC 握手的安全性。這個金鑰必須透過安全的非頻道管道傳送信號，並提供保密性和完整性保證。請注意，系統會將鍵公開給 JavaScript。

進行中的攻擊

與 DTLS-SRTP 不同，後者只需要完整性來傳送憑證指紋，但傳送預先共用金鑰時，則需要完整性和機密性。如果 PSK 遭到入侵 (例如信號通道中的伺服器)，積極的攻擊者可能會對 QUIC 握手程序發動中間人攻擊。

目前狀態

實用連結

• 其他說明文件
• 公開說明
• 追蹤錯誤
• 要求來源試用權杖
• 如何使用原始試用權杖
• 討論 RTCQuicTransport 的問題
• 討論 RTCIceTransport 的問題