Was bedeutet es für TCP-Verbindungen zu Abwanderung?

Question

Im Zusammenhang mit Webservices habe ich den Begriff "TCP Connection Churn" verwendet. Speziell Twitter finagle hat Möglichkeiten, dies zu vermeiden. Wie ist es passiert? Was heißt das?

Answer 1

Es gibt möglicherweise mehrere Verwendungen für diesen Begriff, aber ich habe es immer in Fällen verwendet, in denen viele TCP-Verbindungen in sehr kurzer Zeit hergestellt werden, was zu Leistungsproblemen auf dem Client und möglicherweise auch auf dem Server führt .

Dies tritt häufig auf, wenn Client-Code geschrieben wird, der sich bei einem TCP-Fehler jeglicher Art automatisch verbindet. Wenn es sich bei diesem Fehler um einen Verbindungsfehler handelt, bevor die Verbindung überhaupt hergestellt wurde (oder sehr früh beim Protokollaustausch), kann der Client in eine Fast-Beschäftigt-Schleife wechseln, die ständig Verbindungen herstellt. Dies kann zu Leistungsproblemen auf der Client-Seite führen - erstens, dass ein Prozess in einer sehr ausgelasteten Schleife CPU-Zyklen aufsaugt und zweitens jeder Verbindungsversuch eine clientseitige Port-Nummer verbraucht - wenn dies schnell genug geht, kann die Software umhergehen wenn sie die maximale Portnummer erreichen (da ein Port nur eine 16-Bit-Nummer ist, ist dies sicherlich nicht unmöglich).

Während das Schreiben von robustem Code ein wertvolles Ziel ist, ist dieser einfache "automatische Wiederholungsversuch" etwas zu naiv. Sie können ähnliche Probleme in anderen Zusammenhängen sehen - z. Ein Elternprozess startet einen Kindprozess, der sofort abstürzt, ständig neu. Ein gemeinsamer Mechanismus, um dies zu vermeiden, ist eine Art von Back-Off. Wenn die erste Verbindung fehlschlägt, verbinden Sie sich sofort erneut. Wenn es innerhalb kurzer Zeit wieder fehlschlägt (z. B. 30 Sekunden), warten Sie beispielsweise 2 Sekunden vor dem erneuten Verbinden. Wenn es innerhalb von 30 Sekunden erneut fehlschlägt, warten Sie 4 Sekunden und so weiter. Lesen Sie the Wikipedia article on exponential backoff (oder this blog post könnte für diese Anwendung besser geeignet sein) für mehr Hintergrund zu dieser Technik.

Dieser Ansatz hat den Vorteil, dass er den Client oder Server nicht überlastet, aber auch, dass der Client ohne manuellen Eingriff wiederhergestellt werden kann (was insbesondere für Software auf einem unbeaufsichtigten Server oder im großen Fall entscheidend ist) Cluster).

In Fällen, in denen die Wiederherstellungszeit kritisch ist, ist auch eine einfache Ratenbegrenzung der TCP-Verbindungserstellung möglich - vielleicht nicht mehr als 1 pro Sekunde oder so. Wenn es viele Clients pro Server gibt, kann dieser einfachere Ansatz jedoch immer noch den Server überschwemmen lassen, indem er eine hohe Verbindungsrate akzeptiert und dann schließt.

Eine Sache zu beachten, wenn Sie Exponential Backoff verwenden möchten - ich empfehle eine maximale Wartezeit auferlegen, oder Sie können feststellen, dass längere Fehler einen Client zu lange dauern, sobald das Server-Ende wieder Verbindungen akzeptiert. Ich würde unter den meisten Umständen etwas wie 5 Minuten als ein vernünftiges Maximum vorschlagen, aber natürlich hängt es von der Anwendung ab.