Windows TCP Window Scaling Atteindre le plateau trop tôt

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

A lire :

Augmentation des performances côté émetteur pour la transmission à haut débit (High-BDP)

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

...

Ces algorithmes fonctionnent bien pour petits PEB et une fenêtre de réception plus petite de réception. Cependant, lorsque vous avez une connexion TCP avec une grande fenêtre de réception importante et une fenêtre de réception grand BDP comme la réplication de données entre deux serveurs situés sur un réseau à grande vitesse. Lien WAN avec une connexion de 100 d'aller-retour Ces algorithmes n'augmentent pas 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 dans ces situations, la pile TCP/IP de nouvelle génération inclut le TCP composé (CTCP). COMPOSÉ (CTCP). CTCP augmente de manière plus agressive la fenêtre d'envoi pour les des connexions avec des fenêtres de réception de grande taille et des BDP . Le CTCP tente de maximiser le débit sur ces types de connexions en surveillant le délai et les pertes. En outre, CTCP s'assure que son comportement n'ait pas d'impact négatif sur les autres connexions TCP.

...

Le protocole CTCP est activé par défaut sur les ordinateurs fonctionnant sous Windows Server 2008 et désactivé par par défaut sur les ordinateurs fonctionnant sous Windows Vista. Vous pouvez activer CTCP à l'aide de la commande netsh interface tcp set global congestionprovider=ctcp commandement. Vous pouvez désactiver CTCP avec la commande la commande netsh interface tcp set global congestionprovider=none commande.

Editer le 30/06/2014

pour voir si le CTCP est réellement activé

> netsh int tcp show global

d.h.

PO a déclaré :

Si j'ai bien compris, ce réglage augmente le taux de qui élargit la fenêtre d'encombrement plutôt que la taille maximale il peut atteindre

CTCP augmente de manière agressive la fenêtre d'envoi

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

Composé TCP

Les algorithmes existants qui empêchent une de submerger le réseau sont connus sous le nom de démarrage lent et de congestion. Ces algorithmes augmentent le nombre de segments que l'expéditeur peut envoyer, k l'expéditeur peut envoyer, appelée fenêtre d'envoi, lors de l'envoi initial de données sur la connexion et de l'envoi de données sur le réseau. données sur la connexion et lors de la récupération 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). L'évitement de la congestion augmente la fenêtre d'envoi de d'envoi d'un segment TCP complet pour chaque fenêtre complète de données qui est acquittée.

Ces algorithmes fonctionnent bien pour les médias LAN spe plus petites. Cependant, lorsque vous avez une connexion TCP avec une grande taille de fenêtre de réception et une grande largeur de bande, ces algorithmes fonctionnent bien pour les vitesses des médias du réseau local. de réception et un produit bande passante-délai important (bande passante et délai bande passante et un délai élevé), comme la réplication de données entre deux serveurs situés sur un réseau WAN à grande vitesse. sur une liaison WAN à grande vitesse avec un temps d'aller-retour de 100 ms, ces algorithmes n'augmentent pas la fenêtre d'envoi assez rapidement pour pour utiliser pleinement la bande passante de la connexion. Par exemple, sur une connexion de 1 Gigabit par seconde (Gbps) avec un temps d'aller-retour (RTT) de 100 ms, il peut Il faut compter jusqu'à une heure pour que la fenêtre d'envoi passe initialement au niveau de la fenêtre d'envoi. de la taille de la fenêtre annoncée par le récepteur et de se rétablir lorsque la fenêtre est trop grande. il y a des segments perdus.

Pour mieux utiliser la bande passante o dans ces situations, la pile TCP/IP de nouvelle génération comprend Composé TCP (CTCP). CTCP augmente de manière plus agressive la fenêtre d'envoi pour les pour les connexions avec des fenêtres de réception importantes et des produits bande passante-délai de la bande passante. CTCP tente de maximiser le débit sur ces types de connexions en la surveillance des variations de délai et des pertes . Le CTCP s'assure que son comportement n'a pas d'impact négatif sur les autres connexions TCP ne sont pas affectées par son comportement.

Lors des tests effectués en interne par Microsoft, les temps de sauvegarde des fichiers volumineux étaient les suivants ont été réduits de près de moitié pour une connexion à 1 Gbps avec un RTT de 50 ms. Les connexions avec un produit de retard de bande passante plus important peuvent avoir des encore plus performantes. CTCP et Receive Window Auto-Tuning fonctionnent ensemble pour l'utilisation de la liaison et peuvent se traduire par des performances substantielles. des gains de performance substantiels pour les connexions avec un produit de retard de bande passante important.

Clarifier le problème :

TCP a deux fenêtres :

• La fenêtre de réception : Le nombre d'octets restant dans la mémoire tampon. Il s'agit d'un contrôle de flux imposé par le récepteur. Vous pouvez voir la taille de la fenêtre de réception dans wireshark puisqu'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 de la connexion TCP annoncent leur fenêtre de réception, mais en général, celui qui vous intéresse est celui qui reçoit la majeure partie des données. Dans votre cas, il s'agit du "serveur" puisque le client télécharge vers le serveur.
• La fenêtre de congestion. Il s'agit d'un contrôle de flux imposé par l'expéditeur. Elle est gérée par le système d'exploitation et n'apparaît pas dans l'en-tête TCP. Elle contrôle la vitesse à laquelle les données sont 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 vite parce que la fenêtre d'envoi (alias la fenêtre de contrôle de la congestion) ne s'ouvre pas assez pour satisfaire le RWIN du récepteur. En bref, le récepteur dit "Donnez-moi plus", et lorsque Windows est l'expéditeur, il n'envoie pas assez vite.

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

Comment y remédier ?

Je ne sais pas. interface tcp set global congestionprovider=ctcp 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 fonctionnait pas. Donc, juste pour être sûr :

1. Avez-vous redémarré après avoir activé cette fonction ?
2. Le déchargement de la cheminée est-il activé ? Si c'est le cas, essayez de le désactiver à titre expérimental. Je ne sais pas exactement ce qui est déchargé lorsque cette option est activée, mais si le contrôle de la fenêtre d'envoi en fait partie, peut-être que congestionprovider n'a aucun effet lorsque cette option est activée... Je ne fais que supposer...
3. Par ailleurs, je pense que cela date d'avant Windows 7, mais vous pourriez 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 ces clés fonctionnent, il est probablement nécessaire de désactiver ctcp.
4. Encore une autre hypothèse, essayez de vérifier netsh interface tcp show heuristics . Je pense qu'il pourrait s'agir de RWIN, mais ce n'est pas précisé, alors essayez de désactiver ou d'activer cette fonction au cas où elle aurait un impact sur la fenêtre d'envoi.
5. Assurez-vous également que vos pilotes sont à jour sur votre client de test. Il se peut que quelque chose ne fonctionne pas.

Je ferais ces expériences avec toutes les fonctions de délestage désactivées pour commencer, afin d'éliminer la possibilité que les pilotes réseau réécrivent/modifient certaines choses (surveillez le processeur lorsque le délestage est désactivé). Les TCP_OFFLOAD_STATE_DELEGATED struct semble au moins impliquer que le délestage du CWnd est possible.

@Pat et @Kyle ont donné d'excellentes informations ici. Prêtez attention à l'article de @Kyle. explication des fenêtres de réception et d'envoi TCP, je pense qu'il y a eu une certaine confusion à ce sujet. Pour ajouter à la confusion, iperf utilise le terme "fenêtre TCP" avec l'expression "fenêtre TCP". -w qui est un terme ambigu en ce qui concerne la réception, l'envoi ou la fenêtre coulissante globale. Ce qu'il fait en réalité, c'est définir le tampon d'envoi de la socket pour la fenêtre coulissante -c (client) et le tampon de réception de la socket sur l'instance -s (serveur). Dans l'instance 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 le mentionne Kyle, le problème ne vient pas de la fenêtre de réception sur la machine Linux, mais de l'expéditeur qui n'ouvre pas suffisamment la fenêtre d'envoi. Ce n'est pas qu'elle ne s'ouvre pas assez vite, elle plafonne simplement à 64k.

La taille par défaut de la mémoire tampon de la socket sous Windows 7 est de 64k. Voici ce que dit la documentation à propos de la taille de la mémoire tampon du socket en relation avec le débit à エムエスディーエヌ

Lors de l'envoi de données sur une connexion TCP à l'aide de important de conserver une quantité suffisante de données en suspens (envoyées mais pas encore acquittées) dans TCP afin d'atteindre le meilleur débit le plus élevé. La valeur idéale de la quantité de données en suspens pour pour obtenir le meilleur débit pour la connexion TCP s'appelle le retard d'envoi idéal (ideal send backlog, ISB). d'envoi (ISB). La valeur ISB est fonction de la du produit bande passante-délai de la connexion TCP et de l'avance du récepteur. récepteur (et en partie de l'encombrement du réseau). réseau).

Ok, bla bla bla, maintenant on y va :

Les applications qui effectuent une requête d'envoi bloquante ou non bloquante à la fois s'appuient généralement sur la mise en mémoire tampon d'envoi interne de Winsock. à la fois s'appuient généralement sur la mise en mémoire tampon interne de Winsock pour atteindre un pour obtenir un débit décent. La limite du tampon d'envoi pour une connexion donnée est est contrôlée par l'option de socket SO_SNDBUF. Pour les requêtes d'envoi bloquantes et non bloquantes, l'option de socket méthode d'envoi non bloquante, la limite de la mémoire tampon d'envoi détermine données sont conservées en suspens dans la mémoire tampon de TCP . Si la valeur de l'ISB pour la connexion est supérieure à la limite de la mémoire tampon d'envoi, le débit atteint sur la la connexion ne sera pas optimal.

Le débit moyen de votre dernier test iperf utilisant la fenêtre 64k est de 5.8Mbps. Cela provient de Statistiques > Résumé dans Wireshark, qui compte tous les bits. Il est probable qu'iperf compte le débit de données TCP, qui est de 5,7 Mbps. Nous constatons la même performance avec le test FTP, ~5.6Mbps.

Le débit théorique avec un tampon d'envoi de 64k et un RTT de 91ms est de....5.5Mbps. C'est assez proche pour moi.

Si nous regardons votre test iperf avec une fenêtre de 1MB, le débit est de 88.2Mbps (86.2Mbps pour les données TCP). Le débit théorique avec une fenêtre de 1 Mo est de 87,9 Mbps. Encore une fois, c'est assez proche pour un travail gouvernemental.

Cela montre que le tampon de la socket d'envoi contrôle directement la fenêtre d'envoi et que celle-ci, associée à 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 affaire d'autotuning ? Windows 7 ne s'en charge-t-il pas automatiquement ? Comme nous l'avons 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 :

La mise en mémoire tampon dynamique des envois pour TCP a été ajoutée à Wind Server 2008 R2. Par défaut, la mise en mémoire tampon dynamique pour TCP est activée à moins qu'une application ne définisse l'option de socket SO_SNDBUF sur le socket sur le flux.

L'iperf utilise SO_SNDBUF lors de l'utilisation du -w de sorte que la mise en mémoire tampon dynamique des envois soit désactivée. Cependant, si vous n'utilisez pas l'option -w alors il n'utilise pas SO_SNDBUF . La mise en mémoire tampon dynamique des envois 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. J'ai dû modifier le registre et fixer cette valeur à 0 :

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

Je ne pense pas que la désactivation de cette fonction soit utile ; il s'agit simplement d'une information complémentaire.

Pourquoi votre tampon d'envoi ne s'étend-il pas au-delà des 64k par défaut lorsque vous envoyez des données à une machine Linux avec beaucoup de place dans la fenêtre de réception ? Excellente question. Les noyaux Linux disposent également d'une pile TCP à réglage automatique. Comme T-Pain et Kanye qui font un duo autotune ensemble, il se peut que cela ne sonne pas bien. Il se peut qu'il y ait un problème avec ces deux piles TCP autotunées qui se parlent.

Une autre personne J'ai eu un problème similaire au vôtre et j'ai pu le résoudre en modifiant le registre afin d'augmenter la taille du tampon d'envoi par défaut. Malheureusement, cela ne semble plus fonctionner, du moins cela n'a pas fonctionné pour moi lorsque j'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 se développer de manière dynamique, que peut faire une fille ?

Vous pouvez :

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

Clause de non-responsabilité : j'ai passé de nombreuses heures à faire des recherches sur ce sujet et il est correct au mieux de mes connaissances et de ma connaissance de Google. Mais je ne jurerais pas sur la tombe de ma mère (elle est encore en vie).

Une fois la pile TCP réglée, il se peut qu'un goulot d'étranglement subsiste au niveau de la couche Winsock. J'ai constaté que la configuration de Winsock (Ancillary Function Driver dans le registre) fait une énorme différence pour les vitesses de téléchargement (envoi de données au serveur) dans Windows 7. Microsoft a reconnu un bogue dans le réglage automatique de TCP pour les sockets non bloquants - exactement le type de socket utilisé par les navigateurs ;-)

Ajoutez une clé DWORD pour DefaultSendWindow et définissez-la sur BDP ou sur une valeur supérieure. 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 expérimenter différents réglages du niveau de la prise en utilisant la fonction Violoniste Proxy et commandes pour ajuster la taille des tampons des sockets 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 toutes les analyses dans les réponses, ce problème semble indiquer que vous utilisez Windows7/2008R2 aka Windows 6.1.

La pile réseau (TCP/IP et Winsock) de Windows 6.1 était terriblement défectueuse et comportait toute une série de bogues et de problèmes de performance que Microsoft a fini par résoudre au fil de nombreuses années de corrections depuis la sortie initiale de la version 6.1.

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

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

Vous devez également comprendre comment fonctionnent les trains de correctifs LDR/GDR dans Windows 6.1.

J'avais l'habitude de maintenir ma propre liste de correctifs LDR (pas seulement les correctifs de la pile réseau) pour Windows 6.1 et d'appliquer ces correctifs de manière proactive à tous les serveurs/clients Windows 6.1 que je rencontrais. La vérification régulière des nouveaux correctifs LDR prenait beaucoup de temps.

Heureusement, Microsoft a mis fin à la pratique des correctifs LDR avec les nouvelles versions du système d'exploitation et les corrections de bogues sont désormais disponibles par le biais des services de mise à jour automatique de Microsoft.

MISE À JOUR : Un exemple parmi d'autres de bogues de 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-us/kb/2780879