このページは Cloud Translation API によって翻訳されました。

RTCQuicTransport のオリジントライアルがまもなく開催（Chrome 73）

概要

RTCQuicTransport は、新しいウェブプラットフォームです。 QUIC を使用してリモートピアと任意のデータを交換できる API 構成されます。ピアツーピアのユースケースを想定しているため、スタンドアロンの RTCIceTransport API を介してピアツーピア接続を確立 ICE: データが確実かつ順番に転送される（下記のセクションを参照）詳しくは、信頼性が低い配信など）。汎用であるためゲーム、ファイル転送メディアトランスポート、メッセージングなど

理由

パワフルな低レベルのデータ転送 API により、アプリケーション（リアルタイム新しいタスクをウェブで行うよう求めています。API を基盤とすることもでき独自のソリューションを作成し、同業他社の手法の限界を押し上げるたとえば、カスタムビットレート割り当てノブのロック解除など）。イン将来的には、エンコードされたメディアのサポートが強化されたことで、独自のビデオ通信アプリケーションを開発します。WebRTC による NV の取り組み下位レベルの API に移行することです価値があります。

QUIC が選ばれる理由

リアルタイムの通信には QUIC プロトコルが推奨されます。Kubernetes の上に構築されており、 UDP の場合、暗号化、輻輳制御が組み込まれており、ヘッドオブラインブロッキングする必要がありますRTCQuicTransport は、Terraform とよく似た機能を提供します。 RTCDataChannel API。ただし、トランスポートとして SCTP ではなく QUIC を使用構成されます。RTCQuicTransport はスタンドアロン API であるため、何も行いません。リアルタイムメディアを含む RTCPeerConnection API のオーバーヘッド説明します。

方法

汎用 API の概要

API には、RTCIceTransport、RTCQuicTransport という 3 つの主要な抽象化があります。および RTCQuicStream。

API のアーキテクチャを示す RTCQuicTransport の図

RTCIceTransport

ICE は、インターネット経由でピアツーピア接続を確立するためのプロトコルです。現在 WebRTC で使用されています。このオブジェクトは、サービスアカウントまたはリソースを保護するための 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* メソッドによって返される Promise を使用すると、次の場合にデータをバッファリングできます。 JavaScript がビジー状態です。送信側にバックプレッシャーが適用されるのは、受信側で読み取りバッファがいっぱいになります。送信側は書き込みを行いますバッファがいっぱいになっているため、バックプレッシャーが適用されたときに書き込み側には waitForWriteBufferedAmountBelow メソッドもあります。バッファ内の書き込みスペースを待つことができます。詳細情報: データの書き込み/読み取りの方法については、ドキュメントをご覧ください。

順序付けされていない/信頼性が低い配信

RTCQuicStream は、データを確実かつ順番に送信することしかサポートしませんが、信頼性に欠ける/順序付けられていない配信は、他の手段で達成できます。対象小さなデータチャンクを別々のストリームに送信できますデータがストリーム間で並べ替えられないためです配信の信頼性が低い場合、 final を true に設定してデータの小さなチャンクを送信し、タイムアウト後のストリームに対するreset()。タイムアウトは、アプリケーションの必要な再送回数を指定します。

時期

Chrome 73 バージョンでオリジントライアルを開始し、バージョン M75 以前までです。その後オリジントライアルはあります。フィードバックと関心に基づいて、適切な変更を行います API を公開するか、この API の新しいオリジントライアルを続けるか、提供されません。

場所

iOS を除くすべてのプラットフォームの Chrome ブラウザ。

他には？

フィードバック

オリジントライアルの主な目的の一つはフィードバックを得ることです。開発者に提供します。私たちが関心を寄せているのは、

この API でできること
この API は他の Data Transport API をどのように改善しますか？（WebSocket または WebRTC の RTCDataChannel）？改善すべき点をお聞かせください。
パフォーマンス
API エルゴノミクス

オリジントライアルに登録する

送信元のトークンをリクエストします。
ページにトークンを追加します。このトークンを提供する方法は 2 つあります。元のページ: <ph type="x-smartling-placeholder">
- origin-trial <meta> タグをページの head に追加します。たとえば次のようになります。 <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
- サーバーを設定できる場合は、トークンをページで提供することもできます。 Origin-Trial HTTP ヘッダーを使用します。結果のレスポンスヘッダーは、次のようになります: Origin-Trial: TOKEN_GOES_HERE

ウェブ仕様

ドラフト仕様はオリジントライアルで API より先に進む含まれます。

WHATWG ストリームとの整合性がより高い単方向ストリーム
再送信の無効化
（近日提供予定）データグラム

完全な仕様だけでなく、 WHATWG ストリーミングサポートなど）ですが、まずはフィードバックを伺いたいと思います。

セキュリティ

QUIC handshake におけるセキュリティは、事前共有鍵を使用して適用されます。暗号化された P2P QUIC 接続を確立します。この鍵は Cloud Storage バケットに機密性と完全性が保証された安全な帯域外チャネルなお、キーは JavaScript に公開されます。

アクティブな攻撃

証明書のシグナリングに完全性のみを必要とする DTLS-SRTP とは異なりフィンガープリントでは、事前共有鍵に完全性と機密性が保持されます。PSK が（たとえば、シグナリング内のサーバーによって）侵害された場合、攻撃者が中間者（Man-in-the-middle）攻撃を仕掛けて関連しています

現在のステータス

ステップ	ステータス
1. 説明を作成	完了
2a.RTCQuicTransport 仕様	処理中
2b.RTCIceTransport の仕様	処理中
3.フィードバックの収集と設計を反復処理する	処理中
4. オリジントライアル	Chrome 73 以降
5. リリース	開始していません