HTTP and HTTPS: How the Web Actually Talks

Every time a web page appears on your screen, two machines have just finished a fast, rigidly polite conversation. One asked for something; the other answered. The rules of that exchange — who speaks first, what a request looks like, how the reply is labelled — are what we call HTTP. And when that same conversation has to happen where no one else can listen in, it gains a single quiet letter: the S in HTTPS.

A Protocol Is Just an Agreement

Before anything technical, it helps to strip the word "protocol" of its intimidation. A protocol is simply a shared agreement about how to communicate — the digital equivalent of two people agreeing to speak the same language, take turns, and finish each sentence clearly. HTTP, the Hypertext Transfer Protocol, is the agreement that browsers and web servers use to move pages, images, videos and data across the web.

HTTP follows a client–server model. The client — your browser — opens a connection, sends a request, and waits. The server processes it and returns a response. The client always speaks first; the server never volunteers anything unasked. Underneath, these messages travel over a reliable transport connection called TCP, so that every byte arrives complete and in the right order. By convention, HTTP servers listen on port 80 and HTTPS servers on port 443 — like a building address and a specific apartment number, so traffic always finds the right door.

One property surprises newcomers: HTTP is stateless. The server keeps no memory of you between two requests — each one arrives as if it were the first the server had ever seen. That sounds limiting, but statelessness is exactly what lets the web scale to billions of requests. Memory is added on top through cookies: small pieces of data the browser attaches to each request so the server can recognise a returning visitor.

The Anatomy of a Request and a Reply

An HTTP message is plain, structured text divided into three zones — you will see them colour-coded in the diagram below. The first is the start line : a single line naming the method (what you want to do), the path (which resource), and the HTTP version being spoken. Next come the headers : labelled lines of metadata such as which host you are addressing or what content format you accept. Finally, separated by a blank line, sits the optional body — data you are sending, like a form submission. A simple GET request has no body at all.

The response mirrors that exact shape. Its start line — called the status line — carries the HTTP version, a three-digit status code, and a short phrase. Its headers describe the content coming back. And its body is the actual payload: the HTML, the image, the JSON — whatever you came for. Reading the diagram left to right, you are seeing one full round trip.

The Verbs: What You Can Ask For

Methods are the verbs of the web. They tell the server not just which resource you mean, but what you want to do with it. Two ideas help understand how each verb behaves. A method is safe if it only reads and changes nothing on the server. It is idempotent if repeating the exact same request always leaves the server in the same state — useful when a flaky network forces you to retry.

One distinction worth keeping in mind: idempotent and "changes state" are not opposites. PUT and DELETE both modify the server's state, yet they are idempotent — repeating them always leaves the resource in the same intended condition. The table below shows how the properties combine:

The Replies: Reading a Status Code

Every response carries a three-digit code. Its first digit alone tells you the outcome. Learning to read that leading digit is one of the fastest ways to understand what the web is doing behind the scenes.

Adding the S: When the Conversation Is Sealed

Plain HTTP has one glaring weakness: it travels in the open. Anyone positioned between you and the server — on shared Wi-Fi, at an internet provider, somewhere along the route — can read every byte. This is not theoretical; it is trivially easy to demonstrate with a packet sniffer on any public network.

HTTPS closes that gap. It is not a different protocol but the same HTTP wrapped inside a layer of encryption called TLS (Transport Layer Security). The S simply stands for secure. HTTPS solves three problems at once: encryption scrambles the data so eavesdroppers see only noise; authentication proves the server really is who it claims to be, using a digital certificate issued by a trusted authority; and integrity ensures the content was not quietly altered in transit.

All three are established in an opening exchange called the TLS handshake — a brief negotiation that happens before any page content flows. Think of it as two parties agreeing on a private code before the real conversation begins.

This design is clever about speed. Public-key cryptography is secure but slow, so TLS uses it only briefly — to establish a shared secret — and then switches to much faster symmetric encryption for the rest of the session. The current version, TLS 1.3, trimmed the handshake to a single round trip, making the overhead nearly invisible. Security, once a noticeable tax on speed, is now essentially free — which is a large part of why the web has moved almost entirely to HTTPS.

Three Generations of the Same Conversation

HTTP's meaning — its methods, headers and status codes — has stayed remarkably stable since the 1990s. What kept changing is how efficiently those messages travel. Each generation solved a bottleneck the previous one exposed.

HTTP/1.1 introduced persistent connections, so a browser no longer opened a fresh connection for every image and stylesheet. But it still handled requests largely one after another: a single slow response could hold up everything queued behind it — a problem known as head-of-line blocking. Browsers worked around it by opening several connections at once, which helped but was never elegant.

HTTP/2 rethought the transport entirely. It replaced human-readable text with a compact binary format and introduced multiplexing: many independent streams interleaved over a single connection, plus header compression to cut repetitive overhead. Think of the difference between a single-lane road where every car waits for the one ahead, and a multi-lane highway where traffic flows in parallel — HTTP/2 added the lanes. A large step forward — yet because it still ran over TCP, one lost packet could stall every stream at once, pushing the blocking problem down a layer rather than removing it.

HTTP/3 takes the boldest step: it drops TCP in favour of QUIC, a newer transport built on UDP. QUIC treats each stream as genuinely independent, so a lost packet on one stream no longer freezes the others. It folds TLS 1.3 encryption directly into the connection setup and can even survive a change of network — switching from Wi-Fi to mobile data — without starting the conversation over.

That is the quiet elegance of the whole system. The words a browser and server exchange today would be recognisable to the web of thirty years ago — a method, a path, a status code. Everything underneath has been rebuilt for speed and privacy, while the conversation itself stayed simple enough to explain in a single sitting.

What to Look for Next Time

The next time you open a website, the concepts in this article are right there on screen — you just need to know where to look.

Click the padlock icon in your browser's address bar on any HTTPS site. You will see the certificate that authenticated the server and the TLS version that sealed the session. On most browsers you can also open the Developer Tools (F12 on Windows, Cmd+Option+I on Mac) and go to the Network tab. Reload the page and watch every HTTP request appear in real time: the method, the path, the status code, and the response headers — the exact anatomy this article described.

Try visiting http://example.com instead of https://example.com and see whether your browser redirects you automatically (a 301 status code) or warns you about an insecure connection. That redirect is HTTP/HTTPS in action, visible in the Network tab as a pair of requests: one that returns 301 and one that finally returns 200.