The page you are reading crossed the internet to get here, and it did
that before you finished the first sentence. Your browser turned the
name aramansell.github.io into one of four numbers, cut
this file into pieces small enough for the wire, and let machines that
have never seen a map carry them. Today you do all of it on purpose,
and read the answers back.
In this lesson you will be able to answer“how does a message find its way across the internet?”
Break It Down~10 min
The page you are reading came to you across the internet. Between your finger and this sentence there is a name that had to become a number, a file that had to be cut into pieces, a path that no single machine knows, and a rule deciding whether a missing piece is worth waiting for. "The internet" is not one system. It is five, and each one can be checked from the machine in front of you.
First, before anything else: cut that into parts small enough that you could look each one up on its own.
Address every piece so it can travel alonewhat does this part do?Read: the header table in this lesson's Concept Lab, and the "Packets, not streams" section of the Unit 9 Internet reference
Decide whether a missing piece is worth waiting forwhat does this part do?Read: the TCP-versus-UDP table in this lesson's Concept Lab, and the "TCP vs UDP" section of the Unit 9 Internet reference
The split is the whole lesson. "How does the internet work" is a question you can only answer by waving your hands. These five are five things you can settle from the machine in front of you: the first is a command you type and a hierarchy you watch answer, the second and the fourth are arithmetic on your own files, and the last is the tradeoff the exam asks about in every form it owns. Nothing here needs Unity open, because nothing here is a game — it is the network the game will one day have to talk over.
The test for a finished split: could you settle the part from a terminal and a file listing? The lookup gives you four numbers back, the packet part gives you a division, and the routing part gives you a list of hops with milliseconds beside them. A part that needs a server of your own before you can check it is not a part of this problem — it is a project.
Your turn
Pick two of the parts above and say in one line what each one actually does.
The name this page is served under has four addresses and your browser used one of them. A classmate in the same room may have used a different one and still received the same bytes. What does that tell you about which machine served you — and what would have to change about the reply before the answer was different?
One packet carries 1,460 bytes and your whole Assets/ folder is 20,185,356 bytes over 4,967 files. Work out the packet count, then say what the very last packet carries that none of the others does, and why the count must always round up rather than down.
Concept Lab~15 min
Nothing crosses the internet whole. A packet
carries at most 1,460 bytes of your file. The limit is
the MTU — the largest frame a link will carry, 1,500 bytes on Ethernet
— and the IP and TCP headers take 40 of those bytes before your data
gets any of them. So a file is never sent as a file. It is divided into
as many 1,460-byte pieces as the arithmetic demands, and the last piece
is mostly empty. Your biggest scene file is
Assets/_Scenes/Overworld.unity at 2,377,344 bytes:
1,629 packets, and the 1,629th carries the leftovers.
Each packet carries its own header, repeated in full on every single
one of them:
Field
What it is for
FROM address
Where the packet started, so the reply knows where to go.
TO address
Where it is going — a number, never a name.
Sequence number
Where this piece sits in the file, so order survives the trip.
Checksum
A sum of the packet's own bytes, so a garbled one is caught rather than assembled.
That repetition is the design, not the overhead. Because every packet
can be addressed and ordered on its own, the packets do not have to
travel together — they can take different routes and still be put back
in the right order at the far end. If one dies, only that one is resent,
and the rest of the file never knows. This is what "the internet routes
around damage" means: a design with no single point of failure.
TCP vs UDP — the reliability trade.
TCP
UDP
Guarantee
All packets, in order, or none
Best effort; drops are fine
Speed cost
Handshake, receipts, resends
Fire and forget
Used for
Web pages, file transfer, email
Game packets, video calls, voice
Your world
This page arrived whole and you never saw a gap
A position 10 ms late is DROPPED, never awaited
That split is the exam's favourite tradeoff: a game would rather LOSE
a packet than WAIT for one, and a page reader would rather wait.
DNS — names to numbers.aramansell.github.io is a name for humans. Routers move
numbers, and this name has four of them:
DNS is the lookup that converts, hierarchically, with caching at
every level. Hierarchically, because no single machine on earth holds
every name: the root servers know who runs .io, the
.io servers know who runs github.io, and
GitHub's nameservers know the four addresses. With caching, because
climbing that tree costs about a tenth of a second, and repeating it
for every image on every page would be unbearable — so every level
keeps the answer it just gave, and hands it straight back next time.
The site you are reading is a GitHub Pages project
site.astro.config.mjs sets
site: 'https://aramansell.github.io' and
base: '/AP_CS_Principles', and there is no
CNAME file anywhere in the repository — which is why
the hostname is aramansell.github.io and not a domain
the course owns. Ask that host for its certificate and it will not
name this site back to you: it names *.github.io, one
wildcard certificate covering every Pages site there is. All of
that was checked live while this lesson was written, and all of it
is two commands away from you in Step 1.
Socratic
Your browser knows aramansell.github.io and
connects to a number. Walk the lookup — your machine's cache,
then the school's resolver, then the root servers, then the
.io servers, then GitHub's own — and say where
the hundred milliseconds go. The resolver's answer comes back
marked non-authoritative, which means it did not ask
anyone just now. What does that word promise you, and why is
caching the difference between a page that loads and one that
does not?
Build Lab~20 min
Step 1 — resolve this site's own name. You are
reading a page that had to be fetched by name. Ask what that name
means, in Terminal:
nslookuparamansell.github.io
Read the answer twice. The first reading is the four addresses
above, one of which — 185.199.108.153 — is the one
ping aramansell.github.io picks out. The second reading is
the line sitting above them: Non-authoritative answer.
That phrase is the whole of caching in two words. Your machine asked
its resolver, and the resolver answered from something it already
remembered instead of going and asking. It is telling you, honestly,
that it did not check.
Step 2 — climb the hierarchy yourself. The cached
answer is what you get in normal life. This is what it cost the first
time, and it is the only way to see the shape:
dig+tracearamansell.github.io
Read it top to bottom. It starts at the root servers — thirteen of
them, a.root-servers.net through
m.root-servers.net — asks which machines run
.io, asks those which machines run github.io,
and asks those for the four addresses. Four questions, four different
organisations, and not one of the machines involved knew the answer
when it started. On the machine this lesson was written on, the climb
cost 25 ms to a root server, 103 ms to the .io servers and
7 ms for the final answer — against roughly 10 ms for the whole cached
lookup in Step 1. Your milliseconds will differ; the shape will
not. That gap is what caching buys, and it is why the first visit
to a site is the slow one.
Step 3 — see a route, and read the server's own
header. Every line of a trace is one router making one local
decision:
traceroutearamansell.github.io
The milliseconds jump where your traffic leaves one network and
enters another — usually the boundary between your school and the open
internet. Many school and hotel networks drop the probes
traceroute sends, so a row of asterisks is a fact about
the network rather than a broken command. Then ask the far end who it
is:
Among the headers is server: GitHub.com — the machine
naming itself — and cache-control: max-age=600, which is
GitHub telling your browser it may keep its copy for ten minutes before
asking again. That is the same caching decision you just watched DNS
make, written down as policy instead of left as a habit.
Step 4 — price the trip in packets. One packet
carries 1,460 bytes of your file, so a packet count is a division and a
rounding up. Do these three on paper:
Your whole Assets/ folder: 4,967 files,
20,185,356 bytes. How many packets?
The biggest picture in the project,
mainlevbuild.png, 654,657 bytes. How many packets,
and how much of the last one is actually used?
Not one of those answers is a whole number of anything, and the
leftover on the final packet is why the count always rounds up instead
of down. It is the same arithmetic you ran on pictures in
9.3, pointed the other way.
Checkpoint — before moving on, you must be able to:
Explain packets, headers, sequence numbers, and reassembly
Choose TCP vs UDP for a given application with reasons
Resolve a real name and read the answer, cached and uncached
Read the DNS hierarchy out of a +trace and say what each level knows
Turn a file size into a packet count, and explain the leftover
Tell DNS, the network and the server apart when something fails
Break this topic into parts small enough to check each one on its own, and say in one line what each part does
Say which earlier lesson each part came from, and where you would reread it
Reference Docs
Need a deeper explanation? These pages cover the same concepts:
The Internet — the full reference: packets, TCP vs UDP, DNS and routing