Wie der Browser eine Webseite anzeigt
Eine Webseite erscheint nicht unverändert in dem Moment, in dem Sie eine URL in den Browser eingeben.
Tatsächlich laufen nacheinander mehrere Schritte ab: Interpretation der URL, Ermittlung der IP-Adresse durch DNS, Verbindung zum Server, Aufbau eines sicheren Kommunikationskanals durch HTTPS, Senden einer HTTP-Anfrage, Empfang der Serverantwort und Darstellung durch den Browser.
Nicht jedes Mal laufen alle Schritte vollständig von vorn ab. DNS-Ergebnisse können gecacht sein, bereits aufgebaute Verbindungen können wiederverwendet werden, und Daten können aus dem Browsercache gelesen werden.
Dieser Artikel ordnet ohne zu viele Spezifikationsdetails, was bis zur Anzeige einer Webseite geschieht.
Was passiert nach der Eingabe einer URL?
Nehmen wir an, Sie geben in die Adressleiste des Browsers https[:]//example.com ein.
Der Browser prüft zuerst die eingegebene Zeichenfolge.
Er beurteilt, ob es sich um Suchbegriffe oder um eine URL handelt. Wenn es eine URL ist, interpretiert er das Ziel.
Eine URL enthält hauptsächlich folgende Informationen.
| Element | Beispiel | Bedeutung |
|---|---|---|
| Schema | https | Zeigt, mit welchem Verfahren kommuniziert wird |
| Hostname | example.com | Name der Website, zu der verbunden werden soll |
| Portnummer | 443 | Zeigt, zu welchem Kommunikationszugang verbunden wird; oft weggelassen |
| Pfad | /about | Zeigt, welchen Ort auf dem Server man anfordert |
| Query-String | ?id=10 | Übergibt zusätzliche Informationen an den Server |
| Fragment | #section | Zeigt eine Position innerhalb der Seite; wird normalerweise nicht an den Server gesendet |
Eine URL ist eine für Menschen leicht nutzbare Form zur Angabe einer Website.
Um den Kommunikationspartner im Netzwerk zu finden, wird am Ende jedoch eine IP-Adresse benötigt.
Deshalb geht der Browser zur Ermittlung der IP-Adresse aus dem Hostnamen über.
DNS ermittelt die IP-Adresse
Mit dem Namen example.com allein kann der Browser keine Verbindung zum Server herstellen.
Dafür wird DNS verwendet.
DNS ordnet Domainnamen IP-Adressen zu.
Browser oder OS prüfen zuerst, ob ein DNS-Ergebnis bereits intern vorhanden ist. Wenn dieselbe Domain früher aufgerufen wurde, kann die IP-Adresse aus einem DNS-Cache stammen.
Wenn keine Cache-Information vorhanden ist, wird ein DNS-Resolver gefragt. Der DNS-Resolver fragt bei Bedarf mehrere DNS-Server ab, um die IP-Adresse zum Domainnamen zu finden.
| Phase | Was passiert | Zweck |
|---|---|---|
| 1 | Browser oder OS prüfen den Cache | Prüfen, ob eine früher ermittelte IP wiederverwendet werden kann |
| 2 | DNS-Resolver wird gefragt | IP-Adresse zum Domainnamen ermitteln |
| 3 | A- oder AAAA-Records werden erhalten | IPv4- oder IPv6-Ziel erhalten |
| 4 | Mit der IP-Adresse wird das Verbindungsziel bestimmt | Tatsächlichen Kommunikationspartner festlegen |
Die erhaltene IP-Adresse ist nicht zwingend fest.
Auch bei demselben Domainnamen können je nach Region, DNS-Einstellung, Lastverteilung und CDN unterschiedliche IP-Adressen zurückkommen.
Verbindung zum Server
Wenn die IP-Adresse bekannt ist, verbindet sich der Browser mit dem Server, der diese IP-Adresse hat.
Bei Webkommunikation ist nicht nur die Ziel-IP-Adresse wichtig, sondern auch die Portnummer.
HTTP verwendet üblicherweise Port 80, HTTPS Port 443.
| Kommunikationsart | Haupt-Portnummer | Bedeutung |
|---|---|---|
| HTTP | 80 | Häufig für unverschlüsselte Webkommunikation |
| HTTPS | 443 | Häufig für durch TLS geschützte Webkommunikation |
Bei HTTP/1.1 und HTTP/2 wird für die Verbindung zum Server normalerweise TCP verwendet.
HTTP/3 verwendet dagegen QUIC, das über UDP läuft.
Dieser Artikel geht nicht in die Details von HTTP/2 oder HTTP/3. Wichtig ist, dass der Browser mit IP-Adresse und Portnummer einen Kommunikationsweg zum Server erstellt.
Außerdem wird nicht jedes Mal eine neue Verbindung aufgebaut. Wenn bereits eine Verbindung zum selben Server besteht, kann der Browser sie wiederverwenden.
HTTPS erstellt einen sicheren Kommunikationskanal
Wenn die URL mit https beginnt, kommuniziert der Browser per HTTPS mit dem Server.
HTTPS ist HTTP, das durch TLS geschützt wird.
TLS hat hauptsächlich folgende Rollen.
| Rolle | Bedeutung | Wichtigkeit |
|---|---|---|
| Verschlüsselung | Inhalte werden für Dritte schwerer lesbar | Schützt Passwörter und Seiteninhalte |
| Veränderungserkennung | Prüft, ob Inhalte unterwegs geändert wurden | Erschwert Veränderung durch Zwischenstellen |
| Prüfung des Gegenübers | Prüft, ob das Ziel der Server der beabsichtigten Domain ist | Schutz gegen falsche Websites und Man-in-the-Middle |
HTTPS ist also nicht nur ein Mechanismus zur Verschlüsselung.
Der Browser prüft das vom Server vorgelegte Zertifikat und verifiziert, ob es für den aufgerufenen Domainnamen gültig ist.
Durch diese Prüfung kann der Browser beurteilen, dass das Gegenüber wahrscheinlich das beabsichtigte Gegenüber ist.
Trotz HTTPS ist nicht jede Information zur Kommunikation verborgen.
Ziel-IP-Adresse, Kommunikationszeit, Datenmenge und ähnliche Informationen lassen sich durch HTTPS allein nicht vollständig verbergen.
Je nach Umgebung können außerdem Informationen zum Ziel-Domainnamen auf dem Kommunikationsweg sichtbar sein.
HTTPS ist also sehr wichtig für Schutz der Inhalte und Prüfung des Gegenübers, garantiert aber keine vollständige Anonymität.
Seite per HTTP/HTTPS anfordern
Wenn ein sicherer Kommunikationskanal erstellt ist, fordert der Browser die Seite beim Server an.
Diese Anfrage nennt man HTTP-Request.
Bei HTTPS wird der Inhalt des HTTP-Requests durch TLS geschützt gesendet.
Der Browser kann dem Server zum Beispiel folgende Informationen senden.
| Information | Bedeutung | Ergänzung |
|---|---|---|
| Methode | Welche Operation gewünscht ist | Für Seitenabruf wird häufig GET verwendet |
| Pfad | Welche Seite oder Daten gewünscht sind | Zum Beispiel / oder /about |
| Host | Für welche Domain die Anfrage bestimmt ist | Auch wichtig, wenn eine IP mehrere Websites bedient |
| User-Agent | Informationen zu Browser und OS | Wird für Umgebungsbeurteilung und Darstellung verwendet |
| Accept-Language | Bevorzugte Sprache | Dient etwa der Auswahl japanischer Seiten |
| Referer | Von welcher Seite man gekommen ist | Wird je nach Einstellung und Spezifikation nicht immer gesendet |
| Auf der Website gespeicherte Identifikationsdaten | Dient Login-Zustand und Einstellungen |
Der Server entscheidet anhand dieser Anfrage, welche Daten er zurückgibt.
Auch bei derselben URL können Login-Zustand, Cookies, Spracheinstellung und Gerätetyp den zurückgegebenen Inhalt verändern.
Der Server gibt Daten zurück
Der Server empfängt die Anfrage des Browsers und gibt eine HTTP-Response zurück.
Eine HTTP-Response enthält Statuscode, Header, Body und Ähnliches.
| Element | Beispiel | Bedeutung |
|---|---|---|
| Statuscode | 200 | Zeigt Erfolg, Fehler und Ähnliches |
| Header | Content-Type | Zeigt Datentyp, Cache-Regeln und Ähnliches |
| Body | HTML und Ähnliches | Eigentliche Daten, die der Browser nutzt |
Der Kern einer Webseite ist HTML, aber HTML allein bildet häufig nicht die ganze Seite.
Viele Webseiten werden durch Kombination mehrerer Daten angezeigt.
| Daten | Rolle |
|---|---|
| HTML | Beschreibt die Seitenstruktur |
| CSS | Legt Farbe, Abstand, Anordnung, Schriftgröße und anderes Aussehen fest |
| JavaScript | Führt Verarbeitung und dynamische Änderungen auf der Seite aus |
| Bilder | Zeigt Fotos, Icons, Diagramme und Ähnliches |
| Schriftarten | Gestaltet das Aussehen von Text |
| Video / Audio | Spielt Medieninhalte ab |
Der Browser empfängt zuerst HTML und ruft dann darin angegebene CSS-, JavaScript-, Bild- und Schriftdateien zusätzlich ab.
Deshalb entstehen oft mehrere HTTP-Anfragen, obwohl nur eine Webseite geöffnet wurde.
Der Browser zeigt die Seite an
Wenn der Browser Daten vom Server erhält, wandelt er sie in eine Form um, die auf dem Bildschirm angezeigt werden kann.
Grob laufen folgende Verarbeitungen ab.
| Phase | Was passiert |
|---|---|
| HTML-Analyse | Die Struktur der Seite wird gelesen |
| CSS-Anwendung | Regeln für das Aussehen werden angewandt |
| Layoutberechnung | Es wird bestimmt, welches Element wo liegt |
| Zeichnen | Text, Bilder, Hintergründe und Ähnliches werden angezeigt |
| JavaScript-Ausführung | Inhalte und Verhalten der Seite werden bei Bedarf geändert |
Wichtig ist: Der Browser erhält keinen fertig gerenderten Bildschirm vom Server.
Der Server gibt Materialien wie HTML, CSS, JavaScript und Bilder zurück.
Der Browser interpretiert diese und setzt die Seite passend zu Bildschirmgröße, Einstellungen und unterstützten Funktionen zusammen.
Deshalb kann dieselbe Webseite auf PC, Smartphone, verschiedenen Browsern, unterschiedlichen Bildschirmbreiten und Einstellungen anders aussehen.
Auch eine Seite kann mehrere Kommunikationen auslösen
Wichtig beim Anzeigen einer Webseite ist, dass auch eine einzelne Seite nicht nur ein einziges Kommunikationsziel haben muss.
Der Seitenkörper kann von example.com kommen, während Bilder, Werbung, Zugriffsauswertung, externe Schriftarten und externe Skripte von anderen Domains geladen werden.
| Kommunikationsziel | Zweck | Beispiel |
|---|---|---|
| Server des Seitenkörpers | HTML abrufen | Text und Seitenstruktur |
| Bildauslieferungsserver | Bilder abrufen | Artikelbilder und Icons |
| Werbeserver | Werbung anzeigen | Banner und Werbeskripte |
| Analyseserver | Zugriffe messen | Zugriffsauswertungs-Tags |
| Server für externe Schriftarten | Webfonts laden | Schriftarten |
| Server für externe Skripte | Funktionen hinzufügen | Eingebettete Widgets und UI-Teile |
Aus Nutzersicht wurde nur "eine Seite geöffnet", aber im Hintergrund können mehrere Server kontaktiert werden.
Auch nach dem Öffnen können Scrollen, Schaltflächen, Suche, Formulareingabe oder Videowiedergabe zusätzliche Kommunikation auslösen.
Viele heutige Webseiten laden zuerst nur Mindestdaten und rufen je nach Nutzerhandlung weitere Daten ab.
Cache kann Kommunikation auslassen
Beim Anzeigen einer Webseite werden nicht jedes Mal alle Daten vom Server abgerufen.
Der Browser kann früher abgerufene Bilder, CSS, JavaScript und Ähnliches vorübergehend speichern.
Das nennt man Cache.
Wenn ein Cache gültig ist, kann der Browser dieselben Daten aus dem Gerät verwenden, ohne sie erneut vom Server abzurufen.
| Ziel | Wirkung des Cache |
|---|---|
| DNS-Ergebnis | Verringert Aufwand, Domainnamen erneut in IP-Adressen aufzulösen |
| Bilder | Gleiche Bilder müssen nicht mehrfach heruntergeladen werden |
| CSS | Dateien zum Aussehen der Seite können wiederverwendet werden |
| JavaScript | Gleiche Skripte müssen nicht erneut abgerufen werden |
| Verbindung | Bestehende Kommunikationswege können wiederverwendet werden |
Cache ist wichtig, um Anzeige zu beschleunigen und Datenmenge zu verringern.
Bei Anonymität und Privatsphäre muss man jedoch auch Informationen beachten, die im Browser verbleiben, etwa Cache und Cookies.
Wichtige Perspektive für Anonymität
Für Anonymität ist wichtig, dass das Öffnen einer Webseite keine einfache einzelne Kommunikation ist.
Beim Webzugriff sind DNS, IP-Adressen, HTTPS, Cookies, User-Agent, Referer, externe Skripte, Cache und andere Elemente beteiligt.
Auch wenn HTTPS Inhalte schützt, bleiben Ziel-IP-Adresse, Timing, Datenmenge, vom Browser gesendete Header, Identifikation durch Cookies und zusätzliche Kommunikation zu externen Servern eigene Themen.
| Perspektive | Zu prüfen |
|---|---|
| DNS | Welche Domainnamen abgefragt wurden |
| IP-Adresse | Zu welchem Server verbunden wurde |
| HTTPS | Ob Verschlüsselung, Veränderungserkennung und Gegenüberprüfung erfolgen |
| Cookie | Ob eine Identifikation als derselbe Nutzer möglich ist |
| User-Agent | Ob Informationen zu Browser und OS gesendet werden |
| Referer | Ob mitgeteilt wird, von welcher Seite man kam |
| Externe Kommunikation | Ob auch Server außerhalb des Seitenkörpers kontaktiert werden |
| Cache | Ob frühere Ansichten oder abgerufene Daten im Gerät bleiben |
Besonders wichtig ist: "Kommunikationsinhalte sind verschlüsselt" und "niemand weiß, wer wohin zugegriffen hat" sind nicht dasselbe.
HTTPS ist sehr wichtig, um Inhalte zu schützen und das Gegenüber zu prüfen.
Für Anonymität muss man jedoch neben HTTPS auch DNS, IP-Adressen, vom Browser gesendete Informationen, Cookies und externe Kommunikation getrennt betrachten.
Zusammenfassung
Bis ein Browser eine Webseite anzeigt, laufen mehrere Schritte ab.
Zuerst interpretiert der Browser die eingegebene URL und prüft den Hostnamen.
Dann ermittelt DNS die zum Hostnamen gehörende IP-Adresse.
Wenn die IP-Adresse bekannt ist, verbindet sich der Browser mit dem Server.
Bei HTTPS baut TLS einen sicheren Kommunikationskanal mit Verschlüsselung, Veränderungserkennung und Prüfung des Gegenübers auf.
Danach sendet der Browser eine HTTP-Anfrage, und der Server gibt Daten wie HTML, CSS, JavaScript und Bilder zurück.
Der Browser analysiert die empfangenen Daten und zeigt sie auf dem Bildschirm an.
Während der Anzeige einer Seite können außerdem zusätzliche Kommunikationen durch Bilder, Werbung, Analyse-Tags, externe Schriftarten und externe Skripte entstehen.
Das Öffnen einer Webseite beruht auf mehr Kommunikation und Verarbeitung, als es äußerlich aussieht.
Wer diesen Ablauf versteht, kann nicht nur die Webgrundstruktur, sondern auch die Punkte besser ordnen, die für Anonymität und Privatsphäre wichtig sind.
Verwandte Werkzeuge
DNSLeakTest
Eine externe Ressource zu diesem Artikel. Öffne sie nur, wenn sie zu deiner Situation und deinem Bedrohungsmodell passt.
Warum es hier aufgeführt ist: Sie kann beim Thema des Artikels helfen, liegt aber außerhalb von Anonymity Sense und sollte vor der Nutzung geprüft werden.
BrowserLeaks WebRTC
Eine externe Ressource zu diesem Artikel. Öffne sie nur, wenn sie zu deiner Situation und deinem Bedrohungsmodell passt.
Warum es hier aufgeführt ist: Sie kann beim Thema des Artikels helfen, liegt aber außerhalb von Anonymity Sense und sollte vor der Nutzung geprüft werden.