Inclusive App Craft
Request a quote

Web Foundations 15 min

How the Internet Works

  • You're previewing this lesson. Enrol free to unlock the full course, quizzes, and your certificate.

    • Let's start with something you do every day without thinking about it: you type an address into your browser, and a moment later a whole page appears. What just happened in that moment? Behind that little pause is a fast, elegant conversation between machines — and understanding it is the foundation everything else in this course rests on. So before you write a single line of code, let's follow a web page on its journey to your screen.

    The web is a conversation

    Picture ordering a meal at a restaurant. You (the customer) ask the waiter for a dish; the kitchen prepares it; the waiter brings it back. You don't cook it yourself, and you don't need to know how the kitchen works — you just ask, and you receive. The web works exactly like this, and it has two roles: a client that asks, and a server that answers.

    Your browser is the client. When you visit a site, it sends a request across the internet to a server — a computer whose whole job is to wait for requests and send back responses. That response is usually a bundle: the HTML that describes the page, the CSS that styles it, the JavaScript that makes it interactive, plus images and fonts. Your browser gathers those pieces and assembles the page you see.

    Hold on to this picture, because it never leaves you. Later in this course, you become the person who writes the kitchen — deciding what the server sends back when a client comes asking.

    Finding the right kitchen: addresses and DNS

    Every server on the internet has an IP address — a string of numbers like 172.65.255.143 that identifies it uniquely, the way a street address identifies one building. The trouble is, people don't remember numbers; we remember names like inclusiveappcraft.com. So something has to translate the name into the number.

    That something is the Domain Name System, or DNS — and the easiest way to picture it is a phone book. You know the person's name; the phone book gives you their number; then the call goes through. When you type a web address, your browser first quietly asks a DNS server, “what's the number for this name?” Only once it has the number can it actually reach the right machine. (This is also why a brand-new website can seem slow to “go live” — that name-to-number entry is still spreading to phone books around the world.)

    The language they speak: HTTP

    Once your browser has found the server, the two of them talk in a shared language called HTTP — the HyperText Transfer Protocol. And a request is more than just “give me the page.” It carries a few things worth knowing now, because you'll work with all of them:

    • A method — the verb, what you want to do. GET means “fetch me this,” POST means “here's some data to save.”
    • A path — which thing, exactly, like /about or /courses/web.
    • Headers — extra notes about the request, such as what kind of response the client can handle.

    The server writes back with a status code that says how it went, and you'll come to know these like old friends: 200 means success, 404 means “I couldn't find that,” 500 means the server tripped over its own feet, 301 means “that's moved — look over here.”

    Why the S in HTTPS matters

    Plain HTTP sends everything as readable text. Imagine posting a letter written on the outside of the envelope — anyone who handles it along the way can read it. On shared café Wi-Fi, that's roughly what plain HTTP is, and it's how passwords and personal details could be snooped in transit.

    HTTPS is the same conversation, sealed in an envelope. The S stands for “secure,” and it does two jobs: it scrambles the data so only the intended server can read it, and it proves the server really is who it claims to be, using a certificate from a trusted authority. That's why browsers warn you away from plain-HTTP pages, and why every professional site today uses HTTPS. When you deploy your own projects later, switching that padlock on will be one of your steps — and by then you'll know exactly what it's protecting.

    The whole journey, in six steps

    Let's put it all together and trace one visit to https://example.com, start to finish:

    1. You type the address. The browser asks DNS for the IP number behind example.com.
    2. DNS answers. The browser opens a secure (HTTPS) connection to that server.
    3. The browser sends an HTTP GET request for the page.
    4. The server does its work and sends back an HTTP response — a status code plus the HTML.
    5. The browser reads the HTML, notices it also needs CSS, JavaScript, and images, and asks for those too.
    6. As the pieces arrive, the browser renders the finished page — and builds the accessibility tree that screen readers use to describe it.

    All of that, usually, in well under a second — every single time you open any page anywhere.

    One idea to carry with you

    Here's something worth saying plainly, because it shapes everything this course teaches. The web was designed so that anyone, on any device, could reach any content. Your HTML isn't just pixels for one screen — it's structured meaning a browser can show as a page, a screen reader can speak aloud, and a search engine can understand. Building for that universality isn't extra work bolted on at the end. It's what the web is for — and you'll learn to build that way from your very first page.

    Key terms from this lesson

    • Client / server — the one who asks (your browser) and the one who answers (the machine that responds).
    • IP address — the numeric address of a machine on the internet.
    • DNS — the phone book that turns domain names into IP addresses.
    • HTTP — the request-and-response language of the web, with methods like GET and POST and status codes like 200 and 404.
    • HTTPS — HTTP sealed in an envelope: encrypted, with a certificate proving the server's identity.