it-swarm.com.de

Windows TCP Fensterskalierung Das Plateau zu früh erreicht

Szenario: Wir haben eine Reihe von Windows-Clients, die regelmäßig große Dateien (FTP/SVN/HTTP PUT/SCP) auf Linux-Server hochladen, die ca. 100-160 ms entfernt sind. Wir haben eine synchrone Bandbreite von 1 Gbit/s im Büro und die Server sind entweder AWS-Instanzen oder werden physisch in US-DCs gehostet.

Der erste Bericht war, dass Uploads auf eine neue Serverinstanz viel langsamer waren als sie sein könnten. Dies hat sich beim Testen und an mehreren Standorten bewährt. Clients sahen von ihren Windows-Systemen aus stabile 2-5 Mbit/s für den Host.

Ich habe iperf -s Auf einer AWS-Instanz und dann von einem Windows - Client im Büro ausgebrochen:

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

Die letztere Zahl kann bei nachfolgenden Tests erheblich variieren (Vagaries of AWS), liegt jedoch normalerweise zwischen 70 und 130 Mbit/s, was für unsere Anforderungen mehr als ausreichend ist. Beim Shesharking der Sitzung kann ich sehen:

  • iperf -c Windows SYN - Fenster 64 KB, Maßstab 1 - Linux SYN, ACK: Fenster 14 KB, Maßstab 9 (* 512) iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN - Windows 64 KB, Maßstab 1 - Linux SYN, ACK: Fenster 14 KB, Maßstab: 9 iperf window scaling with default 1MB Window

Natürlich kann die Verbindung diesen hohen Durchsatz aufrechterhalten, aber ich muss die Fenstergröße explizit einstellen, um sie nutzen zu können, was die meisten realen Anwendungen nicht zulassen. Die TCP Handshakes verwenden jeweils die gleichen Startpunkte, aber der erzwungene skaliert

Umgekehrt gibt mir von einem Linux-Client im selben Netzwerk ein Straight iperf -c (Unter Verwendung des Systemstandards 85 KB):

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

Ohne Zwang skaliert es wie erwartet. Dies kann nicht in den dazwischenliegenden Hops oder unseren lokalen Switches/Routern liegen und scheint Windows 7- und 8-Clients gleichermaßen zu betreffen. Ich habe viele Anleitungen zur automatischen Optimierung gelesen, aber hier geht es normalerweise darum, die Skalierung insgesamt zu deaktivieren, um das schlechte, schreckliche Heimnetzwerk-Kit zu umgehen.

Kann mir jemand sagen, was hier passiert und mir eine Möglichkeit geben, das Problem zu beheben? (Am besten etwas, das ich über das Gruppenrichtlinienobjekt in die Registrierung einfügen kann.)

Anmerkungen

Auf die betreffende AWS Linux-Instanz werden die folgenden Kerneleinstellungen in sysctl.conf Angewendet:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

Ich habe die Umleitung von dd if=/dev/zero | nc Auf /dev/null Am Serverende verwendet, um iperf auszuschließen und andere mögliche Engpässe zu beseitigen, aber die Ergebnisse sind ähnlich. Tests mit ncftp (Cygwin, Native Windows, Linux) lassen sich ähnlich skalieren wie die oben genannten iperf-Tests auf den jeweiligen Plattformen.

Bearbeiten

Ich habe hier eine andere konsistente Sache entdeckt, die relevant sein könnte: enter image description here

Dies ist die erste Sekunde der vergrößerten 1-MB-Aufnahme. Sie können Slow Start in Aktion sehen, wenn das Fenster vergrößert wird und der Puffer größer wird. Es gibt dann dieses winzige Plateau von ~ 0,2s genau an dem Punkt, an dem der Standard-Fenster-Iperf-Test für immer abflacht. Dieser skaliert natürlich auf viel schwindelerregendere Höhen, aber es ist merkwürdig, dass es diese Pause in der Skalierung gibt (Werte sind 1022 Bytes * 512 = 523264), bevor dies geschieht.

Update - 30. Juni.

Weiterverfolgung der verschiedenen Antworten:

  • CTCP aktivieren - Dies macht keinen Unterschied. Die Fensterskalierung ist identisch. (Wenn ich das richtig verstehe, erhöht diese Einstellung die Geschwindigkeit, mit der das Überlastungsfenster vergrößert wird, anstatt die maximale Größe, die es erreichen kann.)
  • Aktivieren von TCP Zeitstempel. - Auch hier keine Änderung.
  • Nagles Algorithmus - Das macht Sinn und bedeutet zumindest, dass ich diese bestimmten Punkte in der Grafik wahrscheinlich als Hinweis auf das Problem ignorieren kann.
  • pcap-Dateien: Zip-Datei hier verfügbar: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.Zip (Anonymisiert mit bittwiste , extrahiert auf ~ 150 MB, da von jedem Betriebssystem-Client einer zum Vergleich vorhanden ist)

Update 2 - 30. Juni

O, also habe ich nach dem Vorschlag von Kyle ctcp aktiviert und das Abladen von Schornsteinen deaktiviert: TCP Globale Parameter

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

Leider ändert sich der Durchsatz nicht.

Ich habe hier jedoch eine Ursache-Wirkungs-Frage: Die Diagramme entsprechen dem RWIN-Wert, der in den ACKs des Servers für den Client festgelegt ist. Habe ich bei Windows-Clients Recht, wenn ich denke, dass Linux diesen Wert nicht über diesen Tiefpunkt hinaus skaliert, weil die begrenzte CWIN des Clients verhindert, dass auch dieser Puffer gefüllt wird? Könnte es einen anderen Grund geben, warum Linux den RWIN künstlich einschränkt?

Hinweis: Ich habe versucht, ECN zum Teufel einzuschalten. aber keine Veränderung, da.

Update 3 - 31. Juni.

Keine Änderung nach Deaktivierung der Heuristik und des RWIN-Autotunings. Die Intel-Netzwerktreiber wurden mit einer Software auf den neuesten Stand (12.10.28.0) aktualisiert, die Funktionsänderungen über die Registerkarten des Geräte-Managers ermöglicht. Bei der Karte handelt es sich um einen integrierten 82579-V-Chipsatz NIC Ich werde weitere Tests von Kunden mit Realtek oder anderen Anbietern durchführen).

Ich habe mich für einen Moment auf die NIC) konzentriert und Folgendes versucht (meistens nur, um unwahrscheinliche Schuldige auszuschließen):

Update 3 - 3. Juli

Beim Versuch, die Linux-Serverseite zu eliminieren, habe ich eine Server 2012R2-Instanz gestartet und die Tests mit iperf (Cygwin-Binär) und --- (NTttcp wiederholt.

Mit iperf musste ich explizit -w1m Auf both Seiten angeben, bevor die Verbindung über ~ 5Mbit/s hinaus skaliert. (Übrigens konnte ich überprüft werden und der BDP von ~ 5 Mbit bei 91 ms Latenz beträgt fast genau 64 kb. Finde das Limit ...)

Die ntttcp-Binärdateien zeigten nun eine solche Einschränkung. Wenn ich ntttcpr -m 1,0,1.2.3.5 Auf dem Server und ntttcp -s -m 1,0,1.2.3.5 -t 10 Auf dem Client verwende, kann ich einen viel besseren Durchsatz sehen:

Copyright Version 5.28
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8 MB/s bringen es auf die Ebenen, die ich mit explizit großen Fenstern in iperf erhalten habe. Seltsamerweise sind 80 MB in 1273 Puffern wieder ein 64-KB-Puffer. Ein weiterer Wireshark zeigt einen guten, variablen RWIN, der vom Server zurückkommt (Skalierungsfaktor 256), den der Client zu erfüllen scheint. Vielleicht meldet ntttcp das Sendefenster falsch.

Update 4 - 3. Juli

Auf Wunsch von @ karyhead habe ich hier weitere Tests durchgeführt und einige weitere Captures generiert: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07 -03.Zip

  • Zwei weitere iperfs, beide von Windows auf denselben Linux-Server wie zuvor (1.2.3.4): Eines mit einer Socket-Größe von 128 KB und einem Standardfenster von 64 KB (wieder auf ~ 5 Mbit/s beschränkt) und eines mit einem Send von 1 MB Fenster und Standardgröße von 8 KB Socket. (skaliert höher)
  • Ein ntttcp Trace vom selben Windows-Client zu einer Server 2012R2 EC2-Instanz (1.2.3.5). hier skaliert der Durchsatz gut. Hinweis: NTttcp führt an Port 6001 etwas Seltsames aus, bevor die Testverbindung geöffnet wird. Ich bin mir nicht sicher, was dort passiert.
  • Eine FTP-Datenverfolgung, bei der 20 MB /dev/urandom Mit Cygwin ncftp auf einen nahezu identischen Linux-Host (1.2.3.6) hochgeladen werden. Wieder ist die Grenze da. Das Muster ist mit Windows Filezilla ähnlich.

Das Ändern der Pufferlänge iperf macht den erwarteten Unterschied zum Zeitsequenzdiagramm (viel mehr vertikale Abschnitte), aber der tatsächliche Durchsatz bleibt unverändert.

50
SmallClanger

Haben Sie versucht, Compound TCP (CTCP) in Ihren Windows 7/8-Clients zu aktivieren?.

Bitte lesen Sie:

Erhöhung der senderseitigen Leistung für die Übertragung mit hohem BDP

http://technet.Microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

Diese Algorithmen eignen sich gut für kleine BDPs und kleinere Empfangsfenstergrößen. Wenn Sie jedoch eine TCP Verbindung mit einer großen Empfangsfenstergröße und einem großen BDP haben, z. B. das Replizieren von Daten zwischen zwei Servern, die sich über ein Hochgeschwindigkeits-WAN befinden Verbindung mit einer 100-ms-Umlaufzeit, diese Algorithmen vergrößern das Sendefenster nicht schnell genug, um die Bandbreite der Verbindung voll auszunutzen.

Um die Bandbreite von TCP Verbindungen in diesen Situationen besser zu nutzen, enthält der TCP/IP-Stapel der nächsten Generation die Verbindung TCP (CTCP). CTCP erhöht aggressiver das Sendefenster fürVerbindungen mit großen Empfangsfenstergrößen und BDPs. CTCP versucht, den Durchsatz für diese Verbindungstypen zu maximieren, indem Verzögerungsschwankungen und -verluste überwacht werden. Darüber hinaus stellt CTCP sicher, dass sich sein Verhalten nicht negativ auf andere TCP Verbindungen auswirkt.

...

CTCP ist auf Computern unter Windows Server 2008 standardmäßig aktiviert und auf Computern unter Windows Vista standardmäßig deaktiviert. Sie können CTCP mit dem Befehl netsh interface tcp set global congestionprovider=ctcp Aktivieren. Sie können CTCP mit dem Befehl netsh interface tcp set global congestionprovider=none Deaktivieren.

Bearbeiten 30.06.2014

um zu sehen, ob CTCP wirklich "on" ist

> netsh int tcp show global

d.h.

enter image description here

PO sagte:

Wenn ich das richtig verstehe, erhöht diese Einstellung die Rate bei was das Überlastungsfenster vergrößert und nicht die maximale Größe es kann erreichen

CTCP vergrößert das Sendefenster aggressiv

http://technet.Microsoft.com/en-us/library/bb878127.aspx

Zusammengesetztes TCP

Die vorhandenen Algorithmen, die verhindern, dass ein sendender TCP Peer das Netzwerk überfordert, werden als langsame Start- und Überlastungsvermeidung bezeichnet. Diese Algorithmen erhöhen die Anzahl der Segmente, die der Absender senden kann. Dies wird als Sendefenster bezeichnet, wenn Daten zum ersten Mal über die Verbindung gesendet werden und wenn ein verlorenes Segment wiederhergestellt wird. Langsamer Start erhöht das Sendefenster für jedes empfangene Bestätigungssegment (für TCP in Windows TCP und Windows Server 2003) oder für jedes Segment um ein volles XP Segment bestätigt (für TCP in Windows Vista und Windows Server 2008). Durch die Vermeidung von Überlastungen wird das Sendefenster für jedes bestätigte Datenfenster um ein vollständiges TCP Segment erhöht.

Diese Algorithmen eignen sich gut für LAN-Mediengeschwindigkeiten und kleinere TCP Fenstergrößen. Wenn Sie jedoch eine TCP -Verbindung mit einer großen Empfangsfenstergröße und einem Produkt mit großer Bandbreitenverzögerung (hohe Bandbreite und hohe Verzögerung) haben, z. B. das Replizieren von Daten zwischen zwei Servern, die sich über eine Hochgeschwindigkeits-WAN Bei einer Verbindung mit einer Umlaufzeit von 100 ms erhöhen diese Algorithmen das Sendefenster nicht schnell genug, um die Bandbreite der Verbindung voll auszunutzen. Beispiel: Bei einer Verbindung mit 1 Gigabit pro Sekunde (Gbit/s) WAN mit einer Umlaufzeit von 100 ms (RTT) kann es kannbis zu einer Stunde dauern Das Sendefenster wird zunächst aufgroße Fenstergröße, die vom Empfänger angekündigt wird, erhöht und wiederhergestellt, wennSegmente verloren gehen.

m die Bandbreite besser zu nutzen von TCP Verbindungen in diesen Situationen enthält der TCP/IP-Stack der nächsten Generation Compound TCP (CTCP). CTCP erhöht das Sendefenster für Verbindungen mit großen Empfangsfenstergrößen und Produkten mit großer Bandbreitenverzögerung aggressiver. CTCP versucht, den Durchsatz für diese Verbindungstypen durch Überwachung von Verzögerungsschwankungen und -verlusten zu maximieren. CTCP stellt außerdem sicher, dass sein Verhalten andere TCP Verbindungen nicht negativ beeinflusst.

Bei Tests, die intern bei Microsoft durchgeführt wurden, wurden die Sicherungszeiten für große Dateien für eine 1-Gbit/s-Verbindung mit einer 50-ms-RTT um fast die Hälfte reduziert. Verbindungen mit einem Produkt mit größerer Bandbreitenverzögerung können eine noch bessere Leistung erzielen. CTCP und Receive Window Auto-Tuning arbeiten zusammen, um die Verbindungsauslastung zu erhöhen, und können zu erheblichen Leistungssteigerungen bei Produktverbindungen mit großer Bandbreitenverzögerung führen.

15
Pat

Klärung des Problems:

TCP hat zwei Fenster:

  • Das Empfangsfenster: Wie viele Bytes sind noch im Puffer. Dies ist eine vom Empfänger auferlegte Flusskontrolle. Sie können die Größe des Empfangsfensters im Wireshark sehen, da es sich aus der Fenstergröße und dem Fensterskalierungsfaktor im TCP - Header zusammensetzt. Beide Seiten der TCP - Verbindung kündigen ihr Empfangsfenster an, aber im Allgemeinen ist dasjenige, das Sie interessiert, dasjenige, das den Großteil der Daten empfängt. In Ihrem Fall ist es der "Server", da der Client auf den Server hochlädt
  • Das Überlastungsfenster. Dies ist eine vom Absender auferlegte Flusskontrolle. Dies wird vom Betriebssystem verwaltet und nicht im Header TCP angezeigt. Es steuert die Geschwindigkeit, mit der Daten gesendet werden.

In der von Ihnen angegebenen Erfassungsdatei. Wir können sehen, dass der Empfangspuffer niemals überläuft:

enter image description here

Meine Analyse ist, dass der Absender nicht schnell genug sendet, weil sich das Sendefenster (auch bekannt als Überlastungskontrollfenster) nicht genug öffnet, um die RWIN des Empfängers zu erfüllen. Kurz gesagt, der Empfänger sagt "Gib mir mehr" und wenn Windows der Absender ist, sendet er nicht schnell genug.

Dies wird durch die Tatsache belegt, dass in der obigen Grafik der RWIN offen bleibt und mit einer Umlaufzeit von 0,09 Sekunden und einem RWIN von ~ 500.000 Bytes ein maximaler Durchsatz gemäß dem Bandbreitenverzögerungsprodukt (500000) erwartet werden kann /0.09) * 8 = ~ 42 Mbit/s (und Sie erhalten nur ungefähr ~ 5 in Ihrem Gewinn für Linux-Capture).

Wie man es repariert?

Ich weiß es nicht. interface tcp set global congestionprovider=ctcp Klingt für mich wie das Richtige, da es das Sendefenster vergrößern würde (was ein anderer Begriff für das Überlastungsfenster ist). Sie sagten, das funktioniert nicht. Also nur um sicher zu gehen:

  1. Haben Sie nach dem Aktivieren neu gestartet?
  2. Ist der Schornstein abgeladen? Wenn dies der Fall ist, versuchen Sie es als Experiment auszuschalten. Ich weiß nicht, was genau entladen wird, wenn dies aktiviert ist, aber wenn die Steuerung des Sendefensters eine davon ist, hat der Überlastungsanbieter möglicherweise keine Auswirkung, wenn dies aktiviert ist ... Ich vermute nur ...
  3. Ich denke auch, dass dies vor Windows 7 sein könnte, aber Sie könnten versuchen, die beiden Registrierungsschlüssel DefaultSendWindow und DefaultReceiveWindow in HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parametern hinzuzufügen und damit zu spielen. Wenn diese überhaupt funktionieren, haben Sie wahrscheinlich ctcp ausgeschaltet.
  4. Noch eine Vermutung, versuchen Sie es mit netsh interface tcp show heuristics. Ich denke, das könnte RWIN sein, aber es heißt nicht, also spielen Sie vielleicht mit dem Deaktivieren/Aktivieren, falls es das Sendefenster beeinflusst.
  5. Stellen Sie außerdem sicher, dass Ihre Treiber auf Ihrem Testclient auf dem neuesten Stand sind. Vielleicht ist gerade etwas kaputt.

Ich würde all diese Experimente zunächst mit allen Offloading-Funktionen ausprobieren, um die Möglichkeit auszuschließen, dass die Netzwerktreiber die Dinge neu schreiben/ändern (behalten Sie die CPU im Auge, während das Offloading deaktiviert ist). Die Struktur TCP_OFFLOAD_STATE_DELEGATED scheint zumindest zu implizieren, dass CWnd-Offloading zumindest möglich ist.

12
Kyle Brandt

Hier gab es einige großartige Informationen von @Pat und @Kyle. Achten Sie auf jeden Fall auf @ Kyles Erklärung des TCP Empfangs- und Sendefensters, ich glaube, es gab einige Verwirrung darüber. Um die Sache weiter zu verwirren, verwendet iperf den Begriff "TCP-Fenster" mit der Einstellung -w, Die in Bezug auf das Empfangs-, Sende- oder Gesamtschiebefenster eine Art mehrdeutiger Begriff ist. Tatsächlich wird der Socket-Sendepuffer für -c (Client) -Instanz und der Socket empfangen Puffer auf der -s (Server) -Instanz. In src/tcp_window_size.c:

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

Wie Kyle erwähnt, liegt das Problem nicht beim Empfangsfenster auf der Linux-Box, aber der Absender öffnet das Sendefenster nicht genug. Es ist nicht so, dass es sich nicht schnell genug öffnet, es ist nur auf 64k begrenzt.

Die Standardgröße des Socket-Puffers unter Windows 7 beträgt 64 KB. In der Dokumentation wird Folgendes über die Socket-Puffergröße in Bezug auf den Durchsatz bei MSDN angegeben

Beim Senden von Daten über eine TCP -Verbindung über Windows-Sockets) ist es wichtig, dass in TCP in) eine ausreichende Datenmenge aussteht (gesendet, aber noch nicht bestätigt) Um den höchsten Durchsatz zu erzielen. Der ideale Wert für die ausstehende Datenmenge, um den besten Durchsatz für die Verbindung TCP Verbindung) zu erzielen, wird als ideale ISB-Größe (Send Backlog) bezeichnet. Der ISB-Wert ist a Funktion des Bandbreitenverzögerungsprodukts der TCP -Verbindung und des angekündigten Empfangsfensters des Empfängers (und teilweise der Überlastungsmenge im Netzwerk).

Ok, bla bla bla, jetzt geht es los:

Anwendungen, die jeweils eine blockierende oder nicht blockierende Sendeanforderung ausführen, sind normalerweise auf die interne Sendepufferung durch Winsock angewiesen, um einen angemessenen Durchsatz zu erzielen. Das Sendepufferlimit für eine bestimmte Verbindung wird durch die Socket-Option SO_SNDBUF gesteuert. Für die blockierende und nicht blockierende Sendemethode bestimmt das Sendepufferlimit, wie viele Daten in TCP ausstehend bleiben . Wenn der ISB-Wert für die Verbindung größer als das Sendepufferlimit ist, ist der für die Verbindung erzielte Durchsatz nicht optimal.

Der durchschnittliche Durchsatz Ihres letzten iperf-Tests mit dem 64k-Fenster beträgt 5,8 Mbit/s. Das ist von Statistik> Zusammenfassung in Wireshark, die alle Bits zählt. Wahrscheinlich zählt iperf TCP Datendurchsatz, der 5,7 Mbit/s beträgt. Wir sehen die gleiche Leistung auch beim FTP-Test, ~ 5,6 Mbit/s.

Der theoretische Durchsatz mit einem 64k-Sendepuffer und 91ms RTT beträgt .... 5,5 Mbit/s. Nah genug für mich.

Wenn wir uns Ihren 1-MB-Fenster-Iperf-Test ansehen, beträgt der Tput 88,2 Mbit/s (86,2 Mbit/s für nur TCP -Daten). Der theoretische Tput mit einem 1-MB-Fenster beträgt 87,9 Mbit/s Arbeit.

Dies zeigt, dass der Sende-Socket-Puffer das Sendefenster direkt steuert und in Verbindung mit dem Empfangsfenster von der anderen Seite den Durchsatz steuert. Das angekündigte Empfangsfenster bietet Platz, sodass wir nicht vom Empfänger eingeschränkt werden.

Was ist mit diesem Autotuning-Geschäft? Behandelt Windows 7 das nicht automatisch? Wie bereits erwähnt, übernimmt Windows die automatische Skalierung des Empfangsfensters, kann aber auch den Sendepuffer dynamisch verarbeiten. Kehren wir zur MSDN-Seite zurück:

Dynamische Sendepufferung für TCP wurde unter Windows 7 und Windows Server 2008 R2 hinzugefügt. Standardmäßig ist die dynamische Sendepufferung für TCP ist aktiviert, sofern keine Anwendung den SO_SNDBUF festlegt Socket-Option auf dem Stream-Socket.

iperf verwendet SO_SNDBUF, wenn die Option -w verwendet wird, sodass die dynamische Sendepufferung deaktiviert wird. Wenn Sie jedoch nicht -w Verwenden, wird SO_SNDBUF Nicht verwendet. Die dynamische Sendepufferung sollte standardmäßig aktiviert sein. Sie können jedoch Folgendes überprüfen:

netsh winsock show autotuning

In der Dokumentation heißt es, dass Sie es deaktivieren können mit:

netsh winsock set autotuning off

Aber das hat bei mir nicht funktioniert. Ich musste eine Registrierungsänderung vornehmen und diese auf 0 setzen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

Ich denke nicht, dass das Deaktivieren helfen wird. Es ist nur eine FYI.

Warum liegt die Skalierung Ihres Sendepuffers nicht über dem Standardwert von 64 KB, wenn Sie Daten an eine Linux-Box mit viel Platz im Empfangsfenster senden? Gute Frage. Linux-Kernel haben auch einen Autotuning-Stapel TCP. Wie T-Pain und Kanye, die zusammen ein Autotune-Duett machen, klingt es möglicherweise nicht gut. Vielleicht gibt es ein Problem mit diesen beiden Autotuning TCP-Stapel, die miteinander sprechen.

Eine andere Person hatte ein Problem wie das Ihre und konnte es mit einer Registrierungsbearbeitung beheben, um die Standardgröße des Sendepuffers zu erhöhen. Leider scheint das nicht mehr zu funktionieren, zumindest nicht für mich, als ich es ausprobiert habe.

An diesem Punkt denke ich, dass es klar ist, dass der begrenzende Faktor die Sendepuffergröße auf dem Windows-Host ist. Da es nicht dynamisch zu wachsen scheint Richtig, was soll ein Mädchen tun?

Du kannst:

  • Verwenden Sie Anwendungen, mit denen Sie den Sendepuffer, d. H. Die Fensteroption, festlegen können
  • Verwenden Sie einen lokalen Linux-Proxy
  • Verwenden Sie einen Remote-Windows-Proxy?
  • Öffnen Sie einen Fall mit Microsofhahahahahahaha
  • Bier

Haftungsausschluss: Ich habe viele, viele Stunden damit verbracht, dies zu recherchieren, und es ist nach bestem Wissen und Gewissen richtig. Aber ich würde nicht auf das Grab meiner Mutter schwören (sie lebt noch).

5
karyhead

Sobald Sie den TCP -Stack optimiert haben, haben Sie möglicherweise immer noch einen Engpass in der Winsock-Ebene. Ich habe festgestellt, dass die Konfiguration von Winsock (Zusatzfunktionstreiber in der Registrierung) einen großen Unterschied für die Upload-Geschwindigkeit darstellt ( Daten auf den Server übertragen) in Windows 7. Microsoft hat einen Fehler in der TCP Autotuning für nicht blockierende Sockets - genau die Art von Socket, die Browser verwenden ;-)

Fügen Sie den DWORD-Schlüssel für DefaultSendWindow hinzu und setzen Sie ihn auf BDP oder höher. Ich benutze 256000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

Das Ändern der Winsock-Einstellung für Downloads kann hilfreich sein - fügen Sie einen Schlüssel für DefaultReceiveWindow hinzu.

Sie können mit verschiedenen Einstellungen auf Socket-Ebene experimentieren, indem Sie den Fiddler Proxy und die Befehle verwenden, um die Client- und Server-Socket-Puffergrößen anzupassen:

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF
4
LeslieM

Nachdem Sie alle Analysen in den Antworten gelesen haben, klingt dieses Problem sehr nach Windows7/2008R2, auch bekannt als Windows 6.1

Der Netzwerkstapel (TCP/IP & Winsock) in Windows 6.1 war schrecklich fehlerhaft und hatte eine ganze Reihe von Fehlern und Leistungsproblemen, die Microsoft seit der ersten Veröffentlichung von 6.1 über viele Jahre hinweg behoben hat.

Die beste Möglichkeit, diese Hotfixes anzuwenden, besteht darin, alle relevanten Seiten auf support.Microsoft.com manuell zu durchsuchen und die LDR-Versionen der Netzwerkstapel-Hotfixes manuell anzufordern und herunterzuladen (es gibt viele Dutzend davon).

Um die relevanten Hotfixes zu finden, müssen Sie www.bing.com mit der folgenden Suchabfrage verwenden: site:support.Microsoft.com 6.1.7601 tcpip.sys

Sie müssen auch verstehen, wie LDR/DDR-Hotfix-Züge in Windows 6.1 funktionieren

Im Allgemeinen habe ich meine eigene Liste von LDR-Fixes (nicht nur Netzwerk-Stack-Fixes) für Windows 6.1 verwaltet und diese Fixes dann proaktiv auf alle Windows 6.1-Server/-Clients angewendet, auf die ich gestoßen bin. Es war eine sehr zeitaufwändige Aufgabe, regelmäßig nach neuen LDR-Hotfixes zu suchen.

Glücklicherweise hat Microsoft die Praxis von LDR-Hotfixes mit neueren Betriebssystemversionen eingestellt, und Bugfixes sind jetzt über automatische Update-Dienste von Microsoft verfügbar.

[~ # ~] update [~ # ~] : Nur ein Beispiel für viele Netzwerkfehler in Windows7SP1 - https: // support. Microsoft.com/en-us/kb/2675785

UPDATE 2 : Hier ist ein weiterer Hotfix, der einen Netsh-Schalter hinzufügt, um die Fensterskalierung nach der zweiten erneuten Übertragung eines SYN-Pakets zu erzwingen (standardmäßig ist die Fensterskalierung danach deaktiviert 2 SYN-Pakete werden erneut übertragen) https://support.Microsoft.com/en-us/kb/2780879

3

Ich sehe, dass dies ein etwas älterer Beitrag ist, aber er könnte anderen helfen.

Kurz gesagt, Sie müssen "Auto-Tuning des Empfangsfensters" aktivieren:

netsh int tcp set global autotuninglevel=normal

CTCP bedeutet nichts ohne oben aktiviert.

Wenn Sie "Auto-Tuning des Empfangsfensters" deaktivieren, bleiben Sie bei einer Paketgröße von 64 KB hängen, was sich negativ auf lange RTTs bei Hochbreitbandverbindungen auswirkt. Sie können auch mit den Optionen "eingeschränkt" und "stark eingeschränkt" experimentieren.

Sehr gute Referenz: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

1
spricer

Ich hatte ein ähnliches Problem mit Windows-Clients (Windows 7). Ich habe das meiste Debugging, das Sie durchlaufen haben, durchlaufen und den Nagle-Algorithmus deaktiviert, TCP Chimney Offloading, und Tonnen anderer TCP-bezogene Einstellungsänderungen. Keiner von ihnen hatte jede Wirkung.

Was es für mich endgültig behoben hat, war das Ändern des Standard-Sendefensters in der Registrierung des AFD-Dienstes. Das Problem scheint mit der Datei afd.sys zu zusammenhängen. Ich habe mehrere Clients getestet, einige zeigten den langsamen Upload und andere nicht, aber alle waren Windows 7-Computer. Maschinen, die das langsame Verhalten zeigten, hatten dieselbe Version AFD.sys. Die Registrierungsumgehung wird für Computer mit bestimmten Versionen von AFD.sys benötigt (leider nicht an die Versionsnummern erinnern).

HKLM\CurrentControlSet\Services\AFD\Parameters

Add - DWORD - DefaultSendWindow

Wert - Dezimal - 1640960

Diesen Wert habe ich hier gefunden: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Ich denke, um den richtigen Wert zu verwenden, sollten Sie ihn selbst berechnen mit:

z.B. Angekündigter Upload: 15 Mbit/s = 15.000 Kbit/s

(15000/8) * 1024 = 1920000

Soweit ich weiß, sollte Client-Software diese Einstellung in der Registrierung im Allgemeinen überschreiben. Andernfalls wird der Standardwert verwendet, und anscheinend ist der Standardwert in einigen Versionen der Datei AFD.sys sehr niedrig.

Ich habe festgestellt, dass die meisten MS-Produkte das Problem des langsamen Uploads hatten (IE, Mini-Redirector (WebDAV), FTP über Windows Explorer usw.). Bei Verwendung von Software von Drittanbietern (z. B. Filezilla) hatte ich nicht die gleichen Verlangsamungen .

AFD.sys wirkt sich auf alle Winsock-Verbindungen aus, daher sollte dieser Fix für FTP, HTTP, HTTPS usw. gelten.

Außerdem wurde dieses Update auch irgendwo oben aufgeführt, sodass ich es nicht gutschreiben möchte, wenn es für irgendjemanden funktioniert. Es gab jedoch so viele Informationen in diesem Thread, dass ich befürchtete, es könnte beschönigt worden sein.

1
jjspierx

Nun, ich bin selbst in eine ähnliche Situation geraten (meine Frage hier ), und am Ende musste ich TCP Skalierungsheuristiken) deaktivieren und das Autotuning-Profil manuell einstellen und aktivieren Sie CTCP:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok. 
0

Dies ist ein faszinierender Thread, der genau den Problemen entspricht, die ich mit Win7/iperf hatte, um den Durchsatz an langen Fettrohren zu testen.

Die Lösung für Windows 7 besteht darin, den folgenden Befehl sowohl auf dem iperf-Server als auch auf dem Client auszuführen.

netsh interface tcp set global autotuninglevel = experimentell

NB: Bevor Sie dies tun, müssen Sie den aktuellen Status des Autotunings aufzeichnen:

netsh interface tcp show global

Auto-Tuning-Stufe des Empfangsfensters: deaktiviert

Führen Sie dann den iperf-Server/Client an jedem Ende der Pipe aus.

Setzen Sie den Autotuning-Wert nach Ihren Tests zurück:

netsh interface tcp set global autotuninglevel =

   autotuninglevel - One of the following values:
                     disabled: Fix the receive window at its default
                         value.
                     highlyrestricted: Allow the receive window to
                         grow beyond its default value, but do so
                         very conservatively.
                     restricted: Allow the receive window to grow
                         beyond its default value, but limit such
                         growth in some scenarios.
                     normal: Allow the receive window to grow to
                         accomodate almost all scenarios.
                     experimental: Allow the receive window to grow
                         to accomodate extreme scenarios.
0
wicksee

Ich habe nicht genug Punkte, um Kommentare abzugeben, daher werde ich stattdessen eine "Antwort" veröffentlichen. Ich habe ein scheinbar ähnliches/identisches Problem (siehe Serverfehlerfrage hier ). Mein (und wahrscheinlich Ihr) Problem ist der Sendepuffer des iperf-Clients unter Windows. Es wächst nicht über 64 KB hinaus. Windows soll den Puffer dynamisch vergrößern, wenn er vom Prozess nicht explizit dimensioniert wird. Dieses dynamische Wachstum findet jedoch nicht statt.

Ich bin mir nicht sicher, ob Ihr Fensterskalierungsdiagramm zeigt, dass das Fenster bis zu 500.000 Byte für Ihren "langsamen" Windows-Fall öffnet. Ich habe erwartet, dass dieses Diagramm nur für ~ 64.000 Bytes geöffnet ist, da Sie auf 5 Mbit/s beschränkt sind.

0