Networking and Protocols

HTTP

Stateless request response application protocol used to deliver web and API content.

Where you will see it: Shows up in packet captures, network diagrams, firewall rules, and system or network logs.

What it is

HTTP (Hypertext Transfer Protocol) is an application layer protocol for requesting and transferring resources. A client sends a request that includes a method, target, headers, and sometimes a body. A server replies with a status code, headers, and an optional body.

Key points
  • Built around methods like GET and POST and responses with status codes.
  • Runs over transports like TCP (HTTP/1.1 and HTTP/2) and QUIC (HTTP/3).
  • Caching and proxies are core design features, not add ons.

How it works in broad strokes

  1. The client resolves the server name (usually via DNS) and opens a connection to the server.
  2. The client sends an HTTP request specifying a method, a path, and headers. Some requests include a body.
  3. The server processes the request and returns an HTTP response with a status code, headers, and a body if needed.
  4. HTTP is stateless, so the server does not automatically remember anything between requests. State is carried in cookies, tokens, or application data.
  5. Connections can be reused. HTTP/1.1 uses persistent connections, while HTTP/2 multiplexes many streams on one connection.
  6. Caching rules allow clients and intermediaries to reuse responses safely, which reduces latency and load.
  7. Proxies and gateways can modify routing and behavior, which is why the path between client and server is often more complex than it looks.

Concrete example

Your browser sends `GET /` to a server and receives `200 OK` plus HTML. Later it requests images and scripts with more GET requests. Even though it feels like one session, each request is independent unless cookies or tokens tie them together.

Why it matters

HTTP provides a flexible, interoperable way for clients, servers, and intermediaries to communicate. Its design supports caching, proxying, and incremental evolution, which is why it became the foundation of the web and modern APIs.

Security angle

  • Many web vulnerabilities are about how HTTP data is interpreted, such as injection into headers, parameters, or bodies.
  • Authentication is usually an application layer mechanism layered on top of HTTP. Protect tokens and cookies carefully.
  • Logging full URLs or headers can leak secrets. Be deliberate about what you store.

Common pitfalls

  • Assuming HTTP is always encrypted. Only HTTPS provides transport encryption.
  • Confusing idempotent methods with safe methods. Retries are not always harmless.
  • Misconfiguring caching headers and accidentally serving stale or private data.
  • Forgetting that intermediaries exist. Proxies can rewrite headers, compress bodies, and terminate connections.
  • Treating status codes as decorative. They are a contract that clients rely on.

DEEP DIVE

▾

What happens when you fetch a URL

At the core, HTTP is simple. A client opens a connection to a server, sends a request line plus headers, and optionally a body. The server responds with a status code, headers, and a body. That request and response pair is the unit of work.

HTTP is stateless in the sense that each request stands on its own. If the server needs continuity, it uses cookies, tokens, or other state carried in headers. This separation is powerful because it allows load balancing and caching, but it also means authentication and session management are explicit design choices, not hidden magic.

In real browsers, one page load causes many HTTP requests: HTML, CSS, JavaScript, images, APIs. Efficiency comes from connection reuse, parallelism, and caching, not from making one request bigger.

Connection reuse and why keep alive matters

In HTTP/1.1, a single TCP connection can carry multiple requests over time. The client sends a request, reads the response, then sends another. Reusing the connection avoids repeating TCP and TLS setup and avoids repeated slow start, which improves latency and throughput.

HTTP/2 goes further by multiplexing many streams over one connection. Instead of strict request then response ordering on the wire, frames for different streams can interleave. This reduces the need for many parallel TCP connections and improves performance on constrained networks.

Even with newer versions, the mental model stays. Requests and responses still exist. The differences are in how they are framed and scheduled on the wire.

Caching is part of HTTP, not an afterthought

HTTP includes explicit caching controls so clients and intermediaries can reuse responses safely. Headers like Cache Control and Expires describe how long content may be reused. Validators like ETag and Last Modified enable conditional requests where the client asks, has this changed, and the server can respond with Not Modified without resending the body.

This caching layer is one reason the web scales. A CDN is essentially an HTTP cache with clever routing. When caching is configured well, your browser and your nearest edge server do most of the work, and the origin sees far fewer requests.

Caching also creates common bugs. If you cache something that should be per user, you leak data. If you fail to cache something that is safe to share, you waste bandwidth. Understanding caching headers is a practical skill, not a theoretical detail.

Message details that show up in security and debugging

Headers are both powerful and risky. They carry authentication tokens, cookies, content types, and many other controls. If an application reflects untrusted input into headers or interprets headers incorrectly, you can get vulnerabilities like response splitting or cache poisoning.

HTTP also defines how proxies should behave. Some headers are hop by hop and must not be forwarded. Others are end to end. Mistakes here can create subtle failures where a request works directly but fails behind a proxy or a load balancer.

A good debugging habit is to inspect the exact request and response, not only the URL. Status codes, redirects, content types, and caching headers tell you what really happened, and they often explain issues faster than application logs alone.