HTTP Alternative Services, Plan B のメモ

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情報を提供するように設計されています。

今までのユースケースに対して次のようなアプローチです

  • HTTP/3などの別プロトコルのアドバタイズ => DNS HTTPS レコードを使用
  • 別サーバに接続を誘導 => 一旦クライアントにDNSを引かせ、再接続させる

特に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フレームが定義されています(説明割愛)