Was macht net.ipv4.tcp_app_win?

Question

Ich kann nicht herausfinden, warum die Variablen tcp_adv_win_scale und  tcp_app_winin Linux koexistieren. Die Informationen austcp(7)sagt:

Für tcp_adv_win_scale:

tcp_adv_win_scale(Ganzzahl; Standard: 2; seit Linux 2.4)

Zählen Sie den Puffer-Overhead alsbytes/2^tcp_adv_win_scale, Wenn tcp_adv_win_scalegrößer als 0 ist; oder bytes-bytes/2^(-tcp_adv_win_scale), Wenntcp_adv_win_scaleist kleiner oder gleich Null.

 Der Socket-Empfangspuffer wird von der Anwendung und dem Kernel gemeinsam genutzt. TCP verwaltet einen Teil des Puffers als TCP-Fenster. Dies ist die Größe des Empfangsfensters, das dem anderen Ende mitgeteilt wird. Der restliche Speicherplatz wird als „Anwendungspuffer“ verwendet, um das Netzwerk von Planungs- und Anwendungslatenzen zu isolieren. Dertcp_adv_win_scaleDer Standardwert 2 bedeutet, dass der für den Anwendungspuffer verwendete Speicherplatz ein Viertel des Gesamtspeicherplatzes beträgt.

Und für tcp_app_win:

tcp_app_win(Ganzzahl; Standard: 31; seit Linux 2.4)

Diese Variable definiert, wie viele Bytes des TCP-Fensters für den Puffer-Overhead reserviert sind.

Ein Maximum von (window/2^tcp_app_win, mss) Bytes im Fenster sind für den Anwendungspuffer reserviert. Ein Wert von 0 bedeutet, dass kein Betrag reserviert ist.

Ich bin mir also nicht sicher, was sich tcp_app_wingenau ändert. Mir scheint, dass beide Variablen verwendet werden können, um den TCP-Anwendungspuffer zu optimieren, daher besteht keine Notwendigkeit, sie gemeinsam zu ändern. Habe ich recht?

Answer 1

Ich habe diese Informationen gefunden, die darüber sprechen tcp_adv_win_scale. Die Seite trägt den Titel:TCP-Leistungsoptimierung - So optimieren Sie Linux.

Auszug

Die TCP-Leistung wird durch die Latenz und die Fenstergröße (und den Overhead, der die effektive Fenstergröße reduziert) durch Fenstergröße/RTT (das ist die Datenmenge, die zu einem bestimmten Zeitpunkt über die Verbindung „übertragen“ werden kann) begrenzt.

Um die tatsächlich möglichen Übertragungsgeschwindigkeiten zu erhalten, müssen Sie das resultierende Fenster durch die Latenz (in Sekunden) teilen:

Der Overhead beträgt: window/2^tcp_adv_win_scale (der Standardwert für tcp_adv_win_scale ist 2)

Die Standardparameter für das Empfangsfenster (tcp_rmem) unter Linux lauten also: 87380 – (87380 / 2^2) = 65536.

Bei einer transatlantischen Verbindung (150 ms RTT) beträgt die maximale Leistung: 65536/0,150 = 436906 Bytes/s oder etwa 400 KBytes/s, was heutzutage wirklich langsam ist.

Mit der erhöhten Standardgröße: (873800 - 873800/2^2)/0,150 = 4369000 Bytes/s oder etwa 4 MBytes/s, was für ein modernes Netzwerk angemessen ist. Und beachten Sie, dass dies die Standardeinstellung ist. Wenn der Sender mit einer größeren Fenstergröße konfiguriert ist, lässt er sich problemlos auf das Zehnfache skalieren (8738000*0,75/0,150 = ~40 MBytes/s), was für ein modernes Netzwerk ziemlich gut ist.

2.6.17 und höher haben einigermaßen gute Standardwerte und optimieren die Fenstergröße tatsächlich auf das maximal zulässige Maß, wenn die andere Seite dies unterstützt. Seitdem wird dieser Leitfaden größtenteils nicht mehr benötigt. Für einen guten Durchsatz auf langen Strecken muss der Maximalwert jedoch möglicherweise erhöht werden.

Ich konnte dem folgen, habe aber die Beziehung zwischen diesen beiden Variablen, sofern es eine gibt, nicht ganz verstanden.

Ich habe nur am Rande verstanden, was damit erklärt werden sollte. Im Kern klingt es so, als ob dieser Parameter zum Skalieren der Pufferspeichermenge für TCP und für die Anwendung verwendet werden soll.

Nach etwas mehr Recherche fand ich diese Erklärungen, die mehr Sinn machten. Die Seite war betitelt:Ipsysctl-Tutorial 1.0.4 - Kapitel 3. IPv4-Variablenreferenz.

Auszug

3.3.2. tcp_adv_win_scale

Mit dieser Variable wird dem Kernel mitgeteilt, wie viel des Socket-Pufferspeicherplatzes für die TCP-Fenstergröße verwendet werden soll und wie viel für einen Anwendungspuffer gespeichert werden soll. Wenn tcp_adv_win_scale negativ ist, wird die folgende Gleichung verwendet, um den Puffer-Overhead für die Fensterskalierung zu berechnen:

Dabei ist Bytes die Anzahl der Bytes im Fenster. Wenn der Wert von tcp_adv_win_scale positiv ist, wird die folgende Gleichung verwendet, um den Puffer-Overhead zu berechnen:

Die Variable tcp_adv_win_scale nimmt einen ganzzahligen Wert an und ist standardmäßig auf 2 eingestellt. Dies wiederum bedeutet, dass der Anwendungspuffer 1/4 des gesamten Pufferspeichers beträgt, der in der Variable tcp_rmem angegeben ist.

3.3.3. tcp_app_win

Diese Variable teilt dem Kernel mit, wie viele Bytes für ein bestimmtes TCP-Fenster im Speicherpuffer des TCP-Sockets reserviert werden sollen, in den das bestimmte TCP-Fenster übertragen wird. Dieser Wert wird in einer Berechnung verwendet, die angibt, wie viel Pufferspeicherplatz reserviert werden soll. Diese sieht wie folgt aus:

Wie Sie aus der obigen Berechnung vielleicht verstehen, ist der Pufferspeicherplatz für das jeweilige Fenster umso kleiner, je größer dieser Wert wird. Die einzige Ausnahme von dieser Berechnung ist 0, was dem Kernel mitteilt, keinen Speicherplatz für diese bestimmte Verbindung zu reservieren. Der Standardwert für diese Variable ist 31 und sollte im Allgemeinen ein guter Wert sein. Ändern Sie diesen Wert nicht, es sei denn, Sie wissen, was Sie tun.

Basierend auf diesen Erklärungen klingt es so, als ob der erste Parameter tcp_adv_win_scaledie Aufteilung des Socket-Pufferspeichers steuert, und zwar im Hinblick darauf, wie er für die Verwendung des TCP-Fensters im Vergleich zum Anwendungspuffer aufgeteilt wird.

Der zweite Parameter tcp_app_wingibt die Anzahl der Bytes an, die für den in der Beschreibung genannten Anwendungspuffer reserviert werden sollen tcp_adv_win_scale.

Answer 2

Hier sind meine Erkenntnisse aus Kernelquellen:

• tcp_adv_win_scale wird im Makro verwendettcp_win_from_space in include/net/tcp.hDieses Makro wird verwendet inFunktion tcp_grow_window in net/ipv4/tcp_input.c.
  Scheint, als würde es nur für hergestellte Verbindungen verwendet, nicht beim Verbinden.
  Der Standardwert für diesen Parameter ist 1, was 50 % des Empfangspuffers für die Anwendung ergibt.
• tcp_app_win wird verwendet inFunktion tcp_init_buffer_space in net/ipv4/tcp_input.c.
  Scheint, als würde es nur beim Verbinden und nicht für bestehende Verbindungen verwendet.
  Der Standardwert für diesen Parameter ist 31, was 0,0 % des Empfangspuffers für die Anwendung ergibt.

Ich würde sagen, dass die Logik nicht darin besteht, den Puffer für die Anwendung in neuen Verbindungen zu reservieren und ihn beim Empfangen von Daten zu vergrößern.
Auf diese Weise könnte der anfängliche rwnd theoretisch so groß angekündigt werden, wie der gesamte Puffer ist. Der Sender sendet diese Datenmenge. Der Empfängerpuffer füllt sich, der Empfänger verkleinert den Puffer und vergrößert den Anwendungsanteil des Puffers gemäß tcp_adv_win_scale.
Wie in erwähnt@slmAntwort: Es scheint keinen Grund zu geben, tcp_app_win zu berühren.