HTTP/HTTPS

The Language of the Web

Every time you visit a website, your browser and the server are having a conversation. They need a shared language, agreed-upon rules for how to ask for things and how to respond. That language is HTTP (HyperText Transfer Protocol).

HTTP is simple in concept: you ask for something, you get a response. But modern web applications have pushed it far beyond its origins, and understanding how HTTP works, and how HTTPS secures it, is foundational for anyone building or designing web systems.

The Request-Response Cycle

The client (usually a browser, mobile app, or another service) sends a request. The server processes it and sends back a response. That's it.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Plain HTTP: all data travels as readable text. Anyone who can observe the network (ISP, router, public WiFi owner, or an attacker doing a man-in-the-middle attack) can read your passwords, session tokens, and request body. HTTP is fine for static public content; it's dangerous for anything authenticated or private.

1 / 10.5×1×2×3×Playground

Plain HTTP request and response in plaintext

A raw HTTP request looks like this:

And a response looks like:

Both have a headers section (metadata about the request or response) and optionally a body (the actual content).

HTTP is also stateless, meaning each request is completely independent. The server doesn't remember anything about your previous requests. This is why cookies and sessions exist (to simulate statefulness on top of a stateless protocol).

HTTP Methods

HTTP methods define the intent of a request. A solid REST API maps these to CRUD operations:

Idempotent means calling the same request multiple times has the same effect as calling it once. GET, PUT, and DELETE are idempotent. POST is not: posting the same order twice creates two orders.

The PATCH vs PUT distinction: PUT replaces the entire resource. If you PUT a user object and forget to include the email field, the email gets wiped. PATCH only updates the fields you send. In practice, most APIs use PUT loosely, but the distinction matters in strict REST design.

Status Codes

Status codes tell the client what happened. They're grouped by their first digit:

2xx — Success

• 200 OK — standard success
• 201 Created — resource was created (response to POST)
• 204 No Content — success but nothing to return (common for DELETE)

3xx — Redirection

• 301 Moved Permanently — the resource has a new permanent URL
• 302 Found — temporary redirect (browser follows but keeps using old URL)
• 304 Not Modified — cached version is still valid; no need to re-download

4xx — Client Error

• 400 Bad Request — malformed request syntax
• 401 Unauthorized — not authenticated
• 403 Forbidden — authenticated but not allowed
• 404 Not Found — resource doesn't exist
• 429 Too Many Requests — rate limited

5xx — Server Error

• 500 Internal Server Error — generic server failure
• 502 Bad Gateway — upstream server returned an invalid response
• 503 Service Unavailable — server is overloaded or down for maintenance
• 504 Gateway Timeout — upstream server took too long

The 401 vs 403 distinction trips people up. 401 means "you're not logged in." 403 means "you're logged in, but you don't have permission." Always use the right one, as it affects how clients and security tools behave.

HTTP Versions: 1.1, 2, and 3

HTTP has evolved significantly. Each version addresses the performance limitations of the previous one.

HTTP/1.1 (1997)

The workhorse of the web for decades. Introduced persistent connections (keep-alive) so multiple requests could reuse the same TCP connection instead of opening a new one each time.

The problem: HTTP/1.1 is head-of-line blocked at the request level. If one request is slow, subsequent requests queue up behind it on the same connection. Browsers work around this by opening 6-8 parallel connections per domain: a workaround, not a solution.

HTTP/2 (2015)

HTTP/2 is a major overhaul:

• Multiplexing: multiple requests and responses fly over a single TCP connection simultaneously, with no head-of-line blocking at the HTTP level
• Header compression: HTTP headers are repetitive; HTTP/2 compresses them with HPACK, saving bandwidth
• Server push: servers can proactively send resources the client will need (before the client asks)
• Binary protocol: more efficient to parse than HTTP/1.1's text format

HTTP/2 requires HTTPS in practice (all major browsers enforce this).

HTTP/3 (2022)

HTTP/3 replaces the underlying transport: instead of TCP, it runs on QUIC (over UDP). This fixes a fundamental problem: HTTP/2's multiplexing is still limited by TCP's head-of-line blocking at the transport layer. If a single TCP packet is lost, all streams wait.

QUIC implements its own reliability per-stream, so a lost packet only delays that stream, not every other request. HTTP/3 also has faster connection setup (0-RTT in some cases) and handles network changes better (useful on mobile when switching between WiFi and cellular).

How HTTPS Works

HTTPS is HTTP with TLS (Transport Layer Security) on top. TLS encrypts the connection so that nobody between your browser and the server can read or tamper with the data.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

TLS handshake: the negotiation that happens before any HTTPS data flows. The browser sends supported cipher suites, the server responds with its certificate (signed by a trusted CA) and public key. Both sides derive the same session key via a key exchange algorithm. TLS 1.3 (2018) cut this to 1 RTT; older TLS 1.2 required 2 RTTs, adding 100-300ms of latency.

1 / 10.5×1×2×3×Playground

TLS handshake establishing encrypted session key

Here's a simplified version of the TLS handshake:

1. Client Hello: "I want to connect. Here are the TLS versions and cipher suites I support."
2. Server Hello: "Here's the TLS version and cipher we'll use. Here's my certificate."
3. Certificate verification: The client verifies the certificate is valid and signed by a trusted Certificate Authority (CA).
4. Key exchange: Client and server use asymmetric cryptography (like RSA or ECDH) to agree on a shared session key without ever sending it directly over the wire.
5. Symmetric encryption begins: All subsequent data is encrypted with the shared session key (symmetric crypto is much faster than asymmetric).

The certificate is the trust anchor. It proves the server is who it says it is, signed by a CA like Let's Encrypt, DigiCert, or Comodo. Your browser has a built-in list of trusted CAs.

TLS 1.3 (the current version) made the handshake faster; it completes in 1 round trip instead of 2, and supports 0-RTT resumption for previously-visited sites. Always use TLS 1.3 if you're configuring servers today.

TLS Termination

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

TLS termination at the edge: a common production pattern. The browser communicates with a load balancer or reverse proxy over HTTPS. The proxy decrypts the traffic and forwards plain HTTP to the backend services over a private network. This lets you manage one TLS certificate at the edge instead of on every service, and keeps encryption processing off your app servers.

1 / 10.5×1×2×3×Playground

TLS termination at the edge of the private network

In production environments, a load balancer or reverse proxy acts as the entry point to the system and performs TLS termination. The proxy decrypts the incoming HTTPS traffic and passes it to internal application servers as plain HTTP over a private, secure network. This centralizes certificate administration and keeps encryption/decryption CPU overhead off your primary app servers.

HTTP Headers Worth Knowing

A few headers come up constantly in system design:

• Authorization carries auth tokens (Bearer tokens, API keys)
• Content-Type tells the receiver what format the body is in (application/json, text/html, etc.)
• Cache-Control controls caching behavior (no-cache, max-age=3600)
• ETag is a version identifier for resources, used with 304 Not Modified
• CORS headers (Access-Control-Allow-Origin) controls cross-origin access
• X-Request-ID is a trace ID for debugging requests across services
• Retry-After tells rate-limited clients when to try again

Summary

HTTP is the request-response protocol that powers the web. Requests have methods that express intent (GET, POST, PUT, DELETE), and responses have status codes that communicate outcomes. HTTP/1.1 is simple but inefficient; HTTP/2 adds multiplexing and compression over TCP; HTTP/3 moves to QUIC over UDP to eliminate transport-level head-of-line blocking. HTTPS layers TLS on top of HTTP, using a handshake to establish encrypted communication verified by certificates. These fundamentals underpin everything from REST APIs to microservice communication to CDN behavior; know them deeply and system design decisions become much clearer.