Transport Layer

Role of the Transport Layer

The Transport Layer (Layer 4) sits between the Application Layer and the Network Layer. Its job is to manage the actual transport of data between applications running on source and destination hosts — not just between devices, but between specific processes running on those devices.

The Transport Layer offers two very different protocols, and choosing between them is one of the most important design decisions an application makes:

TCP Overview

TCP (Transmission Control Protocol) is a connection-oriented protocol that guarantees reliable, ordered, and error-checked delivery. It is used whenever data integrity matters more than speed — web browsing, email, file transfer.

Key TCP header fields:
Source Port        16 bits — identifies sending application
Destination Port   16 bits — identifies receiving application
Sequence Number    32 bits — tracks byte order for reassembly
Acknowledgment Number 32 bits — next byte the receiver expects
Window Size        16 bits — how much data the receiver can accept
Flags              SYN, ACK, FIN, RST, PSH, URG — control the connection
Checksum           16 bits — error detection

Applications that rely on TCP include HTTP/HTTPS (web), SMTP/IMAP/POP3 (email), and FTP (file transfer) — anywhere a missing or corrupted byte would break the result.

UDP Overview

UDP (User Datagram Protocol) is connectionless and provides no reliability, ordering, or flow control. It simply sends datagrams and moves on — making it far faster and lower-overhead than TCP, at the cost of any delivery guarantee.

UDP header — only 4 fields, 8 bytes total:
Source Port        16 bits
Destination Port   16 bits
Length             16 bits — size of header + data
Checksum           16 bits — error detection only, no recovery

UDP is the right choice when speed matters more than perfection — DNS lookups, DHCP, streaming video/audio, and VoIP all use UDP. A dropped video frame or a missed voice packet is far less disruptive than the delay TCP's retransmission would introduce.

Port Numbers

Port numbers let a single IP address support many simultaneous conversations. Combined with the IP address, a port number forms a socket — and a pair of sockets (source + destination) forms a socket pair, which uniquely identifies one specific conversation.

Socket = IP address : Port number
192.168.1.10:51422   (client socket — random high port)
93.184.216.34:443    (server socket — well-known HTTPS port)

Socket Pair = source socket + destination socket — uniquely identifies ONE conversation
192.168.1.10:51422 ↔ 93.184.216.34:443

Port numbers are divided into three ranges:

C:\> netstat -n
Proto  Local Address          Foreign Address        State
TCP    192.168.1.10:51422    93.184.216.34:443     ESTABLISHED
TCP    192.168.1.10:51500    142.250.80.46:443     ESTABLISHED

TCP Communication Process

Before any data flows, TCP establishes a session with the three-way handshake — a synchronized exchange that confirms both sides are ready and agrees on starting sequence numbers.

Session termination uses a similar but distinct exchange — each side sends a FIN to signal it's done sending, and the other acknowledges it. Because each direction is closed independently, a full graceful close takes four messages (FIN/ACK from each side).

Reliability and Flow Control

TCP's reliability comes from sequence numbers and acknowledgments. Every byte sent is numbered; the receiver acknowledges the next byte it expects, letting the sender know exactly what arrived and what needs to be resent.

Sender transmits 3 segments:
Segment 1: seq=1000, 500 bytes  →  received, ACK=1500 sent
Segment 2: seq=1500, 500 bytes  →  LOST in transit
Segment 3: seq=2000, 500 bytes  →  received, but ACK=1500 sent again (duplicate)

Sender sees duplicate ACK=1500 → knows Segment 2 was lost
Sender retransmits Segment 2 (seq=1500)
Receiver now has 1000-2500 contiguous → sends ACK=2500

Flow control prevents a fast sender from overwhelming a slow receiver. The receiver advertises a window size — the amount of data it can accept before needing an acknowledgment — and the sender respects that limit, adjusting dynamically as conditions change.

UDP Communication

Because UDP has no concept of a session, the server process must be ready to listen continuously, and the client simply sends a datagram whenever it has data — no setup, no teardown. There is no window size, no sequence numbers, no retransmission.

! Client sends a single DNS query datagram — no handshake
Client (192.168.1.10:52000)  →  DNS query for "example.com"  →  Server (8.8.8.8:53)

! Server responds with a single datagram — also no handshake
Server (8.8.8.8:53)  →  DNS answer: 93.184.216.34  →  Client (192.168.1.10:52000)

! If the query or response is lost, the application (not UDP) decides whether to retry

UDP datagrams that arrive out of order are simply delivered in the order they arrive — reassembly into the correct sequence, if it matters at all, is left entirely to the application. This is why streaming applications often build their own light reordering buffer on top of UDP rather than relying on TCP's heavier mechanism.

The Right Protocol for the Right Application

Every application developer makes a deliberate choice between TCP and UDP based on what the application actually needs.