Ensiklopedia VibeKoding: Computer System Overview: From Boot to Web Visit.Ensiklopedia VibeKoding: Computer System Overview: From Boot to Web Visit.
Have you ever wondered what happens between pressing your computer's power button and finally seeing a webpage in your browser? This process is like a relay race — hardware powers up and wakes the firmware, the firmware finishes checking and passes the baton to the operating system, the OS prepares the environment so the browser can run, and the browser reaches across the network to retrieve a webpage from a distant server. Every step depends on the successful completion of the previous one. If any runner drops the baton, subsequent steps cannot proceed. Understanding this complete chain will help you build a holistic understanding of computer systems and is an essential step on the path to becoming a full-stack engineer.Have you ever wondered what happens between pressing your computer's power button and finally seeing a webpage in your browser? This process is like a relay race — hardware powers up and wakes the firmware, the firmware finishes checking and passes the baton to the operating system, the OS prepares the environment so the browser can run, and the browser reaches across the network to retrieve a webpage from a distant server. Every step depends on the successful completion of the previous one. If any runner drops the baton, subsequent steps cannot proceed. Understanding this complete chain will help you build a holistic understanding of computer systems and is an essential step on the path to becoming a full-stack engineer.
What will you learn?What will you learn?
This article guides you through the five stages from pressing the power button to seeing a webpage, in the actual order events occur:This article guides you through the five stages from pressing the power button to seeing a webpage, in the actual order events occur:
Each step builds on the previous one, and none can be skipped.Each step builds on the previous one, and none can be skipped.
------
When you press the power button, the Power Supply Unit (PSU) starts working, converting alternating current (220V) into direct current (12V, 5V, 3.3V, etc.) to power all hardware components.When you press the power button, the Power Supply Unit (PSU) starts working, converting alternating current (220V) into direct current (12V, 5V, 3.3V, etc.) to power all hardware components.
CODE Power button → Power Supply Unit (PSU) → DC output → Powers motherboard components
Once the power stabilizes, the motherboard chipset begins working. It's like the computer's "head dispatcher," responsible for coordinating all hardware components.Once the power stabilizes, the motherboard chipset begins working. It's like the computer's "head dispatcher," responsible for coordinating all hardware components.
After receiving the reset signal, the CPU clears all internal registers and cache, and starts executing instructions from a preset address. This address typically points to the BIOS/UEFI chip.After receiving the reset signal, the CPU clears all internal registers and cache, and starts executing instructions from a preset address. This address typically points to the BIOS/UEFI chip.
------
> First relay leg complete At this point, the hardware-level work is done: the power supply converted AC into stable DC, the motherboard chipset was awakened and began coordinating components, and the CPU completed its reset, cleared registers, and is ready to execute its first instruction.> First relay leg complete At this point, the hardware-level work is done: the power supply converted AC into stable DC, the motherboard chipset was awakened and began coordinating components, and the CPU completed its reset, cleared registers, and is ready to execute its first instruction.
>>
> But note — at this moment, the CPU is like a "newborn baby just opening its eyes." It can execute instructions but knows nothing about its environment: how much memory is installed? Is the graphics card working? Where is the hard drive? Which device should it boot the OS from? The CPU can't answer these questions itself.> But note — at this moment, the CPU is like a "newborn baby just opening its eyes." It can execute instructions but knows nothing about its environment: how much memory is installed? Is the graphics card working? Where is the hard drive? Which device should it boot the OS from? The CPU can't answer these questions itself.
>>
> So the first instruction the CPU executes after reset is a jump to a fixed memory address — this address points to the BIOS/UEFI firmware chip permanently soldered on the motherboard. From this moment on, control passes from pure hardware to firmware. BIOS/UEFI's mission is clear: check that all hardware is functioning properly, then find and boot the operating system. This is the second leg of the relay.> So the first instruction the CPU executes after reset is a jump to a fixed memory address — this address points to the BIOS/UEFI firmware chip permanently soldered on the motherboard. From this moment on, control passes from pure hardware to firmware. BIOS/UEFI's mission is clear: check that all hardware is functioning properly, then find and boot the operating system. This is the second leg of the relay.
------
> Second relay leg complete BIOS/UEFI has successfully fulfilled its three missions: confirmed through POST that memory, graphics card, keyboard, and other hardware are all working normally; initialized each hardware component's operating mode; and found the boot sector on the hard drive according to the boot order.> Second relay leg complete BIOS/UEFI has successfully fulfilled its three missions: confirmed through POST that memory, graphics card, keyboard, and other hardware are all working normally; initialized each hardware component's operating mode; and found the boot sector on the hard drive according to the boot order.
>>
> But BIOS/UEFI's role ends here — it's essentially a "health examiner + dispatcher." It can check if hardware is healthy and decide which device to boot from, but it won't manage your files, run your applications, or display a beautiful desktop. These complex tasks require a more powerful software to take over — the operating system.> But BIOS/UEFI's role ends here — it's essentially a "health examiner + dispatcher." It can check if hardware is healthy and decide which device to boot from, but it won't manage your files, run your applications, or display a beautiful desktop. These complex tasks require a more powerful software to take over — the operating system.
>>
> The handoff is very specific: BIOS/UEFI reads the bootloader code from the first sector of the hard drive (boot sector), loads it into memory, and tells the CPU to jump to this code and begin execution. From this moment, control officially passes from firmware to the OS bootloader. The bootloader will gradually load the OS kernel, start system services, and ultimately present the familiar desktop. The most complex leg of this chain has begun.> The handoff is very specific: BIOS/UEFI reads the bootloader code from the first sector of the hard drive (boot sector), loads it into memory, and tells the CPU to jump to this code and begin execution. From this moment, control officially passes from firmware to the OS bootloader. The bootloader will gradually load the OS kernel, start system services, and ultimately present the familiar desktop. The most complex leg of this chain has begun.
------
> Third relay leg complete The operating system has fully started, and the desktop is displayed. Let's review what this leg accomplished: the bootloader read the kernel from disk, the kernel took control of the CPU and memory, system services started one by one (networking, audio, security center...), and finally the graphical interface rendered the desktop.> Third relay leg complete The operating system has fully started, and the desktop is displayed. Let's review what this leg accomplished: the bootloader read the kernel from disk, the kernel took control of the CPU and memory, system services started one by one (networking, audio, security center...), and finally the graphical interface rendered the desktop.
>>
> At this point, the OS is like a building with water and electricity connected and property management moved in — process management allocates rooms to each resident (program), memory management allocates space, the file system manages the warehouse, and the network protocol stack handles external communications. These "public services" are the infrastructure all applications run on. Without them, no program could start.> At this point, the OS is like a building with water and electricity connected and property management moved in — process management allocates rooms to each resident (program), memory management allocates space, the file system manages the warehouse, and the network protocol stack handles external communications. These "public services" are the infrastructure all applications run on. Without them, no program could start.
>>
> Now you want to go online, so you double-click the browser icon on the desktop. Behind this simple action, the OS must do a series of tasks: find where the browser's executable file is on the hard drive, create an independent process for it, allocate memory space, and load the program code... This is a direct demonstration of the OS's "process management" capability. Next, let's see how the browser is launched.> Now you want to go online, so you double-click the browser icon on the desktop. Behind this simple action, the OS must do a series of tasks: find where the browser's executable file is on the hard drive, create an independent process for it, allocate memory space, and load the program code... This is a direct demonstration of the OS's "process management" capability. Next, let's see how the browser is launched.
When you double-click the browser icon, the operating system will:When you double-click the browser icon, the operating system will:
.exe (Windows) or executable fileFind the executable file: Based on file associations, locate the browser's .exe (Windows) or executable fileCODE Browser launch process: ┌─────────────────────────────────────┐ │ 1. Double-click icon │ │ 2. OS finds browser executable │ │ 3. Create browser process │ │ 4. Load browser code into memory │ │ 5. Initialize modules (rendering, │ │ networking, JS engine) │ │ 6. Display browser window │ └─────────────────────────────────────┘
A modern browser is a complex "operating system," primarily composed of:A modern browser is a complex "operating system," primarily composed of:
| Module | Function |
|---|---|
| User Interface | Address bar, tabs, bookmarks, etc. |
| Browser Engine | Coordinates UI and rendering engine |
| Rendering Engine | Parses HTML/CSS and displays webpages |
| JavaScript Engine | Executes JavaScript code |
| Networking Module | Sends HTTP requests |
| UI Backend | Draws basic UI components |
| Data Storage | Cookies, LocalStorage, etc. |
------
> Fourth relay leg complete The browser has launched successfully. The OS created an independent process for it, allocated memory space, and the browser's internal modules have all initialized: the rendering engine is ready to parse HTML/CSS, the JavaScript engine is ready to execute scripts, and the networking module is ready to send and receive data.> Fourth relay leg complete The browser has launched successfully. The OS created an independent process for it, allocated memory space, and the browser's internal modules have all initialized: the rendering engine is ready to parse HTML/CSS, the JavaScript engine is ready to execute scripts, and the networking module is ready to send and receive data.
>>
> You can think of the browser at this moment as a car that's been started — the engine is running, the dashboard is lit, and the navigation system is ready. But the car is still parked, because the driver (you) hasn't told it "where to go." The browser window is blank, the cursor blinks in the address bar, waiting for your input.> You can think of the browser at this moment as a car that's been started — the engine is running, the dashboard is lit, and the navigation system is ready. But the car is still parked, because the driver (you) hasn't told it "where to go." The browser window is blank, the cursor blinks in the address bar, waiting for your input.
>>
> When you type https://www.example.com in the address bar and press Enter, a journey spanning the entire internet begins. The browser's networking module takes over this request: first parsing the URL structure, then translating the domain name into an IP address via DNS, establishing a TCP connection with the distant server across the network, negotiating an encrypted channel, sending an HTTP request, waiting for the server's response, and finally passing the received HTML/CSS/JS code to the rendering engine to draw the webpage you see. This is the leg with the most steps and the richest set of protocols — and the one Web developers need to understand most.> When you type https://www.example.com in the address bar and press Enter, a journey spanning the entire internet begins. The browser's networking module takes over this request: first parsing the URL structure, then translating the domain name into an IP address via DNS, establishing a TCP connection with the distant server across the network, negotiating an encrypted channel, sending an HTTP request, waiting for the server's response, and finally passing the received HTML/CSS/JS code to the rendering engine to draw the webpage you see. This is the leg with the most steps and the richest set of protocols — and the one Web developers need to understand most.
A URL (Uniform Resource Locator) is the address of a resource. Just like a real-world address, it locates resources on the internet.A URL (Uniform Resource Locator) is the address of a resource. Just like a real-world address, it locates resources on the internet.
CODE URL structure: ┌─────────────────────────────────────────────────────────┐ │ https:// │ www.example.com │ /path/to/page │ ?query=1 │ │ Protocol │ Domain │ Path │ Query │ └─────────────────────────────────────────────────────────┘
When you access https://www.example.com, here's what happens:When you access https://www.example.com, here's what happens:
The browser first parses the URL, extracting the protocol, domain, path, and other information.The browser first parses the URL, extracting the protocol, domain, path, and other information.
CODE URL parsing process: https://www.example.com/index.html ↓ Protocol: https Domain: www.example.com Path: /index.html
Computers access servers over the network using IP addresses (e.g., 93.184.216.34), not domain names. So the domain name must be converted to an IP address. This process is called DNS resolution.Computers access servers over the network using IP addresses (e.g., 93.184.216.34), not domain names. So the domain name must be converted to an IP address. This process is called DNS resolution.
CODE DNS resolution flow: ┌─────────────────────────────────────────────────────────┐ │ Browser cache → hosts file → Local DNS cache → DNS server │ └─────────────────────────────────────────────────────────┘ Actual process: 1. Browser checks cache (visited recently?) 2. Operating system checks DNS cache 3. Send query request to DNS server 4. DNS server returns IP address
After obtaining the IP address, the browser needs to establish a TCP connection with the server. TCP is a transport layer protocol that ensures reliable data transmission.After obtaining the IP address, the browser needs to establish a TCP connection with the server. TCP is a transport layer protocol that ensures reliable data transmission.
CODE TCP three-way handshake: ┌─────────────────────────────────────────────────────────┐ │ Client → Server: SYN (synchronization request) │ │ Server → Client: SYN-ACK (acknowledge and synchronize) │ │ Client → Server: ACK (acknowledgment) │ │ ↓ │ │ Connection established! │ └─────────────────────────────────────────────────────────┘
For HTTPS, a TLS/SSL handshake is also needed to establish an encrypted channel.For HTTPS, a TLS/SSL handshake is also needed to establish an encrypted channel.
After the connection is established, the browser sends an HTTP request to the server:After the connection is established, the browser sends an HTTP request to the server:
CODE HTTP request format: ┌─────────────────────────────────────────────────────────┐ │ GET /index.html HTTP/1.1 │ │ Host: www.example.com │ │ User-Agent: Mozilla/5.0... │ │ Accept: text/html │ │ │ │ (empty line) │ └─────────────────────────────────────────────────────────┘
Common HTTP methods:Common HTTP methods:
| Method | Meaning | Purpose |
|---|---|---|
| GET | Retrieve a resource | Browsing webpages |
| POST | Submit data | Login, form submission |
| PUT | Upload a resource | File upload |
| DELETE | Delete a resource | Data deletion |
After the server (typically a web server like Nginx or Apache) receives the request:After the server (typically a web server like Nginx or Apache) receives the request:
CODE Server processing flow: ┌─────────────────────────────────────────────────────────┐ │ 1. Web server receives request (Nginx/Apache) │ │ 2. Route to the appropriate handler based on path │ │ 3. Execute backend code (API, business logic) │ │ 4. Query database if needed, retrieve data │ │ 5. Assemble response (HTML/JSON/CSS/JS) │ │ 6. Return HTTP response │ └─────────────────────────────────────────────────────────┘
The server returns an HTTP response containing a status code, response headers, and response body:The server returns an HTTP response containing a status code, response headers, and response body:
CODE HTTP response format: ┌─────────────────────────────────────────────────────────┐ │ HTTP/1.1 200 OK │ │ Content-Type: text/html │ │ Content-Length: 1234 │ │ │ │ <!DOCTYPE html> │ │ <html>...</html> │ └─────────────────────────────────────────────────────────┘
Common status codes:Common status codes:
| Status Code | Meaning |
|---|---|
| 200 | Success |
| 301/302 | Redirect |
| 404 | Resource not found |
| 500 | Server error |
After receiving the response, the browser begins rendering the page:After receiving the response, the browser begins rendering the page:
CODE Browser rendering process: ┌─────────────────────────────────────────────────────────┐ │ 1. HTML parsing → DOM tree │ │ 2. CSS parsing → Style rules │ │ 3. DOM + CSS → Render tree │ │ 4. Layout calculation → Size and position of elements │ │ 5. Paint → Pixels displayed on screen │ │ 6. Composite → Multiple layers merged for display │ └─────────────────────────────────────────────────────────┘
------
> Final relay leg complete The webpage is finally displayed on your screen! Let's review how many stages this last leg went through: the browser parsed the URL to extract the protocol and domain, translated the domain into an IP address through layered DNS queries, established a reliable connection with the server via TCP three-way handshake, built an encrypted channel through TLS handshake, sent an HTTP request, the server processed business logic, queried the database, assembled response data and returned it, and finally the browser's rendering engine parsed the HTML into a DOM tree, computed CSS into style rules, merged both into a render tree, calculated layout, and painted pixels onto the screen one by one.> Final relay leg complete The webpage is finally displayed on your screen! Let's review how many stages this last leg went through: the browser parsed the URL to extract the protocol and domain, translated the domain into an IP address through layered DNS queries, established a reliable connection with the server via TCP three-way handshake, built an encrypted channel through TLS handshake, sent an HTTP request, the server processed business logic, queried the database, assembled response data and returned it, and finally the browser's rendering engine parsed the HTML into a DOM tree, computed CSS into style rules, merged both into a render tree, calculated layout, and painted pixels onto the screen one by one.
>>
> Now let's zoom out and review the full picture of this relay race from start to finish. From the moment the power button is pressed: current wakes the hardware (1st leg) → firmware checks devices and finds the boot disk (2nd leg) → the OS boots completely from kernel to desktop (3rd leg) → the browser is launched as an application by the OS (4th leg) → network requests cross the internet to retrieve data and render it as a page (5th leg). Five legs connected end to end, each building on the previous one's results. Without any single leg, you couldn't see the webpage in front of you.> Now let's zoom out and review the full picture of this relay race from start to finish. From the moment the power button is pressed: current wakes the hardware (1st leg) → firmware checks devices and finds the boot disk (2nd leg) → the OS boots completely from kernel to desktop (3rd leg) → the browser is launched as an application by the OS (4th leg) → network requests cross the internet to retrieve data and render it as a page (5th leg). Five legs connected end to end, each building on the previous one's results. Without any single leg, you couldn't see the webpage in front of you.
>>
> Next, let's use a complete flowchart to connect these five stages and visualize their dependencies.> Next, let's use a complete flowchart to connect these five stages and visualize their dependencies.
Let's connect the entire process:Let's connect the entire process:
CODE Complete process from pressing power to visiting a website: ┌──────────────────────────────────────────────────────────────────┐ │ 1. Press Power │ │ └── Power startup → Motherboard wake-up → CPU reset → Execute BIOS/UEFI │ ├──────────────────────────────────────────────────────────────────┤ │ 2. BIOS/UEFI Boot │ │ └── Hardware self-test → Find boot device → Read bootloader │ ├──────────────────────────────────────────────────────────────────┤ │ 3. Operating System Boot │ │ └── Bootloader → Load kernel → Start services → Display desktop │ ├──────────────────────────────────────────────────────────────────┤ │ 4. Open Browser │ │ └── Double-click icon → Create process → Load program → Display window │ ├──────────────────────────────────────────────────────────────────┤ │ 5. Access URL │ │ └── URL parsing → DNS resolution → TCP connection → HTTP request │ │ → Server processing → HTTP response → Browser rendering → Display page │ └──────────────────────────────────────────────────────────────────┘
------
> Looking at the entire chain, you'll notice an interesting pattern: each stage solves completely different problems, and the technical domains involved are entirely different. The 1st leg is in the domain of electrical engineering — power conversion, circuit design, signal transmission; the 2nd leg belongs to firmware programming — using low-level code to directly control hardware; the 3rd leg is the world of operating systems — process scheduling, memory management, file systems, which are core topics in computer science; the 4th leg involves application development — how to design a complex software architecture like a browser; and the 5th leg spans computer networking and frontend development — from network protocols like DNS, TCP/IP, and HTTP to HTML/CSS/JS parsing and rendering.> Looking at the entire chain, you'll notice an interesting pattern: each stage solves completely different problems, and the technical domains involved are entirely different. The 1st leg is in the domain of electrical engineering — power conversion, circuit design, signal transmission; the 2nd leg belongs to firmware programming — using low-level code to directly control hardware; the 3rd leg is the world of operating systems — process scheduling, memory management, file systems, which are core topics in computer science; the 4th leg involves application development — how to design a complex software architecture like a browser; and the 5th leg spans computer networking and frontend development — from network protocols like DNS, TCP/IP, and HTTP to HTML/CSS/JS parsing and rendering.
>>
> This also explains why a "full-stack engineer" needs broad knowledge: every line of frontend code you write must travel through this entire chain before reaching the user. Understanding each link helps you quickly locate problems — is it a network layer issue? A server problem? Or a browser rendering issue?> This also explains why a "full-stack engineer" needs broad knowledge: every line of frontend code you write must travel through this entire chain before reaching the user. Understanding each link helps you quickly locate problems — is it a network layer issue? A server problem? Or a browser rendering issue?
>>
> The knowledge map below organizes these technical domains and points the way for your further learning.> The knowledge map below organizes these technical domains and points the way for your further learning.
The knowledge domains covered in this chapter:The knowledge domains covered in this chapter:
CODE Computer System Overview ├── Hardware Basics │ ├── Power Supply (PSU) │ ├── Motherboard Chipset │ └── CPU ├── BIOS/UEFI │ ├── POST Self-Test │ ├── Boot Order │ └── Bootloader ├── Operating System │ ├── Kernel │ ├── System Services │ └── Desktop Environment ├── Applications │ ├── Process Management │ └── Program Loading └── Network Communication ├── DNS Resolution ├── TCP/IP Protocol ├── HTTP Protocol └── Browser Rendering
If you want to dive deeper into any stage, you can continue learning: - From Transistors to CPU: Understand computer hardware fundamentals - Operating Systems (Processes/Memory/File Systems): Deepen your understanding of operating systems - Computer Networks: Deepen your understanding of network protocolsIf you want to dive deeper into any stage, you can continue learning: - From Transistors to CPU: Understand computer hardware fundamentals - Operating Systems (Processes/Memory/File Systems): Deepen your understanding of operating systems - Computer Networks: Deepen your understanding of network protocols