Comprehensive Study Notes on Transport Layer Protocols: TCP, UDP, and Addressing

Role and Fundamentals of the Transport Layer

The transport layer provides end-to-end communication services for applications across network infrastructures. While physical and data link layers handle the encoding and transmission of signals over physical media, the transport layer acts as the foundational glue of the Internet. It enables host applications to establish logical connections independently of the underlying network topology. Primary applications, including web browsing via Hypertext Transfer Protocol (HTTP), rely almost entirely on transport layer protocols—predominantly Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)—to manage data exchanges.

Reliable sliding window protocols, such as Selective Repeat and Go-Back-N, manage data unit reassembly and error recovery. In Selective Repeat, both the sender and receiver maintain independent sliding windows defined by sequence numbers. For example, in a five-slot sender window where four data units are transmitted and the frame with sequence number $2$ is lost in transit, the sender window remains anchored at sequence number $0$ because it has not yet received an acknowledgment for that frame. Meanwhile, the receiver accepts subsequent out-of-order frames, buffering them and moving its receive window forward. Upon timer expiration for the unacknowledged frame, the sender retransmits frame $2$. If the original frame had actually reached the receiver but its acknowledgment was lost, receiving the retransmitted frame prompts the receiver to issue a duplicate acknowledgment to notify the sender that the data was safely buffered.

To optimize network utilization, transport protocols employ piggybacking. When bi-directional data streams exist between endpoints, acknowledgment values for previously received data frames are embedded directly into outgoing data packets rather than generated as standalone control frames. A bit or a $16\text{-bit}$ field in the packet header indicates the presence of a valid acknowledgment number. Standalone acknowledgment frames are transmitted only when no reverse payload data is scheduled within a designated response time window.

Layered network architectures, such as the TCP/IP and OSI models, rely on fundamental software engineering principles. Structuring functionality into distinct, modular layers—such as the application, transport, and network layers—reduces the operational complexity of global networks. Modularity allows individual layer implementations to be updated or swapped without requiring changes to adjacent layers. Although minor abstraction leaks occasionally occur, encapsulation isolates layer operations.

Architectural design choices in the TCP/IP stack place session complexity and state management entirely within end hosts (clients and servers) rather than intermediate network routers. Intermediate routers operate on a simplified, connectionless packet-switching model, routing discrete packets independently. Consequently, network conditions may cause packet duplication, out-of-order delivery, packet loss, or packet corruption. Rather than implementing complex state synchronization across intermediate network nodes, these anomalies are accepted as deliberate design trade-offs. Handling reliability at the end hosts avoids router overhead, maximizing network throughput and efficiency. By contrast, virtual circuit switching networks negotiate dedicated paths with explicit bandwidth and capacity guarantees, but introduce significantly higher operational costs and resource constraints.

Application Addressing and Port Numbers

While IP addresses at the network layer uniquely identify individual host machines and facilitate routing across nodes, transport layer addressing relies on port numbers to direct incoming data payloads to specific software applications executing on those hosts. A combination of an IP address and a transport port number defines an explicit communication endpoint.

Port numbers operate within independent $16\text{-bit}$ integer address spaces mapped per transport protocol. Consequently, TCP port $80$ and UDP port $80$ represent entirely distinct application endpoints. Transport layer addresses are divided into well-known ports and user (or ephemeral) ports. Well-known port numbers, typically defined below $1000$ or $2000$ depending on standard assignments and operating systems, are reserved for standardized services (for example, TCP port $80$ for web servers or port $53$ for Domain Name System services). User ports, located above the well-known threshold, are dynamically allocated for user applications and ephemeral client-side connections.

Applications interface with the transport layer through operating system abstractions known as sockets. A socket serves as a software endpoint wrapping a network connection. Port numbers are bound to sockets and registered with the operating system kernel's protocol stack, enabling the kernel to demultiplex incoming network traffic to the correct application process. Socket APIs are typed by protocol; a TCP socket cannot send or receive UDP datagrams due to structural and operational differences between the protocols.

The programming semantics of modern socket APIs mirror file system calls, utilizing standard operations such as open, close, read, and write. Historically, as operating systems evolved from single-program environments to multi-user, multi-tasking systems with protected memory spaces, direct memory access between processes was restricted. Operating systems adapted file systems as inter-process communication (IPC) mechanisms. This file-oriented paradigm was subsequently extended across network boundaries to create socket abstractions, preserving familiar file read and write semantics for network communication.

User Datagram Protocol (UDP) Architecture

The User Datagram Protocol (UDP) is a minimalist, best-effort, connectionless transport protocol defined for discrete, finite-sized units of data. UDP transmits datagrams between applications without establishing a pre-existing session or maintaining connection state across interactions. It inherits the core characteristics of the underlying IP datagram delivery mechanism, meaning datagrams may be duplicated, delivered out of order, delayed, lost, or discarded without automatic protocol-level remediation.

The UDP header adds minimal overhead to the IP datagram payload, consisting of exactly $8\text{ bytes}$ ($64\text{ bits}$) divided into four $16\text{-bit}$ ($2\text{-byte}$) fields. The Source Port Number field ($16\text{ bits}$) identifies the sending application endpoint, while the Destination Port Number field ($16\text{ bits}$) specifies the target application endpoint. The Length field ($16\text{ bits}$) explicitly defines the combined byte count of the $8\text{-byte}$ UDP header plus its payload data. Finally, the Checksum field ($16\text{ bits}$) provides end-to-end integrity verification for the header and payload.

UDP operates similarly to physical mail delivery. Every outgoing UDP datagram must be explicitly tagged with the target machine's IP address and destination port number, alongside return metadata containing the client's IP address and source port number. Although the return address metadata is structurally optional, it is practically required whenever an application expects a response from the receiving endpoint.

In a standard UDP client-server architecture, the server process initializes a UDP socket, binds it to a known port number, and blocks while listening for incoming datagrams. Because UDP provides no built-in port discovery or advertising mechanisms, clients must learn port assignments through standardized well-known numbers or out-of-band communication. The client initiates communication by creating its own UDP socket and transmitting a formatted datagram directly to the server's endpoint. The server reads the return address from the incoming datagram header to dispatch any optional response.

Transmission Control Protocol (TCP) Fundamentals

The Transmission Control Protocol (TCP) provides a connection-oriented, reliable, full-duplex, byte-stream delivery service over unreliable packet-switched IP networks. Unlike UDP, TCP does not treat data as isolated datagrams with explicit application message boundaries. Instead, it processes data as a continuous, structured sequence of individual bytes. Payload bytes are collected in send buffers and formatted into variable-sized units called TCP segments for network transmission.

TCP maintains complex state information for every active session, requiring memory allocations in kernel space for send and receive buffers, dynamic variables, timers, and sequence state tracking. The socket interface acts as the boundary between user space (where application logic executes) and kernel space (where the operating system executes the network protocol stack). Sockets expose operating system control over network transmissions while shielding applications from protocol mechanics.

To manage communication quality, TCP incorporates flow control and congestion control mechanisms. Flow control prevents a fast sender from exhausting the buffer capacity of a slower receiver. Congestion control dynamically probes available network capacity between endpoints to avoid saturating intermediate network links. Because TCP maintains direct peer-to-peer connection state, it operates exclusively between two single endpoints, making it unsuited for native multicast communications.

TCP Header Mechanics and Control Flags

To support connection management, sequence tracking, and flow control, TCP utilizes a complex header structure containing multiple control fields and bit flags. The standard TCP header begins with a $16\text{-bit}$ Source Port Number and a $16\text{-bit}$ Destination Port Number to identify application endpoints.

Data sequencing is governed by a $32\text{-bit}$ Sequence Number field and a $32\text{-bit}$ Acknowledgment Number field. The Sequence Number field specifies the byte stream position of the first data byte contained within that specific segment. The Acknowledgment Number field indicates the next sequential byte number that the sender of the segment expects to receive from the remote host. The Acknowledgment Number field is considered valid only when the ACK control bit is explicitly set to $1$.

TCP operational behavior is controlled via specific header bit flags. The SYN (Synchronize) bit initiates connection setup and synchronizes initial sequence numbers (ISNs) between endpoints during handshaking. The ACK (Acknowledgment) bit indicates that the acknowledgment number field contains valid data. The FIN (Finish) bit requests graceful termination of an established connection direction. The RST (Reset) bit forcefully resets or rejects an invalid connection attempt.

The PSH (Push) bit forces the operating system protocol stack to flush buffered segment data directly to the receiving application without waiting for buffers to fill. Because wrapping a single interactive byte (such as a remote terminal keypress) in full transport, network, and data link headers introduces high overhead relative to payload size, protocol stacks default to buffering small data amounts. The PSH flag overrides this optimization when immediate delivery is required. The URG (Urgent) bit flags payload data that requires prioritized processing.

Connection Establishment and Termination Procedures

TCP establishes connections using a reliable three-way handshake designed to prevent stale or duplicated connection requests—caused by network delays and intermediate router buffering—from creating ghost sessions at the receiver.

Connection setup begins with an active open initiated by the client. The client transmits a segment with the SYN bit set and a randomly selected Initial Sequence Number $x$. Selecting sequence numbers randomly, rather than starting predictably at $0$, isolates new sessions from delayed duplicate packets belonging to previous closed connections. In step two (passive open), the server responds with a segment having both its SYN and ACK bits set (a SYN-ACK segment). The server chooses its own Initial Sequence Number $y$ and sets the acknowledgment field to $x + 1$, signaling that it received sequence $x$ and expects sequence $x + 1$ next. In step three, the client completes the handshake by returning an ACK segment with sequence number $x + 1$ and acknowledgment number $y + 1$. To maximize network efficiency, the client can piggyback initial application payload data directly inside this third handshake segment.

If a delayed duplicate SYN segment with sequence number $x$ arrives at the server from an old, aborted connection, the server issues a SYN-ACK segment containing sequence number $y$ and acknowledging $x + 1$. When the client receives this SYN-ACK, it recognizes that it has no matching active connection request pending for that sequence space, prompting it to reject or reset the invalid connection attempt. Similarly, if a delayed duplicate payload packet arrives during handshake negotiation, sequence number validation (such as detecting an unexpected sequence $z$ instead of $y$) forces immediate rejection by both hosts.

TCP connection termination operates as an independent, four-step handshake supporting half-close operations, where each direction of the full-duplex stream closes separately. An active close is initiated when an endpoint transmits a segment with its FIN bit set at sequence number $x$. The receiving host acknowledges this FIN by returning an ACK segment set to $x + 1$. At this point, the connection is half-closed: the initiating host can no longer send data, but the receiving host may continue transmitting buffered data. Once the second host finishes its data transmission, it sends its own FIN segment at sequence number $y$. The original host responds with an ACK set to $y + 1$. Upon completion of this four-step exchange, both operating system kernels safely deallocate session memory, control blocks, buffers, and active timers. Operating system timers also act as fallbacks to reclaim resources if an ungraceful disconnect prevents normal four-step termination.