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

圖片形式

RTCQuicTransport 是新的網路平台 API,允許使用 QUIC 通訊協定與遠端對等點交換任意資料。這項功能適用於對等互連之間的用途,因此可與獨立的 RTCIceTransport API 搭配使用,透過 ICE 建立點對點連線。系統會穩定地傳輸資料 (如需瞭解未排序及不可靠的傳送作業,請參閱下方的相關章節)。由於它是通用的雙向資料傳輸,因此可用於遊戲、檔案傳輸、媒體傳輸和訊息傳遞等。

原因為何?

強大的低階資料傳輸 API 可讓應用程式 (例如即時通訊) 在網路上進行新操作。您可以在 API 的基礎上進行建構,建立自己的解決方案,提高點對點連線可執行的作業限制,例如解鎖自訂位元率配置旋鈕。日後,如果進一步支援編碼媒體,甚至還能使用低階控制項來建構自己的視訊通訊應用程式。WebRTC 的 NV 工作就是改用較低級別的 API,因此及早針對這個 API 進行測試非常重要。

為什麼要使用 QUIC?

QUIC 通訊協定最適合用於即時通訊。此程式庫是以 UDP 為基礎建構,並內建加密和壅塞控制等功能,且在沒有行阻率的情況下進行多工處理。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* 方法傳回的承諾在 JavaScript 忙碌時允許緩衝資料。當接收端的讀取緩衝區已滿時,傳送端就會套用返回壓力。傳送端具有寫入緩衝區,可在套用返回壓力後填充,因此寫入端也有 waitForWriteBufferedAmountBelow 方法,可以等候緩衝區寫入的空間。如要進一步瞭解如何寫入/讀取資料,請參閱進一步的開發人員說明文件

未排序/配送不可靠

雖然 RTCQuicStream 僅支援穩定且按順序傳送的資料,但可以透過其他方法達成不可靠/未排序的傳送作業。如果是未排序的傳送,一個可以在不同的串流中傳送小型的資料區塊,因為串流之間不會排序資料。以不可靠的傳送方式來說,一個人可以傳送結尾設為 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

網路規格

在來源試用期間,草稿規格已提前開放,包括:

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

我們想導入完整規格和更多內容 (包括 WHATWG 串流支援),但還是希望收到你的意見回饋!

安全性

系統會使用預先共用金鑰建立加密 P2P QUIC 連線,藉此強制執行 QUIC 握手的安全性。這個金鑰必須以安全外通道發出訊號,並保證提供機密性和完整性保證。請注意,金鑰將向 JavaScript 公開。

進行中的攻擊

與 DTLS-SRTP 不同,DTLS-SRTP 只需要使用完整性來傳送憑證指紋的信號,而信號預先共用金鑰需要完整性和機密性。如果 PSK 遭到入侵 (例如信號管道中的伺服器),主動攻擊者可能會針對 QUIC 握手程序掛接中間人攻擊。

目前狀態

步驟 狀態
1. 建立說明 完成
**2a. RTCQuicTransport 規格 ** **進行中**
**2b. RTC IceTransport 規格 ** **進行中**
**3. 收集意見回饋並持續改進設計** **進行中**
4. 來源試用 從 Chrome 73 開始!
5. 啟動 Not started

實用連結