Antworten:
Ein grundlegendes TCP-ACK besagt "Ich habe alle Bytes bis zu X erhalten." Bei Auswahl von ACK können Sie sagen, dass ich die Bytes XY und VZ empfangen habe.
Wenn Ihnen zum Beispiel ein Host 10.000 Bytes gesendet hat und 3000-5000 Bytes während der Übertragung verloren gingen, würde ACK sagen: "Ich habe alles auf 3000 gebracht." 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 großartig bei einer Verbindung mit hoher Bandbreite, Verlust (oder hoher Verzögerung). Das Problem ist, dass es unter bestimmten Umständen zu schwerwiegenden Leistungsproblemen kommen kann. Normale TCP-ACKs bewirken, dass der Server eine verlustbehaftete Verbindung mit hoher Bandbreite mit Kid-Handschuhen behandelt (500 Byte senden, warten, 500 Byte senden, warten usw.). SACK kann sich an die hohe Verzögerung anpassen, da es genau weiß, wie viele Pakete tatsächlich verloren gegangen sind.
Hier können schlimme Dinge passieren. Ein Angreifer kann Ihren Server dazu zwingen, eine massive Warteschlange für erneute Übertragungen für eine lange Zeit aufrechtzuerhalten und diese verdammte Sache dann immer und immer wieder zu verarbeiten. Dies kann die CPU belasten, RAM belasten und mehr Bandbreite verbrauchen, als es sollte. Kurz gesagt, ein leichtgewichtiges System kann einen DoS gegen einen bulligeren 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 andere Gruppe von Benutzern mit geringer Latenz bedienen, kauft Ihnen SACK nichts und kann aus Sicherheitsgründen ohne Leistungseinbußen deaktiviert werden.
Wenn Sie sich auf einer Verbindung mit geringer Bandbreite befinden (beispielsweise 1 Mbit / s oder weniger als völlig willkürliche Faustregel), kann SACK im normalen Betrieb Probleme verursachen, indem es Ihre Verbindung überlastet und sollte ausgeschaltet werden.
Letztendlich liegt es an Ihnen. Überlegen Sie, wem Sie von was aus dienen, und wägen Sie das Risiko gegen die Leistungseffekte von SACK ab.
Hier gibt es einen guten Überblick über SACK und seine Verwundbarkeit .
Ein weiterer Grund, warum TCP SACK oft deaktiviert wird, ist, dass es eine erstaunliche Menge an Netzwerkgeräten gibt, die diese Option nicht richtig handhaben. Dies sehen wir ständig bei einem von uns bereitgestellten Hochgeschwindigkeitsprodukt für die Dateiübertragung, das TCP verwendet. Das häufigste Problem sind Gateway-Geräte, die beispielsweise Sequenznummern für TCP-Pakete, die von internen zu externen Netzwerken über das Gerät übertragen werden, zufällig sortieren, die TCP-SACK-Optionen, die möglicherweise von der Remote-Station gesendet werden, jedoch nicht "unzufällig" sortieren Ende. Wenn die tatsächlichen SACK-Werte von diesen Geräten nicht auf die richtigen Werte zurückgesetzt werden, wird die TCP-Sitzung trotz Paketverlust nie beendet, wenn die Gegenstelle versucht, SACK zu verwenden, um die selektiven ACK-Vorteile zu nutzen.
Wahrscheinlich wäre dies weniger problematisch, wenn die Leute aggressiver vorbeugende Softwarewartung auf diese Ausrüstung anwenden würden, aber sie neigen dazu, dies nicht zu tun.
Ich kann aus bitterer Erfahrung bestätigen, dass tcp_sack = 1 eine blockierte Datenübertragung über sftp / rsync / scp usw. mit Dateien über 12 MB bei Verwendung bestimmter Cisco ASA-Firewall-Appliances verursacht.
JEDES MAL würde es ins Stocken geraten.
Wir haben über eine dedizierte 100-Mbit / s-Verbindung zwischen Host A und Host B in zwei verschiedenen Rechenzentren übertragen. Beide verwendeten Cisco-Firewall und Switch-Hardware mit Centos.
Dies kann durch Ändern der Puffergröße etwas gemildert werden - z. B. konnte ich keine 1-GB-Datei per SFTP von Host A auf Host B übertragen, es sei denn, ich habe den SFTP-Puffer auf 2048 eingestellt, aber ich könnte es unabhängig davon tun, ob Host B die Datei von A abruft.
Experimente mit der gleichen Datei unter Verwendung von rsync und Send / Receive Buffer Tuning ermöglichten es mir, ungefähr 70 MB einer 1-GB-Datei aufzurufen, die von A nach B verschoben wurde.
Die ultimative Antwort war jedoch, tcp_sack auf Host A zu deaktivieren. Zuerst habe ich tcp_sack = 0 im Kernel on-the-fly gesetzt - aber letztendlich habe ich es zu meiner /etc/sysctl.conf hinzugefügt