Boosting Global Video Quality: How We Integrated QUIC into Our Client‑Server Architecture

Background

The business is rapidly expanding overseas, where network quality varies widely and degrades user experience for video and voice services. TCP can no longer reliably improve connectivity in complex networks, so we decided to integrate the QUIC protocol to enhance network quality.

QUIC (Quick UDP Internet Connection), proposed by Google, is a UDP‑based transport protocol offering 0‑RTT low latency, connection migration, security, and congestion control.

After integrating QUIC into the client SDK and long‑connection server, overall link connectivity improved by about 0.3‑0.5%, reaching over 99.8%, and connection establishment time in weak networks was roughly 8% faster than TCP.

Solution Selection

The overall solution adds QUIC support to both client and server, upgrades channel interaction logic, and uses QUIC as a backup channel controlled by the server while ensuring high availability. The client maintains message availability across multiple channels, and both ends connect via a cloud provider's four‑layer QUIC‑enabled load balancer.

For the client SDK we adopted the mature Chromium quiche library (https://quiche.googlesource.com/quiche), trimmed it to retain core QUIC functionality, and wrapped it into the ikquic network library.

For the server we used the active and stable open‑source quic-go library, integrating and adapting it into our server network library.

2.1 Client Architecture Design

The client architecture consists of three layers:

Channel layer handling basic socket communication and protocols.

Connection layer managing channel connections and related policies.

Capability layer providing higher‑level SDK functions such as handling vendor push messages.

Design aims to keep the existing TCP channel operational while adding QUIC as a supplementary channel. To ensure high availability, the app establishes dual channels at startup, each maintaining its own active connection pool, and selects the appropriate channel based on strategy during request handling.

The client SDK request flow includes channel switching, channel persistence, and message deduplication. Upstream messages choose the channel based on current network quality, while downstream messages from the server undergo multi‑channel deduplication before reaching business logic.

2.2 Server Architecture Design

The server network library is optimized to support both TCP and QUIC dual‑channel access at the communication layer, storing user connection information separately. Downstream messages are initially sent per connection; after optimization they are dispatched via multiple channels, with the client SDK handling deduplication.

Multi‑dimensional strategy control is added, allowing smooth QUIC rollout and limiting impact scope. Control dimensions include UID whitelist, UID suffix, user region, and client version.

Implementation Details

3.1 QUIC Client SDK Implementation

The client QUIC network library is layered: the bottom layer is based on Chromium, qlink wraps quiche , providing abstract APIs that hide implementation details. Different client platforms can integrate QUIC by adapting the APIs offered by Qlink.

Qlink provides simple APIs; QLinkClientManager manages a pool of client objects from which a usable QUIC client can be obtained. The SDK uses RFCv1 QUIC version to build connections, invoking Chromium’s quic‑core APIs.

Reference path: chromium/src/net/third_party/quiche/src/quiche/quic/core .

Callbacks are set for QUIC connection state changes to allow external logic to react.

3.2 QUIC Server Network Library Implementation

The server’s QUIC capability is built on the open‑source quic-go library, which can be directly called and then wrapped for adaptation.

Reference repository: https://github.com/quic-go/quic-go.git

3.3 Multi‑Channel Management

Connection Strategy

When using long connections, the SDK decides whether to enable the QUIC channel based on configuration:

If QUIC is enabled and the SDK supports it, TCP and QUIC channels compete to establish connections simultaneously.

If QUIC is disabled, the original TCP single‑channel competition remains.

In dual‑channel mode, each channel handles its own reconnection logic if the app goes to background or network jitter causes disconnections.

Message Transmission

In a multi‑channel scenario, the server processes and dispatches messages on all channels; the client SDK deduplicates messages based on a unique identifier before forwarding them to business logic.

The client compares the network score configuration config_score with its current network evaluation score client_score to select the appropriate channel:

If client_score < config_score , use the QUIC channel for upstream messages.

If client_score ≥ config_score , use the TCP channel.

3.4 QUIC Load Balancing

Because UDP is connectionless, it lacks TCP‑style connection binding, but QUIC provides a QUIC ID that can route the same ID to the same backend server, solving traffic mixing issues. Cloud providers already support this capability, typically enabled via the load balancer management console.

Benefits

For long‑connection channels, QUIC as a supplementary channel improves overall connectivity by about 0.3‑0.5%, achieving over 99.8% link success. In weak networks (300 ms–1 s), QUIC reduces connection time by roughly 8% compared to TCP, while in stronger networks TCP may perform slightly better.

Regional variations exist; some areas have lower QUIC connectivity or time‑based and vendor restrictions, so QUIC activation should consider region and cloud provider specifics.

Future Plans

We have achieved global multi‑access‑point coverage and multi‑cloud hybrid deployment, meeting current business needs. As traffic grows, we will continue to:

Fine‑tune links to further reduce latency, improve congestion control, and enhance anomaly monitoring.

Develop richer multi‑channel capabilities, mixing self‑built long connections with HTTP/HTTP3 links and enabling seamless switching.

Collaborate with vendors to optimize edge‑region access, potentially leveraging acceleration products.