Internet verstehen
Chapter 1 of 6
Chapter One

You click —
and boom,
the page is there.
The internet,
understood
properly.
The internet,
understood in the
classroom.
— How the internet works: data packets, DNS, servers and browsers explained simply.

You type an address or click a link — and in half a second the page is there. But what actually happens in between? Who fetches the page, and from where? Don't worry, this is not magic. We'll look at it calmly, step by step.

Between the click and the finished page lie DNS resolution, routing across many networks, the connection setup and the transfer in packets. This page puts the building blocks in place — the network of networks, IP and TCP, DNS, the role of server and browser — and makes the journey of a data packet interactive and tangible. Factual, without myths like “the cloud”.

How does a website get from somewhere in the world onto your screen? This learning unit gets students from Year 7 up ready to understand the internet: from the data packet through DNS to server and browser. With an interactive packet journey, a quiz and discussion prompts — ideal for computer science lessons.

~ Get comfortable. We'll go through this together.
~ With the technology in context and an interactive packet journey.
~ Recommended learning unit: 2 lessons of 50 min each.
Chapter Two

What is the
internet?

A network
of networks.

A definition
for the class.

The internet is a huge network of many smaller networks, all connected to each other. Picture it like a worldwide road network: countless paths that connect everyone with everyone. Over it, devices and servers send data back and forth — images, messages, whole websites.

The internet is a federation of autonomous networks that communicate via a shared set of addresses and rules. It is packet-switched: data is broken into individual packets, routed independently and reassembled at the recipient. The common language is protocols — above all the Internet Protocol (IP) for addressing.

The internet is a network of networks. Many small networks — at your home, in school, at companies — are connected by cables and together form a worldwide network. Over it everyone exchanges data, following shared rules called protocols.

Very important: the internet is not a “cloud”. Behind every click are real cables — fibre running across countries, thick lines even deep down on the seabed — and radio links to phones and satellites. It is tangible technology, not mist in the sky.

“The cloud” is a marketing term, not a place: it simply means someone else's servers in data centres. Physically, the internet consists of fibre and copper lines, undersea cables, routers, exchange points (IXPs) and radio links (mobile, satellite). This hardware reality explains latency, bandwidth and resilience.

Watch out, common misconception: the internet is not a “cloud”. Behind every connection are real cables — including giant undersea cables on the seabed that connect entire continents — and radio to phones and satellites.

The internet is a network of networks — made of real cables and radio, not of a cloud.
Core idea: packet-switched communication over loosely coupled, autonomous networks that speak a shared protocol (IP).
Protocol stack (simplified): IP addresses and routes individual packets (connectionless, “best effort”). TCP sits on top and provides reliability: ordering, acknowledgements, resending lost packets. UDP is the lean alternative without these guarantees (e.g. for live video). On top sit application protocols like HTTP/HTTPS.
Layered model — who does what: So that so many devices work together, communication is split into layers. In practice the TCP/IP model with four layers is what counts; the older OSI model has seven and serves as a teaching reference.
  1. Application (OSI 5–7): HTTP, DNS, TLS — what the programs “speak”.
  2. Transport (OSI 4): TCP/UDP — ports, reliability, data streams.
  3. Internet (OSI 3): IP — addressing and routing across network boundaries.
  4. Network access (OSI 1–2): Ethernet, Wi-Fi, fibre — bits on the actual medium.
Each layer relies on the one below and does not know its details — exactly what makes the internet interchangeable and extensible (encapsulation: each layer wraps its header around the data of the one above).
Hardware shapes the experience: At internet exchange points (IXPs, e.g. DE-CIX Frankfurt) many networks swap data directly — shorter paths, lower cost. Latency is the delay (round-trip time, RTT, in milliseconds) and is physically limited by the speed of light in fibre; bandwidth is the throughput (data per second). The two are independent: a satellite link can have high bandwidth and yet high latency. Jitter (varying latency) and packet loss round out the picture.
📚 Learning objectives
  • You can explain the internet as a network of networks.
  • You can refute the myth “the internet is a cloud” with real examples (undersea cables, radio).
  • You know that data is transmitted in packets.
📖 Key terms
  • Network of networks: many small networks that together form the internet.
  • Protocol: an agreed rule by which devices talk to each other.
  • Packet switching: data travels in small, independent chunks.
💡 Did you know…

Over 95% of the world's internet traffic between continents runs through undersea cables on the seabed — not via satellites.

❓ Quiz
What best describes the internet?

Answer B: “A worldwide network of many connected networks.”

A (a single large company) is wrong — no one owns the internet alone. C (a cloud in the sky) is an image, not technology. Only B describes reality.

For the teacher — options: A: “A single large computer of one company.” / B: “A worldwide network of many connected networks.” / C: “A cloud in which data floats.”

🎯 Extended objectives (Bloom's taxonomy)
  • L1 — Knowledge: students name three physical components of the internet (cables, routers, radio).
  • L2 — Comprehension: students explain “network of networks” in their own words.
  • L3 — Application: students correctly classify examples (Wi-Fi at home, undersea cable, school network).
  • L4 — Analysis: students discuss why “the cloud” is a misleading image.
⏱ Timing for this chapter (≈ 15 min)
  • 2 min: read the lead text together.
  • 4 min: collect on the board: “What is physically behind the internet?”
  • 3 min: discuss the “Did you know…” fact about undersea cables.
  • 4 min: quiz in small groups — guess first, then reveal.
  • 2 min: discussion: “Why do we say ‘cloud’ even though it's cables?”
💬 Discussion guidance

Question: “When you send a photo to a friend in another country — which route do you think it takes?”

🔗 Cross-reference

Which data is actually travelling and who can see it is explored in depth by the sister site Datenschutz verstehen (Understanding privacy).

Chapter Three

The journey of a
data packet.

From click to
server — and back.

Follow a
data packet.

Now it gets exciting: we follow a single data packet on its journey — from your device to the server that holds the website, and back again. Just press “Next” and see for yourself what happens at each stop.

Follow a request along the path device → router → provider → DNS → web server and back. Each step shows a phase: address resolution, forwarding, the request and the packet-by-packet response from which the browser renders the page. By click, “Next” or arrow keys.

Click your way through the journey of a data packet! At each stop you learn what is happening right now. With “Next” you send the packet to the next stop — or jump straight to a stop with Tab and Enter. How many stops lie between the click and the page?

The journey of a data packet
Press “Go” and then “Next” — the packet travels from stop to stop. Controls: “Next”/“Back”, click a stop, or arrow keys ←/→ on the scene. Use “Next” to go step by step. Press Tab to jump to a stop, Enter to select it.

Ready?

Press “Go” and follow a data packet on its journey from your device to the web server — and back again.

Step 0 of 6
  • Your devicePacks your request into data packets and sends them off.
  • RouterThe door to the internet — forwards packets in the right direction.
  • ProviderYour provider connects you to the worldwide network.
  • DNS serverThe phone book: looks up the IP address for the domain.
  • Web serverHolds the page and sends it back in packets.
  • Your browserReassembles the packets and builds the finished page.
In reality: Between provider and server lie many more stations (hops) across several networks; routers make the routing decisions dynamically. Before the HTTP request, TCP performs the connection setup (three-way handshake); with HTTPS there is additionally the TLS handshake. The DNS response is often cached, so not every request has to look it up anew.
What's inside a packet: Every IP packet carries a header with source and destination IP address, a TTL (Time to Live — a counter that decreases per hop and prevents endless loops) and a checksum, then the payload. TCP adds source/destination port as well as sequence and acknowledgement numbers, with which the recipient restores the order and re-requests anything lost. Packets of the same page can travel on different routes and arrive out of order — TCP sorts this out transparently.
Routing & BGP — how the network finds the way: The internet consists of thousands of autonomous systems (AS), e.g. providers and large companies. Among themselves they exchange, via BGP (Border Gateway Protocol), which IP ranges are reachable through them. Routers decide packet by packet, based on these tables, on the next hop — there is no fixed line from A to B. If one route fails, packets usually reach their destination via another. With traceroute you can make the hops of a connection visible.
The TCP three-way handshake:
  1. SYN — the client proposes a connection and states its initial sequence number.
  2. SYN-ACK — the server confirms and states its own.
  3. ACK — the client confirms; from now on the connection is established and data can flow.
Only after that does the TLS handshake begin (with HTTPS), then the actual HTTP request. Each of these steps costs at least one round-trip time — which is why high latency is felt especially during connection setup.
📚 Learning objectives
  • You can name the stops between device and web server in the correct order.
  • You can explain why a request goes to the DNS server first.
  • You understand that the response comes back in many packets.
❓ Quiz
What happens at the very start when you type an address?

Answer A: “Your device breaks the request into small data packets.”

First the data is packed into packets, then they travel off. B (the server calls you) and C (the image arrives in one piece) are wrong.

Options: A: “Your device breaks the request into data packets.” / B: “The web server calls your device first.” / C: “The whole page arrives in one piece.”

⏱ Timing (≈ 18 min) — core of the lesson
  • 5 min: interactive packet journey on the projector, class names each stop.
  • 5 min: go through the station legend, find your own analogies (post, road).
  • 5 min: discussion “Why break data into packets?” (resilience, routes).
  • 3 min: quiz + answers.
🎯 Method tip

Let one child play the “packet courier” who physically walks a note (the packet) from desk to desk (the stops) — mirroring the animation.

🖨 Mini worksheet
  1. Draw the route of a data packet from your device to the server.
  2. Why does the packet ask the DNS server first?
  3. Explain in one sentence what your browser does at the end.
Chapter Four

The phone book
of the internet.

DNS: names
become addresses.

From name
to number.

You remember names like “wikipedia.org”. Computers, though, prefer to work with numbers — the IP addresses. To make both fit together, there is the DNS, the Domain Name System. It works like a huge phone book: you give the name, it returns the matching number.

The Domain Name System translates domain names into IP addresses. It is a distributed, hierarchical database: a resolver works its way down from the root servers via the top-level domain (e.g. .org) to the domain's authoritative name server. Results are cached with a TTL to reduce load and latency.

People remember names, computers need numbers. The DNS (Domain Name System) translates between the two: from the name “wikipedia.org” it produces the IP address at which the server is actually reachable. Like a phone book, only lightning-fast and worldwide.

Example URL: https://www.webhoch.com/blog/internet. The scheme is https, the domain www.webhoch.com, the path /blog/internet.

  • Scheme https:// — how the connection is made. “https” means: encrypted and secure.
  • Domain www.webhoch.com — the name of the site. Behind it (via DNS) sits an IP address.
  • Path /blog/internet — the specific page within the domain, like a chapter in a book.

A whole address that you see in the bar is called a URL. It tells your browser: how to connect (https), which site is meant (the domain) and which part of it (the path).

Terms cleanly separated: IP address = technical identifier (IPv4 like 192.0.2.10, or IPv6). Domain = the name resolved via DNS. URL = scheme + host (domain) + optionally port, path, query, fragment. Subdomains (www., mail.) are sub-areas of a domain.
How a DNS resolution works: Your device asks a recursive resolver (usually at your provider or a public one like 1.1.1.1). If it does not have the answer in its cache, it queries down the hierarchy:
  1. Root server (.): “For .org, this name server is responsible.”
  2. TLD server (.org): “For wikipedia.org, that authoritative server is responsible.”
  3. Authoritative name server: “wikipedia.org has the IP address X.”
The recursive resolver handles this chain for you; the queried servers each answer only iteratively with the next step.
Important DNS entries (records): A = name → IPv4 address, AAAA = name → IPv6 address, CNAME = reference to another name (alias), MX = responsible mail server, NS = responsible name server, TXT = free text values (e.g. for email authenticity). Each entry has a TTL (Time to Live) in seconds — that's how long it may be cached before it is looked up again. Small TTLs allow fast moves, large ones relieve the system.
📚 Learning objectives
  • You can explain what DNS is for (name → IP address).
  • You can distinguish URL, domain and IP address.
  • You can read out the parts of a URL correctly.
💡 Did you know…

If you type an IP address directly into the browser, you often land on the same page as via the name — the name is just the convenient wrapper for the number.

❓ Quiz
What is the DNS responsible for?

Answer C: “It translates domain names into IP addresses.”

DNS does not store websites (A) and does not encrypt anything (B) — it is the phone book that resolves names to numbers.

Options: A: “It stores all the websites in the world.” / B: “It encrypts your data.” / C: “It translates domain names into IP addresses.”

⏱ Timing (≈ 14 min)
  • 3 min: introduce the phone-book analogy.
  • 4 min: take the URL card apart together on the projector.
  • 4 min: break down the class's own favourite URLs.
  • 3 min: quiz + answers.
🖨 Mini worksheet
  1. Mark the scheme, the domain and the path in a URL.
  2. Explain the difference between a domain and an IP address.
  3. Why does DNS exist at all — why don't we just type numbers?
🔗 Cross-reference

What the “s” in “https” means and how a secure connection is established is covered by the page Sicher im Netz (Safe online).

Chapter Five

Browser, server
and “loading”.

How code
becomes a page.

Who asks,
who answers?

Two players are enough for a website to appear: the server, which holds the page, and the browser on your device, which fetches and shows it. Tap a card to learn more.

The server delivers resources on request (HTML, CSS, JavaScript, images); the browser is the render engine that builds the visible document from them. Tap a card for details on each building block.

A website comes about through teamwork: the server holds it ready, the browser fetches it and assembles it on your screen. Tap the cards and discover what HTML, CSS and “loading” mean.

The server

A computer that holds and delivers websites.

Tap for details Show less
A server is a computer that never sleeps. It sits in a data centre and waits for someone to request its pages. When a request comes in, it sends the matching page back.
A web server is software (e.g. nginx, Apache) on a permanently reachable host. It accepts HTTP requests, determines the resource and delivers it with a status code and headers — static or dynamically generated by an application.

The browser

The program that fetches and shows the page.

Tap for details Show less
Firefox, Chrome, Safari, Edge — these are browsers. They make the request to the server, receive the response and build the page you see from it. The browser is your window to the web.
The browser parses HTML into the DOM, CSS into the CSSOM, runs JavaScript and produces the render tree from them, which becomes layout and paint. It also manages connections, caching, security (same-origin policy) and rendering.

HTML & CSS

The blueprint and the look of a page.

Tap for details Show less
HTML is the blueprint: it says what is on the page — heading, text, image. CSS is the look: colours, fonts, spacing. The browser reads both and assembles the finished, pretty page from them.
HTML describes structure and semantics (elements, hierarchy), CSS the presentation (layout, typography, colours). JavaScript adds behaviour. The clean separation of content, presentation and behaviour is a core principle of the web.

What does “loading” mean?

The page is fetched and built up piece by piece.

Tap for details Show less
“Loading” means: the browser fetches all the parts of the page one after another — first the blueprint, then images, fonts and more. That's why sometimes the text appears first and only then the images. Once everything is there, the page has “finished loading”.
When loading, the browser retrieves the HTML, discovers the linked resources in it (CSS, JS, images) and requests them — partly in parallel. Render-blocking resources, caching and compression determine how quickly the page becomes usable.
HTTP in one sentence: The browser sends a request (e.g. GET /index.html), the server replies with a status code (200 OK, 404 Not Found) and the resource. HTTPS is the same, only over a connection encrypted with TLS.
Ports & HTTP versions: The standard ports are 80 (HTTP) and 443 (HTTPS) — the port tells the server which service is meant. HTTP/1.1 uses one request after another per connection, HTTP/2 bundles many requests in parallel over one connection (multiplexing), HTTP/3 builds on QUIC over UDP and copes better with packet loss and connection changes (e.g. Wi-Fi → mobile).
The TLS handshake (the “s” in https): After the TCP connection setup, browser and server negotiate an encrypted connection: the server identifies itself with a certificate (signed by a trusted authority), both agree on methods and exchange keys. From then on the transfer is encrypted — eavesdropping and tampering in transit are prevented. This protects the connection, not the content from the recipient.
Critical Rendering Path — from code to picture: The browser builds the page in traceable steps:
  1. Parsing: HTML → DOM, CSS → CSSOM.
  2. Render tree: DOM and CSSOM are combined into the visible tree.
  3. Layout: the position and size of each element are calculated.
  4. Paint & composite: pixels are drawn and assembled.
JavaScript can change the DOM afterwards and influence rendering. Render-blocking resources (above all CSS and synchronous JS) delay the first visible content.
CDNs — content closer to you: A Content Delivery Network mirrors content (images, scripts, whole pages) onto many servers worldwide. Your request lands at the nearest node — this lowers latency and load on the origin server and absorbs spikes. That's why the same page often loads noticeably faster from nearby, even when the operator sits far away.
📚 Learning objectives
  • You can distinguish the roles of server and browser.
  • You can explain what HTML and CSS each do.
  • You can describe in your own words what “loading” means.
❓ Quiz
What does the browser do with the HTML the server sends?

Answer B: “It builds the visible page from it.”

The browser does not show the code (A) and does not send it back (C) — it interprets HTML and CSS and renders the page.

Options: A: “It shows the code as text.” / B: “It builds the visible page from it.” / C: “It sends it to the DNS server.”

⏱ Timing (≈ 16 min)
  • 4 min: role play: one child is the “server”, one the “browser” — act out request and response.
  • 5 min: open and discuss the cards on the projector.
  • 4 min: load a real page in the browser and watch it build (network tab optional).
  • 3 min: quiz + answers.
🖨 Mini worksheet
  1. Who holds the page ready, who fetches it? Match “server” and “browser”.
  2. What does HTML describe, what does CSS describe?
  3. Why, when loading, does the text sometimes appear first and then the image?
Chapter Six

Who owns
the internet?

Decentralised —
and open.

No one —
and everyone at once.

The surprising answer: no one alone. There is no owner and no big off switch. Instead, the individual parts belong to many different people and companies — and everyone follows shared rules of the game. That is exactly what makes the internet so robust.

The internet is decentralised and has no owner. Providers run networks, organisations run servers, and non-profit bodies coordinate what is shared: the IETF develops protocol standards, ICANN/IANA manages names and addresses. This distributed governance is the reason for resilience and openness to innovation.

No one owns the internet — and that's a good thing. The parts belong to many different participants, but everyone follows shared rules (protocols). Because it is decentralised, no one can simply “switch it off”, and new ideas can come from anywhere.

  • Decentralised means: no boss. Many small parts together make up the whole.
  • Providers run the lines. They bring the internet to your home.
  • Open rules for everyone. Shared standards make sure everything fits together.
  • Net neutrality. The idea that all data is treated equally — no matter who it's from.
  • Openness protects you. It makes the network robust and lets new things emerge.
  • No one alone. The internet has no owner.
  • Many participants. Providers, companies, organisations — each a piece.
  • Shared standards. Bodies like the IETF and ICANN maintain the rules.
  • Net neutrality. Data should be treated equally.
  • Open = robust. No single off switch, lots of innovation.
  • Decentralised topology. Loosely coupled autonomous systems, no single point of control.
  • Standardisation. IETF RFCs define protocols across vendors.
  • Name/address management. ICANN/IANA coordinate the DNS root and IP allocation.
  • Net neutrality. Equal treatment of traffic — handled differently by regulators.
  • Openness as a principle. Low barriers to entry foster resilience and innovation.
IPv4, IPv6 and address scarcity: IPv4 has only about 4.3 billion addresses (32 bit) — long since too few for all devices. Transition techniques like NAT (several devices share one public address) stretch the supply. The real solution is IPv6 with 128 bit, i.e. a practically inexhaustible number of addresses (e.g. 2001:db8::1). IPv4 and IPv6 have run in parallel for years; many connections already use IPv6 today without you noticing.
Net neutrality — why it is contested: The principle says that providers treat all data packets equally — regardless of sender, content or service. Against it stand models like zero-rating (certain services don't count towards your data allowance) or paid fast lanes. Supporters see net neutrality as the basis for fair competition and freedom of expression; critics point to necessary traffic management. Regulation differs considerably by country and over time.
Now you know what happens between the click and the page: packets travel, DNS looks up addresses, server and browser play together — over a network that no one owns alone. Not magic, but clever, open technology.
From packet via DNS to rendering: the internet is a surprisingly coherent layering of simple principles — packet switching, shared protocols, decentralised governance. Whoever knows these building blocks sees through not only the loading process but also debates about security, privacy and openness.
You now understand the path from your click to the finished page — and why the internet is so open and robust. Pass it on: explain it to friends and family. Whoever understands how something works uses it more confidently.

🍎 For teachers: teaching pack

This page can be used as a complete double lesson “How does the internet work?” in computer science class. All content is free to use (CC BY 4.0) — please credit “Webagentur Hochmeir e.U. (webhoch.com)” as the source. The “mini worksheet” tasks in the chapters serve as a printable template.

📦 Open the full teacher pack — in German (4 worksheets, test, homework, parent letter)

📅 Suggestion: double lesson (90 min)

  1. 10 min — Warm-up: “What actually happens when you open a page?” Collect guesses.
  2. 15 min — Chapter 2: the internet as a network of networks; debunk the “cloud” myth.
  3. 20 min — Chapter 3: interactive packet journey on the projector + station legend.
  4. 15 min — Chapter 4: DNS as a phone book; take a URL apart together.
  5. 15 min — Chapter 5: server vs. browser, HTML/CSS, “loading” — role play.
  6. 15 min — Chapter 6 + wrap-up: who owns the internet, net neutrality, quiz review.

Differentiation: weaker groups stay in Simple mode; stronger ones switch to “In Detail” for protocols (TCP/IP) and governance.

Frequently asked

Frequently asked questions

The most important questions about the internet — compact and easy to look up.

A quick reference about the internet. Answers are embedded in FAQPage schema for search engines and AI assistants.

The internet is a worldwide network of many smaller networks that are connected to each other. Computers, phones and servers exchange data over it — via real cables (including under the sea), via fibre optics and via radio. It is not a “cloud” but tangible technology: cables, devices and agreed rules by which everyone talks to each other.
Your device breaks the request into small data packets and sends them via your router to your provider. First a DNS server is asked which IP address belongs to the name (e.g. webhoch.com). With this address the request travels to the web server that holds the page. The server sends the page back — again in packets — and your browser reassembles it into the finished page. This often takes only half a second.
Instead of sending a whole website in one piece, the internet breaks it into many small chunks — the data packets. Each packet carries a sender, a recipient and a number. The packets travel independently through the network, often on different routes, and are put back into the correct order at the recipient based on their numbers. If one is lost, only that single packet is requested again.
DNS stands for Domain Name System. It is the phone book of the internet: people remember names like wikipedia.org, but computers need numbers — the IP addresses. The DNS server looks up the matching IP address for the name so that your request finds the right server. Without DNS you would have to remember a long string of digits for every site.
An IP address is the technical number of a device on the network (e.g. 192.0.2.10). A domain is the memorable name for it (e.g. webhoch.com). A URL is the full address of a page and contains the domain plus further parts: the protocol (https://), often a subdirectory (/blog) and sometimes a specific page. In short: the domain is the name, the IP address is the number behind it, the URL is the precise signpost to a page.
A server is a computer that holds websites and delivers them on request — it runs around the clock in a data centre. A browser is the program on your device (e.g. Firefox, Chrome, Safari) that makes the request, receives the response and assembles the visible page from the delivered HTML, CSS and JavaScript. The browser asks, the server answers.
No. The internet is the infrastructure — the worldwide network of connected devices and cables. The World Wide Web (the “websites” you view in your browser) is only one service that runs on the internet. Email, video streaming and messengers also use the internet but are not part of the web. So the web is a part of the internet, not the whole thing.
No one alone. The internet is decentralised: there is no owner and no central on/off switch. Instead, individual parts belong to many different participants — providers operate the lines, companies and organisations run servers, and non-profit bodies maintain the shared rules and the allocation of names and addresses. This openness is one reason the internet is so resilient.
Powered by webhoch.com