Loading content
Web Protocols
The transport and application protocols that carry every request — and why each one exists.
What it is
Once a name resolves and a route is found, two machines still have to agree on how to talk. That agreement is a stack of protocols — transport underneath, application on top — each solving a specific problem of speed, reliability or security.
Knowing the protocols explains the web’s behaviour: why some connections are fast and others stall, why HTTPS is now universal, and what each layer can and cannot guarantee.
Going deeper
The client sends a ClientHello listing its supported ciphers and the server name it wants (SNI); the server replies with its choice and its certificate; the two agree a shared secret via key exchange; and the rest of the session is encrypted with that secret. TLS 1.3 compresses this to a single round trip — one reason modern HTTPS feels no slower than plain HTTP.
HTTP/2 multiplexed many streams over one TCP connection, but TCP delivers bytes strictly in order — so one lost packet stalls every stream behind it (head-of-line blocking). QUIC rebuilds transport on UDP with independent streams and built-in encryption, so a lost packet only stalls its own stream. That is the whole reason HTTP/3 exists.
TCP’s guarantees — ordered, complete, congestion-controlled delivery — are not free: they cost a handshake before any data, and a stall-and-retransmit whenever a packet drops. UDP throws those guarantees away for raw speed, which is exactly why real-time media, DNS and QUIC prefer it and rebuild only the reliability they actually need on top.
The request/response protocol of the web — HTTPS adds TLS encryption.
HTTP is the simple request-then-response conversation every page load is built on; HTTPS is the same protocol wrapped in TLS so the exchange is encrypted and authenticated. HTTPS is now effectively mandatory across the web.
Many requests multiplexed over one connection.
HTTP/2 lets a browser send many requests in parallel over a single connection with compressed headers, removing the need for the connection-juggling tricks HTTP/1.1 forced. Faster pages, same semantics.
HTTP over QUIC (UDP) — faster setup, no head-of-line blocking.
HTTP/3 runs over QUIC, a UDP-based transport that folds in encryption and connection setup, eliminating the head-of-line blocking that hurt HTTP/2 on lossy networks. The current cutting edge of web transport.
The reliable, ordered byte-stream transport.
The Transmission Control Protocol guarantees that bytes arrive in order and without loss, via a three-way handshake and retransmission. The dependable workhorse under most of the web, at the cost of latency.
Connectionless, fast, and lossy by design.
The User Datagram Protocol fires packets with no handshake, ordering or delivery guarantee — perfect where speed matters more than perfection: DNS lookups, video, gaming, and now QUIC.
A persistent, two-way channel over an HTTP upgrade.
WebSocket upgrades an HTTP connection into a long-lived, bidirectional channel, so server and client can push messages to each other in real time — the basis of live chat, feeds and collaborative apps.
Well-known port numbers map services to sockets.
A port number tells a machine which service a connection is for — 443 for HTTPS, 53 for DNS, 22 for SSH, 25 for mail. The port map is the directory of what a server is actually offering.
Read it honestly
Protocols describe capability, not trust: HTTPS proves the channel is encrypted and the certificate valid, not that the other end is honest. The stack tells you how two machines talk and what each layer guarantees — never who is on the far side or why.
Take Web Protocols from reference to the live system.