Frage Receiver begrenzt die TCP-Fenstergröße auf 64.512


Fakten (Bitte identifizieren Sie falsche Angaben):

  1. Ich habe eine 100 Mbps-Verbindung zwischen zwei Standorten, die 80 ms voneinander entfernt sind

  2. Dies ist eine lange fette Verbindung, die von einer großen TCP-Fenstergröße von vielleicht bis zu 100 Mbps * 0,08 Sek. = 1.000.000 Byte profitieren könnte

  3. Auf beiden Computern wird Windows Server 2012 ausgeführt. Die automatische Optimierung des Empfangsfensters ist in beiden Fällen normal. "Window-Scaling-Heuristiken" sind bei beiden deaktiviert.

  4. Ich lief "iperf -s" auf der einen Seite und "iperf -c" auf der anderen Seite. Die Übertragung erfolgte mit 5 Mbit / s. Ich bekomme das gleiche Ergebnis in die andere Richtung.

  5. Beide Seiten bewarben Unterstützung für TCP gleitende Fenster in ihren SYNs.

  6. Der Empfänger hat eine TCP-Fenstergröße von 64,512 Byte angefordert (0xFC00) während des gesamten Laufs mit einem TCP-Fenster Maßstabswert von "keine Verschiebung" (0x000).

  7. Das Netzwerk konnte eine größere Fenstergröße verarbeiten (siehe Sequenz) Diagramme unten)

  8. Der Empfänger hat das Fenster kleiner gehalten, als das Netzwerk unterstützt

  9. Diese Verbindung findet innerhalb eines IPSEC VPN statt. Die MTU der Tunnelschnittstelle ist in beiden Richtungen auf 1400 Byte reduziert.

Frage

  • Warum hält der Empfänger das Fenster klein?

Nicht-Antworten

  • Das Netzwerk ist kaputt

    Linux-Computer, die im selben Netzwerk ausgeführt werden, öffnen das TCP-Fenster auf 1,5 Megabyte und übertragen Daten mit der sechsfachen Bandbreite

  • Window-Scaling-Heuristiken sind aktiviert

    Window-Scaling-Heuristiken sind deaktiviert (siehe Ausgabe von "netsh interface tcp show heuristics")

  • Auto-Tuning-Level für Empfangsfenster ist nicht normal

    Die Empfangsautomatik ist normal (siehe Ausgabe von "netsh interface tcp show global")

  • Dies funktioniert auf einer virtuellen Maschine in ESXi nur schlecht

    Ich bekomme 6 Mal bessere Leistung auf einem virtuellen Linux-Rechner, der auf demselben Host läuft.


Update 1 12. Juni 2015 16:30 Uhr PDT

Ich modifizierte den Test, indem ich Linux auf eine Seite der Verbindung setzte. Wenn Linux Daten an Windows Server 2012 sendet, bietet Windows ein zu kleines TCP-Empfangsfenster (64 512 Bytes).

Wenn ich Daten von Windows nach Linux sende, bietet Linux ein TCP-Empfangsfenster (1.365.120 Bytes). Windows schränkt jedoch Sends im Flug auf maximal ~ 60.000 Bytes ein.


Update 2 13. Juni 2015 15:00 Uhr PDT

Ein Schritt näher zur Ursache. In meinem Setup sind weder SO_SNDBUF noch SO_RCVBUF gesetzt (von iperf). Dies sind die Sende- und Empfangspuffer, die das Empfangsfenster effektiv begrenzen. Wenn diese Werte nicht angegeben werden, stellt Windows Server 2012 einen Standardwert von 64 KB bereit. Also die Frage ist jetzt:

Frage

  • Wenn nicht angegeben wird, warum wird Windows Server 2012 SO_SNDBUF / SO_RCVBUF nicht dynamisch erhöht, um lange fette Pipelines aufzunehmen, wie unter beschrieben MSDN?

Nicht-Antworten

  • "netsh winsock show autotuning" ist deaktiviert

    Es ist aktiviert.


Update 3 24. August 2015 16:00 Uhr PDT

Netsh wurde anscheinend durch Set-NetTCPSetting und Familie ersetzt. Get-NetTCPSetting kombiniert mit Get-NetTCPConnection zeigt, dass ich im "Internet" -Regime operiere, welches mir folgende Einstellungen bietet:

SettingName                   : Internet
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : CTCP
CwndRestart                   : False
DelayedAckTimeout(ms)         : 50
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

Sender-TCP-Einstellungen

PS C:\Users\acs> netsh interface tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : disabled
Direct Cache Access (DCA)           : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : none
ECN Capability                      : enabled
RFC 1323 Timestamps                 : disabled
Initial RTO                         : 3000
Receive Segment Coalescing State    : enabled

PS C:\Users\acs> netsh interface tcp show heuristics
TCP Window Scaling heuristics Parameters
----------------------------------------------
Window Scaling heuristics         : disabled
Qualifying Destination Threshold  : 3
Profile type unknown              : normal
Profile type public               : normal
Profile type private              : normal
Profile type domain               : normal

PS C:\Users\acs> Get-NetTCPSetting

SettingName                   : Automatic
MinRto(ms)                    : 
InitialCongestionWindow(MSS)  : 
CongestionProvider            : 
CwndRestart                   : 
DelayedAckTimeout(ms)         : 
MemoryPressureProtection      : 
AutoTuningLevelLocal          : 
AutoTuningLevelGroupPolicy    : 
AutoTuningLevelEffective      : 
EcnCapability                 : 
Timestamps                    : 
InitialRto(ms)                : 
ScalingHeuristics             : 
DynamicPortRangeStartPort     : 
DynamicPortRangeNumberOfPorts : 

SettingName                   : Custom
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Compat
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 2
CongestionProvider            : Default
CwndRestart                   : False
DelayedAckTimeout(ms)         : 200
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Datacenter
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Internet
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : CTCP
CwndRestart                   : False
DelayedAckTimeout(ms)         : 50
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

Absender SYN

No.     Time           Source                Destination           Protocol Length Delta      Sequence number Acknowledgment number Bytes in flight Calculated window size Info
    814 5.036577000    10.10.0.21            10.11.0.1             TCP      66     0.000000000 0               0                                     64512                  49758→5001 [SYN, ECN, CWR] Seq=0 Win=64512 Len=0 MSS=1460 WS=1 SACK_PERM=1

Frame 814: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Ethernet II, Src: 00:11:22:33:44:55, Dst: aa:bb:cc:dd:ee:ff
Internet Protocol Version 4, Src: 10.10.0.21 (10.10.0.21), Dst: 10.11.0.1 (10.11.0.1)
Transmission Control Protocol, Src Port: 49758 (49758), Dst Port: 5001 (5001), Seq: 0, Len: 0
    Source Port: 49758 (49758)
    Destination Port: 5001 (5001)
    [Stream index: 73]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 0
    Header Length: 32 bytes
    .... 0000 1100 0010 = Flags: 0x0c2 (SYN, ECN, CWR)
    Window size value: 64512
    [Calculated window size: 64512]
    Checksum: 0x1451 [validation disabled]
    Urgent pointer: 0
    Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
        Maximum segment size: 1460 bytes
        No-Operation (NOP)
        Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        No-Operation (NOP)
        No-Operation (NOP)
        TCP SACK Permitted Option: True

Senderperspektive des Sequenzgraphen enter image description here

enter image description here

Empfänger-TCP-Einstellungen

PS C:\Users\acs> netsh interface tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : disabled
Direct Cache Access (DCA)           : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : none
ECN Capability                      : enabled
RFC 1323 Timestamps                 : disabled
Initial RTO                         : 3000
Receive Segment Coalescing State    : enabled

PS C:\Users\acs> netsh interface tcp show heuristics
TCP Window Scaling heuristics Parameters
----------------------------------------------
Window Scaling heuristics         : disabled
Qualifying Destination Threshold  : 3
Profile type unknown              : normal
Profile type public               : normal
Profile type private              : normal
Profile type domain               : normal

PS C:\Users\acs> Get-NetTCPSetting

SettingName                   : Automatic
MinRto(ms)                    : 
InitialCongestionWindow(MSS)  : 
CongestionProvider            : 
CwndRestart                   : 
DelayedAckTimeout(ms)         : 
MemoryPressureProtection      : 
AutoTuningLevelLocal          : 
AutoTuningLevelGroupPolicy    : 
AutoTuningLevelEffective      : 
EcnCapability                 : 
Timestamps                    : 
InitialRto(ms)                : 
ScalingHeuristics             : 
DynamicPortRangeStartPort     : 
DynamicPortRangeNumberOfPorts : 

SettingName                   : Custom
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Compat
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 2
CongestionProvider            : Default
CwndRestart                   : False
DelayedAckTimeout(ms)         : 200
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Datacenter
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Internet
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : CTCP
CwndRestart                   : False
DelayedAckTimeout(ms)         : 50
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

Empfänger SYN

No.     Time           Source                Destination           Protocol Length Delta      Sequence number Acknowledgment number Bytes in flight Calculated window size Info
    817 5.110501000    10.11.0.1             10.10.0.21            TCP      70     0.073924000 0               1                                     64512                  5001→49758 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 SACK_PERM=1 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

Frame 817: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0
Ethernet II, Src: aa:bb:cc:dd:ee:ff, Dst: 00:11:22:33:44:55
Internet Protocol Version 4, Src: 10.11.0.1 (10.11.0.1), Dst: 10.10.0.21 (10.10.0.21)
Transmission Control Protocol, Src Port: 5001 (5001), Dst Port: 49758 (49758), Seq: 0, Ack: 1, Len: 0
    Source Port: 5001 (5001)
    Destination Port: 49758 (49758)
    [Stream index: 73]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 1    (relative ack number)
    Header Length: 32 bytes
    .... 0000 0101 0010 = Flags: 0x052 (SYN, ACK, ECN)
    Window size value: 64512
    [Calculated window size: 64512]
    Checksum: 0xb5bb [validation disabled]
    Urgent pointer: 0
    Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
        Maximum segment size: 1460 bytes
        No-Operation (NOP)
        Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        No-Operation (NOP)
        No-Operation (NOP)
        TCP SACK Permitted Option: True
    [SEQ/ACK analysis]

Empfängerperspektive des Sequenzgraphen enter image description here enter image description here

TCP-Fenster enter image description here


34
2018-06-12 07:18


Ursprung


Können Sie bitte die genaue Konfiguration hinzufügen - soft UND Hardware relevant (Netzwerkkarte) für beide Seiten? - TomTom
Klingt wie Fenster-Tuning beschränkt. - David Schwartz
@TomTom Beide Computer sind VMs in ESXi, die auf dem HP Proliant DL380 G5 ausgeführt werden. Virtuelle Ethernet-Adapter sind Intel 82574L. Hardware-Ethernet-Adapter sind BCM5719. - Chris Stankevitz
@David Schwartz "Empfangsfenster-Autotuning Level" ist normal bei beiden und "Window Scaling Heuristiken" sind deaktiviert (siehe aktualisierte Konfiguration in OP). Ich glaube, das deutet darauf hin, dass Tuning nicht ist beschränkt. - Chris Stankevitz
Ich glaube nicht, dass diese Frage meinungsbezogen sein würde, ich denke, das eigentliche Problem damit, dass eine gute Antwort erfordert, würde ein Debugging der Systeme / Netzwerke des OP erfordern, was nur von ihm und nicht von uns gemacht werden kann . - peterh


Antworten:


Ich habe dies als ein fahrerspezifisches Problem gesehen. in meinem Fall mit QLogic-Netzwerkcontrollern, die versuchten, TCPChimney zu verwenden. Dieser Link beschreibt die TCPChimney-Funktionalität, die in Windows 2008 hinzugefügt wurde - aber ich bin mir ziemlich sicher, dass es immer noch gilt: https://support.microsoft.com/en-us/kb/951037

Ich würde empfehlen, das Folgende in der Reihenfolge zu testen; Überprüfen Sie nach jedem Test, ob der Empfänger die TCP-RWIN wie erwartet erhöht.

1) Laden Sie die neuesten Versionen der Treiber für den Netzwerkadapter auf dem empfangenden Computer. 1) Deaktivieren Sie TCPChimney auf dem empfangenden Computer 2) Deaktivieren Sie alle 'TCP Receive' Offloading. Dies wäre in den erweiterten Einstellungen der Eigenschaften des Netzwerkadapters zu finden (derselbe Bereich, in dem Geschwindigkeit und Duplex eingestellt wären) 3) Deaktivieren Sie alle 'TCP Send' Offloading (auch in den erweiterten Eigenschaften des Netzwerkadapters)

( Und im Gegensatz zu dem Kommentar "Und große TCP-Fenstergrößen über 65k sind schlecht für Server, da dann der Speicherbedarf für Verbindungen steigt. 65k allein könnten Sie auch nicht glücklich genug machen. - user303507 6. August 15 um 11:30", groß TCP-Empfangsfenster sind NICHT von Natur aus schlecht für den Server. Im Fall von Verbindungen mit hoher Bandbreite und hoher Latenz (wie z. B. Satellitenrelais) sind große RWIN-Werte erforderlich, damit wir mehr TCP-Daten "in der Pipeline" haben. Stellen Sie sich eine 600 Mbps Verbindung mit einer Latenz von 3000 ms vor. die Verbindung mit hoher Bandbreite würde auf ungefähr 20 KBps beschränkt sein, da nur 65 KB unverwurzelte TCP-Daten gleichzeitig "in der Leitung" sein könnten. )


1
2018-06-09 02:52





Sieht für mich wie ein Windows Autotuning Bug aus, vielleicht etwas damit zu tun? https://support.microsoft.com/en-us/kb/932170 

Haben Sie versucht, einen größeren SO_RCVBUF-Wert manuell mit WskControlSocket anzufordern?


0
2018-06-19 16:36



Technisch haben diese Puffer keine Beziehung zur TCP-Fenstergröße: stackoverflow.com/questions/14381303/increasing-tcp-window-size - Mary
Phil: Ich verwende Windows Server 2012 auf beiden Seiten, so dass die Verknüpfung nicht zutrifft, aber ich vermute einen Fehler. Ich kann ein größeres SO_RCVBUF anfordern - und das hilft - aber das hilft mir nicht zu verstehen, was kaputt ist (siehe "Update 2"). - Chris Stankevitz
Mary: Die Puffer sind indirekt mit der Fenstergröße verbunden. Der Netzwerkstapel erkennt die kleinen Puffer und erhöht folglich nicht die Fenstergröße. Ich beschreibe dies mit Handwaving in "Update 2". - Chris Stankevitz


Verwenden Sie einen Netzwerkoptimierer wie Cisco WAAS oder Riverbed. Sie machen lokale Acks schnell, so dass Sie sich nicht um die Servereinstellungen kümmern müssen. In größeren Netzwerken haben Sie sowieso keinen Einfluss auf das Server-Setup, da es sich um andere Teams handelt oder diese ausgelagert werden.


0
2017-08-06 11:28



Und große TCP-Fenstergrößen über 65k sind schlecht für Server, da dann der Speicherbedarf für Verbindungen steigt. 65k allein könnte dich auch nicht glücklich genug machen. - user303507
user303507: Ich möchte verstehen, was mit dem Windows Server 2012-Netzwerkstack passiert. Ich bin nicht daran interessiert, das Problem mit einer Netzwerk-Appliance zu maskieren. Aber ich stimme zu, dass das Kaufen einer Netzwerk-Appliance oder das Verschieben meiner Büros näher zusammen um dieses Problem geht. - Chris Stankevitz
Der Kommentar von user303507 könnte auf der richtigen Spur sein - Ich frage mich, ob der Speicherproblem dazu führt, dass Fenster die Fenstergröße aufgrund einiger unsichtbarer Heuristik- oder Registrierungseinstellungen einschränken. Nicht, dass dies ein angemessenes Verhalten ist, vorausgesetzt, Sie haben Recht bezüglich der Dokumentation. - Dan Pritts


Hier ist einige Informationen Ich habe festgestellt, dass dies die Antwort ist, nach der Sie suchen. Beachten Sie, dass die Erwähnung der 64 KB-Grenze im deaktivierten Modus ein Hinweis auf ähnliche Grenzwerte im normalen Modus sein kann, die nicht dokumentiert sind.

Versuchen Sie, den "experimentellen" Modus für astronomische Auto-Tuning-Ebenen zu aktivieren.

Wenn Sie Windows Auto-Tuning einstellen, können Sie die möglichen Einstellungen vornehmen   sind wie folgt:

  • normal: Standardwert, lässt das Empfangsfenster wachsen, um den meisten Bedingungen gerecht zu werden
  • disabled: Verwendet einen festen Wert für das TCP-Empfangsfenster. Begrenzt es auf 64 KB (begrenzt auf 65535).
  • highlyrestricted: lässt das Empfangsfenster sehr konservativ über den Standardwert hinaus wachsen
  • eingeschränkt: etwas eingeschränktes Wachstum des tcp-Empfangsfensters über seinen Standardwert hinaus
  • experimental: erlaubt das Empfangsfenster zu wachsen, um extremen Szenarien gerecht zu werden (nicht empfohlen, kann es die Leistung beeinträchtigen   häufige Szenarien, die nur für Forschungszwecke gedacht sind. Es aktiviert RWIN   Werte von über 16 MB)

0
2018-06-02 15:08



Das würde Sinn machen, aber das OP zeigt, dass er auf 64k begrenzt ist, nicht einmal auf 1024. - Jim B