Unter Berücksichtigung derBeschreibung von TCP_USER_TIMEOUT:
Wenn der Wert größer als 0 ist, gibt er die maximale Zeit in Millisekunden an, die übertragene Daten unbestätigt bleiben dürfen, bevor TCP die entsprechende Verbindung zwangsweise schließt und ETIMEDOUT an die Anwendung zurückgibt.
Unddieser Kommentar aus dem RFC:
Sehr kurze USER TIMEOUT-Werte können TCP-Übertragungen über Pfade mit hoher Verzögerung beeinträchtigen. Wenn das Benutzer-Timeout eintritt, bevor eine Bestätigung für ein ausstehendes Segment eintrifft (möglicherweise aufgrund von Paketverlust), wird die Verbindung geschlossen. Bei vielen TCP-Implementierungen liegen die USER TIMEOUT-Werte standardmäßig bei einigen Minuten. Obwohl die UTO-Option die Angabe kurzer Timeouts zulässt, sollten Anwendungen, die diese ankündigen, diese Auswirkungen berücksichtigen.
Ich würde erwarten, dass ein TCP_USER_TIMEOUT von 2 ms katastrophale Folgen hat: In einem Netzwerk, in dem die RTT weniger als 2 ms beträgt, würde jedes gesendete TCP-Paket beim Warten auf eine ACK-Nachricht eine Zeitüberschreitung erleiden und die Verbindung würde geschlossen werden. In meiner Umgebung erlebe ich dies jedoch nicht. Verbindungen können hergestellt werden und Daten werden einwandfrei gesendet und empfangen. Ich stelle jedoch fest, dass, wenn ich das Kabel ziehe oder die Empfangsschnittstelle herunterfahre, das TCP_USER_TIMEOUT einen Verbindungsverlust tatsächlich erkennt und die Verbindung rechtzeitig geschlossen wird. TCP_USER_TIMEOUT funktioniert also, nur nicht so, wie ich es erwarten würde.
Was verstehe ich falsch an TCP_USER_TIMEOUT? Warum führen Werte unter RTT nicht dazu, dass die Verbindung unterbrochen wird?
Falls es hilfreich ist, mein Client ist eine Scientific Linux 6.1-Box mit dem Kernel 2.6.32.
Antwort1
Die UTO-Implementierung in Linux war ungenau und wurde kürzlich durch dieses Patchset behoben: (Nur für den Fall, dass Sie nicht der Autor dieses Patchsets sind): https://lkml.org/lkml/2018/7/18/1090
Aber auch nachdem UTO ausgelöst wurde, stoppt der Host die erneute Übertragung und wechselt in den Zustand TCP_CLOSE, setzt die Verbindung aber nicht zurück. Es liegt in der Verantwortung der Anwendung, den RST zu senden.