Type bbc.com and press Enter. On a fresh HTTPS connection, the screen can remain blank while the browser resolves the name, establishes a transport connection, negotiates encryption keys, checks a certificate and sends its first request. These are several distinct network exchanges, not a fixed dozen handshakes, and modern protocols can combine or skip many of them.
The timing is equally variable. A nearby server, warm DNS cache and reused connection can return a first byte in well under 200 milliseconds, while a cold connection to a distant server can take several times longer. The machinery stays invisible either way.
Step one: turning a name into an address
Internet traffic is routed toward IP addresses rather than human-readable domain names. The Domain Name System described in RFC 1034, published in 1987, provides the distributed hierarchy that connects names such as bbc.com with address records. It works more like a network of directories than a single phonebook.
When the browser needs an address, it may first consult its own cache, the operating system, a local hosts file or another implementation-specific source. If none supplies a usable answer, the device sends a query to its configured recursive resolver. That resolver may belong to the internet provider, an employer or a public DNS service.
On a complete cache miss, the resolver can ask a root server where to find the servers for .com, ask a .com server where to find the authoritative servers for bbc.com, and then ask an authoritative server for the address record. Caching means the full climb is often unnecessary. Readers can inspect those returned records with Make Tech Easier’s guide to using nslookup.
Encrypted DNS changes the transport without changing the underlying question. DNS over HTTPS, defined in RFC 8484, carries DNS messages inside HTTPS, while DNS over TLS uses a dedicated TLS connection. A fresh encrypted connection may require setup, but clients can reuse persistent sessions, so every DNS query does not automatically incur another handshake; Make Tech Easier also has a guide to DNS over HTTPS in browsers.
Step two: opening a TCP connection
Traditional HTTPS over HTTP/1.1 or HTTP/2 normally uses TCP, the reliable byte-stream protocol specified in RFC 9293. TCP delivers bytes in order and retransmits data when packets disappear. The application sees a stream rather than a loose collection of datagrams.
Opening the connection uses three packets in the basic case. The client sends SYN, the server responds with SYN-ACK, and the client completes the handshake with ACK. Because the reply must travel back before the third step can reach the server, connection establishment costs roughly one network round trip.
A server 50 milliseconds away in each direction therefore adds about 100 milliseconds at this stage alone. Light moves through optical fibre at roughly 200,000 kilometres per second, and routers, indirect cable routes and congestion add more delay. Content delivery networks reduce that distance by placing copies or proxy servers closer to readers.
Step three: negotiating encryption
HTTPS protects HTTP traffic with Transport Layer Security. TLS 1.3, standardised in RFC 8446 in 2018, is the newest standardised version. Its handshake establishes encryption keys and authenticates the server before ordinary application data begins flowing.
The browser sends a ClientHello containing supported parameters and usually a key share. The server selects compatible parameters, supplies its own key share and sends a certificate for the requested hostname. The two sides derive traffic secrets, typically through an elliptic-curve Diffie-Hellman exchange, then protect data with an authenticated cipher such as AES-GCM or ChaCha20-Poly1305.
The browser checks whether the certificate matches the hostname, remains within its validity period and chains back to an authority in its trust store. Browser and operating-system policies also determine how revocation information is handled. Certificate Transparency, described in RFC 9162, creates auditable public logs that make suspect certificate issuance easier to detect.
A new TLS 1.3 session can complete its normal handshake in one round trip. On a resumed session, the client may be permitted to send encrypted 0-RTT application data in its first flight. That saves time but provides weaker replay protection, so applications must restrict early data to requests they can safely process more than once.
Step four: requesting the page
Once the secure connection is ready, the browser can request the document. An HTTP/1.1 request might begin with the textual line GET / HTTP/1.1, but HTTP/2 does not send GET / HTTP/2 as a request line. It encodes the method and path in binary header frames using fields such as :method and :path, as specified in RFC 9113.
The server returns HTML, and the browser begins parsing it. That document may point to stylesheets, scripts, images, fonts, advertisements and analytics hosted on several origins. A new origin can require another lookup and connection, although HTTP/2 lets many requests to the same server share one multiplexed connection.
HTTP/3 changes the sequence more dramatically. It runs HTTP over QUIC rather than TCP, integrating TLS 1.3 into the transport and allowing independent streams to progress without TCP-level head-of-line blocking. Under the conditions described in RFC 9114, a fresh secure connection can be established in one round trip, while a resumed connection may carry permitted early data immediately.
Why the timing has no single budget
There is no universal 200-millisecond allowance for these exchanges. A cached DNS answer, nearby CDN edge and existing secure connection may eliminate almost all setup, while a cold lookup and fresh connection introduce several network trips. Server processing then adds its own delay before the first response byte appears.
Time to First Byte measures the interval between starting a navigation and receiving the first response byte, not the time required to display the complete page. Google’s TTFB guidance gives 0.8 seconds or less as a rough target for most sites, which illustrates how much broader real-world timing is than a fixed 200-millisecond claim. Large pages may continue downloading and rendering long after that first byte arrives.
Distance adds delay to every uncached round trip. Packet loss forces retransmission, congestion slows delivery, and public Wi-Fi may insert a captive portal before the requested site can be reached. A fast server cannot erase time already spent getting packets across the network.
Some optimisations begin the work before it becomes urgent. A preconnect hint can prompt the browser to perform DNS, TCP and TLS setup for a likely destination in advance. Browsers may also resolve visible links speculatively, turning later clicks into warmer starts.
The parts that quietly changed
The sequence has been rebuilt piece by piece. TLS 1.3 shortened cryptographic setup, QUIC combined transport and encryption, encrypted DNS protected queries between clients and resolvers, and Certificate Transparency made public certificate issuance auditable. Those changes reduced delay or exposure without removing the underlying need for machines to locate and authenticate one another.
HTTPS adoption also transformed the ordinary page load. An official Google Chrome Security report says HTTPS navigations climbed from roughly 30 to 45 percent in 2015 to about 95 to 99 percent around 2020. Free, automated certificate issuance helped make encrypted connections ordinary rather than exceptional.
Most of this still appears as nothing more than a blank tab becoming a page. During that brief pause, small packets cross routers and fibre, certificates are examined, keys are derived and a server finally receives the request. When the caches are cold and the destination is distant, every missing reply leaves the white rectangle on the screen for one round trip longer.
