Zoom-in: HTTP

Type an address, press Enter, a page appears. Inside that action is a stack of layers — each one solving a problem the layer before it left behind.

graph LR
    A(["👤 You"]) -->|"press Enter"| B(["🌐 Web page"])
    style A fill:#1e293b,stroke:#475569,color:#cbd5e1
    style B fill:#1e293b,stroke:#475569,color:#cbd5e1

Zoom in.

Layer 1 — Two roles

Two machines are involved: one asks, one answers.

graph LR
    C["💻 Client\n(Browser)"] -->|"asks"| S["🖥️ Server\nkarify98.site"]
    S -->|"answers"| C
    style C fill:#1e3a5f,stroke:#3b82f6,color:#93c5fd
    style S fill:#1a3a2a,stroke:#22c55e,color:#86efac

The client has no data of its own — it requests from the server. A browser, a mobile app, or another service can all act as a client.

→ Problem remaining: computers don't understand domain names. They only understand IP addresses.

Layer 2 — DNS: translating names to addresses

Before asking the server anything, the client needs to know where it lives.

graph LR
    C["💻 Client"] -->|"where is karify98.site?"| D["🗂️ DNS"]
    D -->|"18.235.x.x"| C
    C -->|"asks"| S["🖥️ Server\n18.235.x.x"]
    S -->|"answers"| C
    style C fill:#1e3a5f,stroke:#3b82f6,color:#93c5fd
    style D fill:#3b2a1a,stroke:#f59e0b,color:#fcd34d
    style S fill:#1a3a2a,stroke:#22c55e,color:#86efac

DNS is a phone book: look up a name, get a number. The result is cached, so repeat lookups skip this step.

→ Problem remaining: we have the address, but sending data directly doesn't guarantee delivery. The internet drops packets.

Layer 3 — TCP: opening a reliable channel

Before sending data, both sides confirm they can actually talk to each other.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: DNS resolved — now open the channel
    C->>S: SYN
    S-->>C: SYN-ACK
    C->>S: ACK
    Note over C,S: Reliable channel open

This three-way handshake ensures both ends are ready. If a packet is lost, TCP retransmits it automatically.

→ Problem remaining: channel is open, but data travels as plain text. Anyone in between can read it.

Layer 4 — TLS: encrypting the channel

HTTPS only. Both sides exchange certificates and negotiate an encryption key before any real data moves.

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: TCP connect ✓
    C->>S: ClientHello — here are the ciphers I support
    S-->>C: ServerHello + Certificate
    C->>S: Certificate verified ✓
    Note over C,S: Encryption key negotiated
    Note over C,S: All data from here is encrypted 🔒

TLS doesn't change how HTTP works — it wraps an encryption layer around the existing channel.

→ Problem remaining: the channel is secure. But what do the two sides actually say to each other?

Layer 5 — HTTP: the language of the conversation

HTTP is the agreed format for questions and answers. Each request has four parts:

GET /posts/hello-world HTTP/1.1
Host: karify98.site
Accept: text/html
Authorization: Bearer eyJhbGci...

Method GET · POST · PUT · DELETE — what the client wants to do

Path /posts/hello-world — the specific resource

Headers Metadata: who is sending, what format is accepted, auth token

Body Attached data — only present in POST/PUT

The server receives the request, processes it, and returns a response with a status code — a number that summarizes the outcome.

Full picture

5 layers. 1 journey. Each one exists for a reason.

sequenceDiagram
    participant C as Client
    participant D as DNS
    participant S as Server

    C->>D: where is karify98.site?
    D-->>C: 18.235.x.x

    C->>S: TCP connect (SYN → SYN-ACK → ACK)
    C->>S: TLS handshake 🔒
    S-->>C: Encrypted channel ready

    C->>S: GET /posts/hello-world HTTP/1.1
    Note over S: auth → logic → DB query
    S-->>C: HTTP/1.1 200 OK + body

Status codes — what the server is saying

Code	What the server means
200	OK — done, here's the data
201	Created — new resource was saved
301	Moved Permanently — address changed forever, cache this
302	Found — temporarily elsewhere, check here again next time
400	Bad Request — malformed request, client-side error
401	Unauthorized — not authenticated, log in first
403	Forbidden — authenticated but not authorized
404	Not Found — doesn't exist, or server won't say
500	Internal Server Error — bug in server-side code
503	Service Unavailable — server alive but overloaded or a dependency is down

Three common misconceptions

404 vs 403

404: not found — or the server is deliberately hiding it to avoid leaking information. 403: found it, but refused. Many APIs return 404 instead of 403 as a deliberate security pattern.

301 vs 302

301 is permanent: browsers and search engines cache it and never ask again. 302 is temporary: the client checks the original URL every time. One wrong redirect can hurt SEO for months.

500 vs 503

500 is a code bug: unhandled exception, null pointer, wrong logic. 503 is a load problem: server is alive but the database timed out or an upstream dependency isn't responding. Debug in completely different places.

Takeaway

Each layer exists for a specific reason — not because someone liked complexity. DNS because computers don't understand domain names. TCP because the internet doesn't guarantee packet delivery. TLS because plain text isn't safe. HTTP because both sides need a common language.

When debugging, the right question isn't "why is it broken" — it's "which layer broke": DNS, TCP, TLS, or HTTP logic?

Written with assistance from Amy 🌸 - AI Assistant. Content reviewed by the author.