以前紹介した通り、HTTP/3やECHに対応していることをDNSで通知するためのHTTPSレコードというものがあります。
asnokaze.hatenablog.com
このHTTPSレコードで、WebSocketの対応についても通知できるようにする「Advertising WebSocket support in the HTTPS resource record」という提案仕様がMozillaの方より提出されています。
モチベーション
これは、特にHTTP/2やHTTP/3でWebSocketを使う際にメリットがあります。
それぞれの動作については以前書いたとおりです
- 「ChromeがWebSockets over HTTP/2に対応したので試す (RFC8441) - ASnoKaze blog」
- 「Bootstrapping WebSockets with HTTP/3 の仕様 - ASnoKaze blog」
既存のWebSocket over HTTP/2とWebSocket over HTTP/3では、拡張CONNECTメソッドを用いてストリームをWebSocket通信用に切り替えます。仕様上、この拡張CONNECTメソッドをクライアントが使うためには、サーバがこの拡張をサポートしていることを知る必要があります。
サーバが拡張CONNECTメソッド対応していることは、HTTP/2, HTTP/3コネクションが確立した後にサーバから送られてくるSETTINGSフレームで知ることが出来ます。つまり、クライアントは、このSETTINGSフレームの受信を待ってCONNECTメソッドのリクエストを送ることになります。
「Advertising WebSocket support in the HTTPS resource record」では、HTTPSレコードにWebSocket (拡張CONNECTメソッド)への対応が記述されるため、SETTINGSフレームの受信を待つ必要がありません。
HTTPSレコードの拡張
HTTPSレコードの仕様で定義されるSvcParamKeyとしてextended-connectキーを新しく定義します。この、extended-connectがある場合はalpnとしてh2かh3を指定する必要があります
おそらくこんな感じ
simple.example. 7200 IN HTTPS 1 . alpn=h3 extended-connect ...
おまけ
似たようなモチベーションで検討されている仕様があります。
TLS ALPSという仕組みがChromeでは実装されています。これも、TLSハンドシェイク中にHTTPレイヤのSETTINGSを送信可能にします。
asnokaze.hatenablog.com
