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.
Noctiluca Dev Story โ How QUIC Was Reached
A developer called unstabler posted their real-world development journey on GeekNews. They insisted on using Linux desktop but needed to build iOS apps, so they built their own remote control software.
Attempt 1: xrdp + ulalaca
Tried attaching xrdp (open-source RDP) to macOS via a VNC backend + ScreenCaptureKit plugin called 'ulalaca.' Never reached practical usability โ GFX/RemoteFX codec support disappeared from Windows, and debugging audio/clipboard sync was nightmarish.
Attempt 2: WebRTC
Retried with WebRTC after shelving ulalaca for 6 months. WebRTC had its own walls:
Customization barrier: Had to modify and rebuild Chromium source code just to use screen data as video source
Port fixation impossible: Needed signaling server + STUN/TURN, couldn't fix outgoing ports
SCTP curse: WebRTC DataChannel uses SCTP internally โ when payload exceeds MTU, video/audio streams start lagging
Attempt 3: QUIC โ Finally solved
Shelved again for 6 months. Remembered QUIC while spacing out at a cafรฉ. macOS/iOS Network.framework provides QUIC, so prototyping was fast โ and every WebRTC problem was instantly solved.
HOL Blocking solved: QUIC streams are independent. One lost audio packet doesn't freeze mouse input or video frames.
Single UDP port: No signaling/STUN/TURN complexity. Just open one UDP port. Connection Migration keeps sessions alive across WiFi AP switches.
Community reaction โ Parsec comparison
'Just use Parsec?' โ Parsec is excellent but requires matching monitor sizes and doesn't support mobile (iPad). Noctiluca targets what Parsec can't: RemoteApp-style individual window display, USB redirection, and ultimately iOS development from a Linux laptop.
Why QUIC fits remote control
| Issue | WebRTC | QUIC |
|---|---|---|
| Infra complexity | Signaling+STUN+TURN | 1 UDP port |
| Customization | Modify Chromium source | Standard libraries |
| HOL Blocking | Occurs in SCTP DataChannel | Resolved by stream independence |
| Port fixation | Impossible | Possible |
| Connection Migration | Not supported | Built-in |
| Media codecs | Built-in (pro and con) | DIY (more freedom) |
Architecture Diagram
How It Works
Client sends Initial packet to server UDP port (including TLS 1.3 ClientHello)
Server responds with Handshake packet โ encryption negotiation + connection established in 1-RTT
0-RTT on revisit: data can be sent from the first packet using previous session key
Independent stream multiplexing: video/audio/input sent as separate streams, loss in one does not affect others
Connection ID-based management: connection persists even when IP changes during WiFi โ LTE switch (Connection Migration)
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