WebTransport登場から5年経ったため変わったと感じる部分を整理する

本記事について

WebTransport の仕様が提案されてからそろそろ 5 年になります。
本記事では、提案初期からどの程度変更が入ったのかを確認してみたいと思います。

WebTransport について

2020 年に、WebSocket の次の技術！？WebTransport についての解説とチュートリアル という記事を書いたのですが、ここから技術の根幹は変わっていません。

上記の記事から抜粋すると、おおよそ以下のような内容にまとめられます。

• WebTransport は TCP ではなく QUIC を採用した WebSocket のようなもの
• 従来の WebSocket は TCP ベースであったため、メッセージが順番通り届くことを保証するために、後続のメッセージが詰まることがあった
• WebTransport では QUIC ベースになったため、メッセージが順番通り届かなくても後続のメッセージを受け取ることができるようになった
• 超高頻度でデータを送るようなユースケースで有効
  • 映像や音声、VR 空間上の位置情報などを 1 秒間に 30 回送りたい
• 但し、2020 年時点では Chrome しか対応しないので Production Ready ではない
  • (2024 年でも Safari はまだ対応していないので Production Ready ではない)

変わった点 1. 対応ブラウザが増えた

Safari はまだ対応していないものの、5 年経って Chrome, Edge, FireFox が対応しました。

MDN

WebTransport は Google が提案した技術なので、Chrome が対応しているのは自然として、FireFox が対応したというのは大きな変化です。なぜなら、主要なブラウザは実質 3 つであり、2 つが対応したということは多数派になったという解釈が出来るからです。

ブラウザが実質 3 つというのは、Chrome, FireFox, Safari の 3 つを指します。

上に貼った対応したか否かの画像では,Edge と Opera を含めた 5 種類のブラウザが登場しますが、Edge と Opera は Google Chrome の元となる Chromium をベースに開発しています。WebTransport のような Web 標準技術の API は、Chromium の中で実装されているため、Edge や Opera は WebTransport の実装例としてカウントすることは出来ません。

なので、WebTransport の実装が 2/3 になったことは大きいのではないかなと思います。(とは言っても Safari のシェアは大きいので Safari が対応しないことには普及の大きな壁となるのですが)

変わった点 2. QuicTransport / FallbackTransport が消滅した

以前に書いた記事では、WebTransport の中でも、シンプルな実装である QuicTransport という API を用いてサンプルアプリを実装しました。

この QuicTransport は、2020 年時点で 4 種類あった WebTransport の仕様のうちの 1 つです。4 種類は以下の通りです

• QUIC が通る環境では
  • HTTP3Transport
  • QuicTransport
• QUIC が通らない環境では
  • FallbackTransport
  • HTTP2Transport

当初の WebTransport は、「QUIC が通る・通らない」「低レベルな API か高レベルな API か」で分かれ 4 種類ありました。
しかし、議論をしやすくするために高レベルな API が選ばれ、HTTP3Transport と HTTP2Transport の二つが残ったようです。これらの二つは、WebTransport over HTTP/3 と WebTransport over HTTP/2 という仕様で策定されています。

QUIC が通らない環境がある以上、フォールバック先として TCP ベースの仕様も考えなければいけないので、これ以上は減らせなさそうです。

変わった点 3. 具体的なユースケースの仕様の策定が始まった

ここでいう具体的なユースケースの仕様とは、Media over QUIC Transport(MoQT)のことです。この MoQT は、映像や音声を WebTransport で送ることで、超低遅延な大規模配信を可能にする技術として仕様が進められています。

以前書いた記事では、「WebRTC の代替として使われるのではないか」という話を書いていましたが、その時予想していた形とは少し変わってきました。MoQT のユースケースには、WebRTC のようなビデオ会議も含まれてはいるのですが、どちらかというとビデオ会議ではなくライブ配信のための技術というニュアンスが強いです。そして、ライブ配信の技術としては、現在は HLS / MPEG-DASH という技術が一般的ですので、「WebRTC の代替」というよりかは「HLS / MPEG-DASH の代替」と言った方が正しいかもしれません。

実は、最近では WebRTC が HLS / MPEG-DASH の代替として大規模ライブ配信に使われてきていたりするので、「WebRTC の代替」と言っても間違いではないのですが、WebRTC の主要ユースケースであるウェブ会議の代替になるかというと怪しいなというのが現状です。
WebRTC を用いた大規模低遅延ライブ配信については、fukabori.fm #81 「 低遅延ライブ配信を支える技術 w/ mmasaki」 がわかりやすいのでオススメです。

少し話が逸れましたが、ともあれ WebTransport は具体的なユースケースを見つけ、そのユースケースに向けた仕様がかなり活発に策定されていますので、普及する可能性が高まってきました。Media over QUIC Transport についても課題が山積みですので、1,2 年でユーザーの手元に届くかというと厳しいのですが、5 年経って「前に進んでいるな」と考えています。

WebTransport 関連ドラフトについて

IETF で、WebTransport 関連ドラフトについてまとめられています。

webtransport documents

このスクリーンショットから分かるように、関連ドラフトは 3 つです。

• WebTransport Overview
• WebTransport over HTTP2
• WebTransport over HTTP3

Overview はその名の通り WebTransport の概要です。
記載されている内容はおおよそ以下の通りです

• WebTransport が必要となったモチベーション・背景
• WebTransport で登場する概念の名前と定義
• セッション確立の仕方・おおよその要件

WebTransport Overview の仕様変更について

WebTransport Overview の仕様については、2019 年 5 月に出てきた version-00 から 2024 年 8 月現在の version-08 までで、そこまで変更は入っていないようです。
version-00 では 12 ページあったのですが、version-08 でも 12 ページのままです。

iddiff というサービスを使うと、二つの draft の diff を出すことができます。

変更された仕様は、以下の 5 点のみです。他にも、細かい点は変更が入っていますが、文意が変わっているところはあまりありません。

• [追加] 4.1. Session-Wide Features
• [拡充] 4.2. Datagrams
• [拡充] 4.3. Streams
• [削除] 4.4. Bandwidth Prediction
• [削除] 5. Buffering and Prioritization

この Overview には、WebTransport over HTTP/2 と WebTransport over HTTP/3 に共通した仕様が記載されるため、仕様として細かい部分は記載されません。一度目を通しておけば数年は見なくて良さそうです。

おわりに

今回の記事では、仕様の提案からそろそろ 5 年が経つ WebTransport の変更を振り返ってみました。技術としては着実に仕様策定されているものの、まだ普及までは遠そうです。

WebTransport over HTTP/2 と WebTransport over HTTP/3 の仕様変更についてはまた別の記事でまとめたいと思います。