IETFのHTTP WGで『HTTP Alternative Services, Plan B』という仕様の議論されている。
これは、RFC 7838 『HTTP Alternative Services』の課題を改善するための取り組みです。
ざっと読んでメモ
RFC 7838 HTTP Alternative Services
HTTP Alternative Services (代替サービス)は、サーバが提供するWebサービスの代替をクライアントに通知する仕組みです。
代替通知により、ことなるサーバからそのWebサービスを提供できるようになります。
よく使われているのは、HTTP/3 のサポートをクライアントに通知するのに使われています。下記のようにalt-svcヘッダをレスポンスで返すことで、クライアントにHTTP/3で接続するように通知できます。
alt-svc: h3=":443"; ma=2592000
なお、代替サービスは別のドメイン名も指定できます。次の例は、alt.example.comの8000版ポートでこのWebサービスを提供していることを通知できます。クライアントはそちらのサーバに繋ぎにいきます。
alt-svc: h2="alt.example.com:8000", h2=":443"
まとめると、alt-svcのユースケースは主に次のとおりです
- クライアントに合わせて、適切な場所のサーバに誘導する
- 負荷分散やシャットダウンの都合のために別のサーバに誘導する
- HTTP/3で接続できることをクライアントに通知する
HTTP Alternative Services の課題
既存のHTTP Alternative Servicesは、レスポンスヘッダで次のように通知されます。このとき、maで指定された秒数クライアント側でキャッシュされます。
alt-svc: h3=":443"; ma=2592000
このmaが長く設定されるとクライアントは長くそのAlternative Servicesを使いますし、短すぎると再確認の発生が増えます
また、クライアント側で長くキャッシュしてると、サーバ側のインフラ環境が変わった場合に追随できません。
さらに、HTTP/3のアドバタイズはDNS HTTPS レコードを用いており HTTP Alternative Servicesのキャッシュ期間とは異なるメカニズムを持っています。
asnokaze.hatenablog.com
このようにAlternative Servicesを一貫して管理/提供が課題として上げられています。
HTTP Alternative Services, Plan B
説明したHTTP Alternative Services課題にたいして、IETF HTTP WGではDesign Teamを結成し課題の整理と解決策の議論をしていました。
そのDesign Teamの最初のアウトプットとして出てきたのが『HTTP Alternative Services, Plan B』です。
このPlan Bでは、一貫してDNSからAlternative Services情報を提供するように設計されています。
今までのユースケースに対して次のようなアプローチです
特に2点目の接続の誘導のために、alt-svcbヘッダを導入しています。
こんな感じでレスポンスを返すと、クライアントはalt-svcbで指定されたドメインにHTTPSレコードを引いた上で、代替サービスとして使用します。
200 OK HTTP/1.1 date: Mon, 24 Oct 2022 02:58:31 GMT alt-svcb: "instance31.example.com" content-length: 0
HTTP/2やHTTP/3では専用フレームも使うことが出来ます。ALTSVCフレームのようにALTSVCBフレームが定義されています（説明割愛）
