the protocol stack
Sending a letter abroad involves several specialists who each handle one job and hand off to the next: you write the note, an envelope service addresses it, the postal system routes it, an airline flies it. None of them needs to know the others' jobs in detail — they just trust the layer below to deliver. A protocol stack is that arrangement for networking: a set of protocols organized into layers, each stacked on the one beneath it.
Each layer offers a clean service to the layer above and relies on the service of the layer below, communicating only with its immediate neighbors. Your browser (application layer) hands data to the transport layer (TCP), which adds reliability and hands it to the network layer (IP), which adds addressing and hands it to the link layer (Ethernet or Wi-Fi), which puts bits on the physical medium. On the far side the same stack runs in reverse, each layer stripping off and acting on what its peer added. The real Internet runs the five-layer TCP/IP stack: application, transport, network, link, physical.
The power of stacking is modularity: you can change one layer without touching the others. Wi-Fi replaced Ethernet at the link layer and the Web never noticed; HTTP/3 swapped TCP for QUIC at the transport layer and IP routing did not change. This is why the Internet can evolve. The honest caveat is that the neat layers blur in practice — a TLS-aware load balancer or a NAT box peeks across layers — but the stack remains the organizing mental model the entire field is built on.
Loading a page runs HTTP over TCP over IP over Wi-Fi over radio — five cooperating layers, each adding its own job and trusting the one below to carry it.
Layers stacked, each serving the one above and using the one below.
The clean layers are an idealization. Real systems sometimes break layering on purpose (NAT reads transport ports; some optimizers inspect application data) — useful to know, but the stack model is still how everyone reasons about the network.