本頁面由 Cloud Translation API 翻譯而成。

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

什麼？

RTCQuicTransport 是新的網路平台這個 API 允許使用 QUIC 與遠端對等節點交換任意資料因此效能相當卓越這項工具適用於點對點用途，因此用於獨立的 RTCIceTransport 透過 API 建立點對點連線 ICE。資料傳輸過程既可靠又安全 (請參閱下方的章節) 。不可靠的傳送)。由於這是通用雙向資料傳輸，可用於遊戲、檔案傳輸媒體傳輸、訊息等

為什麼？

強大的低階資料傳輸 API 可實現各種應用，例如即時功能)，為網路上的新事物帶來全新體驗。透過這個 API 建立自己的解決方案，突破共同團隊所能完成的極限以及對等互連連線，例如解鎖自訂位元率配置旋鈕。於日後還能進一步支援編碼媒體並採用低階控制措施的視訊通訊應用程式WebRTC 的 NV 成果就是改用較低層級的 API 價值。

為什麼要使用 QUIC？

QUIC 通訊協定適用於即時通訊。以頂層為建構基礎內建加密和壅塞控管機制，並且是多工處理的線路阻斷RTCQuicTransport 具備與以下功能非常相似的功能： RTCDataChannel API，但使用 QUIC 做為傳輸方式因此效能相當卓越由於 RTCQuicTransport 是獨立 API，因此沒有 RTCPeerConnection API 的負荷，包括即時媒體

做法：

一般 API 總覽

API 有 3 個主要抽象化機制：RTCIceTransport、RTCQuicTransport 和 RTCQuicStream。

顯示 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* 方法傳回的保證可在下列情況中緩衝資料 JavaScript 忙碌中。當讀取緩衝區空間變滿。傳送端出現寫入作業會在套用背壓時填滿的緩衝區，因此寫入端也有 waitForWriteBufferedAmountBelow 方法會等待緩衝區中等待資料寫入。進一步瞭解如需寫入/讀取資料說明文件。

未訂購/貨到不可靠

雖然 RTCQuicStream 只能按照順序可靠地傳送資料，也可透過其他方式達成不穩定/沒有順序的交付。適用對象非排序傳送，參與者可以在不同的串流中傳送小區塊資料因為資料不是依序在串流之間排序傳送不可靠的傳送便可傳送已完成設為 true 的小區塊資料，最後再呼叫 reset()在直播逾時後繼續透過串流功能播放內容。逾時時間應取決於有多少次重新傳輸資料。

何時？

來源試用將從 Chrome 73 版開始試用，最多包含 M75 版本此來源試用結束後，結尾。我們會根據意見回饋和興趣，進行適當調整。並推出 API，繼續進行這個 API 新來源試用，或或是停止 API

在哪裡？

所有平台 (iOS 除外) 的 Chrome 瀏覽器。

還有呢？

意見回饋

來源試用的主要目標之一是收集意見回饋、開發人員。希望加入以下行列：

這個 API 能為您帶來什麼好處？
這個 API 如何改良其他資料傳輸 API (WebSocket 或 WebRTC 的 RTCDataChannel)？如何改善？
成效
API 作業效率

註冊來源試用

針對來源要求權杖。
將權杖新增至網頁，有兩種方式可以提供此權杖來源中的任何頁面：
- 在任一網頁的標頭中加入 origin-trial <meta> 標記。例如：如下所示： <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
- 如果您能設定伺服器，也可以直接在頁面中提供權杖使用 Origin-Trial HTTP 標頭產生的回應標頭如下所示：Origin-Trial: TOKEN_GOES_HERE

網路規格

在來源試用中，草稿規格已移至 API 之前包括：

與 WHATWG 串流更相符的單向串流
停用重新傳輸
(即將推出) 資料元

我們希望您能導入完整規格，包括支援什麼，但我想先聽聽你的意見！

安全性

系統會透過使用預先共用金鑰強制執行 QUIC 握手程序的安全性，讓建立加密的 P2P QUIC 連線。這組金鑰必須經由採用機密性和完整性保證，享有跳脫框架的框架。請注意，JavaScript 會取得金鑰。

主動攻擊

DTLS-SRTP 差別在於 DTLS-SRTP 只需完整性來為憑證發出信號指紋，為預先共用金鑰發出信號時必須完整機密性。如果 PSK 遭到入侵 (比如在發出訊號中的伺服器發現) 此時活躍的攻擊者可能會掛接攔截式攻擊封鎖 QUIC 握手程序

目前狀態

步驟	狀態
1. 建立說明	完成
2a.RTCQuicTransport 規格	處理中
2b.RTCIceTransport 規格	處理中
3.收集意見回饋與針對設計反覆改進	處理中
4. 來源試用	Chrome 73 開始！
5. 啟動	尚未開始