How Does the Internet Actually Work?
Nothing travels from the website to you. The page is cut into thousands of numbered pieces, each one finds its own way across the planet, and your machine puts them back in order.
What happens between clicking and seeing
Junior level — plain language, no maths
When you type an address and press enter, the first thing your computer has to do is admit it does not know where that place is. labinatab.com is a name, and names mean nothing to the network. So it asks - and the asking is itself a little journey, from your router to your provider to a machine that keeps the master list, until an answer comes back: a number. That number is the address, and only now can anything be sent.
Then comes the surprising part. The page is not sent as a page. It is chopped into pieces of about fifteen hundred characters each, and every single piece is put in its own envelope with the destination written on the front and a sequence number written inside. A photo might be four hundred envelopes. Each one is released separately, and nobody is holding them together.
They travel by being passed along. Your envelope arrives at a machine that looks at the address, decides which of its cables points roughly the right way, and throws it down that cable - then forgets about it entirely. Ten or twenty machines do this in turn, and none of them knows the whole route. It is the postal system, not a phone call: no line is ever opened between you and the server.
Some envelopes get lost. A machine is too busy, a cable glitches, and the piece simply never arrives. Your computer notices the gap in the sequence numbers and asks for that one again - which is why a bad connection does not give you half a photo, it gives you a slow one. Move the sliders and watch where the time actually goes. It is almost never where people think.
Things worth knowing
- Every piece of every page you load carries the full destination address on it, because no machine along the way remembers anything about the ones that came before.
- About 99% of all intercontinental internet traffic runs through undersea cables, not satellites. A cable the thickness of a garden hose can carry the traffic of a country.
- Light in fibre travels at about two thirds of its speed in vacuum, which puts a hard floor of roughly 60 ms on a round trip from Europe to the US west coast. No amount of money makes that shorter.
DNS, packets, handshakes, and why latency beats bandwidth
Student level — the core equations
A page load is four separate things happening in sequence, and understanding which one dominates is most of the practical knowledge. First DNS: the name is resolved to an IP address by walking a hierarchy - root servers, then the top-level domain, then the authoritative server for the domain - unless the answer is already cached, in which case it costs almost nothing. Then the TCP handshake, three messages that establish the connection and cost one and a half round trips before a single byte of content moves. Then TLS, which costs more round trips. Only then does the data flow.
The data is split into packets sized by the MTU, typically 1500 bytes, of which about 1460 is payload. A 240 kB page is therefore around 170 packets. They are sent in a window - several in flight at once, because waiting for an acknowledgement after each one would be catastrophically slow - and the window grows as the connection proves itself reliable. This is why the first second of a connection is slower than the rest.
Routing is hop-by-hop and stateless. Each router reads the destination, consults a forwarding table, and sends the packet out of one interface. Packets from the same page can take different routes and arrive out of order; TCP reorders them using sequence numbers and requests retransmission of anything missing. A lost packet costs at least one full round trip to notice and replace, which is why loss hurts far more than its percentage suggests.
Hence the rule that surprises people: for ordinary web pages, latency matters more than bandwidth. Going from 10 to 100 Mbps barely changes load time, because the page was never big enough to saturate the pipe. Halving the round-trip time changes it enormously, because the load is a chain of round trips. That is the entire reason content delivery networks exist - not to send faster, but to sit closer.
Key Formulas
| Propagation delay | \(t_{\text{prop}} = \dfrac{2d}{c_{\text{fibre}}}\) | c ≈ 200 000 km/s in glass |
|---|---|---|
| Packets needed | \(N = \lceil S / \text{MTU} \rceil\) | S = page size |
| Time before first byte | \(t_{\text{TTFB}} \approx t_{\text{DNS}} + 1.5\,\text{RTT} + t_{\text{TLS}}\) | |
| Transfer time | \(t \approx \dfrac{S}{B} + \text{RTT}\log_2\!\left(\dfrac{S}{\text{IW}}\right)\) | slow start, IW = initial window |
Things worth knowing
- Opening an HTTPS connection costs about 3 round trips before any content arrives. At 100 ms RTT that is 300 ms spent agreeing to talk, which on a short page can exceed the time spent sending it.
- 1% packet loss can cut TCP throughput by more than half, because the congestion control algorithm treats loss as a signal to back off, not merely as a piece to resend.
- A traceroute to a server 1000 km away typically shows 8 to 15 hops. None of those routers knows the full path - each only knows which neighbour is closer.
The layered model, congestion control, and why the internet does not fall over
Scholar level — full mathematical depth
01Layers, and what each one refuses to know
The architecture's central trick is deliberate ignorance. IP, the network layer, promises only best effort: it will try to deliver a datagram and will tell you nothing if it fails. It does not guarantee order, delivery, or timing. Everything people want from a network - reliability, ordering, flow control, security - is built above that in TCP and TLS, at the endpoints. This is the end-to-end principle, and it is why the network scaled: routers stayed simple and stateless while the interesting complexity lived in machines at the edge, where it could be upgraded without touching the middle.
02Congestion control as a distributed algorithm
No central authority allocates bandwidth. Instead every TCP sender runs a control loop that increases its sending rate until it sees loss, then halves it - additive increase, multiplicative decrease. Millions of independent senders running this rule converge on a rough fair share of every shared link, which is a genuinely remarkable distributed result. Modern variants complicate it usefully: CUBIC recovers faster on high bandwidth-delay paths, and BBR abandons loss as the signal altogether, modelling the bottleneck's bandwidth and round-trip time directly, because in an era of large router buffers loss arrives long after the queue has already ruined latency.
03Bufferbloat and the tyranny of the queue
Cheap memory produced a pathology. Routers with oversized buffers absorb bursts rather than dropping them, so loss-based congestion control gets its signal late and the queue sits permanently full. Throughput looks fine while interactive latency collapses - the classic symptom of a video upload destroying a voice call on the same link. The fix is active queue management, CoDel and FQ-CoDel, which drop or mark packets based on how long they have been queued rather than how many there are.
04BGP, and the fact that routing is a matter of policy
Between networks, paths are chosen by the Border Gateway Protocol, which is not a shortest-path algorithm but a system for announcing reachability and applying commercial policy. An autonomous system prefers routes through customers over peers over providers, for reasons of money rather than distance. The consequences are structural: the internet has no map, route changes propagate as gossip and can take minutes to settle, and a mistaken announcement can pull a country's traffic through the wrong continent, which has happened more than once.
05What HTTP/3 changed
Running reliable streams over a single TCP connection created head-of-line blocking: one lost packet stalls every stream sharing that connection. QUIC moves the reliability and encryption machinery into user space on top of UDP, giving independent streams, a handshake that merges transport and cryptographic setup into one round trip, and connection identifiers that survive a change of IP address - so a phone moving from wi-fi to cellular keeps its connection instead of rebuilding it.
Key Formulas
| AIMD | \(w \leftarrow w + \tfrac{1}{w}\ \ \text{per ACK};\quad w \leftarrow \tfrac{w}{2}\ \ \text{on loss}\) | |
|---|---|---|
| TCP throughput | \(B \approx \dfrac{\text{MSS}}{\text{RTT}\sqrt{p}}\) | the square-root law; p = loss rate |
| Bandwidth-delay product | \(\text{BDP} = B \times \text{RTT}\) | bytes needed in flight to fill the pipe |
| Queue delay | \(t_q = \dfrac{Q}{B}\) | why a big buffer is a slow buffer |
Things worth knowing
- AIMD - additive increase, multiplicative decrease - is provably fair and stable for competing flows sharing a bottleneck. It is one of the few places where a simple local rule reliably produces a good global outcome.
- Bufferbloat can add seconds of latency to a link whose throughput measures perfectly. It is why a speed test can say 200 Mbps while a video call is unusable.
- BGP has no built-in verification of who owns which address block. Route origin validation is being deployed, but for most of the internet's history any network could announce any prefix and be believed.