In diesem Artikel
- Die Adresszeile ist kein Teleporter
- DNS liefert die Information, wo es hingeht
- Datenpakete wissen nichts von schönen Webseiten
- TCP oder QUIC: zwei verschiedene Wege
- HTTPS schützt Inhalte, aber nicht jede Spur
- HTTP: Jetzt wird die Seite angefordert
- Der Browser macht aus Daten eine Oberfläche
- Wer kann eigentlich was sehen?
- Schau deinem eigenen Browser zu
- Häufige Fragen
- Quellen
Eine Adresse eintippen, Enter drücken – und Sekundenbruchteile später ist die Seite da. Aber dazwischen passiert erstaunlich viel: Namensauflösung, Routing, Verschlüsselung, Anfragen, Antworten und schließlich baut der Browser aus Code eine sichtbare Webseite. Wir verfolgen diese Reise Schritt für Schritt – ohne so zu tun, als würde jeder Aufruf exakt gleich ablaufen.
01 — Die Adresszeile ist kein Teleporter
Stell dir vor, ich öffne auf Cthulhu https://www.example.com/. Der Browser zerlegt die Adresse: https ist das Schema, www.example.com der Host und / der Pfad. Ein Fragment wie #abschnitt bleibt normalerweise im Browser und wird nicht als HTTP-Anfragepfad übertragen.
Schon bevor ein Paket ins Internet geht, können Cache, eine bestehende Verbindung oder ein Service Worker ins Spiel kommen. Weiterleitungen, HSTS und Browser-Regeln verändern den Ablauf. Die folgenden neun Stationen sind ein typisches Erklärmodell, kein Mitschnitt eines bestimmten Seitenaufrufs.
02 — DNS liefert die Information, wo es hingeht
Das Domain Name System stellt unter anderem A- und AAAA-Einträge bereit, die einen Hostnamen mit IPv4- oder IPv6-Adressen verknüpfen. Browser oder Betriebssystem fragen dafür einen Resolver. Der hat die Antwort vielleicht schon gespeichert oder muss andere DNS-Server fragen.
DNS geht nicht zwingend unverschlüsselt zum Internetanbieter: Lokale Caches, DNS over HTTPS, DNS over TLS, VPNs und Firmenrichtlinien spielen mit hinein. Auch eine IP-Adresse steht nicht automatisch für einen einzelnen Rechner. CDNs, Reverse Proxies und Anycast können hinter derselben Adresse stecken. Unsere Beispieladresse 203.0.113.42 ist für Dokumentation reserviert und ausdrücklich nicht die echte IP von example.com.
03 — Datenpakete wissen nichts von schönen Webseiten
Dein Rechner überträgt Daten zunächst über das lokale Netzwerk und dann über Router Richtung Ziel. Ethernet oder WLAN bedienen den lokalen Abschnitt; IP liefert die Adressierung über Netzgrenzen hinweg. Router müssen kein HTML verstehen, um Pakete weiterzuleiten.
Der Weg kann sich jederzeit ändern. DNS-Anfragen und Webverbindungen sind zwei getrennte Vorgänge: Dein Browser schickt die HTTP-Anfrage normalerweise nicht durch den DNS-Resolver. Ein CDN kann die Verbindung in deiner Nähe annehmen und Inhalte im Hintergrund von anderen Servern beziehen.
INTERAKTIVES LABOR · MISSION 01
Die Reise eines Seitenaufrufs
Wähle eine Station und vergleiche HTTP/2 mit HTTP/3. Alles wird hier im Browser simuliert.
Schritt 1 / 9
Die Adresse
Der Browser prüft Adresse und Caches, bevor er neue Netzwerkverbindungen anlegt.
https://www.example.com/
04 — TCP oder QUIC: zwei verschiedene Wege
HTTP/1.1 und HTTP/2 verwenden normalerweise TCP. Vor der Übertragung von Anwendungsdaten steht ein Verbindungsaufbau, oft als SYN, SYN-ACK und ACK dargestellt. TCP stellt einen zuverlässigen, geordneten Bytestrom bereit. Wiederholte Übertragungen bei Verlusten passieren unterhalb von HTTP.
HTTP/3 funktioniert anders: Es nutzt QUIC über UDP, nicht TCP. QUIC bietet verschlüsselte, voneinander unabhängige Datenströme und integriert den TLS-1.3-Verbindungsaufbau. Ein Browser kann HTTP/3 etwa durch frühere Verbindungen, Alt-Svc oder HTTPS-DNS-Records entdecken und bei Problemen auf TCP-basiertes HTTP zurückfallen. Mit dem Schalter in unserem Labor kannst du beide Wege gegenüberstellen – ohne die Handshakes zu vermischen.
05 — HTTPS schützt Inhalte, aber nicht jede Spur
Bei HTTPS über TCP authentifiziert TLS den Server mithilfe einer Zertifikatskette und vereinbart die Verschlüsselung, bevor geschützte HTTP-Daten übertragen werden. Bei QUIC ist TLS 1.3 Teil des QUIC-Handshakes – kein zusätzlicher Schritt nach einem TCP-Aufbau.
HTTPS schützt Anfragenpfade, Inhalte und die meisten Header auf dem Übertragungsweg. Es macht dich aber nicht anonym: Ziel-IP-Adressen bleiben fürs Routing sichtbar, DNS ist je nach Konfiguration beobachtbar und Teile der TLS-Verhandlung können den Hostnamen verraten, wenn beispielsweise ECH nicht genutzt wird. Die Zielwebseite kann natürlich weiterhin verarbeiten, was du ihr sendest.
06 — HTTP: Jetzt wird die Seite angefordert
Ein einfacher Aufruf entspricht sinngemäß GET /. Daneben überträgt HTTP beispielsweise den Zielhost, akzeptierte Formate und eventuell passende Cookies. HTTP/2 und HTTP/3 verwenden binäre Frames statt der reinen HTTP/1.1-Textdarstellung – unser Labor zeigt die Inhalte bewusst menschenlesbar.
Die Antwort enthält einen Status: 200 bedeutet Erfolg, 301/302 stehen für Weiterleitungen, 304 bestätigt die Gültigkeit einer Cache-Version und 404 meldet eine fehlende Ressource. Es bleibt nicht zwingend bei einer Anfrage; Weiterleitungen und Anmeldung können zusätzliche Schritte auslösen.
07 — Der Browser macht aus Daten eine Oberfläche
HTML wird gelesen und in den DOM (Document Object Model) verwandelt. CSS erzeugt das CSSOM. Daraus werden Darstellung und Layout berechnet, anschließend werden Pixel gezeichnet. JavaScript kann den DOM verändern, weitere Daten laden und die Darstellung beeinflussen.
Bilder, Schriften, Skripte und Stylesheets verursachen häufig weitere HTTP-Anfragen. Die können gleichzeitig laufen, andere Hosts ansprechen und vorhandene Caches nutzen. Eine Seite kann schon benutzbar sein, obwohl noch Dateien nachladen. Den einen universellen Zeitpunkt, an dem „alles fertig“ ist, gibt es nicht.
08 — Wer kann eigentlich was sehen?
Heimnetz, DNS-Resolver, Internetanbieter, Zwischenstationen und Zielserver haben unterschiedliche Einblicke. Verschlüsselung schützt meist den HTTP-Inhalt vor rein mitlesenden Netzteilnehmern. Sie verbirgt aber nicht unbedingt, mit welcher Ziel-IP du dich verbindest. Ein Resolver kann den angefragten Domainnamen kennen; eine Website erfährt deine IP und das, was dein Browser übermittelt.
Genau dieser Unterschied wird später bei VPN, Proxy und Tor spannend: Solche Werkzeuge ändern, wer welche Verbindung beobachten kann. Sie beseitigen nicht einfach alle Vertrauensfragen.
09 — Schau deinem eigenen Browser zu
Öffne die Entwicklertools → Netzwerk, blende bei Bedarf die Protokollspalte ein und lade diese Seite neu. Du kannst die Dokumentanfrage, Statuscodes, Zeiten und weitere CSS- oder JavaScript-Dateien sehen. Die genauen Bezeichnungen unterscheiden sich je nach Browser. Ein warmer Cache sieht anders aus als ein leerer; eine HTTP/3-Verbindung wiederum anders als HTTP/2.
Unter Linux lässt getent ahosts www.example.com den Rechner einen Host auflösen. curl -I https://www.example.com/ fragt dagegen die HTTP-Header ab – und verursacht eine echte Verbindung. Unsere nachfolgende Paketreise bleibt vollständig lokal und schickt keine Testpakete ins Netz.
Häufige Fragen
Muss bei jedem Aufruf eine DNS-Anfrage passieren?
Nein. DNS-Caches, bestehende Verbindungen, lokale Richtlinien oder Service Worker können einzelne Schritte ersetzen oder die Reihenfolge verändern.
Versteckt HTTPS, welche Seite ich besuche?
Es schützt große Teile der HTTP-Kommunikation. Die Ziel-IP bleibt aber für das Routing sichtbar; DNS oder bestimmte Handshake-Daten können Rückschlüsse auf die Domain erlauben.
Benutzt HTTP/3 weiterhin TCP?
Nein. HTTP/3 verwendet QUIC über UDP, einschließlich eines integrierten TLS-1.3-Handshakes.
Ist die Paketreise eine echte Netzwerkmessung?
Nein. Sie ist eine lokale Lernsimulation mit einer reservierten Beispieladresse und ohne Netzwerktests.
Quellen und Einordnung
Der Artikel ist eine didaktische Vereinfachung. Die Dokumentation erklärt die verwendeten Protokolle und den Rendering-Prozess genauer. Unsere Animation ist keine Messung einer echten Verbindung.