Networking

HTTP

HTTPS's own page describes itself as "just HTTP run over TCP with one thing added: TLS." This page is that one thing removed — HTTP itself, the plain request/response protocol underneath practically every web page, REST API, and IoT device dashboard, independent of whether the connection happens to be encrypted.

Quick reference

What it is: A text-based request/response protocol built on TCP — a client sends a request, a server sends back a response, and that exchange is done.
Mental model: Ordering at a counter: you state exactly what you want, you get back exactly one answer, and the interaction ends — nothing is remembered between orders unless you're carrying something (a cookie/token) that says otherwise.
Key numbers: Port 80 (plaintext); status codes are 3 digits, grouped 1xx–5xx by category.
Reach for it when: Any request/response interaction between a client and server — in practice almost always via HTTPS, never plain HTTP, once anything real is at stake.

The request/response shape

Every HTTP exchange is one request, one response — a method, a path, a set of headers, and an optional body, answered with a status code, its own headers, and an optional body.

One request, one response — the entire exchange, whether it's a browser loading a page or a device polling an API.

Methods

GET: Fetch a resource. Should never change anything server-side — safe to retry, cache, or send twice by accident.
POST: Create something, or trigger an action with side effects. Not safe to blindly retry — a retried POST can create a duplicate.
PUT: Replace a resource entirely with the given data. Idempotent — sending the same PUT twice has the same effect as sending it once.
PATCH: Apply a partial update to a resource, rather than replacing the whole thing.
DELETE: Remove a resource. Idempotent — deleting something already deleted is still "deleted."
HEAD: Same as GET, but the server returns only headers, no body — used to check a resource's existence/metadata cheaply.

Status codes

Range	Meaning	Common examples
1xx	Informational — the request was received, processing continues	101 Switching Protocols (used by WebSocket's upgrade)
2xx	Success	200 OK, 201 Created, 204 No Content
3xx	Redirection — the client should look elsewhere	301 Moved Permanently, 304 Not Modified
4xx	Client error — the request itself was wrong	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	Server error — the request was fine, the server failed	500 Internal Server Error, 503 Service Unavailable

Headers

Headers carry metadata about the request or response, separate from the actual body content:

Host: Which domain the request is for — required since one server/IP can host many different domains.
Content-Type: The format of the body — application/json, text/html, application/octet-stream for raw binary (like a firmware image).
Content-Length: Body size in bytes, so the receiver knows exactly where the body ends.
Authorization: Credentials — a bearer token, API key, or Basic-auth pair — proving who's making the request.
Cache-Control: How long a response may be cached, and by whom, before it needs to be re-fetched.

Statelessness — and how cookies work around it

HTTP itself has no memory — each request is handled with zero knowledge of any earlier one, even from the same client. That's deliberate: it's what lets any server behind a load balancer answer any request, since no server needs to remember which client it talked to last. The practical need to stay "logged in" across many requests is solved entirely outside the protocol's own state: a cookie or token is sent by the client on every subsequent request, and the server looks it up against its own session store — the illusion of a continuous conversation, built out of many independent, stateless ones.

HTTP/1.1 vs. HTTP/2 vs. HTTP/3

HTTP/1.1: Text-based, one request waits for its response before the next can use that same connection (unless pipelined, which is rarely used in practice) — browsers work around this by opening several TCP connections in parallel.
HTTP/2: Binary framing, multiplexes many requests over a single TCP connection at once — but still inherits TCP's own head-of-line blocking at the packet level, since it's all still one TCP stream underneath.
HTTP/3: Runs over QUIC instead of TCP — gets true independent-stream multiplexing, since QUIC's per-stream ordering means one lost packet no longer blocks unrelated requests.

Real-world applications

REST APIs — the vast majority of device-to-cloud and service-to-service APIs use HTTP methods and status codes as their entire vocabulary for "what happened."
IoT device dashboards and local config pages — many embedded devices run a small HTTP server for local setup/status (often on their own Wi-Fi AP before they've joined a network).
OTA firmware update checks — a device periodically issuing a GET to ask "is a newer firmware version available" is one of the simplest and most common HTTP use cases in embedded systems.
Webhooks — one service notifying another of an event by making an outbound HTTP POST is the standard way independent systems integrate without polling each other.

Gotchas

Field notes

Returning HTTP 200 with an error described only in the response body is a common API design mistake — it defeats every piece of tooling (caches, monitoring, retries) that makes decisions based on the status code alone.
GET requests are meant to be safe and idempotent — a GET that has side effects (like incrementing a counter) will eventually get "retried" by a cache, prefetcher, or browser in a way that silently corrupts state.
Plain HTTP (no TLS) sends everything, including any Authorization header, in cleartext — see HTTPS & TLS for why this matters on any network you don't fully control.