How NetEase Cloud’s QUIC Proxy Boosts Audio‑Video Reliability in Weak Networks

Introduction

Providing reliable audio‑video services in extremely weak network conditions is a top priority for NetEase Cloud. This article describes the architectural and technical solutions NetEase Cloud employs to improve the timeliness of reliable data transmission in such environments.

Problems with Traditional TCP‑Based Audio‑Video Services

Low transmission efficiency : TCP’s reliable transmission leads to slow speeds, especially on weak networks.

High connection‑establishment latency : The three‑handshake design causes delayed first‑screen rendering.

Poor weak‑network resilience : Small packet loss can break the link.

Severe head‑of‑line blocking : Ordered packet delivery means loss of a low‑sequence packet blocks subsequent packets until retransmission.

These drawbacks cause reliable data links to break before media links, resulting in delayed signaling and degraded user experience.

Why QUIC?

QUIC (Quick UDP Internet Connection) uses UDP for multiplexed, concurrent transmission, offering SSL/TLS‑level security, reduced connection latency, and bandwidth control to avoid congestion. Its advantages over TCP include:

Simplified TLS handshake (0‑1 RTT vs. 3 RTT for HTTPS).

Multi‑stream design prevents head‑of‑line blocking across streams.

Improved congestion control with per‑stream flow control.

Dynamic connection migration via a 64‑bit ConnectionID.

Forward error correction through redundant packet transmission.

NetEase Cloud’s QUIC Acceleration Architecture

Leveraging QUIC’s benefits, NetEase Cloud built a QUIC acceleration proxy service that provides reliable data transmission between end‑users and edge servers.

The client simultaneously supports QUIC and TCP links; it prefers QUIC and falls back to TCP only when QUIC fails, ensuring high availability even when UDP is blocked.

Design Goals

Accelerate the last‑mile link where weak‑network failures are most common.

Provide UDP/TCP dual insurance for high availability.

Keep acceleration service transparent to business data, enabling easy reuse.

Maintain compatibility with existing architecture for seamless upgrades.

QUIC Front‑Proxy Module

Listens on UDP, receives client QUIC packets, performs decoding, redundancy filtering, bandwidth calculation, redundant packet sending, and integrity checks before forwarding.

QUIC Back‑Proxy Module

Establishes TCP connections or HTTP requests to the backend, packages business data for transparent forwarding, compresses and validates data from the backend before sending it back to the front‑proxy.

Optimizations Implemented on Top of QUIC

First‑screen opening speed : 0‑1 RTT handshake reduces latency by 2 RTT, saving 100‑300 ms in remote areas.

Multi‑stream design : Isolates streams so low‑priority head‑of‑line blocking does not affect high‑priority data.

Signal priority tiers : Higher‑priority data receives higher redundancy.

Optional data compression : zlib compression achieves up to 20 % reduction for JSON signaling data.

CRC verification : Ensures data integrity by terminating connections on checksum failure.

Dynamic redundancy adjustment : Increases redundancy when packet loss is detected and reduces it when the network stabilizes.

Performance in Weak Networks

Comparisons between accelerated (QUIC) and non‑accelerated (TCP) setups show:

~20 % reduction in first‑screen opening time and ~30 % reduction in login latency.

QUIC maintains service up to 70 % upstream and 75 % downstream packet loss, whereas TCP fails around 45 % loss.

Bandwidth utilization exceeds 90 % with QUIC under constrained bandwidth, far surpassing TCP.

Conclusion

NetEase Cloud’s QUIC acceleration architecture delivers a 50 % improvement in packet‑loss tolerance, a 20 % boost in first‑screen speed, and high bandwidth efficiency, establishing a leading position in audio‑video service reliability under weak network conditions.