Free lesson · Computer Networking

Comparing Transport Protocols

Easy11 min readnetworkingcomputer-networkstcp-ip

Choosing the Right Transport

This module has covered TCP (Module 05), UDP, QUIC, RTP, and multicast. Each protocol makes different trade-offs between reliability, latency, complexity, and control. This topic brings them together with a comprehensive comparison, introduces SCTP (a protocol that appears in interviews but rarely in practice), and provides a decision matrix for protocol selection in System Design contexts.

The goal is not to memorize a table. It is to internalize the trade-offs deeply enough that when an interviewer says "design a real-time analytics dashboard" or "design a peer-to-peer file sharing system," you can articulate a transport protocol choice with confidence and nuance.

Comprehensive Protocol Comparison

TCP - The Reliable Default

What it provides: Connection-oriented, reliable, ordered byte stream delivery. Flow control (sliding window), congestion control (CUBIC/BBR), and guaranteed delivery of every byte in order.

What it costs: 1 RTT connection setup, per-connection kernel state, retransmission delays on loss, head-of-line blocking when multiplexing, no connection migration, slow protocol evolution (kernel-implemented).

Best for: Web applications (HTTP/1.1, HTTP/2), APIs, databases, file transfers, email, SSH - any application where correctness and completeness are non-negotiable and latency variability from retransmission is acceptable.

Avoid when: Real-time media delivery, high-frequency state updates where stale data has no value, or applications that multiplex independent streams and are sensitive to HOL blocking on lossy networks.

UDP - The Raw Canvas

What it provides: Connectionless, unreliable datagram delivery. Source and destination port multiplexing, optional checksum, and nothing else. 8-byte header, zero connection state, zero latency overhead.

What it costs: The application must handle (or accept) packet loss, reordering, and congestion. No flow control means the sender can overwhelm the receiver. No congestion control means the sender can contribute to network congestion.

Best for: DNS, DHCP, NTP, real-time media (via RTP), online gaming, and as a substrate for higher-level protocols (QUIC, WireGuard, VXLAN) that implement their own reliability semantics.

Avoid when: The application needs reliable delivery and does not want to implement its own reliability. Using raw UDP for anything that requires guaranteed delivery is reinventing TCP poorly.

QUIC - The Modern Transport

What it provides: Connection-oriented, reliable, multiplexed streams with per-stream independence. Integrated TLS 1.3 (1-RTT / 0-RTT), connection migration, and userspace implementation for rapid evolution.

What it costs: Higher CPU usage than TCP (userspace processing), less mature tooling (debugging, monitoring), potential UDP blocking on some networks, and the need for QUIC-aware infrastructure (load balancers, monitoring).

Best for: HTTP/3 web traffic (especially on mobile/lossy networks), applications multiplexing independent streams, mobile applications that benefit from connection migration, and any new protocol that wants stream-level independence with built-in encryption.

Avoid when: Operating in data center environments where TCP's kernel-based processing is more efficient and loss is negligible. Also when operating in network environments that block or throttle UDP traffic.

SCTP - The Telecom Protocol

SCTP (Stream Control Transmission Protocol), defined in RFC 4960, is a transport protocol originally designed for signaling in telecom networks (SS7 over IP). SCTP provides several features that neither TCP nor UDP offer:

Multi-streaming: A single SCTP association (connection) supports multiple independent streams. Unlike TCP, where a lost segment blocks all data, SCTP's streams are independently ordered - a loss on one stream does not block other streams. This is the same property that QUIC provides, and SCTP had it first (SCTP was standardized in 2000, QUIC in 2021).

Multi-homing: An SCTP association can span multiple IP addresses on each endpoint. If the primary path fails (a network interface goes down), SCTP automatically switches to an alternate path. This provides network-level redundancy without application changes - particularly valuable for telecom systems that require high availability.

Message boundaries: TCP is a byte stream - it does not preserve message boundaries. The application must implement its own framing (length prefixes, delimiters) to determine where one message ends and another begins. SCTP preserves message boundaries - each send() corresponds to a discrete message received by a single recv(). This eliminates the framing problem entirely.

Ordered and unordered delivery: SCTP supports both ordered delivery (like TCP) and unordered delivery (like UDP) on a per-message basis within the same association. The application can choose per-message whether ordering is required.

Despite these advantages, SCTP has seen minimal adoption outside of telecom:

NAT/firewall incompatibility. Most NAT devices and firewalls do not understand SCTP and either drop it or cannot track associations correctly. This makes SCTP unusable across the public internet for most applications.

Kernel-level implementation required. Like TCP, SCTP is implemented in the OS kernel. Unlike TCP (which is universally available), SCTP support varies: Linux has kernel SCTP support, but macOS and Windows have limited or no native support. Applications must often use userspace SCTP libraries, negating the kernel performance advantage.

QUIC largely supersedes it. QUIC provides multi-streaming (with per-stream independence), runs on UDP (traversing NATs and firewalls), and has massive ecosystem investment from Google, Cloudflare, and browser vendors. For most applications where SCTP's multi-streaming would be valuable, QUIC is the pragmatic choice.

SCTP remains important in its original domain: telecom signaling (Diameter, SIP trunk), and it is used by WebRTC's data channels (SCTP over DTLS over UDP - a stack that works around the NAT traversal problem by tunneling SCTP through UDP). Understanding SCTP demonstrates breadth of knowledge in interviews, even though you are unlikely to deploy it for new applications.

graph TD
    subgraph Comparison["Transport Protocol Feature Matrix"]
        direction TB
        subgraph Reliable["Reliable Protocols"]
            TCP_BOX["TCP<br/>Byte stream<br/>Kernel<br/>Universal support"]
            QUIC_BOX["QUIC<br/>Multi-stream<br/>Userspace<br/>Growing support"]
            SCTP_BOX["SCTP<br/>Multi-stream +<br/>multi-homing<br/>Telecom only"]
        end
        subgraph Unreliable["Unreliable Protocols"]
            UDP_BOX["UDP<br/>Datagram<br/>Kernel<br/>Universal support"]
        end
    end

    style TCP_BOX fill:#22c55e,stroke:#16a34a,color:#fff
    style QUIC_BOX fill:#3b82f6,stroke:#2563eb,color:#fff
    style SCTP_BOX fill:#f59e0b,stroke:#d97706,color:#fff
    style UDP_BOX fill:#ef4444,stroke:#dc2626,color:#fff

This diagram organizes the four transport protocols by reliability. In the reliable category: TCP provides a byte stream with kernel implementation and universal support; QUIC provides multi-stream with userspace implementation and growing support; and SCTP provides multi-stream plus multi-homing but is limited to telecom. In the unreliable category: UDP provides datagram delivery with kernel implementation and universal support.

Protocol Overhead Comparison

Understanding the concrete overhead of each protocol helps justify choices:

Connection Establishment

On a 100ms RTT mobile connection, the difference between TCP+TLS (200ms) and QUIC resumed (0ms) represents a significant user-perceptible improvement in page load speed. This is why QUIC's impact is most visible on mobile networks.

Per-Packet Overhead

For small messages (DNS queries, game state updates), header overhead relative to payload size matters significantly. A 50-byte DNS query has 16% overhead with UDP (8/50) versus 40%+ with TCP (20+/50), not counting the handshake bytes.

Bandwidth Efficiency

TCP's acknowledgment traffic consumes bandwidth (typically 5-10% of the data stream for bulk transfers). UDP has zero acknowledgment overhead. QUIC's acknowledgments are more compact than TCP's (QUIC ACK frames encode ranges efficiently) but still consume bandwidth. For asymmetric workloads (video streaming, file downloads), acknowledgment overhead is a real cost - TCP ACKs flowing upstream consume upstream bandwidth that might be scarce on asymmetric connections like cable and DSL.

Practical Deployment Considerations

Beyond protocol features, deployment realities affect protocol choice:

Library and ecosystem maturity. TCP has 40+ years of battle-tested implementations in every operating system, language, and framework. QUIC has high-quality implementations (quiche by Cloudflare, msquic by Microsoft, ngtcp2, quic-go) but the ecosystem is still maturing - debugging tools, monitoring integrations, and operational playbooks are less developed. Choosing QUIC for a new project means accepting a less mature operational story.

Team expertise. If the engineering team has deep TCP operational experience (tuning sysctl parameters, interpreting tcpdump captures, managing connection pools) but no QUIC experience, the transition involves a learning curve. TCP problems are well-understood; QUIC problems are newer and may require reading RFCs to diagnose.

Infrastructure compatibility. Load balancers, WAFs, DDoS mitigation systems, and monitoring tools may not fully support QUIC. Before choosing QUIC, verify that the entire infrastructure stack (not just the application) can handle it.

Regulatory and compliance requirements. Some industries require traffic inspection for compliance (financial services, healthcare). QUIC's encrypted transport makes deep packet inspection impossible without terminating the QUIC connection at an inspection point. This may require architectural changes to maintain compliance.

Decision Matrix for System Design

Use this matrix when choosing a transport protocol during System Design interviews. Find the row that matches your application's characteristics:

The Future of Transport

The transport layer is evolving in several directions:

QUIC adoption continues to grow. As of 2025, roughly 8-10% of internet traffic uses QUIC, up from near zero in 2020. Major CDNs, browsers, and cloud providers support it. QUIC will likely become the dominant web transport protocol within the next decade, though TCP will remain for non-HTTP protocols and data center communication.

Application-level protocols over QUIC. WebTransport, DNS over QUIC, and Media over QUIC are extending QUIC beyond HTTP/3. QUIC's stream multiplexing and connection migration make it attractive for any protocol that would benefit from these features.

Kernel bypass and DPDK. High-performance networking increasingly bypasses the kernel entirely, using technologies like DPDK (Data Plane Development Kit) and io_uring to process packets in userspace with minimal overhead. This blurs the line between kernel TCP and userspace QUIC - both may eventually run in userspace on high-performance systems.

eBPF and programmable transport. Linux's eBPF (extended Berkeley Packet Filter) enables custom packet processing logic at the kernel level without modifying the kernel itself. eBPF programs can implement custom congestion control, load balancing, and protocol logic with near-native performance, potentially enabling TCP-like efficiency with QUIC-like flexibility.

Post-TCP transport research. Academic research continues exploring alternatives: Homa (a transport protocol designed specifically for data center RPCs with microsecond-scale latency), pHost (priority-based transport), and various RDMA-over-Ethernet approaches for ultra-low-latency communication within data centers.

graph LR
    subgraph Timeline["Transport Protocol Evolution"]
        direction LR
        ERA1["1980s–2000s<br/>TCP + UDP<br/>dominate"]
        ERA2["2010s<br/>QUIC emerges<br/>HTTP/2 deploys"]
        ERA3["2020s<br/>HTTP/3 + QUIC<br/>standardized<br/>30%+ CDN traffic"]
        ERA4["2030s (projected)<br/>QUIC majority web<br/>MoQ for media<br/>eBPF custom transport"]
    end

    style ERA1 fill:#94a3b8,stroke:#64748b,color:#fff
    style ERA2 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style ERA3 fill:#4f46e5,stroke:#4338ca,color:#fff
    style ERA4 fill:#22c55e,stroke:#16a34a,color:#fff

This timeline shows the evolution of transport protocols. From the 1980s through the 2000s, TCP and UDP dominated with no serious alternatives. In the 2010s, QUIC emerged from Google and HTTP/2 was deployed. In the 2020s, HTTP/3 and QUIC were standardized by the IETF, with over 30% of CDN traffic using QUIC. Looking to the 2030s, QUIC is projected to carry the majority of web traffic, with Media over QUIC replacing RTP for some use cases and eBPF enabling custom transport logic in the kernel.

Module Summary

This module has taken you from UDP's 8-byte simplicity through QUIC's sophisticated stream multiplexing, from real-time media delivery with RTP to one-to-many distribution with multicast. The transport layer is where the most consequential protocol decisions are made in system design - TCP vs UDP is not a trivia question but a design decision that affects latency, reliability, scalability, and user experience.

The key takeaways:

UDP is not "worse TCP." It is a deliberately minimal protocol that gives applications full control over reliability, ordering, and timing. For real-time, high-frequency, and loss-tolerant workloads, UDP's simplicity is its strength.

QUIC is not "UDP with extras." QUIC is a complete, modern transport protocol that addresses TCP's fundamental limitations (HOL blocking, connection setup latency, protocol ossification, connection migration) while running on UDP to traverse existing network infrastructure.

The right protocol depends on the workload. There is no universally best transport protocol. The decision framework in this topic - evaluating reliability requirements, ordering needs, latency sensitivity, and communication patterns - should become second nature in System Design interviews.

Interview: The comprehensive protocol comparison demonstrates breadth and depth:

"Tell me about SCTP." - SCTP provides multi-streaming (independent ordered streams in one association), multi-homing (automatic failover between network interfaces), and message boundary preservation. It was designed for telecom signaling (SS7 over IP) and is used by WebRTC data channels. However, poor NAT/firewall traversal and limited OS support have prevented general adoption. QUIC provides similar multi-streaming benefits with better ecosystem support.

"What is the future of transport protocols?" - QUIC adoption is growing rapidly for web traffic. New protocols are being built on QUIC: WebTransport for interactive applications, DNS over QUIC for encrypted DNS, Media over QUIC for live streaming. Within data centers, kernel bypass technologies (DPDK, RDMA) and eBPF are enabling custom transport logic. TCP will remain the workhorse for non-HTTP protocols and server-to-server communication, but the transport layer is more diverse and active than at any point in the last 40 years.

"When would you choose TCP over everything else?" - When you need reliable, ordered delivery and the ecosystem is mature: database connections, internal microservice RPC, file transfers, email. TCP's universal support, mature tooling, kernel-optimized performance, and decades of operational knowledge make it the safe, correct default for most applications. Choose an alternative only when TCP's specific limitations (HOL blocking, connection setup latency, no migration) are causing measurable problems for your workload.

Exercise: Starter: For each protocol in this topic (TCP, UDP, QUIC, SCTP), name one application where it is the clearly correct choice and one where it would be the wrong choice. Write one sentence explaining each answer.

Intermediate: Design the transport layer for a collaborative online game that includes: real-time player movement (60 updates/sec), text chat, voice chat, and a leaderboard. Which transport protocol would you use for each component? Can you use different protocols for different components? What happens if UDP is blocked by the player's network?

Advanced: Research the Homa transport protocol (Montazeri et al., Stanford 2018). Homa is designed specifically for data center RPCs and claims to achieve 99th percentile latencies 100x lower than TCP for short messages. How does Homa achieve this? Why does it work only in data center environments? Compare Homa's approach to TCP's congestion control and QUIC's stream multiplexing. Could Homa replace TCP for internal microservice communication? What would the operational challenges be?

Back to Computer Networking