Implementing QUIC in Trip.com App: Server Architecture, Connection Migration, and 0‑RTT Optimization

Background – QUIC (Quick UDP Internet Connections) is a Google‑originated UDP‑based transport protocol that underpins HTTP/3. Trip.com App, serving many overseas users, suffers from long‑haul, unstable network links, prompting an experiment to replace TCP with QUIC.

Experiments showed that QUIC reduced overall link latency by about 20%, markedly improving user experience.

QUIC Overview – QUIC combines UDP with TLS 1.3 for secure, reliable transmission, offering lower handshake latency, elimination of head‑of‑line blocking, flexible congestion control, connection migration, and encrypted headers.

Server‑Side Implementation – The client uses Google’s Cronet library, while the server is built on the official Nginx QUIC branch. Both sides were customized to fit Trip.com’s deployment scenario.

Overall Architecture

The architecture includes an external load balancer (AX) that hashes client IP + port to a specific backend instance, an Nginx Stream layer for connection‑migration support, and the Nginx QUIC process handling UDP packets and forwarding HTTP requests to the API gateway.

Multi‑Process Deployment – Nginx QUIC and Stream run as clustered multi‑process services using the Linux reuseport mechanism. However, AX may forward packets of the same QUIC connection to different backend instances or processes, breaking connection migration.

To keep packets of a single client flow on the same process, AX was configured to consistently route packets from the same client IP + port to the same backend instance, and the Stream layer was enhanced to preserve the mapping.

Connection Migration – QUIC’s connection‑migration allows a client to change its IP + port without breaking the session, using a stable connection ID (cid). In a multi‑process, multi‑instance environment, the original Nginx implementation could not guarantee that migrated packets reach the same process.

The solution adds a middle‑layer LB (Nginx Stream) that extracts the cid, embeds the server’s IP + port into the cid, and forwards packets to the original process. This required a custom Stream configuration and modifications to cid generation.

Because the Stream layer only knows the cid, it forwards initial/0‑RTT packets to the listening port of the appropriate Nginx QUIC instance, while subsequent packets (containing the worker‑port in the cid) are routed to the same worker process.

Multi‑Port Listening Solution – Each Nginx QUIC worker listens on a shared "listening" port for initial packets and on a unique "worker" port for subsequent packets. The cid carries the worker‑port, ensuring that after connection migration all packets are directed to the same process.

0‑RTT Implementation – QUIC supports 0‑RTT via TLS 1.3 session tickets. Nginx processes store ticket_key in per‑process memory, preventing cross‑process reuse. To share the key, a Redis store was introduced: each process checks Redis for an existing ticket_key or generates and stores a new one, enabling any worker to decrypt 0‑RTT packets.

Conclusion – By adapting the official Nginx QUIC branch for multi‑instance, multi‑process deployment, adding a Stream‑based load‑balancing layer, employing a multi‑port listening scheme, and sharing TLS ticket keys via Redis, Trip.com achieved stable QUIC service with connection migration and 0‑RTT support, reducing average request latency by about 20% and paving the way for further QUIC feature integration.