Falsche TCP-Annahmen, an die Programmierer glauben

 (lwn.net)
3 Punkte von GN⁺ 2024-09-16 | 1 Kommentare | Auf WhatsApp teilen

NetworkManager oder networkd

  • NetworkManager oder networkd

    • Der Nutzer erklärt, warum er auf eine Verwaltung auf Basis von wpa_supplicant umgestiegen ist
    • Er präsentiert eine Liste falscher Annahmen über TCP
    • Es geht um Missverständnisse bezüglich der Zuverlässigkeit von TCP

  • Liste falscher Annahmen über TCP

    • TCP ist immer zuverlässig
    • TCP ist meistens zuverlässig
    • TCP ist nicht zuverlässig, aber Sender und Empfänger werden sich am Ende über die übertragenen Bytes einig sein
    • Wenn man über TCP ein nachrichtenorientiertes Protokoll aufbaut, kann man Zuverlässigkeit garantieren
    • Es gibt so etwas wie TCP-Pakete
    • Es gibt so etwas wie TCP-Pakete nicht
    • Wenn die Verbindung zu einem entfernten Host fehlschlägt, ist dieser offline
    • Der Nagle-Algorithmus ist gut
    • Der Nagle-Algorithmus ist schlecht
    • Man muss sich um den Nagle-Algorithmus nicht kümmern
    • TCP behandelt das Netzwerk transparent
    • Wenn das Netzwerk für TCP transparent ist, ist es auch für IP transparent
    • Wenn das Netzwerk für HTTP/1.1 transparent ist, ist es auch für TCP transparent
    • Netzwerke, die für Standardprotokolle nicht transparent sind, sind Ausnahmen
    • TCP ist auf Basis von IP implementiert

  • Erklärung

    • Wenn die Verbindung abbricht, während ein ACK noch aussteht, kann der Sender nicht wissen, ob das Segment empfangen wurde
    • Es werden Algorithmen wie Paxos oder Raft benötigt, und dafür sind mindestens drei Knoten nötig
    • Dieses Problem tritt auch bei Protokollen wie SMTP auf

  • Zusätzliche Anmerkungen

    • Zwei Parteien können über einen unsicheren Link Einigkeit erreichen
    • Sie können sich über eine Teilmenge der übertragenen Bytes einigen
    • Die Menge der vereinbarten Bytes kann 0 sein und anschließend wachsen
    • Paxos ist nicht erforderlich

  • Weitere Diskussion

    • Der exakte Bereich der vereinbarten Bytes ist nicht bekannt
    • Falsche Annahmen über Netzwerktranzparenz verursachen Probleme
    • Es gibt Netzwerke, die ICMP blockieren oder Pakete verwerfen, die sie nicht verstehen
    • Wissen über Congestion Control ist erforderlich

Zusammenfassung von GN⁺

  • Dieser Artikel behandelt falsche Annahmen über die Zuverlässigkeit von TCP und enthält eine Diskussion über die Wahl von Netzwerkverwaltungs-Tools
  • Es wird erklärt, dass Zuverlässigkeitsprobleme bei TCP komplexe Algorithmen wie Paxos erforderlich machen
  • Es wird betont, dass falsche Annahmen über Netzwerktranzparenz in der Praxis Probleme verursachen können
  • Es werden verschiedene Faktoren vorgestellt, die bei der Auswahl von Netzwerkverwaltungs-Tools berücksichtigt werden sollten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-16
Hacker-News-Kommentare

  • Das Format „falsehoods programmers believe“ ist nicht klar, was verwirrend wirkt

    • Die Debatte darüber, ob TCP-Pakete existieren, ist nicht nachvollziehbar
    • Das sorgt für philosophische Verwirrung

  • Es ist erstaunlich, dass eine Verbindung bestehen bleibt, selbst wenn man das Ethernet-Kabel abzieht und wieder einsteckt

    • TCP wurde so entworfen, dass es sogar dann weiter funktioniert, wenn Bomben fallen

  • Eine Zustellgarantie vom Typ „at most once“ oder „at least once“ ist möglich, aber „exactly once“ ist unmöglich

    • Viele Junior-Entwickler halten das Fehlen einer „exactly once“-Zustellgarantie für einen Bug

  • Wenn bei einem ausstehenden ACK die Verbindung abbricht, kann der Sender nicht wissen, ob das Segment empfangen wurde

    • TCP stellt eine bidirektionale Pipe bereit, und die exakte Zustellung ist Verantwortung der Anwendung
    • Wenn eine HTTP-Anfrage abbricht, bevor eine Antwort eintrifft, muss der Sender davon ausgehen, dass die Anfrage den Server nicht erreicht hat, und sie über eine neue Verbindung erneut versuchen

  • Es wird infrage gestellt, ob man noch nie von Fehlerkorrekturcodes gehört hat

    • TCP oder Ethernet-Frames enthalten FEC-Bytes
    • HTTP over TLS verwendet verschlüsselte Daten-Frames, und bei Datenverlust können diese nicht empfangen werden
    • Ein großer Teil des modernen Internets basiert auf diesem Paradigma

  • Wenn man innerhalb eines Rechenzentrums eigene Hardware nutzt, kann man Details auf niedriger Ebene ignorieren

    • Bandbreitenbegrenzung, Paket-RPS-Limits und Latenz bleiben dennoch wichtig

  • Dieser Artikel ist kein fertig ausgearbeiteter Text, und der HN-Einreichtitel könnte irreführend sein

  • Das erinnert an ein Problem, das man bei VKontakte lösen wollte

    • In der U-Bahn wird eine Nachricht gesendet, erreicht den Server, aber das Signal bricht ab, bevor die Antwort ankommt
    • Der Client wertet das als fehlgeschlagenen Versand und versucht es erneut
    • Das Problem wurde mit einer clientseitig erzeugten „random ID“ gelöst
    • Telegram sendet, wenn der Client die Verbindung zum Server wiederherstellt, alle Antworten, die während der vorherigen Verbindung nicht bestätigt wurden

  • Viele Menschen verstehen nicht, dass TCP kein Funktionsaufruf ist

    • Kürzlich wurde ein neuer TCP-Rate-Limiter in einem sehr fehlerhaften Zustand veröffentlicht
    • Die meisten Container dürften unter Bufferbloat-Problemen leiden