How the Internet Actually Works: Understanding Client-Server Architecture with Real Code

The Big Picture: What Happens When You Visit a Website?

Every time you type a URL into your browser and hit Enter, a surprisingly complex chain of events kicks off in the background. Most people never think about it, but understanding this process is the foundation of everything we'll cover in this guide.

Let's walk through what actually happens when you visit something like https://www.example.com.

Step 1: Your browser looks up the address

Your computer doesn't understand domain names like www.example.com. It needs an IP address, which is basically a numerical home address for a server somewhere in the world. To get it, your browser contacts a DNS (Domain Name System) server, which works like a giant phone book for the internet. It translates the human-friendly name into something like 93.184.216.34.

Step 2: Your browser opens a connection

Now that your browser knows the IP address, it reaches out to that server and says "hey, I'd like to talk." This happens using a protocol called TCP (Transmission Control Protocol), which sets up a reliable back-and-forth channel between your machine and the server.

Step 3: Your browser sends an HTTP request

Once the connection is open, your browser sends a message to the server. That message looks something like this:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

This is a raw HTTP request. It's just text, following a specific format. The GET part means "please give me this resource." The / refers to the homepage.

Step 4: The server sends back a response

The server receives your request, figures out what you want, and sends back a response:

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html>
  <body><h1>Hello, World!</h1></body>
</html>

The 200 OK means everything went fine. The server then sends the actual HTML content your browser will display.

Step 5: Your browser renders the page

Your browser reads the HTML, fetches any additional files it needs (like CSS, images, or JavaScript), and paints the final page on your screen.

The whole process typically takes under a second, but it involves your computer, at least one DNS server, and a web server potentially located on the other side of the planet.

This request-and-response cycle is the heartbeat of the web. Everything else we cover in this tutorial builds directly on top of it.

Clients vs. Servers: Who Does What?

Before we write any code, let's get one thing straight: a client and a server are just two computers (or programs) having a conversation. That's it. No magic involved.

Here's the simple breakdown:

The client is the one asking questions. Your web browser is a client. When you type a URL and hit enter, your browser is saying "Hey, can I have that webpage?"
The server is the one answering. It sits around waiting for requests, and when one arrives, it figures out what to send back.

Think of it like ordering food at a restaurant. You're the client, you make a request ("I'll have the burger"), and the kitchen is the server, preparing and sending back exactly what you asked for.

A Client Sends Requests

A request has a few key pieces:

A method (like GET or POST) that says what kind of action you want
A URL that says where you want to do it
Headers that carry extra info (like what kind of data you can accept)
A body (optional) that carries data you're sending along

Here's what a dead-simple client looks like in Python using the requests library:

import requests

response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

print(response.status_code)  # 200 means success
print(response.json())       # The actual data sent back

Run that and you'll see a dictionary of data come back. Your script just acted as a client.

A Server Listens and Responds

The server's job is to:

Listen on a specific port for incoming connections
Read the incoming request
Process it (look up data, run some logic, whatever)
Send back a response with a status code and some data

A status code is just a number that tells the client how things went. You've probably seen 404 before, which means "I couldn't find what you asked for." A 200 means everything went fine.

Here's a quick cheat sheet of the most common ones:

Code	Meaning
200	OK, here's your stuff
201	Created successfully
400	Bad request (you messed up)
404	Not found
500	Server error (they messed up)

Neither side can do the other's job. The client can't serve data, and the server doesn't go out looking for things to do — the client always starts the conversation, and the server always responds. That boundary is also why you can swap out a Spring Boot backend for FastAPI without touching the Angular frontend, as long as the contract — the API — stays the same.

Next up, we'll actually build one of these servers from scratch.

Building a Basic HTTP Server in Python from Zero

Alright, let's get our hands dirty and actually build something. The good news is that Python comes with a built-in HTTP server module, so you don't need to install anything extra to get started.

Open up your terminal and try this one-liner first, just to see the magic happen:

python3 -m http.server 8080

Point your browser to http://localhost:8080 and you'll see a file listing for whatever directory you ran that command in. Cool, right? But that's cheating a little. Let's build one ourselves so you actually understand what's going on.

Create a new file called server.py and paste in this code:

from http.server import HTTPServer, BaseHTTPRequestHandler

class MyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # Send a 200 OK response
        self.send_response(200)
        self.send_header("Content-type", "text/html")
        self.end_headers()

        # Write the response body
        message = "<h1>Hello from my server!</h1>"
        self.wfile.write(message.encode("utf-8"))

# Start the server on port 8080
server = HTTPServer(("localhost", 8080), MyHandler)
print("Server running on http://localhost:8080")
server.serve_forever()

Run it with python3 server.py, then visit http://localhost:8080 in your browser. You should see a big "Hello from my server!" heading. You just wrote a web server.

Let's break down what each part does:

BaseHTTPRequestHandler is the class we inherit from. It handles the low-level networking stuff so we don't have to.
do_GET is a method that gets called automatically whenever someone sends a GET request to your server. The name matters here, so don't rename it.
send_response(200) tells the client "everything went fine." That 200 is an HTTP status code.
send_header and end_headers package up the metadata about your response before the actual content.
self.wfile.write() is where you actually send the content back. It needs bytes, which is why we call .encode("utf-8").

Want to serve different content based on the URL? You can check self.path to see what the user requested:

def do_GET(self):
    self.send_response(200)
    self.send_header("Content-type", "text/html")
    self.end_headers()

    if self.path == "/about":
        message = "<h1>About Page</h1>"
    else:
        message = "<h1>Home Page</h1>"

    self.wfile.write(message.encode("utf-8"))

Now visiting /about gives a different response than visiting /. That right there is the core concept behind routing — something every web framework like Flask or Django builds on top of. Worth noting: this raw http.server approach is useful for learning, but in production you'd reach for FastAPI or Spring Boot, where routing, validation, and serialization are handled for you. For now, though, knowing what happens underneath those abstractions is exactly the point.

Press Ctrl+C in your terminal to stop the server when you're done experimenting.

Making Your First API Request: Sending and Receiving Data

Now that you have a server running, let's actually talk to it. This is where things get fun.

An API request is just your code asking another computer for data. Think of it like ordering food at a restaurant: you (the client) tell the waiter (the HTTP request) what you want, and the kitchen (the server) sends it back.

We'll use Python's requests library to do this. If you don't have it yet, install it with:

pip install requests

Fetching Data with a GET Request

A GET request means "give me some data." Here's the simplest possible example:

import requests

response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

print(response.status_code)   # Should print 200
print(response.json())        # Prints the actual data

Run that and you'll see a real JSON response come back. The status_code of 200 means everything went fine. You'll also notice response.json() automatically converts the raw text into a Python dictionary you can work with right away.

Sending Data with a POST Request

A POST request means "here's some data, do something with it." This is how login forms, sign-up pages, and chat apps send information to a server.

import requests

new_post = {
    "title": "My First Post",
    "body": "Hello, internet!",
    "userId": 1
}

response = requests.post(
    "https://jsonplaceholder.typicode.com/posts",
    json=new_post
)

print(response.status_code)   # Should print 201 (Created)
print(response.json())

Notice the status code here is 201 instead of 200. Servers use different codes to tell you what happened:

Code	Meaning
200	OK, here's your data
201	Created successfully
404	Resource not found
500	Server had a problem

Reading the Response

Every response has two important parts:

Headers: metadata about the response (content type, server info, etc.)
Body: the actual data you requested

print(response.headers["Content-Type"])  # Tells you the data format
print(response.text)                     # Raw response as a string
print(response.json())                   # Parsed as a Python dict

One quick tip: always check the status code before trusting the data. A simple habit is:

if response.status_code == 200:
    data = response.json()
    print(data)
else:
    print(f"Something went wrong: {response.status_code}")

That's genuinely all there is to making API requests. You're sending a message over the internet and reading the reply. Everything else is just details built on top of this foundation.

Understanding Stateless vs. Stateful Communication

Here's one of those concepts that trips up a lot of beginners, but once it clicks, everything starts to make more sense.

HTTP is stateless by default. That means every single request your browser sends to a server is treated as a brand new conversation. The server has no memory of you from one request to the next. It's like calling a customer service line where the agent forgets you the moment you hang up, and you have to re-introduce yourself every single time you call back.

Let's make this concrete. Imagine you log into a website. On request #1, you send your username and password. The server checks them and says "yep, that's valid." Now on request #2, you ask to see your profile page. The server has absolutely no idea who you are anymore. Stateless. Clean slate.

# Every request arrives with no memory of previous requests
# The server just sees raw data each time

from http.server import BaseHTTPRequestHandler, HTTPServer

class StatelessHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # The server has zero context about who called before
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"Who are you? I have no idea!")

So how do websites actually remember you're logged in? They fake statefulness by passing identity information along with every request. The two most common tricks are:

Cookies - The server sends a small token to your browser after you log in. Your browser then automatically attaches that token to every future request, like wearing a name badge.

Tokens (like JWTs) - Similar idea, but the token itself contains encoded information about who you are, so the server can verify it without even checking a database.

# Simulating stateful behavior by reading a token from headers
class TokenHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        token = self.headers.get("Authorization")

        if token == "Bearer secret-token-123":
            response = b"Welcome back! I recognize your token."
        else:
            response = b"Access denied. Who are you?"

        self.send_response(200)
        self.end_headers()
        self.wfile.write(response)

Notice what happened there. The server itself still has no memory. But because the client sent a token, the server could figure out who was asking. The state lives in the token, not in the server.

This is actually a really smart design. If the server held everyone's session in memory, it would get overwhelmed fast and become nearly impossible to scale. By keeping things stateless and pushing identity into tokens or cookies, you can run dozens of servers and any one of them can handle any request. In practice, this is exactly the pattern you see in Kubernetes-based deployments — pods can be added, removed, or replaced without any of them needing to share session memory, because the client carries its own identity on every call.

The takeaway: stateless does not mean insecure or forgetful from the user's perspective. It just means the client is responsible for proving who they are on every single request.

Common Pitfalls Beginners Make and How to Avoid Them

You've made it this far, which means you're ready to start building real things. But before you do, let's talk about the mistakes that trip up almost every beginner. Learning these now will save you hours of frustration later.

Pitfall #1: Forgetting to Handle Errors in Your Requests

A lot of beginners write code that assumes everything will work perfectly. Spoiler: it won't. Networks fail, servers go down, and URLs get mistyped. Always wrap your requests in error handling:

import requests

try:
    response = requests.get("https://api.example.com/data", timeout=5)
    response.raise_for_status()  # Raises an error for 4xx and 5xx status codes
    print(response.json())
except requests.exceptions.Timeout:
    print("The request timed out. Try again later.")
except requests.exceptions.HTTPError as e:
    print(f"HTTP error occurred: {e}")
except requests.exceptions.ConnectionError:
    print("Could not connect. Check your internet or the URL.")

Notice the timeout=5 parameter too. Without it, your program could hang forever waiting for a response that never comes.

Pitfall #2: Hardcoding Sensitive Data

Never put API keys, passwords, or tokens directly in your code like this:

# BAD - don't do this!
api_key = "my_super_secret_key_12345"

If you push this to GitHub, the whole world can see it. Instead, use environment variables:

import os

api_key = os.environ.get("API_KEY")

Then set the variable in your terminal before running your script:

export API_KEY="my_super_secret_key_12345"

Pitfall #3: Ignoring Status Codes

A request can "succeed" in the sense that it got a response, but that response might be a 404 Not Found or a 500 Internal Server Error. Beginners often skip checking the status code and then wonder why their data looks weird.

Always check response.status_code or use raise_for_status() as shown above.

Pitfall #4: Not Closing Your Server Properly

When you run a local Python server during testing, always stop it with Ctrl + C when you're done. If you just close the terminal window, the port can stay occupied. Then the next time you try to start the server, you'll see something like:

OSError: [Errno 98] Address already in use

You can find and kill the process using:

lsof -i :8080   # Find what's using port 8080
kill -9 <PID>   # Replace <PID> with the process ID shown

Pitfall #5: Assuming JSON is Always the Answer

JSON is super common, but not every API returns it. Some return XML, plain text, or even HTML. Always check the Content-Type header in the response before blindly calling .json(), or you'll get a confusing parse error.

print(response.headers["Content-Type"])

Avoiding these five mistakes puts you way ahead of where most beginners start. Keep them in your back pocket and your debugging sessions will be a lot shorter.

推荐订阅源

DEV Community