🚀

QUIC vs WebRTC: Why the Switch Back to QUIC?

A Real-world Case of Switching to QUIC After Struggling with WebRTC Complexity

QUIC is a transport protocol designed by Google and the foundation of HTTP/3. It solves TCP's three chronic problems — slow connection establishment (2-3 RTT), Head-of-Line Blocking (entire stream waits when one packet is lost), and connection drops on IP change — on top of UDP. A real-world remote desktop project (ulalaca → Noctiluca) attempted WebRTC but hit limitations. WebRTC required Chromium source modification, complex signaling/STUN/TURN configuration, inability to fix ports, and SCTP DataChannel HOL Blocking. Switching to QUIC solved all these issues instantly: just open one UDP port, stream independence resolves HOL, and Connection Migration maintains connections even during WiFi AP switches.

Architecture Diagram

Connection Setup: TCP+TLS vs QUIC
TCP + TLS (traditional)
RTT 1 TCP SYN → SYN-ACK → ACK
RTT 2 TLS ClientHello → ServerHello
RTT 3 TLS Finished → Data transfer begins
2-3 RTT required
QUIC
RTT 1 Initial (incl. TLS 1.3) → Connected!
Revisit 0-RTT: Data from the first packet!
1 RTT (revisit 0-RTT)
Head-of-Line Blocking Problem
TCP / WebRTC SCTP
Video Audio Input → BLOCKED
1 packet lost → all blocked
QUIC (independent streams)
Stream 1: Video x lost → Only this retransmitted
Stream 2: Audio ✓ continues
Stream 3: Input ✓ continues
Infrastructure Complexity: WebRTC vs QUIC
WebRTC
Required Signaling server (SDP exchange)
Required STUN server (public IP discovery)
Required TURN server (NAT relay)
Problem No port pinning / no reuse
Problem Chromium source modification needed (custom)
QUIC
Done Just open 1 UDP port
Solved No signaling/STUN/TURN needed
Solved Port pinning possible
Solved Native support (Network.framework etc.)
Connection Migration
📶
WiFi AP-A
IP: 192.168.1.10
AP switch →
📶
WiFi AP-B
IP: 192.168.2.20
TCP/WebRTC
IP change → disconnected
QUIC
Connection ID preserved → no disconnection
Practical lesson: WebRTC is optimized for browser P2P video calls. For custom real-time streaming like remote desktop, QUIC is much simpler and more powerful

How It Works

1

Client sends Initial packet to server UDP port (including TLS 1.3 ClientHello)

2

Server responds with Handshake packet — encryption negotiation + connection established in 1-RTT

3

0-RTT on revisit: data can be sent from the first packet using previous session key

4

Independent stream multiplexing: video/audio/input sent as separate streams, loss in one does not affect others

5

Connection ID-based management: connection persists even when IP changes during WiFi → LTE switch (Connection Migration)

6

Built-in flow control + congestion control for adaptive transmission based on network conditions

Pros

  • ✓ 0-RTT / 1-RTT connection establishment (saves 1-2 RTT vs TCP+TLS)
  • ✓ Head-of-Line Blocking fully resolved (stream independence)
  • ✓ Connection Migration (connection persists despite IP change)
  • ✓ All communication through single UDP port (no complex infrastructure like WebRTC)
  • ✓ Built-in TLS 1.3 (no separate encryption layer needed)

Cons

  • ✗ UDP-based so may be blocked by some firewalls/networks
  • ✗ Compatibility issues with existing TCP middleboxes (firewalls, IDS)
  • ✗ High implementation complexity (custom retransmission, congestion control needed)
  • ✗ Media codecs/echo cancellation not built-in like WebRTC (implement yourself)
  • ✗ Performance degradation possible without UDP-optimized NIC/kernel

Use Cases

HTTP/3 (all modern web browsing) Remote desktop / screen sharing (Noctiluca) Real-time games (low-latency UDP + reliability) Mobile app APIs (frequent network switching) CDN / edge server communication

References

Related

📹
How Does WebRTC Work?
Direct Video/Audio/Data Transfer Between Browsers
→
← 🏆 Making WASM a First-Class Language on the Web 📶 How Does Location Sensing via WiFi CSI Work? →