Windows TCP Window Scaling Atteindre le plateau trop tôt

Scénario: Nous avons plusieurs clients Windows qui téléchargent régulièrement des fichiers volumineux (FTP / SVN / HTTP PUT / SCP) sur des serveurs Linux situés à environ 100 à 160 ms. Nous avons une bande passante synchrone de 1 Gbit / s au bureau et les serveurs sont des instances AWS ou hébergées physiquement dans des centres de distribution américains.

Le rapport initial indiquait que les téléchargements sur une nouvelle instance de serveur étaient beaucoup plus lents qu’ils ne le pourraient. Cela s'est avéré lors d'essais et à partir de plusieurs endroits; les clients voyaient une stabilité de 2 à 5 Mbit / s sur l'hôte à partir de leurs systèmes Windows.

J'ai éclaté iperf -ssur une instance AWS puis à partir d'un client Windows du bureau:

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

Ce dernier chiffre peut varier considérablement lors de tests ultérieurs (variables de AWS), mais se situe généralement entre 70 et 130 Mbit / s, ce qui est largement suffisant pour répondre à nos besoins. En chargeant la session, je peux voir:

• iperf -c Windows SYN - Fenêtre 64 Ko, échelle 1 - Linux SYN, ACK: Fenêtre 14 Ko, Échelle: 9 (* 512)
• iperf -c -w1M Windows SYN - Windows 64kb, échelle 1 - Linux SYN, ACK: fenêtre 14kb, échelle: 9

Il est clair que le lien peut supporter ce débit élevé, mais je dois définir explicitement la taille de la fenêtre pour pouvoir l'utiliser, ce que la plupart des applications du monde réel ne me permettent pas de faire. Les handshakes TCP utilisent les mêmes points de départ dans chaque cas, mais celui forcé

Réciproquement, à partir d’un client Linux sur le même réseau, un droit iperf -c(en utilisant le système par défaut de 85 Ko) me donne:

[  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

Sans forcer, il évolue comme prévu. Cela ne peut pas être quelque chose dans les sauts ou nos commutateurs / routeurs locaux et semble affecter les clients Windows 7 et 8. J'ai lu de nombreux guides sur le réglage automatique, mais ceux-ci concernent généralement la désactivation de la mise à l'échelle pour contourner le mauvais kit de réseau domestique.

Quelqu'un peut-il me dire ce qui se passe ici et me donner un moyen de le réparer? (De préférence, je peux me connecter au registre via GPO.)

Remarques

Les paramètres de noyau suivants sont appliqués dans l'instance AWS Linux en question sysctl.conf:

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

J'ai utilisé la dd if=/dev/zero | ncredirection vers /dev/nullle serveur pour iperféliminer et éliminer tous les goulots d'étranglement possibles, mais les résultats sont sensiblement les mêmes. Les tests avec ncftp(Cygwin, Windows natif, Linux) s’effectuent de la même manière que les tests iperf ci-dessus sur leurs plates-formes respectives.

Modifier

J'ai remarqué une autre chose cohérente ici qui pourrait être pertinente:

Il s’agit de la première seconde de la capture de 1 Mo agrandie. Vous pouvez voir le démarrage lent en action à mesure que la fenêtre s’agrandit et que la mémoire tampon s’agrandit. Il y a ensuite ce petit plateau de ~ 0,2s exactement au point où le test iperf par défaut de la fenêtre s’aplatit pour toujours. Celui-ci évolue bien sûr jusqu'à des hauteurs beaucoup plus vertigineuses, mais il est curieux qu'il y ait une pause dans la mise à l'échelle (les valeurs sont de 1022 octets * 512 = 523264) avant de le faire.

Mise à jour - 30 juin.

Suivi des différentes réponses:

• Activer le CTCP - Cela ne fait aucune différence. la mise à l'échelle de la fenêtre est identique. (Si je comprends bien, ce paramètre augmente la vitesse à laquelle la fenêtre d’encombrement est agrandie plutôt que la taille maximale qu’elle peut atteindre)
• Activation des horodatages TCP. - Pas de changement ici non plus.
• Algorithme de Nagle - Cela a du sens et au moins, cela signifie que je peux probablement ignorer ce blips particulier dans le graphique comme une indication du problème.
• Fichiers pcap: Le fichier Zip est disponible ici: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (anonymisé avec bittwiste, extraits à ~ 150 Mo comme indiqué ci-dessous. un de chaque client OS pour la comparaison)

Mise à jour 2 - 30 juin

O, donc après la suggestion de Kyle, j'ai activé ctcp et désactivé le déchargement de cheminées: Paramètres globaux TCP

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

Mais malheureusement, aucun changement dans le débit.

J'ai cependant une question de cause à effet ici: les graphiques correspondent à la valeur RWIN définie dans les ACK du serveur adressés au client. Avec les clients Windows, ai-je raison de penser que Linux ne redimensionne pas cette valeur au-delà de ce point bas, car le CWIN limité du client empêche même le remplissage de cette mémoire tampon? Pourrait-il y avoir une autre raison pour laquelle Linux limite artificiellement le RWIN?

Remarque: j'ai essayé d'allumer ECN pour le plaisir. mais pas de changement, là-bas.

Mise à jour 3 - 31 juin.

Aucune modification après la désactivation des heuristiques et du réglage automatique RWIN. Avoir mis à jour les pilotes de réseau Intel avec la dernière version (12.10.28.0) avec un logiciel exposant les onglets de la fonctionnalité ajustés au gestionnaire de viadevice. La carte est une carte réseau intégrée au jeu de puces 82579V - (je vais faire d'autres tests avec des clients de realtek ou d'autres fournisseurs)

En me concentrant un instant sur la carte réseau, j'ai essayé les solutions suivantes (principalement en éliminant les coupables improbables):

• Augmentez le nombre de tampons de réception de 256 à 2k et passez de 512 à 2k les tampons de transmission (les deux sont désormais au maximum) - Aucune modification.
• Désactiver tout le déchargement de la somme de contrôle IP / TCP / UDP. - Pas de changement.
• Désactivé Large envoi Déchargement - Nada.
• Désactivé IPv6, planification QoS - Maintenant.

Mise à jour 3 - 3 juillet

En essayant d'éliminer le côté serveur Linux, j'ai démarré une instance de Server 2012R2 et répété les tests en utilisant iperf(cygwin binary) et NTttcp .

Avec iperf, je devais préciser explicitement -w1msur les deux côtés avant que la connexion escaladeraient au - delà de ~ 5Mbit / s. (Incidemment, je pourrais être vérifié et le BDP de ~ 5 Mbits à une latence de 91 ms est presque à 64 kb. Trouvez la limite ...)

Les fichiers binaires ntttcp ont maintenant montré une telle limitation. En utilisant ntttcpr -m 1,0,1.2.3.5sur le serveur et ntttcp -s -m 1,0,1.2.3.5 -t 10sur le client, je peux voir un débit bien meilleur:

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

8Mo / s met en hausse au niveau que je recevais avec des fenêtres explicitement dans les grandes iperf. Bizarrement, cependant, 80 Mo sur 1273 mémoires tampon = une mémoire tampon de 64 Ko à nouveau. Une autre liste de fils montre un bon RWIN variable renvoyé par le serveur (facteur d'échelle 256) que le client semble remplir; alors peut-être que ntttcp fait une mauvaise déclaration de la fenêtre d'envoi.

Mise à jour 4 - 3 juillet

À la demande de @ karyhead, j'ai effectué d'autres tests et généré quelques captures supplémentaires, à l' adresse suivante : https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

• Deux secondes supplémentaires iperf, toutes deux de Windows vers le même serveur Linux qu'auparavant (1.2.3.4): une avec une taille de socket de 128 Ko et une fenêtre par défaut de 64 Ko (limitée à environ 5 Mbit / s) et une avec une fenêtre d'envoi de 1 Mo et un socket de 8 Ko par défaut Taille. (échelles plus élevées)
• Une ntttcptrace du même client Windows vers une instance Server 2012R2 EC2 (1.2.3.5). ici, le débit varie bien. Remarque: NTttcp fait quelque chose d'étrange sur le port 6001 avant d'ouvrir la connexion de test. Pas sûr de ce qui se passe là-bas.
• Une trace de données FTP, en téléchargeant 20 Mo /dev/urandomsur un hôte Linux presque identique (1.2.3.6) à l’aide de Cygwin ncftp. Encore une fois la limite est là. Le schéma est sensiblement le même avec Windows Filezilla.

La modification de la iperflongueur de la mémoire tampon fait toute la différence attendue par rapport au graphe de séquence dans le temps (sections beaucoup plus verticales), mais le débit réel reste inchangé.

Avez-vous essayé d'activer Compound TCP (CTCP) dans vos clients Windows 7/8.

Lisez s'il vous plaît:

Augmentation des performances côté émetteur pour une transmission à haute densité BDP

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

...

Ces algorithmes fonctionnent bien pour les petits projets BDP et les fenêtres de réception plus petites. Toutefois, lorsque vous disposez d'une connexion TCP avec une grande taille de fenêtre de réception et un grand fichier BDP , telle que la réplication de données entre deux serveurs situés sur une liaison WAN haut débit avec un temps d'aller-retour de 100 ms , ces algorithmes n'augmentent pas la fenêtre d'envoi. assez rapide pour utiliser pleinement la bande passante de la connexion .

Pour utiliser au mieux la bande passante des connexions TCP dans ces situations, la pile TCP / IP de nouvelle génération inclut le protocole TCP (CTCP) composé. CTCP augmente de manière plus agressive la fenêtre d'envoi pour les connexions avec de grandes tailles de fenêtres de réception et BDP . CTCP tente de maximiser le débit de ces types de connexion en surveillant les variations de retard et les pertes. De plus, CTCP veille à ce que son comportement n’affecte pas les autres connexions TCP.

...

CTCP est activé par défaut sur les ordinateurs exécutant Windows Server 2008 et désactivé par défaut sur les ordinateurs exécutant Windows Vista. Vous pouvez activer CTCP avec la netsh interface tcp set global congestionprovider=ctcpcommande. Vous pouvez désactiver CTCP avec la netsh interface tcp set global congestionprovider=nonecommande.

Modifier le 30/06/2014

pour voir si le CTCP est vraiment "allumé"

> netsh int tcp show global

c'est à dire

PO a déclaré:

Si je comprends bien, ce paramètre augmente le taux d’ agrandissement de la fenêtre d’encombrement plutôt que la taille maximale qu’elle peut atteindre.

CTCP augmente agressivement la fenêtre d'envoi

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

TCP composé

Les algorithmes existants qui empêchent un homologue TCP émetteur de submerger le réseau sont appelés démarrage lent et évitement de congestion. Ces algorithmes augmentent la quantité de segments que l'expéditeur peut envoyer, appelée fenêtre d'envoi, lors de l'envoi initial de données sur la connexion et lors de la récupération à partir d'un segment perdu. Le démarrage lent augmente la fenêtre d'envoi d'un segment TCP complet pour chaque segment d'accusé de réception reçu (pour TCP dans Windows XP et Windows Server 2003) ou pour chaque segment acquitté (pour TCP dans Windows Vista et Windows Server 2008). La prévention des encombrements augmente la fenêtre d'envoi d'un segment TCP complet pour chaque fenêtre complète de données acquittée.

Ces algorithmes fonctionnent bien pour les vitesses de média LAN et les tailles de fenêtre TCP plus petites. Toutefois, lorsque vous disposez d'une connexion TCP avec une grande taille de fenêtre de réception et un produit à délai de bande passante important (bande passante élevée et délai élevé), tel que la réplication de données entre deux serveurs situés sur une liaison WAN haut débit avec un aller-retour de 100 ms temps, ces algorithmes n'augmentent pas assez rapidement la fenêtre d'envoi pour utiliser pleinement la bande passante de la connexion. Par exemple, sur une liaison WAN de 1 Gigabit par seconde (Gbps) avec un temps d'aller-retour (RTT) de 100 ms, la fenêtre d'envoi peut prendre jusqu'à une heure pour augmenter initialement jusqu'à la grande taille annoncée par le récepteur et récupérer quand il y a des segments perdus.

Pour utiliser au mieux la bande passante des connexions TCP dans ces situations, la pile TCP / IP de nouvelle génération inclut le protocole TCP (CTCP) composé . CTCP augmente de manière plus agressive la fenêtre d'envoi pour les connexions avec des tailles de fenêtre de réception et des produits à délai de bande passante importants. CTCP tente de maximiser le débit de ces types de connexion en surveillant les variations de retard et les pertes . CTCP s'assure également que son comportement n'a pas d'impact négatif sur les autres connexions TCP.

Lors de tests effectués en interne chez Microsoft, les temps de sauvegarde des fichiers volumineux ont été réduits de près de moitié pour une connexion de 1 Gbps avec un RTT de 50 ms. Les connexions avec un produit à délai de bande passante plus important peuvent offrir des performances encore meilleures. CTCP et le réglage automatique de la fenêtre de réception fonctionnent ensemble pour une utilisation accrue des liaisons et peuvent entraîner des gains de performance substantiels pour les connexions de produits à délai de bande passante importante.

Clarifier le problème:

TCP a deux fenêtres:

• La fenêtre de réception: combien d'octets sont restés dans la mémoire tampon. C'est le contrôle de flux imposé par le récepteur. Vous pouvez voir la taille de la fenêtre de réception dans la grille de connexion car elle se compose de la taille de la fenêtre et du facteur de dimensionnement de la fenêtre dans l'en-tête TCP. Les deux côtés de la connexion TCP annonceront leur fenêtre de réception, mais généralement celui qui vous intéresse est celui qui reçoit la plus grande partie des données. Dans votre cas, c'est le "serveur" puisque le client télécharge sur le serveur
• La fenêtre de congestion. C'est le contrôle de flux imposé par l'expéditeur. Ceci est maintenu par le système d'exploitation et n'apparaît pas dans l'en-tête TCP. Il contrôle la vitesse à laquelle les données seront envoyées.

Dans le fichier de capture que vous avez fourni. Nous pouvons voir que le tampon de réception ne déborde jamais:

Mon analyse est que l'expéditeur n'envoie pas assez rapidement car la fenêtre d'envoi (ou fenêtre de contrôle d'encombrement) ne s'ouvre pas suffisamment pour satisfaire le RWIN du destinataire. En bref, le destinataire dit "Give me More" et lorsque Windows est l'expéditeur, l'envoi n'est pas assez rapide.

Ceci est démontré par le fait que dans le graphique ci-dessus, le RWIN reste ouvert et qu'avec un temps aller-retour de 0,09 seconde et un RWIN d'environ 500 000 octets, on peut s'attendre à un débit maximal en fonction du produit de délai de bande passante (500 000). /0.09) * 8 = ~ 42 Mbit / s (et vous ne gagnez qu'environ 5 dans votre victoire sur la capture sous Linux).

Comment le réparer?

Je ne sais pas. interface tcp set global congestionprovider=ctcpCela me semble être la bonne chose à faire car cela augmenterait la fenêtre d’envoi (qui est un autre terme pour la fenêtre d’encombrement). Vous avez dit que cela ne fonctionne pas. Alors juste pour être sûr:

1. Avez-vous redémarré après avoir activé cela?
2. La cheminée est-elle déchargée? Si c'est peut-être essayer de l'éteindre à titre d'expérience. Je ne sais pas ce qui se décharge exactement lorsque cette option est activée, mais si le contrôle de la fenêtre d'envoi est l'un d'entre eux, le fournisseur de congestion n'a peut-être aucun effet lorsque cette option est activée ... Je suppose que ...
3. En outre, je pense que cela pourrait être avant Windows 7, mais vous pouvez essayer d’ajouter et de jouer avec les deux clés de registre nommées DefaultSendWindow et DefaultReceiveWindow dans HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters. Si cela fonctionne même, vous avez probablement déjà été ctcp.
4. Encore une fois, essayez de vérifier netsh interface tcp show heuristics. Je pense que cela pourrait être RWIN, mais cela ne dit pas, alors jouez peut-être avec la désactivation / activation au cas où cela aurait un impact sur la fenêtre d’envoi.
5. Assurez-vous également que vos pilotes sont à jour sur votre client de test. Peut-être que quelque chose est juste cassé.

J'essaierais toutes ces expériences avec toutes vos fonctionnalités de déchargement pour éliminer la possibilité que les pilotes de réseau procèdent à une réécriture / modification de choses (gardez un œil sur le processeur lorsque le déchargement est désactivé). La structure TCP_OFFLOAD_STATE_DELEGATED semble au moins impliquer que le déchargement CWnd est au moins possible.

@Pat et @Kyle ont publié d'excellentes informations. Faites bien attention à l' explication de @ Kyle sur les fenêtres de réception et d'envoi TCP, je pense qu'il y a eu une certaine confusion autour de cela. Pour compliquer encore les choses, iperf utilise le terme "fenêtre TCP" avec le -wparamètre, qui est en quelque sorte un terme ambigu en ce qui concerne la fenêtre de réception, d'envoi ou glissante. En réalité, il définit le tampon d’envoi de socket pour l’ -cinstance (client) et le tampon de réception de socket sur l’ -sinstance (serveur). Dans 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 ));
}

Comme Kyle le mentionne, le problème ne vient pas de la fenêtre de réception sous Linux, mais l'expéditeur n'ouvre pas suffisamment la fenêtre d'envoi. Ce n'est pas que ça ne s'ouvre pas assez vite, mais juste à 64k.

La taille du tampon de socket par défaut sous Windows 7 est de 64 Ko. Voici ce que dit la documentation sur la taille de la mémoire tampon du socket en fonction du débit sur MSDN

Lors de l'envoi de données via une connexion TCP utilisant des sockets Windows, il est important de conserver une quantité suffisante de données en attente (envoyées mais pas encore acquittées) en TCP afin d'obtenir le débit le plus élevé. La valeur idéale pour la quantité de données en attente permettant d'obtenir le meilleur débit pour la connexion TCP est appelée taille idéale du carnet de commandes d'envoi (ISB). La valeur ISB est une fonction du produit délai-bande passante de la connexion TCP et de la fenêtre de réception annoncée du destinataire (et en partie de la quantité d'encombrement sur le réseau).

Ok, bla bla bla, maintenant on y va:

Les applications qui effectuent une demande d'envoi bloquante ou non bloquante à la fois dépendent généralement de la mise en mémoire tampon interne de l'envoi par Winsock pour obtenir un débit correct. La limite du tampon d'envoi pour une connexion donnée est contrôlée par l'option de socket SO_SNDBUF. Pour la méthode d'envoi bloquant et non bloquant, la limite du tampon d'envoi détermine la quantité de données restant en attente dans TCP . Si la valeur ISB de la connexion est supérieure à la limite du tampon d'envoi, le débit obtenu sur la connexion ne sera pas optimal.

Le débit moyen de votre dernier test iperf utilisant la fenêtre 64k est de 5,8 Mbps. Cela provient de Statistiques> Résumé dans Wireshark, qui compte tous les bits. Probablement, iperf compte le débit de données TCP qui est de 5,7 Mbps. Nous constatons également les mêmes performances avec le test FTP, ~ 5,6 Mbps.

Le débit théorique avec un tampon d’envoi de 64 Ko et un RTT de 91 ms est de ... 5,5 Mbps. Assez proche pour moi.

Si nous examinons votre test iperf sur une fenêtre de 1 Mo, le débit est de 88,2 Mbits / s (86,2 Mbits / s pour les données TCP uniquement). Le débit théorique avec une fenêtre de 1 Mo est de 87,9 Mbps. Encore une fois, assez proche pour le travail du gouvernement.

Cela montre que le tampon de socket d'envoi contrôle directement la fenêtre d'envoi et que, associé à la fenêtre de réception de l'autre côté, contrôle le débit. La fenêtre de réception annoncée a de la place, nous ne sommes donc pas limités par le récepteur.

Bravo, qu'en est-il de cette entreprise autotuning? Windows 7 ne gère-t-il pas ce genre de choses automatiquement? Comme il a été mentionné, Windows gère automatiquement la mise à l'échelle de la fenêtre de réception, mais il peut également gérer de manière dynamique le tampon d'envoi. Revenons à la page MSDN:

La mise en tampon d'envoi dynamique pour TCP a été ajoutée sous Windows 7 et Windows Server 2008 R2. Par défaut, la mise en tampon d'envoi dynamique pour TCP est activée sauf si une application définit l'option de socket SO_SNDBUF sur le socket de flux.

iperf utilise SO_SNDBUFlors de l'utilisation de l' -woption, de sorte que la mise en tampon d'envoi dynamique serait désactivée. Cependant, si vous n'utilisez pas, -walors il n'utilise pas SO_SNDBUF. La mise en tampon d'envoi dynamique devrait être activée par défaut, mais vous pouvez vérifier:

netsh winsock show autotuning

La documentation indique que vous pouvez le désactiver avec:

netsh winsock set autotuning off

Mais cela n'a pas fonctionné pour moi. Je devais faire un changement de registre et mettre ceci à 0:

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

Je ne pense pas que désactiver cela va aider; c'est juste un FYI.

Pourquoi votre mémoire tampon d'envoi ne dépasse-t-elle pas la valeur par défaut de 64 Ko lorsque vous envoyez des données à une machine Linux avec beaucoup d'espace dans la fenêtre de réception? Excellente question. Les noyaux Linux ont également une pile TCP autoréglable. Comme T-Pain et Kanye qui font un duo autotune ensemble, ça pourrait ne pas sembler bien. Peut-être qu'il y a un problème avec ces deux piles TCP autotuning qui se parlent.

Une autre personne a eu un problème similaire au vôtre et a été en mesure de le résoudre avec une modification du registre afin d’augmenter la taille du tampon d’envoi par défaut. Malheureusement, cela ne semble plus fonctionner, du moins cela ne m’a pas été pour moi lorsque j’ai essayé.

À ce stade, je pense qu'il est clair que le facteur limitant est la taille de la mémoire tampon d'envoi sur l'hôte Windows. Étant donné que cela ne semble pas se développer correctement de manière dynamique, que doit faire une fille?

Vous pouvez:

• Utilisez des applications qui vous permettent de définir l'option d'envoi de la mémoire tampon, c.-à-d.
• Utiliser un proxy Linux local
• Utiliser un proxy Windows distant?
• Ouvrir un cas avec Microsofhahahahahahaha
• Bière

Déni de responsabilité: J'ai passé de nombreuses heures à effectuer des recherches à ce sujet, ce qui est correct, autant que je sache, et google-fu. Mais je ne jurerais pas sur la tombe de ma mère (elle est toujours en vie).

Une fois que vous avez réglé la pile TCP, vous pouvez toujours avoir un goulot d'étranglement dans la couche Winsock. J'ai constaté que la configuration de Winsock (pilote de fonction auxiliaire dans le registre) influe considérablement sur les vitesses de téléchargement (envoi de données sur le serveur) dans Windows 7. Microsoft a reconnu l'existence d'un bogue dans l'optimisation automatique TCP pour les sockets non bloquantes. type de socket que les navigateurs utilisent ;-)

Ajoutez la clé DWORD pour DefaultSendWindow et définissez-la sur BDP ou supérieur. J'utilise 256000.

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

Modifier le paramètre Winsock pour les téléchargements peut être utile - ajoutez une clé pour DefaultReceiveWindow.

Vous pouvez expérimenter différents paramètres de niveau de socket en utilisant le proxy Fiddler et les commandes permettant de régler la taille de la mémoire tampon de socket client et serveur:

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

Après avoir lu toute l’analyse dans les réponses, ce problème donne l’impression que vous exécutez Windows7 / 2008R2, ou Windows 6.1.

La pile de mise en réseau (TCP / IP et Winsock) de Windows 6.1 était horriblement défectueuse et contenait toute une série de problèmes de performances et d’erreurs que Microsoft a finalement résolus au cours de nombreuses années de corrections à chaud depuis la version initiale 6.1.

Le meilleur moyen d'appliquer ces correctifs consiste à parcourir manuellement toutes les pages pertinentes sur support.microsoft.com et à demander et télécharger manuellement les versions LDR du correctif de la pile réseau (il en existe plusieurs dizaines).

Pour rechercher les correctifs pertinents, vous devez utiliser www.bing.com avec la requête de recherche suivante. site:support.microsoft.com 6.1.7601 tcpip.sys

Vous devez également comprendre le fonctionnement des trains de correctifs LDR / GDR dans Windows 6.1.

J'avais l'habitude de gérer ma propre liste de correctifs LDR (pas seulement les correctifs de pile réseau) pour Windows 6.1, puis de les appliquer de manière proactive à tout serveur / client Windows 6.1 que je rencontrais. Vérifier régulièrement la disponibilité de nouveaux correctifs LDR était une tâche très fastidieuse.

Heureusement, Microsoft a cessé d’appliquer les correctifs LDR avec les versions de système d’exploitation plus récentes et les corrections de bogues sont désormais disponibles via les services de mise à jour automatique de Microsoft.

UPDATE : Juste un exemple de nombreux bugs réseau dans Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785

MISE À JOUR 2 : voici un autre correctif qui ajoute un commutateur netsh pour forcer la mise à l'échelle de la fenêtre après la deuxième retransmission d'un paquet SYN (par défaut, la mise à l'échelle de la fenêtre est désactivée après la retransmission de 2 paquets SYN) https://support.microsoft.com/en- nous / kb / 2780879

Je vois que c'est un article un peu ancien, mais il pourrait aider les autres.

En bref, vous devez activer "Réglage automatique de la fenêtre de réception":

netsh int tcp set global autotuninglevel=normal

CTCP ne signifie rien sans ce qui précède est activé.

Si vous désactivez le "Réglage automatique de la fenêtre de réception", vous serez bloqué à une taille de paquet de 64 Ko, ce qui aura un impact négatif sur les RTT longs dans les connexions haut débit. Vous pouvez également expérimenter avec les options "restreint" et "hautement restreint".

Très bonne référence: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

Je rencontrais un problème similaire avec les clients Windows (Windows 7). J'ai effectué la plupart des opérations de débogage que vous avez suivies, en désactivant l'algorithme Nagle, le déchargement TCP Chimney et de nombreux autres changements de paramètres liés à TCP. Aucun d'entre eux n'a eu d'effet.

Ce qui a finalement été résolu pour moi, c’était la modification de la fenêtre d’envoi par défaut dans le registre du service AFD. Le problème semble être lié au fichier afd.sys. J'ai testé plusieurs clients, certains montraient le téléchargement lent, d'autres non, mais tous étaient des machines Windows 7. Les machines qui présentaient le comportement lent avaient la même version AFD.sys. La solution de registre est nécessaire pour les ordinateurs dotés de certaines versions de AFD.sys (désolé, ne rappelez pas les numéros de version).

HKLM \ CurrentControlSet \ Services \ AFD \ Parameters

Ajouter - DWORD - DefaultSendWindow

Valeur - Décimal - 1640960

Cette valeur est quelque chose que j'ai trouvé ici: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Je pense que pour utiliser la valeur appropriée, vous devriez le calculer vous-même en utilisant:

par exemple. Téléchargement annoncé: 15 Mbps = 15 000 Kbps

(15000/8) * 1024 = 1920000

D'après ce que j'ai compris, les logiciels clients devraient généralement remplacer ce paramètre dans le registre, mais s'ils ne le font pas, la valeur par défaut est utilisée et, apparemment, la valeur par défaut est très basse dans certaines versions du fichier AFD.sys.

J'ai remarqué que la plupart des produits MS avaient un problème de téléchargement lent (IE, Mini-redirecteur (WebDAV), FTP via l'Explorateur Windows, etc.). Lors de l'utilisation d'un logiciel tiers (ex. Filezilla), je n'avais pas les mêmes ralentissements. .

AFD.sys affecte toutes les connexions Winsock. Ce correctif doit donc s'appliquer à FTP, HTTP, HTTPS, etc.

En outre, ce correctif était également mentionné quelque part ci-dessus, aussi je ne veux pas en remercier tout le monde, mais ce fil de discussion contenait tellement d'informations que je craignais qu'il ait été dissimulé.

Eh bien, j’ai moi-même rencontré une situation similaire (ma question ici ), et j’ai finalement dû désactiver les méthodes heuristiques de mise à l’échelle de TCP, définir manuellement le profil de réglage automatique et activer le protocole 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. 

Je n'ai pas assez de points à commenter, je vais donc poster une "réponse" à la place. J'ai un problème qui semble être similaire / identique (voir la question serverfault ici ). Mon (et probablement votre) problème est le tampon d’envoi du client iperf sous Windows. Il ne dépasse pas 64 Ko. Windows est supposé développer de manière dynamique le tampon lorsqu'il n'est pas explicitement dimensionné par le processus. Mais cette croissance dynamique ne se produit pas.

Je ne suis pas sûr que votre graphique de redimensionnement de la fenêtre indique que la fenêtre s’ouvre jusqu’à 500 000 octets pour votre cas Windows "lent". Je m'attendais à voir ce graphique ouvert à environ 64 000 octets, sachant que vous êtes limité à 5 Mbps.

C’est un sujet fascinant qui correspond exactement aux problèmes que j’ai rencontrés avec Win7 / iperf pour tester le débit des tuyaux longs et gras.

La solution pour Windows 7 consiste à exécuter la commande suivante sur le serveur iperf ET le client.

netsh interface tcp set global autotuninglevel = expérimental

NB: Avant de faire cela, assurez-vous d’enregistrer le statut actuel de l’autotuning:

netsh interface tcp show global

Niveau de réglage automatique de la fenêtre de réception: désactivé

Ensuite, exécutez le serveur / client iperf à chaque extrémité du tuyau.

Réinitialisez la valeur de syntonisation automatique après vos tests:

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.