圖片形式
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 個主要抽象層: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*
方法傳回的承諾在 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
- 在任一網頁的標頭中加入
網路規格
在來源試用期間,草稿規格已提前開放,包括:
- 更符合 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 |
實用連結
- 其他說明文件
- 公開說明
- 追蹤錯誤
- 要求來源試用權杖
- 如何使用來源試用權杖
- 討論 RTCQuicTransport 的問題
- 討論 RTCIceTransport 的問題