Your question, from a class where the connection kept dropping: "I was just talking about how the internet lags out." You were right that it was interesting, and you were right that it was real. The lag you felt is measurable and explainable — and by the end of this page you will be able to measure your own house and say which kind of lag you have.
It is not "the internet is complicated, here are some words". Every section here ends in a number you can check. The last one is an experiment you run at home, with a table you fill in yourself — and nobody, including me, knows what your answer will be until you measure it.
You press a key. Something has to physically travel. Here is the trip — press Step to walk it one hop at a time and read what happens, or Play to watch it run.
Ready. Your request has not left the building yet.
One click, many hops — and every hop can add delay. Notice that nothing here is "the internet" as a single place. It is a relay race between machines that have never met, each one deciding where to pass your packet next.
The journey above starts with a packet already addressed. But your computer cannot address a packet to x1000.ai. It can only address a number. Getting that number is a separate errand that happens before section 1 begins, and on a cold start it can easily cost more time than the page itself.
Ready. Nobody has asked anybody anything yet.
Assumptions printed so you can change them: resolver→root 20 ms, resolver→TLD 30 ms, resolver→authoritative 60 ms — plausible, not measured. The two sliders are yours. After DNS: the TCP handshake costs 1 round trip, TLS 1.3 costs 1 more, and asking for the page costs 1 more. Older TLS 1.2 costs 2, which is a big part of why the upgrade happened.
Nobody on that chain knows the whole answer, and that is deliberate. A root server has never heard of x1000.ai and never will. It knows one thing: who is responsible for .ai. The .ai servers know one thing: who is responsible for x1000.ai. Only the last machine — the authoritative one — actually holds the address, and its owner is the only person who can change it. The internet's naming system is a chain of referrals, not a directory.
Which is why caching matters so much. Every answer arrives with a TTL — a time to live, often 300 seconds. For those 5 minutes, your resolver may hand out the same answer to anybody who asks, in one hop instead of four. Your operating system caches it too, and so does your browser. That is why the second visit to a site feels instant while the first one does not, and why changing where a domain points takes hours to be believed by everybody: you are waiting out other people's caches.
Before the internet, the telephone network solved this problem the obvious way: when you place a call, a path through the network is reserved for you end to end, and it stays yours until you hang up. That is circuit switching, and it is genuinely good — the delay never changes and nothing ever arrives out of order.
The internet does the opposite. Nothing is reserved, every packet is addressed and released on its own, and the network makes no promises at all. Watch the same message go both ways.
Pick one. Then pick the other, and watch what each one buys and what each one costs.
and charges you: one round trip of setup before a single byte moves, and a link that stays reserved while you are silent.
and charges you: a header on every packet, variable delay, arrival out of order, and queues that can overflow and drop.
This is not a matter of taste. Put a link in front of a crowd of bursty users — people who need a lot for a moment and nothing for minutes — and the arithmetic is not close.
Fixed for this calculation: a 30 Mbps link, and an active user needs 10 Mbps — so at most 3 can be served at once. Users are assumed independent, which is why this is a binomial: P(more than 3 active) = 1 − Σ C(n,k)·p^k·(1−p)^(n−k) for k = 0…3. The sum is computed here, not looked up.
Read what that trade actually is. Circuit switching refuses the fourth user at the door. Packet switching lets everyone in and occasionally makes them queue. Neither is cheating — they are different answers to "what should happen when demand exceeds supply", and the internet chose degrade for everyone over block someone. Every lag you have ever felt is that choice being made on your behalf.
Push the activity slider up towards 100% and watch the packet-switching argument collapse. When users are not bursty — a phone call, where you are using your channel constantly — circuit switching wins, and that is exactly what the telephone network was.
These two get confused constantly, including by adverts. They are not the same thing and they are not even the same kind of thing.
how MUCH can flow per second · measured in megabits per second
how LONG one thing takes to go and come back · measured in milliseconds
A wide pipe can still be a long pipe. A satellite link can carry 100 Mbps and still take 600 ms to answer, because the signal has to go up to orbit and back. Downloading a film on it is fine. Having a conversation on it is miserable.
The rule is just division: Time ≈ Size ÷ Bandwidth. The trap is units, and it catches nearly everyone.
8 bits = 1 byte → 100 Mbps = 100 ÷ 8 = 12.5 MB/s
Mbps is megaBITS per second (network people). MB/s is megaBYTES per second (file people). The factor of 8 between them is why a "100 Mbps" line downloads a 1 GB game in about 80 seconds, not 10.
write a prediction to unlock the calculator ↓
Why predict first? Because a number you guessed and then checked sticks. A number you just read does not. If your prediction was wrong, that gap is the most useful thing on this page.
Section 7 is about to tell you that roughly 6% of what your line carries is not your data. That is a real number with a real derivation, and here it is, byte by byte. Nothing here is rounded before you see it.
A standard Ethernet link has an MTU of 1500 bytes — that is the largest IP packet it will carry. Inside that 1500 sits an IPv4 header (20 bytes), then a TCP header (20 bytes), and only then your data. Around the outside the link adds its own wrapper.
Both numbers are true. They answer slightly different questions, and that is the entire lesson: a percentage without its assumptions is not a measurement, it is a rumour. Say which bytes you counted and anybody can check you.
Every field below exists because some earlier version of the network did not have it and something broke. The four that matter most to you are marked.
Now look at the small-packet row in the table above. A 40-byte game update — your position and your aim, sixty times a second — spends more of the wire on labels than on you. That is not waste anybody can fix: the labels are what make the packet deliverable at all. It is the honest price of a network where nothing is reserved in advance, and it is why an online game uses far less bandwidth and far more packets per second than a video stream.
One more thing the byte count explains. The checksum is only 16 bits in IPv4 and in TCP. That is deliberately cheap and deliberately weak — it catches ordinary transmission damage and would not survive a determined attacker for a second. Integrity against people, rather than against noise, is what TLS is for, and it lives higher up.
Switch these on and watch the same journey again. Each one is a real effect, and each one takes a bite out of the number you just calculated.
nothing switched on — this is the formula's ideal world
The formula is the ceiling; the real world subtracts from it. This is the same move you met in Amdahl's law — the clean equation tells you the best case, and then engineering is the study of everything that keeps you off it.
Start a big download and watch the speed readout: it does not appear at your full line rate, it climbs there. That is not your computer waking up. It is TCP deliberately refusing to trust the network until the network has proved itself.
The problem TCP has. A sender has no idea how much the path can carry. Send too little and you waste the line. Send too much and you overflow a queue somewhere in the middle, packets are dropped, and everybody — including you — gets slower. Since nobody will tell it the answer, TCP finds out by experiment: send a little, and if that works, send twice as much.
Assumptions: one TCP segment carries MSS = 1460 bytes (the 1500-byte MTU from section 6, minus 20 for IPv4 and 20 for TCP). "Doubling every round trip" is slow start — the sender may have cwnd segments unacknowledged at once, and each acknowledgement lets it grow. Real stacks vary; Linux has defaulted to an initial window of 10 segments since about 2011, where the original specification said 1.
Read the last line of that calculation again. Most small files finish before TCP has finished working out how fast it was allowed to go. That is why a 200 kB page never feels like your advertised speed, why speed tests deliberately download something large, and why a slow-looking website is usually suffering from round trips rather than from bandwidth.
And it is why latency multiplies. Every extra millisecond of round trip does not just delay one packet — it stretches every single rung of that ladder. Double your ping and the ramp takes twice as long, on a line whose advertised speed has not changed by one bit per second. Bandwidth is what you bought. Round trips are what you wait for.
Press the loss button and look at what happens: the window is cut in half and then climbs back in a straight line instead of doubling. That is TCP saying I was wrong about how much this path can take, and then probing upward one segment per round trip, cautiously, for ever. The resulting sawtooth is what almost all internet traffic looks like from the inside, right now, on every link between you and everywhere.
Which gives the honest answer to your original question. When the internet "lags out", one likely story is exactly this: a queue somewhere filled, something was dropped, and every connection sharing that queue halved itself at the same moment — then all of them climbed back together, filled it again, and did it once more.
Does where you stand change your internet, and which number changes most — download, upload, or ping?
the chart unlocks when you have written a prediction. That is not a bug — it is the experiment.
| Spot | Download (Mbps) | Upload (Mbps) | Ping (ms) |
|---|---|---|---|
| a · next to the router | |||
| b · far room | |||
| c · behind a wall |
download Mbps (left axis) ping ms (right axis) — two different units, so two different scales. Compare each colour with itself, never blue against red.
type your numbers above — the chart draws itself
Write one sentence for each: (1) which number changed most, and (2) why that one and not the others. Then the honest clause: (3) what this experiment cannot tell you.
Hint for (3), and it is a real limitation, not a formality: three readings in one house on one evening is a pilot, not a study. It cannot separate "distance" from "that wall happens to have pipes in it", and it cannot tell you whether tomorrow looks the same. Saying so out loud is what makes the rest of it trustworthy.
Bring your chart to class. We will read the shape of your house — and the shape will be different from mine, which is the entire reason it is worth measuring.
Nothing travels as one piece. A file is cut into numbered chunks called packets, typically about 1,500 bytes each. Each one carries its own address labels and sequence number, and each one is routed independently — two packets from the same file can genuinely take different paths and arrive out of order.
TCP is the protocol that pretends none of that happened. Its job is to hand the application a clean, ordered stream. It does this with a simple contract: the receiver acknowledges what arrived; anything not acknowledged gets sent again; everything is reassembled in sequence order before being handed up. From the outside it looks like a reliable pipe. On the inside it is a lot of bookkeeping over an unreliable one.
And here is the cost that matters to you. If packet #47 goes missing, packets #48 onwards may already have arrived — but TCP will not hand any of them over until #47 has been resent and filled in. That wait is at least one round trip, and often more. This is called head-of-line blocking.
Because a live video call has a deadline that a download does not. A frame that arrives 300 ms late is not "slow", it is useless — the moment it was meant to be shown has passed. So what hurts a call is not bandwidth but:
This is why live video usually avoids TCP entirely and runs over UDP: it would rather show you a slightly damaged frame now than a perfect frame too late. It is also why a speed test can proudly report 200 Mbps on a connection that is unusable for a call.
Which means the thing you experienced in class has a precise name. You did not have a bandwidth problem. You had a latency-and-jitter problem, most likely on the Wi-Fi hop — the one link in the whole chain that is shared with every other device in the building and is made of radio waves passing through walls. Next time it happens, run a ping test while it is happening. If download looks fine and ping is jumping around, you have just diagnosed it yourself.
Every animation here is a caricature with the right ratios, not a simulation — real hop counts vary, real routers make decisions this page does not model, and your actual path to a server may cross a dozen networks owned by companies you have never heard of. The exceptions are the arithmetic: the header byte counts in section 6, the binomial in section 3 and the window ladder in section 8 are computed in front of you from assumptions printed beside them, and you can check every one by hand. The only measured numbers on this page are the ones you type into the experiment card. That asymmetry is on purpose: a diagram should make you want to measure, not replace measuring.