When your service sends an HTTP request to a neighbouring service, a dozen things happen between "called the method" and "got the response": a name turns into an address, a connection is established, data is encrypted, sliced into packets, flown through a pile of intermediate nodes, and reassembled. Holding all of this in your head as one blob is impossible. So networking is described in layers — each layer handles its own job and doesn't meddle in anyone else's.

There are two such maps: the theoretical OSI model (seven layers) and the practical TCP/IP model (four layers) that the internet actually runs on. Let's get comfortable with both — and from then on the whole network falls into a picture that makes sense instead of looking like magic.

Why layers at all

The idea is simple: break the hard task of "move data from one machine to another" into independent levels. The upper layer doesn't know and doesn't want to know how the lower one works — it just uses its services.

An analogy is sending a parcel. You put an item in a box and write the address (that's your job). How the box gets there — by truck, plane, or bicycle — doesn't concern you; the delivery service handles that. And how the plane stays in the air no longer concerns the delivery service. Each level trusts the one below to do its job.

Networking is the same: your code works with HTTP and JSON without thinking about how the bytes run across the wire. Thanks to that, you can swap Wi-Fi for a cable and the service won't even notice — only the lowest layer changed.

The OSI model: seven layers

OSI (Open Systems Interconnection) is a teaching model of seven levels. In practice nothing is built directly on it, but everyone knows it because it's a common language: when an engineer says "the problem is at layer 7" or "it's an L4 balancer", they mean exactly these OSI layers.

Top to bottom:

  1. Application — what your code works with: HTTP, gRPC, SMTP, DNS. This is where requests and responses that the application understands live.
  2. Presentation — formats and encryption: TLS, character encodings, compression. Turns application data into a byte stream and back.
  3. Session — setting up and maintaining the "dialogue" between the parties. In practice it's mostly dissolved into the neighbouring layers.
  4. Transport — delivery between processes: TCP and UDP, ports. Responsible for data reaching the right service on the machine and (for TCP) arriving whole and in order.
  5. Network — addressing and routing between machines: IP. Decides which path a packet takes from sender to receiver through intermediate nodes.
  6. Data Link — transfer within one network segment: Ethernet, MAC addresses, Wi-Fi.
  7. Physical — the actual wires, radio waves, optics: how ones and zeros become a signal.

You don't need to memorize all seven. Four matter in practice: application (your HTTP), transport (TCP/UDP and ports), network (IP addresses), and — once security is involved — the TLS layer.

The TCP/IP model: four layers

TCP/IP is what the internet actually runs on. It's simpler and groups the same tasks into four layers:

  • Application — HTTP, DNS, gRPC. TLS is effectively lumped in here too. These are OSI layers 5–7 merged together.
  • Transport — TCP and UDP. Exactly OSI layer 4.
  • Internet — IP. OSI layer 3.
  • Link — Ethernet, Wi-Fi, network card drivers. OSI layers 1–2 together.

When people say "the TCP/IP stack", they mean this foursome. The mapping to OSI is kept in mind only to understand other people's jargon like "L7 routing".

Encapsulation: how data passes through the layers

The most useful thing for building intuition is understanding what happens to your data on the way down. Each layer wraps the upper layer's data in its own "envelope", adding its own header. This is called encapsulation.

Take an HTTP request from your service:

  1. Application: an HTTP request is formed — the line GET /orders/42, headers, body.
  2. Transport: TCP wraps this into a segment and attaches ports (say, "from port 51000 to port 443") and numbers for reassembling in order.
  3. Network: IP wraps the segment into a packet and attaches the sender's and receiver's IP addresses.
  4. Link: the packet is wrapped into a frame with MAC addresses for delivery to the nearest router.

On the other side, everything is unwrapped in reverse order: the link layer strips its envelope and passes it up, the transport layer strips its own, and the exact HTTP request that was sent arrives at your code. Each layer on the receiving side effectively "talks directly" to its counterpart on the sending side, without knowing about the rest.

Where this applies

This map isn't an abstraction for an exam — it's a working diagnostic tool. When something breaks, an engineer's first question is: which layer is the problem on?

  • A service can't find another service by name — that's the application layer, most likely DNS.
  • A connection is established but drops or lags — you look at the transport layer, TCP and timeouts.
  • "No route to host", packets don't arrive — the network layer, IP and routing.
  • A certificate error — the TLS layer, HTTPS.
  • A 500 or 404 comes back — that's already the application layer, HTTP itself; the network has nothing to do with it.

Layers give you a language and an order of action: not "everything's broken", but "let's check bottom to top". This is also where balancer jargon comes from — an L4 balancer works at the transport layer (spreading TCP connections without looking inside), while an L7 balancer understands HTTP and can route by URL. We cover the difference in the article on load balancers.

Where beginners stumble:

  • They try to memorize the seven OSI layers word for word. Four matter in practice; the rest is for understanding other people's jargon.
  • They confuse TCP and IP. IP (network layer) delivers a packet to the machine; TCP (transport) delivers it to a specific service on it and watches over integrity. Different jobs on different layers.
  • They think TLS is a separate protocol instead of HTTP. TLS is an encryption layer under HTTP: on top it's still the same HTTP, just in a secure envelope.
  • When debugging they grab the top layer even though the cause is lower: for example, fixing code when the name actually isn't resolving.

What to learn next

From here it makes sense to go down the layers that a backend actually touches. First, addressing: IP addresses, ports, and NAT, to understand how a packet finds a machine and a service. Then transport: TCP and UDP. After that, the application layer you work with every day: DNS and HTTP, and on top of it HTTPS and TLS. All of it sits exactly on the layers we've just laid out.