HTTP/HTTPS: The Language of the Web

📘 Chapter 2: How the Internet Works ⏱️ 8 min read 🎯 Networking Fundamentals

Once DNS gives you an IP address, your browser needs to talk to that server. HTTP (HyperText Transfer Protocol) is the language they speak — a simple, text-based request/response protocol that powers virtually every web interaction.

The Request/Response Model

HTTP is fundamentally simple: the client sends a request, the server sends back a response. Every web page, API call, image load, and form submission follows this pattern.

Fig 1. An HTTP request and response — every part labeled. The protocol is text-based and human-readable.

HTTP Methods

Method	Purpose	Has Body?	Idempotent?
`GET`	Retrieve data	No	Yes
`POST`	Create a resource	Yes	No
`PUT`	Replace a resource entirely	Yes	Yes
`PATCH`	Partially update a resource	Yes	No*
`DELETE`	Remove a resource	Optional	Yes

*PATCH can be idempotent depending on implementation, but isn't guaranteed to be.

Status Codes — What the Server Is Telling You

The Five Families

1xx (Informational): "Hold on, I'm working on it" — rarely seen directly
2xx (Success): "Here you go" — 200 OK, 201 Created, 204 No Content
3xx (Redirect): "Go look over there" — 301 Moved Permanently, 304 Not Modified
4xx (Client Error): "You messed up" — 400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Too Many Requests
5xx (Server Error): "I messed up" — 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

HTTP Versions: The Evolution

Feature	HTTP/1.1 (1997)	HTTP/2 (2015)	HTTP/3 (2022)
Connections	One request per connection (or pipelining)	Multiplexed streams over one connection	Multiplexed over QUIC (UDP)
Head-of-line blocking	Yes — a slow response blocks all others	Solved at HTTP level, still at TCP level	Fully solved (independent streams)
Headers	Text, repeated every request	Binary, compressed (HPACK)	Binary, compressed (QPACK)
Server push	No	Yes (rarely used in practice)	Yes
Transport	TCP	TCP	UDP (QUIC)
Connection setup	TCP + TLS = 3 round trips	TCP + TLS = 2-3 round trips	0-1 round trips (QUIC)

Why HTTP/2 Was a Big Deal

With HTTP/1.1, browsers opened 6+ parallel TCP connections per domain to work around the one-request-per-connection limit. HTTP/2's multiplexing lets dozens of requests fly over a single connection simultaneously. This dramatically reduced connection overhead and improved page load times.

HTTPS and TLS: Why Encryption Matters

HTTPS is HTTP wrapped in TLS (Transport Layer Security). The "S" means the entire conversation is encrypted — not just passwords, but URLs, headers, and content.

Fig 2. The TLS handshake — establishing an encrypted channel before any HTTP data flows.

For system design, HTTPS matters because:

Trust: Users and browsers require it. Chrome marks HTTP as "Not Secure."
Performance cost: TLS adds 1-2 round trips at connection start (but TLS 1.3 and session resumption minimize this).
Certificate management: At scale, managing thousands of certificates (and their renewals) becomes an infrastructure challenge.
Termination point: Where do you terminate TLS? At the load balancer? At each server? This is a key design decision.

Keep-Alive and Connection Pooling

Opening a new TCP + TLS connection for every request is expensive. Modern systems reuse connections:

Connection Reuse Strategies

Keep-Alive (HTTP/1.1 default): The connection stays open after a response, ready for the next request. Saves the TCP+TLS setup cost.
Connection pooling: Servers maintain a pool of pre-established connections to databases and upstream services. A request grabs one from the pool, uses it, and returns it.
HTTP/2 multiplexing: One connection handles unlimited parallel requests. No need for multiple connections at all.

Design implication: A service making 1000 requests/second to a database shouldn't open 1000 connections. With a connection pool of 20, those requests queue and reuse connections — protecting the database from connection exhaustion.

How HTTP/2 Transformed Page Loading

When Akamai tested HTTP/2 vs HTTP/1.1 for loading a page with 200+ small resources (images, scripts, styles), they saw:

HTTP/1.1: Browser opens 6 connections, requests queue behind each other. ~10 second page load.
HTTP/2: Single connection, all 200 resources requested simultaneously. ~3 second page load.

The improvement is most dramatic on high-latency connections (mobile networks, cross-continent) where the cost of each round trip is highest.

Headers That Matter for System Design

Header	Direction	Why It Matters
`Cache-Control`	Response	Controls how long clients/CDNs cache responses. Saves server load.
`ETag`	Response	Content fingerprint. Enables `304 Not Modified` — "nothing changed, use your cache."
`Content-Encoding: gzip`	Response	Compressed body. Reduces bandwidth 60-80% for text content.
`Connection: keep-alive`	Both	Reuse this TCP connection for subsequent requests.
`Retry-After`	Response	With 429/503 — tells clients when to retry. Prevents thundering herd.
`X-Request-ID`	Both	Trace a request across microservices for debugging.

Build an HTTP Request

Select the components to construct a valid HTTP request:

Method:

Path:

Headers:
Authorization: Bearer token123
Content-Type: application/json
Accept: application/json

Body (for POST/PUT):

🎯 Key Takeaway

Understanding HTTP deeply lets you optimize at the protocol level — caching headers eliminate redundant requests, compression reduces bandwidth, connection reuse slashes latency, and choosing the right HTTP version can transform performance. HTTP isn't just plumbing; it's a toolbox of optimization levers.

Further reading: MDN HTTP reference · "High Performance Browser Networking" by Ilya Grigorik (free online) · RFC 9110 (HTTP Semantics)