Why networks are built in layers

A request is not one job, it is four

You type a URL, press Enter, a page appears. From where you sit that is one action. Underneath, four unrelated problems had to be solved at the same time. Someone had to decide what the word GET means and what a reply looks like. Someone had to guarantee the bytes arrive complete and in the order they were sent. Someone had to find a route across the planet through routers nobody in this story controls. And someone had to turn ones and zeros into voltage on copper, light in glass, or radio in the air.

A layer is one of those problems, solved once, behind a fixed interface. Sending data across a network is genuinely hard — collision avoidance, error detection, routing, retransmission, encoding — and no single program could carry all of it and stay comprehensible. So the work is cut into layers, each one an abstraction between the physical hardware and the meaning of the data.

Each layer talks only to its neighbours

This course uses the TCP/IP four-layer model: application, transport, internet, host-to-network, from meaning down to metal. The rule that makes the model useful is the restriction: a layer talks only to the layer directly above it and the layer directly below it. Your browser talks to the transport layer. The transport layer talks to the application layer and to the internet layer, never to the wire. The internet layer talks to the transport layer and to the host-to-network layer, never to your browser.

What layering buys: substitutability

Because the interfaces are fixed, you can replace the software inside one layer without touching the others. Move a laptop from Ethernet to Wi-Fi to a phone hotspot and the host-to-network layer changes completely — different framing, different modulation, different hardware — while the browser above it does not change by one line. That is not a happy accident; it is the whole return on the design. The cost is symmetrical: each layer knows only its own job, so the transport layer cannot tell you why a route disappeared.

One more consequence. To the application layer it looks as though it is speaking directly to the application on the other machine — a logical path the lower layers maintain as a fiction. In reality your request goes down your stack, across, and up theirs.

Where Java actually lives

Java's networking classes only understand TCP/IP networks, and they only reach two layers. Roughly 90% of your code sits in the application layer and talks down to transport; the rest sits in the transport layer and talks to application or internet. You cannot send a raw IP datagram from pure Java and you cannot speak ICMP, which is why ping is not a program you write with java.net.

Worked example — one GET, named layer by layer

Fetch http://example.org/index.html.

1. Application. Your code produces request text: GET /index.html HTTP/1.1, a Host: example.org header, a blank line. In Java that is a URLConnection (module 4) or bytes you write to a Socket (module 6).
2. Transport. TCP cuts the text into segments, numbers them, and stamps each with a source port (a temporary one the OS picked for you) and a destination port (80).
3. Internet. IP wraps each segment in a datagram carrying the source and destination addresses, and hands it to whatever hardware exists.
4. Host-to-network. The Wi-Fi driver frames it and modulates it onto the air.

The server's stack runs the same four steps in reverse, then the response repeats the whole trip backwards. Now ask the layering question: to serve this page over HTTPS instead, which layer changes? Only the application layer's port and a TLS shim above transport (module 13). Everything below is indifferent — and that is the answer the exam is looking for.