2009-11-26 10 views
51

Nehmen wir an, es gibt einen Client, der viele kurzlebige Verbindungen zu einem Server herstellt.Was kostet TIME_WAIT auf der Serverseite?

Wenn der Client die Verbindung schließt, befinden sich auf der Clientseite viele Ports im TIME_WAIT-Status. Da der Client keine lokalen Ports mehr hat, ist es unmöglich, schnell einen neuen Verbindungsversuch zu starten. Wenn der Server die Verbindung schließt, werden auf der Serverseite viele TIME_WAIT s angezeigt. Schadet das jedoch? Der Client (oder andere Clients) können weiterhin versuchen, Verbindungen herzustellen, da die lokalen Ports nie ausreichen und die Anzahl der TIME_WAIT-Status auf der Serverseite steigt. Was passiert schließlich? Ist etwas Schlimmes passiert? (Verlangsamung, Absturz, unterbrochene Verbindungen usw.)

Bitte beachten Sie, dass meine Frage nicht lautet: "Was ist der Zweck von TIME_WAIT?" aber "Was passiert, wenn es so viele TIME_WAIT Zustände auf dem Server gibt?" Ich weiß bereits, was passiert, wenn eine Verbindung in TCP/IP geschlossen wird und warum der Status TIME_WAIT erforderlich ist. Ich versuche nicht, es zu bemängeln, sondern möchte nur wissen, was das potenzielle Problem ist.

Um es einfach zu sagen, sagen wir netstat -nat | grep :8080 | grep TIME_WAIT | wc -l Drucke 100000. Was würde passieren? Verlangsamt sich der O/S-Netzwerkstack? "Zu viele offene Dateien" Fehler? Oder einfach nichts, worüber man sich Sorgen machen müsste?

+0

Einige Systeme sehen Probleme auf "32K' TIME_WAIT' "http://serverfault.com/a/212127/87017 – Pacerier

+1

Für Linux gibt es eine [Papier] (https://tools.ietf.org/html/draft- Faber-Time-Wait-Avoidance-00) basierend auf Daten über Webstone Benchmark. Außerdem "[* Der' TIME-WAIT'-Status in TCP und seine Auswirkung auf ausgelastete Server *] (https://scholar.google.com/scholar?cluster=2607037814764769062&hl=de&as_sdt=0,5&sciodt=0,5) ". – Pacerier

Antwort

48

Jeder Sockel in TIME_WAIT verbraucht etwas Speicher im Kernel, in der Regel etwas weniger als ein ESTABLISHED Sockel noch immer signifikant. Eine ausreichend große Anzahl könnte den Kernspeicher erschöpfen oder zumindest die Leistung verschlechtern, da dieser Speicher für andere Zwecke verwendet werden könnte.TIME_WAIT Sockets enthalten keine offenen Dateideskriptoren (vorausgesetzt, sie wurden ordnungsgemäß geschlossen), so dass Sie sich keine Gedanken über einen Fehler "zu viele offene Dateien" machen müssen.

Der Socket bindet auch diese spezielle src/dst IP-Adresse und Port, so dass es nicht für die Dauer des Intervalls wiederverwendet werden kann. (Dies ist der beabsichtigte Zweck des TIME_WAIT-Status.) Das Binden des Ports ist normalerweise kein Problem, es sei denn, Sie müssen eine Verbindung mit demselben Portpaar wiederherstellen. Meistens wird eine Seite einen ephemeren Port verwenden, wobei nur eine Seite an einem bekannten Port verankert ist. Eine sehr große Anzahl von TIME_WAIT Sockets kann jedoch den ephemeren Port-Speicherplatz ausschöpfen, wenn Sie wiederholt und häufig zwischen den gleichen zwei IP-Adressen verbinden. Beachten Sie, dass dies nur dieses bestimmte IP-Adresspaar betrifft und keinen Einfluss auf die Herstellung von Verbindungen mit anderen Hosts hat.

+0

Sind Sie sicher, dass dies auch für Windows Server und andere Betriebssysteme relevant ist? – Pacerier

-1

Es sieht so aus, als ob der Server die Ports für ankommende Verbindungen (für die Dauer der bestehenden TIMED_WAITs) nur für eingehende DOS-Attacken freigibt.

+7

Warum hat der Server keine Ports mehr? Der Server weist keinen lokalen Port für eine akzeptierte Verbindung zu. Das ist der Grund, warum ein Server 100k-gleichzeitige Verbindungen bewältigen kann, wodurch das ausgelastete CPU-Problem beseitigt wird. – trustin

+4

Die Do weist einen lokalen Port für akzeptierte Verbindungen zu, führen Sie einen 'netstat -a' von einer Eingabeaufforderung aus und Sie werden diese sehen. Ich glaube, der Grund für TIME_WAIT ist, dass TCP-Pakete in der falschen Reihenfolge ankommen können, so dass der Port nicht sofort geschlossen werden muss, damit späte Pakete ankommen können. Dies bedeutet, dass es tatsächlich möglich ist, dass die Ports ausgehen. Es gibt Möglichkeiten, die TIME_WAIT-Periode zu verkürzen, aber das Risiko besteht darin, dass bei kürzeren Timeouts spät eintreffende Pakete von einer vorherigen Verbindung mit Paketen von der neuen Verbindung auf dem recycelten Port verwechselt werden können. –

+3

Wenn Sie 'netstat -nat' ausführen, sehen Sie, dass die vom selben Server-Socket akzeptierten Verbindungen denselben lokalen Port haben. Daher denke ich, dass keine zusätzlichen lokalen Ports für akzeptierte Verbindungen zugewiesen sind. – trustin

12

bisherigen Ergebnisse:

Auch wenn der Server die Buchse mit Systemaufruf, dessen Dateideskriptors freigegeben wird nicht geschlossen, wenn er den TIME_WAIT Zustand eintritt. Der Dateideskriptor wird später veröffentlicht, wenn der TIME_WAIT-Zustand verloren ist (d. H. Nach 2 * MSL Sekunden). Daher führen zu viele TIME_WAITs möglicherweise zu einem Fehler "zu viele offene Dateien" im Serverprozess.

Ich glaube, O/S TCP/IP-Stack wurde mit geeigneten Datenstruktur (z. B. Hash-Tabelle) implementiert, so dass die Gesamtzahl der TIME_WAITs sollte nicht die Leistung des O/S TCP/IP-Stack beeinflussen. Nur der Prozess (Server), dem die Sockets im TIME_WAIT-Zustand gehören, wird leiden.

+0

Nicht sicher, dass das stimmt. Ich habe Hunderte von TIME_WAIT produziert, aber sah nicht die Anzahl der geöffneten Dateideskriptor erhöht in sysctl fs.file-nr. – c4il

+0

@ c4il, @trustin, Warum diskutieren alle dies ohne Angabe von ... ** welches OS **?Spezifische Versionen wären auch hilfreich. – Pacerier

+0

@trustin: Was war der Grund für viele offene Dateideskriptoren? Hast du es gefunden? – Albin

9

Jede Verbindung wird durch ein Tupel (Server-IP, Server-Port, Client-IP, Client-Port) identifiziert. Entscheidend ist, dass die TIME_WAIT-Verbindungen (ob auf der Serverseite oder auf der Clientseite) jeweils eines dieser Tupel belegen.

Mit der TIME_WAIT s auf der Client-Seite ist es einfach zu sehen, warum Sie keine weiteren Verbindungen herstellen können - Sie haben keine lokalen Ports mehr. Das gleiche Problem tritt jedoch auf der Serverseite auf - sobald es 64k Verbindungen in TIME_WAIT Zustand für einen einzelnen Client hat, kann es keine weiteren Verbindungen von diesem Client akzeptieren, weil es keine Möglichkeit hat, den Unterschied zwischen zu unterscheiden die alte Verbindung und die neue Verbindung - beide Verbindungen werden durch das gleiche Tupel identifiziert. Der Server sollte in diesem Fall nur RST an neue Verbindungsversuche von diesem Client zurücksenden.

2

Wenn Sie viele Verbindungen von vielen verschiedenen Client-IPs zu den Server-IPs haben, können Einschränkungen der Verbindungsverfolgungstabelle auftreten.

Check:

sysctl net.ipv4.netfilter.ip_conntrack_count 
sysctl net.ipv4.netfilter.ip_conntrack_max 

über alle src IP/Port und Ziel-IP/Port-Tupel können Sie nur net.ipv4.netfilter.ip_conntrack_max haben in der Verfolgungstabelle. Wenn dieses Limit erreicht wird, sehen Sie eine Nachricht in Ihren Protokollen "nf_conntrack: table full, drop packet". Der Server akzeptiert keine neuen eingehenden Verbindungen, bis wieder Speicherplatz in der Verfolgungstabelle vorhanden ist.

Diese Einschränkung könnte Sie treffen, lange bevor die ephemeren Ports aufgebraucht sind.