What Really Happens When You Type a URL? A Deep Dive into the Full Stack

Preface

A few days ago I saw a popular interview question: what actually happens when you type a URL into a browser? Answering it thoroughly can involve almost everything you learned from the start of university, from digital circuits to networking protocols.

1. Hardware layer – from keyboard to CPU

When you press keys, the USB keyboard (a USB‑device) sends serial data over the USB bus to the USB controller on the APB bus. The controller raises an interrupt, which is propagated through the APB bridge to the AHB high‑speed bus, where the CPU receives the interrupt.

The CPU’s interrupt handler (bottom half) queues the interrupt, then the top half reads the characters via the USB driver, copying them into a memory buffer.

Interrupt flow: Keyboard → USB controller → APB bridge → CPU interrupt → bottom‑half handler → top‑half handler → driver → read data → CPU writes to memory.

2. Kernel layer to application layer

Assuming the program reads the URL with a C

scanf

call, the call blocks in kernel mode until the interrupt handler has placed the characters (including the Enter key) into the buffer. Then

read

copies the data from kernel space to user space, making the string available to the browser.

scanf → read system call → kernel blocks → data copied → user‑space receives characters.

3. Network request

After the browser has the URL string, it proceeds with the network stack to fetch the resource.

4. DNS resolution

The browser first checks the local hosts file; if the name is not found, it sends a DNS query (normally over UDP) to a DNS server, which may forward the request up the hierarchy until an authoritative server returns the IP address.

5. Preparing data transmission

With the IP address (e.g.,

https://www.baidu.com/

) the browser initiates a TCP connection. Because the local and remote IPs are on different subnets, the packet is sent to the default gateway (home router), which forwards it through successive routers using routing tables (often based on Dijkstra’s algorithm) until it reaches the destination server.

6. Establishing the connection

The first packet is the SYN segment of the TCP three‑way handshake. After the SYN‑ACK and final ACK, the TCP connection is established on both client and server (e.g., an Nginx process listening on port 80).

7. Transferring data

With the TCP connection in place, the browser sends an HTTP GET request (e.g.,

GET / HTTP/1.1

). Nginx matches the request to its configuration, reads the

index.html

file, and sends the file contents back over the same TCP connection.

Because HTTP is stateless, the connection is closed after the response is sent.

8. Rendering the page

The browser receives the HTML, parses the DOM, executes JavaScript, fetches linked CSS and images, and finally paints the page on the screen. Additional hardware such as the GPU may be involved for complex graphics.

Many details are omitted (ARP, other routing algorithms, Nginx request processing stages, possible reverse‑proxying, GPU acceleration, etc.), but the above outlines the full path from a typed URL to a rendered web page.