OSI Model - Overview

The network layer delivers packets to the correct host—but a host runs many applications simultaneously. Your computer might be running a web browser, an email client, a music streaming app, and a dozen background services, all using the network at the same time. How does an incoming packet reach the right application?

This is the domain of the Transport Layer (Layer 4)—the bridge between network-level addressing and application-level communication. While IP addresses identify hosts, port numbers identify specific applications or services. The transport layer provides process-to-process (or socket-to-socket) communication, ensuring data reaches not just the correct machine, but the correct running program.

Beyond addressing, the transport layer makes crucial decisions about how data is delivered. Should it guarantee delivery, or sacrifice reliability for speed? Should it preserve message boundaries, or treat data as a stream? The answers to these questions determine which transport protocol to use—predominantly TCP for reliability or UDP for lightweight communication.

The transport layer sits between the application layer (where your programs live) and the network layer (which routes packets). Its fundamental responsibility is enabling communication between processes on different hosts.

Core Functions:

1. Process Multiplexing/Demultiplexing:

• Multiplexing (sender): Collects data from multiple application sockets, encapsulates with headers, passes to network layer
• Demultiplexing (receiver): Examines port numbers, directs incoming segments to the correct application socket

2. Segmentation and Reassembly:

• Breaks application data into segments appropriate for network transmission
• Reassembles segments into the original data stream at the destination

3. Connection Management (TCP):

• Establishes connections before data transfer (three-way handshake)
• Maintains connection state during communication
• Terminates connections cleanly when done

4. Reliable Delivery (TCP):

• Sequence numbers track data order
• Acknowledgments confirm receipt
• Retransmissions handle lost segments
• Checksums detect corruption

5. Flow Control (TCP):

• Prevents sender from overwhelming receiver
• Receiver advertises available buffer space (window)

6. Congestion Control (TCP):

• Prevents sender from overwhelming the network
• Detects and responds to network congestion

Port numbers are 16-bit unsigned integers (0-65535) that identify specific applications or services on a host. Combined with an IP address, a port creates a socket address—a unique endpoint for network communication.

Port Number Ranges:

Common Well-Known Ports:

Sockets: The Programming Interface

A socket is an endpoint for network communication, identified by:

• IP Address + Port Number (for single host)
• (Protocol, Local IP, Local Port, Remote IP, Remote Port) for a connection

Connection Identification (TCP):

A TCP connection is uniquely identified by a 4-tuple:

• Source IP Address
• Source Port
• Destination IP Address
• Destination Port

This allows a single server on port 80 to simultaneously handle thousands of clients—each connection has a unique combination of client IP and client port.

Example:

Web server listening on 192.168.1.100:80 serves three clients:

• Client 1: 10.0.0.5:52341 ↔ 192.168.1.100:80
• Client 2: 10.0.0.6:49872 ↔ 192.168.1.100:80
• Client 3: 10.0.0.5:52342 ↔ 192.168.1.100:80 (same client, different source port)

User Datagram Protocol (UDP) is the simpler of the two primary transport protocols. It provides minimal services: just multiplexing and optional error detection. No connections, no reliability, no ordering, no flow control.

UDP Header Structure:

That's it. 8 bytes of header, no connection state, no acknowledgments.

UDP Characteristics:

• Connectionless: No handshake required; send whenever ready
• No reliability: Lost packets are simply lost
• No ordering: Packets may arrive in any order
• No congestion control: Will keep sending at application rate regardless of network state
• Message-oriented: Preserves application message boundaries (each send() = one datagram)

UDP Use Cases in Detail:

DNS (Port 53): DNS uses UDP for queries because:

• Queries are small (fit in one datagram)
• Speed is critical (cached results expire)
• TCP overhead is excessive for single Q&A
• Application handles retry if no response

(Note: DNS uses TCP for zone transfers and large responses that exceed 512 bytes)

VoIP and Video: Real-time media tolerates some packet loss but cannot tolerate retransmission delay. A dropped packet in a voice call creates a brief gap; a retransmitted packet arrives too late to be useful. UDP's low latency is essential.

Gaming: Game state updates must be timely. Receiving old enemy positions is useless and potentially misleading. Games often implement their own reliability only for data that truly requires it (e.g., chat messages).

Transmission Control Protocol (TCP) is the workhorse of the Internet. It provides reliable, ordered, error-checked delivery of a stream of bytes. When you load a web page, send an email, or download a file, TCP ensures the data arrives correctly.

TCP Header Structure:

Minimum header: 20 bytes (no options) Maximum header: 60 bytes (with options)

TCP Key Concepts:

Byte Stream Abstraction: TCP provides a reliable byte stream—not messages or records. The application sends bytes, TCP delivers them in order. If the application needs message boundaries, it must implement them (e.g., HTTP uses Content-Length or chunked encoding).

Full-Duplex Communication: TCP connections are bidirectional—both sides can send and receive simultaneously. Each direction has its own sequence numbers and flow control.

Connection-Oriented: Before data transfer, a connection must be established (three-way handshake). After transfer, connection is terminated (four-way handshake or RST). TCP maintains state throughout the connection lifetime.

TCP connections have a lifecycle: establishment, data transfer, and termination. Understanding this lifecycle is essential for troubleshooting and security analysis.

Connection Establishment: The Three-Way Handshake

Before exchanging data, TCP endpoints synchronize their initial sequence numbers (ISNs):

Step 1: SYN (Client → Server)

• Client sends segment with SYN flag set
• Contains client's initial sequence number (ISN_c)
• "I want to connect; my starting sequence number is X"

Step 2: SYN-ACK (Server → Client)

• Server responds with SYN and ACK flags set
• Contains server's initial sequence number (ISN_s)
• Acknowledges client's sequence number (ACK = ISN_c + 1)
• "Connection accepted; my starting sequence number is Y; I'm expecting X+1 next"

Step 3: ACK (Client → Server)

• Client acknowledges server's sequence number (ACK = ISN_s + 1)
• Connection is ESTABLISHED on both sides
• May include data in this segment
• "Got it; let's exchange data"

Connection Termination: The Four-Way Handshake

Each direction of a TCP connection is closed independently:

1. FIN (Initiator → Peer): "I'm done sending data"
2. ACK (Peer → Initiator): "Acknowledged; I may still send data"
3. FIN (Peer → Initiator): "I'm also done sending"
4. ACK (Initiator → Peer): "Acknowledged; connection closed"

TIME_WAIT State:

After sending the final ACK, the initiator enters TIME_WAIT state for 2×MSL (Maximum Segment Lifetime, typically 2 minutes). This ensures:

• The final ACK reaches the peer (can retransmit if needed)
• Delayed segments from the closed connection don't affect new connections on the same ports

Abrupt Termination (RST):

An RST flag immediately terminates the connection without handshakes. Used when:

• Connection attempt to closed port
• Invalid segment received
• Application requests immediate close
• Firewall resets unauthorized connections

TCP's reliability mechanisms ensure data arrives correctly and in order, despite the unreliable IP network beneath.

Sequence Numbers:

Every byte in a TCP stream has a sequence number. The sequence number in a segment header indicates the first byte's position in the stream:

• ISN (Initial Sequence Number) is randomly chosen during handshake
• Each data byte increments the sequence by 1
• Sequence numbers wrap around (32 bits = ~4 billion bytes)

Example: If a segment has Seq=1000 and carries 500 bytes, the next segment should have Seq=1500.

Acknowledgments (ACKs):

TCP uses cumulative acknowledgments. The ACK number indicates the next expected byte:

• ACK=1500 means "I've received all bytes up to 1499; send me 1500 next"
• ACKs are carried in segments with the ACK flag set
• ACKs can be piggybacked on data segments (bidirectional flow)

Duplicate ACKs: If a receiver gets an out-of-order segment (gaps in sequence), it responds with a duplicate ACK for the last in-order byte. Three duplicate ACKs trigger fast retransmit.

Retransmission Mechanisms:

1. Timeout-Based Retransmission:

• Each segment has a retransmission timer
• If ACK not received before timeout, retransmit
• Timeout value (RTO) adapts based on measured RTT
• Too short: Unnecessary retransmissions (wastes bandwidth)
• Too long: Slow recovery from loss

2. Fast Retransmit:

• Three duplicate ACKs indicate a gap (likely loss)
• Retransmit immediately without waiting for timeout
• Much faster recovery than timeout alone

3. Selective Acknowledgment (SACK):

• Receiver reports non-contiguous blocks received
• Sender knows exactly what's missing
• Retransmit only what's actually lost
• Avoids retransmitting segments already received

Flow control ensures a fast sender doesn't overwhelm a slow receiver. If the sender transmits faster than the receiver can process, the receiver's buffer fills up, new segments are dropped, and retransmissions waste bandwidth.

The Receive Window (rwnd):

The receiver advertises how much buffer space is available in the Window Size field of every ACK. This is called the receive window (rwnd).

• "I can accept up to rwnd bytes beyond what I've acknowledged"
• Sender limits unacknowledged data ("bytes in flight") to rwnd
• As receiver processes data, it advertises larger rwnd
• If receiver is overwhelmed, rwnd decreases (possibly to 0)

Sliding Window Mechanism:

The sender maintains a "window" of bytes that can be sent:

• Left edge: Last acknowledged byte
• Right edge: Last acknowledged byte + min(rwnd, cwnd)
• Sender can only send bytes within this window
• As ACKs arrive, window "slides" right
• New bytes become available for transmission

Zero Window and Window Probes:

If the receiver is completely overwhelmed, it advertises rwnd=0:

• Sender must stop sending new data
• Sender periodically sends window probes (1-byte segments)
• Probes elicit ACKs that might carry a non-zero window
• Prevents deadlock if the window-opening ACK is lost

Example Scenario:

1. Sender has 10KB to send; Receiver advertises rwnd=4KB
2. Sender sends 4KB, stops (window full)
3. Receiver processes 2KB, ACKs with rwnd=2KB
4. Sender sends 2KB more (window full again)
5. Receiver's application is slow; processes 0 bytes, ACKs with rwnd=0
6. Sender stops, starts window probes
7. Eventually, receiver processes data, advertises rwnd=4KB
8. Sender resumes

Window Scaling (RFC 7323):

The 16-bit window field limits rwnd to 65535 bytes—insufficient for modern high-bandwidth connections. Window scaling (negotiated in SYN) multiplies the window by 2^scale, enabling windows up to ~1GB.

While flow control prevents receiver overload, congestion control prevents network overload. When routers are overwhelmed, they drop packets. If all senders respond to drops by retransmitting aggressively, the network collapses (congestion collapse).

The Congestion Window (cwnd):

In addition to rwnd, the sender maintains a congestion window (cwnd)—an estimate of how many bytes the network can handle. The actual sending rate is limited to min(rwnd, cwnd).

TCP Congestion Control Phases:

1. Slow Start:

• Begin with cwnd = 1 MSS (or small initial value)
• For each ACK received, increase cwnd by 1 MSS
• Effect: cwnd doubles each RTT (exponential growth)
• Continue until cwnd reaches slow start threshold (ssthresh) or loss occurs

2. Congestion Avoidance:

• When cwnd ≥ ssthresh, switch to additive increase
• For each RTT, increase cwnd by ~1 MSS (linear growth)
• Probe for available bandwidth cautiously
• Continue until loss occurs

3. Loss Recovery (on timeout):

• Set ssthresh = cwnd / 2
• Set cwnd = 1 MSS
• Return to slow start

4. Fast Recovery (on 3 duplicate ACKs):

• Set ssthresh = cwnd / 2
• Set cwnd = ssthresh (don't drop to 1)
• Skip slow start; resume congestion avoidance

AIMD (Additive Increase, Multiplicative Decrease):

TCP's congestion control follows AIMD:

• Additive Increase: Slowly increase cwnd when things are going well (linear growth in congestion avoidance)
• Multiplicative Decrease: Rapidly cut cwnd when congestion is detected (halve on loss)

This creates a "sawtooth" pattern: cwnd grows linearly, drops sharply on loss, grows again. AIMD provably converges to fair, efficient bandwidth sharing among competing flows.

Modern Congestion Control Algorithms:

Modern operating systems typically default to CUBIC (Linux, Windows 10+) or compound TCP (older Windows).

The transport layer is where the end-to-end principle is realized, providing process-to-process communication with varying levels of service. Let's consolidate the essential concepts:

Module Complete:

We've now explored all layers covered in this OSI Model Overview module—from the physical transmission of bits through the reliable delivery of application data. The OSI model provides the conceptual framework; these layers provide the implementation reality.

In subsequent modules, we'll examine the upper layers (Session, Presentation, Application) and compare the OSI model with the TCP/IP model that actually runs the Internet.