The path to AI FDE #06: How the internet works: clients, servers and requests

Originally published on my newsletter, The Path to AI FDE. Subscribe free to get each issue by email.

This is a “From Zero” issue. Every AI app is a web app first. When a chatbot answers you, your device has sent a message across the internet to a server and waited for a reply. Before we get to AI APIs, it helps to know what actually happens in that round trip. No code today, just six ideas you’ll use for the rest of this series.

Part A · Who talks to whom

1. A client asks, and a server answers. The client is the program that starts the conversation: your browser, a phone app, or a small Python script. The server is a program on a computer somewhere else that sits waiting for requests and answers them. Think of the post: you write a letter (the request), look up the address, the office reads it, and a reply letter comes back (the response).

Two things trip beginners up here. “Client” and “server” are roles, not special kinds of machine: your laptop can run a small server while you test, and a server can be a client of another server. And “the cloud” isn’t magic. It’s servers in someone else’s data centre that you rent by the hour.

2. Every server has a number, and DNS finds it from the name. Computers find each other by IP address. The older format, IPv4, looks like 192.0.2.10: four numbers from 0 to 255. That only allows about 4.3 billion addresses, so a much longer format, IPv6 (like 2001:db8::10), is now used alongside it. (Both examples are addresses reserved for documentation, so they don’t point at anyone’s real server.)

People don’t remember numbers, so we use names like example.com. The Domain Name System (DNS) is the internet’s phone book. Your device asks a resolver (usually run by your internet provider, or a public one). If the resolver doesn’t already know, it asks along a chain: the root servers, then the servers for .com, then the name server for example.com itself. The answer comes back as an IP address, and everyone along the way remembers it for a set time (the TTL, time to live). That’s why most lookups are instant.

3. The client sends a request, and the server sends one response. A request says three main things:

the method, which is the action you want (GET means “send me this”);
the path, which says what you want (/index.html);
the headers, which are extra notes, such as “I’d like HTML back”.

The response comes back with a status code, its own headers, and a body: the actual data, whether that’s a web page, an image or, later in this series, an AI model’s answer.

The first digit of the status code tells you where to look when something goes wrong:

2xx means success (200 OK);
3xx means “look somewhere else”;
4xx means the problem is in the request (404 Not Found);
5xx means the server failed (500 Internal Server Error).

(The text format in the figure is HTTP/1.1. Newer versions, HTTP/2 and HTTP/3, pack the same parts into a compact binary form, but the meaning is the same.)

Part B · How the message travels

4. HTTP is the shared language, and HTTPS is the sealed version. HTTP (HyperText Transfer Protocol) is the set of rules for the request and response you just saw. Plain HTTP is like a postcard: anyone handling it along the way, such as a café Wi-Fi network, can read it. HTTPS is the same HTTP wrapped in TLS encryption, like a sealed envelope. The padlock in your browser gives you three things:

privacy: the content is encrypted;
integrity: changes made in transit are detected;
authenticity: a certificate proves you reached the real site.

People on the network can still see which server you’re talking to, but not what you said. For anything carrying passwords, API keys or user data, HTTPS is the only acceptable choice.

5. Ports say which program on the server should get the message. One computer can run many services at once: a website, a database, a remote-login service. The IP address finds the machine, and the port number (0 to 65535) picks the program. HTTPS uses port 443 by default and plain HTTP uses 80, which is why you never type them.

https://example.com

already means port 443. You’ll meet ports properly when you run a server on your own laptop and visit something like

http://localhost:8000

6. Latency is waiting time, and every round trip adds some. Latency is how long a message takes to get there and back. A first visit to an HTTPS site needs several round trips before the first byte of the page arrives:

one to look up the name;
one to open a connection (the TCP handshake);
one to set up encryption (a TLS 1.3 handshake);
one for the request itself.

Distance sets a hard floor. Light in optical fibre travels roughly 200 km per millisecond, so a server about 13,000 km away (say, India to the US East Coast) costs at least about 130 ms per round trip before it does any work. Later requests are cheaper because the DNS answer is cached and the secure connection stays open.

AI apps care about milliseconds because a model call adds its own thinking time on top. That’s why they reuse connections, pick nearby regions and stream the answer word by word.

Try it (10 minutes, no code)

Open

https://example.com

in Chrome, Edge or Firefox. This domain is reserved for examples, so it’s a safe toy.
Open the developer tools (F12, or Cmd+Option+I on a Mac) and click the Network tab.
Reload the page. Click the first row, the request for the page itself.
Find three things: the status code (you should see 200), the method (GET), and how long it took in the Time column or the Timing tab.
Bonus: reload again and see if the time drops. Can you explain why using point 6?

Check your understanding: a friend says “the site is down”, but when you type its IP address directly, the page loads. Which of the six ideas is most likely broken? (Answer: DNS, point 2. The server is fine; the name lookup isn’t.)

Common beginner mistakes

Thinking “the cloud” is something other than computers. It’s other people’s computers, rented.
Mixing up HTTP and HTML. HTTP is the delivery protocol; HTML is one format of content it can carry, alongside JSON, images and more.
Reading every error as “the server is broken”. A 4xx status means the request was wrong; a 5xx means the server failed.
Sending passwords or API keys over plain http://.

Takeaway

A client sends a request to a server it found through DNS, at a port, usually over HTTPS. The server sends back a status and some data, and every round trip costs time. Every AI API call you’ll ever make follows this exact path.

Where this fits in my roadmap: this is on-ramp material, outside my current study block. I use these ideas every day as a TypeScript engineer, and I’m writing them down for readers starting from zero. Section 3 comes back to HTTP up close: methods, URLs, headers and status codes, with real code.

Over to you: what’s the slowest website or app you use regularly? After today, which of the six steps would you blame first?