How Do HTTP and HTTPS Work? Understanding the Backbone of the Internet
You type https://google.com into your browser and hit Enter. Within milliseconds, Google's homepage is in front of you. It seems so simple. But that single keystroke sets dozens of different systems into motion.
This article explains what happens in those milliseconds. And understanding this mechanism gives you concrete advantages — from diagnosing performance issues to recognizing security vulnerabilities.
What Is HTTP?
HTTP (HyperText Transfer Protocol) defines the rules of communication between a client and a server. Designed by Tim Berners-Lee in 1991, the core idea was simple: a client requests a resource, the server returns it.
HTTP is a stateless protocol — every request is independent. The server remembers nothing about previous requests. This design decision makes the web scalable, but it also pushes session management, authentication, and user state tracking to the application layer.
A Request's Journey: Step by Step
What happens when you go to https://example.com/products?
1. DNS Resolution
The browser first needs to find the IP address of example.com. Domain names are human-readable shortcuts — computers communicate via IP addresses.
DNS resolution happens in order: browser cache, then operating system cache, then router cache, then the ISP's DNS server, and finally the authoritative DNS server. Most requests resolve from cache in the first few steps.
2. TCP Connection — Three-Way Handshake
Once the IP address is found, the browser establishes a TCP connection with the server. TCP is the reliable communication protocol — it guarantees data arrives complete and in order.
The connection is established in three steps:
codeClient → Server: SYN (I want to connect) Server → Client: SYN-ACK (OK, I'm ready) Client → Server: ACK (agreed)
This handshake occurs on every connection and takes one round-trip time (RTT). If the user is in Istanbul and the server is in New York, that latency is ~120ms. A small number, but significant at scale.
3. TLS Handshake (for HTTPS)
If HTTPS is used, a TLS layer is added on top of TCP. TLS (Transport Layer Security) encrypts the communication and verifies the server's identity.
codeClient → Server: ClientHello (encryption methods I support) Server → Client: ServerHello + Certificate Client → Server: Verify certificate, generate session key Server → Client: Ready --- Encrypted communication begins ---
Modern TLS 1.3 reduced this handshake to a single round-trip. The older TLS 1.2 required two.
4. The HTTP Request
Once the connection is established, the actual request is sent:
httpGET /products HTTP/1.1 Host: example.com Accept: text/html,application/xhtml+xml Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Connection: keep-alive Cookie: session_id=abc123; theme=dark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
5. The HTTP Response
httpHTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Cache-Control: max-age=3600 ETag: "33a64df551425fcc55e4d42a148795d9f25f89d" Strict-Transport-Security: max-age=31536000; includeSubDomains <!DOCTYPE html> <html>...
HTTP Headers: Invisible but Critical
Headers carry metadata about requests and responses. Most developers give headers a surface-level glance, but most security, performance, and caching decisions live here.
Cache-Control — tells browsers and CDNs how long this response can be stored.
httpCache-Control: max-age=86400, public # 1 day, anyone can cache Cache-Control: no-store # never cache Cache-Control: private, max-age=3600 # only browser can cache
ETag — a fingerprint of the content. The browser sends this value with If-None-Match on the next request. If the content hasn't changed, the server returns 304 Not Modified and bandwidth is saved.
Strict-Transport-Security (HSTS) — tells the browser "always connect to this site via HTTPS." Automatically redirects HTTP requests to HTTPS.
CORS — controls requests from different origins. The Access-Control-Allow-Origin header defines which domains can access this resource.
httpAccess-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Authorization, Content-Type
HTTP/1.1 vs HTTP/2 vs HTTP/3
HTTP/1.1 (1997) — separate TCP connection for each request, or sequential requests. Browsers open 6 connections simultaneously for performance — which is why reducing resource count mattered on older sites.
HTTP/2 (2015) — multiple requests over a single TCP connection (multiplexing). Header compression. Server Push. You can download dozens of resources over a single connection simultaneously.
codeHTTP/1.1: HTTP/2: Request 1 → Request 1 → ← Response 1 Request 2 → Request 2 → Request 3 → ← Response 2 ← Response 2 Request 3 → ← Response 1 ← Response 3 ← Response 3
HTTP/3 (2022) — uses QUIC protocol instead of TCP. UDP-based but reliable. Superior to HTTP/2 specifically during packet loss. Makes a real difference on unstable connections like mobile networks.
HTTPS: Why TLS Matters
HTTPS is HTTP encrypted with TLS. It guarantees three things:
Encryption — communication cannot be read by third parties. Even if someone captures the traffic in the middle, they see encrypted data.
Authentication — the server certificate proves you're actually talking to example.com. Protection against DNS spoofing and man-in-the-middle attacks.
Integrity — data has not been modified in transit. Every message is protected with a MAC (Message Authentication Code).
Since 2018, Chrome marks HTTP sites as "Not Secure." Google treats HTTPS usage as a positive ranking factor. HTTPS is no longer an option — it's a requirement.
HTTP Through a Developer's Eyes
The Network tab in browser DevTools visualizes HTTP. The waterfall view shows how long each request took, how much time DNS consumed, TLS handshake latency, and TTFB (Time to First Byte).
Most performance problems live at the network layer: unnecessary requests, uncached resources, large payloads, blocking resources. Understanding HTTP is the prerequisite for diagnosing these problems.
Every web request is built on this mechanism. Regardless of the framework, regardless of the language — web development stays on the surface without understanding HTTP.