WebTransport

1. はじめに

このセクションは規範的ではありません。

この仕様は、[WEB-TRANSPORT-OVERVIEW]を使用して、サーバーへのデータ送信およびサーバーからのデータ受信を行います。WebSocketsのように使用できますが、複数ストリーム、単方向ストリーム、順不同配信、信頼性のある転送および信頼性のない転送のサポートがあります。

注: 本仕様で示されているAPIは、IETF WEBTRANS WGで進行中の作業に基づく暫定案です。[WEB-TRANSPORT-HTTP3] および [WEB-TRANSPORT-HTTP2] の仕様は進行中であるため、今後プロトコルやAPIが大きく変更される可能性があります。

2. 適合性

規範的でないと明記されたセクションだけでなく、著者向けガイドライン、図、例、および本仕様書内の注記も全て非規範的です。それ以外は全て規範的です。

「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」といったキーワードは、[RFC2119] および [RFC8174] の定義に従い、ここで示されるように全て大文字で現れる場合のみ、同様に解釈されます。

本仕様は、ここに含まれるインターフェースを実装するユーザーエージェント製品単体に適用される適合性基準を定義します。

アルゴリズムや具体的な手順として記述された適合要件は、最終結果が同等である限り、どのような方法で実装してもかまいません。（特に、本仕様で定義されているアルゴリズムは理解しやすいように意図されており、性能面を考慮しているものではありません。）

本仕様で定義されるAPIをECMAScriptを用いて実装する場合、Web IDL仕様 [WEBIDL] で定義されるECMAScriptバインディングと用語に従い、一貫した方法で実装しなければなりません。

3. プロトコルの概念

WebTransportの主要なプロトコル概念は「セッション」と「ストリーム」の2つです。各WebTransportセッションは複数のWebTransportストリームを含むことができます。

これらは、アプリケーションレベルのAPI構造であるプロトコル名と混同しないでください。

3.1. WebTransportセッション

WebTransportセッションは、HTTP/3またはHTTP/2の基盤となるコネクション上のWebTransportのセッションです。 プーリングが有効な場合、1つのコネクション上に複数のWebTransportセッションが存在することがあります。

WebTransportセッションには、[WEB-TRANSPORT-OVERVIEW]で定義された以下の機能があります：

確立するには、WebTransportセッションをoriginとprotocols配列とともに、[WEB-TRANSPORT-OVERVIEW] セクション4.1に従い、 originをシリアル化および同型エンコードし、リクエストの`Origin`ヘッダーとして使用します。 同型エンコードしたprotocolsは、クライアントがこのセッションでサーバーに優先して使ってほしいプロトコルのリストとして使用し、[WEB-TRANSPORT-OVERVIEW] セクション3.1に従います。 セッションの確立時に、クライアントは認証情報を一切提供してはなりません。 得られる基盤となるトランスポートストリームはセッションのCONNECTストリームと呼ばれます。

WebTransportセッション sessionは、排出中となります。これは、CONNECTストリームがサーバーによって正常に閉じるよう要求された場合であり、詳細は [WEB-TRANSPORT-OVERVIEW] セクション4.1で説明されています。

終了するには、WebTransportセッション sessionに任意の整数 codeと任意のバイト列 reasonを指定し、[WEB-TRANSPORT-OVERVIEW] セクション4.1に従ってください。

WebTransportセッション sessionは、任意の整数 codeとバイト列 reasonとともに、CONNECTストリームがサーバーによって閉じられたときに 終了済みとなります。詳細は [WEB-TRANSPORT-OVERVIEW] セクション4.1で説明されています。

3.2. WebTransportストリーム

WebTransportストリームは、WebTransportセッション上の信頼性のある順序どおりのバイトストリームの概念であり、[WEB-TRANSPORT-OVERVIEW] セクション4.3で説明されています。

WebTransportストリームは、受信単方向、 送信単方向または双方向のいずれかです。

WebTransportストリームには以下の機能があります：

WebTransportストリームには以下のシグナルがあります：

4. WebTransportDatagramsWritable インターフェース

WebTransportDatagramsWritableは、WritableStream であり、 データグラムの送信のための送信ストリーミング機能を提供します。

[Exposed=(Window,Worker), SecureContext, Transferable]
interface WebTransportDatagramsWritable : WritableStream {
  attribute WebTransportSendGroup? sendGroup;
  attribute long long sendOrder;
};

4.1. 内部スロット

WebTransportDatagramsWritable オブジェクトは以下の内部スロットを持ちます。

作成するには、 WebTransportDatagramsWritable を、WebTransport transport、sendGroup、sendOrderで次のステップを実行します。

1. streamを新しいWebTransportDatagramsWritable として、以下の内容で作成：

   [[OutgoingDatagramsQueue]]

   空のキュー

   [[Transport]]

   transport

   [[SendGroup]]

   sendGroup

   [[SendOrder]]

   sendOrder

2. writeDatagramsAlgorithmをtransportとstreamでwriteDatagramsを実行するアクションとする。

3. streamをセットアップし、writeAlgorithm をwriteDatagramsAlgorithmに設定する。

4. streamを返す。

4.2. 属性

sendGroup, 型 WebTransportSendGroup, null可能

ゲッター手順：

1. thisの[[SendGroup]] を返す。

セッター手順（valueを与える）：

1. valueがnullでなく、かつ value.[[Transport]] が this.[[Transport]] でない場合、InvalidStateErrorをスローする。

2. this.[[SendGroup]] をvalueに設定する。

sendOrder, 型 long long

ゲッター手順：

1. thisの[[SendOrder]] を返す。

セッター手順（valueを与える）：

1. this.[[SendOrder]] をvalueに設定する。

4.3. 手順

ユーザーエージェントは、WebTransport オブジェクトのうち [[State]] が"connecting"または"connected"のものについて、関連するWebTransportDatagramsWritable オブジェクトの部分集合（送信順ルールにより決定）に対してsendDatagramsを実行しなければならず、アルゴリズムが進捗できる場合は合理的な範囲ですぐに実行するべきです。

送信順ルールは、送信は一般に、このトランスポート上で以前にキューされたストリームやデータグラムの送信、および今後キューされるストリームやデータグラムの送信とインターリーブされてもよいですが、送信は、同じ [[SendGroup]] かつより高い [[SendOrder]] を持つストリームやデータグラム（エラー状態でもフロー制御でブロックされているものでもない）が全て送信されるまで、優先的に待機しなければなりません。

注: トランスポートの[[State]] が"connecting"の間、データグラムの書き込みは許可されます。 データグラムは[[OutgoingDatagramsQueue]] に格納され、"connected"状態の時と同様に破棄される可能性があります。トランスポートの[[State]] が"connected"になると、キューされたデータグラムの送信が開始されます。

5. WebTransportDatagramDuplexStream インターフェース

WebTransportDatagramDuplexStreamは、汎用的なデュプレックスストリームです。

[Exposed=(Window,Worker), SecureContext]
interface WebTransportDatagramDuplexStream {
  WebTransportDatagramsWritable createWritable(
      optional WebTransportSendOptions options = {});
  readonly attribute ReadableStream readable;

  readonly attribute unsigned long maxDatagramSize;
  attribute unrestricted double? incomingMaxAge;
  attribute unrestricted double? outgoingMaxAge;
  attribute unrestricted double incomingHighWaterMark;
  attribute unrestricted double outgoingHighWaterMark;
};

5.1. 内部スロット

WebTransportDatagramDuplexStream オブジェクトは以下の内部スロットを持ちます。

ユーザーエージェントは、[[OutgoingMaxDatagramSize]]を WebTransportオブジェクトの [[State]]が"connecting"または"connected"の場合に更新してもよい。

生成するには、 WebTransportDatagramDuplexStreamを readableと readableModeを指定して、以下の手順を実行する。

1. streamを新規 WebTransportDatagramDuplexStreamとして生成し、以下の値で初期化する：

   [[Readable]]

   readable

   [[ReadableMode]]

   readableMode

   [[Writables]]

   空の順序付き集合

   [[IncomingDatagramsQueue]]

   空のキュー

   [[IncomingDatagramsPullPromise]]

   null

   [[IncomingDatagramsHighWaterMark]]

   実装依存の値

   [[IncomingDatagramsExpirationDuration]]

   null

   [[OutgoingDatagramsHighWaterMark]]

   実装依存の値

   この実装依存値は、十分なスループットを確保しつつ、送信データの即時性を損なわないように調整されるべきです。

   [[OutgoingDatagramsExpirationDuration]]

   null

   [[OutgoingMaxDatagramSize]]

   実装依存の整数

2. streamを返す。

5.2. メソッド

createWritable()

WebTransportDatagramsWritableを生成します。

createWritable()メソッドが呼ばれた場合、ユーザーエージェントは以下の手順を実行しなければなりません：

1. transportをthisに関連付けられたWebTransport オブジェクトとする。

2. transport.[[State]] が"closed"または"failed"の場合は、 InvalidStateErrorをスローする。

3. sendGroupをoptionsの sendGroup とする。

4. sendOrderをoptionsの sendOrder とする。

5. WebTransportDatagramsWritable をtransport、sendGroup、sendOrderで作成した結果を返す。

5.3. 属性

readable, 型 ReadableStream、読み取り専用

ゲッター手順：

1. thisの[[Readable]] を返す。

incomingMaxAge, 型 unrestricted double、null可能

ゲッター手順：

1. thisの[[IncomingDatagramsExpirationDuration]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが0なら、valueをnullに設定する。

3. thisの[[IncomingDatagramsExpirationDuration]] をvalueに設定する。

maxDatagramSize, 型 unsigned long、読み取り専用

WebTransportDatagramsWritableに渡せる最大データサイズ。 ゲッター手順はthisの[[OutgoingMaxDatagramSize]] を返す。

outgoingMaxAge, 型 unrestricted double、null可能

ゲッター手順：

1. thisの[[OutgoingDatagramsExpirationDuration]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが0なら、valueをnullに設定する。

3. thisの[[OutgoingDatagramsExpirationDuration]] をvalueに設定する。

incomingHighWaterMark, 型 unrestricted double

ゲッター手順：

1. thisの[[IncomingDatagramsHighWaterMark]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが1未満なら、valueを1に設定する。

3. thisの[[IncomingDatagramsHighWaterMark]] をvalueに設定する。

outgoingHighWaterMark, 型 unrestricted double

ゲッター手順：

1. thisの[[OutgoingDatagramsHighWaterMark]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが1未満なら、valueを1に設定する。

3. thisの[[OutgoingDatagramsHighWaterMark]] をvalueに設定する。

5.4. 手順

pullDatagramsは、 WebTransport オブジェクトtransportについて以下の手順を実行します：

1. datagrams を transport.[[Datagrams]] とする。

2. アサーション: datagrams.[[IncomingDatagramsPullPromise]] は null である。

3. queue を datagrams.[[IncomingDatagramsQueue]] とする。

4. もし queue が空なら、次を実行する:

   1. datagrams.[[IncomingDatagramsPullPromise]] を新しいプロミスに設定する。

   2. datagrams.[[IncomingDatagramsPullPromise]] を返す。

5. datagram と timestamp を キューからデキューした結果とする。

6. もし datagrams.[[ReadableMode]] が "bytes" なら、次を実行する:

   1. もし datagrams.[[Readable]] の 現在の BYOB リクエストビュー が null でない場合、次を実行する:

      1. view を datagrams.[[Readable]] の 現在の BYOB リクエストビュー とする。

      2. もし view の バイト長 が datagram のサイズより小さいなら、 RangeError で拒否されたプロミス を返す。

      3. elementSize を 型付き配列コンストラクタの表で view.[[TypedArrayName]] に指定された要素サイズとする。 もし view が [[TypedArrayName]] 内部スロットを持たない場合（つまり DataView である場合）、 elementSize を 0 とする。

      4. もし elementSize が 1 でない場合、TypeError で拒否されたプロミス を返す。

   2. バイトからプル datagram を datagrams.[[Readable]] にプルする。

7. それ以外の場合:

   1. chunk を datagram を表す新しい Uint8Array オブジェクトとする。

   2. エンキュー chunk を transport.[[Datagrams]].[[Readable]] に追加する。

8. undefined で解決されたプロミス を返す。

receiveDatagrams するには、 WebTransport オブジェクト transport を与えて、次の手順を実行する:

1. timestamp を現在時刻を表すタイムスタンプとする。

2. queue を datagrams.[[IncomingDatagramsQueue]] とする。

3. duration を datagrams.[[IncomingDatagramsExpirationDuration]] とする。

4. もし duration が null なら、duration を 実装依存値に設定する。

5. session を transport.[[Session]] とする。

6. session で 受信可能なデータグラム がある間、次を繰り返す:

   1. datagram を datagram を受信した結果とする。

   2. timestamp を現在時刻を表すタイムスタンプとする。

   3. chunk を datagram と timestamp のペアとする。

   4. エンキュー chunk を queue に追加する。

7. toBeRemoved を queue の長さから datagrams.[[IncomingDatagramsHighWaterMark]] を引いた値とする。

8. もし toBeRemoved が正なら、 キューからデキュー を queue から toBeRemoved 回（切り捨て）実行する。

9. queue が空でない間、次を繰り返す:

   1. bytes と timestamp を queue の最初の要素とする。

   2. もし timestamp から duration ミリ秒超過していたら、キューからデキューする。

   3. それ以外の場合、このループを終了する。

10. もし queue が空でなく、datagrams.[[IncomingDatagramsPullPromise]] が null でない場合、次を実行する:

    1. bytes と timestamp を キューからデキューした結果とする。

    2. promise を datagrams.[[IncomingDatagramsPullPromise]] とする。

    3. datagrams.[[IncomingDatagramsPullPromise]] を null に設定する。

    4. ネットワークタスクをキューし、 transport で以下の手順を実行する:

       1. chunk を bytes を表す新しい Uint8Array オブジェクトとする。

       2. エンキュー chunk を datagrams.[[Readable]] に追加する。

       3. 解決する promise を undefined で解決する。

ユーザーエージェントは、任意の WebTransport オブジェクトの [[State]] が "connected" の場合、アルゴリズムが進行可能になったタイミングでできるだけ早く receiveDatagrams を実行するべきである。

6. WebTransport インターフェース

WebTransportは、[WEB-TRANSPORT-OVERVIEW]で定義された基盤となるトランスポート機能へのAPIを提供します。

[Exposed=(Window,Worker), SecureContext]
interface WebTransport {
  constructor(USVString url, optional WebTransportOptions options = {});

  Promise<WebTransportConnectionStats> getStats();
  [NewObject] Promise<ArrayBuffer> exportKeyingMaterial(BufferSource label, optional BufferSource context);
  readonly attribute Promise<undefined> ready;
  readonly attribute WebTransportReliabilityMode reliability;
  readonly attribute WebTransportCongestionControl congestionControl;
  [EnforceRange] attribute unsigned short? anticipatedConcurrentIncomingUnidirectionalStreams;
  [EnforceRange] attribute unsigned short? anticipatedConcurrentIncomingBidirectionalStreams;
  readonly attribute DOMString protocol;

  readonly attribute Promise<WebTransportCloseInfo> closed;
  readonly attribute Promise<undefined> draining;
  undefined close(optional WebTransportCloseInfo closeInfo = {});

  readonly attribute WebTransportDatagramDuplexStream datagrams;

  Promise<WebTransportBidirectionalStream> createBidirectionalStream(
      optional WebTransportSendStreamOptions options = {});
  /* a ReadableStream of WebTransportBidirectionalStream objects */
  readonly attribute ReadableStream incomingBidirectionalStreams;

  Promise<WebTransportSendStream> createUnidirectionalStream(
      optional WebTransportSendStreamOptions options = {});
  /* a ReadableStream of WebTransportReceiveStream objects */
  readonly attribute ReadableStream incomingUnidirectionalStreams;
  WebTransportSendGroup createSendGroup();

  static readonly attribute boolean supportsReliableOnly;
};

enum WebTransportReliabilityMode {
  "pending",
  "reliable-only",
  "supports-unreliable",
};

6.1. 内部スロット

WebTransport オブジェクトは以下の内部スロットを持ちます。

6.2. コンストラクター

6.3. 属性

ready、型: Promise<undefined>、読み取り専用

取得時、thisの[[Ready]]を返さなければならない。

closed、型: Promise<WebTransportCloseInfo>、読み取り専用

取得時、thisの[[Closed]]を返さなければならない。

draining、型: Promise<undefined>、読み取り専用

取得時、thisの[[Draining]]を返さなければならない。

datagrams、型: WebTransportDatagramDuplexStream、 読み取り専用

このセッション上でデータグラムの送受信に使う単一のデュプレックスストリーム。 datagrams属性のgetter手順は以下の通りとする:

1. thisの[[Datagrams]]を返す。

incomingBidirectionalStreams、 型: ReadableStream、読み取り専用

サーバーから受信したReadableStream 内のWebTransportBidirectionalStream を返す。

注: 受信ストリームに既にデータが含まれているかどうかはサーバーの挙動による。

incomingBidirectionalStreams属性のgetter手順は以下の通りとする:

1. thisの[[IncomingBidirectionalStreams]]を返す。

incomingUnidirectionalStreams、 型: ReadableStream、読み取り専用

サーバーから受信した各ReadableStream 内に含まれる単方向ストリーム（ WebTransportReceiveStream で表される）。

注: 受信ストリームに既にデータが含まれているかどうかはサーバーの挙動による。

incomingUnidirectionalStreamsのgetter手順は以下の通り:

1. this.[[IncomingUnidirectionalStreams]]を返す。

reliability、型: WebTransportReliabilityMode、 読み取り専用

コネクションが非信頼性（UDP）転送をサポートするか、信頼性（TCPフォールバック）のみをサポートするかを示す。 コネクションが確立されるまで"pending"を返す。 getterの手順はthisの[[Reliability]]を返すこと。

congestionControl、 型: WebTransportCongestionControl、 読み取り専用

アプリケーションがコンストラクターで要求した場合、ユーザーエージェントが満たせばこのコネクションで送信時にスループット最適化型または低遅延最適化型の輻輳制御アルゴリズムの希望値。 希望値が満たされなければ値は"default"。 getterの手順はthisの[[CongestionControl]]を返すこと。

supportsReliableOnly、 型: boolean、読み取り専用

ユーザーエージェントが完全に信頼性のあるWebTransportセッションを connection上でサポートしていればtrue、そうでなければfalseを返す。

anticipatedConcurrentIncomingUnidirectionalStreams、 型: unsigned short、nullable

アプリケーションがサーバーが生成すると予想する同時オープン状態の 受信単方向ストリーム数を指定できる（任意）。 nullでなければ、ユーザーエージェントはサーバーとのネゴシエーション時に将来のラウンドトリップ削減のため [[AnticipatedConcurrentIncomingUnidirectionalStreams]] を考慮すべきである。

getter手順はthisの[[AnticipatedConcurrentIncomingUnidirectionalStreams]]を返すこと。

setter手順はvalueを受け取り、thisの [[AnticipatedConcurrentIncomingUnidirectionalStreams]] にvalueを設定する。

anticipatedConcurrentIncomingBidirectionalStreams、 型: unsigned short、nullable

アプリケーションがサーバーが生成すると予想する同時オープン状態の 双方向ストリーム数を指定できる（任意）。 nullでなければ、ユーザーエージェントはサーバーとのネゴシエーション時に将来のラウンドトリップ削減のため [[AnticipatedConcurrentIncomingBidirectionalStreams]] を考慮すべきである。

getter手順はthisの[[AnticipatedConcurrentIncomingBidirectionalStreams]]を返すこと。

setter手順はvalueを受け取り、thisの [[AnticipatedConcurrentIncomingBidirectionalStreams]] にvalueを設定する。

注: anticipatedConcurrentIncomingUnidirectionalStreams または anticipatedConcurrentIncomingBidirectionalStreams を設定しても、アプリケーションが期待するストリーム数が必ずしも受信できることを保証しません。

protocol、型: DOMString、読み取り専用

WebTransportセッションが確立され、 protocols コンストラクターオプションに非空配列を指定した場合、サーバーが選択したアプリケーションレベルのプロトコルを返す（存在すれば）。それ以外は空文字列。 getter手順はthisの[[Protocol]]を返すこと。

6.4. メソッド

getStats()

このWebTransportの 基盤となる接続 の統計情報を収集し、非同期で結果を返します。

getStatsが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません:

1. transportをthisとする。

2. pを新規プロミスとする。

3. もしtransport.[[State]] が"failed"なら、pをInvalidStateErrorで拒否し、手順を中止する。

4. 以下の手順を並列で実行する:

   1. もしtransport.[[State]] が"connecting"なら、状態が変わるまで待機する。

   2. もしtransport.[[State]] が"failed"なら、ネットワークタスクをキューし transportでpをInvalidStateErrorで拒否し、手順を中止する。

   3. もしtransport.[[State]] が"closed"なら、ネットワークタスクをキューし transportでpを接続の最新の統計情報で解決し、手順を中止する。 その統計情報の収集タイミングは実装依存とする。

   4. 基盤となる接続から統計情報（データグラムの統計も含む）を収集する。

   5. ネットワークタスクをキューし transportで以下の手順を実行する:

      1. statsを新規 WebTransportConnectionStats オブジェクト（収集した統計情報を表す）とする。

      2. pをstatsで解決する。

5. pを返す。

exportKeyingMaterial(BufferSource label, optional BufferSource context)

このWebTransportの 基盤となる接続 に一意に関連付けられたTLSセッションの TLS Keying Material Exporter から鍵素材をエクスポートします。

exportKeyingMaterialが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません:

1. transportをthisとする。

2. labelLengthをlabel.バイト長とする。

3. もしlabelLengthが255を超えていたら、RangeErrorで拒否されたプロミスを返す。

4. contextLengthを0とする。

5. もしcontextが与えられていれば、contextLengthをcontext.バイト長にする。

6. もしcontextLengthが255を超えていたら、RangeErrorで拒否されたプロミスを返す。

7. pを新規プロミスとする。

8. 以下の手順を並列で実行する。ただし、abort when transportの [[State]] が"closed"または"failed"になった場合は中止し、 代わりにネットワークタスクをキューし transportでpを InvalidStateErrorでrejectする:

   1. keyingMaterialをTLS鍵素材のエクスポート結果とし、 [WEB-TRANSPORT-OVERVIEW] Section TBDに従い、 labelLength、label、contextLength、存在する場合はcontextを渡す。

   2. ネットワークタスクをキューし transportでpをkeyingMaterialで解決する。

9. pを返す。

createBidirectionalStream()

送信側の双方向ストリーム用WebTransportBidirectionalStream オブジェクトを生成します。ストリームの生成だけではピアに即座に認識されません。データ送信時に初めて認識されます。

注: サーバーはデータが送信されるまでこのストリームを認識しない場合があります。

createBidirectionalStreamが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません:

1. transportをthisとする。

2. もしtransport.[[State]] が"closed"または"failed"なら、 新規InvalidStateErrorで拒否されたプロミスを返す。

3. sendGroupをoptionsの sendGroup とする。

4. sendOrderをoptionsの sendOrder とする。

5. waitUntilAvailableをoptionsの waitUntilAvailable とする。

6. pを新規プロミスとする。

7. 以下の手順を並列で実行する。ただし、abort when transportの [[State]] が"closed"または"failed"になった場合は中止し、 代わりにネットワークタスクをキューし transportでpを InvalidStateErrorでrejectする:

   1. streamIdをtransport.[[Session]] に対して有効かつ一意な新規ストリームID（[QUIC] Section 19.11参照）とする。 すぐに利用できない場合、waitUntilAvailableがtrueなら利用可能になるまで待機し、falseなら ネットワークタスクをキューし transportでpをQuotaExceededErrorで拒否し、手順を中止する。

   2. internalStreamを双方向ストリームの生成で transport.[[Session]] とstreamIdを渡して得る。

   3. ネットワークタスクをキューし transportで以下の手順を実行する:

      1. もしtransport.[[State]] が"closed"または"failed"なら、 pをInvalidStateErrorで拒否し、手順を中止する。

      2. streamをWebTransportBidirectionalStream生成で internalStream、transport、sendGroup、sendOrderを渡して得る。

      3. pをstreamで解決する。

8. pを返す。

createUnidirectionalStream()

送信側の単方向ストリーム用WebTransportSendStream を生成します。ストリームの生成だけではサーバーに即座に認識されず、データ送信時に初めて認識されます。

注: サーバーはデータが送信されるまでこのストリームを認識しない場合があります。

createUnidirectionalStream()メソッドが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません:

1. transportをthisとする。

2. もしtransport.[[State]] が"closed"または"failed"なら、 新規InvalidStateErrorで拒否されたプロミスを返す。

3. sendGroupをoptionsの sendGroup とする。

4. sendOrderをoptionsの sendOrder とする。

5. waitUntilAvailableをoptionsの waitUntilAvailable とする。

6. pを新規プロミスとする。

7. 以下の手順を並列で実行する。ただし、abort when transportの [[State]] が"closed"または"failed"になった場合は中止し、 代わりにネットワークタスクをキューし transportでpを InvalidStateErrorでrejectする:

   1. streamIdをtransport.[[Session]] に対して有効かつ一意な新規ストリームID（[QUIC] Section 19.11参照）とする。 すぐに利用できない場合、waitUntilAvailableがtrueなら利用可能になるまで待機し、falseなら ネットワークタスクをキューし transportでpをQuotaExceededErrorで拒否し、手順を中止する。

   2. internalStreamを送信側単方向ストリームの生成で transport.[[Session]] とstreamIdを渡して得る。

   3. ネットワークタスクをキューし transportで以下の手順を実行する:

      1. もしtransport.[[State]] が"closed"または"failed"なら、 pをInvalidStateErrorで拒否し、手順を中止する。

      2. streamをWebTransportSendStream生成で internalStream、transport、sendGroup、sendOrderを渡して得る。

      3. pをstreamで解決する。

8. pを返す。

createSendGroup()

WebTransportSendGroup を生成します。

createSendGroup()メソッドが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません:

1. transportをthisとする。

2. もしtransport.[[State]] が"closed"または"failed"なら、 InvalidStateErrorを投げる。

3. WebTransportSendGroup生成の WebTransportSendGroup にtransportを渡した結果を返す。

6.5. 手順

6.6. クライアントによって開始されていないセッション終了

6.7. コンテキストクリーンアップ手順

この仕様はコンテキストクリーンアップ手順を次の手順として定義する。WebTransport transportについて：

1. transport.[[State]] が"connected"なら：

   1. transport.[[State]] を"failed"に設定する。

   2. 並行して、transport.[[Session]]を終了する。

   3. ネットワークタスクをキューし、 transportで以下の手順を実行：

      1. errorを新しく作成したWebTransportErrorとし、 source は"session"とする。

      2. transportのクリーンアップをerrorで実行する。

2. transport.[[State]] が"connecting"なら、transport.[[State]] を "failed"に設定する。

   これはWorkerでも行う必要がある。詳細は #127 および whatwg/html#6731参照。

6.8. ガベージコレクション

WebTransport オブジェクトで[[State]] が"connecting"の場合、 [[IncomingBidirectionalStreams]]、 [[IncomingUnidirectionalStreams]]、 いずれかの WebTransportReceiveStream、 または[[Datagrams]].[[Readable]] がロック済みである場合、またはready、 draining、 closed の各プロミスが監視されている場合は、ガベージコレクションされてはならない。

WebTransport オブジェクトで[[State]] が"connected"の場合、 [[IncomingBidirectionalStreams]]、 [[IncomingUnidirectionalStreams]]、 いずれかの WebTransportReceiveStream、 または[[Datagrams]].[[Readable]] がロック済みである場合、またはdraining またはclosed のプロミスが監視されている場合は、ガベージコレクションされてはならない。

WebTransport オブジェクトで[[State]] が"draining"の場合、 [[IncomingBidirectionalStreams]]、 [[IncomingUnidirectionalStreams]]、 いずれかの WebTransportReceiveStream、 または[[Datagrams]].[[Readable]] がロック済みである場合、またはclosed のプロミスが監視されている場合は、ガベージコレクションされてはならない。

WebTransport オブジェクトで確立済みのWebTransportセッション を持ち、ネットワークへ送信待ちのデータ（[[Datagrams]].[[OutgoingDatagramsQueue]]のデータグラムも含む）がある場合、ガベージコレクションされてはならない。

WebTransport オブジェクトがガベージコレクションされ、基盤接続 がまだ開いている場合、ユーザーエージェントは WebTransportセッションを終了 し、Application Error Codeは0、Application Error Messageは""を指定しなければならない。

6.9. 設定

dictionary WebTransportHash {
  DOMString algorithm;
  BufferSource value;
};

dictionary WebTransportOptions {
  boolean allowPooling = false;
  boolean requireUnreliable = false;
  sequence<WebTransportHash> serverCertificateHashes;
  WebTransportCongestionControl congestionControl = "default";
  [EnforceRange] unsigned short? anticipatedConcurrentIncomingUnidirectionalStreams = null;
  [EnforceRange] unsigned short? anticipatedConcurrentIncomingBidirectionalStreams = null;
  sequence<DOMString> protocols = [];
  DatagramsReadableMode datagramsReadableMode;
};

enum WebTransportCongestionControl {
  "default",
  "throughput",
  "low-latency",
};

enum DatagramsReadableMode { "bytes" };

WebTransportOptionsは、WebTransportセッションの確立と利用方法を決定するパラメータの辞書です。

allowPooling、型：boolean、デフォルトはfalse

trueに設定した場合、WebTransportセッションはプール可能、すなわち 基盤接続が他のWebTransportセッションと共有可能になります。

requireUnreliable、 型：boolean、デフォルトはfalse

trueに設定した場合、WebTransportセッションは、 HTTP/3 connectionが不可能な場合、HTTP/2 connectionで確立できません。

serverCertificateHashes、 型：sequence<WebTransportHash>

このオプションは専用接続を使用する場合のみサポートされます。 この機能をサポートしないトランスポートプロトコルでは、このフィールドが空でない場合、 NotSupportedError 例外がスローされます。

サポートされ、空でない場合、ユーザーエージェントは 証明書ハッシュの検証で serverCertificateHashes が成功し、かつカスタム証明書要件を満たす場合のみサーバー証明書を信頼します。未知の algorithm を使用したハッシュは無視します。空の場合、通常のfetch操作で用いる証明書検証手順を使います。

これはallowPoolingと併用できません。

congestionControl、 型：WebTransportCongestionControl、デフォルトは"default"

アプリケーションがこの接続でデータ送信時にスループット最適型または低遅延最適型の輻輳制御アルゴリズムの希望値を指定できます。これはユーザーエージェントへのヒントです。

この設定オプションは、現時点で低遅延最適化の輻輳制御アルゴリズムがブラウザで実装されていないため、リスクがある機能とみなされています。

anticipatedConcurrentIncomingUnidirectionalStreams、 型：unsigned short、nullable、デフォルトはnull

アプリケーションがサーバーが生成すると予想する同時オープン状態の 受信単方向ストリーム数を指定できます。 ユーザーエージェントは初期状態でサーバーから少なくとも100本の受信単方向 ストリームを許可しなければなりません。 nullでなければ、ユーザーエージェントはネゴシエーション時に [[AnticipatedConcurrentIncomingUnidirectionalStreams]] を考慮してラウンドトリップ削減を試みるべきです。

anticipatedConcurrentIncomingBidirectionalStreams、 型：unsigned short、nullable、デフォルトはnull

アプリケーションがサーバーが生成すると予想する同時オープン状態の 双方向ストリーム数を指定できます。 ユーザーエージェントは初期状態でサーバーに少なくとも100本の双方向ストリーム生成を許可しなければなりません。 nullでなければ、ユーザーエージェントはネゴシエーション時に [[AnticipatedConcurrentIncomingBidirectionalStreams]] を考慮してラウンドトリップ削減を試みるべきです。

protocols、型：sequence<DOMString>、デフォルトは[]

アプリケーションレベルのプロトコル名の配列を省略可能で指定します。サーバーが希望するアプリケーションプロトコルを選択してクライアントに伝えることは任意です。 適切なプロトコルが提供されていなかった場合、サーバーはリクエストを拒否する可能性があります。

datagramsReadableMode、 型：DatagramsReadableMode

アプリケーションが受信データグラムに対して 読み取りバイトストリームを利用することを希望する場合に指定できます。そうでなければ、デフォルトの読み取りストリームが使われます。

注: デフォルトの読み取りストリームはゼロ長データグラムの検出に必要です。 一方、読み取りバイトストリームはBYOBリーダーを用いることでより効率的にバイト処理（特にコピーの最小化）が可能です。

カスタム証明書要件は以下の通り：証明書は[RFC5280]で定義されるX.509v3証明書でなければならず、Subject Public Keyの鍵は許可された公開鍵アルゴリズムのいずれかでなければならず、現在時刻は[RFC5280]のSection 4.1.2.5で定義される有効期限の範囲内でなければならず、有効期間の合計長は2週間を超えてはならない。ユーザーエージェントは追加の実装定義要件を課すことができます。

許可された公開鍵アルゴリズムのリストは実装定義ですが、相互運用性のためにNIST P-256（secp256r1）を使うECDSA（[RFC3279]、Section 2.3.5； [RFC8422]）は必須です。RSA鍵（[RFC3279]、Section 2.3.1）は含めてはなりません。

6.10. WebTransportCloseInfo辞書

WebTransportCloseInfo辞書は、 終了処理時に WebTransportセッションのエラーコードと理由を設定するための情報を含みます。

dictionary WebTransportCloseInfo {
  unsigned long closeCode = 0;
  USVString reason = "";
};

この辞書は以下の属性を持ちます:

closeCode、型：unsigned long、デフォルトは0

ピアに通知されるエラーコードです。

reason、型：USVString、デフォルトは""

WebTransportを閉じる理由です。

6.11. WebTransportSendOptions辞書

WebTransportSendOptionsは、 createUnidirectionalStream、 createBidirectionalStream、 createWritable の振る舞いに影響を与える基本パラメータの辞書です。

dictionary WebTransportSendOptions {
  WebTransportSendGroup? sendGroup = null;
  long long sendOrder = 0;
};

この辞書は次の属性を持ちます：

sendGroup, 型 WebTransportSendGroup、null可能、デフォルトはnull

作成されたストリームをグループ化するための任意のWebTransportSendGroup、またはnull。

sendOrder, 型 long long、デフォルトは0

送信順序番号。指定すると作成されたストリームは厳密な順序付けに参加します。 現在厳密順序ストリームにキューされたバイトは、より小さい送信順序番号で作成された他の厳密順序ストリームにキューされたバイトよりも先に送信されます。

送信順序番号が指定されていない場合、他のストリームとの相対的な送信順は実装定義です。ただし、ユーザーエージェントは、低い順序番号で飢餓状態になっていない限り、すべてのストリーム間で帯域を公平に分配することが強く推奨されます。

注: これは送信側のデータ優先制御であり、受信順序を保証するものではありません。

6.12. WebTransportSendStreamOptions辞書

WebTransportSendStreamOptionsは、 WebTransportSendStreamの パラメータ辞書であり、 createUnidirectionalStream および createBidirectionalStream で生成されたストリームの振る舞いに影響します。

dictionary WebTransportSendStreamOptions : WebTransportSendOptions {
  boolean waitUntilAvailable = false;
};

この辞書は次の属性を持ちます：

waitUntilAvailable, 型 boolean、デフォルトはfalse

trueの場合、 createUnidirectionalStream や createBidirectionalStream の呼び出しで返されるPromiseは、 settled されるまで、基盤となるコネクションがストリーム生成に十分なフロー制御クレジットを持つか あるいはコネクションが新たな送信ストリームを生成できない状態になるまで待機します。falseの場合、呼び出し時にフロー制御ウィンドウがなければPromiseは rejectedされます。

6.13. WebTransportConnectionStats辞書

WebTransportConnectionStats辞書は、 WebTransportセッションの基盤となるコネクションに関するWebTransport固有の統計情報を含みます。

注: プールが利用される場合、同一WebTransportセッションが同じコネクション上にプールされている場合、すべて同じ情報を受け取ります。つまり、同じネットワークパーティションキーに属するプールされたセッション間で情報が公開されます。

注: 利用不可な統計項目はWebTransportConnectionStats辞書から欠落します。

dictionary WebTransportConnectionStats {
  unsigned long long bytesSent = 0;
  unsigned long long packetsSent = 0;
  unsigned long long bytesLost = 0;
  unsigned long long packetsLost = 0;
  unsigned long long bytesReceived = 0;
  unsigned long long packetsReceived = 0;
  required DOMHighResTimeStamp smoothedRtt;
  required DOMHighResTimeStamp rttVariation;
  required DOMHighResTimeStamp minRtt;
  required WebTransportDatagramStats datagrams;
  unsigned long long? estimatedSendRate = null;
  boolean atSendCapacity = false;
};

この辞書は次の属性を持ちます：

bytesSent, 型 unsigned long long、デフォルトは0

基盤となるコネクション上で送信されたバイト数（再送分も含む）。UDPやその他の外部フレーミングは含みません。

packetsSent, 型 unsigned long long、デフォルトは0

基盤となるコネクション上で送信されたパケット数（ロストと判定されたものも含む）。

bytesLost, 型 unsigned long long、デフォルトは0

基盤となるコネクション上でロストしたバイト数（単調増加ではない。ロストとされたパケットが後で受信されることもある）。UDPや外部フレーミングは含みません。

packetsLost, 型 unsigned long long、デフォルトは 0

基盤となるコネクション上でロストしたパケット数（単調増加ではない。ロストとされたパケットが後で受信されることもある）。

bytesReceived, 型 unsigned long long、デフォルトは 0

基盤となるコネクション上で受信したバイト数（ストリーム重複データも含む）。UDPや外部フレーミングは含みません。

packetsReceived, 型 unsigned long long、デフォルトは 0

基盤となるコネクション上で受信したパケット数（処理不能パケットも含む）。

smoothedRtt, 型 DOMHighResTimeStamp

コネクション上で現在観測されているスムーズなRTT（往復遅延時間）。定義は[RFC9002] Section 5.3参照。

rttVariation, 型 DOMHighResTimeStamp

コネクション上で現在観測されているRTTサンプルの平均変動。定義は[RFC9002] Section 5.3参照。

minRtt, 型 DOMHighResTimeStamp

接続全体で観測された最小ラウンドトリップ時間。[RFC9002] セクション5.2で定義されています。

estimatedSendRate, 型 unsigned long long、null可能、デフォルトは null

ユーザーエージェントがキューしたデータを送信する推定速度（bps）。この値は同じWebTransportセッション内の全ストリーム・データグラムに適用され、 （congestionControlで選択された可能性のある）輻輳制御アルゴリズムにより算出されます。フレーミングオーバーヘッドは除外され、アプリケーションペイロード送信速度を示します。現在推定値がなければnullとします。前回はnullでなかった場合でもnullになることがあります。

atSendCapacity, 型 boolean、デフォルトはfalse

falseの場合、estimatedSendRate がアプリケーション制限となり、アプリケーションが輻輳制御で許容されるよりも明らかに少ないデータしか送信していないことを意味します。輻輳制御がアプリケーション制限時は、利用可能なネットワーク容量の推定値が不正確になる可能性があります。

trueの場合、アプリケーションはネットワーク容量一杯で送信しており、estimatedSendRate はアプリケーションの利用可能なネットワーク容量を反映します。

atSendCapacity がtrueの時、estimatedSendRate は上限値となります。 アプリケーション送信速度が維持される限り、estimatedSendRate はネットワーク状況に応じて適応します。ただし、estimatedSendRate はtrueでもnullになり得ます。

6.14. WebTransportDatagramStats辞書

WebTransportDatagramStats辞書は、 基盤となるコネクション上でのデータグラム送受信に関する統計情報を含みます。

dictionary WebTransportDatagramStats {
  unsigned long long droppedIncoming = 0;
  unsigned long long expiredIncoming = 0;
  unsigned long long expiredOutgoing = 0;
  unsigned long long lostOutgoing = 0;
};

この辞書は次の属性を持ちます：

droppedIncoming, 型 unsigned long long、デフォルトは0

アプリケーションがdatagramsの readable から読み取る前に、新しいデータグラムにより受信キューがオーバーフローし、破棄された着信データグラムの数。

expiredIncoming, 型 unsigned long long、デフォルトは0

incomingMaxAge より古くなり、datagramsの readable から読み取られる前に破棄された着信データグラムの数。

expiredOutgoing, 型 unsigned long long、デフォルトは0

送信待ちキューに入っていたデータグラムが、outgoingMaxAge より古くなり、送信される前に破棄された数。

lostOutgoing, 型 unsigned long long、デフォルトは0

送信されたデータグラムで、[RFC9002] Section 6.1で定義される「ロスト」と判定された数。

7. インターフェイス WebTransportSendStream

WebTransportSendStream は、送信単方向または双方向 のWebTransportストリームを使った送信ストリーミング機能を提供する WritableStream です。

これはサーバーにデータを送信するために書き込み可能な WritableStream 型のUint8Array です。

[Exposed=(Window,Worker), SecureContext, Transferable]
interface WebTransportSendStream : WritableStream {
  attribute WebTransportSendGroup? sendGroup;
  attribute long long sendOrder;
  Promise<WebTransportSendStreamStats> getStats();
  WebTransportWriter getWriter();
};

WebTransportSendStream は必ずcreate手続きによって作成されます。

WebTransportSendStreamの 転送ステップおよび 転送受信ステップは WritableStreamのものです。

7.1. 属性

sendGroup、型：WebTransportSendGroup、nullable

getterの手順：

1. thisの[[SendGroup]]を返す。

setterの手順（valueを与えたとき）：

1. もしvalueがnullでなく、 value.[[Transport]] が this.[[Transport]]でない場合、 InvalidStateErrorを投げる。

2. this.[[SendGroup]] にvalueを設定する。

sendOrder、型：long long

getterの手順：

1. thisの[[SendOrder]]を返す。

setterの手順（valueを与えたとき）：

1. this.[[SendOrder]] にvalueを設定する。

7.2. メソッド

getStats()

このWebTransportSendStreamの パフォーマンスに関する統計情報を収集し、結果を非同期で報告します。

getStatsが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません：

1. 新しいpromisepを作成する。

2. 以下の手順を並行して実行する：

   1. このWebTransportSendStreamに 特有の統計情報を収集する。

   2. 統計情報が準備できるまで待機する。

   3. ネットワークタスクをキューに入れる（transport）を実行し、以下の手順を行う：

      1. 収集した統計情報を表すnew WebTransportSendStreamStats オブジェクトとしてstatsを作成する。

      2. Resolve pにstatsで解決する。

3. pを返す。

getWriter()

このメソッドは、getWriter （WritableStream から継承）と同様に実装されなければならないが、 WritableStreamDefaultWriter の代わりに、 WebTransportWriterをWebTransportWriter としてthisに対して生成する必要がある。

7.3. 内部スロット

WebTransportSendStream には以下の内部スロットがあります。

7.4. 手続き

7.5. サーバーから送信された受信中止シグナルの受信

7.6. WebTransportSendStreamStats辞書

WebTransportSendStreamStats辞書には、 1つのWebTransportSendStream に特有の統計情報が含まれます。

dictionary WebTransportSendStreamStats {
  unsigned long long bytesWritten = 0;
  unsigned long long bytesSent = 0;
  unsigned long long bytesAcknowledged = 0;
};

この辞書は以下の属性を持ちます：

bytesWritten, 型 unsigned long long、デフォルト値0

アプリケーションがこのWebTransportSendStream に正常に書き込んだバイト数の合計。この値は増加のみする。

bytesSent, 型 unsigned long long、デフォルト値0

このWebTransportSendStream に書き込まれたアプリケーションバイトのうち、少なくとも一度送信されたバイト数の進捗指標。この値は増加のみし、常にbytesWritten以下。

注: これは単一ストリーム上のアプリデータ送信のみの進捗であり、ネットワークオーバーヘッドは含まない。

bytesAcknowledged, 型 unsigned long long、デフォルト値0

このWebTransportSendStream に書き込まれたアプリケーションバイトのうち、QUICのACKメカニズムでサーバーに受信を認められたバイト数の進捗指標。最初の非ackバイトを除くまでの連続バイトのみカウントされる。この値は増加のみし、常にbytesSent以下。

注: HTTP/2接続時はこの値はbytesSent と一致する。

8. インターフェイス WebTransportSendGroup

WebTransportSendGroup は多数の個別（通常は厳密順序）WebTransportSendStream にまたがるデータ転送を追跡するためのオプションの管理オブジェクトです。

WebTransportSendStreamは、 生成時またはsendGroup属性の割り当てによって、 同時に最大1つのWebTransportSendGroup にグループ化されることができます。デフォルトでは グループ化されていません。

ユーザーエージェントは、WebTransportSendGroup 間の帯域分配を平等に扱います。 各WebTransportSendGroup はsendOrder 番号評価の独立した数値空間も確立します。

[Exposed=(Window,Worker), SecureContext]
interface WebTransportSendGroup {
  Promise<WebTransportSendStreamStats> getStats();
};

WebTransportSendGroup は必ずcreate手続きによって作成されます。

8.1. メソッド

getStats()

WebTransportSendStreamで、 このsendGroupにグループ化されている全てから統計情報を集約し、非同期で結果を報告します。

getStatsが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません：

1. pを新規プロミスとする。

2. streamsをWebTransportSendStreamのうち、 [[SendGroup]] がthisであるもの全てとする。

3. 次の手順を並列で実行する：

   1. streams内の全ストリームから統計情報を収集する。

   2. ネットワークタスクをキューし transportで以下の手順を実行する：

      1. statsを新規 WebTransportSendStreamStats オブジェクト（集計した統計値を表す）とする。

      2. pをstatsで解決する。

4. pを返す。

8.2. 内部スロット

WebTransportSendGroup には以下の内部スロットがあります。

8.3. 手続き

9. インターフェイス WebTransportReceiveStream

WebTransportReceiveStream は、受信単方向または双方向 のWebTransportストリームを用いて、受信ストリーミング機能を提供する ReadableStream です。

これはサーバーから受信したデータを消費するために読み取ることができる ReadableStream 型のUint8Array です。WebTransportReceiveStream は読み取りバイトストリームであり、 利用者はBYOBリーダーだけでなくデフォルトリーダーも使用できます。

[Exposed=(Window,Worker), SecureContext, Transferable]
interface WebTransportReceiveStream : ReadableStream {
  Promise<WebTransportReceiveStreamStats> getStats();
};

WebTransportReceiveStream は必ずcreate手続きによって作成されます。

WebTransportReceiveStreamの 転送ステップおよび 転送受信ステップは ReadableStreamのものです。

9.1. メソッド

getStats()

このWebTransportReceiveStreamの パフォーマンスに関する統計情報を収集し、結果を非同期で報告します。

getStatsが呼び出されたとき、ユーザーエージェントは以下の手順を実行します：

1. 新しいpromisepを作成する。

2. 以下の手順を並行して実行する：

   1. このWebTransportReceiveStream に特有の統計情報を収集する。

   2. ネットワークタスクをキュー（transport）し、以下の手順を実行：

      1. 収集した統計情報を表すnew WebTransportReceiveStreamStats オブジェクトstatsを作成。

      2. pをstatsで解決。

3. pを返す。

9.2. 内部スロット

WebTransportReceiveStream には以下の内部スロットがあります。

9.3. 手続き

9.4. サーバーから送信中止シグナルを受信した場合

9.5. WebTransportReceiveStreamStats辞書

WebTransportReceiveStreamStats辞書には、 1つのWebTransportReceiveStream に特有の統計情報が含まれます。

dictionary WebTransportReceiveStreamStats {
  unsigned long long bytesReceived = 0;
  unsigned long long bytesRead = 0;
};

この辞書は以下の属性を持ちます：

bytesReceived, 型 unsigned long long、デフォルト値0

サーバーアプリケーションがこのWebTransportReceiveStream に送信することを意図したバイトのうち、これまで受信した分の進捗指標。最初の欠損バイトを除くまでの連続バイトのみカウントされる。この値は増加のみする。

注: これは単一ストリーム上のアプリデータ受信のみの進捗であり、ネットワークオーバーヘッドは含まない。

bytesRead, 型 unsigned long long、デフォルト値0

アプリケーションがこのWebTransportReceiveStream から正常に読み取ったバイト数の合計。この値は増加のみし、常にbytesReceived以下。

10. インターフェイス WebTransportBidirectionalStream

[Exposed=(Window,Worker), SecureContext]
interface WebTransportBidirectionalStream {
  readonly attribute WebTransportReceiveStream readable;
  readonly attribute WebTransportSendStream writable;
};

10.1. 内部スロット

WebTransportBidirectionalStream は以下の内部スロットを持ちます。

10.2. 属性

readable, 型 WebTransportReceiveStream, 読み取り専用

getter手順は、thisの[[Readable]]を返すこと。

writable, 型 WebTransportSendStream, 読み取り専用

getter手順は、thisの[[Writable]]を返すこと。

10.3. 手続き

11. WebTransportWriter インターフェイス

WebTransportWriter はWritableStreamDefaultWriter のサブクラスであり、 2つのメソッドを追加します。

WebTransportWriter は必ずcreate 手続きによって作成されます。

[Exposed=*, SecureContext]
interface WebTransportWriter : WritableStreamDefaultWriter {
  Promise<undefined> atomicWrite(optional any chunk);
  undefined commit();
};

11.1. メソッド

atomicWrite(chunk)

atomicWrite メソッドは、与えられたchunkが送信時点でのフロー制御 ウィンドウ内で全て送信できない場合はrejectされます。 この動作は、フロー制御デッドロックに敏感な ニッチなトランザクション型アプリケーションに対応するためのものです（[RFC9308] Section 4.4）。

注: atomicWrite は、一部データ送信後にrejectされる場合もあります。 フロー制御に対して原子的ですが、他のエラーが発生することがあります。 atomicWrite はデータをパケット間で分割したり、他のデータとインターリーブされるのを防ぐものではありません。 フロー制御クレジット不足による失敗は送信側のみが把握できます。

注: 原子的書き込みも非原子的書き込みの後ろに並ぶとブロックされる場合があります。 atomicWriteがrejectされた場合、その時点で後ろに並んでいた全てのリクエストもrejectされます。 このときrejectされた非原子的書き込みはストリームをエラー状態にします。 したがって、アプリケーションはatomicWriteのawaitを推奨します。

atomicWrite が呼ばれた際、ユーザーエージェントは以下の手順を実行します：

1. pをwrite(chunk) （WritableStreamDefaultWriter に対してchunkを渡す）で得る。

2. pをstreamの[[AtomicWriteRequests]] に追加。

3. promiseがsettledになった際に反応する以下のステップの結果を返す：

   1. もしstreamの[[AtomicWriteRequests]] にpが含まれていれば、 pを削除する。

   2. もしpが理由rでrejectされた場合、rでrejectされたpromiseを返す。

   3. undefinedを返す。

commit()

commit メソッドは、ストリームの[[CommittedOffset]] を、そのストリームに書き込まれたバイト数([[BytesWritten]]) と一致するように更新します。 これにより、書き込みが中止されてストリームが送信中止された後でも、 それらのバイトがピアに確実に配信されることが保証されます。 この動作は[RELIABLE-RESET]で説明されている仕組みを利用します。

注: これは接続が失敗した場合の配信を保証するものではなく、 ストリームが送信中止された場合のみ保証されます。

commit がstreamに対して呼ばれた際、ユーザーエージェントは以下の手順を実行します：

1. transportをstreamの[[Transport]]とする。

2. streamの[[CommittedOffset]] をstreamの[[BytesWritten]] の値に設定する。

11.2. 手続き

12. WebTransportError インターフェイス

WebTransportErrorはDOMException のサブクラスであり、

• サーバーまたはネットワークからのエラー、または

• クライアントが開始した中止操作の理由を表します。

[Exposed=(Window,Worker), Serializable, SecureContext]
interface WebTransportError : DOMException {
  constructor(optional DOMString message = "", optional WebTransportErrorOptions options = {});

  readonly attribute WebTransportErrorSource source;
  readonly attribute unsigned long? streamErrorCode;
};

dictionary WebTransportErrorOptions {
  WebTransportErrorSource source = "stream";
  [Clamp] unsigned long? streamErrorCode = null;
};

enum WebTransportErrorSource {
  "stream",
  "session",
};

12.1. 内部スロット

WebTransportError は以下の内部スロットを持ちます。

12.2. コンストラクタ

12.3. 属性

source、型：WebTransportErrorSource、読み取り専用

getterの手順は、thisの[[Source]]を返すこと。

streamErrorCode、型：unsigned long、読み取り専用、nullable

getterの手順は、thisの[[StreamErrorCode]]を返すこと。

12.4. シリアライズ

WebTransportError オブジェクトはシリアライズ可能オブジェクトです。 そのシリアライズ手順（valueとserializedを与えて）：

1. DOMException のシリアライズ手順をvalueとserializedで実行する。

2. serialized.[[Source]]をvalue.[[Source]]に設定。

3. serialized.[[StreamErrorCode]]をvalue.[[StreamErrorCode]]に設定。

そのデシリアライズ手順（serializedとvalueを与えて）：

1. DOMException のデシリアライズ手順をserializedとvalueで実行する。

2. value.[[Source]] をserialized.[[Source]]に設定。

3. value.[[StreamErrorCode]] serialized.[[StreamErrorCode]]に設定。

13. プロトコルマッピング

この節は非規範的です。

この節では、[WEB-TRANSPORT-OVERVIEW] を用いて、本仕様で定義されるメソッドの基盤となるプロトコルの挙動を説明します。バッファリングにより、因果関係は即時でない場合があります。

下層接続がHTTP/3の場合、[WEB-TRANSPORT-HTTP3]から以下のプロトコル挙動が適用されます。

WebTransportError エラーの application streamErrorCode は、httpErrorCode に変換され、またその逆も [WEB-TRANSPORT-HTTP3] Section 4.3 に従って行われます。

注: [QUIC]の3.2節で述べられているように、 RESET_STREAMフレームやRESET_STREAM_ATフレーム（[RELIABLE-RESET]） の受信は、必ずしもアプリケーションに通知されるわけではありません。 リセットの受信は即座にシグナルされ、 ストリームデータの配信が中断され、消費されていないデータは破棄されます。 ただし、即時のシグナルは必須ではありません。 特に、RESET_STREAM_ATフレームのReliable Sizeフィールドで指定されたデータの配信を許すため、 シグナルが遅延される場合があります。 ストリームデータが完全に受信されていて、 まだアプリケーションによって読み取られていない場合には、 送信中止シグナルが抑制されることがあります。 WebTransportは常にRESET_STREAM_ATフレームを使用し、 ストリームヘッダの確実な配信を保証します。 詳細は4.1節 および4.2節 [WEB-TRANSPORT-HTTP3]参照。

基盤接続がHTTP/2を使用している場合は、 [WEB-TRANSPORT-HTTP2]に記載されているプロトコル動作が適用されます。 HTTP/3の場合とは異なり、ストリームエラーコードをHTTPエラーコードに変換する必要はありませんし、逆も同様です。

14. プライバシーおよびセキュリティに関する考慮事項

この節は非規範的であり、新しい挙動は規定せず、他の仕様部分に既に存在する情報をまとめたものです。

14.1. 通信の機密性

ネットワークを監視できる攻撃者に対して、通信が行われている事実を隠すことはできないため、これは公開情報として扱う必要があります。

本書で説明する全てのトランスポートプロトコルはTLS [RFC8446] またはそれと同等の意味を持つプロトコルを利用し、TLSの全てのセキュリティ特性（通信の機密性と完全性含む）を提供します。WebTransport over HTTPは、外向きHTTPリクエストと同じ証明書検証メカニズムを使用するため、リモートサーバーの認証に同じ公開鍵基盤に依存します。WebTransportでは、証明書検証エラーは致命的であり、証明書検証を回避するインタースティシャル（警告画面）はありません。

14.2. 状態の永続性

WebTransport自体は新しい一意な識別子や新たな永続的状態保存方法を作成せず、既存の永続的状態をサーバーに自動的に公開することもありません。例えば、[WEB-TRANSPORT-HTTP3] や [WEB-TRANSPORT-HTTP2] では、Cookieの送信やHTTP認証、キャッシュ無効化機構はサポートされません。ただしTLSを利用するため、TLSセッションチケットなどTLSの永続的状態を継承します。これは受動的ネットワーク監視者からは見えませんが、サーバー側が同じクライアントからの複数接続を関連付けるために利用できる場合があります。

14.3. プロトコルセキュリティ

WebTransportは[WEB-TRANSPORT-OVERVIEW]で記述された一連の要件を課します。主なものは以下の通りです：

1. リモートサーバーがWebTransportプロトコルの利用を認識し、WebTransportプロトコルの利用意思があることを確認すること。[WEB-TRANSPORT-HTTP3] ではALPN [RFC7301]、 HTTP/3設定、:protocol擬似ヘッダーの組み合わせでWebTransportプロトコルを特定します。[WEB-TRANSPORT-HTTP2] ではALPN、HTTP/2設定、:protocol擬似ヘッダーの組み合わせでWebTransportプロトコルを特定します。

2. サーバーが、トランスポートセッションを開始したリソースのオリジンに基づいて接続をフィルタリングできること。セッション確立リクエストの Origin ヘッダーがこの情報を伝達します。

プロトコルのセキュリティ関連事項については、 セキュリティに関する考慮事項の章で説明されています。 [WEB-TRANSPORT-OVERVIEW]のセクション6、 [WEB-TRANSPORT-HTTP3]のセクション8、 そして[WEB-TRANSPORT-HTTP2]のセクション9を参照してください。

ネットワークAPIはローカルネットワークの利用可能なホストをスキャンする用途にも使われることが多く、フィンガープリントやその他攻撃手法に利用される可能性があります。WebTransportはWebSocketのアプローチに従います：特定の接続エラーは、エンドポイントがWebTransportエンドポイントであることが検証されるまで返されません。つまりWebアプリケーションは、存在しないエンドポイントとWebからの接続受け入れ意思のないエンドポイントとを区別できません。

14.4. 証明書ハッシュによる認証

通常、ユーザーエージェントは、URLのサーバー名に対して提供されたTLSサーバー証明書の有効性を検証することで、TLS接続の認証を行います [RFC9525]。これは、ユーザーエージェントが管理する信頼できるアンカーに証明書チェーンをつなげることで達成されます。信頼アンカーは証明書内のサーバー名認証を担当します。この仕組みをWeb PKIと呼びます。

このAPIは、Webアプリケーションが、サーバー名ではなく特定のサーバー証明書で認証されたリモートネットワークエンドポイントに接続する機能を提供します。この仕組みは、長期証明書の取得が困難なエンドポイント（例：短命な仮想マシンや公開ルート不可なホスト）への接続を可能にします。この仕組みはWeb PKIベース認証の代替となるため、両者のセキュリティ特性を比較する必要があります。

リモートサーバーは、指定された証明書の公開鍵に対応する秘密鍵を保持している場合のみ、TLSハンドシェイクに成功できます。APIは証明書のハッシュで証明書を識別します。これは使用する暗号学的ハッシュ関数がセカンドプリイメージ耐性を持つ場合のみ安全です。本書で定義される唯一の関数はSHA-256であり、APIは複数のアルゴリズム-ハッシュペア指定により新たなハッシュ関数の導入手段を提供します。

Web PKIはサーバー名の信頼チェーン構築以外にも、証明書失効処理など追加のセキュリティ機構を提供します。証明書がエフェメラルな場合はこの機構は不要ですが、その他の場合は証明書ハッシュの導入方法（例：キャッシュされたHTTPリソースの場合、証明書が侵害により交換された際はキャッシュを無効化する必要がある）を検討する必要があります。Web PKIは、既知の弱い鍵を持つ証明書の拒否など、鍵生成に関する問題への対策も提供します。本仕様では特定の指針はありませんが、ブラウザは実装依存でこれらを拒否しても構いません。

Web PKIは証明書の有効期間制限を課します。これは鍵侵害の範囲を限定し、運用者が鍵ローテーションを設計・実行する仕組みとなります。WebTransportも同様の有効期間制限（最大2週間）を課します。2週間という制限は、鍵侵害の影響最小化と、デバイス間の時計ズレやクライアントとサーバー間での証明書同期コスト低減のバランスを考慮したものです。

WebTransport APIは、アプリケーションが複数の証明書ハッシュを同時に指定できるようにし、新しい証明書がロールアウトされる期間中クライアントが複数の証明書を受け入れられるようにします。

WebRTCの類似の仕組みと異なり、WebTransportのサーバー証明書ハッシュAPIはクライアント認証手段を提供しません。クライアントがサーバー証明書や接続方法を知っているだけでは十分ではなく、必要に応じてアプリケーションがバンド内でクライアントのアイデンティティを確立する必要があります。

14.5. フィンガープリントとトラッキング

このAPIはサイトにネットワーク活動を生成し、その効果を詳細に観察する能力を提供します。このように得られた情報は識別可能である可能性があります。

同様のネットワーク機能は他のWebプラットフォームAPI（例：fetchや[webrtc]）でも提供されているため、WebTransport追加によるプライバシーへの悪影響は最小限です。本節の考慮事項は他のネットワーク機能にも等しく適用されます。

ネットワーク特性の計測にはネットワーク利用とその利用効果の計測が必要であり、どちらもこのAPIによって可能となります。WebTransportはサイトに、任意のサーバーへのネットワーク活動生成および効果の観察能力を提供します。ネットワーク経路の安定した特性や動的な利用効果の両方の観察が可能です。

ネットワーク情報は、サーバー自身のネットワークスタック、クライアントによるデータ消費・送信速度、またはAPIが提供する統計情報（§ 6.13 WebTransportConnectionStats Dictionary参照）としてサーバーに直接・間接的に提供されます。そのため、ユーザーエージェントで情報制限するだけではプライバシーリスク管理には不十分な場合があります。

14.5.1. 静的観測

サイトはユーザーエージェントと選択したサーバー間の利用可能なネットワーク容量やRTT（往復遅延時間）を観測できます。これらの情報は他のトラッキング要素と組み合わせると識別性を持つ場合があります。RTTは複数地点から複数回測定することでユーザーエージェントの物理的な位置情報の一部を明らかにできる場合もあります。

ネットワークは共有されているものの、利用は断続的なことが多いため、サイトは競合や負荷の少ない経路の容量やRTTを観測できる場合があります。これらの特性は多くの人にとって安定しており、ネットワークの位置が変わらず、ボトルネック（容量決定要素）がユーザーエージェントに近い場合は特に安定します。

14.5.2. 共有ネットワーク

競合するリンクでは、サイトにクロスサイト認識 の機会が生まれ、これが非公認のトラッキング（[UNSANCTIONED-TRACKING]）に利用される恐れがあります。 ネットワーク容量は有限で共有資源のため、ユーザーエージェントが複数サイトに同時アクセスする場合、各サイトに提示されるアイデンティティの関連付けが明らかになる場合があります。

一つのサイトでネットワーク機能を使うと、他サイトで利用できる容量が減少し、ネットワークAPIを使って観測できます。ネットワーク利用やメトリクスは動的に変化し、変化はリアルタイムで観測可能です。これにより、異なるサイト上の活動が同一ユーザーによるものであるという確信度を高めることができます。

ユーザーエージェントは、アクティブでない・フォーカスされていないサイトに対して、フィードバック機構（統計情報、§ 6.13 WebTransportConnectionStats Dictionary）へのアクセスを制限・劣化させることができます。ただし、これだけではサーバーがネットワークの変化を観測することを防ぎきれません。

14.5.3. セッションのプール

共有ネットワークのシナリオと同様、セッションが単一の接続上でプールされる場合、あるセッションの情報は他のセッションの活動によって影響を受けます。別のセッションがどの程度データを送信しているかなどの情報が推論される可能性があります。

共有接続の利用は、サーバー側がセッションを関連付けることを可能にします。network partition keyを使用すると、プール利用が無効化され、共有セッションが不要なクロスサイト認識を可能にする状況を防ぐことができます。

15. 例

15.1. データグラムバッファの送信

この節は非規範的です。

データグラムのバッファ送信は、datagramsの createWritable メソッドおよびその結果のストリームのwriterを利用して実現できます。下記例では、トランスポートが送信可能な場合のみデータグラムを送信します。

async function sendDatagrams(url, datagrams) {
  const wt = new WebTransport(url);
  const writable = wt.datagrams.createWritable();
  const writer = writable.getWriter();
  for (const bytes of datagrams) {
    await writer.ready;
    writer.write(bytes).catch(() => {});
  }
  await writer.close();
}

15.2. 一定レートでデータグラム送信

この節は非規範的です。

トランスポートが送信可能かどうかに関わらず一定レートでデータグラムを送信したい場合は、datagramsの createWritable メソッドと、その結果のストリームのwriterをready属性を待たずに使えばよいです。

// 100msごとにデータグラム送信
async function sendFixedRate(url, createDatagram, ms = 100) {
  const wt = new WebTransport(url);
  const writable = wt.datagrams.createWritable();
  const writer = writable.getWriter();
  const bytes = createDatagram();
  setInterval(() => writer.write(bytes).catch(() => {}), ms);
}

15.3. データグラム受信

この節は非規範的です。

データグラムはtransport.datagrams.readable 属性から読み出すことで受信できます。null値はパケット処理が遅すぎることを示す場合があります。

async function receiveDatagrams(url) {
  const wt = new WebTransport(url);
  for await (const datagram of wt.datagrams.readable) {
    // datagramを処理
  }
}

15.4. BYOBリーダーによるデータグラム受信

この節は非規範的です。

datagrams は読み取りバイトストリームなので、バッファのコピーを避けるために より精密なバッファ割り当て制御ができるBYOBリーダーを取得できます。 この例では、64kBのメモリバッファに datagram を読み取ります。

const wt = new WebTransport(url);

for await (const datagram of wt.datagrams.readable) {
  const reader = datagram.getReader({ mode: "byob" });

  let array_buffer = new ArrayBuffer(65536);
  const buffer = await readInto(array_buffer);
}

async function readInto(buffer) {
  let offset = 0;

  while (offset < buffer.byteLength) {
    const {value: view, done} = await reader.read(
        new Uint8Array(buffer, offset, buffer.byteLength - offset));
    buffer = view.buffer;
    if (done) {
      break;
    }
    offset += view.byteLength;
  }

  return buffer;
}

15.5. ストリーム送信

この節は非規範的です。

一方向ストリームでデータを送信するには、createUnidirectionalStream 関数およびその結果のストリームのwriterを利用します。

書き込みchunkの境界は受信側で保証されません。バイトがワイヤ上で合流する可能性があるため、アプリケーションは独自フレーミングを推奨します。

async function sendData(url, ...data) {
  const wt = new WebTransport(url);
  const writable = await wt.createUnidirectionalStream();
  const writer = writable.getWriter();
  for (const bytes of data) {
    await writer.ready;
    writer.write(bytes).catch(() => {});
  }
  await writer.close();
}

エンコーディングは、ReadableStreamからpipeすることで実現できます。 例えばTextEncoderStream を用います。

async function sendText(url, readableStreamOfTextData) {
  const wt = new WebTransport(url);
  const writable = await wt.createUnidirectionalStream();
  await readableStreamOfTextData
    .pipeThrough(new TextEncoderStream("utf-8"))
    .pipeTo(writable);
}

15.6. 着信ストリームの受信

この節は非規範的です。

着信ストリームの読み出しは、incomingUnidirectionalStreams 属性を反復し、各WebTransportReceiveStream のチャンクを反復処理することで実現できます。

チャンク化はユーザーエージェントによって決定され、送信者ではありません。

async function receiveData(url, processTheData) {
  const wt = new WebTransport(url);
  for await (const readable of wt.incomingUnidirectionalStreams) {
    // 各ストリームを個別に消費し、ストリームごとのエラーを報告
    ((async () => {
      try {
        for await (const bytes of readable) {
          processTheData(bytes);
        }
      } catch (e) {
        console.error(e);
      }
    })());
  }
}

デコードは新しいWritableStreamにpipeすることで実現できます。例えば TextDecoderStream を使います。 この例ではテキスト出力が混在しないよう、1ストリームずつ読み取ります。

async function receiveText(url, createWritableStreamForTextData) {
  const wt = new WebTransport(url);
  for await (const readable of wt.incomingUnidirectionalStreams) {
    // 順次消費して出力を混在させず、ストリームごとのエラーを報告
    try {
      await readable
       .pipeThrough(new TextDecoderStream("utf-8"))
       .pipeTo(createWritableStreamForTextData());
    } catch (e) {
      console.error(e);
    }
  }
}

15.7. BYOBリーダーでストリーム受信

この節は非規範的です。

WebTransportReceiveStream は読み取りバイトストリームなので、コピーを避けるために より精密なバッファ割り当て制御ができるBYOBリーダーを取得できます。 この例では、WebTransportReceiveStream から最初の1024バイトを単一のメモリバッファに読み取ります。

const wt = new WebTransport(url);

const reader = wt.incomingUnidirectionalStreams.getReader();
const { value: recv_stream, done } = await reader.read();
const byob_reader = recv_stream.getReader({ mode: "byob" });

let array_buffer = new ArrayBuffer(1024);
const buffer = await readInto(array_buffer);

async function readInto(buffer) {
  let offset = 0;

  while (offset < buffer.byteLength) {
    const {value: view, done} = await reader.read(
        new Uint8Array(buffer, offset, buffer.byteLength - offset));
    buffer = view.buffer;
    if (done) {
      break;
    }
    offset += view.byteLength;
  }

  return buffer;
}

15.8. ストリームでトランザクションチャンク送信

この節は非規範的です。

一方向ストリームで、フロー制御でブロックせずに全体送信できる場合のみトランザクションデータを送信したい場合は、 getWriter 関数およびそのwriterを利用します。

async function sendTransactionalData(wt, bytes) {
  const writable = await wt.createUnidirectionalStream();
  const writer = writable.getWriter();
  await writer.ready;
  try {
    await writer.atomicWrite(bytes);
  } catch (e) {
    if (e.name != "AbortError") throw e;
    // フロー制御でブロックを避けるためreject
    // 非atomicな書き込みがpendingでなければwritableはエラー化されない
  } finally {
    writer.releaseLock();
  }
}

15.9. サーバー証明書ハッシュ利用

この節は非規範的です。

WebTransportセッションは、クライアント側で行われるデフォルトの信頼評価を、サーバーに提供された証明書のハッシュによるチェックで上書きできます。下記例ではhashValueは下層接続が有効とみなすべきサーバー証明書のSHA-256ハッシュを含むBufferSourceです。

const wt = new WebTransport(url, {
  serverCertificateHashes: [
    {
      algorithm: "sha-256",
      value: hashValue,
    }
  ]
});
await wt.ready;

15.10. 完全な例

この節は非規範的です。

この例はclosed/ready promiseの利用、クライアント・サーバー双方での一方向・双方向ストリームの開始、データグラムの送受信方法を示します。

wt.datagrams.writable ||= wt.datagrams.createWritable();

// ページ上のイベントログにエントリを追加し、指定CSSクラスを適用可能
// CSSクラスを任意指定

let wt, streamNumber, datagramWriter;

connect.onclick = async () => {
  try {
    const url = document.getElementById('url').value;

    wt = new WebTransport(url);
    wt.datagrams.writable ||= wt.datagrams.createWritable();
    addToEventLog('接続を開始しています...');
    await wt.ready;
    addToEventLog(`${(wt.reliability == "reliable-only")? "TCP" : "UDP"} ` +
                  `接続完了.`);
    wt.closed
      .then(() => addToEventLog('接続が正常に閉じられました。'))
      .catch(() => addToEventLog('接続が異常終了しました。', 'error'));

    streamNumber = 1;
    datagramWriter = wt.datagrams.writable.getWriter();

    readDatagrams();
    acceptUnidirectionalStreams();
    document.forms.sending.elements.send.disabled = false;
    document.getElementById('connect').disabled = true;
  } catch (e) {
    addToEventLog(`接続失敗: ${e}`, 'error');
  }
}

sendData.onclick = async () => {
  const form = document.forms.sending.elements;
  const data = sending.data.value;
  const bytes = new TextEncoder('utf-8').encode(data);
  try {
    switch (form.sendtype.value) {
      case 'datagram': {
        await datagramWriter.ready;
        datagramWriter.write(bytes).catch(() => {});
        addToEventLog(`データグラム送信: ${data}`);
        break;
      }
      case 'unidi': {
        const writable = await wt.createUnidirectionalStream();
        const writer = writable.getWriter();
        writer.write(bytes).catch(() => {});
        await writer.close();
        addToEventLog(`一方向ストリームでデータ送信: ${data}`);
        break;
      }
      case 'bidi': {
        const duplexStream = await wt.createBidirectionalStream();
        const n = streamNumber++;
        readFromIncomingStream(duplexStream.readable, n);

        const writer = duplexStream.writable.getWriter();
        writer.write(bytes).catch(() => {});
        await writer.close();
        addToEventLog(`双方向ストリーム #${n} でデータ送信: ${data}`);
        break;
      }
    }
  } catch (e) {
    addToEventLog(`送信中のエラー: ${e}`, 'error');
  }
}

// EOF到達までデータグラムをイベントログに読み出し
async function readDatagrams() {
  try {
    const decoder = new TextDecoderStream('utf-8');

    for await (const data of wt.datagrams.readable.pipeThrough(decoder)) {
      addToEventLog(`データグラム受信: ${data}`);
    }
    addToEventLog('データグラム読み取り終了！');
  } catch (e) {
    addToEventLog(`データグラム読取中のエラー: ${e}`, 'error');
  }
}

async function acceptUnidirectionalStreams() {
  try {
    for await (const readable of wt.incomingUnidirectionalStreams) {
      const number = streamNumber++;
      addToEventLog(`新しい着信一方向ストリーム #${number}`);
      readFromIncomingStream(readable, number);
    }
    addToEventLog('着信一方向ストリーム受付終了！');
  } catch (e) {
    addToEventLog(`ストリーム受付中エラー ${e}`, 'error');
  }
}

async function readFromIncomingStream(readable, number) {
  try {
    const decoder = new TextDecoderStream('utf-8');
    for await (const data of readable.pipeThrough(decoder)) {
      addToEventLog(`ストリーム #${number} でデータ受信: ${data}`);
    }
    addToEventLog(`ストリーム #${number} 閉じました`);
  } catch (e) {
    addToEventLog(`ストリーム #${number} 読取中のエラー: ${e}`, 'error');
    addToEventLog(`    ${e.message}`);
  }
}

function addToEventLog(text, severity = 'info') {
  const log = document.getElementById('event-log');
  const previous = log.lastElementChild;
  const entry = document.createElement('li');
  entry.innerText = text;
  entry.className = `log-${severity}`;
  log.appendChild(entry);

  // ログの直前のエントリが可視なら、新しい要素までスクロール
  if (previous &&
      previous.getBoundingClientRect().top < log.getBoundingClientRect().bottom) {
    entry.scrollIntoView();
  }
}

16. 謝辞

WebTransport インターフェイスは、W3C ORTC CGで最初に記述された QuicTransport インターフェイスに基づいており、本仕様に合わせて適合・拡張されています。