What happens after entering a URL in the browser?

Preface

If asked this question in an interview, the least technical answer would of course be: “After entering the URL, the browser finds the page on the internet and then renders it.” But if you say this when interviewing for an engineering position, the moment the words leave your mouth you might see an indescribable expression on the interviewer’s face… So this article is a bit of preparation, my notes after going through some courses and related materials.

The browser’s processes

Take Chrome, currently the browser with the largest market share, as an example. When you open the Google homepage and check Chrome dev, you can see multiple processes running:

The first thing we can conclude is that “the browser is multi-process”. As for why multi-process is used: in the older single-process browsers, all modules ran in the same process—network I/O, the Javascript runtime, page rendering, and so on. If anything went wrong in any one of them, the whole process would crash. There were also security issues: if some third-party plugin contained malicious code, it could easily release a virus or steal sensitive data (account passwords, etc.) from inside the browser.

Today’s browser process architecture has evolved to 5 processes:

• Browser Process
  • Mainly responsible for page display, user interaction, and child-process management. It also provides storage management (LocalStorage, etc.)
• Render Process
  • Responsible for rendering HTML, CSS, and Javascript into a page that the user can interact with. The layout engine Blink and the JS engine V8 both live in this process.
• GPU Process
  • Accelerates page drawing, 3D computation, etc.
• Network Process
  • Spun out from the Browser Process, responsible for loading network resources
• Plugin Process
  • All other plugins run in this process; it is optional. Splitting the plugin process out ensures that if a plugin crashes, the main process will not crash.
    

The journey of the data

On the internet, data is transmitted in the form of packets. So how do we ensure that packets are sent to the right place and that the data stays intact? Ensuring that packets reach the right place relies on IP and UDP, while data integrity relies on the TCP protocol.

IP: deliver the packet to the target server

In the real world, when we want to deliver an item to a different place, we rely on an address. The address in the computer world is the IP Address. Suppose we want to send data from host A to host B; we need to attach host B’s IP Address, along with some other information such as host A’s own IP, IP version, time-to-live, etc. (For details see wiki)

UDP: deliver the packet to the application

After the IP protocol delivers the data to host B, host B does not actually know whether this data is meant for the browser or for some other program. Adding the UDP protocol (User Datagram Protocol) attaches a UDP header to the packet that includes port information, so host B can use the port number to deliver the packet to the right program.

However, UDP cannot guarantee data integrity and provides no retransmission mechanism. Its advantage is speed, so UDP is well suited to scenarios that need fast transmission but are not strict about data integrity, such as live video streaming and interactive games.

TCP: deliver the data to the application intact

Besides also having a port in its header so the target host can route the packet to the right application (just like UDP), TCP (Transmission Control Protocol) has the following extra features:

• For lost data, TCP provides a retransmission mechanism
• TCP introduces a packet ordering mechanism, which is used to assemble out-of-order packets back into the correct file

The lifecycle of a TCP connection

1. Establishing a connection through a three-way handshake. The “three-way handshake” means that the client side and server side exchange a total of three packets to confirm that the connection has been established.
   • A: “Hey, can you hear me?”
   • B: “Yes I can hear you! Can you hear me?”
   • A: “I can hear you too, we can talk now.”
2. The data transmission phase. The client side receives the data sent from the server side, and at the same time checks for lost packets and reorders them into the correct file.
3. Closing the connection through a four-way handshake.

Answering “What happens after entering a URL in the browser?”

With the background above, we can now answer this question a little more professionally.

1. After a URL is entered into the browser, the Browser Process determines whether the string is a search keyword or a valid URL. If it is a search keyword, the Browser Process automatically composes a search URL. If it is a string that matches the URL rules, the Browser Process adds the protocol according to the rules to compose the full URL (e.g., youtube.com becomes https://www.youtube.com).
2. The Browser Process uses inter-process communication (IPC) to send the URL request to the Network Process, and the Network Process then sends the actual URL request.
3. Through DNS resolution, the correct IP address is found.
4. A TCP connection is established, and the Network Process starts to receive data.
5. After the Browser Process receives the data header from the Network Process, assuming what is received is an HTML document, the Browser Process makes the Render Process and the Network Process establish a data transmission pipe.
6. After the document transmission completes, the Render Process returns a “commit confirmation” message to the Browser Process (at this point the page is still blank).
7. The Render Process starts parsing the page and loading sub-resources, then paints the page.

ChangeLog

• 20221025 - init
• 20260501–translate by claude code

Ref

• Geek Time: 《Browser Principles and Practice》

• ← Previous Post
• Next Post →