How the internet actually works

What it covers

1. Packets and addresses The internet does not send your message in one piece. It chops it into packets of at most about 1,500 bytes, stamps each with a source and destination IP address, and sends them separately. Packets can take different routes and arrive out of order; the receiving computer reassembles them. An IPv4 address is four numbers from 0 to 255, such as 142.250.74.46; the newer IPv6 uses 128-bit addresses because the 4.3 billion IPv4 addresses ran out.
2. DNS: names into numbers Computers route by numbers, people remember names. The Domain Name System translates study-graph.com into an IP address. Your device asks a resolver (often your ISP's or a public one such as 1.1.1.1), which walks the hierarchy: a root server points to the servers for .com, which point to the servers for study-graph.com, which answer with the address. Answers are cached along the way so the second lookup is instant. DNS runs mostly over UDP on port 53.
3. Routing: finding a path No single map of the internet exists. Each router knows only its neighbours and which direction leads towards blocks of addresses. The internet is a mesh of about 75,000 independent networks (autonomous systems) run by ISPs, universities and companies, and they exchange reachability information with the Border Gateway Protocol. A packet hops from router to router, each one choosing the next hop, typically 10 to 20 hops to cross a continent. If a link fails, routers learn new paths within seconds to minutes.
4. TCP: making unreliable reliable Packets get lost, duplicated and reordered. TCP sits on top of IP and fixes that: it numbers every byte, the receiver acknowledges what arrived, and the sender retransmits anything missing. It also starts slow and speeds up until it senses congestion, which is why a download ramps up. A connection begins with a three-way handshake (SYN, SYN-ACK, ACK). Where speed matters more than perfection, such as video calls, applications use UDP instead and accept some loss.
5. HTTP and HTTPS Once a connection exists, the browser speaks HTTP: a request line (GET /lesson HTTP/1.1), headers (which site, what formats it accepts, cookies), and for the response a status code (200 OK, 404 Not Found), headers and the body. HTTPS wraps this in TLS: the server proves its identity with a certificate signed by an authority the browser trusts, the two sides agree on keys, and from then on nobody in the middle can read or alter the traffic. The padlock means exactly that and nothing more: the site is who it says it is and the connection is private, not that the site is honest.
6. What the browser does with it The response body is usually HTML. The browser parses it into a tree (the DOM), fetches the stylesheets, scripts, images and fonts it references (each another HTTP request), computes the layout, paints pixels, and runs the JavaScript, which can change the page and fetch more data without a reload. A page that feels instant is one that needs few requests, small files and no script that blocks rendering. Developer tools in any browser show every request and how long it took.