Entering a URL in a browser starts a coordinated exchange between the browser, operating system, local network, internet routers, and one or more servers.

Consider this address:

The browser cannot send this string directly across the network and expect the destination to understand it. It must identify the server, establish a way to communicate with it, protect the connection, format a request, and pass the request through several networks. The server then processes the request and sends a response back.

This chapter follows that exchange from the address bar to the rendered page. It focuses on the sequence and the responsibility of each component rather than the internal mechanics of every protocol.

A network request usually passes through the following stages:

This is the full path, but a browser does not perform every stage for every request. It may reuse a cached DNS result, an existing connection, or a cached response. For the main walkthrough, assume that the browser needs fresh data from the network.

The browser first interprets the URL and separates it into components:

The URL does not specify a port, so the browser uses the default port for the scheme. HTTPS normally uses port 443, while HTTP normally uses port 80.

The fragment has a special property: the browser does not send it in the HTTP request. The browser uses #reviews locally after it receives the document. The server receives the path and query string:

If the user enters text that is not clearly a URL, the browser may treat it as a search query. A complete URL such as the one above avoids that ambiguity.

The browser may also apply local policies at this stage. It can consult its cache, enforce a previous rule that requires HTTPS, or allow a service worker to handle the request. These mechanisms can change the path, but they do not change the basic network exchange when the browser must contact a remote server.

Networks deliver packets using numeric IP addresses, not domain names. The browser therefore needs an IP address for shop.example.com.

The browser asks a resolver for an address, either through the operating system's name-resolution service or through a built-in secure DNS client. The answer may already exist in a browser cache, an operating-system cache, or a nearby DNS resolver. If no cache contains a valid answer, the DNS system locates the authoritative records for the domain.

A result might contain an IPv4 address:

It might also contain an IPv6 address:

Modern clients may receive both and choose whichever address provides a usable connection first.

DNS answers can also direct the client toward an edge server, content delivery network, or load balancer rather than the machine that runs the application. From the browser's perspective, that returned endpoint is the server to contact.

DNS resolution answers one narrow question: which IP address should the client try? It does not establish the connection or deliver the web page.

The browser asks the operating system to communicate with the chosen IP address. The operating system inspects its routing table to decide where to send the traffic.

If the destination is on the same local network, the computer can send frames toward it directly. A public web server is normally outside the local network, so the computer sends the traffic to its default gateway, usually a home router, office router, or cloud network router.

Before sending a frame, the computer needs the local-link address of that next hop. On an IPv4 network, it commonly uses ARP to find the gateway's MAC address. IPv6 uses Neighbor Discovery for a similar purpose.

This distinction matters:

For a remote website, the first frame normally targets the local gateway's MAC address, not the web server's MAC address. MAC addresses have local-link significance and do not guide traffic across the entire internet.

The browser opens a socket, which is the operating system interface used to send and receive network data. A connection can be identified by the transport protocol and four endpoint values:

The operating system usually selects a temporary source port for the client. The server listens on the well-known destination port.

For HTTP/1.1 and HTTP/2, the browser normally establishes a TCP connection. TCP begins with a three-message handshake:

The handshake confirms that both endpoints can exchange traffic and creates the state needed for TCP's ordered, reliable byte stream.

HTTP/3 follows a different path. It uses QUIC over UDP instead of TCP and combines transport and security setup more closely. The end goal remains the same: create a communication channel between the client and server.

At this point, the browser has reached an endpoint, but an HTTPS request still needs a secure channel.

HTTPS protects HTTP traffic with TLS. The TLS handshake lets the client and server:

The server presents a certificate for a hostname such as shop.example.com. The browser verifies that the certificate covers the requested hostname, has not expired, chains to a trusted certificate authority, and has a valid signature.

If verification succeeds, both sides derive keys for the connection. Later messages are encrypted and protected against undetected modification.

If verification fails, the browser stops or displays a security warning. A valid network route and a working TCP connection do not make an invalid certificate safe.

TLS also lets the endpoints agree on an application protocol. For example, they can select HTTP/1.1 or HTTP/2 during the handshake. For this walkthrough, TLS turns the established connection into an authenticated, encrypted channel.

The browser converts the relevant URL components and its request metadata into an HTTP message. An HTTP/1.1 request could look like this:

The request line contains the method, path, query string, and HTTP version. Headers carry metadata such as the requested hostname, accepted response formats, browser information, and cookies.

The hostname remains important even after DNS resolution. Many websites can share one IP address, so the receiving infrastructure uses the hostname to select the correct site. With HTTPS, the client also supplies the intended server name during connection setup so the endpoint can present the appropriate certificate.

HTTP/2 and HTTP/3 encode messages differently on the wire, but they preserve the same application meaning: a method, target, headers, and optional body.

The HTTP message must pass through several networking responsibilities before it can leave the computer.

With HTTPS over TCP, the transformation can be summarized as follows:

Each stage adds information needed for its responsibility. The receiver removes and interprets that information in the opposite direction.

This process is called encapsulation. The important idea for this walkthrough is that one browser request appears in different forms at different parts of the network stack.

Applications usually do not perform these transformations themselves. The browser handles HTTP and TLS, while the operating system and network interface handle much of the transport, network, link, and physical work.

The first transmission carries the data from the client to its local gateway over Ethernet, WiFi, or another access technology. The gateway removes the incoming link-layer frame, examines the destination IP address, chooses the next hop, and creates a new frame for the next link.

This hop-by-hop process continues across the path:

Routers make forwarding decisions using IP addressing and routing information. A router does not normally need the URL path to forward a packet. For HTTPS traffic, the HTTP path is encrypted anyway.

The link-layer frame changes at each hop because each link has different endpoints. The IP packet carries the end-to-end network addresses in the usual case, although devices such as NAT gateways can rewrite addresses and ports.

A home router commonly performs Network Address Translation. It replaces the client's private source address, such as 192.168.1.25, with a public address and records the mapping. When response traffic returns, the router uses that record to forward the data to the correct device and source port.

The internet path may cross several independently operated networks. Routing chooses a viable path, but it does not guarantee that request and response traffic follow the same routers.

The IP address returned by DNS often belongs to an edge system rather than the application process that produces the page.

Depending on the site's architecture, the first server may be:

TLS may terminate at this first server. In that case, the edge system decrypts the request after completing the TLS handshake, inspects the HTTP hostname and path, and either serves a response or forwards the request to another service.

For the example request, the application might retrieve product 42, apply the requested currency, and generate an HTML page. That work may involve caches, databases, and other services, but those application operations are separate from delivering the request across the network.

The server returns an HTTP response containing a status code, headers, and an optional body:

The status code describes the result. 200 OK means the server successfully returned the requested representation. Other responses may redirect the browser, report that a resource does not exist, reject access, or indicate a server failure.

The headers describe the response. They tell the browser how to interpret the body, whether it is compressed, how long it may be cached, and how much data to expect.

The response follows the same layered process as the request. The server supplies HTTP data to TLS, the transport protocol carries protected bytes or frames, IP routes packets toward the client, and each local link delivers frames to the next hop.

For TCP, the receiving side acknowledges delivered bytes. If packets are lost, TCP can retransmit the missing data. Packets may arrive out of order, but TCP presents an ordered byte stream to the application.

When the bytes reach the client, the browser reverses the transformations: it receives transport data, verifies and decrypts TLS records, decodes the HTTP response, and passes the body to the appropriate browser component.

Receiving the HTML document rarely completes a page load. The browser parses the document and may discover references to stylesheets, scripts, images, fonts, videos, and API endpoints.

Each distinct hostname may require DNS resolution and a connection. Requests to the same server can often reuse an existing connection. HTTP/2 and HTTP/3 can carry multiple concurrent request streams over one connection.

The browser also checks its cache before requesting a resource. A valid cached response can avoid a network transfer. If the cached entry needs validation, the browser can ask the server whether the resource has changed and reuse its local copy when it has not.

After parsing and laying out the document, the browser uses the fragment from the original URL, #reviews, to navigate to the matching part of the page. The server never needed that fragment.

A page load is the sum of work performed by several systems. A simplified latency breakdown is:

Some of these operations can overlap, and caches or reused connections can remove entire stages.

DNS time covers hostname resolution when a valid answer is not already cached.

Connection time covers TCP or QUIC setup. Physical distance affects this stage because handshake messages must travel between the endpoints.

TLS time covers authentication and key establishment. Session resumption can reduce this cost for repeat connections.

Server time covers the work between request arrival and the beginning of the response.

Transfer time depends on response size, available bandwidth, congestion, packet loss, and protocol behavior.

Browser time covers parsing, script execution, layout, painting, and the loading of additional resources.

The delay before the first response byte reaches the client is often measured as time to first byte, or TTFB. It can include connection work, network travel, queueing, and server processing, depending on where measurement begins.

This breakdown makes vague reports such as "the website is slow" more precise. A delay can occur before DNS completes, during connection setup, while the server computes the response, during transfer, or while the browser processes the result.

The complete cold-start path is useful for learning, but repeated requests are often shorter.

A cached DNS record can remove the need for a new lookup. A persistent connection can remove another TCP and TLS handshake. A CDN can return content without contacting the origin application. A cached browser response can avoid the network entirely.

Redirects add extra request-response cycles. For example, a server may redirect http://example.com to https://example.com, or example.com to www.example.com. Each new hostname may require its own resolution and connection.

Proxies, VPNs, enterprise gateways, and mobile carrier networks can change the route. The browser may connect to a proxy first, while the proxy creates another connection toward the destination.

The IP address can also select an edge location close to the client. Two users requesting the same hostname may receive different addresses or reach different physical servers.

These variations optimize, secure, or control the same fundamental exchange: identify an endpoint, establish communication, send an application request, and return a response.

The complete example uses:

Each line in this walkthrough maps to a separate networking responsibility. A failure at any stage produces a different symptom, from "host not found" to a certificate warning, connection timeout, HTTP error, or incomplete page.

When you type a URL, the browser separates its scheme, hostname, port, path, query, and fragment. DNS resolves the hostname, the operating system selects a route, TCP or QUIC establishes communication, TLS protects HTTPS traffic, and HTTP carries the request and response.

Routers forward packets across networks while link-layer frames change at every hop. The first responding server may be a CDN, proxy, or load balancer, and the returned HTML can trigger many more requests.

The most important idea is:

A web page is the visible result of a layered exchange involving names, addresses, connections, protected messages, packets, frames, and signals.