# How the internet actually works > Follow one web page from your screen to a server and back. A free course from Learnfold. 6 lessons, 20–30 min. Web: https://learnfold.app/learn/internet/ ## What you'll learn Explain what happens between tapping a link and seeing the page, and name the part to blame when something goes wrong. ## Before you start You use the internet every day. No networking or programming knowledge is required. ## Outline ### Chapter 1: The journey of a page Follow one page load from start to finish, then see why data travels in small pieces and how those pieces find their way. 1. [What happens when you open a page](https://learnfold.app/learn/internet/open-a-page/): The whole trip from your screen to a server and back, in five steps. 2. [Why everything travels in packets](https://learnfold.app/learn/internet/packets/): See why the internet chops every message into small numbered pieces, and what happens when one goes missing. 3. [How packets find their way](https://learnfold.app/learn/internet/routing/): IP addresses, routers that only know the next step, how networks share directions, and the cables on the seabed. ### Chapter 2: Names, lost packets, and trust Turn names into addresses, recover what the network loses, and find out what the padlock really guarantees. 4. [DNS, the internet's phone book](https://learnfold.app/learn/internet/dns/): How a name like wikipedia.org turns into an address, and why that usually takes milliseconds. 5. [TCP, UDP, and lost packets](https://learnfold.app/learn/internet/tcp-udp/): Two ways to handle a network that loses things: resend everything, or keep moving. 6. [What the padlock promises](https://learnfold.app/learn/internet/https/): What HTTPS protects, how your phone knows it reached the real site, and what the padlock can't tell you. ## Lessons ## 1. What happens when you open a page Type an address into your browser and tap Go. About a second later, a page appears. In that second your phone traded messages with computers that may be thousands of kilometers away, and it did so dozens of times. This lesson walks the whole trip once, quickly. The rest of the course slows down at each stop. Press Play to follow a page request, or Step to inspect one stage. This is a simplified TCP path; QUIC combines setup differently. ### Step 1: get onto the network Your phone talks over Wi-Fi to a small box in your home, the router. The router connects to your internet provider, the company you pay each month. Your provider connects to other networks, and those connect to others still. "The internet" is the name for all those networks agreeing to carry each other's traffic. Nobody owns it, and no single computer runs it. ### Step 2: turn the name into a number Computers on the internet find each other by numeric address, called an IP address. One looks something like 203.0.113.7. The name you typed, say wikipedia.org, means nothing to the machines that move your data. So your phone first asks the Domain Name System, or DNS, which number goes with that name. Usually the answer is already saved somewhere nearby and comes back in a few milliseconds. ### Step 3: open a conversation Your phone contacts that address and sets up a connection. Then it runs a second setup for encryption, so that nobody between you and the server can read what follows. Each setup is a quick exchange of messages there and back. Every round trip costs time, which is why a faraway server feels slow even on fast Wi-Fi. ### Step 4: ask for the page Now your browser sends the actual request, in the language browsers and web servers share, called HTTP. In older versions of HTTP, the request was plain text you could read: ``` GET / HTTP/1.1 Host: wikipedia.org ``` That says "send me the main page of wikipedia.org." Newer versions pack the same information into a more compact form, but the idea hasn't changed. ### Step 5: the answer comes back in pieces The server replies with the page's HTML, broken into small chunks called packets. The HTML lists everything else the page needs, like images, fonts, and scripts. A busy news page can ask for a hundred files or more, often from several different servers. Your browser fetches many at once and draws the page as they land, which is why text often shows up before the pictures. ### The big idea Each step is handled by a separate layer that ignores the others. Wi-Fi doesn't know it's carrying a web page. Routers don't look at what's inside the packets they pass along. Your browser doesn't care whether the packets crossed an ocean. That separation is the internet's best design decision. It's why the same network carries video calls, email, and games, even though it was built for none of them in particular. ### Rabbit holes > Why does a page sometimes show the text first and the images later? > What does my home router actually do all day? > If nobody owns the internet, who decides how it works? Read online: https://learnfold.app/learn/internet/open-a-page/ ## 2. Why everything travels in packets Old telephone networks worked by reserving a line. When you placed a call, switches along the way connected a circuit just for you. It stayed yours until you hung up, even while nobody was talking. That suits a phone call. Computers talk differently, in short bursts with long gaps, so a reserved line would sit idle most of the time. The internet does the opposite. It chops every message into small pieces called packets and sends each one on its own. A packet is usually no bigger than about 1,500 bytes, roughly a long paragraph of text. One photo on a web page might take hundreds of packets. A movie takes millions. ### What's on a packet Every packet has two parts. The payload is a slice of your data. The header is a label on the front, like the outside of an envelope. It says where the packet came from and where it's going. It also carries a number that tells the receiver where this slice fits in the whole. One more field is worth knowing about. The header holds a counter that drops by one at every router. If it reaches zero, the packet is thrown away. That way a packet caught in a loop dies quietly instead of circling forever. ### Why chop things up Sharing is the first reason. Thousands of conversations can take turns on the same cable, one packet at a time, and nobody hogs it. When you pause to read, the link carries someone else's packets instead of sitting empty. The second reason is resilience. If a link fails, routers send the next packets another way. Nothing needs to be redialed. A network built like this keeps working while parts of it are broken, and on a network this size, some part always is. ### Out of order is normal Because packets travel independently, they can arrive out of order, and some never arrive at all. In practice the packets of one download usually follow the same path, but nothing guarantees it. And when a router gets more packets than it can forward, it simply drops some. The receiver uses the numbers to put everything back in order and to spot what's missing. Try it below. Tap Send message and watch the arrival order. Then turn on Drop packet 3 and send again. Notice two things. The pieces arrive jumbled, yet the message comes out right. And with a packet dropped, the receiver can't finish until the sender notices the gap and sends that piece again. That wait is the stall you sometimes feel on a bad connection. Lesson five covers how the sender notices. ### Rabbit holes > Why is a typical packet about 1,500 bytes and not much bigger? > Who first proposed chopping messages into packets, and why did phone engineers doubt it? > What happens inside a router when too many packets arrive at once? Read online: https://learnfold.app/learn/internet/packets/ ## 3. How packets find their way Every device on the internet needs an address so packets can reach it. That's its IP address. The classic kind, IPv4, is four numbers with dots between them, like 203.0.113.7. There are only about 4.3 billion possible IPv4 addresses, fewer than there are people, and the supply of new ones ran out years ago. The newer kind, IPv6, has so many addresses that running out isn't a real concern. The two run side by side. So how do far more than 4.3 billion devices get online? Mostly by sharing. Your home router has one public address and hands every device in your house a private one. When your phone's packets leave the house, the router swaps in its public address and keeps a note, so it can pass the replies back to the right device. This trick is called network address translation, or NAT. ### Routers only know the next step A router is a computer whose whole job is forwarding packets. It reads the destination address, checks a table, and sends the packet out whichever connection brings it closer. Then it moves on to the next packet. A big router does this many millions of times a second. No router knows the full route. Picture asking for directions in a city where each person only knows which street to take next. A packet from your phone to a server on another continent might pass through somewhere around 10 to 20 routers, each making one small decision. Play the route, then fail the link and play again. The small network is illustrative; route updates take time on a real network. ### How networks share directions The internet is made of tens of thousands of separate networks, run by internet providers, universities, big companies, and cloud platforms. Each runs its own routers. To fill their tables, networks tell their neighbors which blocks of addresses they can reach, using a protocol called BGP, the Border Gateway Protocol. Neighbors pass the news along, and before long every network has a path to everywhere. BGP runs largely on trust. If a network announces a route it shouldn't, others may believe it. In 2008 a provider in Pakistan tried to block YouTube inside the country by announcing a route to YouTube's addresses. The announcement leaked to the rest of the world, a large share of YouTube's traffic headed to Pakistan, and the site was unreachable for many people for about two hours. Networks have better ways to check announcements now, but smaller versions of this mistake still happen. ### Under the sea When your packets cross an ocean, they almost certainly travel through a cable on the seabed, not a satellite. Several hundred of these cables wrap the planet. In the deep ocean one is roughly as thick as a garden hose, and most of that is protective layers around hair-thin glass fibers that carry pulses of light. Light in glass moves at about two thirds of its speed in empty space. That sets a floor no upgrade can beat. A round trip between New York and London takes about 65 milliseconds, however fast your plan is. That's why big websites keep copies of themselves on several continents. Drag the globe sideways or tap Turn to see the ocean path from another angle. The route is illustrative; real cables follow the seabed and use landing stations. ### Rabbit holes > How does a ship lay a cable across the ocean floor, and what happens when one breaks? > Why did we run out of IPv4 addresses, and why is the move to IPv6 taking so long? > How does a router choose between two paths to the same place? Read online: https://learnfold.app/learn/internet/routing/ ## 4. DNS, the internet's phone book Routers move packets by number. People remember names. The Domain Name System, DNS, connects the two. You hand it a name like wikipedia.org and it hands back an IP address. It's often called the internet's phone book, and that's close. The difference is that no single book exists. The directory is split across a huge number of servers, and each one is responsible for its own small part. ### Read the name backwards DNS reads names from right to left. Take en.wikipedia.org. The last part, org, is a top-level domain. Wikipedia registered its name under org. Then Wikipedia created en under its own name, for the English site. Each level hands control of the level below to someone else, which is how one system can cover every name on the internet without one owner. ### A lookup, step by step Your phone doesn't do the hard work itself. It asks a resolver, a server run by your internet provider or by a company you've chosen. If the resolver already has the answer saved, it replies at once. If not, it walks down the levels: 1. It asks a root server who handles org. The root server doesn't know Wikipedia's address, but it knows which servers are in charge of org. 2. It asks one of those org servers who handles wikipedia.org. They point it to Wikipedia's own name servers. 3. It asks Wikipedia's name servers for en.wikipedia.org and finally gets the address. The resolver passes the address back to your phone and keeps a copy for next time. Step through the lookup and watch every reply return to the resolver. Turn on the cached answer to skip the referrals. There are only 13 root server names, run by about a dozen organizations. Each name is really a fleet of machines spread around the world that all answer to the same address, so your question reaches a nearby one. ### Saved answers keep it fast If every lookup went all the way to the root, the root servers would drown. Instead, every answer comes with a time to live, a number of seconds it may be reused. A popular name is almost always saved at your resolver already, so the full walk is rare. The catch shows up when a site changes its address. Some people keep getting the old one until their saved copy expires. ### The answer depends on who asks Big sites keep copies of their content in data centers all over the world. Their name servers often reply with the address of a copy near you. Someone in Tokyo and someone in Toronto can type the same name, get different numbers, and both be right. ### When DNS breaks If DNS fails, the internet looks dead even though every cable works. Your connection is fine. Your phone just can't turn names into addresses. A surprising number of large outages turn out to be DNS problems, often a bad configuration change. ### Rabbit holes > Who runs the root servers, and what would happen if they all went offline? > When I buy a domain name, who actually records that it's mine? > Can my internet provider see every site name I look up? Read online: https://learnfold.app/learn/internet/dns/ ## 5. TCP, UDP, and lost packets The network makes your packets exactly one promise. It will try. Packets get dropped, delayed, and delivered out of order, and the routers in the middle don't fix any of it. That job falls to the two computers at the ends. They usually pick one of two approaches. ### TCP: everything, in order TCP, the Transmission Control Protocol, turns a stream of unreliable packets into a reliable conversation. It starts with a handshake of three messages. Your phone says "I'd like to talk." The server says "Got it, I'd like to talk too." Your phone says "Got it." Along the way, both sides agree on the numbers they'll use to count what they send. From then on, every piece of data is numbered, and the receiver keeps sending back acknowledgments that mean "I have everything up to here." When the sender sees the same acknowledgment again and again, or hears nothing for too long, it concludes a packet was lost and sends it again. That's what you watched in the packets lesson. ### Loss means slow down TCP treats a lost packet as a sign that some router along the way is overloaded. So it backs off, sending less, then speeds up again gently. This is called congestion control. It's a quiet bit of cooperation. Millions of computers ease off whenever the network gets crowded, so it doesn't jam. That cooperation was added after the fact. In the mid-1980s, parts of the early internet nearly ground to a halt, with useful traffic on some links falling to a tiny fraction of normal. Congestion control was the fix, and it's still at work in your phone today. ### UDP: send it and move on UDP, the User Datagram Protocol, does almost nothing. It sends packets and never checks whether they arrived. For a file download that would be a disaster. For a video call it's exactly right. If a packet carrying a sliver of someone's voice goes missing, getting it back half a second later is useless, because the conversation has moved on. Better to skip it and accept a tiny glitch than freeze while waiting. Online games use UDP for the same reason. DNS lookups often do too, since the question and the answer each fit in a single packet, and if either gets lost it's quicker to just ask again. Play TCP to see setup and a resend after a timeout. Switch to UDP to see later datagrams arrive without transport-level repair. | What happens | TCP | UDP | |---|---|---| | Lost packets | Sent again | Gone | | Order | Always restored | Not guaranteed | | Setup | Handshake first | None | | Good for | Web pages, email, downloads | Calls, games | ### The twist A large share of web traffic now travels over QUIC, a newer protocol that runs on top of UDP and adds its own acknowledgments and resending. Why rebuild what TCP already does? Speed, for one. QUIC folds the connection setup and the encryption setup into fewer round trips. And with TCP, one lost packet holds up everything behind it, while QUIC lets other files keep flowing. There's a practical reason too. TCP is built into operating systems and network equipment everywhere, so changing it takes years. QUIC lives in apps and browsers, which update all the time. ### Rabbit holes > Why does a video call get blurry or choppy instead of freezing when my connection is bad? > What went wrong in the congestion collapse of the 1980s, and how did the fix work? > If TCP is everywhere, why is it so hard to change? Read online: https://learnfold.app/learn/internet/tcp-udp/ ## 6. What the padlock promises Your packets pass through a lot of hands on the way to a server. There's the coffee shop Wi-Fi, your provider, and every network in between. Without encryption, any of them could read what you send, or change it on the way. HTTPS fixes that. It's ordinary HTTP wrapped in TLS, Transport Layer Security. The padlock or similar icon in your address bar means TLS is on. ### Two problems at once Encryption alone isn't enough. A perfectly secret channel to an impostor protects nothing. So TLS has to settle who you're talking to before it settles who can listen. First, identity. When you connect, the server presents a certificate, a signed statement saying that a particular key belongs to wikipedia.org. The signature comes from a certificate authority, one of a list of organizations your phone already trusts because its maker shipped that list with the software. Before signing, the authority checks that whoever asked really controls the domain. If the certificate doesn't match the name you typed, your browser stops you with a full-page warning. Second, privacy. Your phone and the server agree on a fresh secret key using math that works even while strangers watch every message of the exchange. An eavesdropper sees the whole conversation and still can't work out the key. From then on, everything is encrypted, and any tampering shows up as an error instead of a changed page. Step through the public key shares and identity checks. Try a wrong-domain certificate and see why the request must stop. ### What the padlock does promise - You're connected to a server that controls the domain in the address bar. - Nobody between you and that server can read what you send or receive. - Nobody in between can quietly change it. ### What it doesn't promise The padlock says nothing about whether a site is honest. A scam site at yourbank-secure-login.com can get a valid certificate in minutes, because the authority only checks that the scammer controls yourbank-secure-login.com, and they do. The padlock proves you reached that address. It can't tell you it's the address you meant. Read the domain, not the lock. It also doesn't hide everything. Your network can usually still tell which site you're connecting to, because the server's address, and often its name, sit outside the encryption. Watchers can see how much data moves and when. What they can't see is which pages you read or what you typed. And the protection ends at the server. Once your data arrives, TLS has done its job. What the company does with it next is a question for its privacy policy, not for the padlock. ### Where you've been That's the whole trip. A name becomes a number, a message becomes packets, routers pass them hop by hop, TCP or QUIC repairs what gets lost, and TLS keeps the conversation private. Next time a page hangs, you'll have a decent guess which part is stuck. ### Rabbit holes > How can two computers agree on a secret key while strangers watch every message? > What happens when a certificate authority gets hacked or signs a certificate it shouldn't? > Is it safe to log in to my bank on public Wi-Fi if the padlock is showing? Read online: https://learnfold.app/learn/internet/https/ --- Read this course in the Learnfold app to ask about any sentence, follow a question into a new lesson, or have it rebuilt around what you already know: https://apps.apple.com/us/app/learnfold/id6794672797