Der Weg einer Anfrage: DNS, TCP, TLS, HTTP

Jemand tippt eine Adresse in den Browser, drückt Enter, und nach einem Wimpernschlag erscheint die Seite. Zwischen diesen beiden Momenten passieren Dutzende Schritte: Namen werden aufgelöst, Verbindungen aufgebaut, Schlüssel ausgehandelt, Daten über mehrere Netze geschickt, auf einem Server verarbeitet und zurückgeliefert. Wer Systeme entwirft, muss diesen Weg nicht bis ins letzte Bit kennen, aber gut genug, um zu verstehen, wo Zeit vergeht, wo Fehler entstehen und wo sich Optimierungen lohnen. Diese Lektion führt Schritt für Schritt durch den Weg einer Anfrage.

1. Die Schichten

Die Kommunikation im Internet ist in Schichten organisiert. Jede Schicht löst eine Aufgabe und verlässt sich auf die darunterliegende. Für System Design sind vier Schichten und ein vorgelagerter Dienst entscheidend.

Abb. 1.1Die Schichten einer Webanfrage

2. Schritt für Schritt

DNS: Der Browser kennt nur den Namen, etwa lernplattform-beispiel.de. Das Domain Name System übersetzt ihn in eine IP-Adresse. Die Antwort wird auf mehreren Ebenen zwischengespeichert – im Browser, im Betriebssystem, beim Internetanbieter –, deshalb ist die Auflösung meist schnell. Wie lange eine Antwort gespeichert werden darf, legt der Betreiber mit der Time to Live fest. Eine kurze TTL erlaubt schnelle Umzüge, eine lange entlastet die Namensserver.

TCP: Für eine zuverlässige Verbindung tauschen Browser und Server zunächst drei Nachrichten aus, den sogenannten Handshake. Das kostet eine volle Hin-und-Rück-Zeit, die Round Trip Time. TCP sorgt dafür, dass Daten vollständig und in der richtigen Reihenfolge ankommen, und wiederholt verlorene Pakete. TLS: Darauf folgt die Aushandlung der Verschlüsselung. Der Server weist sich mit einem Zertifikat aus, beide Seiten einigen sich auf Schlüssel. Mit TLS 1.3 kostet das eine weitere Round Trip Time, mit dem älteren TLS 1.2 zwei. Das neuere Protokoll QUIC, die Grundlage von HTTP/3, fasst Verbindungsaufbau und Verschlüsselung zusammen und spart dadurch Zeit.

HTTP: Erst jetzt wird die eigentliche Anfrage gesendet: eine Methode wie GET oder POST, ein Pfad, Header mit Zusatzinformationen und gegebenenfalls ein Inhalt. Der Server verarbeitet die Anfrage – vielleicht mit Datenbankabfragen, Aufrufen anderer Dienste und Berechnungen – und schickt eine Antwort mit Statuscode, Headern und Inhalt zurück. Statuscodes zeigen das Ergebnis: 2xx für Erfolg, 3xx für Weiterleitungen, 4xx für Fehler der Anfrage und 5xx für Fehler des Servers.

3. Wo die Zeit vergeht

Probieren Sie in der Zeitleiste aus, wie sich einzelne Faktoren auswirken. Ausgangspunkt ist ein Nutzer in München, dessen Anfrage an einen Server in New York geht.

Sie sehen sofort, dass die Entfernung der wichtigste Faktor ist. Jede Runde des Verbindungsaufbaus kostet eine volle RTT, und bei 90 Millisekunden summiert sich das schnell auf über 300 Millisekunden, bevor der Server überhaupt mit der Arbeit beginnt. Ein CDN-Knoten in der Nähe verkürzt jede Runde drastisch. Die Wiederverwendung bestehender Verbindungen spart den gesamten Aufbau – deshalb halten Browser Verbindungen offen, und deshalb sollten auch Server untereinander Verbindungspools verwenden, statt für jede Anfrage eine neue Verbindung zu öffnen.

4. HTTP/1.1, HTTP/2, HTTP/3

In der Praxis übernimmt meist der Webserver, der Load Balancer oder das CDN die Wahl der Version. Für den Entwurf ist wichtig zu wissen, dass moderne Versionen viele parallele Anfragen effizient abwickeln und in instabilen Mobilnetzen Vorteile bringen. Zwischen eigenen Diensten im Rechenzentrum spielt die Version eine geringere Rolle; hier zählen stabile, wiederverwendete Verbindungen.

5. Die Rolle des CDN und der Edge

Für fast jede Webanwendung lohnt sich ein CDN für statische Inhalte: Es verkürzt die Ladezeit, entlastet den eigenen Server und fängt Lastspitzen ab. Entscheidend ist eine durchdachte Cache-Steuerung über HTTP-Header wie Cache-Control. Dateien mit einem Inhalts-Hash im Namen, wie sie moderne Frameworks erzeugen, dürfen praktisch unbegrenzt zwischengespeichert werden, weil sich bei jeder Änderung der Name ändert. HTML-Seiten und API-Antworten brauchen dagegen kurze oder gar keine Zwischenspeicherung, je nachdem, wie aktuell sie sein müssen und ob sie personalisiert sind. Personalisierte Antworten dürfen nie in einem gemeinsamen Cache landen – ein klassischer Fehler, der dazu führen kann, dass Nutzer fremde Daten sehen.

6. Was das für den Entwurf bedeutet

Aus dem Weg einer Anfrage folgen einige Grundregeln. Erstens: Weniger Hin und Her. Jede zusätzliche Anfrage vom Client kostet mindestens eine RTT. Eine Seite, die nach dem Laden noch zehn Anfragen nacheinander stellt, wirkt auf dem Handy träge, egal wie schnell der Server ist. Besser sind Schnittstellen, die in einer Anfrage liefern, was eine Ansicht braucht. Zweitens: Nähe. Server und Datenbank sollten in der Region stehen, in der die meisten Nutzer sind, und statische Inhalte gehören ins CDN. Drittens: Wiederverwendung. Verbindungen zu Datenbank, Cache und externen Diensten sollten in Pools gehalten werden. Viertens: Zeitlimits. Jeder Schritt kann hängen, besonders Aufrufe externer Dienste. Ohne Zeitlimit wartet eine Anfrage im schlimmsten Fall ewig und blockiert Ressourcen – mehr dazu im Modul Skalierung.

Für die eigene Fehlersuche sind die Entwicklerwerkzeuge des Browsers eine Fundgrube. Der Netzwerk-Reiter zeigt für jede Anfrage, wie lange DNS, Verbindungsaufbau, TLS, Warten auf den Server und Übertragung gedauert haben. Wer diese Aufschlüsselung einmal für die eigene Anwendung betrachtet, erkennt schnell, ob Zeit im Netzwerk oder auf dem Server verloren geht – und damit, wo sich Optimierung lohnt. Kommandozeilenwerkzeuge wie curl mit Zeitmessung liefern dieselben Informationen für Schnittstellen und Dienste.

Ein letzter Hinweis gilt der Sicherheit. Jeder Schritt auf dem Weg einer Anfrage ist auch ein möglicher Angriffspunkt: gefälschte DNS-Antworten, abgefangene Verbindungen ohne Verschlüsselung, überlastete Server durch massenhafte Anfragen. Durchgehende Verschlüsselung mit TLS, ein vorgeschaltetes CDN oder eine Web Application Firewall und Begrenzungen der Anfragerate gehören deshalb zu jedem produktiven System. Das Modul Schnittstellen und Sicherheit vertieft diese Themen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.