Le récepteur limite la taille de la fenêtre TCP à 64 512

34

Faits (veuillez identifier toute fausse déclaration):

J'ai une connexion à 100 Mbps entre deux sites distants de 80 ms
Il s’agit d’une connexion longue durée qui pourrait tirer parti d’une fenêtre TCP de grande taille, pouvant atteindre 100 Mbps * 0.08 sec = 1 000 000 octets.
Les deux ordinateurs exécutent Windows Server 2012. Le "niveau de réglage automatique de la fenêtre de réception" est normal sur les deux. Les "heuristiques de mise à l'échelle de la fenêtre" sont désactivées sur les deux.
J'ai couru "iperf -s" d'un côté et "iperf -c" de l'autre. Le transfert a eu lieu à 5 Mbps. J'obtiens le même résultat dans l'autre sens.
Les deux parties ont annoncé la prise en charge des fenêtres glissantes TCP dans leurs SYN.
Le destinataire a demandé une taille de fenêtre TCP de 64 512 octets (0xFC00) pendant toute la durée de l'exécution avec une valeur d'échelle de fenêtre TCP de "pas de décalage" (0x000).
Le réseau était capable de gérer une plus grande taille de fenêtre (voir les diagrammes de séquence ci-dessous)
Le récepteur a gardé la fenêtre plus petite que celle prise en charge par le réseau
Cette connexion se produit dans un VPN IPSEC. La MTU de l'interface de tunnel est réduite à 1400 octets dans les deux sens.

Question

Pourquoi le récepteur garde-t-il la fenêtre petite?

Non-réponses

Le réseau est cassé

Les machines Linux fonctionnant sur le même réseau ouvrent la fenêtre TCP à 1,5 Mo et transmettent des données à 6 fois la bande passante.
Les heuristiques de mise à l'échelle de la fenêtre sont activées

Les heuristiques de mise à l'échelle de la fenêtre sont désactivées (voir le résultat de la section "heuristique de l'interface de TCPH show" ci-dessous)
Le niveau de réglage automatique de la fenêtre de réception n'est pas normal

Le niveau de réglage automatique de la fenêtre de réception est normal (voir le résultat de "netsh interface tcp show global" ci-dessous)
Cela ne fonctionne tout simplement pas bien sur une machine virtuelle dans ESXi

Les performances sont 6 fois meilleures sur une machine virtuelle Linux exécutée sur le même hôte.

Mise à jour 1 12 juin 2015 16h30 HAP

J'ai modifié le test en mettant Linux sur un côté de la connexion. En effet, lorsque Linux envoie des données à Windows Server 2012, Windows offre une fenêtre de réception TCP trop petite (64 512 octets).

Lorsque j'envoie des données de Windows à Linux, Linux offre une fenêtre de réception TCP suffisamment grande (1 365 120 octets). Cependant, Windows limite les envois à environ 60 000 octets en vol.

Mise à jour 2 13 juin 2015 15h00 HAP

Un pas de plus vers la cause première. Dans ma configuration, ni SO_SNDBUF ni SO_RCVBUF ne sont définis (par iperf). Ce sont les tampons d'envoi et de réception qui lient efficacement la fenêtre de réception. Si vous ne spécifiez pas ces valeurs, Windows Server 2012 fournit une valeur par défaut de 64 Ko. Donc la question est maintenant:

Question

Si aucun n'est spécifié, pourquoi Windows Server 2012 n'augmente-t-il pas de manière dynamique SO_SNDBUF / SO_RCVBUF afin de prendre en charge les canaux de communication longs, comme décrit dans MSDN ?

Non-réponses

"netsh winsock show autotuning" est désactivé

C'est activé.

Mise à jour 3 le 24 août 2015 16h00 HAP

netsh a apparemment été remplacé par Set-NetTCPSetting et sa famille. Get-NetTCPSetting combiné à Get-NetTCPConnection montre que je suis sous le régime "Internet" qui m'offre ces paramètres:

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

Paramètres TCP de l'expéditeur

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

SYN émetteur

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

Perspective de l'expéditeur du graphe de séquence entrez la description de l'image ici

Paramètres TCP du récepteur

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

Récepteur 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]

Perspective du récepteur du graphe de séquence entrez la description de l'image ici

Fenêtre TCP entrez la description de l'image ici

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

— Chris Stankevitz
source

1

Pouvez-vous s'il vous plaît ajouter la configuration exacte - soft ET matériel pertinent (carte réseau) pour les deux côtés?

— TomTom

1

On dirait que le réglage de la fenêtre est limité .

— David Schwartz

@TomTom Les deux machines sont des ordinateurs virtuels sous ESXi fonctionnant sous HP Proliant DL380 G5. Les adaptateurs Ethernet virtuels sont Intel 82574L. Les adaptateurs Ethernet matériels sont BCM5719.

— Chris Stankevitz

@ David Schwartz "le niveau de réglage automatique de la fenêtre de réception" est normal et les "méthodes heuristiques de mise à l'échelle de la fenêtre" sont désactivées (voir la configuration mise à jour dans OP). Je crois que cela indique que le réglage n'est pas restreint .

— Chris Stankevitz

2

Je ne pense pas que cette question reposerait sur l'opinion, je pense que le vrai problème avec cette réponse est qu'il faut déboguer les systèmes / réseaux du PO, ce qui ne peut être fait que par lui et pas par nous. .

— Peter dit de réintégrer Monica

1

J'ai vu cela comme un problème spécifique au conducteur; dans mon cas, avec les contrôleurs de réseau QLogic qui essayaient d'utiliser TCPChimney. Ce lien décrit les fonctionnalités de TCPChimney ajoutées à Windows 2008 - mais je suis à peu près sûr que cela s'applique toujours: https://support.microsoft.com/en-us/kb/951037

Je recommanderais de tester les éléments suivants, dans l'ordre; après chaque test, redémarrez et voyez si le récepteur commence à augmenter le TCP RWIN comme prévu.

1) Chargez les dernières versions des pilotes de la carte réseau sur l’ordinateur destinataire. 1) Désactivez TCPChimney sur l’ordinateur récepteur. 2) Désactivez tous les déchargements 'Réception TCP'. Cela se trouverait dans les paramètres avancés des propriétés de la carte réseau (la même zone que celle où la vitesse et le duplex seraient définis) 3) désactive tout déchargement «Envoi TCP» (également dans les propriétés avancées de la carte réseau)

(Et contrairement au commentaire "Et les grandes tailles de fenêtres TCP supérieures à 65k sont mauvaises pour les serveurs, car la demande en mémoire pour les connexions augmente. 65k seul pourrait également ne pas vous rendre assez heureux. - user303507 Le 6 août à 15h30", Les fenêtres de réception TCP de grande taille ne sont PAS intrinsèquement mauvaises pour le serveur. Connexion à 600 Mbits / s avec une latence de 3 000 ms; le lien à bande passante élevée serait limité à environ 20 kbit / s; dans la mesure où seulement 65 Ko de données TCP non acquises pouvaient être "en attente" à la fois.)

— Jason Walker
source

0

Ça ressemble à un bogue automatique de Windows, peut-être quelque chose à voir avec ça? https://support.microsoft.com/en-us/kb/932170

Avez-vous essayé de demander une valeur SO_RCVBUF plus grande manuellement à l'aide de WskControlSocket?

— Phil McKerracher
source

Techniquement, ces tampons n'ont pas de relation avec la taille de la fenêtre TCP: stackoverflow.com/questions/14381303/increasing-tcp-window-size

— Mary

Phil: J'utilise Windows Server 2012 des deux côtés pour que ce lien ne s'applique pas, mais je soupçonne un bogue. Je peux demander un plus grand SO_RCVBUF - et cela aide - mais cela ne m'aide pas à comprendre ce qui est cassé (voir "Mise à jour 2").

— Chris Stankevitz

Mary: les tampons sont indirectement liés à la taille des fenêtres. La pile réseau reconnaîtra les petits tampons et n'augmentera donc pas la taille de la fenêtre. Je décris cela en utilisant handwaving dans "Update 2".

— Chris Stankevitz

0

Utilisez un optimiseur de réseau tel que Cisco WAAS ou Riverbed. Ils effectuent rapidement des acks locaux, vous n'avez donc pas à vous soucier des paramètres du serveur. Dans un réseau plus grand, vous n’avez de toute façon aucune influence sur la configuration du serveur, car il s’agit d’autres équipes ou est externalisée.

— utilisateur303507
source

Et les grandes tailles de fenêtres TCP supérieures à 65 000 sont mauvaises pour les serveurs, car la demande en mémoire pour les connexions augmente. 65k seul pourrait aussi ne pas vous rendre assez heureux.

— user303507

user303507: Je souhaite comprendre ce qui se passe avec la pile réseau de Windows Server 2012. Je ne souhaite pas masquer le problème avec un appareil réseau. Mais je conviens que l'achat d'un appareil réseau ou le rapprochement de mes bureaux vont permettre de contourner ce problème.

— Chris Stankevitz

Le commentaire de user303507 est peut-être sur la bonne voie - je me demande si le problème de mémoire a pour conséquence que Windows limite la taille de la fenêtre en fonction de paramètres heuristiques ou de registre invisibles. Non pas que ce soit un comportement approprié, en supposant que vous ayez raison en ce qui concerne la documentation.

— Dan Pritts

0

Voici quelques informations que j'ai découvertes et qui pourraient bien être la réponse que vous recherchez. Notez que la mention de la limite de 64 Ko en mode désactivé peut indiquer des limites similaires en mode normal qui ne sont pas documentées.

Essayez d'activer le mode "expérimental" pour les niveaux astronomiques de réglage automatique.

Lors du réglage du niveau de réglage automatique de Windows, les paramètres possibles sont les suivants:

normal: valeur par défaut, permet à la fenêtre de réception de s'agrandir pour s'adapter à la plupart des conditions

disabled: utilise une valeur fixe pour la fenêtre de réception tcp. Le limite à 64 Ko (limité à 65 535).

hautement restreint: permet à la fenêtre de réception de se développer au-delà de sa valeur par défaut, de manière très conservatrice

restreint: croissance quelque peu restreinte de la fenêtre de réception tcp au-delà de sa valeur par défaut

experimental: permet à la fenêtre de réception de s’agrandir pour s’adapter à des scénarios extrêmes (non recommandée, elle peut dégrader les performances dans des scénarios courants, uniquement à des fins de recherche. Elle autorise des valeurs RWIN de plus de 16 Mo)

— Un terrain
source

Cela aurait du sens, mais l'OP indique qu'il est limité à 64k, pas même à 10h24.

— Jim B