Die Anwendungsschicht

Eine Netzwerkanwendung besteht aus Programmen, die auf Endsystemen laufen: Smartphones, Laptops und Servern. Ihre Prozesse tauschen Nachrichten über das Netz aus. Router und Switches leiten die Pakete weiter; auf ihnen muss kein neues Anwendungsprogramm installiert werden, wenn jemand einen neuen Dienst erstellt.

Zwei Arten, die Arbeit aufzuteilen

Eine Anwendungsarchitektur beschreibt, wie die Anwendung Arbeit auf Hosts verteilt. Sie ist von der Schichtenarchitektur des Netzes getrennt. Der Entwickler entscheidet, wo Programme laufen, und verlässt sich darauf, dass das bestehende Netz sie verbindet.

Bei einer Client-Server-Architektur kontaktieren Clients einen ständig eingeschalteten Server unter einer bekannten Adresse. Ein Browser fordert ein Dokument von einem Webserver an, der das Dokument zurückgibt. Andere Browser müssen für diesen Austausch nicht online sein. Ein beliebter Dienst kann seine Serverrolle auf Tausende Rechner in Rechenzentren verteilen; ein öffentlicher Name kann diese Gruppe repräsentieren. Geräte, Strom, Kühlung und Internetverbindungen kosten Geld.

Eine Peer-to-Peer-Architektur, kurz P2P, ermöglicht den direkten Datenaustausch zwischen Nutzergeräten. Ein Peer kann ein Dateistück anfordern und auch Stücke hochladen, die er bereits besitzt. Peers können die Verbindung trennen oder Adressen ändern, sodass die Anwendung verfügbare Peers finden und bei wechselnder Teilnahme weiterarbeiten muss.

Verfolge einen Austausch

Angenommen, eine Forschungsgruppe verteilt einen großen Datensatz. Bei einer Client-Server-Architektur lädt jeder Forschende eine Kopie vom Server der Gruppe herunter. Zehn neue Forschende bedeuten zehn weitere Kopien, die dieser Server hochladen muss. Bei einer P2P-Architektur senden Forschende, die bereits einige Stücke besitzen, diese an neu Hinzukommende. Jede hinzukommende Person kann neben zusätzlicher Nachfrage auch Kapazität einbringen. Das ist Selbstskalierung: Die Ressourcen der Anwendung wachsen mit der Teilnahme.

Selbstskalierung hängt dennoch von nützlichen Beiträgen ab. Ein Peer mit einer langsamen Uploadverbindung steuert weniger Kapazität bei als einer mit einer schnellen Verbindung. Viele Anschlüsse von Privathaushalten sind asymmetrisch: Herunterladen ist schneller als Hochladen. Ein Peer, der die Verbindung trennt, trägt nichts bei, solange er offline ist. P2P-Software muss Teilnehmer außerdem vor nicht vertrauenswürdigen Peers schützen und Nutzer dazu anregen, hochzuladen, statt nur Daten zu beziehen.

Zentrale Koordination und direkte Übertragung

Eine hybride Architektur kombiniert Serverkoordination mit P2P-Datenübertragung. Ein BitTorrent-Tracker informiert einen Peer über andere Peers; er muss die Datei nicht selbst senden. Ebenso kann ein Anrufdienst Teilnehmer über einen Server finden, ihre Geräte Medien direkt austauschen lassen und eine Weiterleitung nutzen, wenn kein direkter Pfad verfügbar ist. Ordne den Pfad, über den die Daten übertragen werden, getrennt von dem Pfad ein, über den die Übertragung eingerichtet wird.

Die Wörter Client und Server beschreiben auch Rollen bei einem einzelnen Austausch. Wenn Peer Mira eine Anfrage an Peer Leo stellt, ist Mira bei diesem Austausch der Client und Leo der Server. Kurz darauf können sie die Rollen tauschen. P2P beseitigt die Abhängigkeit von eigens dafür vorgesehenen Inhaltsservern; die Rollen der anfragenden und antwortenden Seite bleiben bestehen.

Ein laufendes Anwendungsprogramm ist ein Prozess. Prozesse auf verschiedenen Hosts tauschen Nachrichten über Sockets aus, die Softwareschnittstellen zwischen Anwendungs- und Transportschicht. Der Anwendungscode bestimmt die Bedeutung der Nachricht; der Transportdienst überträgt ihre Bytes oder Datagramme.

Den empfangenden Prozess finden

Eine IP-Adresse bezeichnet einen Host, aber auf dem Host können viele Dienste laufen. Eine Portnummer bezeichnet einen Transportendpunkt auf ihm. Um einen HTTPS-Dienst unter 203.0.113.10 zu kontaktieren, richtet ein Client seine Anfrage normalerweise an Port 443. Sein eigenes Betriebssystem weist ihm üblicherweise einen vorübergehenden, sogenannten ephemeren Quellport zu.

Ports sind 16-Bit-Werte von 0 bis 65.535. Die Systemports umfassen 0–1023, die registrierten Ports 1024–49.151 und die dynamischen Ports 49.152–65.535. Zu den gebräuchlichen Dienstports gehören HTTP 80, HTTPS 443, SMTP-Übertragung 25 und DNS 53. Ein Port ist Teil der Adressierung und sagt nicht aus, ob der Verkehr verschlüsselt oder vertrauenswürdig ist.

Die Nachrichten festlegen

Ein Anwendungsschichtprotokoll legt Nachrichtentypen, Syntax, Semantik und Austauschregeln fest. Typen unterscheiden eine Anfrage von einer Antwort. Die Syntax beschreibt Felder und Trennzeichen. Die Semantik erklärt jedem Teilnehmer, was diese Felder bedeuten. Austauschregeln bestimmen, wann ein Prozess eine Nachricht sendet und wie der Empfänger antwortet. Öffentliche Spezifikationen, häufig RFCs, ermöglichen die Kommunikation zwischen Programmen verschiedener Entwickler.

Ein Protokoll ist ein Bestandteil einer Anwendung. Das Web benötigt auch Browser, Server und Dokumente. Die Definition von HTTP allein erstellt weder einen Browser noch legt sie das Aussehen seiner Oberfläche fest.

Den Dienst passend zum Bedarf wählen

Betrachte vier Anforderungen: korrekte Übertragung, ausreichenden Durchsatz, akzeptable Verzögerung und Sicherheit. Ein E-Mail-Anhang benötigt jedes Byte. Ein Sprachanruf kann einzelne verlorene Mediendaten verkraften, leidet aber, wenn ältere Audiodaten zu spät ankommen. Ein gespeichertes Video benötigt einen anhaltenden Durchsatz nahe seiner codierten Bitrate, während ein elastischer Download die jeweils verfügbare Rate nutzen kann.

TCP umfasst Flusskontrolle zum Schutz des Empfängers und Überlastkontrolle, um Überlastung im Netz zu verringern. Es bietet weder eine Mindestbandbreite noch eine Zustellfrist. UDP selbst ergänzt weder Zuverlässigkeit noch Überlastkontrolle. Seine Wahl beseitigt keine Überlastung auf dem Pfad.

Ein Spiel beispielsweise, das 30-mal pro Sekunde Positionen sendet, erzeugt etwa alle 33 ms eine neue Aktualisierung. Es kann UDP nutzen, damit eine verlorene Aktualisierung durch eine neuere ersetzt werden kann, ohne auf ihre erneute Übertragung zu warten. Der Chat des Spiels benötigt weiterhin zuverlässige Übertragung, ob durch TCP oder durch Zuverlässigkeitsmechanismen im eigenen Protokoll.

Sicherheit im Protokollstapel ergänzen

Weder TCP noch UDP verschlüsselt für sich genommen Anwendungsdaten. HTTP/1.1 und HTTP/2 nutzen für HTTPS gewöhnlich TLS über TCP. TLS ergänzt Vertraulichkeit, Integrität und Serverauthentifizierung. HTTP/3 nutzt QUIC über UDP; QUIC bietet Zuverlässigkeit, Überlastkontrolle und integriertes TLS 1.3. Gespeicherte Videos, die über HTTP ausgeliefert werden, nutzen daher TCP oder QUIC, während interaktive Anrufe Medien häufig über UDP übertragen.

Eine Webseite besteht meist aus mehreren Objekten, jedes mit einer eigenen URL. Die HTML-Basisdatei nennt Bilder, Skripte und andere Dateien. In https://www.example.org/docs/intro.html ist https das Schema, www.example.org der Host und /docs/intro.html der Pfad.

Eine Anfrage und eine Antwort lesen

HTTP arbeitet mit Anfrage-Antwort-Austauschen. Eine HTTP/1.1-Anfrage beginnt mit Methode, Pfad und Version:

GET /docs/intro.html HTTP/1.1
Host: www.example.org
Connection: close

Die Anfragezeile und die Headerzeilen enden mit CRLF. Eine Leerzeile beendet die Header, danach folgt ein optionaler Nachrichtentext. Host ist in HTTP/1.1 erforderlich, weil mehrere Websites eine Serveradresse gemeinsam nutzen können. Connection: close fordert das Schließen der Verbindung nach der Antwort an.

GET ruft ein Objekt ab. HEAD fordert dessen Antwortheader ohne den Nachrichtentext an. POST sendet Daten im Nachrichtentext einer Anfrage; ein GET kann Formularwerte auch in der Abfragezeichenkette seiner URL mitführen. PUT speichert ein Objekt unter einer angegebenen URL und DELETE entfernt eines.

Die Antwort beginnt mit einer Statuszeile wie HTTP/1.1 200 OK, gefolgt von Headern, einer Leerzeile und dem Nachrichtentext. Content-Type bezeichnet die Darstellung; Content-Length gibt deren Länge in Byte an. Die Statusklassen sind 1xx Information, 2xx Erfolg, 3xx Umleitung, 4xx Clientfehler und 5xx Serverfehler. Ein 301 verweist in Location auf eine neue URL; 304 erlaubt die Wiederverwendung einer zwischengespeicherten Kopie. Ein 404 bedeutet, dass der Server geantwortet hat, das angeforderte Objekt sei nicht gefunden worden, nicht dass der Server unerreichbar war. Weitere nützliche Codes sind 400, 500 und 505.

HTTP ist zustandslos: Jede Anfrage lässt sich ohne frühere Anfragen verstehen. Eine Website kann trotzdem oberhalb von HTTP Anmelde- oder Warenkorbzustände verwalten. Ein gewöhnliches wiederholtes GET kann das Objekt erneut zurückgeben, während eine bedingte Anfrage eine gespeicherte Kopie überprüfen kann.

Die Umlaufzeiten zählen

Für ein Objekt über eine neue TCP-Verbindung rechne eine RTT für den Verbindungsaufbau und eine für die Anfrage und den Beginn der Antwort. Addiere dann die Übertragungszeit des Objekts. Bei RTT 30 ms, Größe 500 kB und Rate 50 Mbps:

Insgesamt sind das 60 ms plus 80 ms, also 140 ms. Dieses Modell lässt DNS, TLS und Verarbeitungszeit außer Acht. Ein vollständiger TLS-1.3-Handshake über die neue TCP-Verbindung fügt eine weitere RTT hinzu.

Die Verbindung wiederverwenden oder neu öffnen

Eine nicht persistente Verbindung überträgt ein Objekt. Eine persistente Verbindung kann spätere Anfragen ohne erneuten TCP-Aufbau übertragen. Persistenz ist die Voreinstellung von HTTP/1.1, auch wenn inaktive Verbindungen irgendwann geschlossen werden.

Für ein HTML-Objekt und acht kleine Bilder, RTT 20 ms und vernachlässigbare Übertragungszeiten:

Die Bildanfragen setzen den Empfang der HTML-Datei voraus. Selbst bei parallelem Abruf können sie erst beginnen, wenn ihre URLs bekannt sind. Zähle diese voneinander abhängigen Schritte, bevor du die Handshakes zählst. HTTP/1.1-Browser nutzen häufig mehrere Verbindungen pro Host; Pipelining ist ein Zeitmodell und keine Voraussetzung für Persistenz.

HTTP-Anfragen stehen für sich, trotzdem kann sich ein Shop einen Warenkorb merken. Ein Browser kann auch ein Bild wiederverwenden, statt es erneut herunterzuladen. Cookies unterstützen die Wiedererkennung über mehrere Anfragen hinweg; Caches ermöglichen die Wiederverwendung von Antworten.

Ein Cookie verfolgen

Beim ersten Besuch erstellt shop.example.com einen Datenbankeintrag für einen Besucher und gibt Set-Cookie: id=1678 zurück. Der Browser speichert diesen Wert. Spätere passende Anfragen enthalten Cookie: id=1678, sodass der Server den Warenkorb nachschlagen kann. Das Cookie sind Daten, kein ausführbarer Code, und der Warenkorb selbst kann in der Datenbank des Servers bleiben.

Cookie-Attribute steuern seine Verwendung. Expires oder Max-Age legt eine Lebensdauer fest; ein Cookie ohne beide ist ein Sitzungscookie. Domain und Path schränken ein, zu welchen Anfragen es passt. Secure beschränkt das Senden auf HTTPS, HttpOnly verhindert den Zugriff durch Seitenskripte und SameSite steuert das Senden im Kontext anderer Websites. Die Sitzungswiederherstellung kann Sitzungscookies erhalten, wenn ein Browser eine frühere Sitzung wiederherstellt.

Erstanbieter-Cookies gehören zur besuchten Website. Ein eingebetteter Drittanbieterdienst kann Cookies über verschiedene Websites hinweg nutzen, um einen Browser wiederzuerkennen. Safari blockiert Drittanbieter-Cookies standardmäßig; Firefox trennt sie nach Websites; Chrome bietet Nutzern Einstellungsmöglichkeiten und blockiert sie im Inkognitomodus. Die Regeln der Europäischen Union verlangen eine Einwilligung für Cookies, die zur Bereitstellung eines angeforderten Dienstes nicht unbedingt erforderlich sind.

Eine Anfrage an den Cache verfolgen

Ein Webcache speichert HTTP-Antworten. Ein Browser hat seinen eigenen Cache. Ein Caching-Proxy sitzt zwischen Clients und Ursprungsservern: Er liefert bei einem Cachetreffer direkt eine Antwort oder ruft sie bei einem Cachefehltreffer ab, speichert sie und leitet sie weiter. Er handelt gegenüber dem Browser als Server und gegenüber dem Ursprungsserver als Client. Ein Proxy kann auch ohne Caching existieren.

Ein Treffer in einem nahe gelegenen Cache verringert Verzögerung, Last am Ursprungsserver und Verkehr auf der Zugangsverbindung. Bei 90 Anfragen pro Sekunde mit durchschnittlich je 1 Mbit beträgt die angebotene Last 90 Mbps. Auf einer 100-Mbps-Zugangsverbindung beträgt die Verkehrsintensität 0,9; dabei können Warteschlangen groß werden. Eine Trefferquote von 40 % lässt 60 % über die Verbindung laufen: 54 Mbps und eine Intensität von 0,54. Wenn Treffer 10 ms und Fehlzugriffe 200 ms dauern, beträgt die durchschnittliche Antwortzeit:

Diese Verkehrsberechnung setzt für die Gruppe der Treffer und die der Fehlzugriffe dieselbe durchschnittliche Objektgröße voraus. Eine allein anhand der Anzahl der Anfragen gemessene Trefferquote muss bei unterschiedlichen Objektgrößen nicht dem Anteil der eingesparten Bytes entsprechen.

Vor der Wiederverwendung die Aktualität prüfen

Ein bedingtes GET sendet If-Modified-Since mit einem gespeicherten Änderungsdatum oder If-None-Match mit einem gespeicherten ETag. Ein unverändertes Objekt ergibt 304 Not Modified ohne Objektdaten im Nachrichtentext. Der Cache verwendet seine Kopie erneut. Ein geändertes Objekt ergibt 200 OK mit dem Ersatz. Die Prüfung spart die Übertragung des Nachrichtentexts, benötigt aber weiterhin einen Umlauf zum Ursprungsserver.

Ein gemeinsam genutzter Proxy kann normalerweise die Inhalte einer HTTPS-Verbindung, die ihn durchläuft, nicht einsehen. Browsercaches und CDN-Server, die im Auftrag einer Website ausliefern, können an den Endpunkten zwischenspeichern, an denen diese Antworten in lesbarer Form vorliegen.

HTTP-Versionen behalten die Bedeutung von Methoden, Statuscodes, Feldern und URLs bei. Ein 404 bedeutet weiterhin, dass die angeforderte Ressource nicht gefunden wurde. Was sich ändert, ist die Übertragung von Anfragen und Antworten: HTTP/1.1 nutzt Textnachrichten, während HTTP/2 und HTTP/3 binäre Frames nutzen.

Kleine Antworten vorankommen lassen

Auf einer HTTP/1.1-Verbindung können geordnete Antworten dazu führen, dass ein kleines Objekt hinter einem großen warten muss. Das ist Head-of-Line-Blocking auf Anwendungsebene. Mehrere TCP-Verbindungen zu öffnen, verkürzt diese Wartezeit, verursacht aber zusätzlichen Verbindungsaufbau und verschafft der Seite mehrere konkurrierende, überlastkontrollierte Verbindungen.

HTTP/2 teilt Nachrichten in HTTP-Frames und weist jedem Anfrage-Antwort-Austausch einen Datenstrom zu. Der Sender verschachtelt Frames verschiedener Datenströme auf einer TCP-Verbindung. Die Headerkompression HPACK verringert wiederholte Felddaten. Prioritäten können steuern, welche Antworten zuerst berücksichtigt werden.

Für einen vereinfachten Vergleich hat eine große Antwort 1.000 Frames und acht kleine haben je zwei Frames. Pro Zeitschlitz wird ein Frame gesendet. Wird die große Antwort zuerst gesendet, werden die kleinen Antworten in den Zeitschlitzen 1.002 bis 1.016 fertig, im Durchschnitt bei 1.009. Wird abwechselnd je ein Frame aus jedem noch nicht abgeschlossenen Datenstrom gesendet, werden die kleinen Antworten in den Zeitschlitzen 11 bis 18 fertig, im Durchschnitt bei 14,5. Die große Antwort wird in Zeitschlitz 1.016 fertig. Die Verschachtelung ändert die Fertigstellungszeiten, ohne die Übertragungsrate der Verbindung zu erhöhen.

HTTP/2 spezifizierte auch Server Push, bei dem Inhalte vor einer Anfrage gesendet werden. Große Browser haben es deaktiviert. Eine 103 Early Hints-Antwort weist stattdessen auf Ressourcen hin, sodass der Browser beginnen kann, sie anzufordern.

Die verbleibende Blockierung finden

TCP liefert einen geordneten Bytestrom. Fehlen Bytes, warten spätere Bytes auf die Wiederherstellung, selbst wenn sie Frames eines anderen HTTP/2-Datenstroms enthalten. HTTP/2 beseitigt die Blockierung durch die Reihenfolge der Antworten, behält aber diese Blockierung auf Transportebene bei.

HTTP/3 bildet HTTP auf QUIC ab, ein Transportprotokoll über UDP, und komprimiert Header mit QPACK. QUIC bietet zuverlässige Datenströme, Fluss- und Überlastkontrolle sowie Sicherheit durch TLS 1.3. Jeder Datenstrom hat seine eigene Auslieferungsreihenfolge. Fehlende Daten in einem Datenstrom verhindern für sich genommen nicht die Auslieferung bereits empfangener Daten in einem anderen. Gemeinsame Überlastkontrolle und Abhängigkeiten innerhalb der Anwendung können weiterhin mehrere Datenströme betreffen.

QUIC nutzt Verbindungs-IDs, damit eine Verbindung eine Änderung der IP-Adresse übersteht, etwa beim Wechsel vom WLAN zum Mobilfunk. Seine Implementierung kann mit einer Anwendungsbibliothek aktualisiert werden. So wird der langsame Verbreitungsweg von TCP-Änderungen in Betriebssystemen und Middleboxes umgangen.

Eine neue Verbindung vergleichen

Bei RTT 50 ms und ohne Aufwand für DNS oder Verarbeitung benötigen TCP und TLS 1.3 zwei RTTs, bevor die erste HTTP/2-Anfrage abgesendet wird. Eine erste Antwort beginnt nach etwa 150 ms. QUIC kombiniert Transport- und Sicherheitsaufbau in einer RTT, sodass eine HTTP/3-Antwort nach etwa 100 ms beginnen kann. Wiederaufgenommene QUIC-Verbindungen können 0-RTT-Daten nutzen, aber das Risiko eines Wiederholungsangriffs beschränkt, welche Anfragen sich gefahrlos früh senden lassen.

Browser können HTTP/3 über Alt-Svc oder DNS-HTTPS-Einträge entdecken. Ist UDP blockiert, können sie auf HTTP über TCP zurückfallen. HTTP/3 bleibt zuverlässig, weil QUIC oberhalb von UDP Zuverlässigkeit bereitstellt.

Ein Name wie www.example.org ist für Menschen praktisch. Eine Verbindung benötigt eine IP-Adresse. Das Domain Name System, kurz DNS, ist sowohl die verteilte Datenbank der Namenseinträge als auch das Anwendungsprotokoll zu ihrer Abfrage. Es nutzt normalerweise Port 53 und arbeitet unabhängig von HTTP.

Die Namensverwaltung aufteilen

Lies www.example.org. von rechts nach links: Wurzel, org, example, dann www. Der letzte Punkt steht für die Wurzel und wird in der Alltagsschreibweise meist weggelassen. Ein zentraler Server für alle Namen würde eine Ausfallstelle, einen Verkehrsengpass und lange Pfade für entfernte Clients schaffen.

Root-Nameserver verweisen Resolver an TLD-Nameserver. TLD-Nameserver verweisen sie an die autoritativen Nameserver für Domains unterhalb der TLD. Autoritative Nameserver veröffentlichen die eigentlichen Einträge einer Domain. Die 13 benannten Serveridentitäten des Root-Dienstes sind auf viele physische Instanzen repliziert; 13 ist nicht die Anzahl der Rechner, die das weltweite DNS tragen.

Der Host sendet seine Frage normalerweise an einen lokalen Resolver, den seine Organisation, sein Internetanbieter oder ein öffentlicher Dienst bereitstellt. Dieser Resolver arbeitet im Auftrag des Hosts. Er ist keine weitere Ebene zwischen der Wurzel und der TLD in der Namenshierarchie.

Eine Namensauflösung bei leerem Cache verfolgen

Ein Laptop auf dem Campus benötigt die IPv4-Adresse von www.example.org:

1. Der Laptop fragt seinen lokalen Resolver nach der endgültigen Antwort.
2. Der Resolver fragt einen Root-Nameserver und erhält einen Verweis auf .org-Server.
3. Er fragt einen .org-Server und erhält einen Verweis auf die autoritativen Nameserver für example.org.
4. Er fragt einen autoritativen Nameserver und erhält 203.0.113.25.
5. Er gibt die Adresse an den Laptop zurück.

Es gibt vier Anfrage-Antwort-Paare, also acht Nachrichten. Die Anfrage des Hosts ist rekursiv: Beschaffe mir die Antwort. Die Anfragen des Resolvers sind iterativ: Jeder kontaktierte Server antwortet aus seinem Wissen oder verweist den Resolver weiter. Der Root-Nameserver beschafft die Adresse des Webservers nicht im Auftrag des Laptops.

Antworten bis zum Ablauf ihrer TTL wiederverwenden

Ein Ressourceneintrag enthält eine Gültigkeitsdauer, kurz TTL, die in Sekunden gemessen wird. Resolver halten wiederverwendbare Einträge in Caches, bis ihre zulässige Lebensdauer endet. Sie können sowohl Verweise als auch endgültige Adressen zwischenspeichern. Eine gespeicherte Delegation für eine TLD oder Domain ermöglicht es, bei einer späteren Namensauflösung frühere Schritte zu überspringen. Auch Betriebssysteme und Browser können Caches haben.

Bei einer RTT von 2 ms zwischen Host und Resolver und einer RTT von 30 ms für jede der drei aufeinanderfolgenden Hierarchieabfragen dauert die Namensauflösung bei leerem Cache etwa 92 ms. Eine beim Resolver zwischengespeicherte Adresse benötigt etwa 2 ms. Die Wartezeiten addieren sich, weil jeder Verweis Informationen für die nächste Anfrage liefert.

Caching verzögert auch Änderungen. Hat ein Resolver eine Adresse unmittelbar vor einer Aktualisierung mit einer TTL von einer Stunde zwischengespeichert, kann er die alte Adresse für die verbleibende Lebensdauer weiter zurückgeben. Das Absenken der TTL vor einer geplanten Änderung begrenzt diese Überschneidung; die Änderung des autoritativen Eintrags allein ersetzt nicht jede zwischengespeicherte Kopie.

DNS kann mehr als Namen in Adressen auflösen. Es unterstützt Aliase, findet Mailserver und verteilt Last, indem es mehrere Adressen für einen Dienst zurückgibt. Diese Aufgaben erklären, warum auch E-Mail-Zustellung und CDN-Auswahl von DNS abhängen.

DNS speichert Ressourceneinträge mit Name, Wert, Typ und TTL. Der Typ teilt dem Resolver mit, wie er den Wert deuten muss. Ein Adresseintrag, ein Alias und ein Mailservereintrag beantworten unterschiedliche Fragen zu derselben Domain.

Den Eintragstyp lesen

Beispielsweise gibt www.example.org. 3600 IN A 203.0.113.25 den zugehörigen Namen, die TTL, die Internetklasse, den Typ und die Adresse an. Ein NS-Wert ist ein Name, keine Adresse. Ein Verweis kann einen separaten A-Eintrag mit der Adresse des Nameservers enthalten, der oft Glue-Eintrag genannt wird, wenn er zur Auflösung der Delegation benötigt wird.

Ein CNAME wie media.example.org, der auf edge.cdn.example.net zeigt, veranlasst den Resolver, die Adresse des Ziels nachzuschlagen. Ein MX-Eintrag steuert dagegen die E-Mail-Zustellung. Versuche bei den Präferenzen 10 und 20 zuerst den Mailserver mit Präferenz 10; eine größere Zahl bedeutet keine höhere Priorität.

Die Nachricht um die Einträge lesen

Anfragen und Antworten haben ein gemeinsames Format. Der 12 Byte lange Header enthält eine Identifikationsnummer, Flags und die Anzahl der Einträge in vier Abschnitten. Die Antwort übernimmt die ID der Anfrage, damit der Anfragende den Austausch zuordnen kann.

Der Frageabschnitt nennt, was angefordert wurde. Der Antwortabschnitt enthält passende Einträge. Der Autoritätsabschnitt kann NS-Verweise enthalten, während der zusätzliche Abschnitt hilfreiche Einträge wie Nameserveradressen liefert. In der Ausgabe von dig kennzeichnet qr eine Antwort, rd bedeutet, dass Rekursion angefordert wurde, und ra, dass Rekursion verfügbar ist. NOERROR meldet keinen DNS-Fehler; NXDOMAIN meldet, dass der abgefragte Name nicht existiert. Auch eine Antwort ohne Fehler kann keinen Eintrag des angeforderten Typs enthalten.

Um eine neue Domain zu veröffentlichen, registriert ein Inhaber sie und gibt die Daten ihrer autoritativen Nameserver an. Die Delegation der übergeordneten Domain leitet Anfragen an diese Server, die die eigenen Host- und Mail-Einträge der Domain veröffentlichen. Durch die Registrierung des Namens wird der Registrar nicht zum Server, der jeden Eintrag speichert.

Übertragung und Schutz

Die meisten kleinen DNS-Austausche nutzen UDP-Port 53. Bei einer gekürzten UDP-Antwort ist das TC-Flag gesetzt; der Resolver kann es über TCP-Port 53 erneut versuchen. TCP unterstützt auch Zonenübertragungen. DNS ist daher nicht auf UDP beschränkt.

Klassischer DNS-Verkehr legt abgefragte Namen für Beobachter auf seinem Pfad offen. DNS over TLS oder DNS over HTTPS verschlüsselt den Austausch zwischen Client und Resolver, üblicherweise über Port 853 beziehungsweise 443. Die Verschlüsselung dieses Austauschs und die Echtheit eines Eintrags sind getrennte Eigenschaften.

Beim Cache-Poisoning akzeptiert ein Resolver eine gefälschte Antwort und schickt Nutzer später an die falsche Adresse. Unvorhersehbare IDs und Quellports erschweren es, gefälschte Antworten passend zuzuordnen. DNSSEC ergänzt Signaturen, mit denen sich die Echtheit von Einträgen prüfen lässt; es verbirgt die Anfrage nicht. Auch Überflutungsangriffe können DNS-Server unerreichbar machen. Replikation und zwischengespeicherte Verweise verringern die Abhängigkeit vom Root-Dienst bei jeder Anfrage, aber Ausfälle bei einem viel genutzten autoritativen Anbieter können weiterhin viele Websites beeinträchtigen.

E-Mail trennt das Verfassen einer Nachricht von ihrer Zustellung. Ein Benutzerprogramm ist die App oder Webseite zum Lesen und Schreiben von E-Mails. Ein Mailserver speichert eingehende E-Mails in Postfächern und hält ausgehende Nachrichten in einer Warteschlange. SMTP überträgt Nachrichten zwischen Systemen.

Die Zustellung nach der Einlieferung verfolgen

Alice liefert bei ihrem eigenen Server eine Nachricht für Bob ein. Dieser Server schlägt die MX-Einträge für Bobs Domain nach, löst die Adresse des gewählten Servers auf und öffnet eine TCP-Verbindung zu Port 25. Er überträgt die Nachricht an Bobs Server, der sie in dessen Postfach speichert. Alices Server ist bei dieser Übertragung der SMTP-Client, obwohl er in einem anderen Austausch Alices Benutzerprogramm als Server bedient.

Ist das Ziel vorübergehend nicht verfügbar, behält die Ausgangswarteschlange die Nachricht für weitere Versuche. Alices Gerät kann offline gehen, während ihr Server weiterarbeitet. Nach wiederholtem Fehlschlag kann ein Unzustellbarkeitsbericht an den Absender im Umschlag zurückgehen.

Den Dialog lesen

SMTP nutzt Textbefehle und numerische Antworten. Hier ist ein verkürzter Zustellungsdialog; C: und S: bezeichnen die beiden Seiten und werden nicht als Teil jedes Befehls übertragen.

S: 220 mail.example.net ready
C: EHLO mail.example.org
S: 250 mail.example.net
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.net>
S: 250 OK
C: DATA
S: 354 Send message
C: From: Alice <alice@example.org>
C: To: Bob <bob@example.net>
C: Date: Tue, 03 Mar 2026 10:02:44 +0100
C: Subject: Lab report
C:
C: The report is ready.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Closing

Mit EHLO stellt sich der sendende Host vor. MAIL FROM legt den Absender im Umschlag fest; jedes RCPT TO nennt einen Empfänger im Umschlag. DATA beginnt die Nachricht und eine Zeile, die nur einen Punkt enthält, beendet sie. Eine Verbindung kann mehr als eine Nachricht übertragen. Antwortklassen unterscheiden Erfolg (2xx), die Aufforderung zu weiterer Eingabe (3xx), vorübergehenden Fehler (4xx) und dauerhaften Fehler (5xx). Eine 4xx-Antwort verlangt einen späteren erneuten Versuch; ein 5xx-Fehler erfordert eine andere Behandlung, oft eine Unzustellbarkeitsmeldung.

Zustelladressen und angezeigte Felder unterscheiden

Der SMTP-Umschlag steuert die Zustellung. Die Felder From: und To: innerhalb der Nachricht werden den Lesenden angezeigt. Sie können sich vom Umschlag unterscheiden. Ein Bcc-Empfänger kann in RCPT TO erscheinen, ohne in den sichtbaren Nachrichtenheadern zu stehen. Für die Antwort auf eine Nachricht und für die Meldung eines Zustellfehlers muss nicht dieselbe Adresse verwendet werden.

Ein Nutzer liefert E-Mails normalerweise über authentifiziertes SMTP an Port 587 mit STARTTLS oder an Port 465 mit TLS von Anfang an ein. Die Übertragung zwischen Servern nutzt normalerweise Port 25 und kann STARTTLS aushandeln. Einlieferung und Übertragung haben unterschiedliche Aufgaben, auch wenn beide SMTP nutzen. HTTP ruft im Allgemeinen angeforderte Objekte ab; SMTP überträgt eine vorbereitete Nachricht aktiv.

Die Domain des Absenders prüfen

Ein sichtbares From:-Feld lässt sich leicht fälschen. SPF prüft, ob der sendende Host für die Domain im Umschlag autorisiert ist. DKIM prüft eine Nachrichtensignatur mit einem in DNS veröffentlichten öffentlichen Schlüssel. DMARC verknüpft ein erfolgreiches SPF- oder DKIM-Ergebnis durch Domainübereinstimmung mit der sichtbaren From-Domain und veröffentlicht eine Richtlinie für Fehlschläge. Ein erfolgreiches SPF-Ergebnis für eine nicht zugehörige Domain im Umschlag bestätigt allein nicht den sichtbaren Absender.

E-Mail-Übertragung, Nachrichteninhalt und Postfachzugriff sind getrennte Teile von E-Mail. SMTP überträgt eine Nachricht zu einem Mailserver. Die Nachricht hat ihr eigenes Format mit Header und Nachrichtentext; ein Empfänger greift später über ein anderes Protokoll auf das gespeicherte Postfach zu.

Die Nachricht selbst lesen

Eine Nachricht beginnt mit Feldern wie From:, To:, Date:, Subject: und Message-ID:. Eine Leerzeile trennt diese Header vom Nachrichtentext. Sie bleiben Teil der gespeicherten Nachricht; die SMTP-Befehle MAIL FROM und RCPT TO werden nicht zu Nachrichtenheadern.

Das Grundformat nutzt Textzeilen. MIME, Multipurpose Internet Mail Extensions, beschreibt vielfältigere Inhalte mit zusätzlichen Feldern. Content-Type: text/plain; charset=UTF-8 beschreibt reinen Text und seine Zeichencodierung. image/jpeg bezeichnet ein Bild. multipart/mixed beschreibt mehrere Teile, die durch eine Trennzeichenkette voneinander abgegrenzt sind, etwa eine Textnotiz gefolgt von einem Anhang. Jeder Teil kann seinen eigenen Inhaltstyp und seine eigene Übertragungscodierung haben.

Content-Transfer-Encoding beschreibt, wie ein Teil für die Übertragung dargestellt wird. Base64 wandelt jede Gruppe von drei Bytes in vier ASCII-Zeichen um. Bei einem Anhang von 3 MB werden aus 3.000.000 Byte vor Zeilenumbrüchen und Nachrichtenheadern 4.000.000 Zeichen. Die Codierung erhöht die Größe um etwa ein Drittel. Die Gesamtgrößenbeschränkung eines Servers für Nachrichten lässt sich daher nicht allein mit der Rohgröße des Anhangs vergleichen. Quoted-Printable ist eine weitere Codierung, die sich für überwiegend lesbaren Text eignet.

Ein E-Mail-Zugriffsprotokoll wählen

Der Server des Empfängers kann E-Mails empfangen, während dessen Geräte offline sind. Wenn der Empfänger zurückkehrt, ermöglicht ein E-Mail-Zugriffsprotokoll einem Client, gespeicherte Nachrichten abzurufen.

IMAP kann die Header oder ausgewählte Teile einer Nachricht abrufen, ohne jeden Anhang herunterzuladen. Es nutzt gewöhnlich Port 143 mit STARTTLS oder Port 993 mit TLS von Anfang an. POP3 nutzt üblicherweise Port 110 oder TLS an Port 995. Seine Löschmarkierungen werden wirksam, wenn die Sitzung normal endet. Beim Herunterladen und Behalten bleiben Kopien auf dem Server, aber POP3 bietet weder die Serverordner noch die gemeinsamen Kennzeichnungen von IMAP.

Angenommen, Bob prüft seine E-Mails auf einem Laptop, bevor er das Haus verlässt, und danach auf einem Smartphone. Nutzt der Laptop POP3 zum Herunterladen und Löschen, findet das Smartphone möglicherweise ein leeres Serverpostfach vor. Bei IMAP ändert das Markieren einer Nachricht als gelesen auf dem Laptop den Serverzustand, den auch das Smartphone sehen kann. Der Unterschied liegt in der Postfachsynchronisation, nicht in der SMTP-Zustellung.

Eine Webmail-Nachricht über den Browser hinaus verfolgen

Ein Browser liefert E-Mails über HTTPS ein oder liest sie darüber. Der Webmail-Anbieter nutzt weiterhin SMTP, um E-Mails zum Server einer anderen Domain zu übertragen. Ein vollständiger Weg kann daher über HTTPS vom Sender zum Anbieter, SMTP zwischen den Anbietern und anschließend IMAP oder HTTPS auf der Empfängerseite führen. Die Bezeichnung Webmail beschreibt die Benutzeroberfläche und die Browserverbindung eines Dienstes, nicht jedes Protokoll auf dem Weg der Nachricht.

Eine Datei zu verteilen bedeutet, dass jeder Empfänger eine vollständige Kopie erhalten muss. Der Engpass ist nicht immer der Server: Ein langsamer Empfänger oder eine unzureichende gesamte Uploadkapazität kann die Mindestdauer bestimmen. Das Standardmodell setzt voraus, dass die Zugangsverbindungen die Engpässe sind und der Netzkern genügend Kapazität hat.

Die unteren Schranken vergleichen

Die Datei enthalte $F$ Bit und es gebe $N$ Empfänger. Der Server lädt mit $u_s$ hoch; Peer $i$ lädt mit $u_i$ hoch und mit $d_i$ herunter. Die niedrigste Downloadrate der Peers ist $d_{min}$. Verwende zueinander passende Einheiten wie Mbit und Mbps, damit die Division Sekunden ergibt.

Bei der Client-Server-Verteilung muss der Server $NF$ Bit senden und der langsamste Peer $F$ Bit empfangen:

Bei P2P muss der Server jedes Bit mindestens einmal einspeisen. Die Peers müssen weiterhin die Datei herunterladen und das gesamte System muss genügend Daten für alle Kopien hochladen:

Nimm das Maximum, weil während der Verteilung alle Anforderungen erfüllt werden müssen. Die Terme zu addieren würde fälschlich voraussetzen, dass diese Upload- und Downloadvorgänge nacheinander stattfinden. Dies sind untere Schranken; Protokollaufwand, nicht verfügbare Peers und andere Engpässe können reale Übertragungen verlangsamen.

Einen Vergleich durchrechnen

Verwende für eine Datei von 2 Gbit den Wert 2.000 Mbit. Der Server lade mit 100 Mbps hoch, der langsamste Download betrage 20 Mbps und jeder der 100 Peers lade mit 5 Mbps hoch.

Der Serverterm bei Client-Server ist 200.000 Mbit dividiert durch 100 Mbps, also 2.000 s. Der Term für den langsamsten Download beträgt 100 s. Die Schranke beträgt daher 2.000 s.

Bei P2P dauert das Einspeisen der Datei mindestens 20 s. Der langsamste Download dauert weiterhin 100 s. Die gesamte Uploadkapazität beträgt 100 plus 500, also 600 Mbps; die Verteilung von 200.000 Mbit dauert mindestens etwa 333 s. Die P2P-Schranke beträgt etwa 333 s. Bei 1.000 Peers steigt die Client-Server-Schranke auf 20.000 s, während die P2P-Schranke etwa 392 s beträgt. Bei gleichen Uploadraten der Peers nähert sich der Term für die Gesamtkapazität mit wachsender Peerzahl der Dateigröße dividiert durch die Uploadrate eines Peers.

Dateistücke in BitTorrent tauschen

Ein Torrent ist eine Gruppe, die eine Datei teilt. Peers tauschen Dateistücke, finden Nachbarn über einen Tracker oder eine verteilte Hashtabelle und können bereits vor Abschluss des Downloads hochladen. Ein Seeder besitzt die vollständige Datei und teilt sie weiter.

Rarest First wählt ein benötigtes Stück aus, das die wenigsten Nachbarn besitzen. Das hilft, Stücke zu erhalten, die sonst verschwinden könnten, wenn ein Peer ausscheidet. Es entscheidet, was angefordert wird. Das Gegenseitigkeitsprinzip fördert nützlichen Austausch, indem es Nachbarn bevorzugt, die schnell Daten liefern; es entscheidet, für wen hochgeladen wird.

Im ursprünglichen Entwurf ist die Sperre für jeweils vier interessierte Nachbarn aufgehoben, darunter einer durch versuchsweises Aufheben der Sperre. Die reguläre Auswahl wird etwa alle 10 s und der versuchsweise gewählte Peer etwa alle 30 s überprüft. Dieser Platz zum Erkunden gibt neuen Teilnehmern eine Möglichkeit, erste Stücke zu erhalten, und hilft, bessere Partner zu finden. Der Tracker koordiniert die Suche; er ist nicht die Datenquelle für jedes Stück.

Ein Video besteht aus Bildern, die über die Zeit angezeigt werden. Kompression entfernt wiederholte Informationen innerhalb eines Bildes (räumliche Redundanz) und zwischen Bildern (zeitliche Redundanz). Das codierte Ergebnis hat eine Bitrate: die Datenmenge, die für jede Sekunde Videowiedergabe benötigt wird.

Rate, Größe und Wiedergabedauer verknüpfen

Ein zweistündiges Video mit 5 Mbps enthält 36.000 Mbit oder 4,5 GB. Multipliziere die Rate mit der Dauer, um Bit zu erhalten, und dividiere dann durch acht für Byte. Liegt der durchschnittliche Durchsatz des Pfades unter der gewählten Videorate, leert sich bei fortgesetzter Wiedergabe irgendwann jeder endliche Puffer.

Ein Wiedergabegerät kann beginnen, bevor das ganze Video heruntergeladen ist. Es speichert kommende Daten in einem Puffer, der hier in Sekunden abspielbaren Videos gemessen wird. Die Wiedergabe verbraucht den Puffer, während Downloads ihn auffüllen. Ein größerer Anfangspuffer schützt vor Durchsatzeinbrüchen, erhöht aber die Startverzögerung.

Jeweils ein Segment anfordern

DASH, Dynamic Adaptive Streaming over HTTP, speichert mehrere codierte Versionen mit unterschiedlichen Raten und teilt jede in Segmente. Ein Manifest führt verfügbare Versionen und Segment-URLs auf. Der Client fordert ein Segment mit HTTP GET an und wählt an der nächsten Segmentgrenze erneut eine Version. HLS nutzt einen ähnlichen Ansatz mit Wiedergabelisten.

Das Wiedergabegerät trifft die Anpassungsentscheidung anhand des gemessenen Durchsatzes und des Pufferfüllstands. Ein hoher aktueller Schätzwert für den Durchsatz spricht für eine höhere Rate; ein niedriger Pufferfüllstand verlangt Vorsicht. Die höchste einmal erreichte Rate zu wählen, kann eine Unterbrechung verursachen, wenn der nächste Download langsamer wird. Wiedergabegeräte versuchen auch, häufige, störende Qualitätswechsel zu vermeiden.

Den Download eines Segments berechnen

Betrachte 4 s lange Segmente, die mit 1, 2,5, 5 und 8 Mbps codiert sind. Bei einem gemessenen Durchsatz von 6 Mbps enthält das Segment mit 5 Mbps 20 Mbit. Es wird in etwa 3,33 s heruntergeladen und fügt 4 s abspielbaren Inhalt hinzu, während die Wiedergabe etwa 3,33 s verbraucht. Bei fortlaufender Wiedergabe wächst der Puffer um etwa 0,67 s.

Ein Segment mit 8 Mbps enthält 32 Mbit und benötigt etwa 5,33 s, sodass der Puffer um etwa 1,33 s schrumpft. Die 6 Mbps des Pfades sind eine Übertragungsrate; sie machen aus einer Codierung mit 8 Mbps keine mit 6 Mbps.

Fällt der Durchsatz auf 3 Mbps, benötigt dasselbe Segment mit 5 Mbps etwa 6,67 s. Der Puffer verliert pro Segment etwa 2,67 s. Der Wechsel zur Version mit 2,5 Mbps ergibt ein Segment von 10 Mbit, das etwa 3,33 s benötigt, sodass der Puffer wieder wachsen kann. Für eine unterbrechungsfreie Wiedergabe während eines Downloads muss der Anfangspuffer außerdem reichen, bis neue abspielbare Daten verfügbar sind.

Gespeicherte Streams und interaktive Anrufe

Das Streaming gespeicherter Videos nutzt gewöhnliche HTTP-Objekte, die Browsercaches und CDN-Server ausliefern können. Es läuft daher je nach HTTP-Version über TCP oder QUIC. Interaktive Anrufe nutzen häufig Medienübertragung auf UDP-Basis, weil das Warten auf ältere Mediendaten schlechter sein kann als deren Verlust.

Ein Liveereignis kann ebenfalls segmentiertes HTTP-Streaming nutzen, aber das Wiedergabegerät wartet darauf, dass jedes Segment erzeugt wird, und hält einen Puffer mit Abstand zum Livegeschehen. Kürzere Segmente können diese Verzögerung verringern, erhöhen aber die Anzahl der Anfragen. Ein Sprung zu einer ungepufferten Stelle erfordert ebenfalls ein erneutes Auffüllen des Puffers, was die Qualität kurzzeitig senken kann.

Ein Content Delivery Network, kurz CDN, liefert Kopien von Inhalten von vielen Standorten aus. Es vermeidet, jeden Zuschauer an ein einziges entferntes Rechenzentrum zu verweisen, und verringert wiederholte Übertragungen über große Entfernungen. Die Verteilung der Dienstkapazität verringert außerdem die Abhängigkeit von einem Standort.

Inhalte nahe bei den Nutzern platzieren

Ein privates CDN gehört einem Anbieter; ein Drittanbieter-CDN bedient viele Kunden. Beide können neben Videos auch Bilder, Skripte, Software und Webseiten ausliefern. Die ursprüngliche Inhaltsquelle ist der Ursprungsserver. CDN-Cluster halten Kopien vor, damit der Ursprungsserver nicht jede Anfrage bearbeiten muss.

Es gibt zwei nützliche Platzierungsstrategien:

Platzierung und Befüllung mit Inhalten sind getrennte Entscheidungen. Beim Pull-Verfahren holt ein Cluster ein fehlendes Objekt vom Ursprungsserver oder einem anderen Cluster, speichert es und liefert es aus. Beim Push-Verfahren sendet der Anbieter Objekte im Voraus, häufig zu wenig ausgelasteten Zeiten. Die erste Anfrage an ein Pull-CDN für ein nicht zwischengespeichertes Objekt kann weiterhin vom Ursprungsserver abhängen.

Eine DNS-Übergabe verfolgen

Ein Nutzer fordert https://video.stream.example.com/v/6Y7B23V an:

1. Der Resolver des Nutzers fragt nach video.stream.example.com.
2. Der autoritative Server des Anbieters gibt einen CNAME in den Namensraum des CDN zurück, etwa a1105.cdn.example.net.
3. Der Resolver folgt diesem Namen zum autoritativen DNS-Dienst des CDN.
4. Das CDN wählt einen Cluster und gibt eine Adresse wie 198.51.100.17 zurück.
5. Der Client verbindet sich über HTTPS mit diesem Server und fordert den Inhalt an.

Der CNAME verändert, wo die Namensauflösung fortgesetzt wird. DNS gibt Namensinformationen zurück; die Videobytes kommen anschließend über HTTP. Sind die Inhalte segmentiert, folgen viele gewöhnliche Segmentanfragen demselben grundlegenden Pfad zu einem ausgewählten Server.

Einen geeigneten Standort wählen

Der auf einer Karte nächste Cluster kann einen schlechten Netzwerkpfad haben oder überlastet sein. Eine DNS-basierte Entscheidung sieht möglicherweise den Standort des Resolvers, der weit vom Nutzer entfernt sein kann. Eine bessere Auswahl kann gemessene Verzögerung und Verluste, die aktuelle Last und manchmal Informationen über das Netz des Clients berücksichtigen.

IP-Anycast bietet einen weiteren Weg zu einem nahe gelegenen Dienst: Mehrere Standorte geben dieselbe IP-Adresse bekannt und das Internetrouting wählt einen Pfad zu einem von ihnen. Welcher Standort erreicht wird, hängt vom Routing ab und nicht allein von der räumlichen Entfernung. Ein Server nahe am Zuschauer kann trotzdem schlechte Videoqualität liefern, wenn die Zugangsverbindung des Zuschauers selbst der Engpass ist.

Netflix Open Connect platziert Geräte innerhalb der Netze von Internetanbietern und verbindet sie an Austauschstandorten. Inhalte werden vor der Nachfrage bereitgestellt, was den vorgelagerten Datenverkehr zu Spitzenzeiten verringert. Die Anwendungsdienste und die Auslieferung codierter Videos müssen nicht auf derselben Infrastruktur laufen. Andere private CDN-Architekturen können Caches bei Bedarf füllen. In jedem Fall steuert adaptives Streaming, welche Rate das Wiedergabegerät anfordert, während das CDN mitbestimmt, über welchen Pfad und von welchem Server diese Anfragen bedient werden.

Python-Sockets senden Bytes. Codiere eine Zeichenkette vor dem Senden und decodiere die empfangenen Bytes anschließend; die standardmäßige Textcodierung ist UTF-8. AF_INET wählt IPv4 und SOCK_DGRAM UDP. Beginne mit einem lokalen Dienst, damit beide Prozesse die Loopback-Adresse 127.0.0.1 nutzen können.

Den Empfänger zuerst starten

Dieser Server verarbeitet kurze Textdatagramme und antwortet in Großbuchstaben:

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as server:
    server.bind(("127.0.0.1", 12000))
    while True:
        data, client_addr = server.recvfrom(2048)
        reply = data.decode().upper().encode()
        server.sendto(reply, client_addr)

bind weist dem Socket seine Empfangsadresse und seinen Port zu. Die Bindung an 127.0.0.1 akzeptiert nur lokalen Verkehr. Die leere Adresszeichenkette "" bindet dagegen an alle IPv4-Schnittstellen und macht den Dienst von anderen Hosts aus erreichbar, wenn das Netz es zulässt. Stoppe den laufenden Server, bevor du eine weitere Kopie am selben Endpunkt startest.

recvfrom blockiert, bis ein Datagramm eintrifft. Der Aufruf gibt die Daten und die Adresse des Senders einschließlich seines Ports zurück. Der Server nutzt dieses zurückgegebene Paar als Ziel von sendto und kann so Clients antworten, deren ephemere Ports er nicht im Voraus kannte.

Eine Anfrage senden und die Wartezeit begrenzen

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as client:
    client.settimeout(2.0)
    client.sendto(b"hello network", ("127.0.0.1", 12000))
    try:
        data, server_addr = client.recvfrom(2048)
        print(data.decode())
    except TimeoutError:
        print("No reply within 2 seconds")

Das Präfix b erzeugt ein Bytes-Literal; "hello network".encode() erzeugt dieselben Bytes. Das Betriebssystem weist den lokalen Port des Clients bei Bedarf zu. Die erwartete Antwort ist HELLO NETWORK. Keines der beiden Programme ruft listen oder accept auf, weil UDP keinen Transportverbindungsaufbau hat.

Eine fehlende Antwort sagt dem Client nicht genau, was fehlgeschlagen ist. Die Anfrage oder Antwort kann verloren gegangen sein oder es lauscht kein Server. Das Zeitlimit ermöglicht der Anwendung, die Kontrolle zurückzugewinnen. Manche Systeme können einen geschlossenen Zielport als Fehler melden; Windows kann beim Empfang ConnectionResetError auslösen.

Datagrammgrenzen beachten

Jeder Empfang verarbeitet ein Datagramm. Zwei Datagramme werden nicht zu einer Nachricht zusammengefasst. Ist der Empfangspuffer zu klein, wird der überstehende Teil des Datagramms auf typischen Unix-Systemen verworfen; Windows kann stattdessen einen Fehler melden. Ein weiterer Empfang stellt den fehlenden Rest nicht wieder her. Wähle einen Puffer, der für die erwarteten Nachrichten der Anwendung groß genug ist.

Die IPv4-UDP-Nutzlast ist bei einem IPv4-Header der Mindestgröße auf 65.507 Byte begrenzt. Das ist ein Protokollmaximum und keine sinnvolle Zielgröße für gewöhnliche Datagramme. Ein Programm, das Verluste erkennen muss, kann Nachrichten nummerieren, Sendezeiten mit time.perf_counter() festhalten und Zeitüberschreitungen zählen. Zwei Zeitüberschreitungen bei zehn Anfragen ergeben eine gemessene Verlustrate von 20 %. Das Wiederholen einer Anfrage kann eine doppelte Verarbeitung verursachen. Ein Entwurf mit Zeitlimit und Wiederholung benötigt daher möglicherweise auch eine Möglichkeit, wiederholte Nachrichtennummern zu erkennen.

TCP gibt dem Programm einen geordneten Bytestrom. Es erhält die Grenzen von sendall-Aufrufen nicht. Ein vollständiger kurzer Test kann in einem recv ankommen, aber ein korrektes Programm muss auch eine auf mehrere Empfangsvorgänge verteilte Anfrage behandeln.

Eine Textanfrage abgrenzen

Wähle einen Zeilenumbruch als Trennzeichen. Der Client sendet eine UTF-8-Zeile und der Server gibt eine Zeile in Großbuchstaben zurück. Dieser Server liest bis zu diesem Trennzeichen, bevor er decodiert:

from socket import socket, AF_INET, SOCK_STREAM

with socket(AF_INET, SOCK_STREAM) as server:
    server.bind(("127.0.0.1", 12000))
    server.listen(5)
    while True:
        conn, client_addr = server.accept()
        with conn:
            data = b""
            while b"\n" not in data:
                chunk = conn.recv(1024)
                if not chunk:
                    break
                data += chunk
            if b"\n" in data:
                line = data.split(b"\n", 1)[0]
                conn.sendall(line.decode().upper().encode() + b"\n")

listen erstellt einen lauschenden Socket. accept gibt einen neuen Verbindungssocket und die Adresse des Clients zurück. Verwende conn für die Bytes dieses Clients; der ursprüngliche Socket bleibt verfügbar, um weitere Verbindungen anzunehmen. Hier werden Clients einzeln bedient. Der Backlog von fünf betrifft ausstehende Verbindungen, nicht fünf aktive Arbeitsthreads.

Die Clientseite vervollständigen

from socket import create_connection

with create_connection(("127.0.0.1", 12000), timeout=2) as client:
    client.sendall(b"hello network\n")
    data = b""
    while b"\n" not in data:
        chunk = client.recv(1024)
        if not chunk:
            raise EOFError("Reply ended before its newline")
        data += chunk
    print(data.split(b"\n", 1)[0].decode())

Das erwartete Ergebnis ist HELLO NETWORK. sendall sendet weiter, bis alle übergebenen Bytes übergeben wurden oder ein Fehler auftritt. Ein einzelnes send sendet möglicherweise nur einen Teil und meldet, wie viele Bytes es angenommen hat. Keiner der beiden Aufrufe übermittelt dem Empfänger Nachrichtengrenzen der Anwendung.

Dieser Dienst akzeptiert eine Zeile pro Verbindung. Ein persistenter Dienst mit mehreren Nachrichten würde Bytes nach dem ersten Zeilenumbruch für seine nächste Nachricht behalten. Längenpräfixe und das Schließen der Senderichtung sind weitere Möglichkeiten zur Nachrichtenabgrenzung. Der Empfang von b"" bedeutet, dass der Peer seine Senderichtung beendet hat; es ist kein leerer Datenblock, bei dem weiter versucht werden sollte zu lesen.

Den Code mit realen Protokollen verbinden

Auch eine HTTP/1.1-Anfrage ist eine Folge von Bytes:

from socket import create_connection

request = ("GET / HTTP/1.1\r\n"
           "Host: example.com\r\n"
           "Connection: close\r\n\r\n")
with create_connection(("example.com", 80), timeout=5) as sock:
    sock.sendall(request.encode("ascii"))
    chunks = []
    while True:
        chunk = sock.recv(4096)
        if not chunk:
            break
        chunks.append(chunk)
print(b"".join(chunks).decode(errors="replace")[:200])

Dies zeigt den Anfang der rohen Antwort einschließlich Status und Headern. Ein Server kann einen Fehler oder eine Umleitung zurückgeben; der Code setzt keinen bestimmten Nachrichtentext voraus. HTTPS an Port 443 benötigt eine TLS-Umhüllung mit Zertifikats- und Hostnamenprüfung, nicht nur eine geänderte Portnummer. Beispielsweise umhüllt ssl.create_default_context().wrap_socket(sock, server_hostname="example.com") nach import ssl einen verbundenen Socket. Eine abgelehnte Verbindung bedeutet häufig, dass kein Server lauscht; bei stillschweigend verworfenem Verkehr kann ein Zeitlimit ablaufen. Für schnelle Serverneustarts unter Unix kann das Setzen von SO_REUSEADDR vor bind die Wiederverwendung erlauben, während eine alte Verbindung abgebaut wird; es erlaubt nicht, dass zwei aktive lauschende Sockets denselben Endpunkt belegen. Nebenläufige Server nutzen Threads oder Ereignisschleifen und unterscheiden Verbindungen anhand beider Adress-Port-Paare der Endpunkte.