How the Web Works

When you type a URL into a browser and press Enter, more than a dozen independent systems cooperate to fetch a single web page from somewhere on the planet, in a fraction of a second. The process involves the Domain Name System, the Border Gateway Protocol, the Transmission Control Protocol, the Internet Protocol, the Transport Layer Security protocol, the Hypertext Transfer Protocol, and the browser’s own rendering engine. The web is, in this sense, the most elaborate piece of distributed systems engineering in human history. This post is an attempt to explain, in roughly four thousand words, what actually happens between the keystroke and the page.

The protocol stack: from TCP to HTTP

The web runs on a stack of protocols, each of which solves a particular problem. At the bottom is the Internet Protocol (IP), which moves individual packets between hosts. An IP packet has a source address, a destination address, a length, and a payload. Routers along the way look at the destination address and forward the packet one hop closer to its destination. The system is best-effort: a packet may be lost, duplicated, delivered out of order, or corrupted, and IP does nothing about it.[1, 2, 9]

Above IP is the Transmission Control Protocol (TCP), which provides a reliable, ordered, byte-stream abstraction on top of IP. A TCP connection is established with a three-way handshake (SYN, SYN-ACK, ACK) and torn down with a four-way handshake (FIN, ACK, FIN, ACK). Once established, the connection behaves like a pipe: bytes written at one end appear, in the same order, at the other end, with errors and losses handled transparently. The cost is overhead: a TCP header is at least 20 bytes, and the connection setup requires a round-trip before any data can be sent. For a single request, the setup can dominate the latency.[2, 3, 10]

Above TCP is the Transport Layer Security (TLS) protocol, which provides encryption and authentication. TLS adds about two round-trips of latency to a new connection (the handshake negotiates the cryptographic parameters and authenticates the server), but subsequent requests on the same connection (TLS session resumption) require no extra round-trips. The cryptographic primitives have evolved: TLS 1.2, the dominant version until 2018, used a complex handshake with many cipher suites; TLS 1.3, the current version, is simpler, faster, and more secure, with only a small number of strong cipher suites and a 1-RTT handshake. The vast majority of web traffic is now encrypted.[3, 4, 11]

Above TLS is the Hypertext Transfer Protocol (HTTP), which defines how clients request resources and servers respond. HTTP is, in essence, a request-response protocol: the client sends a request (a method like GET or POST, a URL, a set of headers, and an optional body), and the server responds with a status code, a set of headers, and a body. The current version, HTTP/2 (2015) and HTTP/3 (2022), add multiplexing, header compression, and server push. The protocol is text-based in the request and response, but binary-framed in HTTP/2 and HTTP/3, and the bodies can be anything (HTML, JSON, images, video, etc.).[4, 5, 12]

DNS: the phone book of the internet

When you type nekud.click into a browser, the first thing the browser does is look up the IP address. The Domain Name System (DNS) is the global, distributed, hierarchical database that maps human-readable names to IP addresses. The system is, in many ways, the most important piece of infrastructure on the internet: without it, the web would be unusable, email would be impossible, and almost every networked service would fail.[4, 5, 13]

DNS is organised as a tree, with the root at the top, the top-level domains (.com, .org, .uk, .cn, etc.) below, the second-level domains (nekud, google, wikipedia) below that, and arbitrary subdomains (www, en, mail) below. Each zone of the tree is managed by a set of authoritative name servers, which are responsible for answering queries for the names in that zone. The system has more than a thousand root and top-level domain servers, distributed across the world, and a much larger number of recursive resolvers (operated by ISPs, by cloud providers, and by public services like Google Public DNS and Cloudflare 1.1.1.1).[4, 5, 14]

A DNS lookup, in the worst case, involves a recursive resolver asking the root, the TLD, and the authoritative name server, in sequence, for the answer. In practice, the answer is almost always cached: a typical resolver will return the answer from its cache in a few milliseconds, without any network round-trips. The cache lifetimes are controlled by the time-to-live (TTL) field of each DNS record, which is set by the authoritative name server. A short TTL allows changes to propagate quickly, at the cost of more queries; a long TTL reduces queries, at the cost of slower propagation. The trade-off is a constant negotiation between performance and consistency.[4, 5, 14]

The security of DNS has been a long-standing problem. The original DNS protocol was unauthenticated, meaning that a man-in-the-middle could forge a DNS response and redirect a user to a malicious site. The fix, DNSSEC, was standardised in the early 2000s but has been slow to deploy. As of 2024, perhaps half of the world’s DNS queries are validated, and the deployment is concentrated in the developed world. The newer alternatives, DNS over HTTPS (DoH) and DNS over TLS (DoT), encrypt the DNS query itself, preventing eavesdropping and manipulation by networks in the middle. The combination of DNSSEC and DoH/DoT, when fully deployed, will make DNS both authenticated and confidential.[5, 13, 14]

TCP/IP, BGP, and how packets become a connection

Once the IP address is known, the browser opens a TCP connection to the server. The three-way handshake (SYN, SYN-ACK, ACK) takes one round-trip, after which the connection is open and the browser can send the HTTP request. The first HTTP request, over a fresh TCP connection, takes two round-trips (one for the TCP handshake, one for the TLS handshake, one for the HTTP request and response). The total latency, for a server 50 milliseconds away (a typical intercontinental round-trip), is about 150 milliseconds before any data is received.[5, 6, 15]

But the IP address the browser connects to is rarely the destination server. The internet is a network of networks, and the path from the browser to the server is determined by the Border Gateway Protocol (BGP). BGP is the protocol by which the tens of thousands of independent networks (called autonomous systems) that make up the internet announce which IP addresses they can reach. Each autonomous system announces its own routes and the routes it has learned from its neighbours, and the global routing table — more than 900,000 prefixes as of 2024 — is the union of all these announcements.[5, 6, 16]

BGP is, by design, a protocol of trust. It assumes that each autonomous system will announce only routes it is authorised to announce, and only the best path to each destination. The assumption has not always held. In 2008, a Pakistani ISP attempted to censor YouTube within Pakistan by announcing a more specific route for youtube.com; the announcement leaked to the global routing table, and YouTube became unreachable worldwide for several hours. In 2014, an Indonesian ISP made a similar mistake, hijacking a large fraction of internet traffic for several hours. The fix, Resource Public Key Infrastructure (RPKI), allows autonomous systems to cryptographically sign their route announcements, and is now being deployed. The rollout is, however, incomplete, and a major BGP hijack remains a real possibility.[5, 6, 16]

Once the packets are flowing, the browser sends the HTTP request. The server responds with the HTML, the browser parses it, fetches the resources referenced in the HTML (CSS, JavaScript, images), and renders the page. The whole process, for a modern web page with dozens of resources, involves hundreds of DNS lookups, hundreds of TCP connections, hundreds of TLS handshakes, and thousands of HTTP requests. The optimisation of this process — connection pooling, resource preloading, header compression, server push, edge caching, content delivery networks — is the central engineering challenge of the modern web.[6, 7, 17]

TLS: what makes the web safe

Every web page you load is now encrypted. The encryption is provided by Transport Layer Security (TLS), the protocol that replaced the older Secure Sockets Layer (SSL) in 1999. TLS uses public-key cryptography to authenticate the server (and optionally the client), symmetric cryptography to encrypt the data, and a carefully designed handshake to negotiate the parameters. The current version, TLS 1.3, was finalised in 2018 and is now used by the vast majority of web traffic.[6, 7, 18]

The TLS handshake, in TLS 1.3, is a single round-trip. The client sends a ClientHello with a list of supported cipher suites and a key share; the server responds with a ServerHello, its certificate, and its key share; the client and server both derive the session keys and the handshake is complete. The first application data can be sent immediately, in the same flight as the client’s Finished message. The total latency, for a fresh connection, is one round-trip — the same as plain HTTP, before TLS 1.3.[6, 7, 18]

The cryptography under TLS has evolved over the years. Early versions used RSA for key exchange and RC4 or 3DES for bulk encryption; both are now considered broken. Modern TLS uses X25519 for key exchange and AES-256-GCM or ChaCha20-Poly1305 for bulk encryption. The certificates used to authenticate the server are signed by trusted certificate authorities (CAs), whose roots are bundled with the browser or the operating system. The system has been remarkably secure, but it has not been perfect: high-profile CA compromises (DigiNotar in 2011, Symantec in 2017) have led to a more decentralised trust model, with Certificate Transparency and the Automatic Certificate Management Environment (ACME) protocol (which is what Let’s Encrypt uses to issue free certificates).[6, 7, 18]

HTTP/3 and the next transport

The traditional web runs over TCP. HTTP/3, standardised in 2022, replaces TCP with QUIC, a new transport protocol that runs over UDP and provides built-in encryption, multiplexing, and connection migration. The change is invisible to most users, but it is the most significant change to the web’s transport layer in a generation.[6, 7, 19]

The motivation for QUIC is the well-known head-of-line blocking problem of HTTP/2 over TCP. In HTTP/2, multiple requests can be sent in parallel over a single TCP connection. If a single packet is lost, however, all the requests stall until the lost packet is retransmitted — even the requests whose data was already received. The result is that a single network glitch can slow down an entire page. QUIC solves the problem by providing native multiplexing at the transport layer: each stream is independent, and a lost packet affects only the stream it belonged to.[6, 7, 19]

QUIC also includes TLS 1.3 by design, eliminating the separate TLS handshake. And it includes connection migration, which allows a connection to survive a change in the user’s IP address (e.g. when switching from Wi-Fi to cellular). The combination of these features makes QUIC a significant improvement over TCP for the modern web, where users are increasingly mobile, networks are increasingly variable, and the cost of a stalled page is increasingly visible. Cloudflare, Google, Meta, and other large operators have deployed HTTP/3, and the share of web traffic running over QUIC is growing rapidly.[6, 7, 19]

The browser: a complete operating system

A modern browser is a complete operating system in disguise. It has a JavaScript engine, a rendering engine, a networking stack, a storage subsystem, a security model, an extension system, a media codec, a virtual machine, and a debugger. The largest browsers have codebases of more than 30 million lines, and the rendering engine alone is more complex than most desktop operating systems of the 1990s. The browser is, in 2024, the most important piece of software on most users’ devices.[7, 8, 20]

The architecture of a modern browser is multi-process. A browser process manages the user interface, the network, the storage, and the IPC. A renderer process per web page parses the HTML, runs the JavaScript, lays out the page, paints the pixels, and handles user input. A GPU process handles hardware-accelerated graphics. A network process manages the network stack, separate from the renderer to prevent malicious JavaScript from interfering with other pages. The processes are isolated from each other by the operating system, providing a strong security boundary: a compromised renderer cannot read the memory of other renderers, or of the browser process itself.[7, 8, 20]

The JavaScript engine is, perhaps, the most remarkable piece of the modern browser. V8 (in Chrome and Node.js), SpiderMonkey (in Firefox), and JavaScriptCore (in Safari) are just-in-time compilers that translate JavaScript to machine code, optimise it on the fly, and re-optimise it as the program’s behaviour changes. The performance of modern JavaScript is, in many cases, within a factor of two of native C++. The combination of high performance, a rich standard library, and a vast ecosystem of third-party libraries has made JavaScript the most widely deployed programming language in history, and the browser the most widely deployed runtime.[7, 8, 20]

Comparison: the modern web stack (2024)

Layer	Protocol / system	Primary function	Standardised	Key recent development
Network	IPv4 / IPv6	Routing packets between hosts	IPv4 (1981), IPv6 (2017)	IPv6 now ~50 percent of Google traffic
Transport (legacy)	TCP	Reliable byte stream	1981	QUIC replacing TCP for new applications
Transport (modern)	QUIC	Reliable, multiplexed, encrypted	2021 (RFC 9000)	Used by HTTP/3
Security	TLS 1.3	Encryption and authentication	2018	1-RTT handshake, mandatory forward secrecy
Name resolution	DNS	Name-to-address lookup	1983	DoH/DoT for privacy; DNSSEC for authentication
Routing	BGP	Inter-AS routing	1989 (BGP-4)	RPKI for origin validation
Application (legacy)	HTTP/1.1	Request-response protocol	1997	Still widely used
Application (modern)	HTTP/3	Request-response over QUIC	2022	Growing share, especially at the edge

Key numbers

• ~1 trillion: DNS queries per day worldwide (2024).
• ~900,000: prefixes in the global BGP routing table (2024).
• ~80,000: autonomous systems in the global routing table (2024).
• ~150 ms: typical latency for a fresh TCP+TLS+HTTP request across the Atlantic (2024).
• ~30 million: lines of code in the Chrome browser (2024).
• ~30 percent: estimated share of web traffic running over HTTP/3 (2024).
• ~50 percent: estimated share of Google traffic running over IPv6 (2024).

References

1. Wikipedia, “Internet protocol suite.” (Standard reference on the TCP/IP protocol stack.) https://en.wikipedia.org/wiki/Internet_protocol_suite
2. Wikipedia, “Transmission Control Protocol.” (Standard reference on TCP.) https://en.wikipedia.org/wiki/Transmission_Control_Protocol
3. Wikipedia, “Transport Layer Security.” (Standard reference on TLS, with version history.) https://en.wikipedia.org/wiki/Transport_Layer_Security
4. Wikipedia, “Domain Name System.” (Standard reference on DNS.) https://en.wikipedia.org/wiki/Domain_Name_System
5. Wikipedia, “Border Gateway Protocol.” (Standard reference on BGP.) https://en.wikipedia.org/wiki/Border_Gateway_Protocol
6. Wikipedia, “HTTP/3.” (Standard reference on HTTP/3 and QUIC.) https://en.wikipedia.org/wiki/HTTP/3
7. Wikipedia, “QUIC.” (Standard reference on the QUIC transport protocol.) https://en.wikipedia.org/wiki/QUIC
8. Wikipedia, “Google Chrome.” (Standard reference on Chrome, with a section on the multi-process architecture.) https://en.wikipedia.org/wiki/Google_Chrome
9. Wikipedia, “Internet Protocol.” (Standard reference on IP, with version history.) https://en.wikipedia.org/wiki/Internet_Protocol
10. Stevens, W. R. TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA: Addison-Wesley, 1994. (The classic reference on TCP/IP, still in print and still useful.)
11. Wikipedia, “TLS 1.3.” (Standard reference on TLS 1.3, finalised in 2018.) https://en.wikipedia.org/wiki/TLS_1.3
12. Wikipedia, “HTTP/2.” (Standard reference on HTTP/2, the predecessor of HTTP/3.) https://en.wikipedia.org/wiki/HTTP/2
13. Wikipedia, “DNSSEC.” (Standard reference on DNS Security Extensions.) https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
14. Wikipedia, “Google Public DNS.” (Standard reference on Google Public DNS, one of the largest recursive resolvers.) https://en.wikipedia.org/wiki/Google_Public_DNS
15. Wikipedia, “Round-trip time.” (Standard reference on network round-trip time.) https://en.wikipedia.org/wiki/Round-trip_time
16. Wikipedia, “Autonomous system (Internet).” (Standard reference on the autonomous systems that make up the internet.) https://en.wikipedia.org/wiki/Autonomous_system_(Internet)
17. Wikipedia, “Content delivery network.” (Standard reference on CDNs, which are now the dominant way that web content is delivered.) https://en.wikipedia.org/wiki/Content_delivery_network
18. Wikipedia, “Let’s Encrypt.” (Standard reference on Let’s Encrypt, the free, automated certificate authority.) https://en.wikipedia.org/wiki/Let%27s_Encrypt
19. Wikipedia, “Head-of-line blocking.” (Standard reference on the head-of-line blocking problem that QUIC solves.) https://en.wikipedia.org/wiki/Head-of-line_blocking
20. Wikipedia, “V8 (JavaScript engine).” (Standard reference on V8, the JavaScript engine in Chrome and Node.js.) https://en.wikipedia.org/wiki/V8_(JavaScript_engine)