Free lesson · Computer Networking

What Happens When You Type A Url And Press Enter

Easy10 min readnetworkingcomputer-networkstcp-ip

The Golden Question of Networking

"What happens when you type a URL into your browser and press Enter?" This question appears in more technical interviews than almost any other networking question. It shows up in frontend interviews, backend interviews, full-stack interviews, and System Design interviews - because the answer touches every layer of the network stack, from DNS to TCP to TLS to HTTP to server-side processing and back.

More importantly, the answer to this question is the roadmap for this entire course. Every module you will study - DNS, IP, TCP, TLS, HTTP, load balancers, CDNs - plays a role in the sequence of events between pressing Enter and seeing a rendered page. This topic walks through the full sequence at a high level. Later modules will zoom into each step in detail.

Let us trace what happens when you type https://www.example.com/about into your browser and press Enter.

Step 1 - URL Parsing

The browser first examines the URL you typed and breaks it into components:

Scheme: https - tells the browser to use HTTP over TLS (encrypted)
Host: www.example.com - the server to connect to
Path: /about - the specific resource to request
Port: Not specified, so the browser uses the default for HTTPS: port 443

If you had typed just example.com without the scheme, the browser would try HTTPS first (most modern browsers default to HTTPS). If HTTPS fails, some browsers will fall back to HTTP. This fallback behavior is gradually being eliminated as the web moves toward HTTPS-only.

The browser also checks whether this URL matches any entries in its HTTP Strict Transport Security (HSTS) list - a security mechanism where websites tell the browser "never connect to me over plain HTTP." If www.example.com is on the HSTS list, the browser will refuse to use HTTP even if explicitly typed.

Step 2 - DNS Resolution

Interactive animation: A recursive resolver walks the hierarchy - root, then TLD, then authoritative server - and caches each answer along the way.

The browser now knows it needs to connect to www.example.com, but it cannot connect to a hostname - it needs an IP address. The process of translating a human-readable hostname into a numeric IP address is called DNS (Domain Name System) resolution.

DNS resolution follows a multi-step process:

Browser cache: The browser checks its own cache of recent DNS lookups. If you visited www.example.com recently, the IP address might still be cached. If found, skip to Step 3.
Operating system cache: If the browser cache misses, the browser asks the operating system. The OS maintains its own DNS cache and also checks the local hosts file (/etc/hosts on Mac/Linux, C:\Windows\System32\drivers\etc\hosts on Windows).
Recursive resolver: If the OS cache misses, the OS sends a DNS query to a recursive resolver - typically operated by your ISP or a public DNS service like Google (8.8.8.8) or Cloudflare (1.1.1.1). The recursive resolver is a specialized server whose entire job is to resolve DNS queries on your behalf.
Root name server → TLD server → Authoritative server: If the recursive resolver does not have the answer cached, it walks up the DNS hierarchy: first asking a root name server for the .com TLD server, then asking the .com TLD server for the authoritative name server for example.com, then asking that authoritative server for the IP address of www.example.com.

The recursive resolver caches each answer along the way, so future queries for the same domain are answered immediately without repeating the full hierarchy walk. DNS responses include a TTL (Time to Live) value that tells the resolver how long to cache the answer - typically between 60 seconds and 24 hours.

The result of DNS resolution is an IP address - say, 93.184.216.34. Now the browser knows exactly which server to connect to on the internet.

sequenceDiagram
    participant B as Browser
    participant OS as OS Cache
    participant RR as Recursive<br/>Resolver
    participant ROOT as Root<br/>Name Server
    participant TLD as .com TLD<br/>Server
    participant AUTH as example.com<br/>Authoritative

    B->>OS: What is www.example.com?
    Note over OS: Cache miss
    OS->>RR: Query www.example.com
    Note over RR: Cache miss
    RR->>ROOT: Where is .com?
    ROOT-->>RR: Try TLD server at x.x.x.x
    RR->>TLD: Where is example.com?
    TLD-->>RR: Try auth server at y.y.y.y
    RR->>AUTH: What is www.example.com?
    AUTH-->>RR: 93.184.216.34 (TTL: 3600)
    RR-->>OS: 93.184.216.34
    OS-->>B: 93.184.216.34

This sequence diagram shows the DNS resolution process. The browser asks the OS cache for the IP address of www.example.com. The OS cache misses and queries the recursive resolver. The recursive resolver also misses and starts the hierarchy walk: first asking a root name server where the .com TLD server is, then asking the .com TLD server where the example.com authoritative server is, then asking the authoritative server for the actual IP address of www.example.com. The authoritative server responds with 93.184.216.34 and a TTL of 3600 seconds. The answer propagates back through the recursive resolver and OS to the browser.

Step 3 - TCP Connection (Three-Way Handshake)

Interactive animation: The three-way handshake - SYN, SYN-ACK, ACK - that opens a TCP connection in one round trip.

With the IP address in hand, the browser initiates a TCP (Transmission Control Protocol) connection to the server. TCP provides reliable, ordered delivery of data - it guarantees that data arrives completely and in the right order, or the sender is notified of a failure.

TCP connections begin with a three-way handshake:

SYN: Your browser sends a SYN (synchronize) packet to the server, saying "I want to start a connection."
SYN-ACK: The server responds with a SYN-ACK (synchronize-acknowledge), saying "I accept, and I also want to synchronize with you."
ACK: Your browser sends a final ACK (acknowledge), confirming the connection is established.

This handshake takes one round trip between client and server. If the server is 50 ms away, the handshake takes approximately 50 ms (the SYN travels to the server, the SYN-ACK comes back). After the handshake, both sides have agreed on initial sequence numbers and window sizes, and the connection is ready to carry data.

The TCP connection is established to a specific port on the server - port 443 for HTTPS. The server has a process (a web server like Nginx or Apache) listening on that port, waiting for incoming connections.

If this is not your first visit to the site, the browser might skip the TCP handshake entirely by reusing an existing persistent connection (also called a keep-alive connection). HTTP/1.1 and HTTP/2 both support persistent connections, and browsers typically keep connections open for several minutes after the last request. Connection reuse eliminates one full round trip of latency - a significant optimization when a page load triggers dozens of requests for CSS, JavaScript, images, and API calls.

Step 4 - TLS Handshake (For HTTPS)

Interactive animation: The TLS handshake compared - two round trips in TLS 1.2 against a single round trip in TLS 1.3.

Because the URL uses https://, the browser now performs a TLS (Transport Layer Security) handshake on top of the TCP connection. TLS encrypts all data between the browser and the server, preventing anyone between them (ISPs, Wi-Fi eavesdroppers, government surveillance) from reading the content.

The TLS handshake accomplishes three things:

Server authentication: The server presents its TLS certificate, proving it is actually www.example.com and not an impersonator. The browser verifies the certificate against its list of trusted Certificate Authorities (CAs).
Key exchange: The browser and server negotiate a shared secret key using asymmetric cryptography (typically ECDHE - Elliptic Curve Diffie-Hellman Ephemeral). This shared key will encrypt all subsequent communication.
Cipher agreement: Both sides agree on which encryption algorithm to use for the session (typically AES-256-GCM in modern TLS 1.3).

With TLS 1.3 (the current standard), the TLS handshake takes a single round trip - a major improvement over TLS 1.2 which required two round trips. If the browser has connected to this server recently, TLS 1.3 supports 0-RTT resumption, where the handshake is folded into the first data packet, eliminating the TLS latency entirely for repeat connections.

Step 5 - HTTP Request

Now the browser has a secure, encrypted TCP connection to the server. It sends an HTTP request asking for the specific resource:

GET /about HTTP/2
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml,...
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, br
Cookie: session_id=abc123...

The request includes:

Method: GET - retrieve the resource (as opposed to POST, PUT, DELETE, etc.)
Path: /about - the specific page
Protocol version: HTTP/2 - the modern version with multiplexing and header compression
Headers: Metadata about the browser, what content types it accepts, language preferences, encoding support, and any cookies for this domain

If this site uses HTTP/2 (most modern sites do), the request is multiplexed over a single TCP connection. The browser can send multiple requests simultaneously without waiting for each response - a major performance improvement over HTTP/1.1 where requests had to be serialized or required multiple TCP connections.

Step 6 - Server Processing

The server receives the HTTP request and processes it. What happens next depends entirely on the server architecture, but a typical flow for a dynamic web page involves:

Web server (Nginx/Apache) receives the request and determines how to handle it - serve a static file directly, or pass the request to an application server.
Load balancer (if present) may have already distributed this request to one of many backend servers based on health, current load, or geographic proximity.
Application server (running your Node.js, Python, Java, Go, or other application code) processes the request - authenticating the user via the session cookie, querying a database, calling internal APIs, rendering a template.
Database queries fetch the data needed for the page - user profile, page content, personalization data. These queries themselves travel over the network from the application server to the database server using protocols like PostgreSQL's wire protocol or MySQL's client protocol.
Response construction: The application assembles the HTML document, serializes it, and hands it back to the web server.

Step 7 - HTTP Response

The server sends back an HTTP response:

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 23847
Content-Encoding: gzip
Cache-Control: max-age=3600
Set-Cookie: tracking_id=xyz789; Secure; HttpOnly

The response includes a status code (200 OK means success), headers with metadata about the response, and the body - in this case, the HTML document for the /about page.

Common status codes you will encounter: 200 (success), 301 (permanent redirect), 304 (not modified - use your cached version), 404 (not found), 500 (internal server error), 503 (service unavailable).

The response body is compressed with gzip (as indicated by Content-Encoding: gzip), reducing the transfer size by typically 60-80%. The browser decompresses it automatically.

Step 8 - Rendering

The browser receives the HTML and begins rendering the page:

Parse HTML into a DOM (Document Object Model) tree
Discover external resources - CSS files, JavaScript files, images, fonts - referenced in the HTML
Fetch external resources - each triggers its own DNS → TCP → TLS → HTTP cycle (though most reuse the existing TCP connection via HTTP/2 multiplexing, and many are served from a CDN cache)
Parse CSS and construct the CSSOM (CSS Object Model)
Execute JavaScript which may modify the DOM or fetch additional data via API calls
Layout - calculate the position and size of every element
Paint - render pixels to the screen

The entire process - from pressing Enter to seeing a rendered page - typically takes 200-1000 ms for a well-optimized website. The majority of that time is network latency (DNS + TCP + TLS + HTTP round trips), not server processing or rendering.

graph TD
    subgraph FullProcess["URL to Rendered Page"]
        URL["Type URL<br/>Press Enter"] --> PARSE["Parse URL"]
        PARSE --> DNS["DNS Resolution<br/>~20-100 ms"]
        DNS --> TCP["TCP Handshake<br/>~1 RTT (~20-100 ms)"]
        TCP --> TLS["TLS Handshake<br/>~1 RTT (~20-100 ms)"]
        TLS --> HTTP["HTTP Request<br/>+ Server Processing<br/>~50-500 ms"]
        HTTP --> RESP["HTTP Response<br/>Transfer"]
        RESP --> RENDER["Parse HTML<br/>Fetch Assets<br/>Render Page<br/>~100-500 ms"]
    end

    style URL fill:#c4b5fd,stroke:#a78bfa,color:#000
    style DNS fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style TCP fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style TLS fill:#7c3aed,stroke:#6d28d9,color:#fff
    style HTTP fill:#6366f1,stroke:#4f46e5,color:#fff
    style RESP fill:#4f46e5,stroke:#4338ca,color:#fff
    style RENDER fill:#4338ca,stroke:#3730a3,color:#fff

This diagram shows the complete sequence from typing a URL to seeing a rendered page. The steps flow vertically: Parse URL, DNS Resolution taking 20 to 100 milliseconds, TCP Handshake taking one round trip of 20 to 100 milliseconds, TLS Handshake taking one round trip of 20 to 100 milliseconds, HTTP Request plus Server Processing taking 50 to 500 milliseconds, HTTP Response Transfer, and finally parsing HTML, fetching assets, and rendering the page taking 100 to 500 milliseconds.

Why This Sequence Matters

This end-to-end walkthrough is not just interview preparation. It is the mental model that makes every subsequent networking topic click into place:

When you study DNS (Module 7), you will understand exactly where it fits in this sequence and why DNS latency affects every page load.
When you study TCP (Module 5), you will understand why the three-way handshake adds latency and why connection reuse matters.
When you study TLS (Module 9), you will understand why TLS 1.3's single-round-trip handshake was such an important optimization.
When you study HTTP (Module 8), you will understand why HTTP/2 multiplexing improves performance - fewer TCP connections, less handshake overhead.
When you study CDNs (Module 11), you will understand exactly which steps they optimize - they shorten the DNS → TCP → TLS → HTTP path by placing content closer to the user.

Every optimization in web performance - CDNs, connection pooling, HTTP/2, TLS session resumption, DNS prefetching, preconnect hints - targets a specific step in this sequence. Understanding the full sequence is what lets you evaluate those optimizations intelligently rather than applying them blindly.

Interview: This question appears in interviews at every level, but the expected depth varies:

Junior/Mid-level: Cover the major steps - DNS, TCP, HTTP request/response, rendering. Mention that HTTPS adds a TLS handshake. Show awareness of caching at the DNS and browser levels.

Senior/Staff: All of the above plus: HTTP/2 multiplexing, TLS 1.3 optimizations, CDN's role in the path, load balancer placement, connection pooling, the difference between hard and soft navigation (SPA vs server-rendered), service worker interception, and how each step can be optimized or fail.

The key is not memorizing every detail - it is demonstrating that you have a layered mental model and can zoom into any layer when asked.

Interactive animation: Where a page load goes - DNS, the TCP and TLS round trips, server work and rendering, each a target for optimization.

What Comes Next

The next topic examines the client-server model - the architectural pattern that underlies the request-response cycle you just traced. Understanding client-server relationships, and when peer-to-peer is the better alternative, provides the context for how networked applications are designed and built.

Exercise: Starter: Open your browser's developer tools (F12 or Cmd+Option+I), go to the "Network" tab, and load any website. Look at the first request - what are the request headers? What are the response headers? What is the status code? How large is the response body (look for "Content-Length" or the "Size" column)?

Intermediate: In the Network tab, look at the "Timing" or "Waterfall" view for the initial HTML request. You should see separate measurements for DNS Lookup, TCP Connection (labeled "Initial Connection"), TLS Handshake (labeled "SSL"), Waiting for Server Response (labeled "TTFB" - Time to First Byte), and Content Download. Which step takes the longest? Now load the same page again - which steps are eliminated by caching and connection reuse?

Advanced: Use curl -v https://www.example.com in a terminal to see the full connection process in text. The -v flag shows the TCP connection, TLS handshake (including certificate details and cipher negotiation), HTTP request headers, and response headers. Trace through the output and identify each step from this topic. What TLS version was negotiated? What cipher suite was selected? What HTTP version is in use?

Back to Computer Networking