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で説明されています。

終了するには、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 オブジェクトは以下の内部スロットを持ちます。

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" である場合に更新してもよい。

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, of type ReadableStream, readonly

ゲッター手順は以下の通り：

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

incomingMaxAge, of type unrestricted double, nullable

ゲッター手順は以下の通り：

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

セッター手順（value が与えられた場合）：

1. もし value が負または NaN なら、throw し、 RangeError とする。

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

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

maxDatagramSize, of type unsigned long, readonly

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

outgoingMaxAge, of type unrestricted double, nullable

ゲッター手順は以下の通り：

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

セッター手順（value が与えられた場合）：

1. もし value が負または NaN なら、throw し、 RangeError とする。

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

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

incomingHighWaterMark, of type unrestricted double

ゲッター手順は以下の通り：

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

セッター手順（value が与えられた場合）：

1. もし value が負または NaN なら、throw し、 RangeError とする。

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

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

outgoingHighWaterMark, of type unrestricted double

ゲッター手順は以下の通り：

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

セッター手順（value が与えられた場合）：

1. もし value が負または NaN なら、throw し、 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]] に新しいpromiseを設定する。

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

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

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のサイズより小さいなら、 promise rejected（失敗promise）を RangeErrorで返す。

      3. typed array constructors tableの view.[[TypedArrayName]]で指定されたelement sizeをelementSizeとする。viewが [[TypedArrayName]]の内部スロットを持たない場合（DataViewの場合）、elementSizeは0とする。

      4. もしelementSizeが1でなければ promise rejected（失敗promise）を TypeErrorで返す。

   2. Pull from bytesで datagramをdatagrams.[[Readable]]にpullする。

7. それ以外：

   1. chunkをUint8Array でdatagramを表現した新規オブジェクトとする。

   2. Enqueueで chunkを transport.[[Datagrams]].[[Readable]]にenqueueする。

8. promise resolved（成功promise）で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. Enqueueでchunkをqueueにenqueueする。

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

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

9. queueが空でない間：

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

   2. もしtimestampからdurationミリ秒より長く経過していたら、queueからデキューする。

   3. それ以外は、このループをbreakする。

10. もしqueueが空でなく、かつdatagrams.[[IncomingDatagramsPullPromise]] が非nullなら：

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

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

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

    4. Queue a network taskで transportで次の手順を実行：

       1. chunkをUint8Array でbytesを表現した新規オブジェクトとする。

       2. Enqueueでchunkを datagrams.[[Readable]]にenqueueする。

       3. promise 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<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. 内部スロット

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 を設定しても、アプリが予測する本数のストリームを必ず受信できる保証はない。

protocol, of type 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 の member ごとに、 set で gatheredStats の対応する エントリを設定する。

      5. resolve で 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 より大きい場合、promise rejected を RangeError で返す。

4. contextLength を 0 とする。

5. もし context が指定されていれば、contextLength を context のバイト長に設定する。

6. もし contextLength が 255 より大きい場合、promise rejected を RangeError で返す。

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

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

   1. keyingMaterial をエクスポートされた TLS キー情報として取得する（[WEB-TRANSPORT-OVERVIEW] Section 4.1に従う）、labelLength、label、contextLength、context（ある場合）を使う。

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

9. p を返す。

createBidirectionalStream()

送信用の WebTransportBidirectionalStream オブジェクトを作成する。ストリームの作成だけではピアにはすぐに認識されず、データ送信を伴って初めて認識される。

Note: サーバはデータ送信があるまでこのストリームの存在を認識しない。

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

1. もし this.[[State]] が "closed" または "failed" なら、 新しい rejected 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 を bidirectional stream の作成で transport.[[Session]] および streamId を渡して得る。

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

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

      2. stream を 作成した WebTransportBidirectionalStream （internalStream, transport, sendGroup, sendOrder渡す） とする。

      3. resolve で p を stream で解決する。

9. p を返す。

createUnidirectionalStream()

送信用の WebTransportSendStream を作成する。ストリームの作成だけではサーバにはすぐに認識されず、データ送信で初めて認識される。

Note: サーバはデータ送信があるまでこのストリームの存在を認識しない。

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

1. もし this.[[State]] が "closed" または "failed" なら、 新しい rejected 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;
  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, of type boolean, defaulting to false

true の場合、WebTransport セッションはプール可能（複数 WebTransport セッション間で 基盤コネクション の共有が可能）となる。

requireUnreliable, of type boolean, defaulting to false

true の場合、HTTP/3 connection が不可の場合、WebTransport セッションは HTTP/2 connection 上では確立されない。

serverCertificateHashes, of type sequence<WebTransportHash>, defaulting to []

このオプションは専用コネクション利用時のみサポートされる。 この機能が未サポートのトランスポートプロトコルで本フィールドが空でない場合は NotSupportedError 例外がスローされる。

サポートされており非空の場合、ユーザーエージェントは 証明書ハッシュの検証が serverCertificateHashes で一致し、カスタム証明書要件も満たす場合に限り サーバ証明書を信頼すべきである。未知のalgorithm のハッシュは無視される。 空の場合は通常の fetch 操作時と同じ証明書検証を行う。

これは allowPooling と併用できない。

congestionControl, of type WebTransportCongestionControl, defaulting to "default"

データ送信時に利用する輻輳制御アルゴリズムについて、 スループット最適/低遅延最適どちらをアプリが好むかヒントとして指定できる。これはユーザーエージェントへのヒント。

この構成オプションは、低遅延最適アルゴリズムのブラウザー実装が当時存在しないため、リスクのあるフィーチャーとされている。

anticipatedConcurrentIncomingUnidirectionalStreams, of type unsigned short, nullable, defaulting to null

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

anticipatedConcurrentIncomingBidirectionalStreams, of type unsigned short, nullable, defaulting to null

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

protocols, of type sequence<DOMString>, defaulting to []

アプリケーションレベルの プロトコル名 を格納する配列を省略可能で指定できる。サーバ側でプロトコル選択と通知は任意。 適切なプロトコルが指定されていなければサーバはリクエストを拒否することがある。

datagramsReadableType, of type ReadableStreamType

アプリの受信データグラム用に readable byte stream の利用を希望する場合に指定できる。 指定しなければデフォルトで readable stream が用いられる。

Note: 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 固有の統計情報を含む。

Note: プーリングが使用される場合、同じ connection 上でプールされた複数の WebTransport セッション はすべて同じ情報を受け取る。つまり、同じ network partition key を保持するプールされた sessions 間で情報が開示される。

Note: 利用不能な統計は 欠落 として、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機構によりサーバに受信済みと確認されたペイロードバイト数（フレーミングを除く、基盤コネクション上）。

Note: 通常は 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 は実効上限値となる。 アプリ送信レートが継続する限り、この値はネットワーク状況に適応する。ただし estimatedSendRate は atSendCapacity が true のときでも null になりうる。

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 の member ごとに、 set で gatheredStats の 対応する entry を設定する。

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

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

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

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

8.1. メソッド

getStats()

この sendGroup に grouped されているすべての WebTransportSendStream の統計情報を集約し、非同期に結果を返す。

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

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

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

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

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

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

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

      2. ユーザーエージェントが公開したい stats の member ごとに、 set で gatheredStats の 対応する entry を設定する。

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

ゲッター手順：this の [[Readable]] を返す。

writable, 型 WebTransportSendStream, 読み取り専用

ゲッター手順：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 の設定、そして 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();
  }
}