Scaling QUIC Ingress: eBPFソケットステアリングによるHTTP/3接続移行

リモートエッジノードが数百ミリ秒ネットワークから切断され、新しいIPアドレスで復帰した場合、単純なUDPプロキシの展開は、そのような中断を生き延びるはずのセッションを静かに終了させてしまいます。この記事では、その原因と、LinuxとCloudflareが実際に提供する仕組みを使ったeBPFベースのソケットステアリングがどのように解決するかについて解説します。

なぜQUICなのか、そしてナイーブな負荷分散が壊れる理由

リアルタイムのテレメトリ—産業用センサーネットワーク、自動運転車のセンサーフュージョン、モバイルエッジのワークロード—は、TCPからHTTP/3のQUICトランスポートへと移行しています。TCPの厳格な順序配信は、パケットの喪失がその接続上のすべてのストリームの遅延を引き起こす（ヘッド・オブ・ラインブロッキング）ためです。QUICは、UDP上で独自の損失回復とストリーム多重化を行うことでこれを回避し、1つのストリームのパケット喪失が他のストリームに影響しないようにしています。

また、QUICは0-RTTもサポートしていますが、これは何を意味するのか正確に理解しておく必要があります。0-RTTは、*リターン*クライアントが以前のセッションを再開し、アプリケーションデータを即座に送信できるもので、以前のハンドシェイクから共有されたキーを使用します。新規クライアントは依然として完全な1-RTT TLS 1.3ハンドシェイクが必要です。0-RTTはセッション再開の最適化であり、すべてのQUICハンドシェイクの特性ではありません。

この記事で最も重要なのは接続の移行です。TCP接続は4つ組（source IP、source port、destination IP、destination port）に固定されており、これを変更すると接続は失われ、クライアントは最初からやり直す必要があります。QUICは、4つ組の代わりにConnection ID (CID)を使ってセッションを識別し、ネットワークパスから切り離しています。RFC 9000によると、CIDは最大20バイトで、ピアには不透明です。サーバーが選び、クライアントに渡し、IPやポートが変わった後も認識し続けることが可能です。

これは、単一のクライアントとサーバー間では大きなメリットですが、負荷分散された複数のワーカーがいる場合には問題となります。

移行時に壊れる4-tupleハッシュ

NGINX、Envoy、HAProxyのようなリバースプロキシは、SO_REUSEPORTを使って複数のワーカーをスケールさせます。TCPでは、カーネルがハンドシェイクとaccept()を処理し、完了した接続を特定のワーカーに割り当てます。

UDPにはハンドシェイクも持続的なカーネル側の接続状態もないため、SO_REUSEPORTはより単純な仕組みを使います。すべての受信データグラムに対して、カーネルは4-tupleをハッシュし、そのハッシュ値に基づいてソケットを選びます。4-tupleが変わらなければ、すべてのパケットは同じワーカーに届きます。

しかし、クライアントのIPが変わると（これがQUICの接続移行の本質）、4-tupleもハッシュも変わり、パケットは未認識の別のワーカーにルーティングされ、TLSキーも持っていないため破棄されてしまいます。これにより、QUICの主要な特徴が負荷分散の仕組みによって無効化されてしまいます。

eBPFを使ったカーネルへのQUIC認識

Linuxは、カーネルにQUICをハードコーディングするのではなく、BPF_PROG_TYPE_SK_REUSEPORTを使ってカスタムのeBPFプログラムをリユースポートグループにアタッチし、デフォルトのハッシュの代わりにソケット選択を行わせることを可能にしています。この機能はLinux 4.19でMartin KaFai Lauによって導入され、bpf_sk_select_reuseport()ヘルパーとともに、BPF_MAP_TYPE_REUSEPORT_SOCKARRAYマップ（Linux 5.8以降はSOCKHASH/SOCKMAPも）に受信パケットを割り当てることができます。eBPFプログラムが無効なインデックスを返すと、カーネルは安全にデフォルトの4-tupleハッシュにフォールバックします。

これにより、「4-tupleのハッシュ」ではなく、「パケット内のQUIC Connection IDを読み取ってルーティングする」ことが可能となり、カーネル空間で完結します。これにより、パケットがユーザースペースのソケットバッファに到達する前にルーティングを決定できます。

ステアリングパイプライン

1. ワーカーがCIDに自身のIDを埋め込む。 最初のハンドシェイクパケット時に、移行前の状態がないため、デフォルトのハッシュは問題ありません。ハンドシェイクを担当したワーカー（例：ワーカー2）は、サーバーConnection IDを生成し、その中に自身のワーカーインデックスと暗号化エントロピーをエンコードします。
2. eBPFプログラムがカーネル内でQUICヘッダーを解析。 以降のパケットでは、struct sk_reuseport_mdを使って生のペイロードを検査し、QUICの長ヘッダー（ハンドシェイクパケット）と短ヘッダー（通常状態の1-RTTパケット）を区別し、Destination Connection IDを抽出します。
3. ワーカーIDのルックアップはハッシュテーブルではなく直接抽出。 CIDに直接埋め込まれたワーカーIDをマスクして取り出し、その値を整数として復元します。
4. bpf_sk_select_reuseport()がルーティングを行う。 抽出したワーカーIDをインデックスとしてソケット配列にアクセスし、そのワーカーのソケットにダイレクトにデータグラムを届けます—クライアントの現在のIPアドレスに関係なく。

ここで注意すべき点は、「CIDにルーティング情報を直接エンコードする」アイデアは、実はIETFのdraft-ietf-quic-load-balancers（