Expanded university-level treatment – COMP347 (TrustOpen University)
After completing this tutorial, you should be able to:
The transport layer is the critical bridge between application processes and the network infrastructure. It transforms the network layer’s host‑to‑host packet delivery (unreliable, best‑effort IP) into process‑to‑process logical communication, with a service model tailored to the application’s requirements. This tutorial establishes the foundational concepts: the layered architecture, the socket abstraction, the distinction between connection‑oriented and connectionless services, and the key mechanisms that enable reliable, efficient data transfer. We also introduce the end‑to‑end principle and the historical evolution that led to today’s transport protocols.
The Internet protocol suite (TCP/IP) is structured as a layered architecture. The transport layer sits directly above the network layer (IP) and below the application layer. Its primary responsibility is to provide logical communication between application processes—not merely between hosts. This abstraction is realised through sockets, which serve as the programming interface for sending and receiving data.
+-------------------------------+
| Application Layer | (HTTP, DNS, SMTP, etc.)
+-------------------------------+
| Transport Layer | ← logical process‑to‑process communication
| (TCP / UDP / SCTP) |
+-------------------------------+
| Network Layer (IP) | ← logical host‑to‑host communication
+-------------------------------+
| Link Layer |
+-------------------------------+
| Physical Layer |
+-------------------------------+
The transport layer relies on IP’s best‑effort delivery and adds services such as multiplexing, reliability, and flow/congestion control.
In the early ARPANET, the Network Control Program (NCP) provided a rudimentary host‑to‑host connection, but it lacked robust error recovery and flow control. The development of TCP in the 1970s (Vint Cerf and Bob Kahn) introduced the notion of a separate transport layer that could adapt to different network technologies. The subsequent split into TCP (reliable, connection‑oriented) and UDP (simple, datagram‑oriented) in the 1980s reflected a design decision to support both reliable bulk data transfer (e.g., FTP) and lightweight real‑time applications (e.g., DNS). This duality remains a cornerstone of Internet architecture.
Multiplexing at the sender: the transport layer collects data from multiple application sockets, encapsulates each with a header (containing source and destination port numbers), and passes the resulting segments to the network layer. Demultiplexing at the receiver: the transport layer examines the port fields to deliver each segment’s payload to the correct socket. This enables a single host to run many network applications simultaneously.
The demultiplexing granularity differs between UDP (destination port only) and TCP (full 4‑tuple: source IP, source port, destination IP, destination port). This has profound implications for connection management, as we will explore in subsequent tutorials.
Reliability is not a given—IP may drop, corrupt, or reorder packets. A reliable transport protocol must detect and recover from these errors. Key mechanisms include:
TCP implements these in a sophisticated sliding‑window protocol; UDP provides none of these, leaving reliability to the application.
Flow control is a sender‑receiver pacing mechanism that prevents a fast sender from overwhelming a slow receiver’s buffer. In TCP, the receiver advertises a window (rwnd) in each ACK, indicating the amount of free buffer space. The sender limits the number of unacknowledged bytes to this window. This is distinct from congestion control, which addresses network‑level overload.
Congestion occurs when traffic load exceeds network capacity, leading to queue buildup and packet loss. TCP implements end‑to‑end congestion control using the congestion window (cwnd) and algorithms like slow start, congestion avoidance, and fast recovery. These mechanisms dynamically adapt the sending rate to available bandwidth, ensuring stability and fairness across competing flows. UDP does not perform congestion control, which can lead to unfairness but is necessary for latency‑sensitive applications.
Both TCP and UDP include a 16‑bit checksum that covers the segment header, data, and a pseudo‑header (source/destination IP, protocol number, and segment length). The checksum is computed using the 1’s complement sum of all 16‑bit words. This detects most bit errors, though it is not as strong as a cryptographic hash. In IPv6, the UDP checksum is mandatory; in IPv4 it is optional but strongly recommended.
A socket is the endpoint of a communication channel. In operating systems, a socket is a file descriptor that applications use to read from and write to the network. The transport layer maintains a mapping from sockets to port numbers. Two common socket types are:
SOCK_STREAM – provides a reliable, bidirectional, connection‑oriented byte stream (TCP).SOCK_DGRAM – provides a connectionless, unreliable, datagram‑oriented service (UDP).Ports are 16‑bit unsigned integers (0–65535), divided into three ranges by IANA:
| Range | Name | Description |
|---|---|---|
| 0 – 1023 | Well‑known ports | Assigned to system services (e.g., SSH/22, HTTP/80, HTTPS/443). Requires root/admin privileges to bind. |
| 1024 – 49151 | Registered ports | User‑level services (e.g., MySQL/3306, many gaming servers). |
| 49152 – 65535 | Dynamic / ephemeral ports | Temporarily assigned by the OS to client processes for outgoing connections. |
The tuple (source IP, source port, destination IP, destination port) uniquely identifies a TCP connection. For UDP, the socket is often identified by (destination IP, destination port) for demultiplexing, but the source information is used to send responses.
The network layer (IP) provides a best‑effort, connectionless packet delivery service. It does not guarantee:
Thus, any transport protocol that requires reliability, ordering, or rate control must implement these on top of IP. This separation of concerns is a classic example of the end‑to‑end argument: functions that can be correctly and completely implemented only at the application endpoints should be placed there, not in the network core. TCP’s reliability is such a function; placing it in the network layer would be inefficient and unnecessary.
IP fragments large packets at the link layer (MTU). However, fragmentation is costly and can increase loss probability. TCP avoids IP fragmentation by selecting a Maximum Segment Size (MSS) such that the TCP segment (plus IP and TCP headers) fits within the path MTU. UDP does not segment its datagrams; if a UDP datagram exceeds the MTU, it may be fragmented at the IP layer, which can cause performance issues.
| Service Aspect | TCP (Connection‑Oriented) | UDP (Connectionless) |
|---|---|---|
| Connection setup | Three‑way handshake (1 RTT overhead) | No setup (0 RTT) |
| State at endpoints | Full connection state (send/receive buffers, timers, sequence numbers) | Minimal state (only port mapping) |
| Reliability | Yes (ACKs, timeouts, retransmissions) | No |
| Ordering | Guaranteed byte‑stream order | No (datagrams may arrive out of order) |
| Flow control | Yes (advertised window) | No |
| Congestion control | Yes (cwnd, AIMD) | No |
| Header overhead | 20 bytes (without options) | 8 bytes |
| Data boundary | Byte‑stream (no message boundaries) | Datagram (preserves message boundaries) |
| Applications | Web (HTTP), email (SMTP), file transfer (FTP) | DNS, VoIP, streaming, gaming, QUIC |
TCP’s additional features come at a cost: more processing (checksums, timers, congestion control), larger headers, and higher memory requirements for connection state. For short‑lived transactions, the handshake overhead (1 RTT) can be significant. UDP’s simplicity allows lower latency and higher packet rates, but it pushes reliability and congestion management to the application, which may be complex to implement correctly.
The end‑to‑end principle (Saltzer, Reed, Clark 1981) argues that certain functions, such as error recovery and security, are best implemented at the endpoints rather than inside the network. TCP’s reliability is a prime example: it would be wasteful to implement reliable delivery inside routers, as the endpoints already have the necessary information and can adapt to application needs. This principle also underlies the design of QUIC, which moves reliability and encryption into the application space (over UDP).
Modern NICs (network interface cards) support TCP segmentation offload (TSO), checksum offload, and receive side scaling (RSS) to reduce CPU overhead. These hardware features allow the OS to hand large chunks of data to the NIC, which performs segmentation and checksumming in hardware, improving throughput and reducing latency. This offloading is transparent to the transport protocol but affects system‑level performance tuning.
Transport protocols influence QoS. TCP’s congestion control provides network‑friendly behaviour, but its variable throughput can be problematic for real‑time media. UDP offers low jitter but can be throttled by network policies (e.g., policing, shaping). DiffServ and IntServ frameworks operate at the network layer; transport protocols must interact with these to achieve end‑to‑end QoS.
Answer the following questions to check your understanding. All answers are hidden below — click to reveal.
Apply your knowledge to practical scenarios. Solutions are provided below each exercise.
These questions encourage deeper exploration and synthesis. Sample answers are provided below.
This tutorial established the foundational principles of the transport layer:
In the next tutorial we will dive deep into multiplexing, demultiplexing, and socket‑based communication, exploring how UDP and TCP handle demultiplexing differently and how sockets are managed in practice.
COMP347 – Computer Networks (Rev. 10) · TrustOpen University · Based on Kurose & Ross, Computer Networking: A Top‑Down Approach, 9th ed. (2025).