Der Empfänger begrenzt die Größe des TCP-Fensters auf 64.512

34

Fakten (bitte identifiziere falsche Angaben):

Ich habe eine 100-Mbit / s-Verbindung zwischen zwei Standorten, die 80 ms voneinander entfernt sind
Dies ist eine lange, fette Verbindung, die von einer großen TCP-Fenstergröße von möglicherweise bis zu 100 Mbit / s * 0,08 s = 1.000.000 Byte profitieren kann
Auf beiden Computern wird Windows Server 2012 ausgeführt. "Automatische Optimierung des Empfangsfensters" ist auf beiden Computern normal. "Heuristik der Fensterskalierung" ist in beiden Fällen deaktiviert.
Ich habe "iperf -s" auf der einen Seite und "iperf -c" auf der anderen Seite ausgeführt. Die Übertragung erfolgte mit 5 Mbit / s. Ich bekomme das gleiche Ergebnis in die andere Richtung.
Beide Seiten kündigten Unterstützung für TCP-Schiebefenster in ihren SYNs an.
Der Empfänger forderte während des gesamten Laufs eine TCP-Fenstergröße von 64.512 Byte (0xFC00) mit einem TCP-Fensterskalierungswert von "no shift" (0x000) an.
Das Netzwerk war in der Lage, ein größeres Fenster zu handhaben (siehe Sequenzdiagramme unten)
Der Empfänger hielt das Fenster kleiner als das Netzwerk unterstützt
Diese Verbindung wird in einem IPSEC-VPN hergestellt. Die MTU der Tunnelschnittstelle wird in beide 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 6-fachen Bandbreite
Heuristiken zur Fensterskalierung sind aktiviert

Heuristiken der Fensterskalierung sind deaktiviert (siehe Ausgabe von "netsh interface tcp show heuristics" unten)
Der Auto-Tuning-Pegel im Empfangsfenster ist nicht normal

Der Auto-Tuning-Pegel im Empfangsfenster ist normal (siehe Ausgabe von "netsh interface tcp show global" unten).
Dies funktioniert auf einer virtuellen Maschine in ESXi einfach nicht gut

Auf einem virtuellen Linux-Computer, der auf demselben Host ausgeführt wird, ist die Leistung 6-mal höher.

Update 1. Juni 12, 2015, 16:30 Uhr PDT

Ich habe den Test geändert, indem ich Linux auf eine Seite der Verbindung gesetzt habe. Wenn Linux Daten an Windows Server 2012 sendet, bietet Windows ein zu kleines TCP-Empfangsfenster (64.512 Byte).

Wenn ich Daten von Windows an Linux sende, bietet Linux ein ausreichend großes TCP-Empfangsfenster (1.365.120 Byte). Windows beschränkt das Senden jedoch auf maximal ~ 60.000 Byte im Flug.

Update 2. Juni 13, 2015, 15:00 Uhr PDT

Der eigentlichen Ursache einen Schritt näher. 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 Sie diese Werte nicht angeben, gibt Windows Server 2012 einen Standardwert von 64 kB an. Die Frage ist also jetzt:

Frage

Wenn keiner angegeben ist, warum erhöht Windows Server 2012 SO_SNDBUF / SO_RCVBUF nicht dynamisch, um lange Fatpipes aufzunehmen, wie unter MSDN beschrieben ?

Nicht-Antworten

"netsh winsock show autotuning" ist deaktiviert

Es ist aktiviert.

Update 3. August 24, 2015, 16:00 Uhr PDT

netsh wurde anscheinend durch Set-NetTCPSetting und die Familie ersetzt. Get-NetTCPSetting in Kombination mit Get-NetTCPConnection zeigt, dass ich im "Internet" -Regime arbeite, das 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

Absender-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

Absenderperspektive des Sequenzdiagramms Bildbeschreibung hier eingeben

TCP-Einstellungen des Empfängers

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 Sequenzdiagramms Bildbeschreibung hier eingeben

TCP-Fenster Bildbeschreibung hier eingeben

windows-server-2012 tcp-window-scaling tcp-window

— Chris Stankevitz
quelle

1

Können Sie bitte die genaue Konfiguration hinzufügen - soft- UND hardwarerelevant (Netzwerkkarte) für beide Seiten?

— TomTom

1

Klingt so, als wäre die Fensteroptimierung eingeschränkt .

— David Schwartz

@TomTom Beide Computer sind VMs in ESXi, die auf HP Proliant DL380 G5 ausgeführt werden. Virtuelle Ethernet-Adapter sind Intel 82574L. Hardware-Ethernet-Adapter sind BCM5719.

— Chris Stankevitz

@David Schwartz "Receive Window Auto Tuning Level" ist bei beiden normal und "Window Scaling Heuristics" sind deaktiviert (siehe aktualisierte Konfiguration in OP). Ich glaube, das deutet darauf hin, dass die Abstimmung nicht eingeschränkt ist .

— Chris Stankevitz

2

Ich denke nicht, dass diese Frage meinungsbasiert ist, ich denke, das eigentliche Problem dabei ist, dass eine gute Antwort ein Debugging der Systeme / Netzwerke des OP erfordert, was nur von ihm und nicht von uns durchgeführt werden kann .

— Peter sagt, Monica

1

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

Ich würde empfehlen, Folgendes zu testen, um; Starten Sie nach jedem Test neu und prüfen Sie, ob der Empfänger die TCP-RWIN erwartungsgemäß erhöht.

1) Laden Sie die neuesten Versionen der Treiber für den Netzwerkadapter auf den empfangenden Computer. 1) Deaktivieren Sie TCPChimney auf dem empfangenden Computer. 2) Deaktivieren Sie alle 'TCP Receive'-Offloads. Dies finden Sie in den erweiterten Einstellungen der Eigenschaften des Netzwerkadapters (derselbe Bereich, in dem Geschwindigkeit und Duplex eingestellt werden).

(Und entgegen 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 06.08.15 um 11:30", Große TCP-Empfangsfenster sind von Natur aus NICHT schlecht für den Server. Bei Verbindungen mit hoher Bandbreite und hoher Latenz (wie Satellitenrelais) sind große RWIN-Werte erforderlich, damit mehr TCP-Daten "in der Pipe" sind 600-Mbit / s-Verbindung mit 3000-ms-Latenz; die Verbindung mit hoher Bandbreite wäre auf etwa 20 KBit / s begrenzt, da sich jeweils nur 65 KB nicht bestätigter TCP-Daten "in der Pipe" befinden könnten.)

— Jason Walker
quelle

0

Sieht für mich nach einem Windows-Autotuning-Fehler aus, vielleicht hat das 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?

— Phil McKerracher
quelle

Technisch gesehen 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, sodass der Link nicht zutrifft, aber ich vermute einen Fehler. Ich kann einen größeren SO_RCVBUF anfordern - und das hilft - aber das hilft mir nicht zu verstehen, was kaputt ist (siehe "Update 2").

— Chris Stankevitz

Mary: Die Puffer hängen indirekt mit der Fenstergröße zusammen. Der Netzwerkstapel erkennt die kleinen Puffer und vergrößert daher nicht das Fenster. Ich beschreibe dies mit der Handbewegung in "Update 2".

— Chris Stankevitz

0

Verwenden Sie einen Netzwerkoptimierer wie Cisco WAAS oder Riverbed. Sie erledigen lokale Aufgaben schnell, sodass Sie sich nicht um die Servereinstellungen kümmern müssen. In einem größeren Netzwerk haben Sie sowieso keinen Einfluss auf die Serverkonfiguration, da es sich um andere Teams handelt oder diese ausgelagert sind.

— user303507
quelle

Und große TCP-Fenstergrößen über 65 KB sind schlecht für Server, da dann der Speicherbedarf für Verbindungen steigt. 65k alleine könnten dich auch nicht glücklich genug machen.

— user303507

user303507: Ich möchte verstehen, was mit dem Windows Server 2012-Netzwerkstapel geschieht. Ich bin nicht daran interessiert, das Problem mit einer Netzwerk-Appliance zu maskieren. Ich bin jedoch damit einverstanden, dass der Kauf einer Netzwerk-Appliance oder die Annäherung meiner Büros dieses Problem umgeht.

— Chris Stankevitz

Der Kommentar von user303507 ist möglicherweise auf dem richtigen Weg - ich frage mich, ob die Speicherbedenken dazu führen, dass Fenster die Fenstergröße basierend auf einer unsichtbaren Heuristik- oder Registrierungseinstellung begrenzen. Nicht, dass dies ein angemessenes Verhalten ist, vorausgesetzt, Sie haben in Bezug auf die Dokumentation Recht.

— Dan Pritts

0

Hier sind einige Informationen, die ich entdeckt habe und die möglicherweise die Antwort sind, nach der Sie suchen. Beachten Sie, dass die Erwähnung des 64-KB-Grenzwerts im deaktivierten Modus möglicherweise ein Hinweis auf ähnliche Grenzwerte im normalen Modus ist, die nicht dokumentiert sind.

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

Beim Einstellen des Windows-Auto-Tuning-Levels sind folgende Einstellungen möglich:

normal: Standardwert, lässt das Empfangsfenster wachsen, um den meisten Bedingungen gerecht zu werden

disabled: Verwendet einen festen Wert für das TCP-Empfangsfenster. Beschränkt auf 64 KB (begrenzt auf 65535).

stark eingeschränkt: Ermöglicht es dem Empfangsfenster, sehr konservativ über seinen Standardwert hinaus zu wachsen

restricted: Etwas eingeschränktes Wachstum des TCP-Empfangsfensters über den Standardwert hinaus

Experimentell: Das Empfangsfenster kann erweitert werden, um extremen Szenarien gerecht zu werden. (Nicht empfohlen, kann die Leistung in allgemeinen Szenarien beeinträchtigen, die nur zu Forschungszwecken verwendet werden. RWIN-Werte von über 16 MB sind möglich.)

— Ein Land
quelle

Das würde Sinn machen, aber das OP zeigt, dass er auf 64.000 begrenzt ist, nicht einmal um 1024.

— Jim B