Eine URL wird zu vielen zusammenarbeitenden Vorgängen.

Du gibst https://example.com/ in den Browser ein. Kurz darauf stehen Text, Farben und Bilder auf dem Bildschirm. Dazwischen liegt weder ein einzelnes Paket noch eine für jede Website identische Checkliste. Der Browser prüft vorhandene Informationen, beschafft fehlende Ressourcen und verarbeitet Antworten. Gleichzeitig entscheidet der Netzwerkstack für jedes zu sendende Paket, wie es den nächsten Wegabschnitt erreicht.

Wir betrachten einen bewusst überschaubaren Aufruf und verbinden dabei Ethernet und ARP, Routing, DNS und Transportprotokolle. Die interaktive Simulation ergänzt die Erklärung; alle fachlichen Schritte stehen auch im Artikel. Kein Paket wird wirklich versendet und keine Domain für das Lernbeispiel aufgelöst.

Die URL beschreibt mehr als einen Rechnernamen.

Am ergänzenden URL-Beispiel https://example.com/lernen?thema=netz#start lassen sich die Bestandteile unterscheiden. Das Schema https kennzeichnet den sicheren Webzugriff. example.com ist der Hostname. Für HTTPS gilt ohne ausdrücklich angegebenen anderen Port der Standardport 443. /lernen ist der Pfad, thema=netz die Abfrage. Das Fragment #start verarbeitet der Browser für das Dokument; es wird nicht als Fragment im HTTP-Anfrageziel an den Server gesendet. Der Pfad muss auf dem Server keine gleichnamige Datei bezeichnen: Auch eine Anwendung kann eine passende Antwort erzeugen.

Der Hauptaufruf in der Simulation verwendet den einfachen Pfad / ohne Abfrage und Fragment. Eine Origin wird bei diesem HTTPS-Beispiel durch Schema, Host und effektiven Port bestimmt: https, example.com und 443. Ein anderer Pfad ist allein keine andere Origin. Ein anderes Schema, ein anderer Host oder ein anderer effektiver Port kann sie dagegen ändern. Die Origin ist für Browser-Sicherheitsregeln wichtig. Sie ist weder eine MAC-Adresse noch gleichbedeutend mit einer bestimmten Server-IP: Ein Hostname kann über die Zeit verschiedene Adressen liefern.

Auch die Eingabe ist kein Beweis für einen neuen Netzwerkvorgang. Der Browser kann eine bereits geöffnete Verbindung nutzen oder eine Ressource aus einem geeigneten Cache laden. Eine Weiterleitung kann anschließend zu einer anderen URL führen. Unser Hauptbeispiel setzt daher ausdrücklich voraus: gewöhnlicher HTTPS-Aufruf, keine lokale Kopie der benötigten HTML-Antwort, kein Service Worker als zusätzlicher Vermittler und zunächst keine wiederverwendbare Verbindung.

Unser Labor hat klare Grenzen.

Der Client besitzt 192.168.10.20/24 und die frei gewählte Beispiel-MAC 02:00:00:00:10:20. Ein Switch verbindet ihn mit dem Heimrouter: innen 192.168.10.1, MAC 02:00:00:00:10:01. Die Außenadresse des Routers ist illustrativ 198.51.100.10/24; sein nächster Router liegt bei 198.51.100.1. Dazwischen ist ein eigener Ethernet-Link mit eigenen MAC-Adressen.

Der DNS-Resolver ist im Modell entfernt unter 203.0.113.53 erreichbar. Seine simulierte Antwort für example.com lautet 203.0.113.80. Das ist keine reale Auflösung von example.com. Die Adressen aus 198.51.100.0/24 und 203.0.113.0/24 sind offizielle Dokumentationsadressen. Im echten Internet würden wir die tatsächlichen Antworten und Routen untersuchen müssen. Die hier gezeigten MACs sind ebenfalls erfundene Laboridentitäten.

Zwischen Providerrouter und Zielnetz fasst das Modell den Transit zusammen. Es behauptet kein durchgehendes Ethernet vom Heimrouter bis zum Server. Ein Zielrouter stellt die Pakete im eigenen Server-LAN zu. Router-Nachbarinformationen sind für die Darstellung bereits vorhanden, der Nachbarcache des Clients ist anfangs leer. Adressvergabe, WLAN-Anmeldung, Internetanschluss und passende Firewallregeln gelten als vorbereitet. Ein tatsächlicher Aufruf kann an jeder dieser Voraussetzungen scheitern.

Namensauflösung benötigt selbst einen erreichbaren Weg.

Zuerst prüft der Browser beziehungsweise das Betriebssystem, ob ein verwendbares DNS-Ergebnis vorhanden ist. Bei einem Cachetreffer muss nicht erneut ein DNS-Paket zum Resolver gesendet werden. DNS-TTLs begrenzen die Gültigkeit von Einträgen; negative Antworten können ebenfalls zwischengespeichert werden. Ein DNS-Cache ist von einem HTTP-Ressourcencache zu unterscheiden: Er kann eine Adresse kennen, ohne das HTML oder auch nur eine einzige Bilddatei zu besitzen.

Bei unserem Cache-Miss benötigt der Client eine Anfrage an 203.0.113.53. Noch bevor diese DNS-Anfrage das LAN verlassen kann, betrachtet er die Route zum Resolver. Dieser liegt außerhalb seines eigenen /24. Die passende Standardroute führt zu 192.168.10.1. Da dessen MAC noch fehlt, fragt ARP lokal nach der MAC des Gateways. Erst mit der Antwort lässt sich der Ethernet-Frame für die DNS-Anfrage zustellen. „DNS, danach zum ersten Mal ARP“ wäre für genau dieses Beispiel die falsche Abfolge.

Die DNS-Abfrage verwendet hier UDP von Clientport 53000 an Resolverport 53. Der Heimrouter legt dafür eine eigene NAPT-Zuordnung auf 198.51.100.10:62001 an. Die Antwort passiert die passende Rückübersetzung und liefert im Modell den A-Eintrag 203.0.113.80. Der rekursive Resolver beantwortet sie möglicherweise aus seinem eigenen Cache; andernfalls fragt er die DNS-Infrastruktur ab. Der Browser kontaktiert nicht zwangsläufig selbst nacheinander Root-, TLD- und autoritative Server.

DNS ist nicht grundsätzlich unverschlüsseltes UDP. TCP, verschlüsselte Resolververbindungen und weitere Varianten existieren. Auch IPv6-Adressen können über AAAA ermittelt werden. Unser UDP-Beispiel erklärt einen ausgewählten Fall und keinen Pflichttransport für jeden Browser. Die Details von Rekursion und Cachegültigkeit behandelt der DNS-Artikel.

Router leiten weiter; NAPT verändert ausgewählte Endpunkte.

Der Heimrouter entfernt die eingehende Link-Kapselung und trifft seine eigene Routingentscheidung. Auf seinem WAN-Link verwendet der neue Frame die MACs 02:00:00:00:20:01 als Quelle und 02:00:00:00:20:02 als Ziel. Die Weiterleitung reduziert die IPv4-TTL. Andere Router entscheiden ebenso anhand ihrer eigenen Tabellen, ohne für jedes Paket den kompletten Weg im Browser zu hinterlegen.

Für die spätere TCP-Verbindung setzt unser NAPT die Quelle 192.168.10.20:49152 auf 198.51.100.10:62000 um. Der Zielendpunkt bleibt 203.0.113.80:443. Antworten laufen an die sichtbare äußere Quelle zurück und werden über den passenden Zustand wieder auf den Client übersetzt. Diese TCP-Zuordnung ist unabhängig vom vorherigen UDP-DNS-Zustand. Die vollständige Unterscheidung erklärt NAT und NAPT verstehen.

NAPT ist hier eine gewählte Heimnetzfunktion. Im IPv6-Szenario hat der Client stattdessen beispielhaft 2001:db8:10::20, der Server 2001:db8:30::80. Der Client erreicht seinen Standardrouter über die Link-Local-Adresse fe80::1. Wenn die Nachbaradresse fehlt, verwendet IPv6 Neighbor Discovery mit ICMPv6 statt ARP. Globale Client- und Serveradressen bleiben im gezeigten Weg ohne NAT erhalten; das Hop Limit sinkt bei Routerweiterleitungen. Alle 2001:db8-Adressen sind Dokumentation. Eine Firewall kann auch hier Verbindungen zustandsbehaftet filtern.

HTTPS kann TCP oder QUIC verwenden.

Im klassischen Hauptablauf baut der Client eine TCP-Verbindung auf: SYN zum Server, SYN-ACK zurück und ACK als Bestätigung. Darauf folgt der TLS-Handshake. TCP liefert einen zuverlässigen, geordneten Bytestrom; es verschlüsselt die Daten selbst nicht. TLS handelt kryptografische Parameter aus und authentifiziert im normalen Browserfall den Server über eine geprüfte Zertifikatskette und den passenden Namen. Ein Zertifikat für irgendeine andere Domain genügt nicht.

Beim TLS-Aufbau können Client und Server über ALPN ein unterstütztes Anwendungsprotokoll aushandeln, beispielsweise HTTP/2. Erst innerhalb des geschützten Kanals übertragen sie die eigentlichen HTTP-Anfragen und Antworten. Die Darstellung trennt Schritte zum Lernen; reale TCP-Segmente können Daten anders bündeln und TLS-Nachrichten müssen nicht je genau einem Paket entsprechen. Wiederaufgenommene Sitzungen und bereits bestehende Verbindungen können zusätzliche Aufbauschritte verkürzen.

Bei HTTP/3 nutzt der Browser dagegen QUIC über UDP. Im Modell wäre das beispielsweise Clientport 49153, außen nach NAPT 62003, mit Serverport 443. Es gibt dabei keinen TCP-Three-Way-Handshake. QUIC integriert den TLS-Handshake und verwendet daraus abgeleitete Schlüssel zum Schutz seiner Pakete; der TLS-Record-Layer von TLS über TCP wird nicht einfach über UDP gelegt. QUIC selbst stellt zuverlässige Streams bereit. UDP als Unterbau macht HTTP/3 daher nicht zu einer unzuverlässigen Übertragung.

Welche Variante verfügbar ist, hängt unter anderem vom Dienst, bereits bekannten Informationen und dem Netz ab. Eine UDP-Sperre kann den gewählten QUIC-Weg verhindern und zu einem anderen unterstützten Verfahren führen. HTTP/3 ist auch nicht „HTTP/2 auf einem anderen Port“: Es bildet HTTP auf QUIC ab und verwendet eigene Mechanismen. Den Vergleich vertieft TCP, UDP und QUIC.

Die Anfrage beschreibt die Ressource; die Antwort beschreibt das Ergebnis.

Eine HTTP-Anfrage enthält eine Methode, das Anfrageziel und Headerfelder. Für unseren Hauptaufruf fordert GET die Ressource / an. Beim ergänzenden URL-Beispiel wäre es /lernen?thema=netz, weiterhin ohne Fragment. Der Host beziehungsweise die Authority bleibt wichtig: Mehrere Websites können dieselbe Server-IP verwenden. HTTP/1.1 drückt solche Angaben unter anderem über die Request-Line und Host aus; HTTP/2 und HTTP/3 verwenden ihre jeweilige binäre Darstellung mit passenden Pseudoheadern. Ein lesbarer Lehrtext ist deshalb kein wortgetreuer Mitschnitt eines HTTP/2-Pakets.

Der Server antwortet mit einem Status und Headerfeldern sowie gegebenenfalls einem Inhalt. 200 kann eine erfolgreiche HTML-Antwort begleiten; Content-Type: text/html benennt den Medientyp. Ein 404 bedeutet, dass die angeforderte Ressource nicht gefunden wurde, und kann trotzdem eine vollständig übertragene HTML-Fehlerseite enthalten. Eine erfolgreiche TCP-Verbindung allein beweist daher nicht den fachlichen Erfolg des Seitenaufrufs. Auch ein Redirect kann eine weitere Anfrage an ein anderes Ziel auslösen.

Header steuern unter anderem Cacheverhalten, Inhaltsdarstellung und Sicherheitsregeln. Sie gehören zur HTTP-Kommunikation, nicht zum Ethernet-Header. Bei HTTPS sind sie gegenüber gewöhnlichen vermittelnden Routern im geschützten Anwendungsverkehr verborgen. Daraus folgt keine vollständige Unsichtbarkeit der Kommunikation: IP-Adressen, Ports und weitere Metadaten bleiben je nach Transport und Netz beobachtbar.

Aus übertragenen Ressourcen entsteht eine sichtbare Seite.

Der Browser verarbeitet HTML während des Empfangs und baut daraus den Dokumentbaum, das DOM. Verweise auf Stylesheets, Bilder, Schriften oder Skripte können weitere Ressourcenanforderungen auslösen. Ein Parser beziehungsweise ein vorausschauender Lader kann Ressourcen schon entdecken, bevor die ganze HTML-Datei angekommen ist. Deshalb wartet ein echter Seitenaufbau nicht immer auf das vollständige Ende eines einzelnen Schritts.

Aus CSS entstehen die Regeln und Strukturen für die Darstellung, häufig unter dem Begriff CSSOM zusammengefasst. Zusammen mit dem DOM ermittelt der Browser unter anderem Stile und die darzustellenden Elemente. Beim Layout berechnet er Positionen und Größen; beim Paint zeichnet er die benötigten visuellen Inhalte. Compositing kann vorbereitete Ebenen zusammensetzen. Diese begriffliche Reihenfolge erklärt Abhängigkeiten, ist aber kein vollständiger Bauplan jeder Browserengine.

JavaScript kann das DOM und die Styles verändern, zusätzliche Daten anfordern oder Verarbeitung verzögern. Bilder und Webfonts können später eintreffen und das Layout beeinflussen. Die Seite kann deshalb bereits sichtbar sein, während weitere Requests laufen. Ein „geladen“-Ereignis ist außerdem nicht zwangsläufig das Ende jeder späteren Netzwerkaktivität. Für unsere statische Lernseite gilt umgekehrt: Der lesbare Inhalt benötigt keine ausgeführte Simulation.

Vom HTML zur Darstellung mit zusätzlichen RessourcenHTML wird zum DOM. Entdeckte Ressourcen können aus einem HTTP-Cache kommen oder angefragt werden. CSS liefert Darstellungsregeln. Daraus folgen Stilberechnung, Layout, Paint und Compositing. JavaScript und später eintreffende Ressourcen können weitere Verarbeitung auslösen.Mehrere Vorgänge überlappen.HTML empfangen / verarbeitenDOM aufbauenRessourcen entdeckenCache prüfen / anfordernCSS, Bilder, Schriften, JSStile + Layout berechnenPaint / CompositingSichtbare DarstellungSpätere Daten oder Skriptekönnen neue Anforderungenund Neuberechnung auslösen.
Eigene vereinfachte Abhängigkeitsdarstellung. Netzwerktransfer und Browserarbeit sind keine streng nacheinander abgeschlossenen Blöcke.

Caches und Vermittler verändern den konkreten Weg.

Ein frischer HTTP-Cacheeintrag kann eine Ressourcenanfrage vollständig vermeiden. Bei erforderlicher Validierung kann der Browser dagegen eine bedingte Anfrage senden, etwa mit einem bekannten ETag. Eine Antwort 304 bestätigt unter passenden Bedingungen die vorhandene Darstellung, ohne deren Inhalt erneut zu übertragen. Ein Cachetreffer für ein Stylesheet beweist nicht, dass auch HTML, Bilder und Schriften vorliegen. Cachekontrolle und Aktualität gelten pro Ressource und ihren Regeln.

Mehrere Ressourcen derselben Website können eine vorhandene HTTP/2- oder HTTP/3-Verbindung nutzen. Für sie wird nicht jeweils erneut DNS, ARP, TCP und TLS ausgeführt. Andere Origins können zusätzliche Verbindungen benötigen; Wiederverwendung über Origins hinweg unterliegt weiteren Voraussetzungen. Der DNS-Cachetreffer in unserer vierten Simulation spart ausdrücklich die DNS-Anfrage. Er behauptet weder eine vollständig gespeicherte Website noch automatisch eine bereits offene Verbindung. Die zusätzliche fünfte Variante setzt dagegen ausdrücklich eine bereits bestehende HTTP/2-Verbindung und vorhandene Nachbarinformationen voraus. Dann können DNS-Abfrage, Nachbarauflösung und neue TCP-/TLS-Handshakes entfallen, während die benötigte HTML-Ressource weiterhin angefragt wird.

Ein CDN kann die öffentliche Gegenstelle des Browsers sein. Dann endet dessen Verbindung zunächst an einem geeigneten CDN-Server, der Inhalte aus seinem Cache liefert oder die Herkunftsinfrastruktur kontaktiert. Ein Reverse Proxy kann ähnlich als Eingang eines Dienstes auftreten. Die im DNS erhaltene Adresse muss deshalb nicht die Adresse eines einzelnen Ursprungsservers sein. Ein ausdrücklich konfigurierter Forward Proxy verändert den Verbindungsweg wiederum auf andere Weise.

Diese Varianten ändern nicht die Grundfragen: Welche Ressource wird benötigt? Liegt eine verwendbare Kopie vor? Welcher Endpunkt wird angesprochen? Wie erreicht das nächste Paket seinen Next Hop? Welcher Transport schützt und trägt HTTP? Mit diesen Fragen lässt sich auch eine echte Fehlersuche strukturieren, ohne aus einem fehlenden Ping bereits einen ausgefallenen Webdienst abzuleiten. Dazu passt ICMP, Ping und Traceroute.

Verfolge einen Webseitenaufruf.

Lokale Lehrsimulation. Kein Mitschnitt und kein Zugriff auf example.com oder andere Rechner. Es wird kein echter DNS-/HTTP-Verkehr erzeugt.

Ohne JavaScript bleibt der vollständige Hauptablauf hier lesbar. Alle Adressen und Nachrichten sind simuliert; es werden keine Pakete versendet.

IPv4-Client 192.168.10.20/24, Gateway 192.168.10.1; ausgehendes NAPT. HTTP/2 über TLS 1.3 und TCP; keine Proxys oder CDNs. Client-DNS-Cache ist leer; Resolveradresse wurde zuvor konfiguriert. Neue Verbindung; Client-Nachbarcache ist leer, Routercaches und Routen stehen bereits fest. Alle example.com-Auflösungen, IPs, MACs und Ausgaben sind simuliert. Router-zu-Router-Transit wird verkürzt, Ethernet nur für die benannten Links dargestellt.

  1. URL und Origin bestimmen

    HTTPS-URL · https://example.com/

    Der Browser zerlegt Schema, Host und Pfad. Der Origin besteht hier aus https, example.com und dem wirksamen Port 443. Eine URL ist noch kein Ethernet-Frame.

    Noch keine IP-/MAC-Header oder Transportports eines Pakets vorhanden.

  2. DNS-Cache prüfen

    Lokaler DNS-Cache · Cache-Miss

    Für example.com liegt kein gültiges Ergebnis vor. Der konfigurierte Resolver 203.0.113.53 muss gefragt werden.

    Ein DNS-Cachetreffer ersetzt keine HTML-/Ressourcencaches und erzeugt keine neue sichere Verbindung.

  3. Den lokalen Next Hop wählen

    IPv4-Routing · Ziel liegt außerhalb des Clientpräfixes

    Der Client wählt die passende Route über 192.168.10.1. Die MAC des entfernten Servers wird auf diesem LAN nicht gesucht.

    Die IP-Zieladresse bleibt die des entfernten Endpunkts; benötigt wird zunächst der Nachbar auf dem lokalen Link.

  4. Gateway-MAC per ARP erfragen

    ARP · ARP Request

    ARP fragt nach 192.168.10.1, nicht nach der MAC des entfernten Webservers. Die Anfrage ist ein Broadcast im eigenen VLAN; die Antwort kommt hier als Unicast.

    Link: Client-LAN · ARP. ARP-Nutzfelder: 192.168.10.20 → 192.168.10.1. Ethernet: 02:00:00:00:10:20 → ff:ff:ff:ff:ff:ff.

    Die genannten IPv4-Adressen sind ARP-Nutzfelder, kein IPv4-Header. ARP besitzt keine Ports. Die MAC-Zuordnung wird im Nachbarcache vermerkt.

  5. Gateway antwortet auf ARP

    ARP · ARP Reply

    ARP fragt nach 192.168.10.1, nicht nach der MAC des entfernten Webservers. Die Anfrage ist ein Broadcast im eigenen VLAN; die Antwort kommt hier als Unicast.

    Link: Client-LAN · ARP. ARP-Nutzfelder: 192.168.10.1 → 192.168.10.20. Ethernet: 02:00:00:00:10:01 → 02:00:00:00:10:20.

    Die genannten IPv4-Adressen sind ARP-Nutzfelder, kein IPv4-Header. ARP besitzt keine Ports. Die MAC-Zuordnung wird im Nachbarcache vermerkt.

  6. Resolver nach example.com fragen · Client-LAN

    DNS über UDP · A?

    Eine eigene DNS-Anfrage fragt den vorkonfigurierten Resolver. UDP53 ist dieses Beispiel, keine allgemeine Vorschrift für jeden DNS-Verkehr.

    Link: Client-LAN. IP-Header: 192.168.10.20 → 203.0.113.53. Ethernet: 02:00:00:00:10:20 → 02:00:00:00:10:01. UDP-Ports: 53000 → 53.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet UDP 192.168.10.20:53000 ↔ 198.51.100.10:62001 zu; zurück wird genau dieses Mapping umgekehrt.

  7. Resolver nach example.com fragen · Router-WAN

    DNS über UDP · A?

    Eine eigene DNS-Anfrage fragt den vorkonfigurierten Resolver. UDP53 ist dieses Beispiel, keine allgemeine Vorschrift für jeden DNS-Verkehr.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 198.51.100.10 → 203.0.113.53. Ethernet: 02:00:00:00:20:01 → 02:00:00:00:20:02. UDP-Ports: 62001 → 53.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet UDP 192.168.10.20:53000 ↔ 198.51.100.10:62001 zu; zurück wird genau dieses Mapping umgekehrt.

  8. Resolver nach example.com fragen · Ziel-LAN

    DNS über UDP · A?

    Eine eigene DNS-Anfrage fragt den vorkonfigurierten Resolver. UDP53 ist dieses Beispiel, keine allgemeine Vorschrift für jeden DNS-Verkehr.

    Link: Zielrouter ↔ DNS-Resolver. IP-Header: 198.51.100.10 → 203.0.113.53. Ethernet: 02:00:00:00:30:01 → 02:00:00:00:30:53. UDP-Ports: 62001 → 53.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet UDP 192.168.10.20:53000 ↔ 198.51.100.10:62001 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  9. Simulierte DNS-Antwort empfangen · Ziel-LAN

    DNS über UDP · example.com → 203.0.113.80 · TTL300s

    Die Antwort wird durch den Router zum passenden Clientzustand zurückgeführt. Erst am Client liegt das simulierte Auflösungsergebnis vor.

    Link: Zielrouter ↔ DNS-Resolver. IP-Header: 203.0.113.53 → 198.51.100.10. Ethernet: 02:00:00:00:30:53 → 02:00:00:00:30:01. UDP-Ports: 53 → 62001.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet UDP 192.168.10.20:53000 ↔ 198.51.100.10:62001 zu; zurück wird genau dieses Mapping umgekehrt.

  10. Simulierte DNS-Antwort empfangen · Router-WAN

    DNS über UDP · example.com → 203.0.113.80 · TTL300s

    Die Antwort wird durch den Router zum passenden Clientzustand zurückgeführt. Erst am Client liegt das simulierte Auflösungsergebnis vor.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 203.0.113.53 → 198.51.100.10. Ethernet: 02:00:00:00:20:02 → 02:00:00:00:20:01. UDP-Ports: 53 → 62001.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet UDP 192.168.10.20:53000 ↔ 198.51.100.10:62001 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  11. Simulierte DNS-Antwort empfangen · Client-LAN

    DNS über UDP · example.com → 203.0.113.80 · TTL300s

    Die Antwort wird durch den Router zum passenden Clientzustand zurückgeführt. Erst am Client liegt das simulierte Auflösungsergebnis vor.

    Link: Client-LAN. IP-Header: 203.0.113.53 → 192.168.10.20. Ethernet: 02:00:00:00:10:01 → 02:00:00:00:10:20. UDP-Ports: 53 → 53000.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet UDP 192.168.10.20:53000 ↔ 198.51.100.10:62001 zu; zurück wird genau dieses Mapping umgekehrt.

  12. Route zum Webdienst prüfen

    IPv4-Routing · Entfernter Webdienst

    Die Zieladresse wird gegen die Routingtabelle geprüft; in diesem Beispiel gilt dieselbe Default-Route. Die gerade gelernte Gateway-MAC ist noch im Nachbarcache.

    Kein zweites ARP/ND nötig. DNS- und Webverkehr bleiben getrennte Verbindungen/Zustände.

  13. TCP-Verbindung anfragen · Client-LAN

    TCP · SYN · Seq1000

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Client-LAN. IP-Header: 192.168.10.20 → 203.0.113.80. Ethernet: 02:00:00:00:10:20 → 02:00:00:00:10:01. TCP-Ports: 49152 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  14. TCP-Verbindung anfragen · Router-WAN

    TCP · SYN · Seq1000

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:20:01 → 02:00:00:00:20:02. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  15. TCP-Verbindung anfragen · Ziel-LAN

    TCP · SYN · Seq1000

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Zielrouter ↔ Webdienst. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:30:01 → 02:00:00:00:30:80. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  16. TCP-Anfrage bestätigen · Ziel-LAN

    TCP · SYN+ACK · Seq9000 · Ack1001

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Zielrouter ↔ Webdienst. IP-Header: 203.0.113.80 → 198.51.100.10. Ethernet: 02:00:00:00:30:80 → 02:00:00:00:30:01. TCP-Ports: 443 → 62000.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  17. TCP-Anfrage bestätigen · Router-WAN

    TCP · SYN+ACK · Seq9000 · Ack1001

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 203.0.113.80 → 198.51.100.10. Ethernet: 02:00:00:00:20:02 → 02:00:00:00:20:01. TCP-Ports: 443 → 62000.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  18. TCP-Anfrage bestätigen · Client-LAN

    TCP · SYN+ACK · Seq9000 · Ack1001

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Client-LAN. IP-Header: 203.0.113.80 → 192.168.10.20. Ethernet: 02:00:00:00:10:01 → 02:00:00:00:10:20. TCP-Ports: 443 → 49152.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  19. TCP-Verbindung bestätigen · Client-LAN

    TCP · ACK · Seq1001 · Ack9001

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Client-LAN. IP-Header: 192.168.10.20 → 203.0.113.80. Ethernet: 02:00:00:00:10:20 → 02:00:00:00:10:01. TCP-Ports: 49152 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  20. TCP-Verbindung bestätigen · Router-WAN

    TCP · ACK · Seq1001 · Ack9001

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:20:01 → 02:00:00:00:20:02. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  21. TCP-Verbindung bestätigen · Ziel-LAN

    TCP · ACK · Seq1001 · Ack9001

    Der Three-Way-Handshake synchronisiert Anfangssequenznummern; SYN verbraucht jeweils eine Sequenznummer. Die Werte sind illustrative Beispiele und keine vollständige TCP-Zustandsmaschine.

    Link: Zielrouter ↔ Webdienst. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:30:01 → 02:00:00:00:30:80. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  22. TLS-Handshake beginnen · Client-LAN

    TLS 1.3 über TCP · ClientHello

    TCP allein ist unverschlüsselt. ClientHello bietet TLS-Parameter und das Anwendungsprotokoll an; der Server muss zu example.com authentisiert werden.

    Link: Client-LAN. IP-Header: 192.168.10.20 → 203.0.113.80. Ethernet: 02:00:00:00:10:20 → 02:00:00:00:10:01. TCP-Ports: 49152 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  23. TLS-Handshake beginnen · Router-WAN

    TLS 1.3 über TCP · ClientHello

    TCP allein ist unverschlüsselt. ClientHello bietet TLS-Parameter und das Anwendungsprotokoll an; der Server muss zu example.com authentisiert werden.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:20:01 → 02:00:00:00:20:02. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  24. TLS-Handshake beginnen · Ziel-LAN

    TLS 1.3 über TCP · ClientHello

    TCP allein ist unverschlüsselt. ClientHello bietet TLS-Parameter und das Anwendungsprotokoll an; der Server muss zu example.com authentisiert werden.

    Link: Zielrouter ↔ Webdienst. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:30:01 → 02:00:00:00:30:80. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  25. TLS-Serverflight prüfen · Ziel-LAN

    TLS 1.3 über TCP · ServerHello → Zertifikatsnachweis → Finished (Gruppe)

    Mehrere TLS-Nachrichten und TCP-Segmente werden hier als Nachrichtengruppe zusammengefasst. Der Browser prüft Identität und Vertrauenskette. Die TLS-Nachrichten sind kein einzelnes Ethernet-Paket.

    Link: Zielrouter ↔ Webdienst. IP-Header: 203.0.113.80 → 198.51.100.10. Ethernet: 02:00:00:00:30:80 → 02:00:00:00:30:01. TCP-Ports: 443 → 62000.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  26. TLS-Serverflight prüfen · Router-WAN

    TLS 1.3 über TCP · ServerHello → Zertifikatsnachweis → Finished (Gruppe)

    Mehrere TLS-Nachrichten und TCP-Segmente werden hier als Nachrichtengruppe zusammengefasst. Der Browser prüft Identität und Vertrauenskette. Die TLS-Nachrichten sind kein einzelnes Ethernet-Paket.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 203.0.113.80 → 198.51.100.10. Ethernet: 02:00:00:00:20:02 → 02:00:00:00:20:01. TCP-Ports: 443 → 62000.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  27. TLS-Serverflight prüfen · Client-LAN

    TLS 1.3 über TCP · ServerHello → Zertifikatsnachweis → Finished (Gruppe)

    Mehrere TLS-Nachrichten und TCP-Segmente werden hier als Nachrichtengruppe zusammengefasst. Der Browser prüft Identität und Vertrauenskette. Die TLS-Nachrichten sind kein einzelnes Ethernet-Paket.

    Link: Client-LAN. IP-Header: 203.0.113.80 → 192.168.10.20. Ethernet: 02:00:00:00:10:01 → 02:00:00:00:10:20. TCP-Ports: 443 → 49152.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  28. TLS-Handshake abschließen · Client-LAN

    TLS 1.3 über TCP · Client Finished

    Der Client bestätigt den Handshake; das Szenario setzt erfolgreiche Zertifikatsprüfung und ALPN h2 voraus. TLS- und TCP-Fragmentierung/ACKs werden nicht vollständig einzeln gezeigt.

    Link: Client-LAN. IP-Header: 192.168.10.20 → 203.0.113.80. Ethernet: 02:00:00:00:10:20 → 02:00:00:00:10:01. TCP-Ports: 49152 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  29. TLS-Handshake abschließen · Router-WAN

    TLS 1.3 über TCP · Client Finished

    Der Client bestätigt den Handshake; das Szenario setzt erfolgreiche Zertifikatsprüfung und ALPN h2 voraus. TLS- und TCP-Fragmentierung/ACKs werden nicht vollständig einzeln gezeigt.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:20:01 → 02:00:00:00:20:02. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  30. TLS-Handshake abschließen · Ziel-LAN

    TLS 1.3 über TCP · Client Finished

    Der Client bestätigt den Handshake; das Szenario setzt erfolgreiche Zertifikatsprüfung und ALPN h2 voraus. TLS- und TCP-Fragmentierung/ACKs werden nicht vollständig einzeln gezeigt.

    Link: Zielrouter ↔ Webdienst. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:30:01 → 02:00:00:00:30:80. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  31. Webressource anfordern · Client-LAN

    HTTP/2 über TLS · GET https://example.com/ (dekodierte Lehransicht)

    Die semantische Anfrage enthält Methode GET, Pfad / und den Host example.com. HTTP/2 und HTTP/3 kodieren Header binär; die Anzeige ist kein Klartext-Paketmitschnitt. Inhalt ist zwischen TLS-Endpunkten geschützt.

    Link: Client-LAN. IP-Header: 192.168.10.20 → 203.0.113.80. Ethernet: 02:00:00:00:10:20 → 02:00:00:00:10:01. TCP-Ports: 49152 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  32. Webressource anfordern · Router-WAN

    HTTP/2 über TLS · GET https://example.com/ (dekodierte Lehransicht)

    Die semantische Anfrage enthält Methode GET, Pfad / und den Host example.com. HTTP/2 und HTTP/3 kodieren Header binär; die Anzeige ist kein Klartext-Paketmitschnitt. Inhalt ist zwischen TLS-Endpunkten geschützt.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:20:01 → 02:00:00:00:20:02. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  33. Webressource anfordern · Ziel-LAN

    HTTP/2 über TLS · GET https://example.com/ (dekodierte Lehransicht)

    Die semantische Anfrage enthält Methode GET, Pfad / und den Host example.com. HTTP/2 und HTTP/3 kodieren Header binär; die Anzeige ist kein Klartext-Paketmitschnitt. Inhalt ist zwischen TLS-Endpunkten geschützt.

    Link: Zielrouter ↔ Webdienst. IP-Header: 198.51.100.10 → 203.0.113.80. Ethernet: 02:00:00:00:30:01 → 02:00:00:00:30:80. TCP-Ports: 62000 → 443.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  34. Webantwort erhalten · Ziel-LAN

    HTTP/2 über TLS · Status200 · Content-Type:text/html (dekodiert)

    Der Server liefert HTML als Anwendungsergebnis. HTTP-Status, Header und Inhalt sind von erfolgreicher TCP-/QUIC-Zustellung zu unterscheiden. Die Antwort verwendet den passenden Rückweg und vorhandene Übersetzungszustände.

    Link: Zielrouter ↔ Webdienst. IP-Header: 203.0.113.80 → 198.51.100.10. Ethernet: 02:00:00:00:30:80 → 02:00:00:00:30:01. TCP-Ports: 443 → 62000.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  35. Webantwort erhalten · Router-WAN

    HTTP/2 über TLS · Status200 · Content-Type:text/html (dekodiert)

    Der Server liefert HTML als Anwendungsergebnis. HTTP-Status, Header und Inhalt sind von erfolgreicher TCP-/QUIC-Zustellung zu unterscheiden. Die Antwort verwendet den passenden Rückweg und vorhandene Übersetzungszustände.

    Link: Heimrouter ↔ Providerrouter. IP-Header: 203.0.113.80 → 198.51.100.10. Ethernet: 02:00:00:00:20:02 → 02:00:00:00:20:01. TCP-Ports: 443 → 62000.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt. Der ausgelassene Provider-/Zielrouter-Transit erklärt zwei weitere Hop-Dekremente gegenüber dem vorherigen gezeigten Link.

  36. Webantwort erhalten · Client-LAN

    HTTP/2 über TLS · Status200 · Content-Type:text/html (dekodiert)

    Der Server liefert HTML als Anwendungsergebnis. HTTP-Status, Header und Inhalt sind von erfolgreicher TCP-/QUIC-Zustellung zu unterscheiden. Die Antwort verwendet den passenden Rückweg und vorhandene Übersetzungszustände.

    Link: Client-LAN. IP-Header: 203.0.113.80 → 192.168.10.20. Ethernet: 02:00:00:00:10:01 → 02:00:00:00:10:20. TCP-Ports: 443 → 49152.

    Ethernet-Header gilt nur auf diesem Link. Das IP-Ziel ist der entfernte Endpunkt; Router ersetzen die Linkadressen und verringern TTL/Hop Limit. NAPT ordnet TCP 192.168.10.20:49152 ↔ 198.51.100.10:62000 zu; zurück wird genau dieses Mapping umgekehrt.

  37. HTML verarbeiten und weitere Ressourcen laden

    Browser / HTTP-Caching · DOM → Styles → Layout → Paint (vereinfacht)

    HTML wird geparst, CSS ergänzt die Darstellung, Layout bestimmt Geometrie und Paint erzeugt die sichtbare Ausgabe. JavaScript kann DOM und weitere Anfragen verändern; das ist kein starrer einmaliger Ablauf.

    CSS, JavaScript und Bilder können eigene Requests oder Cachetreffer auslösen; vorhandene Verbindungen werden oft weitergenutzt. DNS-Cache, Verbindung und Ressourcencache sind drei verschiedene Dinge.

Erkläre, welche Arbeit wirklich nötig ist.

Aufgabe 1: Im IPv4-Hauptbeispiel sind DNS- und ARP-Cache des Clients leer. Der entfernte Resolver liegt bei 203.0.113.53. Nach welcher IP fragt der erste ARP-Request? Wird damit schon die Serveradresse aufgelöst?

Lösung: Zuerst wird das Gateway lokal erreichbar gemacht.

Die Route zum Resolver führt über 192.168.10.1. Der Client fragt deshalb nach dessen MAC-Adresse. Erst danach kann er den Frame mit der DNS-Anfrage zum Gateway senden. ARP liefert eine lokale Nachbarzuordnung und keine DNS-Antwort. DNS liefert anschließend im Modell die ausdrücklich simulierte Server-IP 203.0.113.80. Für den späteren Frame an denselben Next Hop kann der vorhandene ARP-Eintrag genutzt werden.

Aufgabe 2: Die DNS-Adresse ist gültig im Cache, das HTML fehlt und es gibt keine bestehende Verbindung. Der Dienst unterstützt HTTP/3 und der Browser wählt es. Welche Schritte können entfallen? Warum wäre „kein TCP, also keine Zuverlässigkeit und keine Verschlüsselung“ falsch?

Lösung: DNS entfällt; QUIC übernimmt Transport und integrierten TLS-Aufbau.

Die DNS-Abfrage entfällt wegen des vorhandenen Ergebnisses. Die HTML-Anfrage bleibt notwendig; auch Nachbarauflösung kann bei leerem Nachbarcache nötig sein. HTTP/3 verwendet QUIC über UDP, deshalb entfällt ein TCP-Handshake. QUIC stellt zuverlässige Streams bereit und integriert TLS für den geschützten Verbindungsaufbau. Der HTTP-Request wird anschließend über diesen Transport gesendet. Ein DNS-Cachetreffer ersetzt weder die Ressource noch eine noch nicht aufgebaute Verbindung.

Quellen und fachlicher Stand.

Geprüft am . Adressen, Diagramme und Abläufe sind eigene didaktische Modelle; die IP für example.com ist ausdrücklich simuliert. Implementierungen können Verarbeitung und Übertragung stärker parallelisieren.