Frage Wann TCP SACK ausschalten?


Ich habe Linux-Tuning-Parameter betrachtet und einige Konfigurationen gesehen, in denen SACK ausgeschaltet ist. Kann das jemand erklären?

Dies würde für einen beschäftigten Webserver tunen.


23
2018-05-21 19:34


Ursprung




Antworten:


Eine grundlegende TCP ACK sagt "Ich habe alle Bytes bis zu X erhalten." Selektive ACK ermöglicht Ihnen zu sagen "Ich empfing Bytes X-Y und V-Z."

Wenn also zum Beispiel ein Host Ihnen 10.000 Bytes geschickt hat und die Bytes 3000-5000 beim Transport verloren gegangen sind, würde ACK sagen: "Ich habe alles bis zu 3000 bekommen." Das andere Ende müsste die Bytes 3001-10000 erneut senden. SACK könnte sagen "Ich habe 1000-2999 und 5001-10000" und der Host würde einfach die 3000-5000 senden.

Dies ist bei einer Verbindung mit hoher Bandbreite und Verlust (oder hoher Verzögerung) von Vorteil. Das Problem ist, dass unter bestimmten Umständen schwerwiegende Leistungsprobleme auftreten können. Normale TCP-ACKs bewirken, dass der Server eine verlustreiche Verbindung mit Kid-Handschuhen mit hoher Bandbreite behandelt (500 Bytes senden, warten, 500 Bytes senden, warten usw.). SACK lässt sich an die hohe Verzögerung anpassen, weil es genau weiß, wie viele Pakete es gibt tatsächlich hat verloren.

Hier können schlechte Dinge passieren. Ein Angreifer kann Ihren Server zwingen, eine lange Warteschlange für die erneute Übertragung zu behalten, und dann das ganze verdammte Ding wieder und wieder und wieder und wieder verarbeiten. Dies kann die CPU beeinträchtigen, RAM aufbrauchen und mehr Bandbreite verbrauchen, als es sollte. Kurz gesagt, ein leichtgewichtiges System kann ein DoS gegen einen robusteren Server initiieren.

Wenn Ihr Server robust ist und keine großen Dateien bereitstellt, sind Sie dagegen ziemlich gut isoliert.

Wenn Sie hauptsächlich ein Intranet oder eine Gruppe anderer Benutzer mit niedriger Latenz bedienen, kauft SACK nichts und kann aus Sicherheitsgründen ohne Leistungsverlust ausgeschaltet werden.

Wenn Sie eine Verbindung mit geringer Bandbreite haben (sagen wir 1 Mbps oder weniger als völlig willkürliche Faustregel), kann SACK im normalen Betrieb Probleme verursachen, indem er Ihre Verbindung sättigt und ausgeschaltet werden sollte.

Letztendlich liegt es an dir. Überlegen Sie, was Sie bedienen, an wen und von wem und wie hoch ist Ihr Risiko gegenüber den Leistungseffekten von SACK.

Es gibt einen großartigen Überblick über SACK und seine Sicherheitslücke Hier.


28
2018-05-21 21:11



FTR: seit Linux 4.18 gibt es SACK-Komprimierung aktiviert. Es könnte z.B. Verbessern Sie die Leistung in drahtlosen Netzwerken. Auch etwas relevant: Original-Kommentar des Entwicklers. - Hi-Angel


Ein weiterer Grund dafür, dass TCP SACK oft deaktiviert ist, ist, dass es dort eine erstaunliche Menge an Netzwerkgeräten gibt, die diese Option nicht korrekt verarbeiten können. Wir sehen dies die ganze Zeit mit einem High-Speed-File-Transfer-Produkt, das wir verwenden, die TCP verwendet. Das häufigste Problem ist das von Gateway-Geräten, die z. B. Randomize-Sequenznummern für TCP-Pakete durch das Gerät von internen Netzwerken zu externen Geräten ausführen, aber die TCP SACK-Optionen, die von der Gegenstelle gesendet werden, nicht "zufällig" machen Ende. Wenn die tatsächlichen SACK-Werte von diesen Geräten nicht auf die richtigen Werte zurückübersetzt werden, dann wird die TCP-Sitzung niemals angesichts eines Paketverlusts abgeschlossen, wenn das entfernte Ende versucht, SACK zu verwenden, um die selektiven ACK-Vorteile zu erhalten.

Wahrscheinlich wäre dies weniger ein Problem, wenn die Leute die Software-Vorbeugungs-Software aggressiver anwenden würden, aber das tun sie nicht.


10
2017-12-29 23:25



Siehe diesen RedHat KB Artikel: Warum hängen TCP-Verbindungen von einem Client-System hinter einem ADSL-Router zeitweise unter Red Hat Enterprise Linux? kbase.redhat.com/faq/docs/DOC-26683 - davey


Ich kann aus bitterer Erfahrung bestätigen, dass tcp_sack = 1 den Datentransfer über sftp / rsync / scp usw. mit Dateien verursacht, die bei Verwendung bestimmter Cisco ASA Firewall-Appliances über 12 MB hinausgehen.

JEDES Mal würde es zum Stillstand kommen.

Wir übertrugen über eine dedizierte 100mbps-Verbindung zwischen Host A und Host B in zwei verschiedenen Rechenzentren, die beide eine Cisco-Firewall und Switch-Hardware mit Centos verwenden.

Dies kann etwas gemildert werden, indem Puffergrößen modifiziert werden - z. Ich konnte nicht 1GB Datei über sftp von Host A zu Host B übertragen, es sei denn, ich legte den sftp-Puffer auf 2048, aber ich könnte unabhängig davon, ob Host B die Datei von A zog.

Experimente mit der gleichen Datei unter Verwendung von rsync und Sende / Empfangspuffer-Tuning erlaubten es mir, ungefähr 70 MB einer 1 GB-Datei, die von A nach B geschoben wurde, aufzustehen.

Die ultimative Antwort war jedoch, tcp_sack auf Host A zu deaktivieren. Anfangs, indem ich tcp_sack = 0 im Kernel on-the-fly gesetzt habe - aber letztendlich - habe ich es zu meiner /etc/sysctl.conf hinzugefügt


6
2017-09-26 23:13



fwiw, Cisco ASA Firewall hier auch. Die unidirektionale Natur des Problems war beunruhigend, wir haben das seit Monaten verfolgt. scp arbeitete mehr oder weniger "mit Geschwindigkeit" in einer Richtung, aber regelmäßig gestoppt und Zeitmessung in die andere Richtung. Deaktivieren Sie tcp_sack war ein Heilmittel.