Dev.to WebDev 🛠 Dev 👁 0 📖 7 min read

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 mess

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.

Infographic, "The Path to AI FDE #06: How the Internet Works, from Zero", by Dhanush Kumar Sivaji. Subtitle: clients, servers and requests; every AI app is a web app first. Legend: blue is who and where, lavender is what gets sent, orange is a gotcha. Part A, who talks to whom. 1, Client and server: client and server linked by a two-way arrow; the client asks, and the server, a program on a computer elsewhere, answers. 2, IP addresses and DNS: example.com leads to 192.0.2.10; servers have numeric addresses, and DNS is the phone book that turns names into numbers. 3, Request and response: "GET /page" leads to "200 OK plus data"; method, path and headers go out, and status, headers and body come back. Part B, how the message travels. 4, HTTP and HTTPS: HTTP is a postcard, HTTPS is a sealed envelope. Gotcha: HTTP is the delivery rules, HTML is a page format. 5, Ports: 443 HTTPS, 80 HTTP, 22 SSH; the IP finds the machine and the port picks the program on it. 6, Latency: DNS, connect, secure, ask; each step is a round trip, and distance and extra trips add milliseconds. AI calls add model time on top, so apps stream. Tip bar: your code asks, a server answers, and every round trip costs time. Sources: MDN pages on the Internet, HTTP, DNS, ports and latency; RFC 9110; RFC 1034; RFC 8446; the IANA port registry; checked October 2026.

Part A · Who talks to whom

Figure "Client asks, server answers": every web conversation has two sides, one asks and one answers. On the left, box 1, Client: the program that asks and starts every conversation; examples: browser, phone app, a Python script. On the right, box 2, Server: a program on a computer elsewhere that waits and answers, running all day and listening for requests; examples: web pages, weather data, an AI model. Between them, an arrow labelled request goes right and a green arrow labelled response comes back. Below, the postal version of the same idea, in four cards: your letter equals the request, the address book equals DNS, the office that replies equals the server, the reply letter equals the response. Two notes: "The cloud" is servers in someone else's data centre that you rent, still ordinary computers, just not yours. Roles, not machines: client and server are jobs; your laptop can run a small server for testing, and a server can be a client of another server. Tip bar: every AI app you'll build works this way; your code is the client, and the model sits behind a server you send requests to.

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.

Figure "Names for people, numbers for computers": every server has a numeric IP address, and DNS looks it up from the name you type. Computers find each other by number. IPv4 address example 192.0.2.10: four numbers from 0 to 255, about 4.3 billion possible addresses, which turned out not to be enough. IPv6 address example 2001:db8::10: the newer, much longer format written in hex; both are in use today, often side by side. People use names, and DNS turns a name into a number, in four steps. 1, you type a name: your browser needs the address for example.com. 2, ask a resolver: a DNS server run by your internet provider, or a public one, does the hunting for you. 3, follow the chain: it asks the root servers, then the .com servers, then example.com's own name server. 4, get the number: back comes 192.0.2.10, and your device connects to that address. Two notes. Answers are cached: resolvers and your device remember answers for a set time, the TTL, so most lookups skip steps 3 and 4. Warning: broken DNS looks like "the site is down"; if the name can't be turned into a number, nothing else can start, even if the server is fine. Tip bar: DNS is the internet's phone book, names for people and numbers for computers; the addresses shown are reserved documentation examples.

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.

Figure "One request, one response": the client asks in a fixed format, and the server replies with a status and some data. Left, the request from client to server, shown as text: "GET /index.html HTTP/1.1", "Host: example.com", "Accept: text/html". Labelled parts: 1, method, what you want done, where GET means send me this; 2, path, which thing on the server; 3, headers, extra notes like "I'd like HTML". Right, the response from server to client: "HTTP/1.1 200 OK", "Content-Type: text/html", a blank line, then an HTML doctype and the title "Example Domain". Labelled parts: 4, status, a number saying how it went; 5, headers, notes like "this is HTML"; 6, body, the data itself. Below, the first digit of the status tells you who to look at: 2xx success, 200 OK, here's what you asked for; 3xx look elsewhere, the thing moved; 4xx problem with the request, 404 no such thing here; 5xx problem on the server, 500 it broke while trying. Tip bar: one request, one response, every time; newer HTTP versions send the same parts in a compact binary form, and the meaning doesn't change.

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

Figure "HTTP is a postcard, HTTPS is a sealed envelope": same language and messages, but HTTPS encrypts them on the way. Same message, two ways to send it. HTTP, like a postcard: the message "POST /login, password=sunflower42" travels readable, and anyone on the path, such as café Wi-Fi or a router, can read it. HTTPS, HTTP inside a sealed envelope (TLS): the message travels as scrambled hex bytes, and only the server can open them. What the padlock in your browser gives you: private, the content is encrypted on the way; untampered, any change in transit is detected; the real site, a certificate proves you reached the real example.com. Still visible: which server you're talking to, its IP address and usually the site name, but not what you said. Warning, HTTP is not HTML: HTTP is the delivery rules, HTML is a page format, and HTTP also carries JSON, images and AI replies. Tip bar: treat HTTPS as the default; API keys and user data should never travel over plain HTTP.

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.

Figure "Ports: which door on the server": one computer can run many services, and the port number says which one you want. One server at 192.0.2.10. An IP address finds the machine; a port number, 0 to 65535, picks which program on it gets the message. Four doors: 443 HTTPS, secure web and APIs; 80 HTTP, plain web, usually redirects to 443; 22 SSH, admins logging in; 5432 PostgreSQL, a database, kept private. Below, where the port hides in a web address: "https://" is the scheme, "example.com" the host, ":443" the port, "/docs" the path. Usually invisible: 443 is the default for https and 80 for http, so browsers leave it out, and https://example.com means port 443. You'll see ports soon: when you run a server on your own laptop you'll visit addresses like http://localhost:8000, and port 8000 is just a common choice for testing. Tip bar: IP address equals which building, port equals which door, and the scheme says which language to speak at that door.

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

.

Figure "Latency: every round trip costs time": before the first byte arrives, a new connection makes several trips there and back. A timeline for a first visit to an HTTPS site, with illustrative numbers assuming each round trip takes 50 milliseconds. 1, DNS lookup, name to number: 0 to 50 ms. 2, connect, TCP handshake: 50 to 100 ms. 3, secure, TLS 1.3 handshake: 100 to 150 ms. 4, ask and wait, request to response: 150 to 200 ms, followed by a short block of server work, ending around 240 ms. Distance sets a floor: light in optical fibre covers roughly 200 kilometres per millisecond, so a server 13,000 km away, India to the US East Coast, costs at least about 130 ms per round trip before it does any work. Reuse saves trips: later requests reuse the cached DNS answer and the open, secured connection, so they pay only step 4. Why AI apps care: an AI request adds the model's thinking time on top, so apps reuse connections, pick nearby regions and stream the answer so you see the first words sooner. Tip bar: latency is the waiting time for a round trip; fewer trips and shorter distances make apps feel fast.

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)

  1. Open

https://example.com

  1. in Chrome, Edge or Firefox. This domain is reserved for examples, so it’s a safe toy.
  2. Open the developer tools (F12, or Cmd+Option+I on a Mac) and click the Network tab.
  3. Reload the page. Click the first row, the request for the page itself.
  4. 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.
  5. 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?

Sources

  1. MDN: How does the Internet work? (packets, routers, clients and servers). https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/How_does_the_Internet_work
  2. MDN: An overview of HTTP (client-server protocol, message structure, HTTP/2 framing). https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview
  3. RFC 9110: HTTP Semantics (methods, status code classes 1xx to 5xx, the http and https schemes, default ports 80 and 443). https://www.rfc-editor.org/rfc/rfc9110
  4. MDN: HTTP response status codes. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
  5. RFC 1034: Domain Names, Concepts and Facilities (resolvers, name servers, caching, TTL). https://www.rfc-editor.org/rfc/rfc1034
  6. MDN: DNS (glossary) and What is a domain name? https://developer.mozilla.org/en-US/docs/Glossary/DNS · https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_domain_name
  7. RFC 791 (IPv4, 32-bit addresses) and RFC 8200 (IPv6). https://www.rfc-editor.org/rfc/rfc791 · https://www.rfc-editor.org/rfc/rfc8200
  8. RFC 5737 (IPv4 documentation addresses, 192.0.2.0/24), RFC 3849 (IPv6 documentation prefix, 2001:db8::/32) and RFC 2606 (example.com reserved). https://www.rfc-editor.org/rfc/rfc5737 · https://www.rfc-editor.org/rfc/rfc3849 · https://www.rfc-editor.org/rfc/rfc2606
  9. MDN: HTTPS and TLS (glossary). https://developer.mozilla.org/en-US/docs/Glossary/HTTPS · https://developer.mozilla.org/en-US/docs/Glossary/TLS
  10. RFC 8446: TLS 1.3 (confidentiality, integrity, server authentication; one-round-trip full handshake). https://www.rfc-editor.org/rfc/rfc8446
  11. MDN: Port (glossary) and What is a URL? https://developer.mozilla.org/en-US/docs/Glossary/Port · https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_URL
  12. IANA: Service Name and Transport Protocol Port Number Registry (22 ssh, 80 http, 443 https, 5432 postgresql). https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
  13. MDN: Understanding latency (first request includes DNS lookup, TCP handshake and TLS negotiation) and Round Trip Time. https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Understanding_latency · https://developer.mozilla.org/en-US/docs/Glossary/Round_Trip_Time
  14. RFC 9293: Transmission Control Protocol (three-way handshake). https://www.rfc-editor.org/rfc/rfc9293
  15. Chrome DevTools: Inspect network activity; Firefox: Network Monitor (for Try it). https://developer.chrome.com/docs/devtools/network · https://firefox-source-docs.mozilla.org/devtools-user/network_monitor/
  16. Wikipedia: Optical fiber (typical core refractive index about 1.47, so light travels at roughly 200,000 km/s, about 200 km per millisecond). https://en.wikipedia.org/wiki/Optical_fiber

Sources checked Oct 31, 2026.

Free: the 5-page roadmap from Novice to AI FDE.

If this was useful, subscribe to The Path to AI FDE for the next issue.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram ↗ Reddit 🟧 HN
← News 🛠 Dev 🏠 Home