Applying and Optimizing QUIC in Trip.com Mobile App: Experience and Practices

Trip.com APP, which primarily serves overseas users, faced long latency, high packet loss, and frequent request failures due to its original TCP‑based network stack; in early 2021 the team introduced QUIC to improve network quality, ultimately reducing latency by 20% and raising success rate to 99.5%.

Background : TCP’s connection‑oriented nature caused failures when users switched networks or NAT rebinding occurred, its CUBIC congestion control performed poorly on long‑haul, weak‑network paths, and head‑of‑line blocking added extra delay.

QUIC, a reliable UDP‑based protocol, offers 0‑RTT, connection migration, no head‑of‑line blocking, and pluggable congestion control, making it well‑suited for Trip.com’s overseas‑to‑domestic request scenario.

Supporting infrastructure : The client implementation is based on Google’s open‑source Cronet, which was heavily trimmed and customized; the server side runs a custom Nginx QUIC branch with numerous bug fixes and adaptations.

Application and optimization practices :

1. Cronet code trimming : By removing unnecessary modules and keeping only QUIC, QPACK, and BoringSSL, the library size was reduced by over 60%.

2. IP direct‑connect : Modified Cronet to specify the optimal QUIC IP, bypassing DNS resolution and maintaining a dynamic IP list, which eliminated DNS latency and failures.

3. Support for multiple links per domain : Added an IP parameter to HTTP requests and overloaded the QuicSessionKey with IP+Host to enable a QUIC link pool that can select the best link among several IPs.

4. 0‑RTT optimization : Explained TLS 1.3 handshake flow, early data usage, and the difference between GET (which can send early data) and POST (which cannot). Early data is enabled only for idempotent requests, with memory‑cached SCFG tickets to avoid replay attacks.

5. Connection migration : Customized connection‑ID generation to embed host features and introduced a QUIC SLB layer that forwards packets based on the connection ID, ensuring seamless migration when the client’s IP or network changes.

6. QPACK optimization : Configured http3_max_table_capacity (16 KB) and http3_max_blocked_streams to balance compression ratio and head‑of‑line blocking, and treated rapidly changing header fields (e.g., GUIDs) specially to avoid dynamic‑table overflow.

Example of a raw HTTP/3 header before compression:

{
  :authority: www.trip.com
  :method: POST
  cookie:this is a very large cookie maybe more than 2k
  x-trip-defined-header-field-name: trip defined headerfield value
}

After first‑pass QPACK compression the header becomes:

{
  0: d1,
  20,
  5:d2,
  d3,
}

7. Congestion‑control algorithm comparison : Cronet supports CUBIC, BBR, and BBRv2; experiments showed BBR delivering the best performance for Trip.com’s traffic, so it is the default choice.

8. Usage‑mode optimization : A hybrid framework selects TCP or QUIC at app start or network change based on weighted scoring; QUIC is used for >80% of requests, while TCP/HTTP2 serve as fallbacks for networks that block UDP or have unsuitable conditions.

Summary and outlook : QUIC’s fine‑grained flow control, pluggable congestion control, 0‑RTT, connection migration, and multiplexing have yielded significant performance gains. After more than a year of practice, the team plans to open‑source the entire customized network solution to enable a truly “out‑of‑the‑box” QUIC experience for other developers.