Optimizing Tencent Meeting’s Network Connectivity with QUIC: Reducing Handshake Latency and Enabling Seamless Wi‑Fi/Cellular Switching

When users join a Tencent Meeting and the network switches from Wi‑Fi to cellular (or vice‑versa), the video often freezes ("spinning flower") because the TCP+TLS long‑connection must be torn down and re‑established. Statistics show that 41.53% of login failures are caused by connection‑establishment timeouts, especially on weak networks.

Traditional TCP+TLS requires a 1.5 RTT TCP three‑way handshake plus a 1 RTT TLS 1.3 handshake, resulting in a total of 2.5 RTT before any application data can be exchanged. This latency makes the meeting experience fragile when the underlying IP changes.

QUIC offers several advantages over TCP for this scenario:

0‑RTT or 1‑RTT connection establishment (no separate TLS handshake).

Built‑in encryption, eliminating the need for a separate TLS layer.

Connection migration via a stable connection_id , allowing the long‑link to survive IP changes without breaking.

The QUIC handshake flow (see Fig. 3) completes in a single RTT: the client receives a server Rejection, then sends the first data packet containing its encrypted credentials, completing both handshake and data transmission together. Compared with TCP+TLS, this saves about 1.5 RTT, which translates to a 40‑50% reduction in overall connection‑setup time for the meeting service.

To adopt QUIC, the team evaluated several implementations (Cronet, QuicTransport, TQUIC). TQUIC, built on Tencent’s Secure Tencent Gateway (stgw), was chosen for its lightweight SDK and compatibility with the existing backend.

Key engineering challenges addressed:

Middleboxes that drop UDP packets.

Enterprise firewalls blocking QUIC ports.

Potential server‑cluster failures causing mass QUIC connection loss.

Crash‑protection for the new SDK to avoid login failures.

Four mitigation strategies were deployed before full rollout:

Pre‑switch probing to ensure the network path can carry QUIC.

Cloud‑controlled feature flags for regional, version, and user‑level rollout.

Automatic fallback to TCP when QUIC errors occur.

Crash‑guard that degrades to TCP on SDK crashes.

After integration, performance measurements showed:

Average login latency reduced by 48.6%.

Login success rate improved by 0.09%.

In high‑loss scenarios (70% packet loss), TCP long‑links dropped, while QUIC sustained the heartbeat up to 80% loss (Fig. 10).

User‑perceived issues such as “spinning flower” during network switches were eliminated.

Future work includes extending QUIC to HTTP traffic for faster page loads and further leveraging its multiplexing and 0‑RTT capabilities.