How the internet actually works
The internet is not one big network. It is a network of networks, each piece separately owned, all of them agreeing on one shared language. Whatever you open travels from your device to a server as small numbered packets, station by station, and the answer comes back the same way.
- Lesson 1 of 12
- Beginner
- Free, no signup
The journey of one request, station by station
No station holds the whole map. Each one only knows the neighbour closer to the destination.
-
1
Your device
The browser or app builds the request and hands it to the network.
-
2
The home modem and router
The first station, and where most home slowness actually ends.
-
3
The operator network
The company you pay. It takes your traffic and hands it upstream.
-
4
The networks in the middle
A few routers with no common owner, which have only agreed to pass the packet on.
-
5
The data centre and the server
Where the answer is either lifted from a cache or built on the spot.
-
6
The same road, backwards
The answer does not have to return by the same route, and it is this two way trip that makes the wait.
These six stations are simplified; in practice several more networks can sit between the operator and the data centre. And we cannot measure the route of an Iranian user from our own server.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
When you open a link, what does the request pass through?
Through a chain of stations. No station knows the whole route and none of them needs to; its only job is to hand your packet to whichever neighbour is closer to the destination. The first station is the modem or router in your home, then the network of the operator you pay, then a few larger networks in the middle, and finally the data centre where the site server sits.
The station everyone forgets is the first one. If the home router is congested or the wireless signal is weak, nothing after it matters; in support we have repeatedly seen that "the internet is slow" actually means "there are two metres of wall between the phone and the router". So troubleshooting starts at the nearest station, not the furthest.
Here is the part that usually sounds strange: there is no complete map of the internet stored anywhere. Each router only holds a table of which neighbour to hand a packet to for each range of addresses. The full route is the sum of those local decisions, and it can change halfway through.
And unlike an old telephone call, no line is reserved for you. The server, meanwhile, is answering thousands of other requests in the same moment. What happens at the server end is its own story and is opened up in the lesson on how a website works; this lesson is only about the road to that door.
What is a packet, and why does your message travel in pieces?
A packet is a small piece of your data carrying the destination address and its own sequence number. Nothing is sent in one go, because the link between two stations has a size ceiling and because losing one large piece would mean sending all of it again.
That ceiling is visible. The network card on our server has a ceiling of 1500 bytes and testing it takes one command: with ping -4 -c 1 -M do -s 1472 the packet goes through, and one byte more, -s 1473, returns message too long, mtu=1500. So a three megabyte image is thousands of packets, not one thing.
The pieces do not have to travel the same road and do not have to arrive in order. The receiver puts them back in order by number and asks again for anything that did not arrive. That single sentence explains two familiar experiences: in a download a lost packet costs a few hundredths of a second and you never notice it; in a video call there is no time to ask again, because by the time it arrived it would be useless, so the audio drops or the picture goes blocky right there.
The practical consequence is that "internet speed" is not one number but two things: how many packets fit per second, and how long one round trip takes. The first is bandwidth and the second is latency, and the next section shows why buying more bandwidth does not reduce latency.
The life of a packet, from being cut up to being put back together
-
1
Cut into pieces
The link between two stations has a size ceiling, so everything gets cut.
-
2
Address and number
Each piece carries the destination address and its own sequence number, and travels alone.
-
3
Independent route
There is no guarantee two pieces take the same road; each router decides in the moment.
-
4
Arriving out of order
The receiver sorts them by number, not by the time they arrived.
-
5
Asking again
A lost piece is requested again. In a download that is only time; in a live call it is dropped audio.
This describes a reliable connection. A live call deliberately skips the last link, because a packet that arrives late is of no use.
Who owns the internet?
Nobody, and that is not a slogan. Every network along the way belongs to a separate company or university or operator, and all they have agreed on is to carry each other traffic. There is no switch anyone can use to turn the internet off, because there is no "internet" separate from those networks.
What does get coordinated is names and numbers, not content. ICANN own page says its job is coordinating those unique identifiers, and adds explicitly that it does not control content and does not deal with access. The protocols are published as open documents too: the one defining the shape of a packet, RFC 791, has been readable by anyone since September 1981, with no licence and no fee.
The delegation chain is visible in a local example. In the IANA root database the ir. top level domain is delegated to the Institute for Research in Fundamental Sciences, and from our own server dig +short NS ir. returns four name servers, a.nic.ir through d.nic.ir. So "nobody owns it" does not mean "nobody runs it": every piece has a named operator.
And here is our position: the owner that actually matters to you is not "the internet", it is the links of your own path. The operator you pay, the data centre the site sits in, and the content delivery network in front of it. When a page does not open, the answer is never "the internet is broken"; the answer is one of those owners, and the last section says which.
Why do distance and the number of stations decide the speed?
Because bandwidth is the width of the pipe and latency is its length. Buying a faster line makes the pipe wider; it does not move Singapore closer. For a page made of dozens of small files, it is that length which decides how long you wait.
We took the numbers from our own server in Helsinki on 6 September 2026, best round trip out of ten packets: to a destination in the same city 0.3 ms, to Nuremberg 23.6, to Falkenstein 33.3, to Ashburn in the United States 120.7, to Hillsboro on the west coast 180.5 and to Singapore 187.2 ms. One thing in that list is worth noticing: the two German cities differ by ten milliseconds, and that difference is not distance, it is the route the traffic takes.
The same goes for the number of stations. That machine in the same city is eight stations away and Singapore is seventeen, but the count is not the point: the first eleven stations are all under thirty milliseconds and one jump, from the eleventh to the twelfth, adds about 144 ms on its own. That single jump is the long haul between continents.
The industry answer to this is to move the destination closer rather than to cheat physics: a copy of the page is kept in a city near you so the round trip is short. The name for this is a content delivery network. Just do not expect a miracle: a page that has to be built fresh for every user gains little from being nearer.
Which link is broken? Three commands that answer it
In order, from near to far. First call your own router, then a numeric address like 1.1.1.1, and last a name like rgb.ir. If the first does not answer the problem is inside your home; if the first answers and the second does not, it is the operator link; and if the second answers but the third does not, the network is fine and name resolution is broken.
ping 192.168.1.1
ping 1.1.1.1
ping rgb.irTo see the whole route, mtr rgb.ir on Linux and macOS and tracert rgb.ir on Windows show the stations one by one. What you are looking for is a sudden jump in latency that continues to the end of the route.
And one common misreading worth knowing so you do not hunt for a fault that is not there: if a station in the middle shows a percentage of loss but the stations after it are clean, that is not a fault. Some routers treat answering a probe as low priority work and simply drop it, while passing real traffic perfectly. Only loss that continues to the last station matters.
These tools have limits too. Where a firewall throws the probe away the route looks incomplete, and none of these commands says anything about the server itself being slow. That is a different job and our speed test of ten pages shows how that is measured.
The fast path, with AI
Reading the output of a trace used to be something only network people could do, and now it takes two minutes. The condition is that you hand over the raw output and offer no theory of your own, because the model will agree with your theory.
- Take raw output, not a screenshot: <code>mtr -r -c 20 example.com</code> on Linux and macOS, <code>tracert example.com</code> on Windows. Twenty probes, so accidental loss is not mistaken for real loss.
- Paste that text untouched and say where it was run from and what the destination is. A fast cheap class of model is enough here; there is no heavy judgement involved.
- Ask for three things and no more: the first station with sustained loss, the largest latency jump between two consecutive stations, and which link the pattern points to.
- If the answer points at a middle station, run it again at another hour. Routes change, and a single measurement is not evidence.
Copy-ready recipe
You are a network engineer. The text below is the raw output of a trace, untouched.
{paste the mtr or tracert output here}
Destination: {domain or address}
Run from: {city or operator name}
Write only these three things:
1. The first station that shows loss AND whose loss continues to the last station. If there is none, write "no sustained loss".
2. The largest latency jump between two consecutive stations: the number of both stations and the difference in milliseconds.
3. Which link this pattern points to: my own network, my operator, the middle path, or the destination.
Rule: ignore loss that is not repeated at the stations after it, and say in one sentence why. Do not guess; write unknown for anything this text does not show.Before you trust the output: The final call is yours, because this output says at most which link the problem is in, not who should fix it. If the jump is in the middle path, neither you nor your operator can do anything about it and the only real move is choosing a server closer to your users. And before any decision, measure twice at two different hours.
AI in this kind of work
On network questions a language model is genuinely good at one job: translating jargon and error messages into human language, and turning raw output into a hypothesis. It is bad at the job people most want from it: telling you which menu to open in your particular router. It has not seen the router, and the interface differs by manufacturer and even by firmware version.
Tools that actually help
- Claude Works well for reading raw ping and mtr output and error logs, provided you paste the text rather than describe it. Iran is not on Anthropic list of supported countries, so there is no official route to sign up or pay.
- Gemini Good for the same job and for translating network jargon into Persian. Google own page says the Gemini app works in more than 230 countries and territories, and Iran is not on that list.
- Gemini Notebook The trick few people use: upload the PDF manual of the router itself and ask your question against that document, so the answer comes from the manufacturer text rather than the model memory. It runs on the same Google account, and Iran is not among the available regions.
Where it backfires
The risk here has its own shape. In the same confident tone the model will name a menu path that does not exist in your router firmware, and the dangerous version is when it suggests turning off the firewall, opening a port or putting a device in DMZ mode to "solve the problem". Those three expose your router from the outside, and an ordinary user usually does not know what they just agreed to. Anthropic itself calls this confident invention hallucination in its documentation and writes about reducing it, which means the vendor treats it as a real weakness. Our rule is simple: reading output is the model job, changing a security setting happens only with the manufacturer own manual. And the thing you must never paste is the router configuration backup and the wifi password; Google own help page for Gemini says plainly not to enter confidential information. For what paying for each of these tools looks like from Iran, see the buying guide.
Sources: Anthropic: reduce hallucinations Anthropic: supported countries Google: Gemini Apps privacy and data Google: where Gemini Apps are available
Where this advice stops
This lesson explains the road and repairs nothing; it only makes you look in the right place when you do repair something. The numbers here were taken from one server in Finland and mean something for that point only: the route and latency of an Iranian user is a different thing that we cannot measure from here. And the model of "the request goes and the answer comes" deliberately leaves out layers a working network engineer cannot do without: translating private addresses to public ones, encryption, congestion control, and the newer version of the addressing protocol.
From our own work
We took the numbers in this lesson from our own server in Helsinki on the same day, and the raw output is in this session report. The most interesting piece is one that rarely appears in a tutorial: on the Singapore route three routers, stations three, four and sixteen, did not answer at all, and station thirteen reported twenty percent loss while the four stations after it reported none. Had we taken that twenty percent seriously we would have gone hunting for a fault that did not exist; that station simply treats answering a probe as low priority work. You can repeat the same measurement with mtr -r -c 20 from your own machine, and the numbers will differ while the pattern stays.
Real follow-up questions
Are the internet and the web the same thing?
No. The internet is the road and the web is one of the things moving on it. Email, video calls, phone updates and online games use the same road without any web page being involved. That is why a messaging app can work while a website does not open.
Why does traffic get slower when it passes through an intermediate server?
Because the route becomes two legs and the total length grows. Instead of one round trip to the destination you have one to the intermediary and another from there onwards, and the two latencies add up. If the intermediary sits in the opposite direction from the destination, that single choice can multiply the delay.
My connection is fast, so why does a foreign site take so long to open?
Because being fast means having lots of bandwidth, while what hurts here is latency. A page made of dozens of small files needs a round trip for each of them, and if every round trip is a hundred and eighty milliseconds, a wider line does not shorten it. Part of the slowness can also belong to the destination server itself rather than to the route.