What happens in the network after a user enters a URL in a browser?
Interview preparation resource from Gate Smashers.
After a user enters a URL, the browser parses it, checks available caches, resolves the hostname through DNS if necessary, connects to the selected server, secures the connection for HTTPS, sends an HTTP request, receives a response, fetches referenced resources, and renders the page. Some steps may be skipped, reused, or performed concurrently because of caching, connection reuse, HTTP/2, or HTTP/3.
1. URL parsing and local checks
The browser separates the URL into components such as the scheme, hostname, port if specified, path, query, and fragment. The fragment is normally handled locally by the browser and is not sent in the HTTP request.
Before making network requests, the browser may use cached HTTP responses, cached DNS records, service-worker-controlled responses, or an existing reusable connection. Cache rules and browser policies determine whether a cached response can be used or must be revalidated.
2. DNS resolution and delivery across the network
If the hostname is not already resolved, the browser or operating system obtains one or more IP addresses through DNS. The selected address may belong to the origin server, a content delivery network, or another intermediary.
The host consults its routing table to choose a next hop, commonly the local default gateway for off-network destinations. On a local Ethernet or Wi-Fi network, it resolves the link-layer address of that next hop when needed. Routers then forward IP packets toward the destination; network address translation may occur at a network boundary.
- DNS: Maps the hostname to one or more IP addresses.
- Routing: Determines the next hop used to send packets toward the selected address.
- NAT: May translate private and public addresses, but is not required for every connection.
3. Transport, TLS, and the HTTP request
For HTTP/1.1 or HTTP/2, the browser commonly uses TCP and establishes a connection before exchanging HTTP data. HTTP/3 uses QUIC, which runs over UDP and incorporates transport security. A previously established connection may be reused when permitted.
For an HTTPS URL, TLS authenticates the server using its certificate and negotiates encryption keys. The browser then sends an HTTP request containing a method, target path, headers, cookies when applicable, and an optional request body.
- TCP: Commonly carries HTTP/1.1 and HTTP/2.
- QUIC: Carries HTTP/3 over UDP.
- TLS: Protects HTTPS traffic and authenticates the server, subject to certificate validation.
4. Response processing and rendering
The request may be handled by a CDN, reverse proxy, load balancer, application server, cache, or database, depending on the service architecture. The responding component returns an HTTP status code, headers, and a response body, which may be HTML or another type of content.
When HTML is received, the browser parses it and discovers referenced resources such as stylesheets, scripts, images, and fonts. It requests those resources as needed, applies CSS, executes JavaScript where required, calculates layout, paints the result, and displays the page. Resource loading and rendering can overlap, and JavaScript or later network responses can update the page after the initial display.