Transport Layer Overview

When a video conferencing application sends your voice across the ocean, it needs the transport layer to be fast—a 300ms delay makes conversation awkward. When a banking application transfers money, it needs the transport layer to be reliable—losing even one acknowledgment could mean duplicate transactions. When a file synchronization service uploads gigabytes of data, it needs the transport layer to be efficient—maximizing throughput without overloading the network.

The transport layer offers a menu of services to applications. Different protocols provide different combinations of guarantee—and applications must choose wisely. Selecting the wrong transport service can make your application slow, unreliable, network-unfriendly, or all three.

This page systematically examines the services the transport layer can provide, which protocols offer which services, and how applications should choose based on their requirements.

Transport services can be organized into categories based on the guarantees they provide. Understanding this taxonomy helps you reason about what applications need and what protocols offer.

Category 1: Delivery Guarantees

• Reliable delivery: All data sent is eventually delivered (or connection terminates with clear failure)
• Best-effort delivery: Data may be lost without notification
• Partially reliable delivery: Some loss tolerated (e.g., real-time media dropping old frames)

Category 2: Ordering Guarantees

• Ordered delivery: Data arrives in the order it was sent
• Unordered delivery: Data may arrive out of order; application handles reordering if needed
• Per-stream ordering: Multiple independent streams within one connection; ordering within streams but not between

Category 3: Duplicate Handling

• No duplicates: Each data unit delivered exactly once
• Possible duplicates: Same data may arrive multiple times; application must handle idempotently

Category 4: Connection Semantics

• Connection-oriented: Explicit connection setup before data transfer; state maintained for duration
• Connectionless: No setup; each message self-contained and independent

Category 5: Data Boundaries

• Byte stream: Continuous flow of bytes; message boundaries not preserved
• Message-oriented: Discrete messages; each send results in corresponding receive

Category 6: Rate Management

• Congestion-controlled: Sender adapts rate to avoid network overload
• Uncongestion-controlled: Sender transmits at its chosen rate
• Flow-controlled: Sender adapts rate to receiver's consumption capacity

Category 7: Advanced Features

• Multi-homing: Connection survives interface/path changes
• Multi-streaming: Multiple independent data streams within one connection
• Encryption: Built-in transport-layer security

The most fundamental transport service division is between reliable and best-effort delivery. This choice shapes nearly everything else about how a protocol works.

Reliable Delivery (TCP, SCTP, QUIC):

Reliable delivery guarantees that data sent will either:

• Be delivered successfully to the receiving application, OR
• Result in a clear failure notification to the sending application

There's no silent failure—the sender always knows the outcome.

Mechanisms required:

• Acknowledgments: Receiver confirms receipt
• Sequence numbers: Detect and fill gaps
• Retransmission: Resend lost data
• Checksums: Detect and discard corrupted data
• Timeouts: Detect when to retransmit

Best-Effort Delivery (UDP):

Best-effort means the transport layer makes one attempt to deliver data. If it fails:

• No retransmission
• No notification to sender
• Data simply disappears

This sounds terrible—why would anyone choose it?

The Reliability-Latency Trade-off:

Reliability comes at a cost: latency. When a packet is lost:

• TCP waits for timeout (often 200ms+) or duplicate ACKs
• TCP retransmits and waits for acknowledgment
• Subsequent data is held until the gap is filled (head-of-line blocking)

For real-time applications, this delay is unacceptable. A video call with 500ms gaps is worse than one with occasional visual artifacts. These applications prefer:

• Accept some loss
• Conceal lost data at application level (interpolation, error concealment)
• Never wait for retransmissions

Partial Reliability:

Some modern protocols offer partial reliability—controlled data loss:

• SCTP's PR-SCTP: "Deliver this message if possible within 100ms, otherwise drop it"
• QUIC datagrams: Unreliable messages within a reliable connection

This bridges the gap between TCP's full reliability and UDP's no reliability.

Beyond reliability, applications often care about the order in which data arrives. The transport layer offers several ordering models.

Ordered Delivery (TCP):

TCP guarantees all data arrives in the order it was sent. If bytes 1-100 are sent before bytes 101-200, the application receives them in that order, always.

This is powerful but has a cost: head-of-line blocking.

If packet 2 is lost, packets 3, 4, 5... must wait in the receive buffer. The application can't access any of them until packet 2 arrives. For multiplexed connections (HTTP/2 over TCP), a lost packet for one stream blocks all streams.

Unordered Delivery (UDP):

UDP delivers datagrams in whatever order they arrive. If packet 2 arrives before packet 1, the application receives packet 2 first.

For applications that don't need ordering (DNS queries, some game protocols), this avoids head-of-line blocking.

Per-Stream Ordering (SCTP, QUIC):

This hybrid approach offers the best of both worlds:

• Order is maintained within each stream
• But streams are independent—a lost packet on stream A doesn't block stream B

HTTP/3 (over QUIC) uses this: each HTTP request is a stream, so a lost packet affects only that request, not others.

Message Boundaries:

A related question: does the transport preserve message boundaries?

Byte Stream (TCP, QUIC streams):

• No boundaries preserved
• send(100 bytes) + send(200 bytes) → recv() might return 300 bytes
• Application must frame messages explicitly

Message-Oriented (UDP, SCTP):

• Boundaries preserved
• send(100 bytes) + send(200 bytes) → recv() returns 100, then recv() returns 200
• Each message is a discrete unit

Why Byte Stream?

Byte streams are natural for:

• Streaming data (files, video)
• Protocols with variable-length messages (HTTP)
• Connection multiplexing (multiple logical streams over one TCP connection)

Why Messages?

Messages are natural for:

• Request-response patterns
• Discrete events (game state updates)
• RPC-style communication

Transport protocols differ fundamentally in whether they establish connections before data transfer.

Connection-Oriented (TCP, SCTP, QUIC):

Before exchanging data, endpoints perform a handshake:

1. Client sends connection request (SYN)
2. Server acknowledges and accepts (SYN-ACK)
3. Client confirms (ACK)

This establishes:

• Synchronized sequence numbers
• Agreed-upon parameters (window sizes, options)
• State at both endpoints for the connection's lifetime

Connectionless (UDP):

No handshake. The first packet is either a request or data. Each packet is independent—there's no shared state between sender and receiver.

Trade-offs:

Connection Setup Latency:

Connection overhead matters for short interactions:

For a DNS query (one request, one response), TCP's 1.5 RTT setup doubles latency compared to UDP's instant request. For a long-lived web session, setup latency is negligible.

Connection State Costs:

Servers maintaining millions of connections consume significant memory:

• TCP connection: ~280 bytes of kernel state (Linux)
• Plus send/receive buffers: 16KB+ default
• Per-connection timers and data structures

Connectionless servers avoid this—they maintain no per-client state. This is why DNS servers traditionally used UDP.

The transport layer's rate control services prevent senders from overwhelming receivers or networks. These are among the most important—and most underappreciated—transport functions.

Flow Control:

Flow control prevents faster senders from overwhelming slower receivers:

1. Receiver advertises available buffer space (receive window)
2. Sender limits outstanding data to this window
3. As receiver drains buffer, window grows; as buffer fills, window shrinks
4. If window reaches zero, sender stops (and probes periodically)

This creates backpressure—if the application doesn't read data, the send eventually blocks. This feedback prevents buffer overflows.

Congestion Control:

Congestion control prevents all senders collectively from overwhelming the network:

1. Sender maintains a congestion window based on network conditions
2. Packet loss or delay increase signals congestion
3. Sender reduces window (backs off) when congestion detected
4. Sender increases window (probes) when congestion absent
5. AIMD (Additive Increase, Multiplicative Decrease) converges to fair share

Why UDP Lacks Control:

UDP has no flow or congestion control. Why?

1. Connectionless: No state to track windows
2. Message-oriented: Each datagram independent
3. Simple: Minimal protocol logic
4. Application control: Let applications decide their own rate

But this is dangerous:

• Application can overwhelm receiver (data dropped)
• Application can overwhelm network (congestion, affecting all users)
• Uncongestion-controlled UDP at scale causes "congestion collapse"

Application-Layer Rate Control:

UDP applications that send significant data should implement their own congestion control:

• QUIC: Full congestion control over UDP
• WebRTC: Congestion control for video calling
• DCCP: Datagram Congestion Control Protocol (rarely used)
• Custom: Games often implement crude rate limiting

Responsible network citizens don't send unlimited UDP traffic.

Historically, base transport protocols (TCP, UDP) provided no security. Data traversed networks in plaintext, vulnerable to eavesdropping, tampering, and impersonation. Modern applications require more.

Traditional Model: Security as Add-On

Security was added as a layer above transport:

• TLS (Transport Layer Security): Runs over TCP, provides encryption, integrity, authentication
• DTLS (Datagram TLS): Same security for UDP applications

This works but has inefficiencies:

• Separate handshakes for TCP and TLS (2+ RTT combined)
• TLS is technically "application layer" but often called "Layer 4.5"
• Middleboxes can see TCP headers but not TLS content

Modern Model: Integrated Security (QUIC)

QUIC integrates TLS 1.3 directly:

• Transport and security handshakes combined (1 RTT, 0 RTT for resumption)
• All transport headers encrypted (middleboxes can't inspect)
• Authentication of all transport data (can't tamper with headers)

What Security Services Provide:

Confidentiality: Nobody but endpoints can read the data

• Achieved through encryption (AES-GCM, ChaCha20-Poly1305)
• All transmitted bytes are ciphertext

Integrity: Nobody can modify data in transit without detection

• Achieved through authenticated encryption (AEAD)
• Any modification invalidates the authentication tag

Authentication: You know you're talking to the right party

• Achieved through certificates (server proves identity)
• Client authentication optional but common in mutual TLS

Forward Secrecy: Past sessions can't be decrypted if long-term keys are compromised

• Achieved through ephemeral key exchange (ECDHE)
• Each session has unique keys derived from ephemeral secrets

The Encryption Trend:

The Internet is moving toward ubiquitous encryption:

• HTTP → HTTPS (nearly 100% of web traffic now)
• DNS → DoH/DoT (encrypted DNS)
• SMTP → SMTP with TLS (email encryption)
• HTTP/3 mandates QUIC, which mandates encryption

This closes the gap where transport provided no security.

Choosing the right transport protocol requires understanding your application's requirements and mapping them to available services.

The Decision Framework:

1. Must all data arrive?

   • Yes → Need reliable delivery (TCP, SCTP, QUIC)
   • No → Can use best-effort (UDP, or reliable with partial reliability)

2. Does order matter?

   • Yes, all data → Need fully ordered (TCP)
   • Yes, within streams → Can use per-stream ordering (QUIC, SCTP)
   • No → Can use unordered (UDP)

3. Is latency critical?

   • Yes → Minimize handshakes (UDP, QUIC 0-RTT)
   • Yes → Avoid head-of-line blocking (QUIC, UDP)
   • No → TCP is fine

4. Is security required?

   • Yes → TLS over TCP, DTLS over UDP, or QUIC
   • No → Raw TCP/UDP (but increasingly rare)

Common Mistakes:

Mistake 1: Using TCP when UDP is better

• Real-time media over TCP: Head-of-line blocking kills interactivity
• Every lost packet causes visible delay

Mistake 2: Using UDP when TCP is better

• File transfers over UDP: You'll re-implement TCP badly
• Complex reliability logic, probably with bugs

Mistake 3: Ignoring congestion control

• High-bandwidth UDP applications without rate limiting
• Harms other users, may get traffic shaped by ISPs

Mistake 4: Assuming TCP ordering is free

• Multiplexed protocols (HTTP/2) over TCP suffer from HoL blocking
• Consider QUIC for multi-stream applications

The Modern Default:

For most new applications:

• QUIC if available and multi-stream benefits apply (web apps)
• TCP + TLS 1.3 for reliable, secure communication
• UDP only if you truly need minimal latency and can tolerate loss

We've surveyed the full range of services the transport layer offers. Let's consolidate the essential knowledge:

What's Next:

We've explored what the transport layer offers. The final page of this module examines the host's responsibilities in implementing transport services—how operating systems structure transport protocol implementations, handle connection state, and manage the complex dance of timers, buffers, and events that make transport work.