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セッション session が排出中とは、CONNECTストリームが サーバにより正常にクローズするよう要求された場合を指す（詳細は [WEB-TRANSPORT-OVERVIEW] セクション 4.1 参照）。

終了するには、オプションの整数 code およびオプションのバイト列 reason と共に WebTransportセッション session を 終了するには、[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 オブジェクトは以下の内部スロットを持ちます。

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 を実行しなければならない。アルゴリズムが進行可能な場合はできる限り早く実行すべきである。

注記: トランスポートの [[State]] が "connecting" の間もデータグラムの書き込みは許可されている。 データグラムは [[OutgoingDatagramsQueue]] に格納され、 "connected"状態と同じ方法で 破棄できる。トランスポートの [[State]] が "connected" になった時、キューに格納されたデータグラムの送信が開始される。

送信順序ルール とは、送信は通常、このトランスポートで送信予定のキュー済みストリームやデータグラム、そしてこれからキューされるストリームやデータグラムと インターリーブできるが、同じ [[SendGroup]] かつ [[SendOrder]] がより高い値のストリームやデータグラムで、 エラーではなく、フロー制御によって ブロックされていないものの送信されるまで、送信は阻害されなければならない。

注記: デフォルトの null sendGroup は有効な sendGroup である。

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 unsigned long incomingMaxBufferedDatagrams;
  attribute unsigned long outgoingMaxBufferedDatagrams;
};

5.1. 内部スロット

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

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

5.2. メソッド

createWritable()

WebTransportDatagramsWritableを作成する。

createWritable() メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない：

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

2. もし transport.[[State]] が "closed" または "failed" であれば、 throw を行い、InvalidStateErrorとする。

3. sendGroup を options の sendGroup とする。

4. もし sendGroup が null でなく、かつ sendGroup.[[Transport]] が this.[[Transport]] でない場合、 throw を行い、InvalidStateErrorとする。

5. sendOrder を options の sendOrder とする。

6. transport、sendGroup、sendOrder を用いて 作成される WebTransportDatagramsWritable の結果を返す。

5.3. 属性

readable、 ReadableStream 型、readonly

ゲッター手順は次の通り：

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

incomingMaxAge、 unrestricted double 型、nullable

ゲッター手順：

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

セッター手順、value を与えた場合：

1. value が負または NaN の場合、throw RangeError。

2. value が 0 の場合、value を null にする。

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

maxDatagramSize、 unsigned long 型、readonly

WebTransportDatagramsWritable に渡すことができる最大データサイズ。 ゲッター手順は this.[[OutgoingMaxDatagramSize]] を返すこと。

outgoingMaxAge、 unrestricted double 型、nullable

ゲッター手順：

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

セッター手順、value を与えた場合：

1. value が負または NaN の場合、 throw RangeError

2. value が 0 の場合、value を null にする。

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

incomingMaxBufferedDatagrams、 unsigned long 型

ゲッター手順：

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

セッター手順、value を与えた場合：

1. valueが 1 より小さい場合、value を 1 にする。

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

outgoingMaxBufferedDatagrams、 unsigned long 型

ゲッター手順：

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

セッター手順、value を与えた場合：

1. valueが 1 より小さい場合、value を 1 にする。

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

5.4. 手順

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

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

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

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

4. queue が空の場合：

   1. datagrams.[[IncomingDatagramsPullPromise]] を新しい promise に設定する。

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

5. datagram と timestamp を queue から dequeue した結果とする。

6. datagrams.[[ReadableType]] が "bytes" の場合：

   1. datagrams.[[Readable]] の current BYOB request view が null でない場合：

      1. view を datagrams.[[Readable]] の current BYOB request view とする。

      2. view の byte length が datagram のサイズより小さい場合、 RangeError で reject された promise を返す。

      3. elementSize を typed array constructors table の view.[[TypedArrayName]] に指定された要素サイズとする。 view が [[TypedArrayName]] 内部スロットを持たない場合（つまり DataView の場合）、 elementSize を 0 とする。

      4. elementSize が 1 でない場合、TypeError で reject された promise を返す。

   2. Pull from bytes datagram を datagrams.[[Readable]] に取り込む。

7. それ以外の場合：

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

   2. Enqueue chunk を transport.[[Datagrams]].[[Readable]] に追加する。

8. Promise を undefined で resolve して返す。

receiveDatagrams の手順は、 WebTransport オブジェクト transport を指定して次の通り：

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

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

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

4. duration が null なら 実装依存の値に設定する。

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

6. session 上で 受信可能なデータグラム がある間：

   1. datagram を receive a datagram の結果とする。

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

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

   4. Enqueue chunk を queue に追加する。

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

8. toBeRemoved が正の値の場合、dequeue を queue に対して toBeRemoved（切り捨てで）回繰り返す。

9. queue が空でない間：

   1. bytes と timestamp を queue の先頭要素とする。

   2. timestamp から duration ミリ秒以上経過していたら dequeue queue を行う。

   3. そうでない場合、このループを break する。

10. queue が空でなく、かつ datagrams.[[IncomingDatagramsPullPromise]] が null でない場合：

    1. bytes と timestamp を queue から dequeue した結果とする。

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

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

    4. ネットワークタスクをキューし、transport に対して以下を実行する：

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

       2. Enqueue chunk を datagrams.[[Readable]] に追加する。

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

ユーザーエージェントは、receiveDatagrams を WebTransport オブジェクトで [[State]] が "connected" の場合、アルゴリズムが進行可能なときはできるだけ速やかに実行すべきである。

6. WebTransport インターフェース

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

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

  Promise<WebTransportConnectionStats> getStats();
  [NewObject] Promise<Uint8Array> exportKeyingMaterial(BufferSource label, optional BufferSource context);
  readonly attribute Promise<undefined> ready;
  readonly attribute WebTransportReliabilityMode reliability;
  readonly attribute WebTransportCongestionControl congestionControl;
  attribute [EnforceRange] unsigned short? anticipatedConcurrentIncomingUnidirectionalStreams;
  attribute [EnforceRange] unsigned short? anticipatedConcurrentIncomingBidirectionalStreams;
  [SameObject] readonly attribute Headers? responseHeaders;
  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. 内部スロット

A WebTransport オブジェクトは以下の内部スロットを持つ。

6.2. コンストラクター

6.3. 属性

ready, of type Promise<undefined>, readonly

取得時、this の [[Ready]] を返す必要がある。

closed, of type Promise<WebTransportCloseInfo>, readonly

取得時、this の [[Closed]] を返す必要がある。

draining, of type Promise<undefined>, readonly

取得時、this の [[Draining]] を返す必要がある。

datagrams, of type WebTransportDatagramDuplexStream, readonly

このセッションでデータグラムの送受信を行うための単一のデュプレックスストリーム。 datagrams 属性のゲッター手順は次の通りとする：

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

incomingBidirectionalStreams, of type ReadableStream, readonly

ReadableStream で、サーバから受信したWebTransportBidirectionalStreamのストリームを返す。

Note: 着信ストリームに既にデータがあるかどうかはサーバの動作による。

incomingBidirectionalStreams 属性のゲッター手順は：

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

incomingUnidirectionalStreams, of type ReadableStream, readonly

サーバから受信した各WebTransportReceiveStream で表される単方向ストリームのReadableStream。

Note: 着信ストリームに既にデータがあるかどうかはサーバの動作による。

incomingUnidirectionalStreamsのゲッター手順：

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

reliability, of type WebTransportReliabilityMode, readonly

このコネクションが信頼性なし（UDP経由）転送をサポートするか、信頼性あり（TCPフォールバック）転送のみサポートするか。 接続確立までは"pending"を返す。 ゲッター手順は this の [[Reliability]]を返す。

congestionControl, of type WebTransportCongestionControl, readonly

アプリケーションがコンストラクタで指定し、ユーザーエージェントに満たされた場合はスループット最適化または低遅延最適化の輻輳制御アルゴリズムを示す。満たされない場合は値は"default"となる。 ゲッター手順は this の [[CongestionControl]] を返す。

supportsReliableOnly, of type boolean, readonly

ユーザーエージェントがWebTransportセッション を信頼性のみのコネクション上でサポートする場合はtrue、そうでなければfalseを返す。

anticipatedConcurrentIncomingUnidirectionalStreams, of type unsigned short, nullable

アプリがサーバで同時オープンされると予測する 着信単方向ストリーム数を指定できる。 nullでなければ、ユーザーエージェントは [[AnticipatedConcurrentIncomingUnidirectionalStreams]] をサーバとのネゴシエーションで考慮しラウンドトリップ削減を試みるべきである。

ゲッター手順は this の [[AnticipatedConcurrentIncomingUnidirectionalStreams]] を返す。

セッター手順（value 時）は this の [[AnticipatedConcurrentIncomingUnidirectionalStreams]] に value を設定する。

anticipatedConcurrentIncomingBidirectionalStreams, of type unsigned short, nullable

アプリがサーバで同時オープンされると予測する 双方向ストリーム数を指定できる。 nullでなければ、ユーザーエージェントは [[AnticipatedConcurrentIncomingBidirectionalStreams]] をサーバとのネゴシエーションで考慮しラウンドトリップ削減を試みるべきである。

ゲッター手順は this の [[AnticipatedConcurrentIncomingBidirectionalStreams]] を返す。

セッター手順（value 時）は this の [[AnticipatedConcurrentIncomingBidirectionalStreams]] に value を設定する。

Note: anticipatedConcurrentIncomingUnidirectionalStreams または anticipatedConcurrentIncomingBidirectionalStreams を設定しても、アプリが予測する本数のストリームを必ず受信できる保証はない。

responseHeaders、 Headers 型、readonly、nullable

WebTransportセッションが確立された後、 サーバーによって設定されたアプリケーションレベルのレスポンスヘッダーを保持します（あれば）。初期値はnullです。 ゲッター手順は this の [[ResponseHeaders]] を返すことです。

protocol、 DOMString 型、readonly

WebTransportセッションが確立され、 コンストラクタオプション protocols に空でない配列が渡された場合は、サーバーによって選択されたアプリケーションレベルプロトコルを返します（あれば）。 それ以外の場合は空文字列を返します。 ゲッター手順は this の [[Protocol]] を返すことです。

6.4. メソッド

getStats()

この WebTransport の 基盤コネクション の統計情報を収集し、結果を非同期で返します。

getStatsが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない：

1. transport を this とする。

2. p を新しいpromiseにする。

3. transport.[[State]] が "failed" なら、reject p を InvalidStateError で返し、この手順を中止。

4. 並列処理で以下を実行：

   1. transport.[[State]] が "connecting" なら、状態が変化するまで待つ。

   2. transport.[[State]] が "failed" なら、 ネットワークタスクをキューして transport に reject p を InvalidStateError で返してこの手順を中止。

   3. transport.[[State]] が "closed" なら、 ネットワークタスクをキュー して transport に resolve p コネクションの最新統計情報で返しこの手順を中止。統計収集時点は 実装依存である。

   4. gatheredStats を リストとして 基盤コネクションに固有で WebTransportConnectionStats と WebTransportDatagramStats の辞書メンバーを正確に埋めるために必要な統計情報を集めたものとする。

   5. ネットワークタスクをキューして transport に次の手順を実行：

      1. stats を 新規 WebTransportConnectionStats オブジェクトとする。

      2. datagramStats を 新規 WebTransportDatagramStats オブジェクトとする。

      3. stats["datagrams"] に datagramStats を設定。

      4. ユーザーエージェントが公開したい stats および datagramStats の各 メンバーについて、 set member に対応する エントリを gatheredStats から設定。

      5. resolve p を stats で返す。

5. p を返す。

exportKeyingMaterial(BufferSource label, optional BufferSource context)

この WebTransport の TLS Keying Material Exporter が一意に関連付けられたTLSセッションからキー素材をエクスポートします。 基盤コネクション を用いる。

exportKeyingMaterialが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない：

1. transport を this とする。

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

3. labelLength が255を超える場合、RangeErrorでrejectされたpromise を返す。

4. contextLength を0とする。

5. context が指定された場合、contextLength を context.バイト長 に設定。

6. contextLength が255を超える場合、RangeErrorでrejectされたpromise を返す。

7. p を新しいpromiseにする。

8. 並列処理で以下を実行（ただし abort when transport の [[State]] が "closed" または "failed" となった場合は ネットワークタスクをキューして transport に reject p を InvalidStateError で返す）：

   1. keyingMaterial を Uint8Array とし [WEB-TRANSPORT-OVERVIEW] Section 4.1 のTLSキーエクスポーターを labelLength, label, contextLength, context（あれば）で呼び出して得る。

   2. ネットワークタスクをキューして transport に resolve p を keyingMaterial で返す。

9. p を返す。

createBidirectionalStream()

送信用双方向ストリームの WebTransportBidirectionalStream オブジェクトを生成します。ストリーム作成しただけでは相手ピア側にはすぐ反映されず、データ送信時に認識されます。

注記: サーバーがストリームの存在を認識するのはデータが送信されてからです。

createBidirectionalStreamを呼び出したとき、ユーザーエージェントは次の手順を実行しなければならない：

1. this.[[State]] が "closed" または "failed" なら、 新しい reject promise を InvalidStateError で返す。

2. sendGroup を options の sendGroup とする。

3. sendGroup が null でない、かつ sendGroup.[[Transport]] が this と異なっていれば throw InvalidStateError を投げる。

4. sendOrder を options の sendOrder とする。

5. waitUntilAvailable を options の waitUntilAvailable とする。

6. p を新しいpromiseにする。

7. transport を this とする。

8. 並列処理で以下を実行（ただし abort when transport の [[State]] が "closed" または "failed" となった場合は ネットワークタスクをキューして transport に reject p を InvalidStateError で返す）：

   1. streamId を transport.[[Session]] 用に新規でかつ一意なストリームIDにする。 [QUIC] Section 19.11 に定義。 すぐ得られない場合、waitUntilAvailable が true なら入手まで待つ。 false なら ネットワークタスクをキューして transport に reject p を QuotaExceededError requested/quota両方nullで返しこの手順を中止。

   2. internalStream を bidirectional stream作成 の結果 (transport.[[Session]], streamId) とする。

   3. ネットワークタスクをキュー して transport に次を実行：

      1. transport.[[State]] が "closed" または "failed" なら reject p を InvalidStateError で返しこの手順を中止。

      2. stream を bidirectionalStream作成 の結果 (internalStream, transport, sendGroup, sendOrder) とする。

      3. resolve p を streamで返す。

9. p を返す。

createUnidirectionalStream()

送信用単方向ストリームの WebTransportSendStream を生成します。ストリームを作成しただけではサーバー側にはすぐ認識されません。データ送信時に認識されます。

注記: サーバーがストリームの存在を認識するのはデータが送信されてからです。

createUnidirectionalStream()メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない：

1. this.[[State]] が "closed" または "failed" なら 新しい reject promise を InvalidStateError で返す。

2. sendGroup を options の sendGroup とする。

3. sendGroup が null でない、かつ sendGroup.[[Transport]] が this と異なっていれば throw InvalidStateError を投げる。

4. sendOrder を options の sendOrder とする。

5. waitUntilAvailable を options の waitUntilAvailable とする。

6. p を新しいpromiseにする。

7. transport を this とする。

8. 並列処理で以下を実行（ただし abort when transport の [[State]] が "closed" または "failed" となった場合は ネットワークタスクをキューして transport に reject p を InvalidStateError で返す）：

   1. streamId を transport.[[Session]] 用に新規でかつ一意なストリームIDとする。 [QUIC] Section 19.11 に定義。 すぐ得られない場合、waitUntilAvailable が true なら入手まで待つ。 false なら ネットワークタスクをキューして transport に reject p を QuotaExceededError で返しこの手順を中止。

   2. internalStream を 単方向ストリーム作成 の結果 (transport.[[Session]], streamId) とする。

   3. ネットワークタスクをキュー して transport に次を実行：

      1. transport.[[State]] が "closed" または "failed" なら reject p を InvalidStateError で返しこの手順を中止。

      2. stream を WebTransportSendStream作成 の結果 (internalStream, transport, sendGroup, sendOrder) とする。

      3. resolve p を stream で返す。

9. p を返す。

createSendGroup()

WebTransportSendGroup を生成します。

createSendGroup()メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない：

1. this.[[State]] が "closed" または "failed" なら throw InvalidStateError を投げる。

2. WebTransportSendGroup作成 の結果を this を引数にして返す。

6.5. 手順

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

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

この仕様では、コンテキストクリーンアップ手順を以下の手順として定義する。 WebTransport transport が与えられた場合:

1. もし transport.[[State]] が "connected" なら、次を行う:

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

   2. 並行して、terminate を transport.[[Session]] に対して実行する。

   3. ネットワークタスクをキューに入れる。transport を与え、次の手順を実行する:

      1. error を、新たに 作成された WebTransportError とし、 その source は "session" とする。

      2. Cleanup を transport に対して error を用いて行う。

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

   これはワーカーでも実施する必要がある。次を参照: #127 および whatwg/html#6731。

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

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

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

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

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

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

6.9. 設定

dictionary WebTransportHash {
  required DOMString algorithm;
  required BufferSource value;
};

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

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

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

allowPooling、 boolean 型、初期値は false

true に設定すると、WebTransport セッションはプーリング可能（他の WebTransport セッションと 基盤コネクション を共有可能）になります。

requireUnreliable、 boolean 型、初期値は false

true に設定すると、WebTransport セッション は HTTP/2 の connection では確立できなくなり、 HTTP/3 の connection が不可能な場合は失敗します。

headers、 HeadersInit 型、初期値は {}

オプションで、Headers オブジェクトやオブジェクトリテラル、二要素配列の配列として指定可能。 request の header list は、この値で セッション確立 時に利用される。

serverCertificateHashes、 sequence<WebTransportHash> 型、初期値 []

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

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

これは allowPooling との併用は不可です。

congestionControl、 WebTransportCongestionControl 型、 初期値 "default"

オプションで、アプリケーションがスループット最適化または低遅延に特化した輻輳制御アルゴリズムを希望する場合に指定。 この値はユーザーエージェントへのヒントとなります。

この設定オプションはブラウザで低遅延向け輻輳制御アルゴリズムが実装されていないため危険扱い（at risk）です。

anticipatedConcurrentIncomingUnidirectionalStreams、 unsigned short 型、nullable、初期値 null

オプションで、アプリケーションがサーバーにより同時生成される 受信単方向ストリーム数を指定できます。 ユーザーエージェントは、サーバーから最低100の 受信単方向 ストリームを初期状態で許可します。 nullでない場合、ラウンドトリップ削減のため [[AnticipatedConcurrentIncomingUnidirectionalStreams]] をサーバーとの協議時に考慮しようとします。

anticipatedConcurrentIncomingBidirectionalStreams、 unsigned short 型、nullable、初期値 null

オプションで、アプリケーションがサーバーにより同時生成される 双方向ストリーム数を指定できます。 ユーザーエージェントは、サーバーが最低100の 双方向ストリームを生成可能とします。 nullでない場合、ラウンドトリップ削減のため [[AnticipatedConcurrentIncomingBidirectionalStreams]] をサーバーとの協議時に考慮しようとします。

protocols、 sequence<DOMString> 型、初期値 []

アプリケーションレベルの プロトコル名配列（オプション）。 サーバー側は推奨プロトコルを選択してクライアントに通知するか任意。適切なプロトコルが指定されなかった場合リクエスト拒否もあり得ます。

datagramsReadableType、 ReadableStreamType 型

オプションで、受信データグラム用の readable byte stream を使いたい場合に指定。 未指定ならデフォルトの readable stream が用いられます。

注記: readable stream はデータグラムの意味論と互換性がありますが、 readable byte stream はそうではありません。データグラムは意味のあるメッセージ（0以上バイト）で順不同に到達するため、単なるバイト列とは異なります。 空のデータグラムは失われますし、 min ではメッセージの区切りが失われます。

カスタム証明書要件は次のとおりである: 証明書は[RFC5280]で定義される X.509v3 証明書でなければならず、 Subject Public Key フィールドで使用される鍵は許可された公開鍵アルゴリズムのいずれかでなければならない。 現在時刻は、[RFC5280] のセクション 4.1.2.5 で定義される証明書の有効期間内でなければならず、 有効期間の総期間は 2 週間を超えてはならない。ユーザーエージェントは証明書に対して追加の 実装定義の要件を課すことができる。

Subject Public Key Info フィールド（その結果として TLS の CertificateVerify メッセージにおいて）で使用される許可された公開鍵アルゴリズムの正確なリストは実装定義である。しかし、相互運用可能な既定とするために、secp256r1（NIST P-256）名前付きグループを用いた ECDSA（[RFC3279]、 セクション 2.3.5；[RFC8422]）を含めなければならない。 RSA 鍵（[RFC3279]、 セクション 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セッションが同一の connection上でプールされ、 全て同じ情報を受け取ります。つまり、この情報は同一 セッション間で ネットワークパーティションキー を保持している場合公開されます。

注記: 利用できない統計情報は mapに存在しない状態で WebTransportConnectionStats 辞書に入ります。

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

この辞書は以下の属性を持つものとする：

bytesSent、 unsigned long long 型

基盤コネクションで送信されたペイロードバイト数（フレームや再送オーバーヘッド除く）。

bytesSentOverhead、 unsigned long long 型

bytesSent バイトのペイロードを 基盤コネクション 上で送信した際のフレーミング・再送オーバーヘッド（バイト単位）。

bytesAcknowledged、 unsigned long long 型

QUIC の ACK 機構によりサーバーから受領確認されたペイロードバイト数（フレーム除く）。 基盤コネクションでの値。

注記: 通常は bytesSent より遅れますが、パケットロスにより永続的に小さいこともあります。

bytesAcknowledged （WebTransportConnectionStats 内）は実装懸念があり、Working Group により危険扱いとなっています。

packetsSent、 unsigned long long 型

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

bytesLost、 unsigned long long 型

基盤コネクションで失われたバイト数 （UDPなど外部フレームは含まず。パケットが失われた後で受信されることもあり、単調増加でない）。

packetsLost、 unsigned long long 型

基盤コネクションで失われたパケット数 （パケットが失われた後で受信されることもあり、単調増加でない）。

bytesReceived、 unsigned long long 型

基盤コネクションで受信したバイト数（ストリームの重複データ含む。UDP等外部フレーム除く）。

packetsReceived、 unsigned long long 型

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

smoothedRtt、 DOMHighResTimeStamp 型

現在観測されている往復遅延（RTT）の平滑値。 [RFC9002] Section 5.3 の定義。

rttVariation、 DOMHighResTimeStamp 型

現在観測されている往復遅延サンプルの平均変動値。 [RFC9002] Section 5.3 の定義。

minRtt、 DOMHighResTimeStamp 型

コネクション全体で観測された最低往復遅延。 [RFC9002] Section 5.2 の定義。

estimatedSendRate、 unsigned long long 型、nullable、初期値 null

ユーザーエージェントによる送信予定データの推定レート（bps）。 このレートは WebTransportセッション を共有する全ストリーム・データグラムに適用され、 輻輳制御アルゴリズム（ congestionControl で決まる可能性あり） により算出される。フレーミングオーバーヘッドを除外し、 アプリケーションペイロードとして送信され得る速度を表す。 推定値がない場合は null。 過去は nullでなかった場合も、現時点でnullになり得る。

atSendCapacity、 boolean 型、初期値 false

false の場合、estimatedSendRate はアプリケーション側制限値である可能性（輻輳制御よりもアプリ側がずっと少ないデータしか送信していない場合）。 アプリ制限時、輻輳制御はネットワーク容量の推定値が不正確になり得る。

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

atSendCapacity が true の場合、 estimatedSendRate は上限値（ceiling）を反映します。 アプリ送信レートが持続している限り、 estimatedSendRate はネットワーク状況に適応します。 ただし estimatedSendRate は null になり得ます（ atSendCapacity が true の時でも）。

6.14. WebTransportDatagramStats辞書

WebTransportDatagramStats 辞書には 基盤コネクション 上のデータグラム送受信に関する統計が含まれる。

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

この辞書は以下の属性を持つものとする：

droppedIncoming, 型 unsigned long long

アプリケーションがdatagramsの readable から読み出す前に、受信キューが新しいデータグラムであふれてしまったために廃棄された受信データグラムの数。

expiredIncoming, 型 unsigned long long

incomingMaxAge よりも古くなったため、datagramsの readable から読み出される前に廃棄された受信データグラムの数。

expiredOutgoing, 型 unsigned long long

送信待ちキュー内のデータグラムがoutgoingMaxAge よりも古くなったため送信される前に廃棄された数。

lostOutgoing, 型 unsigned long long

送信済みデータグラムのうちロスト（[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

ゲッター手順：

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

セッター手順（value を与えた場合）：

1. value が null でなく、 value.[[Transport]] が this の [[Transport]] と異なる場合、 throw InvalidStateError を投げる。

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

sendOrder、 long long 型

ゲッター手順：

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

セッター手順（value を与えた場合）：

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

7.2. メソッド

getStats()

この WebTransportSendStream の性能に関する統計情報を収集し、 非同期で結果を報告します。

getStatsが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない：

1. p を新しいPromiseとする。

2. 並列処理で以下実行：

   1. gatheredStats をリストとして、 this WebTransportSendStream の統計情報で WebTransportSendStreamStats の 辞書メンバーを正確に埋めるために必要なものとする。

   2. ネットワークタスクをキューして transport に次を実行：

      1. stats を新規 WebTransportSendStreamStats オブジェクトとする。

      2. statsの各メンバーで ユーザーエージェントが公開したいものについて set member に gatheredStatsの対応する 値を設定する。

      3. resolve p を statsで返す。

3. p を返す。

getWriter()

このメソッドは、 getWriter （WritableStreamから継承） と同様に実装されますが、 WritableStreamDefaultWriter を作成する代わりに、 WebTransportWriter を this で 作成しなければなりません。

7.3. 内部スロット

WebTransportSendStream は以下の内部スロットを持つ。

7.4. 手続き

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

7.6. WebTransportSendStreamStats辞書

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

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

この辞書は以下の属性を持つものとする：

bytesWritten, 型 unsigned long long

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

bytesSent, 型 unsigned long long

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

Note: これは単一ストリームで送信されたアプリデータの進捗のみを示し、ネットワークのオーバーヘッドは含まない。

bytesAcknowledged, 型 unsigned long long

この WebTransportSendStream に書き込み済みのアプリケーションバイトがサーバのQUIC ACK機構で送信・受信確認されたバイトの進捗指標。最初の未確認バイト未満までの連続したバイトのみをカウント。この値は増加のみ行われ、常に bytesSent 以下となる。

Note: この値はコネクションがHTTP/2の場合、 bytesSent と一致する。

8. インターフェイス WebTransportSendGroup

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

WebTransportSendStream や WebTransportDatagramsWritable は、 作成時または sendGroup 属性の割り当てによって、任意の時点で最大１つの WebTransportSendGroup または null sendGroup の下でグループ化されます。 デフォルトでは、WebTransportSendStream や WebTransportDatagramsWritable は null sendGroup に割り当てられます。

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

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

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

8.1. メソッド

getStats()

この WebTransportSendStream を grouped した全ストリームの統計情報を集計し、 結果を非同期で報告します。

getStatsが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない：

1. p を新しいpromiseとする。

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

3. 並列処理で以下を実行：

   1. gatheredStats を、streams内のすべてのストリームから集計した統計情報の リストとして、 WebTransportSendStreamStats の 辞書メンバーを正確に埋めるために必要なものとする。

   2. ネットワークタスクをキューして transport に以下を実行：

      1. stats を新規 WebTransportSendStreamStats オブジェクトとする。

      2. statsの各メンバーで ユーザーエージェントが公開したいものについて set member に gatheredStatsの対応する 値を設定する。

      3. resolve 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. p を新しい Promise とする。

2. 次の手順を 並行して実行する:

   1. gatheredStats を、リスト（this WebTransportReceiveStream に特化した統計）とし、WebTransportReceiveStreamStats の辞書メンバーを正確に埋めるために必要なものとする。

   2. ネットワークタスクをキューに入れ、transport を用いて次の手順を実行する:

      1. stats を、new な WebTransportReceiveStreamStats オブジェクトとする。

      2. ユーザーエージェントが公開したい stats の各メンバー member について、set を行い、gatheredStats 内の対応するエントリに設定する。

      3. Resolve を行い、p を stats で解決する。

3. p を返す。

9.2. 内部スロット

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

9.3. 手続き

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

9.5. WebTransportReceiveStreamStats辞書

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

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

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

bytesReceived, 型 unsigned long long

サーバアプリケーションがこの WebTransportReceiveStream に対して送信しようとしたバイトのうち、これまでに受信された進捗を示す指標。 連続している最初の欠損バイト直前までのバイトのみがカウントされる。この値は増加のみ行われる。

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

bytesRead, 型 unsigned long long

アプリケーションがこの 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 型、readonly

ゲッター手順は、this の [[Readable]] を返すことです。

writable、 WebTransportSendStream 型、readonly

ゲッター手順は、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. メソッド

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、読み取り専用

ゲッター手順は、this の [[Source]] を返すことです。

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

ゲッター手順は、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 の設定、そして WebTransport プロトコルを識別するための :protocol 擬似ヘッダーの組み合わせを用いる。[WEB-TRANSPORT-HTTP2] では、ALPN、HTTP/2 の設定、 そして WebTransport プロトコルを識別するための :protocol 擬似ヘッダーの組み合わせを用いる。

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リーダー を取得できる。この例では64キビバイトのメモリバッファにデータグラムを読み出している。

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();
  }
}