Netzwerke, Internet und Web: IP, DNS, HTTP und das Client-Server-Modell

Netzwerke und Pakete

Kaum eine moderne Software läuft für sich allein. Eine Essensliefer-App auf Ihrem Smartphone kommuniziert mit den Servern des Unternehmens, die wiederum mit den Tablets der Restaurants, einem Zahlungsanbieter, einem Kartendienst und einem Benachrichtigungsdienst kommunizieren. Dieser Abschnitt erklärt, wie diese Kommunikation funktioniert, von unten nach oben.

Ein Netzwerk ist eine Gruppe von Computern, die so verbunden sind, dass sie Daten austauschen können, per Kabel, WLAN, Mobilfunk oder Glasfaser. Das Internet ist ein Netz aus Netzen: Millionen Netzwerke unterschiedlicher Eigentümer (Breitbandanschlüsse zu Hause, Mobilfunkbetreiber, Universitäten, Cloud-Anbieter), die vereinbart haben, den Datenverkehr der jeweils anderen nach gemeinsamen Regeln, sogenannten Protokollen, zu befördern.

Daten reisen nicht als ein durchgehender Strom. Sie werden in Pakete zerlegt: Stücke von typischerweise bis zu etwa 1500 Bytes, jedes mit Herkunft und Ziel beschriftet, wie ein Päckchen mit Absender- und Empfängeradresse. Geräte namens Router reichen Pakete von Netzwerk zu Netzwerk weiter und wählen dabei jeweils einen guten nächsten Hop, ähnlich wie Sortierzentren Päckchen in Richtung ihres Ziels weitergeben. Verschiedene Pakete derselben Nachricht können unterschiedliche Wege nehmen, in falscher Reihenfolge ankommen oder gelegentlich verloren gehen, und der empfangende Computer setzt sie wieder zusammen. Die Aufteilung in Pakete lässt Millionen Gespräche dieselben Kabel fair teilen und den Datenverkehr eine unterbrochene Verbindung umgehen.

Adressen: IP-Adressen und Ports

Damit ein Paket ankommt, braucht das Ziel eine Adresse. Jedes Gerät im Internet wird über eine IP-Adresse erreicht (IP steht für Internet Protocol). Die ältere Version, IPv4, schreibt Adressen als vier Zahlen von 0 bis 255, etwa 192.0.2.10; sie erlaubt etwa 4,3 Milliarden Adressen, was nicht für jedes Smartphone, jeden Laptop und jeden Sensor der Welt reicht. Das neuere IPv6 verwendet viel längere Adressen in hexadezimaler Schreibweise (Basis 16, mit den Ziffern 0 bis 9 und den Buchstaben a bis f), etwa 2001:db8::1, und bietet Platz für praktisch unbegrenzt viele Geräte. Beide sind nebeneinander im Einsatz. (Die Beispieladressen in diesem Abschnitt stammen aus Bereichen, die für Dokumentationszwecke reserviert sind, und gehören daher zu keinem echten Rechner.)

Eine IP-Adresse bringt ein Paket zum richtigen Computer, aber ein Computer führt viele Programme gleichzeitig aus. Eine Portnummer von 0 bis 65535 gibt an, welches Programm es empfangen soll. Ist die IP-Adresse die Straßenadresse eines Bürogebäudes, dann ist der Port die Zimmernummer. Bekannte Dienste haben Standardports: 443 für HTTPS, 80 für einfaches HTTP, 53 für DNS, 5432 für die Datenbank PostgreSQL. Ein Serverprogramm lauscht auf einem Port und wartet auf Verbindungen; wenn Ihr Browser eine Website kontaktiert, verbindet er sich mit Port 443 unter der IP-Adresse der Website.

TCP und UDP: zwei Arten der Zustellung

Auf IP setzen zwei wichtige Transportprotokolle auf, die bestimmen, wie viel Sorgfalt auf die Zustellung verwendet wird. TCP (Transmission Control Protocol) bietet zwei Programmen einen zuverlässigen, geordneten Bytestrom. Bevor Daten fließen, bauen beide Seiten mit einem dreistufigen Handshake eine Verbindung auf. Jedes Paket ist nummeriert; der Empfänger bestätigt, was angekommen ist; Fehlendes wird erneut gesendet; alles wird dem Programm in der richtigen Reihenfolge übergeben. TCP drosselt außerdem das Tempo, wenn das Netzwerk überlastet ist. Es ist wie ein Einschreiben mit Sendungsverfolgung: verlässlich, aber mit etwas Mehraufwand.

UDP (User Datagram Protocol) sendet einfach einzelne Pakete, Datagramme genannt, ohne Handshake, ohne Bestätigungen, ohne erneutes Senden und ohne Reihenfolge. Es ist wie das Verschicken von Postkarten: billig und schnell, aber manche kommen vielleicht nicht an. Genau das ist richtig, wenn ein verspätetes Paket ohnehin nutzlos ist. In einem Videoanruf ist ein Tonfragment, das eine halbe Sekunde zu spät ankommt, schlimmer als eines, das nie ankommt; deshalb nutzen Anrufe, Livestreams und Onlinespiele UDP und kommen mit kleinen Lücken zurecht. Auch DNS-Abfragen, die aus winzigen Fragen und Antworten bestehen, nutzen traditionell UDP.

DNS: das Adressbuch des Internets

Menschen merken sich Namen wie shop.example; Netzwerke leiten nach IP-Adressen weiter. Das Domain Name System (DNS) übersetzt das eine in das andere. Es ist ein weltweites, verteiltes Verzeichnis: Kein einzelner Computer kennt alle Namen. Stattdessen ist die Zuständigkeit nach den Punkten im Namen aufgeteilt, von rechts nach links gelesen. Die Root-Server wissen, wer für jede Top-Level-Domain wie .com oder .uk zuständig ist; diese Top-Level-Domain-Server wissen, welche autoritativen Nameserver für jede darunter registrierte Domain zuständig sind; und die autoritativen Server halten die eigentlichen Einträge, etwa die IP-Adresse von www.shop.example. Die Root-Zone wird von 13 benannten Server-Identitäten bedient, die 12 unabhängige Organisationen über weit mehr als tausend Serverinstanzen in aller Welt betreiben.

Ihr Gerät geht diese Kette normalerweise nicht selbst ab. Es fragt einen rekursiven Resolver, meist betrieben von Ihrem Internetanbieter oder einem öffentlichen Dienst, der die Laufarbeit erledigt und Antworten für eine vom Domaininhaber festgelegte Dauer speichert (cacht), die TTL (Time to Live). Weil Antworten auf vielen Ebenen gecacht werden, sind die meisten Abfragen in wenigen Millisekunden beantwortet, ganz ohne die Root-Server zu erreichen. Dasselbe Caching erklärt, warum eine Änderung an einem DNS-Eintrag Minuten oder Stunden brauchen kann, bis sie überall sichtbar ist.

HTTP: Anfragen und Antworten

Sobald ein Programm ein anderes erreichen kann, brauchen beide eine gemeinsame Sprache für ihre Anliegen. Im Web ist diese Sprache HTTP (Hypertext Transfer Protocol). Es folgt einem einfachen Muster: Der Client sendet eine Anfrage (Request); der Server schickt genau eine Antwort (Response) zurück. Jede Anfrage nennt eine Methode (was zu tun ist), einen Pfad (woran), einige Header (Zusatzinformationen als Name-Wert-Paare) und manchmal einen Body (gesendete Daten). Jede Antwort enthält einen Statuscode, Header und meist einen Body: eine Webseite, ein Bild oder Daten in einem Format wie JSON (ein einfaches Textformat für strukturierte Daten, erklärt im Abschnitt über APIs).

Die gängigsten Methoden sind GET (etwas abrufen, ohne es zu ändern), POST (etwas Neues übermitteln, etwa eine Bestellung aufgeben), PUT (etwas unter einer bekannten Adresse ersetzen, etwa eine Lieferadresse aktualisieren) und DELETE (etwas entfernen). GET, PUT und DELETE sind per Definition idempotent: Dieselbe Anfrage zweimal zu senden hat dieselbe Wirkung wie einmal, weshalb sie nach einem Netzwerkfehler gefahrlos wiederholt werden können. POST ist es nicht; deshalb kann eine unbedachte Wiederholung eine Bestellung doppelt aufgeben. Header transportieren etwa den Inhaltstyp (Content-Type: application/json), die bevorzugte Sprache des Nutzers, Cookies (kleine Datenstücke, die eine Website vom Browser speichern und bei späteren Anfragen zurücksenden lässt) und Anmeldedaten sowie Caching-Anweisungen.

HTTP ist zustandslos: Jede Anfrage wird für sich verstanden, und der Server muss sich nicht an frühere erinnern. Angemeldete Sitzungen werden darauf aufgebaut, meist indem der Client bei jeder Anfrage ein Cookie oder Token mitschickt. Die Zustandslosigkeit ist ein Grund, warum das Web so gut skaliert: Jeder von vielen identischen Servern kann jede Anfrage bearbeiten.

POST /api/orders HTTP/1.1
Host: shop.example
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"product_id": 42, "quantity": 2}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/9917

{"order_id": 9917, "status": "received", "total_pence": 3000}

Die Trennung zwischen 4xx und 5xx ist in der Praxis wichtig. Ein 4xx sagt: „Nicht einfach wiederholen; die Anfrage korrigieren.“ Ein 5xx sagt: „Das Problem liegt bei uns“; ein späterer erneuter Versuch kann klappen, und das Betriebsteam sollte alarmiert werden, wenn die 5xx-Raten steigen.

HTTPS und TLS: Vertraulichkeit und Identität

Einfaches HTTP sendet alles als lesbaren Text, sodass jeder auf dem Weg, etwa jemand im selben Café-WLAN, es lesen oder verändern könnte. HTTPS ist HTTP, das durch einen geschützten Kanal gesendet wird, den TLS herstellt (Transport Layer Security; die aktuelle Version, TLS 1.3, wurde 2018 als RFC 8446 veröffentlicht). TLS bietet drei Dinge: Vertraulichkeit (Lauscher sehen nur verschlüsselte Daten), Integrität (Manipulationen werden erkannt) und Authentifizierung (Sie sprechen wirklich mit shop.example, nicht mit einem Betrüger).

Die Authentifizierung beruht auf Zertifikaten. Das Zertifikat einer Website ist ein digitales Dokument, das sinngemäß sagt: „Dieser öffentliche Schlüssel gehört zu shop.example“, signiert von einer Zertifizierungsstelle (CA), der Ihr Browser oder Smartphone bereits vertraut. Es funktioniert wie ein Reisepass: ausgestellt von einer Stelle, der beide Seiten vertrauen, mit dem Inhaber abgeglichen und nur bis zum Ablaufdatum gültig. Während des TLS-Handshakes legt der Server sein Zertifikat vor, der Client prüft Signatur, Namen und Daten, und beide Seiten vereinbaren frische geheime Schlüssel, um den Rest der Kommunikation zu verschlüsseln. Schlägt eine Prüfung fehl, zeigt der Browser eine Warnung.

TLS schützt Daten während der Übertragung zwischen zwei Punkten. Es schützt keine Daten, sobald sie gespeichert sind, und es beweist nicht, dass die Website ehrlich ist, nur dass sie die ist, die sie zu sein behauptet. Heute ist HTTPS für den gesamten Webverkehr die Norm, nicht nur für Zahlungen, und Zertifikate werden oft kostenlos ausgestellt und automatisch erneuert.

Das Client-Server-Modell

Die meisten Systeme in diesem Kurs folgen dem Client-Server-Modell. Ein Client (ein Browser, eine mobile App, ein anderes Programm) beginnt die Kommunikation, indem er eine Anfrage sendet. Ein Server wartet auf Anfragen und beantwortet sie. Der Server hält, was geteilt und vertrauenswürdig sein muss: den Produktkatalog, die Bestellungen aller Kunden, die Regeln für Preise und Erstattungen. Der Client kümmert sich um den Bildschirm und die Eingaben des Nutzers.

In einem Restaurant sind die Gäste die Clients und die Küche ist der Server: Die Gäste geben Bestellungen auf; die Küche verfügt über die Zutaten und das Können und bedient viele Gäste gleichzeitig. Eine Folge davon ist, dass der Server dem Client nie blind vertrauen darf. Eine Smartphone-App kann von ihrem Nutzer verändert werden; deshalb müssen Preise, Berechtigungen und Lagerbestände auf dem Server geprüft werden, wie sorgfältig die App sie auch selbst prüft.

Ein Server ist oft zugleich ein Client: Der Webserver des Shops ist ein Client seiner Datenbank und des Zahlungsanbieters. Reale Systeme sind Ketten und Geflechte solcher Beziehungen, wie das Sequenzdiagramm unten zeigt.

Latenz und Bandbreite

Zwei Größen beschreiben, wie schnell sich ein Netzwerk anfühlt, und sie werden oft verwechselt. Bandbreite ist die Datenmenge, die eine Verbindung pro Sekunde übertragen kann, etwa 100 Megabit pro Sekunde: die Breite des Rohrs. Latenz ist die Zeit, die ein Datenstück von einem Ende zum anderen braucht, meist gemessen als Round-Trip-Time (RTT) in Millisekunden: die Länge des Rohrs. Ein Autobahnvergleich hilft: Zusätzliche Fahrspuren (Bandbreite) lassen mehr Autos pro Stunde durch, verkürzen aber die Fahrt keines einzelnen Autos (Latenz).

Die Latenz hat eine Untergrenze, die die Physik setzt. Licht in Glasfasern bewegt sich mit rund 200.000 km pro Sekunde, etwa zwei Dritteln seiner Geschwindigkeit im Vakuum. London und Sydney liegen auf geradem Weg über den Globus etwa 17.000 km auseinander; selbst eine perfekte Glasfaser auf dieser Linie bräuchte also etwa 85 ms für eine Richtung und 170 ms für einen Roundtrip. Echte Kabel folgen nicht dem kürzesten Weg, und Router fügen Verzögerung hinzu, sodass gemessene Roundtrips typischerweise bei etwa 250 ms liegen. Kein Upgrade kann das beseitigen. Braucht das Laden einer Seite aus Sydney zehn aufeinanderfolgende Roundtrips zu einem Server in London, wartet der Nutzer zweieinhalb Sekunden, wie schnell sein Breitbandanschluss auch ist.

Was passiert, wenn Sie eine Webadresse eingeben

All diese Teile wirken jedes Mal zusammen, wenn Sie eine Website besuchen. Hier ist der Ablauf, wenn Sie https://shop.example/products/42 eingeben und die Eingabetaste drücken, vereinfacht, aber zutreffend.

Warum das für die Architektur wichtig ist

Sobald ein System auf mehr als einen Computer verteilt ist, wird jede Interaktion zwischen seinen Teilen zu einem Netzwerkaufruf, mit Latenz, der Möglichkeit eines Ausfalls und dem Bedarf an Sicherheit. Ein Funktionsaufruf innerhalb eines Programms dauert Nanosekunden und geht nie verloren; ein Aufruf über ein Netzwerk dauert Millisekunden, manchmal weit länger, und kehrt manchmal nie zurück. Viele der schwierigsten Probleme der Architektur folgen aus diesem Unterschied; deshalb beginnt Kapitel 6 mit den Fallacies of Distributed Computing, etwa dem Glauben, die Latenz sei null.

Die hier behandelten Protokolle tauchen auch als Bausteine wieder auf: HTTP liegt den Web-APIs im nächsten Teil dieses Kapitels und den Kommunikationsstilen in Kapitel 6 zugrunde, während TLS und Zertifikate in sichere Kommunikation und Zero Trust wiederkehren. Server nahe an den Nutzern zu platzieren ist Teil der Multi-Region- und Edge-Architektur.