Foundations · Lesson 03

Layers & the narrow waist

Your API call rides on a stack of layers, each solving one problem and trusting the layer below. Understanding the stack — and the single skinny point everything funnels through — explains why the internet can be so diverse on top and bottom yet still interoperate everywhere.

Why layers at all?

Sending bytes across the world is too big a problem to solve in one piece. So it's split into layers, like a postal system: you write a letter (content), put it in an envelope with an address (delivery), the post office routes it (logistics), and a truck carries it (physical transport). Each layer does one job and depends only on the agreed interface of the layer beneath — it doesn't care how that layer works. Swap the truck for a plane and the letter is unaffected. That's the same interface/implementation idea from Lesson 01, applied to the network itself.

The TCP/IP model (the one that runs the internet)

• Application — the language your API speaks: HTTP, gRPC, DNS. This is where you spend most of this course.
• Transport — TCP (reliable, ordered) or UDP (best-effort), plus ports to reach the right program. (Lesson 05 lives here.)
• Internet — IP: gives every machine an address and routes packets across networks toward it.
• Link — the actual hop over Ethernet or Wi-Fi to the next device.

OSI: the textbook seven-layer version

Interviews and textbooks often reference the OSI model, which splits the same idea into seven layers. You don't need to memorise all seven — just know it's a more granular map of the same territory, and how it lines up:

The narrow waist: everything funnels through IP

Here's the elegant part. There are many things at the top (HTTP, gRPC, email, video, games) and many things at the bottom (Ethernet, Wi-Fi, fibre, 5G). But in the middle, almost everything funnels through one protocol: IP. Drawn out, the diversity-at-the-ends and singularity-in-the-middle forms an hourglass:

Why does this matter so much? Because the narrow waist decouples innovation at the two ends. Inventors of a new application protocol (say, QUIC) only have to run on top of IP — they don't need to care whether the user is on fibre or 5G. Builders of a new physical network only have to carry IP — they don't need to know whether it's a video call or an API request. One stable contract in the middle let the top and bottom evolve independently for decades. It's the interface/implementation principle operating at planetary scale.

Under the hood: encapsulation — tracing a packet down and up the stack

When your application sends an HTTP request, each layer wraps the data from the layer above with its own header (and sometimes trailer). This is called encapsulation. On the receiving end, each layer strips its wrapper and hands the payload up. Here is the exact sequence for GET /v1/users/42 HTTP/1.1:

1. Application (HTTP). Your code produces the request: a UTF-8 string starting with the request line, headers, blank line, and optional body. This is the HTTP message — pure text.
2. Transport (TCP). The OS TCP stack breaks the HTTP message into segments. Each segment gets a TCP header (source port, destination port, sequence number, ACK number, flags, window size). The segment is now: [ TCP header | HTTP data ].
3. Internet (IP). The TCP segment is handed to the IP layer, which prepends an IP header (source IP, destination IP, TTL, protocol=6 for TCP). The packet is now: [ IP header | TCP header | HTTP data ].
4. Link (Ethernet). The IP packet is placed inside an Ethernet frame with a MAC-address header and a CRC trailer for error detection. The frame is now: [ Ethernet header | IP header | TCP header | HTTP data | CRC ].
5. Physical. The frame is serialised to electrical signals / radio waves / photons and sent to the next hop (router or switch).

Traced example — the byte layout on the wire:

━━━ Ethernet frame ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ethernet header  (14 bytes)
  dst_mac: aa:bb:cc:dd:ee:ff   ← MAC of the next router hop
  src_mac: 11:22:33:44:55:66   ← MAC of this machine's NIC
  ethertype: 0x0800              ← "payload is IPv4"

  ━━━ IPv4 packet ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  IP header  (20 bytes minimum)
    version: 4, IHL: 5 (20 bytes), TTL: 64
    protocol: 6                   ← TCP
    src_ip: 203.0.113.5           ← client
    dst_ip: 93.184.216.34         ← server

    ━━━ TCP segment ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    TCP header  (20 bytes minimum)
      src_port: 51000              ← ephemeral client port
      dst_port: 443                ← HTTPS
      seq: 1001, ack: 0, flags: PSH|ACK

      ━━━ HTTP message (application payload) ━━━━━━━━━━━━━━━━━━━━━━━━
      GET /v1/users/42 HTTP/1.1
      Host: api.example.com
      ...

Ethernet CRC  (4 bytes)          ← receiver checks for bit errors; discards frame if bad

On the receiving end the layers unwind in reverse: the NIC checks the Ethernet CRC and strips the Ethernet header; the IP layer checks the destination IP (drops if not for us) and strips the IP header; TCP reassembles segments in order, strips the TCP header, and delivers the HTTP bytes; the HTTP server parses the request line and headers. The application sees only: GET /v1/users/42 HTTP/1.1\r\nHost: api.example.com\r\n….

How to debug & inspect it — which tool sees which layer

Each debugging tool speaks to exactly one layer. Choosing the right tool instantly narrows the search space. If ping fails, the problem is below the application layer — there is no point inspecting HTTP headers yet.

A diagnostic walkthrough — "my API call fails; where is the problem?"

Debug checklist — layer by layer:

1. ping hostname — if this fails, the problem is at the IP or link layer; fix routing/DNS before anything else.
2. dig hostname — confirm the name resolves to the expected IP; a cached stale record is a common gotcha after a server move.
3. traceroute hostname — find the hop where packets stop; that is the firewall or dead router.
4. nc -zv host port — confirm something is listening; if refused, the service is down or the port is wrong.
5. curl -v URL — inspect HTTP-level behaviour; the status code tells you which layer owns the error (4xx = your request, 5xx = the server).
6. If packets arrive but responses look wrong: tcpdump -i any -A host <ip> and port <port> to see the raw bytes at every layer.

Sources & further reading

• MDN — How the web works (overview)
• Cloudflare — OSI model & network layers
• RFC 1122 — Requirements for Internet Hosts (the TCP/IP layering)