How the Web Works: A Developer's Guide to Fundamentals

Intro

Let's be honest: talking about theoretical concepts like "How the Web Works" feels old-fashioned. Most of us would rather watch a tutorial on "Rebuilding Amazon in 1 Hour" or learn the newest, groundbreaking frontend library.

And while those tools are great, they have a flaw: they change.

The fundamentals do not.

I realized recently that many developers—some with 3 or 4 years of experience—are experts in tools but have no idea about the elements that actually make a website work. I can say this because I used to be one of them. I didn't think the "theory" mattered until I was asked to explain how the web works in an interview and realized I had no idea.

That experience taught me that knowing the underlying logic prevents you from being tied to just one framework or language. It gives you a stronger mental model of your work.

In this post, I'm going to skip the fluff and explain how the web works specifically for developers.

P.S. If you aren't a fan of reading, I recorded a video version of this. It was my first time editing so it's not perfect, but you can check it out YouTube Video.

---

1. Client-Server Model

The first thing we need to tackle is the Client-Server Model.

By nature, the web is divided; it is a team effort. Your browser cannot give you the desired website without a server, and vice versa.

Think of it this way: This is very different from an offline mobile app (like a Calculator or Notes app). In an offline app, all the resources, logic, and data are stored locally on your phone. Your phone is the only element required.

In the web world, however, we need two main elements to get the job done:

• The Client: Simply put, this is the device or software you use to access the web (like your laptop running Chrome or your phone running Safari).
• The Server: This is the computer where the website actually "lives" and stores its data.

This structure is known as Client-Server Architecture. (If you want to dive deeper into the academic side of this, you can read more here, but for now, let's stick to the practical side).

The Request-Response Cycle

So, how do these two talk to each other? They use a concept called Request-Response.

• The Request: The communication is always initiated by the Client. The browser says, "Hey Server, give me the files for example.com."
• The Response: The Server processes this and sends a message back: "Okay, here it is," or "Sorry, I can't find that."

It is crucial to remember that the Client must start the conversation. This makes sense if you think about it—the Server can't just force a website onto your screen and yell, "VISIT THIS NOW!" You have to ask for it first.

---

2. Finding the Server: DNS Lookup

As we established, websites live on servers. But is there just a single, known universal server for the whole web? No. There are millions of servers, and the server that hosts your website is different from the one that hosts mine.

Because of this, the browser needs to know the exact location of the website you are asking for.

The Problem: IP Addresses

Every device connected to the web has a unique address called an IP Address (Internet Protocol). This is the actual address where your website lives. Theoretically, if you want to access a website, you could type this number directly into your browser.

It looks something like this: 192.168.1.55 (for IPv4).

But here is the problem: That is impossible to remember. Imagine having to memorize a string of random numbers just to visit Google or Facebook.

The Solution: Domain Names & DNS

To solve this, we use Domain Names, which are the memorable, human-readable versions of IP addresses (like salehkamal.shop or google.com).

But computers don't understand words; they only understand numbers. This is where the DNS (Domain Name System) comes in. Think of the DNS server as the phonebook of the internet.

Here is what happens when you type a URL:

1. You type salehkamal.shop into your browser.
2. Your browser doesn't know where that is, so it sends a request to a DNS Server.
3. The DNS Server looks up the name in its database and converts it to the actual IP address.
4. It sends that IP address back to your browser, allowing the connection to begin.

---

3. The Handshake: Making the Connection

Now your browser has the server's exact address (the IP), but it can't just yell its request across the internet. It needs a reliable, structured way to send and receive data. This is a two-part process that involves two separate "handshakes": TCP for reliability and TLS for security.

Part 1: The TCP Handshake (Reliability)

Before any data (like your request for salehkamal.shop) can be exchanged, the client and server must agree on rules and ensure they are both ready to communicate. This is handled by TCP (Transmission Control Protocol) and is known as the Three-Way Handshake.

The goal of TCP is simple: guarantee delivery and order of packets. Since information on the web is broken down into small pieces (packets) and might arrive out of order, TCP makes sure they get put back together correctly.

Here is how the three-step connection works:

1. SYN (Synchronize): The Client says, "Hey Server, I want to talk! Are you ready?"
2. SYN-ACK (Synchronize-Acknowledge): The Server replies, "Yes, I'm ready! I got your message."
3. ACK (Acknowledge): The Client confirms, "Great, let's start sending data."

Once the server and client exchange these three packets, the TCP connection is established. They now have a reliable pipe to send raw data back and forth.

Part 2: The TLS/SSL Handshake (Security)

The TCP connection is reliable, but it's not yet secure. If you see a website with https:// (the vast majority of the modern web), it means an extra layer of encryption—the TLS (Transport Layer Security) layer—must be established on top of TCP. (You might still hear this called SSL, but TLS is the current standard).

The TLS Handshake is crucial for security because it ensures that only the client and the server can read the information being exchanged, preventing eavesdropping or tampering.

During this exchange, the two main things that happen are:

• Authentication: The server proves its identity (usually via a Digital Certificate) to the browser. This confirms that you are talking to the real salehkamal.shop and not a malicious imposter.
• Key Exchange: The client and server secretly agree on a unique session key. This key will be used to encrypt all the actual request and response data (like your login credentials or banking details) for the duration of your session.

Important: Once the TLS handshake is complete, your browser can finally wrap up its HTTP request and securely send it down the reliable, encrypted TCP pipe.

---

4. The Request: Speaking HTTP 🗣️

The TCP and TLS handshakes are complete, meaning we have a reliable and secure line open between the Client and the Server. But they need a language to talk in—something they both understand. That language is HTTP (Hypertext Transfer Protocol).

HTTP is an application-layer protocol that works within the Client-Server model. It's the standard for structuring the entire communication cycle.

The HTTP Request

When the browser needs a file, it sends an HTTP Request, which contains several key pieces of information. For example, if you are asking for the root (or index) page of your blog, the request would look something like this:

GET / HTTP/2
Host: salehkamal.shop
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept-Language: en-US,en;q=0.5

The first line is the most important:

• GET: This is the HTTP Method (or verb), telling the server what action the client wants to perform (e.g., GET means retrieve data, POST means submit data).
• /: This is the path to the resource the client wants. The single slash / refers to the index or root page.
• HTTP/2: This is the version of the protocol being used.

The lines that follow (Host, User-Agent, etc.) are the Request Headers, providing context about the request and the client (the browser).

The HTTP Response

Once the server receives the request, it processes the request, locates the requested file (e.g., index.html), and sends an HTTP Response back to the client.

The response always starts with a Status Code and its corresponding text, followed by Response Headers, and finally, the actual data (the body).

A successful response would look something like this:

HTTP/2 200 OK
Date: Mon, 01 Dec 2025 15:43:55 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 4567

<!DOCTYPE html>
<html>
   <head>
       <title>Welcome to Salehkamal.shop</title>
   ...

The key piece here is the Status Code:

• 200 OK: This code tells the browser, "Success! I found the file you asked for, and here it is."
• Other common codes are 404 Not Found (meaning the server couldn't locate the file) or 301 Moved Permanently.

The browser then takes the data found after the Response Headers (the HTML, CSS, and JavaScript) and begins the final step of rendering the page.

---

Conclusion: Putting It All Together

We started this journey by acknowledging that learning the fundamentals can feel old-fashioned compared to the latest shiny framework. But look at everything we just covered—from the moment you typed in that URL, we tracked five major steps required just to display one page:

1. The Architecture: We established the need for the Client-Server Model, where your browser and a remote computer cooperate.
2. The Address: We used DNS Lookup to translate the human-readable domain name (like salehkamal.shop) into the machine-readable IP Address.
3. The Connection: We performed two crucial handshakes: TCP for reliable data transfer and TLS for securing the connection.
4. The Language: We structured the conversation using HTTP, sending a Request (e.g., GET /) and receiving a Response with the vital 200 OK status code.
5. The Render: (The implied final step, where the browser takes the returned HTML and builds the page.)

Key Takeaway: Understanding this flow doesn't just make you a better developer; it gives you the mental model to debug network issues, optimize load times, and understand why certain frameworks behave the way they do. When a new technology comes out tomorrow, the principles of DNS, TCP, and HTTP will remain the same.

---

Let's Keep the Conversation Going

I hope this deep dive demystifies the complexity of the web and inspires you to look past the surface-level tools. This is a massive topic, and there are countless details we could still explore, from caching headers to the specific rendering pipeline.

What part of this process surprised you the most? Do you have any go-to tips for optimizing any of these steps?

I'm keen to hear your thoughts and insights! Share your experience and let's discuss this topic further in the comments section below.