Full HTTP3/QUIC Reload Support

Feature Overview

Implement full support for HTTP3/QUIC reload and binary upgrade functionality. This ensures seamless transitioning of QUIC connections during configuration reloads and binary upgrades, addressing performance and stability concerns for HTTP3/QUIC sessions.

Background

The original QUIC BPF dispatch used listening sockets for both new connections and established traffic. This made reload and binary upgrade difficult, replacing listener sockets changes the routing state while existing connections still need to reach old workers.

Implementation is taken into Phases

Phase 1: BPF Reload & Binary Upgrade

Status: PR merged - https://github.com/nginx/nginx/pull/1756 , https://github.com/nginx/nginx/pull/1813

QUIC: support BPF reload and binary upgrade

The SO_COOKIE dependency is removed. QUIC BPF dispatching now uses separate sockets for new and established connections: listener sockets handle new connections, while per-worker sockets handle established ones. Server connection IDs encode a random worker key, which BPF uses to route established packets directly to the correct worker socket. New connections are routed through listen keys using a dual slot scheme that enables both reload and binary upgrade.

On reload, new workers register new sockets and keys while old workers continue receiving established connections through their encoded keys. On binary upgrade, the new master uses the opposite slot, and exiting masters clear their entries so traffic shifts to the surviving instance.

Phase 2: QUIC-LB Encrypted DCID Routing

Status: Next Issue - https://github.com/nginx/nginx/issues/1803

Replace the plaintext random-key-in-DCID scheme with encrypted DCID routing per the QUIC-LB RFC. This eliminates the (theoretical) risk of a client randomly generating a DCID that collides with an existing worker key, and aligns with the standard approach for QUIC load balancing.

consider this comment from Phase1 - https://github.com/nginx/nginx/pull/1756#discussion_r4121619176