- So wie NetworkManager kurze Verbindungsinstabilitäten als „kein Netzwerk“ einstuft, vertrauen manche Softwarekomponenten ihrer eigenen Zustandsbeurteilung mehr als der TCP-Wiederherstellung – in realen Netzwerken kann das jedoch gefährlich sein
- Der Glaube, dass „gesendete Daten ankommen“, „beide Seiten sich am Ende über die übertragenen Bytes einigen“ oder man dies mit Anwendungsprotokollen wie HTTP oder SMTP garantieren könne, bricht in manchen Situationen zusammen
- Wird die Verbindung während der ACK-Verarbeitung unterbrochen, kann der Sender nicht wissen, ob das Segment angekommen ist; diese Grenze lässt sich wie beim Two Generals’ Problem nicht mit einem einzelnen TCP-Stream zwischen zwei Parteien lösen
- Auch SMTP behandelt dieses Problem in RFC 1047 und RFC 2821; an dem Punkt, an dem die Zustellverantwortung übergeht, gibt es bei Verbindungsfehlern eine mehrdeutige Phase, in der doppelte Zustellung oder Auslassungen entstehen können
- Wer seltsame Netzwerke als Ausnahme abtut oder Details wie den Nagle-Algorithmus, Congestion Control oder das Blockieren von ICMP ignoriert, interpretiert echte Störungen leicht falsch
Das Problem, den Netzwerkzustand vor TCP vorschnell festzulegen
- Ein Nutzer von NetworkManager erlebte früher in Wohnheim- und Campus-Roaming-Umgebungen instabile WLAN-Verbindungen und stellte fest, dass schon geringe Paketverluste dazu führten, dass dem ganzen System „kein Netzwerk“ gemeldet wurde
- Dabei konnte das Netzwerk kurz darauf bereits wieder verfügbar sein, und eine normale TCP-Wiederherstellung konnte – selbst mit stark erhöhter Latenz – für Anwendungen weitgehend transparent bleiben
- Das Beispiel zeigt das Problem, dass Anwendungen oder Systemkomponenten vorübergehende Störungen, die TCP selbst behandeln könnte, zu schnell als Fehler interpretieren
Häufige Irrtümer über TCP
- Die folgenden Aussagen tauchen im Umgang mit TCP oft auf, sind aber jeweils zumindest in manchen Fällen falsch
- TCP ist zuverlässig, also kommen alle gesendeten Daten beim Gegenüber an
- TCP ist im Großen und Ganzen zuverlässig
- Selbst wenn TCP keine vollständige Zuverlässigkeit im strengen Sinn bietet, einigen sich Sender und Empfänger am Ende exakt darauf, welche Bytes übertragen wurden
- Wenn man nachrichtenorientierte Anwendungsprotokolle wie HTTP oder SMTP auf TCP aufsetzt, kann man solche Garantien schaffen
- Es gibt so etwas wie TCP-Pakete
- Es gibt keine TCP-Pakete
- Wenn man einen bekannten entfernten Host nicht erreichen kann, ist man offline
- Der Nagle-Algorithmus ist gut
- Der Nagle-Algorithmus ist schlecht
- Man muss sich nicht um den Nagle-Algorithmus kümmern
- TCP kann man sich einfach als bidirektionale Unix-Pipe durchs Netzwerk vorstellen
- Wenn ein Netzwerk für TCP transparent ist, ist es auch für IP transparent
- Wenn ein Netzwerk für HTTP/1.1 transparent ist, ist es auch für TCP transparent
- Seltsame Netzwerke, die für Standardprotokolle nicht transparent sind, sind Ausnahmefälle und können ignoriert werden
- TCP ist auf IP implementiert
Warum es schwer ist, sich exakt auf übertragene Bytes zu einigen
- Die vorigen Punkte 1 bis 4 zur TCP-Zuverlässigkeit hängen mit dem Two Generals’ Problem zusammen
- Wenn die Verbindung unterbrochen wird, während ein ACK noch verarbeitet wird, hat der Sender keine Möglichkeit festzustellen, ob das betreffende Segment empfangen wurde
- Diese Grenze verschwindet nicht, auch wenn man über TCP noch komplexere Schichten stapelt
- Auf einem einzelnen TCP-Stream zwischen zwei Parteien lässt sich diese Garantie nicht herstellen; dafür braucht es ein Verfahren ähnlich Paxos oder Raft sowie mindestens drei Knoten
- Dieselbe Art von Problem betrifft nicht nur TCP, sondern auch Dienste zwischen zwei Parteien auf Basis von UDP oder IP
Die Grauzone der Zustellverantwortung, die SMTP sichtbar macht
- Bei SMTP tritt dieses Problem besonders deutlich zutage, weil der Dienst explizit berücksichtigen muss, ob beide Seiten den Nachrichtenerhalt anerkennen
- RFC 1047 behandelt das Problem aus SMTP-Sicht, und RFC 2821 schreibt vor, dass Implementierungen dem Kernratschlag aus RFC 1047 folgen sollen
- Im SMTP-Beispiel werden die folgenden Zustände unterschieden
- Man kann einen Punkt erreichen, an dem beide Seiten sich einig sind, dass die E-Mail vom Client an den Server übertragen wurde
- Man kann auch einen Punkt erreichen, an dem beide Seiten sich einig sind, dass der Server die Verantwortung für die Zustellung der E-Mail übernommen hat
- Davor muss jedoch zwingend ein mehrdeutiger Zustand durchlaufen werden, in dem unklar ist, wer gerade die Zustellverantwortung trägt
- Wird die Verbindung in diesem mehrdeutigen Zustand unterbrochen, kann die E-Mail dupliziert werden oder verloren gehen
- Die SMTP-Spezifikation legt fest, welche Seite im Zweifel eine E-Mail duplizieren soll, aber wie gut das in realen Implementierungen getestet wurde, ist unklar
- Das Ziel von Paxos und Raft besteht nicht nur darin, einen Endzustand zu erreichen, sondern gerade darin, solche mehrdeutigen Zustände zu vermeiden
Die Grenze des Wissens bei Einigung zwischen zwei Parteien
- Ein Kommentar meint, dass sich zwei Parteien selbst über einen unzuverlässigen, aber nicht bösartigen Link auf eine bestimmte Menge von Bytes einigen können, für die gilt: „Sie wurden zugestellt, und beide wissen das“
- In der ergänzenden Diskussion wird präzisiert, dass eine Partei zwar wissen kann, dass mindestens die ersten N Bytes zur vereinbarten Menge gehören, aber nicht, dass die vereinbarte Menge genau aus den ersten N Bytes besteht
- Deshalb kann es zwar eine Menge von Bytes geben, für die „sicher zugestellt und von beiden Seiten als zugestellt bekannt“ gilt, doch dahinter bleibt eine Grauzone, in der Sender und Empfänger den Wissensstand der Gegenseite nicht sicher festlegen können
- Wer diesen Unterschied übersieht, stößt in verteilten Systemen leicht auf seltsame Fehler
Fallstricke realer Netzwerke und unterer Schichten
- Der Glaube, man könne „seltsame Netzwerke, die für Standardprotokolle nicht transparent sind, ignorieren“, hat wiederholt Probleme verursacht
- Bufferbloat wird als Beispiel dafür genannt, dass Router Mechanismen der Congestion Control aushebeln können
- Problematisch können auch Netzwerke sein, die ICMP blockieren oder Datenverkehr verwerfen, den sie nicht verstehen
- Auch der Glaube, man müsse „über Congestion Control nichts wissen“, ist eher ein Beispiel für ein falsches Verständnis von TCP
- Ein Unterbeispiel dafür ist die Vorstellung, man müsse bei zu geringer Geschwindigkeit einfach mehrere TCP-Verbindungen öffnen
Noch keine Kommentare.