Windows TCP Mise à l'échelle de la fenêtre Atteindre le plateau trop tôt

Question

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

Le rapport initial était que les téléchargements vers une nouvelle instance de serveur étaient beaucoup plus lents qu'ils ne pouvaient l'être. Cela s'est confirmé dans les tests et sur plusieurs sites; les clients voyaient l'hôte 2-5Mbit/s stable à partir de leurs systèmes Windows.

J'ai éclaté iperf -s sur une instance AWS, puis à partir d'un client Windows au 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 des tests ultérieurs (Vagaries of AWS), mais se situe généralement entre 70 et 130 Mbit/s, ce qui est plus que suffisant pour nos besoins. En partageant 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 64 ko, échelle 1 - Linux SYN, ACK: fenêtre 14 ko, échelle: 9

De toute évidence, le lien peut soutenir ce débit élevé, mais je dois explicitement définir la taille de la fenêtre pour en faire usage, ce que la plupart des applications du monde réel ne me laisseront pas faire. Les poignées de main TCP utilisent les mêmes points de départ dans chaque cas, mais celle forcée évolue

Inversement, à partir d'un client Linux sur le même réseau, une ligne droite, iperf -c (en utilisant le système par défaut 85kb) 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 aucun forçage, il évolue comme prévu. Cela ne peut pas être quelque chose dans les sauts intermédiaires ou nos commutateurs/routeurs locaux et semble affecter les clients Windows 7 et 8 de la même manière. J'ai lu de nombreux guides sur le réglage automatique, mais il s'agit généralement de désactiver complètement 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 quelque chose que je peux coller dans le registre via GPO.)

Remarques

L'instance AWS Linux en question a les paramètres de noyau suivants appliqués dans 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é dd if=/dev/zero | nc redirection vers /dev/null du côté serveur pour exclure iperf et supprimer tout autre goulot d'étranglement possible, mais les résultats sont sensiblement les mêmes. Les tests avec ncftp (Cygwin, Windows natif, Linux) évoluent à peu près de la même manière que les tests iperf ci-dessus sur leurs plates-formes respectives.

Éditer

J'ai repéré une autre chose cohérente ici qui pourrait être pertinente: enter image description here

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

Mise à jour - 30 juin.

Suivi des différentes réponses:

Activation du 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 de congestion est agrandie plutôt que la taille maximale qu'elle peut atteindre)
Activation de TCP. - Pas de changement ici non plus.
Algorithme de Nagle - Cela a du sens et au moins cela signifie que je peux probablement ignorer ces bips particuliers dans le graphique comme une indication du problème.
fichiers pcap: fichier Zip disponible ici: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.Zip (anonymisé avec bittwiste , extrait à ~ 150 Mo car il y en a un de chaque client OS pour comparaison)

Mise à jour 2 - 30 juin

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

---------------------------------------------- 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 une question de cause à effet ici, cependant: les graphiques sont de la valeur RWIN définie dans les ACK du serveur pour le client. Avec les clients Windows, ai-je raison de penser que Linux ne fait pas évoluer cette valeur au-delà de ce point bas car le CWIN limité du client empêche même le remplissage de ce tampon? Pourrait-il y avoir une autre raison pour laquelle Linux limite artificiellement le RWIN?

Remarque: j'ai essayé d'activer ECN pour l'enfer; mais pas de changement, là.

Mise à jour 3 - 31 juin.

Aucun changement après la désactivation de l'heuristique et de l'autoréglage RWIN. Avoir mis à jour les pilotes de réseau Intel vers la dernière version (12.10.28.0) avec un logiciel qui expose les onglets du gestionnaire de viadevice de tweaks de fonctionnalité. La carte est un chipset 82579V intégré NIC je vais faire d'autres tests auprès de clients avec realtek ou d'autres fournisseurs)

En me concentrant sur le NIC pendant un moment, j'ai essayé ce qui suit (principalement pour exclure les coupables improbables):

Augmentez les tampons de réception à 2k au lieu de 256 et transmettez les tampons à 2k à partir de 512 (les deux maintenant au maximum) - Aucun changement

Désactivé tous les déchargements de somme de contrôle IP/TCP/UDP. - Pas de changement.

Déchargement d'envoi volumineux désactivé - Nada.

Désactivé IPv6, planification QoS - Nowt.

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 (binaire cygwin) et --- (NTttcp .

Avec iperf, je devais spécifier explicitement -w1m sur les deux côtés avant que la connexion ne s'étende au-delà de ~ 5Mbit/s. (Incidemment, j'ai pu être vérifié et le BDP de ~ 5Mbits à une latence de 91ms est presque précisément 64kb. Repérez la limite ...)

Les binaires ntttcp montraient maintenant une telle limitation. En utilisant ntttcpr -m 1,0,1.2.3.5 sur le serveur et ntttcp -s -m 1,0,1.2.3.5 -t 10 sur 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

8 Mo/s le place aux niveaux que j'obtenais avec des fenêtres explicitement grandes dans iperf. Curieusement, cependant, 80 Mo dans 1273 tampons = un tampon de 64 Ko à nouveau. Un autre wirehark montre un bon RWIN variable revenant du serveur (facteur d'échelle 256) que le client semble remplir; alors peut-être que ntttcp déforme la fenêtre d'envoi.

Mise à jour 4 - 3 juillet

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

Deux autres iperf, à la fois de Windows vers le même serveur Linux qu'avant (1.2.3.4): un avec une taille de socket de 128 Ko et une fenêtre par défaut de 64 Ko (restreint à ~ 5 Mbit/s) et un avec un envoi de 1 Mo fenêtre et taille de socket par défaut de 8 Ko. (échelles plus élevées)
Une trace ntttcp du même client Windows vers une instance Server 2012R2 EC2 (1.2.3.5). ici, le débit évolue bien. Remarque: NTttcp fait quelque chose d'étrange sur le port 6001 avant d'ouvrir la connexion de test. Je ne sais pas ce qui se passe là-bas.
Une trace de données FTP, téléchargeant 20 Mo de /dev/urandom vers un hôte Linux presque identique (1.2.3.6) en utilisant Cygwin ncftp. Encore une fois, la limite est là. Le schéma est sensiblement le même avec Windows Filezilla.

La modification de la longueur du tampon iperf fait la différence attendue pour le graphique de séquence temporelle (sections beaucoup plus verticales), mais le débit réel est inchangé.

Pat · Answer

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

Lisez s'il vous plaît:

Augmentation des performances côté expéditeur pour la transmission à BDP élevé

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

...

Ces algorithmes fonctionnent bien pour les petits BDP et les tailles de fenêtre de réception plus petites. Cependant, lorsque vous avez une connexion TCP avec une grande taille de fenêtre de réception et un grand BDP , comme 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 ne le font pas augmentez la fenêtre d'envoi assez rapidement pour utiliser pleinement la bande passante de la connexion .

Pour mieux utiliser la bande passante des connexions TCP dans ces situations, la pile TCP/IP de nouvelle génération inclut le composé TCP (CTCP). CTCP augmente de façon plus agressive la fenêtre d'envoi pour les connexions avec des tailles de fenêtre de réception et des BDP de grande taille. Le CTCP tente de maximiser le débit sur ces types de connexions en surveillant les variations de retard et les pertes. De plus, CTCP garantit que son comportement n'affecte pas négativement les autres TCP connexions.

...

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 le netsh interface tcp set global congestionprovider=ctcp commande. Vous pouvez désactiver CTCP avec le netsh interface tcp set global congestionprovider=none commande.

Modifier 30/06/2014

pour voir si le CTCP est vraiment "activé"

> netsh int tcp show global

c'est à dire.

enter image description here

PO a dit:

Si je comprends bien, ce paramètre augmente le taux à dont la fenêtre de congestion est agrandie plutôt que la taille maximale il 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 envoi TCP d'envahir le réseau sont appelés démarrage lent et évitement de la congestion. Ces algorithmes augmentent la quantité de segments que l'expéditeur peut envoyer, connue sous le nom de 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. Un démarrage lent augmente la fenêtre d'envoi d'un segment complet TCP pour chaque segment d'accusé de réception reçu (pour TCP dans Windows XP et Windows Server 2003) ou pour chaque segment reconnu (pour TCP dans Windows Vista et Windows Server 2008). L'évitement de la congestion augmente la envoyer la fenêtre par un segment complet TCP pour chaque fenêtre complète de données qui est acquittée.

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

Pour mieux utiliser la bande passante des connexions TCP dans ces situations, la pile TCP/IP de nouvelle génération inclut Composé TCP (CTCP). CTCP augmente de manière plus agressive la fenêtre d'envoi pour les connexions avec de grandes tailles de fenêtre de réception et de grands produits à retard de bande passante. CTCP tente de maximiser le débit sur ces types des connexions en surveillant les variations de retard et les pertes . Le CTCP garantit également que son comportement n'affecte pas négativement les autres TCP connexions).

Lors des tests effectués en interne chez Microsoft, les temps de sauvegarde de gros fichiers ont été réduits de près de moitié pour une connexion à 1 Gbit/s avec un RTT de 50 ms. Les connexions avec un produit à retard de bande passante plus large peuvent avoir des performances encore meilleures. Le 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 performances substantiels pour les connexions de produits à large bande passante.

Kyle Brandt · Answer

Clarifier le problème:

TCP a deux fenêtres:

La fenêtre de réception: combien d'octets restent dans le tampon. Il s'agit du contrôle de flux imposé par le récepteur. Vous pouvez voir la taille de la fenêtre de réception dans le wirehark car elle est composée de la taille de la fenêtre et du facteur d'échelle de fenêtrage à l'intérieur de l'en-tête TCP. Les deux côtés du TCP la connexion annoncera leur fenêtre de réception, mais généralement celle qui vous intéresse est celle qui reçoit la majeure 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. Il s'agit du 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:

enter image description here

Mon analyse est que l'expéditeur n'envoie pas assez rapidement parce que la fenêtre d'envoi (aka la fenêtre de contrôle de congestion) ne s'ouvre pas assez pour satisfaire le RWIN du récepteur. Donc, en bref, le destinataire dit "Donnez-moi plus", et lorsque Windows est l'expéditeur, il n'envoie pas assez rapidement.

Cela est démontré par le fait que dans le graphique ci-dessus, le RWIN reste ouvert, et avec le temps d'aller-retour de 0,09 seconde et un RWIN de ~ 500 000 octets, nous pouvons nous attendre à un débit maximal en fonction du produit de retard de la bande passante (500000 /0.09) * 8 = ~ 42 Mbit/s (et vous n'obtenez qu'environ ~ 5 dans votre gain pour la capture Linux).

Comment le réparer?

Je ne sais pas. interface tcp set global congestionprovider=ctcp me semble la bonne chose à faire car cela augmenterait la fenêtre d'envoi (qui est un autre terme pour la fenêtre de congestion). Vous avez dit que cela ne fonctionnait pas. Il suffit donc de s'assurer:

Avez-vous redémarré après avoir activé cela?
Chimney est-il déchargé? Si c'est le cas, essayez de le désactiver comme expérience. Je ne sais pas exactement ce qui est déchargé lorsque cela est activé, mais si le contrôle de la fenêtre d'envoi en fait partie, peut-être que congestionprovider n'a aucun effet lorsque cela est activé ... Je suppose que ...
En outre, je pense que cela peut être antérieur à Windows 7, mais vous pouvez essayer d'ajouter et de jouer avec les deux clés de registre appelées DefaultSendWindow et DefaultReceiveWindow dans HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters. Si ceux-ci fonctionnent même, vous l'avez probablement désactivé.
Encore une autre supposition, essayez de vérifier netsh interface tcp show heuristics. Je pense que cela pourrait être RWIN, mais cela ne dit pas, alors peut-être jouer avec la désactivation/l'activation au cas où cela affecterait la fenêtre d'envoi.
Assurez-vous également que vos pilotes sont à jour sur votre client de test. Peut-être que quelque chose est juste cassé.

Je voudrais essayer toutes ces expériences avec toutes les fonctionnalités de déchargement pour éliminer la possibilité que les pilotes réseau effectuent une réécriture/modification des choses (gardez un œil sur le processeur pendant que le déchargement est désactivé). La struct TCP_OFFLOAD_STATE_DELEGATED semble au moins impliquer que le déchargement CWnd est au moins possible.

karyhead · Answer

Il y a eu d'excellentes informations ici par @Pat et @Kyle. Faites vraiment attention à @ Kyle's explication des TCP fenêtres de réception et d'envoi, je pense qu'il y a eu une certaine confusion à ce sujet. Pour confondre les choses, iperf utilise le terme "Fenêtre TCP" avec le -w paramètre qui est une sorte de terme ambigu en ce qui concerne la fenêtre coulissante de réception, d'envoi ou globale. En fait, il définit le tampon d'envoi de socket pour le -c (client) et le socket reçoivent le tampon sur le -s (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 sur la boîte Linux, mais l'expéditeur n'ouvre pas suffisamment la fenêtre d'envoi. Ce n'est pas qu'il ne s'ouvre pas assez rapidement, il plafonne simplement à 64k.

La taille par défaut du tampon de socket sur Windows 7 est de 64 Ko. Voici ce que dit la documentation sur la taille du tampon de socket par rapport au débit à MSDN

Lors de l'envoi de données via une connexion TCP à l'aide de sockets Windows, il est important de conserver une quantité suffisante de données en attente (envoyées mais pas encore reconnues) dans TCP in afin d'atteindre le débit le plus élevé. La valeur idéale pour la quantité de données en attente pour atteindre le meilleur débit pour la connexion TCP est appelée la taille idéale de backlog d'envoi (ISB). La valeur ISB est un fonction du produit de retard de bande passante de la TCP et la fenêtre de réception annoncée du récepteur (et en partie la quantité d'encombrement dans le réseau).

Ok, bla bla bla, maintenant c'est parti:

Les applications qui effectuent une demande d'envoi bloquante ou non bloquante à la fois s'appuient généralement sur la mise en mémoire tampon d'envoi interne par Winsock pour obtenir un débit décent. La limite de 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 bloquante et non bloquante, , la limite du tampon d'envoi détermine la quantité de données conservées en attente dans TCP . Si la valeur ISB de la connexion est supérieure à la limite de tampon d'envoi, le débit atteint sur la connexion ne sera pas optimal.

Le débit moyen de votre test iperf le plus récent à l'aide de la fenêtre 64k est de 5,8 Mbps. Cela vient de Statistiques> Résumé dans Wireshark, qui compte tous les bits. Probablement, iperf compte TCP débit de données 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 64k et un RTT de 91 ms est de 5,5Mbps. Assez proche pour moi.

Si nous regardons votre test iperf de fenêtre de 1 Mo, le débit est de 88,2 Mbps (86,2 Mbps pour seulement TCP). Le débit théorique avec une fenêtre de 1 Mo est de 87,9 Mbps. Encore une fois, assez proche pour le gouvernement travail.

Cela montre que le tampon de socket d'envoi contrôle directement la fenêtre d'envoi et que, couplé à 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.

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

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

iperf utilise SO_SNDBUF lors de l'utilisation de -w option, donc la mise en mémoire tampon d'envoi dynamique serait désactivée. Cependant, si vous n'utilisez pas -w alors il n'utilise pas SO_SNDBUF. La mise en mémoire tampon d'envoi dynamique doit ê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. J'ai dû faire un changement de registre et le mettre à 0:

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

Je ne pense pas que la désactivation de cela aidera; c'est juste un FYI.

Pourquoi votre tampon d'envoi ne dépasse-t-il pas les 64 Ko par défaut lors de l'envoi de données vers une boîte Linux avec beaucoup d'espace dans la fenêtre de réception? Grande question. Les noyaux Linux ont également un autoréglage TCP. Comme T-Pain et Kanye faisant un duo d'autoréglage ensemble, cela pourrait ne pas sembler bon. Peut-être y a-t-il un problème avec ces deux autoréglages TCP empile en se parlant.

ne autre personne a eu un problème comme le vôtre et a pu le corriger avec une modification du registre pour augmenter la taille du tampon d'envoi par défaut. Malheureusement, cela ne semble plus fonctionner, du moins ça ne m'a pas plu quand je l'ai essayé.

À ce stade, je pense qu'il est clair que le facteur limitant est la taille du tampon d'envoi sur l'hôte Windows. Étant donné qu'il ne semble pas être en croissance dynamique correctement, que doit faire une fille?

Vous pouvez:

Utilisez des applications qui vous permettent de définir le tampon d'envoi, c'est-à-dire l'option de fenêtre
Utilisez un proxy Linux local
Utiliser un proxy Windows distant?
Ouvrir un dossier avec Microsofhahahahahahaha
Bière

Avis de non-responsabilité: j'ai passé de nombreuses heures à faire des recherches à ce sujet et c'est correct au meilleur de ma connaissance et de google-fu. Mais je ne jurerais pas sur la tombe de ma mère (elle est toujours en vie).

LeslieM · Answer

Une fois que vous avez réglé la pile TCP 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) fait une énorme différence pour les vitesses de téléchargement ( pousser les données vers le serveur) dans Windows 7. Microsoft a reconnu un bogue dans l'autoréglage TCP pour les sockets non bloquants - juste le type de socket que les navigateurs utilisent ;-)

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

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

La modification du paramètre Winsock pour les téléchargements peut aider - ajoutez une clé pour DefaultReceiveWindow.

Vous pouvez tester différents paramètres de niveau de socket en utilisant les commandes Fiddler Proxy et pour ajuster les tailles de 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

Christoph Wegener · Answer

Après avoir lu toutes les analyses dans les réponses, ce problème ressemble beaucoup à ce que vous pourriez exécuter Windows7/2008R2 alias Windows 6.1

La pile de mise en réseau (TCP/IP et Winsock) dans Windows 6.1 était horriblement défectueuse et avait toute une série de bogues et de problèmes de performances que Microsoft a finalement résolus pendant de nombreuses années de correctifs depuis la version initiale de 6.1.

La meilleure façon d'appliquer ces correctifs consiste à passer au crible manuellement toutes les pages pertinentes sur support.Microsoft.com et à demander et télécharger manuellement les versions LDR des correctifs de la pile réseau (il y en a des dizaines).

Pour trouver 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'ai généralement utilisé pour maintenir ma propre liste de correctifs LDR (pas seulement les correctifs de la pile réseau) pour Windows 6.1, puis j'ai appliqué ces correctifs de manière proactive à n'importe quel serveur/client Windows 6.1 que j'ai rencontré. La vérification régulière des nouveaux correctifs LDR a été une tâche très longue.

Heureusement, Microsoft a arrêté la pratique des correctifs LDR avec les nouvelles versions du système d'exploitation et les correctifs sont désormais disponibles via les services de mise à jour automatique de Microsoft.

[~ # ~] mise à jour [~ # ~] : Juste un exemple de nombreux bogues 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 2 paquets SYN sont retransmis) https://support.Microsoft.com/en-us/kb/2780879

spricer · Answer

Je vois que c'est un post un peu plus ancien mais cela 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 l'activation ci-dessus.

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 a un impact négatif sur les RTT longs dans les connexions à haut débit. Vous pouvez également expérimenter avec l'option "restreinte" et "fortement restreinte".

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

jjspierx · Answer

Je rencontrais un problème similaire avec les clients Windows (Windows 7). J'ai effectué la plupart du débogage que vous avez effectué, désactivant l'algorithme Nagle, TCP Chimney Offloading, et des tonnes d'autres TCP changements de paramètres liés. Aucun d'eux n'avait aucun effet.

Ce qui m'a finalement corrigé, c'est 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 ont présenté le téléchargement lent et 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 contournement du Registre est nécessaire pour les ordinateurs avec certaines versions d'AFD.sys (désolé, ne me souviens pas des # de version).

HKLM\CurrentControlSet\Services\AFD\Parameters

Ajouter - DWORD - DefaultSendWindow

Valeur - décimale - 1640960

Cette valeur est quelque chose que j'ai trouvée 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 devez la 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 je comprends, le logiciel client devrait généralement remplacer ce paramètre dans le registre, mais s'il ne le fait pas, la valeur par défaut est utilisée et, apparemment, la valeur par défaut est très faible 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 de logiciels tiers (ex. Filezilla), je n'avais pas les mêmes ralentissements .

L'AFD.sys affecte toutes les connexions Winsock, donc ce correctif devrait s'appliquer au FTP, HTTP, HTTPS, etc ...

En outre, ce correctif a été répertorié ci-dessus également, donc je ne veux pas m'en attribuer le mérite s'il fonctionne pour n'importe qui, mais il y avait tellement d'informations dans ce fil que j'avais peur qu'il ait pu être ignoré.

Andr&#233; Fernandes · Answer

Eh bien, je suis moi-même tombé sur une situation similaire (ma question ici ), et à la fin j'ai dû désactiver TCP heuristique de mise à l'échelle, définir manuellement le profil de réglage automatique et activez 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.

wicksee · Answer

C'est un fil fascinant et correspond exactement aux problèmes que j'ai rencontrés avec Win7/iperf pour tester le débit sur les longs tuyaux gras.

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

interface netsh tcp set global autotuninglevel = experimental

NB: Avant de faire cela, assurez-vous d'enregistrer l'état actuel de l'autoréglage:

interface netsh tcp show global

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

Exécutez ensuite le serveur/client iperf à chaque extrémité du canal.

Réinitialisez la valeur de l'autoréglage 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.

Chris Stankevitz · Answer

Je n'ai pas assez de points pour commenter, donc je posterai une "réponse" à la place. J'ai ce qui semble être un problème similaire/identique (voir la question de défaut de serveur ici ). Mon (et probablement votre) problème est le tampon d'envoi du client iperf sur Windows. Il ne dépasse pas 64 Ko. Windows est censé agrandir dynamiquement 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 de votre graphique de mise à l'échelle de la fenêtre qui montre l'ouverture de la fenêtre jusqu'à 500 000 octets pour votre cas Windows "lent". Je m'attendais à voir ce graphique ouvert à seulement ~ 64 000 octets étant donné que vous êtes limité à 5 Mbps.