Verwenden Sie TCP_QUICKACK, nicht TCP_NODELAY
Das Einschalten von TCP_NODELAY hat ähnliche Auswirkungen, kann aber den Durchsatz bei kleinen Schreibvorgängen verschlechtern. Wenn Sie mit "write()" eine Schleife schreiben, die nur wenige Bytes (im schlimmsten Fall ein Byte) an einen Socket sendet, und der Naglealgorithmus mit TCP_NODELAY deaktiviert ist, wird jeder Schreibvorgang zu einem IP-Paket. Dadurch wird der Datenverkehr um den Faktor 40 erhöht, mit IP- und TCP-Headern für jede Nutzlast. Die Tinygram-Prävention lässt Sie kein zweites Paket senden, wenn Sie eines im Flug haben, es sei denn, Sie haben genügend Daten, um das Paket mit der maximalen Größe zu füllen. Es sammelt Bytes für eine Roundtrip-Zeit und sendet dann alles in der Warteschlange. Das ist fast immer das, was Sie wollen. Wenn Sie TCP_NODELAY festgelegt haben, müssen Sie sich der Probleme beim Puffern und Leeren viel mehr bewusst sein. Nichts davon spielt für Bulk-One-Way-Übertragungen eine Rolle, bei denen es sich heute meist um HTTP handelt. (Ich habe mir nie die Auswirkungen auf den SSL-Handshake angesehen, wo es wichtig sein könnte.) Kurzversion:setze TCP_QUICKACK. Wenn Sie einen Fall finden, in dem die Sache dadurch noch schlimmer wird, lassen Sie es mich wissen. John Nagle
https://news.ycombinator.com/item?id=10608356
Es gibt keine direkte Beziehung zwischen diesen beiden Optionen, sie dienen nur unterschiedlichen Zwecken.
TCP_NODELAY dient zum Deaktivieren/Aktivieren der Segmentpufferung, damit Daten so schnell wie möglich an Peer gesendet werden können. Daher wird dies normalerweise zur Verbesserung der Netzwerkauslastung verwendet. TCP_QUICKACK wird verwendet, um Bestätigungen so früh wie möglich zu senden, anstatt sie bei einem Austausch auf Protokollebene zu verzögern, und es ist nicht stabil/permanent, nachfolgende TCP-Transaktionen (die unter der Haube stattfinden können) können diese Option je nach tatsächlicher Verarbeitung auf Protokollebene oder tatsächlichen Meinungsverschiedenheiten ignorieren zwischen Benutzereinstellung und Stapelverhalten.
HINWEIS TCP_NODELAY
ist tragbar während TCP_QUICKACK
nicht (funktioniert nur unter Linux 2.4.4+).
TCP_QUICKACK
und TCP_NODELAY
beeinflussen verschiedene Operationen in TCP. Die tcp(7)
Manpage beschreibt, welche Socket-Optionen für TCP sich gegenseitig stören, z.B. TCP_CORK
und TCP_NODELAY
.
Kurze Antwort
- Um den Pufferalgorithmus von Nagle zu deaktivieren, verwenden Sie die Socket-Option TCP_NODELAY.
- Um verzögerte Bestätigungen zu deaktivieren, verwenden Sie die TCP_QUICKACK-Socket-Option.
Einzelheiten
-
Nagle-Algorithmus
- Nagles Algorithmus, benannt nach seinem Schöpfer John Nagle, ist ein Mechanismus zur Verbesserung der TCP-Effizienz, indem er die Anzahl kleiner Pakete reduziert, die über das Netzwerk gesendet werden.
- Das Ziel war, zu verhindern, dass ein Knoten viele kleine Pakete überträgt, wenn die Anwendung Daten ziemlich langsam an den Socket liefert.
- Wenn ein Prozess die Übertragung vieler kleiner Pakete verursacht, kann dies zu einer übermäßigen Netzwerküberlastung führen. Dies gilt insbesondere dann, wenn die Nutzdaten eines Pakets kleiner sind als die TCP-Header-Daten.
-
Verzögerte Bestätigung
- TCP Delayed Acknowledgement oder Delayed ACK ist eine weitere Technik, die von einigen Implementierungen des TCP verwendet wird, um die Netzwerkleistung zu verbessern und Staus zu reduzieren.
- Delayed ACK wurde erfunden, um die Anzahl der ACKs zu reduzieren, die zum Bestätigen der Segmente erforderlich sind, und den Protokoll-Overhead zu reduzieren.
- Delayed ACK bedeutet, dass TCP nicht sofort jedes einzelne empfangene TCP-Segment bestätigt. Mehrere ACK-Antworten können zu einer einzigen Antwort kombiniert werden, wodurch der Protokoll-Overhead reduziert wird.
-
Der Algorithmus von Nagle und die verzögerte Bestätigung passen in einem TCP/IP-Netzwerk nicht gut zusammen
- Verzögertes ACK versucht, wenn möglich, mehr Daten pro Segment zu senden. Aber ein Teil von Nagles Algorithmus hängt von einem ACK ab, um Daten zu senden.
- Nagles Algorithmus und verzögerte ACKs erzeugen zusammen ein Problem, da verzögerte ACKs darauf warten, die ACK zu senden, während Nagles Algorithmus darauf wartet, die ACK zu empfangen
-
Wie kann ich die Probleme lösen, die durch Nagles Algorithmus und verzögerte ACKs verursacht werden
- Aktivieren Sie TCP_NODELAY, um Nagles Algorithmus über globale Socket-Optionen auf den Servern zu deaktivieren
- Profilanpassungen an Proxyservern und Load Balancern vornehmen:Dies ist besonders relevant, wenn Sie Anwendungen oder Umgebungen ausführen, die nur manchmal hochgradig interaktiven Datenverkehr und gesprächige Protokolle aufweisen. Indem Sie den Algorithmus von Nagle und TCP_NODELAY dynamisch auf Load-Balancer-Ebene ein- und ausschalten, können Sie selbst sehr heterogene Verkehrsmischungen optimal am Laufen halten.
- Reduzieren Sie den Zeitgeber für verzögerte Bestätigungen auf Ihren Servern und Load Balancern. Manchmal wird diese Art der Optimierung in Software auf Anwendungsebene gehandhabt, aber wenn dies nicht der Fall ist, können Sie den ACK-Timer möglicherweise immer noch dynamisch auf Server- oder Load-Balancer-Ebene verwalten.
- Während Sie diese Änderungen vornehmen, sollten Sie Ihren Netzwerkdatenverkehr genau im Auge behalten und sehen, wie sich jede Optimierung auf die Überlastung auswirkt.
Weitere Einzelheiten finden Sie hier