From my machine to the whole world

You’ve just finished the first website of your life. It looks great on your screen and every button works. Proudly, you copy the address from the bar at the top, localhost:3000, and send it to a friend. A few seconds later your friend replies: "It won’t open."

The website isn’t broken, and your friend’s internet is fine. But between your computer and the computers of everyone else in the world, several pieces are still missing. This chapter assembles those pieces one at a time, until your website can travel out of your machine and reach the screen of someone on the other side of the planet.

The first puzzleWhy can’t my friend open it?

Look again at the address you sent. The word localhost is not your computer’s name. It’s a special word that every computer understands the same way: "this machine." The number 3000 is the port where your website program is waiting for connections.

localhostThis machine

A special name that always points back to the machine you are using. Developers use it to test a website on their own machine before publishing it. Nobody outside can reach anything through this name.

To sum up the first puzzle: right now your website lives on your machine and nowhere else. To let other people open it, we first have to answer four questions. Where will the website live? What is the address there? How will people remember that address? And who will turn what people remember into the real address?

Piece 1A home where the lights never go out: Hosting

Your computer is switched off at night, moves to the coffee shop’s Wi-Fi, and isn’t set up to let strangers connect to it. That makes it a poor home for a website. So we send the website’s files to a server: a computer built to stay on all the time, with a fast internet connection, ready to answer anyone who asks to see the website.

HostingA home for your website

A service that rents out space on a server. The provider takes care of the power, the cooling, the internet cables and the machines. We just upload the website.

Once the website is on a server, it has a public address made of numbers, called an IP address. In this chapter we use the example 203.0.113.10, from a range of numbers set aside for documentation and examples. It is nobody’s real machine.

IP AddressA machine’s address on the network

A set of numbers that identifies one machine on the internet, such as 203.0.113.10. Network equipment uses this number to deliver data to the right machine, like the house number on an envelope.

Pieces 2 and 3A name people can remember, and the world’s address book

At this point anyone who types 203.0.113.10 can open the website, but nobody wants to remember numbers like that. So we register a domain name such as internetmachine.example: a name you can say out loud and remember easily.

DomainDomain name

The name people use for a website instead of numbers, such as example.com. We register a name through a domain registrar and renew it from time to time, so the name stays ours as long as we keep paying the renewal fee.

But registering the name isn’t enough on its own. A freshly registered name doesn’t yet know which machine to send people to. We have to write a note in a system called DNS saying which number this name stands for.

DNS (Domain Name System)The system that translates domain names

The system that translates domain names into IP addresses. Every time we type a website’s name, the browser first asks DNS which numbered machine that name belongs to.

Putting it togetherWhen someone types your website’s name

Now there are enough pieces for the whole world to open the website. Let’s trace what happens in the split second after a user in Japan types internetmachine.example and presses Enter.

1. 1The browser asks DNS, "Which numbered machine is internetmachine.example?" and gets the answer 203.0.113.10.
2. 2The browser connects to the machine with that number and sends a request for the website’s home page. (Book 02 tells the story of requests and responses in detail.)
3. 3The server replies with a response containing the HTML, CSS and JavaScript files.
4. 4The browser reads those files and draws the page on the screen. (Book 01 takes this apart.)

Hands onLab: publish your website to the world

Time to try it yourself. This lab starts with a website that lives on just one machine, the developer’s. Press the publish button and watch the pieces connect one step at a time. Notice three things: how the address bar changes, who can open the site at each step, and the routes the data takes across the map.

If you tried everything, you probably noticed two things we haven’t explained yet: the padlock that appears at the HTTPS step, and the CDN boxes that make images load much faster for people in Brazil. The next two sections explain how they work.

Piece 4The padlock by the address: HTTPS

Between the user’s machine and the server, data passes through many devices, such as the Wi-Fi router in a coffee shop and the equipment of several internet providers. If data travels unencrypted (plain HTTP), devices along the way can read it or secretly change it, including the passwords you type.

HTTPSSecure HTTP

Sending requests and responses over an encrypted connection (using a standard called TLS). The server needs a certificate proving it really owns that domain name, and then the browser shows a padlock.

Piece 5Distance, crowds and the CDN

Data in fiber-optic cables moves very fast, about 200,000 kilometers per second, but the world is very big too. Bangkok and São Paulo in Brazil are about 16,000 kilometers apart in a straight line, so a request that has to go there and back takes at least about 160 milliseconds in theory. In practice it usually takes longer, because cables don’t run in straight lines and data passes through many devices. This waiting time is called latency.

A single web page is often made of dozens of files, so small delays add up until you can feel them. The fix is to put copies of files that rarely change close to users in advance.

CDN (Content Delivery Network)A network that delivers content

A network of edge servers located in many countries. It keeps copies of files such as images, CSS and JavaScript close to users. Users get those files faster, and the origin server has less work.

A CDN also helps with something just as important: load. Every server has a limited capacity: it can handle only so many requests per second. When more requests arrive than that, the extra ones have to wait in line, and when the line is full the server turns them away with the code 503 Service Unavailable, meaning "too busy to serve you right now." This is what happens to concert ticket sites the minute sales open.

• Reduce the work that reaches the origin with a CDN, letting edges answer static files instead.
• Add more servers and use a load balancer to split the requests among them.
• Make each request do less work, for example by keeping results that were already calculated and reusing them. (Chapter 6 of this book goes deeper.)

The big pictureFour books, one machine

Look back over the whole journey. The page you see is assembled from Frontend files (Book 01). When you press a button, a request travels to the Backend to decide what happens (Book 02). Data that must be remembered is stored in a Database (Book 03). And all of it reaches you because of the Hosting, Domain, DNS, HTTPS and CDN we just put together in this chapter. Every time you open a website, this whole machine works together in less than a second.

Before we wrap up, test whether you remember which problem each piece solves.

One last step: try explaining it in your own words. Nothing reads or grades it, but putting it together yourself is the best way to find out whether you really understand.