![Echte Vorteile von TCP TIME-WAIT und Auswirkungen in der Produktionsumgebung](https://rvso.com/image/568262/Echte%20Vorteile%20von%20TCP%20TIME-WAIT%20und%20Auswirkungen%20in%20der%20Produktionsumgebung.png)
EINIGE THEORIE
Ich habe einiges über TCP gelesen TIME-WAIT
(HierUndDort) und ich habe gelesen, dass es sich um einen Wert handelt, der auf 2 x MSL
(maximale Segmentlebensdauer) eingestellt ist, wodurch eine Verbindung für eine Weile in der "Verbindungstabelle" gehalten wird, um zu garantieren, dass„Bevor Sie eine Verbindung mit demselben Tupel herstellen dürfen, sind alle Pakete, die zu früheren Inkarnationen dieses Tupels gehören, tot.“.
Da empfangene Segmente (mit Ausnahme von SYN unter bestimmten Umständen), während eine Verbindung entweder besteht TIME-WAIT
oder nicht mehr besteht, verworfen würden, warum sollte man die Verbindung nicht sofort schließen?
F1: Liegt es daran, dass der Verarbeitungsaufwand für die Bearbeitung von Segmenten aus alten Verbindungen geringer ist und weniger Verarbeitungsaufwand entsteht, um im selben Tupel eine neue Verbindung herzustellen TIME-WAIT
(gibt es also Leistungsvorteile)?
Wenn die obige Erklärung nicht zutrifft, TIME-WAIT
ist der einzige Grund, warum ich es für sinnvoll halte, dass ein Client ein SYN
für eine Verbindung sendet, bevor er verbleibende Segmente für eine alte Verbindung im selben Tupel sendet. In diesem Fall würde der Empfänger die Verbindung erneut öffnen, dann aber fehlerhafte Segmente erhalten und sie beenden müssen.
F2: Ist diese Analyse richtig?
F3: Gibt es noch weitere Vorteile bei der Verwendung von TIME-WAIT?
ETWAS ÜBUNG
Ich habe mir die Munin-Diagramme auf einem Produktionsserver angesehen, den ich verwalte. Hier ist eines:
Wie Sie sehen, gibt es in mehr Verbindungen TIME-WAIT
als ESTABLISHED
, meistens etwa doppelt so viele, in einigen Fällen sogar viermal so viele.
F4: Hat dies Auswirkungen auf die Leistung?
F5: Wenn ja, ist es sinnvoll/empfehlenswert, den TIME-WAIT
Wert zu reduzieren (und wenn ja, was)?
F6: Ist dieses Verhältnis von TIME-WAIT
/ ESTABLISHED
Verbindungen normal? Könnte dies mit böswilligen Verbindungsversuchen zusammenhängen?
Antwort1
Kurz gesagt, machen Sie sich keine Sorgen TIME_WAIT
. Der Mehraufwand ist nahezu gleich Null und verursacht normalerweise keine Probleme.
Auf einem ausgelasteten Server kann es zu einer Erschöpfung der Ports kommen. In diesem Fall gibt es die Sysctl-Option , die es dem Kernel ermöglicht, alte Ports, die noch vorhanden sind , nach Bedarf net.ipv4.tcp_tw_reuse = 1
wiederzuverwenden .TIME_WAIT
TIME_WAIT ist Teil der TCP-Spezifikation und dient dazu, Pakete abzufangen, die möglicherweise noch unterwegs sind (denken Sie daran, dass nicht alle Verbindungen zuverlässig sind, und genau das wollte TCP lösen). Der Timeout-Wert kann für die meisten modernen Anwendungen sehr hoch sein, beeinträchtigt aber normalerweise nichts außer der Ausgabe von netstat.
Wenn Sie selbst die Kontrolle über den Socket haben und sicher sind, dass Sie nicht auf Daten warten (z. B. weil Sie der endgültige Absender sind oder eine Antwort für Sie nicht von Belang ist), können Sie den Socket nach dem Setzen der SO_NOLINGER
Option schließen. Dadurch wird die Verbindung mit einem beendet RST
und der Socket sofort verworfen.
Also Ihre Fragen:
Q1, Q2, Q3: Es dient dazu, verspätete Pakete zu sammeln, „nur für den Fall“, da Links unzuverlässig sein können. Es ist Teil der Spezifikation, es verhindert Paketverlust und eine Anpassung hat keinen wirklichen Nutzen.
F4: Nein
F5: Machen Sie sich darüber keine Sorgen. Sie haben die Möglichkeit, die Wiederverwendung dieser Sockel bei Bedarf zu erzwingen.
F5: TIME_WAIT
und ESTABLISHED
stehen in keinem Zusammenhang, außer dass dieses Verhältnis umso größer ist, je mehr kurzlebige Verbindungen Sie haben. Es könnte durch etwas Bösartiges verursacht werden, ist aber ebenso wenig ein Indikator wie „übermäßige Netzwerkaktivität“.
Antwort2
Einige Antworten aus meiner begrenzten Erfahrung mit TIME_WAIT:
1/2/3) Siehe diesSO-FrageUnddiese Seitefür eine gute Erklärung von TIME_WAIT. Es ist weniger ein Leistungsproblem als vielmehr eine Frage der Dienstqualität, um sicherzustellen, dass alle TCP-Pakete in einer Verbindung ordnungsgemäß empfangen werden.
4/5) Ein Leistungsproblem im Zusammenhang mit TIME_WAIT besteht darin, dass Ihnen auf einem sehr ausgelasteten Server möglicherweise irgendwann die verfügbaren Verbindungen ausgehen, wenn sich zu viele im TIME_WAIT-Status befinden. Wenn Sie auf dieses Problem stoßen, können Sie versuchen, den TIME_WAIT-Wert zu verringern, aber dies fällt möglicherweise in die Kategorie „Ich weiß, was ich tue“. Siehediese SO-Fragefür ein paar weitere Einzelheiten.
6) Der Standardwert von TIME_WAIT „sollte“ bei etwa 240 s liegen (oder das Doppelte der Paket-MSL von 120 s). Das Verhältnis von hergestellten/wartenden Verbindungen hängt also von Ihrer eingehenden Verbindungsrate und davon ab, wie lange sie offen bleiben. Ich habe beispielsweise einige meiner stark ausgelasteten Server überprüft und das Verhältnis lag zwischen 1,3 und 400, was ich alles als normal betrachten würde, basierend auf dem Server und dem Datenverkehr, den er empfängt.