The TCP/IP Model: The Internet's Architectural Blueprint
Transport Layer
Read aloud is unavailable in this browser.
From Host-to-Host to Process-to-Process
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.
Transport Layer Responsibilities
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.
- •Process Multiplexing/Demultiplexing — Port numbers identify specific processes, allowing multiple applications on one host to communicate simultaneously over the network
- •Reliable Data Transfer — TCP ensures all data arrives correctly, in order, without duplicates—despite an unreliable underlying network
- •Flow Control — Prevents a fast sender from overwhelming a slow receiver by regulating transmission rate based on receiver capacity
- •Congestion Control — Prevents network collapse by detecting and responding to network congestion, adjusting transmission rate accordingly
- •Connection Management — TCP establishes and terminates logical connections, maintaining state for reliable communication
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:
- Network Core Simplicity: Routers are fast and simple, processing billions of packets without maintaining connection state
- Flexibility: Applications choose their transport protocol based on needs—reliable TCP for file transfer, fast UDP for gaming
- Resilience: If any intermediate device fails, endpoints can adapt; reliability doesn't depend on any single router
- Innovation: New transport protocols can be deployed without changing the network infrastructure
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.
Port Addressing and Multiplexing
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.
TCP: Reliable Byte Stream Service
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.
- •Connection-oriented — Explicit connection establishment before data transfer (three-way handshake)
- •Reliable delivery — All data is acknowledged; lost segments are retransmitted
- •Ordered delivery — Sequence numbers ensure data arrives in the correct order
- •Byte-stream service — Applications see a continuous stream of bytes, not discrete messages
- •Full-duplex — Data can flow simultaneously in both directions
- •Flow control — Receiver advertises window size to prevent buffer overflow
- •Congestion control — Dynamically adjusts transmission rate based on network conditions
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 Connection Management
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:
- SYN: Client sends a segment with SYN flag, its initial sequence number (ISN)
- SYN-ACK: Server responds with SYN flag, its own ISN, and ACK of client's ISN+1
- ACK: Client acknowledges server's ISN+1; connection established
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:
- FIN: Initiator sends FIN ("I'm done sending")
- ACK: Receiver acknowledges the FIN
- FIN: Receiver sends its own FIN
- ACK: Initiator acknowledges
Connection States
TCP maintains state machines on both sides. Key states include:
- LISTEN: Server waiting for connections
- SYN_SENT: Client has sent SYN, waiting for SYN-ACK
- SYN_RECEIVED: Server received SYN, sent SYN-ACK, waiting for ACK
- ESTABLISHED: Connection open, data can flow
- FIN_WAIT_1/2: Initiator closing, waiting for FIN/ACK
- CLOSE_WAIT: Received FIN, waiting for application to close
- TIME_WAIT: Waiting 2×MSL before final close (handles delayed duplicates)
- CLOSED: No connection
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 Reliability Mechanisms
TCP provides reliable delivery over an unreliable network through several mechanisms working together: sequence numbers, acknowledgments, retransmissions, and checksums.
- •Sequence Numbers — Every byte in the stream is numbered. The sequence number in a segment indicates the first byte of that segment's data.
- •Acknowledgments — The ACK number indicates the next byte the receiver expects. It implicitly acknowledges all prior bytes.
- •Cumulative ACKs — ACK 5000 means bytes 0-4999 received. This allows a single ACK to acknowledge multiple segments.
- •Retransmission Timeout (RTO) — If an ACK isn't received within the timeout, the segment is retransmitted. RTO adapts to network conditions.
- •Selective Acknowledgment (SACK) — Extension that acknowledges non-contiguous byte ranges, enabling faster recovery from multiple losses.
- •Checksum — Covers header and data; corrupted segments are silently discarded (sender will retransmit).
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.
Flow Control and Congestion Control
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.
- •Problem: Fast sender overwhelming slow receiver
- •Mechanism: Receiver advertises window size
- •Window = 0: Sender must stop (receiver buffer full)
- •Controlled by: Receiver
- •Visibility: End-to-end only
- •Problem: Too much traffic collapsing the network
- •Mechanism: Sender maintains congestion window (cwnd)
- •Packet loss: Interpreted as congestion signal
- •Controlled by: Sender (infers network state)
- •Visibility: Network-wide impact
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.
UDP: Lightweight Datagram Service
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.
- •Connectionless — No handshake, no connection state. Just send datagrams.
- •Unreliable — No acknowledgments, no retransmissions. Datagrams may be lost, duplicated, or reordered.
- •Message-oriented — Unlike TCP's byte stream, UDP preserves message boundaries. Each send() = one datagram.
- •No flow control — Sender can transmit as fast as it wants; receiver may drop overflow.
- •No congestion control — UDP doesn't respond to network congestion. Applications must be careful.
- •Low overhead — Only 8 bytes of header vs. TCP's minimum 20.
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:
- DNS: Retries after timeout, uses TCP for large responses
- QUIC: Full reliability, ordering, and congestion control over UDP
- DTLS: TLS-like security for datagram protocols
- RTP: Sequence numbers for ordering, but no retransmission
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.
KEEP LEARNING
There’s more to understand.
You’re reading the introduction. Create a free account to read the complete lesson, save notes and keep track of your progress.