Webbo3 Frontend Development · Month 1 · Lesson 3
How the Internet Actually Works
Learn how the internet works by understanding DNS, HTTP request and response, to explain every step from typing a URL to a page appearing.
When you type a website's address into your browser and press enter, have you ever wondered what happens next? How does your browser know where to find the website, and how does it get the website's content to display on your screen? As a beginner in frontend development, understanding this process is crucial because it will help you identify and fix problems when they arise. For instance, have you ever encountered a "404" or "500" error while browsing the internet? These errors can be frustrating, but knowing what they mean and how they occur can help you troubleshoot issues with your own website. By the end of this lesson, you will be able to explain in plain language every step that happens between typing a URL and a webpage appearing on your screen. You will understand what happens when you enter a website's address, how your browser communicates with the website's server, and how the website's content is transmitted back to your browser. This knowledge will also help you understand what 404 and 500 errors are, and what they really mean. You will be able to identify the source of these errors and take steps to fix them, whether you are browsing the internet or building your own website. The process of how the internet works may seem complex, but it can be broken down into simple, manageable steps. In this lesson, we will take a closer look at each of these steps, and by the end, you will have a clear understanding of the entire process. You will be able to explain it to others, and more importantly, you will be able to use this knowledge to build and troubleshoot your own websites. With this foundation, you will be better equipped to learn more advanced topics in frontend development and become a proficient web developer.
What you need before starting
Everything from the previous lesson, and the project folder you have been building in. Work along in your own editor as you read — this lesson is written to be typed, not skimmed.
The Client-Server Model
A Concrete Analogy
The client-server model is like ordering food at a restaurant. You, the client, sit at a table and look at a menu. When you want something, you tell the waiter, who takes your order and brings it to the kitchen. The kitchen, which is like the server, then prepares your food according to your order. Once your food is ready, the waiter brings it back to you. In this scenario, you never actually go into the kitchen to make your own food. Instead, you send a request (your order) to the kitchen, and they send a response (your prepared food) back to you. In the same way, when you type a website's address into your browser, your computer (the client) sends a request to the website's server. The server then sends a response back to your computer, which displays the website's content.
HTTP versus HTTPS
What the S Actually Protects
HTTP stands for Hypertext Transfer Protocol, and it's the way that computers communicate with each other on the internet. However, when you use HTTP, your requests and responses are sent in plain text, which means that anyone who intercepts them can read them. This is a security risk, especially when you're sending sensitive information like passwords or credit card numbers. HTTPS, on the other hand, stands for Hypertext Transfer Protocol Secure. The S at the end means that your requests and responses are encrypted, which makes it much harder for someone to intercept and read them. The encryption is like a secret code that only the client and server can understand. When you use HTTPS, your browser will display a lock icon in the address bar, which indicates that the connection is secure. This is especially important when you're entering sensitive information, like when you're shopping online or logging into your bank account.

How a Browser Parses HTML and Paints a Page
The Parsing Process
When a browser receives an HTML response from a server, it has to parse the HTML code to understand what it means. HTML stands for Hypertext Markup Language, and it's used to create the structure and content of a web page. Here's an example of a simple HTML page:
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Welcome to my page</h1>
<p>This is a paragraph of text.</p>
</body>
</html>Let's break down what each part of this code does:
- The `<html>` tag is the root element of the HTML document.
- The `<head>` tag contains metadata about the document, like the title.
- The `<title>` tag sets the title of the page, which appears in the browser's title bar.
- The `<body>` tag contains the content of the HTML document.
- The `<h1>` tag is a heading element, which displays the text in a large font.
- The `<p>` tag is a paragraph element, which displays the text in a normal font.
A common mistake that beginners make is forgetting to close their HTML tags. For example, if you forget to close the `<html>` tag, the browser may not be able to parse the HTML correctly, which can cause the page to display incorrectly. To spot this mistake, look for any opening tags that don't have a corresponding closing tag.
Painting the Page
After the browser has parsed the HTML, it has to paint the page, which means it has to render the content on the screen. The browser uses the HTML structure and any associated CSS (Cascading Style Sheets) to determine how to layout the content. The browser will also make any necessary requests for additional resources, like images or JavaScript files, and wait for those requests to complete before finishing the painting process. This is why it's often a good idea to optimize your images and minimize the number of requests your page makes, as this can improve the page's loading time and overall performance.
What DNS Does and Why google.com is Not an Address
Understanding DNS Basics
When you type a website's name into your browser, like google.com, it doesn't directly go to that address. This is because google.com is not an actual address that computers can understand. Instead, it's a human-friendly name. Behind the scenes, there's a system called the Domain Name System (DNS) that translates these names into actual computer addresses, known as IP addresses.
For example, the IP address for google.com might be 216.58.194.174. This is what your computer actually uses to connect to Google's servers. The DNS acts like a phonebook, where you look up someone's name to find their phone number. In this case, you look up google.com to find its IP address.
A Simple DNS Lookup Example
To see this in action, you can use a command line tool like `dig` on Linux or macOS, or `nslookup` on Windows. Here's how you might use `dig` to find the IP address of google.com:
dig google.comThis command will output a lot of information, but the important part is the IP address listed under the "A" record section. This is the actual address your computer uses to connect to google.com.
A common mistake beginners make is thinking that the website's name is the actual address. To spot this, look for instances where someone is trying to use a domain name directly in a context where an IP address is required. For example, trying to use "google.com" as the host in a socket connection instead of the IP address.
Status Codes: Understanding the Server's Response
Status Code 200: OK
When you request a webpage, the server responds with a status code. The most common status code is 200, which means "OK". This indicates that the server has found the resource you requested and is returning it to you. For example, if you request the homepage of google.com, the server will return the HTML of the page with a status code of 200.
Status Code 301: Moved Permanently
A 301 status code means that the resource you requested has been permanently moved to a new location. The server will include the new location in its response, and your browser will automatically redirect you to the new location. For example, if you request a webpage that has been moved to a new domain, the server might respond with a 301 status code and the new domain.
Status Code 404: Not Found
A 404 status code means that the server cannot find the resource you requested. This might happen if you type in a URL incorrectly or if the webpage has been deleted. For example, if you request a webpage that does not exist on google.com, the server will respond with a 404 status code.
Status Code 500: Internal Server Error
A 500 status code means that there is an error on the server's side. This might happen if the server is experiencing technical difficulties or if there is a problem with the code of the webpage. For example, if you request a webpage that has a bug in its code, the server might respond with a 500 status code.
To see these status codes in action, you can use a tool like `curl` from the command line. Here's an example of how you might use `curl` to request the google.com homepage and see the status code:
curl -I https://www.google.comThis command will output the headers of the server's response, including the status code. A common mistake beginners make is not checking the status code of a request. To spot this, look for instances where someone is assuming that a request was successful without checking the status code. For example, trying to parse the response of a request without checking if the status code is 200.
In a real-world scenario, you might use a programming language like JavaScript to make a request to a server and handle the response based on the status code. Here's an example using the `fetch` API:
fetch('https://www.google.com')
.then(response => {
if (response.ok) {
return response.text();
} else {
throw new Error('Failed to fetch page');
}
})
.then(text => console.log(text))
.catch(error => console.error(error));This code makes a request to google.com and checks the status code of the response. If the status code is 200, it logs the response text to the console. If the status code is not 200, it throws an error.
IP Addresses and Why Every Device Needs One
What is an IP Address?
An IP address, or Internet Protocol address, is a unique numerical label assigned to each device connected to a computer network that uses the Internet Protocol to communicate. It's like a street address for your device, allowing it to be identified and located by other devices on the network. Every device needs an IP address to communicate with other devices and send or receive data.
For example, when you type a website's URL into your browser, your device uses the website's IP address to locate its server and send a request for the webpage. Without an IP address, your device wouldn't be able to find the server or send the request.
IP Address Format
An IP address is typically written in dotted decimal notation, with four numbers separated by dots. Each number can range from 0 to 255, such as 192.0.2.1. This format is used to identify a device's IP address and to route data packets between devices.

The Full Request-Response Lifecycle Step by Step
Step 1: Sending a Request
When you type a URL into your browser, your device sends a request to the server associated with that URL. This request includes the URL, the type of request (e.g., GET, POST), and any additional data or headers.
For example, let's say you want to retrieve the HTML content of the Webbo3 Academy homepage. Your browser would send a GET request to the server with the URL http://webbo3.academy.
Step 2: DNS Lookup
Before your device can send the request to the server, it needs to resolve the domain name (webbo3.academy) to an IP address. This is done through a DNS (Domain Name System) lookup, which involves querying a DNS server to retrieve the IP address associated with the domain name.
Step 3: Establishing a Connection
Once your device has the IP address of the server, it establishes a connection to the server using the IP address and a port number (typically port 80 for HTTP). This connection allows your device to send the request to the server.
Step 4: Receiving a Response
After the server receives the request, it processes it and sends a response back to your device. The response includes the requested data (e.g., the HTML content of the webpage), as well as any additional headers or metadata.
Here's an example of how you can use JavaScript to send a GET request to a server and retrieve the response:
const xhr = new XMLHttpRequest();
xhr.open('GET', 'http://webbo3.academy', true);
xhr.onload = function() {
if (xhr.status === 200) {
console.log(xhr.responseText);
} else {
console.log('Error:', xhr.statusText);
}
};
xhr.send();This code creates an XMLHttpRequest object, opens a GET request to the specified URL, and sets an event handler to process the response when it's received. When the response is received, it logs the response text to the console if the status code is 200 (OK), or logs an error message if the status code is not 200.
A common mistake beginners make when working with requests and responses is not checking the status code of the response. This can lead to unexpected behavior or errors if the response is not what was expected. To spot this mistake, look for code that assumes the response will always be successful, without checking the status code or handling potential errors.
Do this now
This exercise will help you understand the flow of requests when a website is loaded. It should take around 10-15 minutes to complete, depending on your internet speed and familiarity with the DevTools. Please follow these steps:
- Open Google Chrome or any other browser that has DevTools, on your laptop.
- Press F12 or right-click on any webpage and select "Inspect" to open DevTools.
- Switch to the Network tab.
- Make sure the "Record" button is on (it looks like a circle or a dot), and then reload the webpage or load any website, for example, https://www.example.com.
- In the Network tab, look for the first request, which should be an HTML file (it usually has a .html extension). Note down its file name and status code.
- Look for the next three requests after the HTML file. These could be CSS, JavaScript, or image files. Note down their file names.
This exercise will give you insight into how the browser fetches files to display a webpage.
How to know you got it right
To verify that you completed the exercise correctly, go through this checklist:
- You have DevTools open with the Network tab active.
- You loaded a website and saw a list of requests in the Network tab.
- You identified the first HTML request and noted down its status code (it should be 200, which means "OK").
- You noted down the names of three other files that were fetched after the HTML file.
If you can confirm all these points, then you have successfully completed the exercise and taken the first step in understanding how the internet actually works.
Common mistakes
- Confusing the internet with the world wide web: This looks like saying "I'm on the internet" when accessing a website. It happens because beginners don't understand the difference between the internet (a network of computers) and the web (a system of interlinked hypertext documents). The fix is to learn the basic definition of each term.
- Thinking that data travels instantly: This looks like expecting a video to load immediately. It happens because beginners don't consider the physical distance data travels. The fix is to understand that data travels at a finite speed, approximately 299,792,458 meters per second.
- Believing that the internet is a single, centralized system: This looks like thinking that one company or government controls the entire internet. It happens because beginners don't grasp the decentralized nature of the internet. The fix is to learn about the network of interconnected networks that make up the internet.
- Not understanding the role of IP addresses: This looks like not knowing how devices identify each other online. It happens because beginners don't learn about IP addresses and their function. The fix is to understand that IP addresses are unique identifiers for devices on a network, like a street address for a house.
Questions students ask
- What is the difference between a website and a web page? A website is a collection of related web pages, while a web page is a single document with its own URL.
- How does my computer find a website? Your computer uses the website's domain name to look up its IP address, then sends a request to that IP address.
- What happens when I enter a URL into my browser? Your browser sends a request to the server associated with the URL, which then sends the requested webpage back to your browser.
Quick recap: The Client-Server Model · HTTP versus HTTPS · How a Browser Parses HTML and Paints a Page · What DNS Does and Why google.com is Not an Address · Status Codes: Understanding the Server's Response · IP Addresses and Why Every Device Needs One · The Full Request-Response Lifecycle Step by Step
Next lesson: HTML Fundamentals: Your First Real Page.