WebTransport プロトコルフレームワーク

1.1. 背景0

歴史的に，~client↔~server間で双方向な~data~streamが必要な~web応用は、 ~WebSocket `RFC6455$r に依拠することもできた — それは、 ~Web~security~modelと互換な，~messageに基づく~protocolである。 しかしながら、 それが供する抽象-化は，［ ~messageたちが成す，順序に`依拠-可能$な単独の~stream ］なので、 そこには渋滞（ `head-of-line blocking^en ）の難がある — すなわち、 すべての~messageは，［ 互いに独立に処理できる場合や，もはや関連しなくなった~messageがある場合 ］でも，送信された順序どおりに受信されなければならない。 これには、 待時間に敏感な応用 — 処理能のために［ 部分的な`依拠-能＠#reliable$, ~streamの独立性 ］に依拠する応用 — が上手く収まらない。 ◎ Historically, web applications that needed a bidirectional data stream between a client and a server could rely on WebSockets [RFC6455], a message-based protocol compatible with the Web security model. However, since the abstraction it provides is a single ordered reliable stream of messages, it suffers from head-of-line blocking, meaning that all messages must be sent and received in order even if they could be processed independently of each other, and some messages may no longer be relevant. This makes it a poor fit for latency-sensitive applications which rely on partial reliability and stream independence for performance.

【 `依拠-可能@ （ `reliable^en ）とは，上で述べられたとおり、 ~dataは送信された順序どおりに（落とされることなく）送達されることが保証されるので， 受信-側は受信した順序に`依拠-可能である^emことを意味する。 `不依拠-可能@ （ `unreliable^en ）は，`依拠-可能$の否定を意味するが、 “依拠-不能”, “依拠-可能でない”, “非~依拠-可能” ではなく，この対訳が選ばれたのは、 その用法に “依拠することなく処理-可能である” という肯定的な意味合いがあることによる。 】

~Web開発者に可用な既存の~optionとして、 ~WebRTC~data~channel `RFC8831$r もある — それは、 ~DTLSにより保護された `peer-to-peer^en ~SCTP~channel用に，~WebSocketの様な~APIを供する。 理論~上は、 この仕様により取組まれる利用事例に，それを利用することもアリである。 しかしながら，実施においては、 次に挙げるものへの依存性に因り， `browser-to-browser^en 設定群の外側では広い採用が見られない： ◎ One existing option available to Web developers are WebRTC data channels [RFC8831], which provide a WebSocket-like API for a peer-to-peer SCTP channel protected by DTLS. In theory, it is possible to use it for the use cases addressed by this specification. However, in practice, it has not seen wide adoption outside of browser-to-browser settings due to its dependency on＼

• ~ICE （これは、 ~Web~modelに上手く収まらない） ◎ ICE (which fits poorly with the Web model) and＼
• `userspace^en ~SCTP （これは、 他の文脈では利用されていないことに因り，可用な実装が限られる） ◎ userspace SCTP (which has a limited number of implementations available due to not being used in other contexts).

代替な設計として、 ~HTTP3越しに複数の~WebSocket接続を~openすること `RFC9220$r が挙げられよう。 それは、 渋滞を避けることに加え， ~streamを取消す能を — それに対応する~WebSocket~sessionを~closeすることにより — 供する。 しかしながら，この~approachには、 首に［ 各~WebSocketが意味論的に完全に独立な実体である事実 ］から起因する，いくつかの欠点がある： ◎ An alternative design would be to open multiple WebSocket connections over HTTP/3 [RFC9220]. That would avoid head-of-line blocking and provide an ability to cancel a stream by closing the corresponding WebSocket session. However, this approach has a number of drawbacks, which all stem primarily from the fact that semantically each WebSocket is a completely independent entity:

• 各~新たな~streamは、 どの応用~protocolを利用するか合意するため，~WebSocket~handshakeを要求することになる — そのことは、 ~clientが~streamへ書込めるようになる前に， 新たな各~streamを確立する際に 1 回以上の~RTT【往復-時間】がかかることを意味する。 ◎ Each new stream would require a WebSocket handshake to agree on application protocol used, meaning that it would take at least one RTT to establish each new stream before the client can write to it.
• ~streamを起動できるのは~clientに限られる。 ~serverが起動する~streamや 通信を成す他の代替な~mode （~QUIC `DATAGRAM^ft ~frame `RFC9221$r など） は可用でない。 ◎ Only clients can initiate streams. Server-initiated streams and other alternative modes of communication (such as the QUIC DATAGRAM frame [RFC9221]) are not available.
• ~streamたちは，通常は~UAにより~poolされることになるが、 そのことは保証されず，［ ある~WebSocketを ある~serverへ対応付ける一般な処理n ］は~clientからは不透明である。 これは、 ~systemの中へ予測-不能な処理能~propを導入し， ~streamたちが同じ接続~上にあることに依拠する最適化を妨げる （一例として、 ~clientが~streamごとに異なる再伝送~優先度を要請することは， アリかもしれないが — それらの~streamすべてが同じ接続~上にある場合を除き — ずっと複階的になる）。 ◎ While the streams would normally be pooled by the user agent, this is not guaranteed, and the general process of mapping a WebSocket to a server is opaque to the client. This introduces unpredictable performance properties into the system, and prevents optimizations which rely on the streams being on the same connection (for instance, it might be possible for the client to request different retransmission priorities for different streams, but that would be much more complex unless they are all on the same connection).

~WebTransportは、 応用が次のような~transport~objを作成できるようにすることにより， 上に挙げた課題~すべてを避ける ⇒ 単独の~transport~objが， 一緒に多重化された複数の~streamを単独の文脈~内に包含でき （~SCTP, ~HTTP2, ~QUIC, その他と類似に）、 `不依拠-可能$な~datagramを送信するためにも利用できる （~UDPと類似に）。 ◎ WebTransport avoids all of those issues by letting applications create a single transport object that can contain multiple streams multiplexed together in a single context (similar to SCTP, HTTP/2, QUIC and others), and can be also used to send unreliable datagrams (similar to UDP).

1.2. 規約と定義

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳~共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

~WebTransportは、［ 下層の~transport~protocolを抽象-化して見えなくする ］一方で［ ~transport層の要を成す少数の側面を応用~開発者に公開する ］ことを目指す~frameworkである。 その構造は、 次に挙げる概念に基づく： ◎ WebTransport is a framework that aims to abstract away the underlying transport protocol while still exposing a few key transport-layer aspects to application developers. It is structured around the following concepts:

~WebTransport~session ◎ WebTransport session:

~client↔~server間で確立される単独の通信~文脈。 ◎ A WebTransport session is a single communication context established between a client and a server.＼

それは、 特定の［ ~transport層を成す接続 ］に対応することもあれば， 既存の多重化された［ ~transport層を成す接続 ］の中の論理的な実体になることもある。 ~WebTransport~sessionどうしは、 一部の~sessionたちが下層の［ ~transport層を成す接続 ］を共有し得る場合でも，論理的に独立である。 ◎ It may correspond to a specific transport-layer connection, or it may be a logical entity within an existing multiplexed transport-layer connection. WebTransport sessions are logically independent from one another even if some sessions can share an underlying transport-layer connection.

~WebTransport~protocol ◎ WebTransport protocol:

~WebTransport~sessionを確立するために利用できる特定の~protocol。 ◎ A WebTransport protocol is a specific protocol that can be used to establish a WebTransport session.

~datagram ◎ Datagram:

次のような，伝送の単位 ⇒＃ その~sizeは（概して経路~MTUに）制限される。 `依拠-可能$に送達されることは期待されない。 当の~transportにより不可分に扱われる。 ◎ A datagram is a unit of transmission that is limited in size (typically to the path MTU), does not have an expectation of being delivered reliably, and is treated atomically by the transport.

~stream ◎ Stream:

送信器が伝送したとおりの順序で受信している応用へ`依拠-可能$に送達される~byte列。 その長さは，任意になり得るので、 その全体を~memory内に~bufferできるとは限らない。 ~WebTransport~protocol, その~APIは、 ~stream全体が受信される前に，部分的な~stream~dataを応用に供することが期待される。 ◎ A stream is a sequence of bytes that is reliably delivered to the receiving application in the same order as it was transmitted by the sender. Streams can be of arbitrary length, and therefore cannot always be buffered entirely in memory. WebTransport protocols and APIs are expected to provide partial stream data to the application before the stream has been entirely received.

~message ◎ Message:

［ 応用に渡される前に全部的に~bufferできる ］までに~sizeが抑えられた~stream。 ◎ A message is a stream that is sufficiently small that it can be fully buffered before being passed to the application.＼

~WebTransportは、 ~messageを~primitiveとして定義しない — ~transportの視点からは、 ~messageは，［ ~streamを応用へ渡す前に~streamを全部的に~bufferする ］ことにより模倣できるので。 しかしながら、 この【~streamと~messageの】区別は，重要である — 類似な~protocolや~APIのうち一部（特に，~WebSocket `RFC6455$r ）は、 ~messageを抽象-化の中核として利用するので。 ◎ WebTransport does not define messages as a primitive, since from the transport perspective they can be simulated by fully buffering a stream before passing it to the application. However, this distinction is important to highlight since some of the similar protocols and APIs (notably WebSocket [RFC6455]) use messages as a core abstraction.

~WebTransport~server （略して，~server） ◎ Server:

流入~WebTransport~sessionを受容する応用。 ◎ A WebTransport server is an application that accepts incoming WebTransport sessions.＼

~WebTransportが多重化された~protocol（~HTTP2や~HTTP3など）越しに~serveされる事例では、 “~WebTransport~server” は — 所与の［ ~TCP／~UDP ］~socketを~listenしている応用ではなく — 特定の多重化された端点~用の~handler （例：特定の~HTTP資源を取扱っている応用） を指す。 ◎ In cases when WebTransport is served over a multiplexed protocol (such as HTTP/2 or HTTP/3), "WebTransport server" refers to a handler for a specific multiplexed endpoint (e.g. an application handling specific HTTP resource), rather than the application listening on a given TCP or UDP socket.

~WebTransport~client （略して，~client） ◎ Client:

~transport~sessionを起動する応用。 ◎ A WebTransport client is an application that initiates the transport session＼

~clientは、 ~securityに関して拘束された文脈~内で走っていることもある — 一例として、 ~browserの内側で走っている~JS応用。 ◎ and may be running in a constrained security context, for instance, a JavaScript application running inside a browser.

~WebTransport~UA （略して，~UA） ◎ User agent:

［ ~host~network~stackへの~accessが制約されない~software~system ］であって，［ ~clientに利するために，~transportを作成できる ］もの。 ◎ A WebTransport user agent is a software system that has an unrestricted access to the host network stack and can create transports on behalf of the client.

4.1. ~session全般な特能

~WebTransport~protocolは、 ~sessionに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】： ◎ Any WebTransport protocol SHALL provide the following operations on the session:

~sessionを確立する ◎ establish a session

要請-者の~URI `RFC3986$r を与える下で， 新たな~WebTransport~sessionを作成する。 ~WebTransport~sessionが~browser~clientから来ている場合には、 生成元 `RFC6454$r も与えなければ`ナラナイ^2119 — 他の場合、 生成元は`任意選択^2119である。 ◎ Create a new WebTransport session given a URI [RFC3986] of the requester. An origin [RFC6454] MUST be given if the WebTransport session is coming from a browser client; otherwise, it is OPTIONAL.

~sessionを終了する ◎ terminate a session

~sessionを終了する — ( 無符号な 32 ~bitの~error~code, ~error事由を与える 1024 ~byte以下の文字列 ) を相手の端点へ通信する。 ~sessionが終了されて以降、 そこで交換される応用~dataは無くなる。 ［ ~error~code／文字列 ］は、 省略可能であり，既定の値は［ 0 ／ 空~文字列 ］とする。 ~error~codeと文字列の送達は、 最善な労に基づいてもヨイ。 ◎ Terminate the session while communicating to the peer an unsigned 32-bit error code and an error reason string of at most 1024 bytes. As soon as the session is terminated, no further application data will be exchanged on it. The error code and string are optional; the default values are 0 and "". The delivery of the error code and string MAY be best-effort.

~WebTransport~protocolは、 次に挙げる~eventを供さなければ`ナラナイ^2119【！SHALL】： ◎ Any WebTransport protocol SHALL provide the following events:

~sessionは終了された ◎ session terminated event

当の~WebTransport~sessionは、［ 相手の端点／局所~networking~stack ］により終了されたことを指示する — 以降，当の~session上では利用者~data【応用~data】を交換し得なくなる。 相手の端点が上の “`~sessionを終了する＠#terminate-a-session$” 演算を遂行した結果として， ~sessionが終了された場合、 対応する ( ~error~code, ~error文字列 ) が供され得る。 ◎ Indicates that the WebTransport session has been terminated, either by the peer or by the local networking stack, and no user data can be exchanged on it any further. If the session has been terminated as a result of the peer performing the "terminate a session" operation above, a corresponding error code and an error string can be provided.

4.2. ~datagram

~datagramは、 ~sizeが（一般には経路~MTUに）制限された~byte列であり， 【~datagramたちが】`依拠-可能$に伝送されることは期待されない。 ~WebTransport~datagramの一般な目標は、 挙動において~UDPと類似する一方で， `§ 共通な~transport要件＠#common-requirements$ にて表出した要件の~subjectになることである。 ◎ A datagram is a sequence of bytes that is limited in size (generally to the path MTU) and is not expected to be transmitted reliably. The general goal for WebTransport datagrams is to be similar in behavior to UDP while being subject to common requirements expressed in Section 2.

~WebTransport送信器には、 ~datagramを伝送し直すことは期待されない — 自身が下層の~protocolとして［ ~TCPその他の`依拠-可能$な送達しか供せないもの ］を利用している場合には，そうする結果になろうが。 ~WebTransport~datagramは、 ~flow制御されることは期待されない — それは、［ 受信器は，応用が十分~速く消費しなかった~datagramたちを落とすかもしれない ］ことを意味する。 ◎ A WebTransport sender is not expected to retransmit datagrams, though it may end up doing so if it is using TCP or some other underlying protocol that only provides reliable delivery. WebTransport datagrams are not expected to be flow controlled, meaning that the receiver might drop datagrams if the application is not consuming them fast enough.

応用には、 自身が送信できる最大な~datagram~sizeが供されなければ`ナラナイ^2119。 この~sizeは、 経路~MTUの発見を遂行した結果から導出される`ベキ^2119である。 ◎ The application MUST be provided with the maximum datagram size that it can send. The size SHOULD be derived from the result of performing path MTU discovery.

~WebTransport~modelにおいては、［ すべての流出~datagram／ すべての流入~datagram ］は， ~sizeに~~上限がある ある~queue %~queue の中へ配置される （~network~interface~card~queueと類似な）。 ◎ In the WebTransport model, all of the outgoing and incoming datagrams are placed into a size-bound queue (similar to a network interface card queue).

~WebTransport~protocolは、 ~sessionに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】： ◎ Any WebTransport protocol SHALL provide the following operations on the session:

~datagramを送信する ◎ send a datagram

所与の~datagram %~datagram を %~queue に~enqueueする — %~datagram は、 相手の端点へ送信されることになる。 %~queue が満杯な場合、 %~datagram は落とされる結果になり得る。 ◎ Enqueues a datagram to be sent to the peer. This can potentially result in the datagram being dropped if the queue is full.

~datagramを受信する ◎ receive a datagram

可用なら【 %~queue は空でないなら】， %~queue から流入~datagramを~dequeueして返す。 ◎ Dequeues an incoming datagram, if one is available.

最大~datagram~sizeを取得する ◎ get maxiumum datagram size

~WebTransport~sessionが送信-可能になるものと期待される最~大な~datagram~sizeを返す。 ◎ Returns the largest size of the datagram that a WebTransport session is expected to be able to send.

4.3. ~stream

一方向~stream （ `unidirectional stream^en ）は、 ある一方通行な［ `依拠-可能$な順序どおりな~byteたちが成す~stream ］であり、 その~dataを送信できる端点は，その起動元に限られる。 双方向~stream （ `bidirectional stream^en ）は、 両~端点にも~dataを送信することを許容する — それは、 概念的には， 2 つの一方向~streamが成す~pairとして表現し得る。 ◎ A unidirectional stream is a one-way reliable in-order stream of bytes where the initiator is the only endpoint that can send data. A bidirectional stream allows both endpoints to send data and can be conceptually represented as a pair of unidirectional streams.

~streamは、 一般に，~QUIC~streamの意味論と状態~機械（ `QUIC$r【！`RFC9000$r】 § 2, § 3 ）に従うことが期待される。 課題：~streamの状態~機械について，明示的に述べる。 ◎ The streams are in general expected to follow the semantics and the state machine of QUIC streams ([RFC9000], Sections 2 and 3). TODO: describe the stream state machine explicitly.

~WebTransport~streamは、 `~reset$され得る。 それは、 当の端点は，当の~streamに関係する~dataを［ 送信する／受信する ］ことに関心を失ったことを指示する。 その事例では、 送信器には，［ 当の~streamに対しすでに送信した~dataがあっても，それを伝送し直さない ］ことが期待される。 ◎ A WebTransport stream can be reset, indicating that the endpoint is not interested in either sending or receiving any data related to the stream. In that case, the sender is expected to not retransmit any data that was already sent on that stream.

~streamは、 ~messageとして利用できるまでに~sizeが抑えられる`ベキ^2119である。 ◎ Streams SHOULD be sufficiently lightweight that they can be used as messages.

~stream上に送信される~dataは、 当の~transport~protocolにより~flow制御される。 加えて，新たな~streamの作成も~flow制御される。 端点が~openできる~streamの個数は、［ 相手の端点が，もっと~streamを作成することを明示的に許容する ］までは制限され得る。 ~clientの視点からは、 これは，流入~streamたちが成す［ ~sizeに~~上限がある~queue ］として呈示される。 ◎ Data sent on a stream is flow controlled by the transport protocol. In addition to flow controlling stream data, the creation of new streams is flow controlled as well: an endpoint may only open a limited number of streams until the peer explicitly allows creating more streams. From the perspective of the client, this is presented as a size-bounded queue of incoming streams.

~WebTransport~protocolは、 ~sessionに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】： ◎ Any WebTransport protocol SHALL provide the following operations on the session:

一方向~streamを作成する ◎ create a unidirectional stream

流出~一方向~streamを作成する — この演算の完了は、 下層の~protocolの~flow制御により許容されるまで阻まれ得る。 ◎ Creates an outgoing unidirectional stream; this operation may block until the flow control of the underlying protocol allows for it to be completed.

双方向~streamを作成する ◎ create a bidirectional stream

流出~双方向~streamを作成する — この演算の完了は、 下層の~protocolの~flow制御により許容されるまで阻まれ得る。 ◎ Creates an outgoing bidirectional stream; this operation may block until the flow control of the underlying protocol allows for it to be completed.

一方向~streamを受信する ◎ receive a unidirectional stream

流入~一方向~streamたちが成す~queueから，可用な ある~streamを除去する。 ◎ Removes a stream from the queue of incoming unidirectional streams, if one is available.

双方向~streamを受信する ◎ receive a bidirectional stream

流入~一方向【双方向？】~streamたちが成す~queueから，可用な ある~streamを除去する。 ◎ Removes a stream from the queue of incoming unidirectional streams, if one is available.

~WebTransport~protocolは、 個々の~streamに対し，次に挙げる演算を供さなければ`ナラナイ^2119【！SHALL】： ◎ Any WebTransport protocol SHALL provide the following operations on an individual stream:

~byte列を送信する ◎ send bytes

~byte列を~streamの送信-~bufferの中へ追加する。 送信器は、 `FIN^i も指示できる — それは、 当の~stream上には送信される新たな~dataは無い事実を通達する。 この演算は、 流入~一方向~stream用には適用-可能でない。 ◎ Add bytes into the stream send buffer. The sender can also indicate a FIN, signalling the fact that no new data will be send on the stream. Not applicable for incoming unidirectional streams.

~byte列を受信する ◎ receive bytes

~stream受信-~bufferから~byte列を除去する。 ~stream~dataと一緒に `FIN^i も受信され得る。 この演算は、 流出~一方向~streamには適用-可能でない。 ◎ Removes bytes from the stream receive buffer. FIN can be received together with the stream data. Not applicable for outgoing unidirectional streams.

送信-側を中止する ◎ abort send side

~streamを成す書込n側を中止したことを指示する通達を相手の端点へ送信する。 送信-~bufferを破棄する — アリな場合【何が？】、 現在~待機中な［ 伝送される／伝送し直される ］~dataは無い。 無符号な 8 ~bitの~error~codeが 相手の端点への通達を成す一部として給され得る — 省略された場合、 ~error~codeは 0 であるものと予め見做される。 ◎ Sends a signal to the peer that the write side of the stream has been aborted. Discards the send buffer; if possible, no currently outstanding data is transmitted or retransmitted. An unsigned 8-bit error code can be supplied as a part of the signal to the peer; if omitted, the error code is presumed to be 0.

受信-側を中止する ◎ abort receive side

~streamを成す読取n側を中止したことを指示する通達を相手の端点へ送信する。 受信-~bufferを破棄する — 相手の端点には、 概して，それに呼応して対応する送信-側を中止することが期待される。 無符号な 8 ~bitの~error~codeが相手の端点への通達を成す一部として給され得る。 ◎ Sends a signal to the peer that the read side of the stream has been aborted. Discards the receive buffer; the peer is typically expected to abort the corresponding send side in response. An unsigned 8-bit error code can be supplied as a part of the signal to the peer.

~WebTransport~protocolは、 個々の~stream用に，次に挙げる~eventを供さなければ`ナラナイ^2119【！SHALL】： ◎ Any WebTransport protocol SHALL provide the following events for an individual stream:

送信-側は中止された ◎ send side aborted

相手の端点は、 当の~streamを成す受信-側を中止したことを指示する。 相手の端点から無符号な 8 ~bitの~error~codeが可用になることもある。 ◎ Indicates that the peer has aborted the corresponding receive side of the stream. An unsigned 8-bit error code from the peer may be available.

受信-側は中止された ◎ receive side aborted

相手の端点は、 当の~streamを成す送信-側を中止したことを指示する。 相手の端点から無符号な 8 ~bitの~error~codeが可用になることもある。 ◎ Indicates that the peer has aborted the corresponding send side of the stream. An unsigned 8-bit error code from the peer may be available.

すべての~dataは~commitされた ◎ all data committed

~stream上の流出~dataすべては、 終了~stream指示も含めて，［ 送信-側を中止しても，送達されている~dataには効果を及ぼさなくなる状態にある ］ことを指示する。 ◎ Indicates that all of the outgoing data on the stream, including the end stream indication, is in the state where aborting the send side would have no further effect on any data being delivered.

~HTTP2 の様な~protocol用には、 ~stream~dataは，伝送~用に（~kernelの様な）別の~componentへ渡されるかもしれない。 そのような~componentへ~dataが渡されたなら、 接続~全体も中止しない限り，~stream~dataの送信を中止することはアリでないかもしれない。 これらの~protocol用には、 すでに他の~componentへ渡された~dataは~commitされたものと見なされる。 ◎ For protocols, like HTTP/2, stream data might be passed to another component (like a kernel) for transmission. Once data is passed to that component it might not be possible to abort the sending of stream data without also aborting the entire connection. For these protocols, data is considered committed once it passes to the other component.

~HTTP3の様な，もっと統合された~stackを利用する~protocolは、 ~dataを更に処理しないよう撤回-可能かもしれない。 これらの~protocol用には、 ~stream上への送信は，すべての~dataが相手の端点により［ 受信され, 認知される ］ — ~QUICにおける `Data Recvd^i 状態に対応しているとき — までの，いつでも中止されるかもしれない。 `QUIC$r `3.1＠~RFCx/rfc9000#section-3.1§ を見よ。 ◎ A protocol, like HTTP/3, that uses a more integrated stack might be able to retract data further into the process. For these protocols, sending on a stream might be aborted at any time until all data has been received and acknowledged by the peer, corresponding to the "Data Recvd" state in QUIC; see Section 3.1 of [QUIC].