要約

  • RFC 9111がミスの集約を認めるのは、返された応答を対象の各要求に再利用できる場合に限られる。
  • 対象、メソッド、Varyフィールド、認可、キャッシュ制御について、待機中のリクエストごとの判断は残る。

明確に仮想のエッジゲートウェイを考える。同じURIへの二つのGETがほぼ同時に届く。一方は匿名で、もう一方はAuthorizationを持ち、アカウント固有の表現を期待している。ゲートウェイは先着を代表リクエストにして上流へ一度だけ送り、返った200 OKを両方へ配る。オリジン負荷は減るが、二番目のリクエストに必要だった応答判断が最適化の中に消える。

RFC 9111が要求集約を認めるのには実用的な理由がある。複数の要求が同時にミスしたとき、一つの転送要求にまとめればオリジンとネットワークの負荷を減らせる。ただし、返された応答が対象の要求に再利用できることが条件だ。一部または全部に使えないなら、遅延が増えても、その要求は別に転送しなければならない。

URIが似ているだけでは再利用を決められない。対象URIが一致し、保存済み応答のメソッドが再利用を許し、Varyが指名した要求フィールドが一致し、no-cacheの条件を満たす必要がある。応答は新鮮であるか、古いまま提供することが許されるか、検証に成功していなければならない。集約が変えるのは上流取得の回数であり、要求ごとの条件ではない。

Varyはその判断材料の一つだ。RFC 9110によれば、Varyは表現選択に影響した可能性のある要求フィールドを示し、後の照合に必要なキャッシュキーを拡張する。RFC 9111は、正規化やフィールド欠落を含む照合方法を定める。*を含むVaryは常に一致しない。Varyは待機中のリクエストを一体化するのではなく、区別するための証拠である。

Authorizationは境界を具体化する。RFC 9111では、共有キャッシュはAuthorizationを含む要求への保存済み応答を、許可するCache-Control指令があり、その要件を満たす場合を除いて、後続要求に使ってはならない。すべての集約が認証付きという意味ではない。ファンアウトも通常の再利用規則を追い越せないということだ。

したがって、「削減したオリジンへのリクエスト数」だけを指標にするのは危険である。代表リクエストの成功は、一つの上流取引が応答を得たことを示すだけだ。各後続リクエストの選択フィールド、認可制約、鮮度、再利用資格が同じとは限らない。違いがあれば、個別転送は無駄ではなく正しさである。

容量と証拠を両立するには、集約解放レシートを用意する。これは本稿が提案する編集上の統制であり、IETFが定義するプロトコルオブジェクトではない。代表リクエストと待機中の全リクエストを結び、応答と保存オブジェクトの識別子を記録し、メソッドと対象を正規化する。Varyを比較し、AuthorizationとCache-Controlを評価し、待機中の各リクエストについて応答解放または個別転送を残す。

これで役割が分かれる。集約は取得を共有する最適化であり、応答の引き渡しは個別判断のままだ。誤った配布をヒットと数えずに、節約した上流作業を測定できる。

情報源