プロトコルの進化と互換性

プロトコルはデプロイされると変更が難しい——TCPの固定ヘッダーにより拡張に10年を要し、TLSミドルボックスの不明な拡張に対するバギーな動作がオシフィケーション（硬化）を引き起こした。QUICは設計当初からバージョンネゴシエーションとGREASE（意味のない拡張のランダム挿入）を内蔵し、ミドルボックスの硬化に対抗している——これは新プロトコルにとって必須の教訓である。

概要

プロトコルは不変ではない——デプロイされると変更が難しい。HTTP/1.1 ヘッダーのテキスト的な柔軟性は、新機能（Cache-Control, CORS）を問題なく追加することを可能にしたが、TCPの固定ヘッダーは拡張を困難にした（TCP Fast Open の普及には10年かかった）。QUICは設計当初からバージョンネゴシエーションとGREASE（意味のない拡張のランダム挿入）を内蔵しており、ミドルボックスが不明なフィールドに対して取るべきバギーな動作によるプロトコルのオシフィケーション（硬化）に対抗している。すべての新設計プロトコルは、GREASEと明確な拡張ポイントを実装すべきである。

フォワード互換性とバックワード互換性

フォワード互換性 (新しいクライアント、古いサーバー):
  不明なフィールド: スキップ (protobuf, TLV)
  不明なフレームタイプ: 無視 (HTTP/2)
  → 実装: 「受け入れる側は寛容に」

バックワード互換性 (古いクライアント、新しいサーバー):
  デフォルト値での埋め合わせ
  バージョンネゴシエーション
  機能ビットマップ (TLSの暗号スイート)

ネゴシエーションとフォールバック

HTTP Upgrade GET / HTTP/1.1 + Upgrade: h2c 101 Switching または 無視

TLS ALPN ClientHello ALPN=[h2, http/1.1] ServerHello ALPN="h2"

HTTP Alt-Svc Alt-Svc: h3=":443" 次回接続で HTTP/3 を使用 (現在の接続はアップグレードしない)

問題: ミドルボックス (ファイアウォール、NAT) は自分が知っているバイトパターンしか認識しない
  → 新しいプロトコル拡張 → 認識できないため破棄される → プロトコルが進化できない

GREASE: クライアントが意味のない拡張/値をランダムに挿入する:
  TLS: ClientHello 内のランダムな暗号スイート
  HTTP/2: ランダムな SETTINGS パラメータ
  QUIC: ランダムなトランスポートパラメータ

目的: ミドルボックスが不明な値を正しく処理する必要がある (無視すること。拒否してはならない)
  → 将来の本当の拡張がミドルボックスによってブロックされない