Die Bestätigung durch TCP garantiert nicht, dass die Daten geliefert wurden

In RFC 793 gibt es einen Teil über die Bestätigung von TCP-Segmenten:

Wenn der TCP ein Segment mit Daten überträgt, legt er eine Kopie in eine Warteschlange für die erneute Übertragung und startet einen Timer. Wenn die Bestätigung für diese Daten empfangen wird, wird das Segment aus der Warteschlange gelöscht. Wenn die Bestätigung nicht empfangen wird, bevor der Timer abgelaufen ist, wird das Segment erneut übertragen.

Eine Bestätigung durch TCP garantiert nicht, dass die Daten an den Endbenutzer geliefert wurden , sondern nur, dass der empfangende TCP die Verantwortung dafür übernommen hat.

Das ist interessant. In unserem NOC beheben wir häufig Konnektivitätsprobleme zwischen unserem Netzwerk und dem externen Client-Netzwerk. Wenn wir den Datenverkehr auf einer Firewall abhören und SYN- und ACK-Bits sehen, die in beide Richtungen gesendet und empfangen werden, gehen wir davon aus, dass die Konnektivität hergestellt ist und das Problem nichts zu tun hat mit Netzwerk tun.

Aber jetzt hat mich dieser RFC zum Nachdenken gebracht - was sollte ich noch überprüfen (ohne Wireshark einzurichten), wenn eine TCP-Verbindung hergestellt wurde, aber die Benutzer immer noch Verbindungsprobleme haben?

In diesem Teil des RFC geht es darum, die Verantwortung auf das Betriebssystem oder die nächste Stufe des Prozesses zu übertragen. Grundsätzlich geht es um die Trennung von Schichten.

Eine Bestätigung durch TCP garantiert nicht, dass die Daten an den Endbenutzer geliefert wurden, sondern nur, dass der empfangende TCP die Verantwortung dafür übernommen hat.

Ich habe immer so darüber nachgedacht:

• Das Betriebssystem kann zwischen dem Senden des ACK und dem Erreichen des Client-Prozesses abstürzen ("Client" bedeutet hier Client des Betriebssystems, nicht "Netzwerk-Client").
• Der Client-Prozess kann fehlerhaft oder abstürzend sein oder nur viel langsamer als erwartet, um mit den eingehenden Daten umzugehen oder sie nur unter nicht offensichtlichen Umständen zu lesen
• Wenn der Client die Daten weiterleitet, möglicherweise an eine Festplattendatei, wurde die Datei möglicherweise noch nicht geschrieben oder geleert
• Wenn der Client die Daten per TCP weiterleitet, hat der TCP auf der Gegenseite die Daten möglicherweise nicht übertragen, keine Bestätigung erhalten oder der Fernprozess hat die Daten erfolgreich verbraucht

Es heißt nur, dass dies eine Bestätigung der Schicht 3 ("Ich höre deine Bytes") ist, keine Bestätigung der höheren Schicht . Betrachten Sie zum Beispiel den Unterschied zwischen dem TCP-ACK, dem SMTP, 250 OKnachdem das Mail-Gateway für den nächsten Hop eine Nachricht akzeptiert, einer Nachrichtenempfangsnachricht (z. B. gemäß RFC 3798 ), einem nachgeöffneten Tracking-Pixel für Nachrichten, einem Dankesbrief von einer PA, und eine Antwort mit der Aufschrift "Ja, ich werde es tun."

Ein weiteres konkretes Beispiel wäre ein Drucker:

• Es muss die Daten frühzeitig bestätigen, bevor es weiß, was das Ende enthält (möglicherweise handelt es sich um eine Postscript-Datei, die mit einer enthaltenen Bibliothek beginnt, die größer als das TCP-Übertragungsfenster ist).
• Es könnte eine Statusabfrage enthalten ("Haben Sie Papier?", Die es offensichtlich ausführen kann)
• Es kann einen Druckbefehl enthalten ("Bitte drucken Sie diesen", der fehlschlagen kann, wenn kein Papier mehr vorhanden ist).

Ich würde vorschlagen, dass, wenn Benutzer ACKs sehen und senden, aber immer noch Verbindungsprobleme auftreten, es um Größenordnungen wahrscheinlicher ist, dass es Überlastungs-, Betriebssystem- oder Anwendungsprobleme gibt als alles, was ausschließlich mit dem Netzwerk zu tun hat.

Zur Diagnose schlage ich vor, nach Neuübertragungen zu suchen, anstatt nach den ACKs.

Aus RFC-Sicht ist der "Endbenutzer" die Anwendung. Es gibt keine Garantie dafür, dass die Anwendung die Daten erhalten hat, nur dass der TCP-Prozess sie empfangen hat.

Aus Ihrer NOC-Sicht funktioniert das Netzwerk und die Daten erreichen den Endhost. Vermutlich ist das alles, was Sie interessiert.

Man konnte es so sehen.

Sie sind M.Smith und möchten einen Brief an M.Toto senden (Personen sind die Anwendungsschicht).

Um den Brief zu senden, gehen Sie zu Ihrem lokalen Postamt A, das den Brief an M.Toto lokales Postamt B sendet (Postämter sind die TCP-Schicht).

Alles könnte gut zwischen Ihnen laufen, Post A und Post B - B senden eine ACK an Post A. Aber nichts garantiert, dass der Brief bei M.Toto ankommt. Zwischen Post B und M.Toto kann alles passieren.

Das sagt RFC im Grunde.