101
0/240
Loading content...
The Internet Layer delivers packets from one host to another, but applications need more. When your web browser requests a page, that data must reach the browser process specifically—not just the computer. When you're running multiple applications simultaneously—email, streaming music, downloading files—each one needs its data delivered to the correct destination process, reliably and in order.
This is the domain of the Transport Layer: the crucial bridge between the network's host-to-host delivery and the application's process-to-process communication needs. Here, two protocols dominate: TCP (Transmission Control Protocol), providing reliable, ordered byte streams, and UDP (User Datagram Protocol), offering lightweight, best-effort datagram delivery.
By the end of this page, you will understand port addressing and multiplexing, master TCP's connection management and reliability mechanisms, comprehend UDP's design and appropriate use cases, and appreciate the critical roles of flow control and congestion control in maintaining network stability.
The Transport Layer provides end-to-end communication services that the Internet Layer cannot. While IP delivers packets between hosts using IP addresses, the Transport Layer delivers data between processes using port numbers, and can optionally provide reliability guarantees that IP's best-effort delivery lacks.
The End-to-End Principle in Action
The Transport Layer embodies the end-to-end principle that TCP/IP is famous for. Rather than building reliability into the network itself (which would require complex, stateful routers), reliability is implemented at the endpoints. Routers focus solely on packet forwarding; hosts handle everything else.
This design has profound implications:
The Transport Layer is the first truly end-to-end layer. While the Internet Layer involves every router along the path, Transport Layer protocols operate only at the source and destination hosts. Intermediate routers see only IP packets—they're unaware of TCP connections or UDP associations.
A single host can run dozens of network-connected applications simultaneously. Port numbers solve the problem of directing incoming data to the correct application. A port is a 16-bit number (0-65535) that identifies a specific process or service on a host.
The Complete Address
Network communication requires a 5-tuple to uniquely identify a connection:
(Source IP, Source Port, Destination IP, Destination Port, Protocol)
For example:
(192.168.1.10, 54321, 142.250.80.46, 443, TCP)
└── Client └── google.com └── HTTPS
Port Number Ranges
| Range | Category | Description |
|---|---|---|
| 0-1023 | Well-Known (System) | Reserved for standard services (HTTP=80, HTTPS=443, SSH=22) |
| 1024-49151 | Registered | Assigned by IANA for specific applications |
| 49152-65535 | Dynamic/Ephemeral | Used by clients for outgoing connections |
| Port | Protocol | Service |
|---|---|---|
| 20-21 | TCP | FTP (Data/Control) |
| 22 | TCP | SSH |
| 23 | TCP | Telnet |
| 25 | TCP | SMTP (Email) |
| 53 | TCP/UDP | DNS |
| 67-68 | UDP | DHCP |
| 80 | TCP | HTTP |
| 110 | TCP | POP3 |
| 143 | TCP | IMAP |
| 443 | TCP | HTTPS |
| 3389 | TCP | RDP |
Multiplexing and Demultiplexing
Multiplexing (at the sender): Multiple applications send data through the Transport Layer, which packages each with appropriate source port, destination port, and protocol headers.
Demultiplexing (at the receiver): The Transport Layer examines incoming segments, uses the port numbers to determine which application should receive the data, and delivers it to the correct socket.
Sender Side: Network Receiver Side:
┌─────────────┐ ┌─────────────┐
│ Web Browser │─┐ ┌───│ Web Server │
│ (Port 443) │ │ │ │ (Port 443) │
└─────────────┘ │ ┌────────────────┐ ┌─────────────┐ │ └─────────────┘
├────│ Transport Layer│────│ Network │───┤
┌─────────────┐ │ │ (Multiplexing) │ │ │ │ ┌─────────────┐
│ Email Client│─┘ └────────────────┘ └─────────────┘ └───│ Mail Server │
│ (Port 25) │ │ (Port 25) │
└─────────────┘ └─────────────┘
A socket is the programming interface to the Transport Layer. It's identified by (IP address, port, protocol). Applications create sockets to send and receive data. The combination of local socket and remote socket uniquely identifies a connection.
Transmission Control Protocol (TCP), defined in RFC 793, provides a reliable, ordered, byte-stream service. When an application sends data over TCP, it's guaranteed to arrive at the destination correctly, in order, without duplicates or losses—despite the underlying IP network providing no such guarantees.
TCP Segment Structure
A TCP segment consists of a header (20-60 bytes) followed by data:
| Field | Size | Description |
|---|---|---|
| Source Port | 16 bits | Sending process port |
| Destination Port | 16 bits | Receiving process port |
| Sequence Number | 32 bits | Position of first byte in stream |
| Acknowledgment Number | 32 bits | Next byte expected from sender |
| Data Offset | 4 bits | Header length in 32-bit words |
| Flags | 9 bits | Control bits: SYN, ACK, FIN, RST, PSH, URG, etc. |
| Window Size | 16 bits | Receiver's buffer space (flow control) |
| Checksum | 16 bits | Error detection over header + data |
| Urgent Pointer | 16 bits | Points to urgent data (rarely used) |
| Options | Variable | MSS, window scaling, SACK, timestamps |
TCP provides a byte stream, not a message stream. If you write 100 bytes, then 200 bytes, TCP might deliver them as 150 + 150, or 300 at once. Applications must implement their own message boundaries (e.g., HTTP's Content-Length header). This is a common source of bugs—never assume TCP preserves message boundaries.
TCP connections are explicitly established and terminated. This connection-oriented approach allows both ends to synchronize state, negotiate parameters, and ensure clean resource cleanup.
Three-Way Handshake (Connection Establishment)
Before data transfer, TCP performs a three-way handshake to establish a connection:
Why three messages? Two wouldn't be enough—both sides need to confirm the other received their sequence number. Four would be redundant.
Four-Way Handshake (Connection Termination)
Closing a connection requires four messages because TCP is full-duplex—each direction must be closed independently:
Connection States
TCP maintains state machines on both sides. Key states include:
TIME_WAIT state lasts 2×MSL (typically 60 seconds). High-traffic servers can accumulate thousands of TIME_WAIT connections. Solutions include SO_REUSEADDR socket option, TCP Fast Open, or connection pooling. Don't 'fix' this by reducing TIME_WAIT—it exists to handle edge cases correctly.
TCP provides reliable delivery over an unreliable network through several mechanisms working together: sequence numbers, acknowledgments, retransmissions, and checksums.
How Retransmission Works
Consider sending segments containing bytes 1000-1999, 2000-2999, and 3000-3999:
Sender Receiver
│ │
├─── Seq=1000, Data[1000] ────────>│ ✓ Received
│<──────────── ACK=2000 ───────────┤
├─── Seq=2000, Data[1000] ────────>│ ✗ LOST!
├─── Seq=3000, Data[1000] ────────>│ ✓ Received (but out of order)
│<──────────── ACK=2000 ───────────┤ (still waiting for 2000-2999)
│<──────────── ACK=2000 ───────────┤ (duplicate ACK)
│ │
├─── Seq=2000, Data[1000] ────────>│ ✓ Retransmitted after timeout
│<──────────── ACK=4000 ───────────┤ (now all received)
Fast Retransmit
Waiting for timeout is slow. TCP uses fast retransmit: if three duplicate ACKs are received, the segment is retransmitted immediately without waiting for timeout. This indicates the segment was likely lost, not just delayed.
TCP continuously estimates round-trip time (RTT) using ACK timing. The retransmission timeout (RTO) is set to RTT plus a safety margin. This allows TCP to work efficiently on both fast LANs (low timeout) and slow satellite links (high timeout). Jacobson's algorithm handles RTT variance to avoid spurious retransmissions.
TCP implements two distinct rate-limiting mechanisms: flow control (preventing receiver overload) and congestion control (preventing network overload). Though they both limit sending rate, they address different problems.
The Sliding Window
TCP uses a sliding window to track what can be sent:
Sending Window = min(Receiver Window, Congestion Window)
The sender can have up to window_size bytes in flight (sent but not acknowledged). As ACKs arrive, the window slides forward.
Congestion Control Phases
Slow Start: Begin with cwnd=1 MSS; double cwnd each RTT. Despite the name, growth is exponential—very fast.
Congestion Avoidance: After reaching ssthresh (slow start threshold), grow cwnd by 1 MSS per RTT. Linear growth.
Fast Recovery (after loss): On packet loss (3 duplicate ACKs), halve cwnd and continue in congestion avoidance. Avoids slow restart.
Timeout Recovery: If retransmission timeout occurs, reset cwnd to 1 MSS and restart slow start. More severe response.
The classic Reno/NewReno algorithms have evolved. BBR (Google) uses bandwidth and RTT measurements instead of loss. CUBIC (Linux default) improves high-bandwidth-delay product networks. Data centers use specialized algorithms like DCTCP. The choice of congestion control algorithm significantly impacts performance.
User Datagram Protocol (UDP), defined in RFC 768, provides a minimal transport service: port-based multiplexing with an optional checksum. It adds almost nothing to raw IP delivery—and that's exactly the point.
UDP Header Structure
UDP's simplicity is evident in its header:
| Field | Size | Description |
|---|---|---|
| Source Port | 16 bits | Sending port (optional: can be 0) |
| Destination Port | 16 bits | Receiving port |
| Length | 16 bits | Total datagram length (header + data) |
| Checksum | 16 bits | Error detection (optional in IPv4, mandatory in IPv6) |
The entire header is just 8 bytes. Compare to TCP's minimum 20 bytes.
When to Use UDP
| Use Case | Why UDP Fits |
|---|---|
| DNS queries | Single request/response, retries at application level |
| Video streaming | Late packets are useless; better to skip than wait |
| Online gaming | Real-time updates; old state is obsolete |
| VoIP | Audio delay is worse than occasional dropouts |
| IoT/sensors | Minimal overhead for tiny devices |
| QUIC protocol | Implements reliability above UDP, avoiding TCP's limitations |
UDP and Application-Layer Reliability
Many UDP-based protocols implement their own reliability:
This gives applications control: they implement exactly the reliability they need, no more.
UDP applications that blast data without congestion control can harm other traffic and even cause network collapse. Well-designed UDP applications should implement their own congestion control (like QUIC does) or rate-limit their transmissions. This is especially important for bulk data transfer over UDP.
We've explored the Transport Layer comprehensively. Let's consolidate the key insights:
What's Next
With the Transport Layer understood, we ascend to the Application Layer—where users finally interact with network services. You'll learn how HTTP powers the web, how DNS translates names to addresses, how email protocols deliver messages, and how the protocols that developers work with daily operate at the top of the TCP/IP stack.
You now understand the Transport Layer's role as the bridge between network-level delivery and application-level communication, including TCP's reliability mechanisms, connection management, flow and congestion control, and UDP's lightweight alternative. This knowledge is essential for understanding network performance, debugging connection issues, and choosing appropriate protocols for applications.