The Internet and the TCP/IP stack

In part 02 a browser controlled a lamp with HTTP requests: PUT /lamp/state to switch it and GET /lamp/energy to read its energy. Each request started on a laptop on KFUPM Wi-Fi and had to reach a server that might sit in a data center on another continent. Neither program knew the path in between, and neither needed to. That is the whole point of the TCP/IP stack.

Every host runs the same set of layers, so a client and a server can exchange bytes as if a private pipe joined them. The stack has a single purpose: connectivity. A program should only have to say who it wants to talk to and what it wants to send. Everything else in this part (layers, PDUs, addresses, sockets) is simply how that one job gets done.

Why split connectivity into layers

Hiding the path is a large job, far too large for one piece of software. Think about an air journey. You buy a ticket, check a bag, pass a gate, the plane takes off from a runway and air traffic control routes it. Each step relies on the step below it and offers a service to the step above. Kurose and Ross use exactly this example to motivate network layering.

The Internet divides connectivity the same way. The stack has five layers, and each layer provides one well-defined service using its own protocols. The payoff is explicit structure and modularity: a layer can change how it works internally without the rest of the system noticing. Wi-Fi can be swapped for 5G, and HTTP does not change a single byte.

Read the plus signs as composition, not arithmetic. No single layer delivers a web page. Connectivity emerges only when all five cooperate, the same way no single airport worker delivers you to another city.

Five layers versus seven

Part 02 used OSI as its example of a layered system, so it is worth lining the two models up. The OSI reference model (ITU-T X.200) defines seven layers. The Internet stack has no separate session or presentation layer. RFC 1122 says the Internet application layer essentially combines OSI presentation and application, and Kurose and Ross note that any such services must be implemented by the application itself.

The stack as the band between people and the physical world

Now zoom out to a whole system. Picture a distance sensor such as the HC-SR04 wired to a Raspberry Pi Pico. The Pico reads a distance, a Wi-Fi-capable board sends it across the network, and a dashboard in a control room shows it to a person. A command can travel the other way, down to an actuator.

The five layers form a band in the middle of that picture. Users sit above it and the physical world of sensing and actuation sits below it. The dashboard does not need to know how bits cross the air, and the device does not need to know how the dashboard draws its charts. This is modularity again, now at the scale of an entire system.

This is the same shape as the lamp system from part 02, and it is also the shape of your research project. In parts 08 to 10 the same pipeline is stretched across the edge to cloud continuum, and the question becomes where along it each piece of processing should run.

Layers cooperate by handing data to each other, and the way they do it is the single most useful mechanism in this part. Take a simple read request, GET /lamp HTTP/1.1. The application layer hands it down as a message. Transport puts a TCP header in front and it becomes a segment. Network adds an IP header and it becomes a packet. Data link adds a MAC header in front and a frame check sequence (a CRC) trailer behind, making a frame. Physical sends that frame as bits.

Each layer's unit of data is its protocol data unit (PDU). The process of wrapping is encapsulation, and it follows one rule: a PDU is this layer's header plus a payload, and the payload is the entire PDU of the layer above. On the receiving host the steps run in reverse. Each layer reads and removes its own header, then passes the payload up. Step through it yourself before reading on.

Who reads which header

Encapsulation is also what lets the middle of the network stay simple. Kurose and Ross label the headers Ht (transport), Hn (network) and Hl (link). A switch processes only the link and physical layers. A router processes network, link and physical. Only the two end hosts open the transport header and the application message. The IP header even carries a Protocol field that names the next-level protocol in its data (RFC 791, section 3.1), which is how the receiver knows whether to hand the payload to TCP or UDP.

These sizes come from RFC 791, RFC 9293 and RFC 768, and together they are the 40 bytes of layering overhead mentioned earlier. They also reveal a division of labor: IP has no acknowledgments, no retransmissions and no flow control (RFC 791, section 1.4). Reliability is added one layer up, by TCP, and only at the end hosts.

The header table ended with an address column, and that column is not decoration. Each header names something different because each layer connects something different. Your laptop on campus loads a page from a cloud server. The path goes over one Wi-Fi hop to the access point, through several routers, and finally over a data-center link to the server. Along that path there is one conversation between two programs, one route between two machines, and many separate links.

These are the three connection scopes. The transport layer provides an end-to-end (E2E) connection between two application processes. The network layer provides a host-to-host (H2H) path between two machines, however many routers lie between them. The data link layer handles point-to-point (P2P) transfer across a single hop between two directly attached interfaces.

The rule to take away: the higher the layer, the wider its scope and the more virtual its connection. Only the P2P links are real cables or radio channels. The E2E connection is not a wire at all. It is state held in the two end hosts: RFC 9293 (section 3.3.1) describes the TCP control block that stores the local and remote IP addresses and ports. TCP creates that state with the three-way handshake (section 3.5), while IP itself is connectionless. UDP keeps no connection state at all, yet its datagrams are still delivered process to process.

One address per scope

If each scope connects a different kind of thing, each needs its own way to name that thing. Look back at the encapsulation stepper. The server is 3.120.0.10, the service on it is port 443, and the next hop's interface is f4:8c:50:2b:e1:04. Three addresses, one per scope.

E2E names a process with a port number. H2H names a machine with an IP address. P2P names a network interface on the local link with a MAC address. (The course materials write "Mac"; the standard spelling is MAC, for Media Access Control.)

Ports are 16-bit fields in both TCP (RFC 9293) and UDP (RFC 768). IPv4 addresses are a fixed four octets (RFC 791, section 2.3). MAC addresses are 48 bits, burned into the NIC but sometimes settable in software, written like 1A-2F-BB-76-09-AD.

What changes at each hop

Putting scopes and addresses together gives the most useful insight of this concept. Along the whole path, ignoring NAT, the source and destination IP addresses and ports stay the same, because their scopes span the whole path. The MAC addresses are replaced at every hop, because their scope is one link: each router strips the old frame and builds a new one for the next link. To build it, the router uses ARP (RFC 826) to map the next hop's IP address to its 48-bit Ethernet address.

Addresses name endpoints, but a conversation needs more than one name. Open two browser tabs to the same server. Both tabs run on one laptop with one IP address, and both talk to one server port. Yet every reply lands in the right tab. Something must tell the two conversations apart.

The general rule builds up in three steps. A socket is one endpoint, an IP address plus a port number. A connection is a pair of sockets, one at each end, which is exactly how RFC 9293 defines it. When networks need to tell flows apart, they add the protocol and use the 5-tuple, which RFC 6437 (section 3) lists as destination address, source address, protocol, destination port and source port. The protocol field is what separates a TCP flow from a UDP flow that happens to share the same addresses and ports.

Notice how this ties back to the scopes. The 5-tuple uses only the E2E and H2H addresses, the ones that survive the whole path. The MAC address plays no part in identifying a connection, because it covers only one hop and would change before the reply ever came back.

So far the layers have been abstractions. The last step is to find them inside a real computer. A Node.js server asks the operating system for a socket and gets back a file descriptor. It writes bytes to that descriptor. Inside the kernel, TCP and IP headers are added. A driver hands the finished frame to the network card, which turns it into electrical or radio signals.

That story maps the layers onto three parts of one machine. The application layer lives in application space: the browser or server process, including its HTTP library. The transport layer and network layer live in the operating system kernel. The data link layer and physical layer live in the network interface and its driver.

Two seams separate these spaces. The socket API is the door between application and OS, which is why the socket of the previous concept is also a programming object. The Linux socket(7) manual calls sockets the uniform interface between the user process and the network protocol stacks in the kernel. Drivers are the door between OS and hardware. For the Web, the concrete stack reads: browser or server, HTTP, socket API, TCP, IP, Ethernet, then wired or wireless media.

The seams are also boundaries of privilege. An application cannot forge TCP state directly; it has to go through the socket API. This matters later in the course. Latency is added at every crossing, and virtual machines and containers in lecture 2 virtualize exactly these seams.