Problèmes connus liés aux performances TCP/IP

Note

Cet article est inclus dans une série en 3 parties. Vous pouvez consulter la partie 1 : Vue d’ensemble des performances TCP/IP et partie 2 : Problèmes de réseau sous-jacents de performances TCP/IP.

Cet article décrit les problèmes de performances TCP/IP suivants :

• Débit lent sur un réseau à latence élevée et à bande passante élevée
• Débit lent sur un réseau à faible latence et à bande passante élevée
• Problèmes réseau sous-jacents

Vitesse de débit lente sur un réseau à latence élevée et bande passante

Deux serveurs situés dans différents sites sont connectés sur un réseau à latence élevée. Le débit mesuré avec l’outil ctsTraffic est inférieur à la ligne de base.

Cela est dû au fait que l’option Échelle de fenêtre TCP n’est pas activée sur l’un ou l’autre serveur. Utilisez l’invite de commandes Windows ou Windows PowerShell pour activer l’option en définissant le niveau de mise en forme automatique de la fenêtre de réception TCP.

Utiliser l’invite de commandes pour activer le niveau de mise en forme automatique

Exécutez la commande suivante :

netsh int tcp set global autotuninglevel=normal 

Pour vérifier si le niveau de mise en forme automatique est activé, utilisez la commande suivante :

netsh int tcp show global

Utiliser PowerShell pour activer le niveau de réglage automatique

Exécutez la commande cmdlet de commande suivante :

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

Pour vérifier si le niveau de mise en forme automatique est activé, utilisez l’applet de commande suivante :

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*

Note

Il existe cinq niveaux pour la mise en forme automatique de la fenêtre de réception : Désactivé, Hautement restreint, Restreint, Normal et Expérimental. Pour plus d’informations sur la façon dont la mise en forme automatique affecte le débit, consultez Les cartes réseau de réglage des performances.

Vitesse de débit lente sur un réseau à faible latence et à bande passante élevée

Deux serveurs sont connectés sur un même réseau qui a une faible latence et une bande passante élevée. Lorsque vous créez une base de référence ou testez les performances TCP avec l’outil ctsTraffic, seuls les pics d’UC 0 dans un serveur processeur multicœur.

Ce problème se produit, car la fonctionnalité de mise à l’échelle côté réception (RSS) ou de file d’attente de machine virtuelle (VMQ) n’est pas activée ou n’est pas configurée correctement. Utilisez VMQ lorsque la machine physique est un hyperviseur. Si ce n’est pas le cas, activez RSS sur le système d’exploitation et sur les cartes réseau.

Note

Les cartes réseau sans fil ne prennent pas en charge les fonctionnalités RSS ou VMQ.

Activer RSS pour le système d’exploitation

Activez RSS à l’aide de l’invite de commandes ou de PowerShell comme suit :

Invite de commandes : netsh int tcp set global rss=enabled

PowerShell : Set-NetAdapterRss -Name <interface name> -Enabled $True

Activer RSS pour les cartes réseau

Tout d’abord, vérifiez si la fonctionnalité RSS est activée. Vérifiez les propriétés avancées de la carte réseau pour la configuration associée à l’aide de l’applet de commande suivante :

Get-NetAdapterAdvancedProperty | Where-Object -property RegistryKeyword -Like *rss* | format-table -AutoSize

Note

Les modifications apportées aux propriétés avancées peuvent entraîner une interruption ou une perte de connectivité réseau. Avant d’apporter les modifications, reportez-vous à la documentation du fournisseur de cartes réseau.

Procédez comme suit pour activer RSS pour les cartes réseau :

1. Exécutez ncpa.cpl pour ouvrir les connexions réseau.
2. Cliquez avec le bouton droit sur la connexion ciblée, puis sélectionnez Propriétés>configurées.
3. Sous l’onglet Avancé, recherchez la mise à l’échelle côté réception dans la liste des propriétés, puis définissez la valeur sur Activer.
4. Cliquez sur OK.

Rss peut également être activé à l’aide de l’applet de commande PowerShell :

Set-NetAdapterAdvancedProperty -Name <Interface name> -RegistryKeyword *RSS -RegistryValue 1

Problèmes réseau sous-jacents

Cette section explique comment rechercher les problèmes réseau sous-jacents lors de la mesure d’une ligne de base de débit ou de la résolution des problèmes de débit.

Pour obtenir une analyse du journal au niveau des paquets, vérifiez les problèmes réseau sous-jacents à l’aide d’un outil de capture de paquets réseau (tel que Microsoft Network Monitor, Wireshark ou ctsTraffic).

Étapes à suivre pour effectuer des journaux avec des outils de capture de paquets réseau

1. Démarrez la journalisation avec Microsoft Network Monitor ou Wireshark pour capturer le trafic sur les deux points de terminaison. Vous pouvez également utiliser l’outil de capture intégré Windows comme suit :

   1. Ouvrez l’invite de commandes en tant qu’administrateur.

   2. Exécutez la commande suivante :

      NETSH TRACE START CAPTURE=YES REPORT=DISABLED TRACEFILE=<FILEPATH>.ETL MAXSIZE=512
      

      Note

      Plusieurs captures peuvent être requises lors de l’utilisation de la netsh trace commande.

2. Exécutez l’outil CTStraffic.exe pour générer un fichier .csv.

3. Arrêtez la journalisation. Pour l’outil de capture intégré Windows, tapez NETSH TRACE STOP l’invite de commandes en tant qu’administrateur.

Analyser le fichier de capture

Voici un exemple montrant comment analyser un résultat filtré. Dans ce scénario, l’outil ctsTraffic utilise le modèle push (modèle par défaut), ce qui signifie que le paquet est envoyé du client au serveur.

1. Ouvrez le fichier de capture dans Microsoft Network Monitor.

2. Filtrez la trace réseau à l’aide du Property.TCPRetransmit==1 && tcp.Port==4444 filtre, qui localise les paquets de retransmission. Une retransmission de paquets signifie qu’un accusé de réception TCP de la séquence TCP donnée de l’expéditeur n’est jamais reçu.

   Note

   Pour analyser un fichier ETL, accédez à Outils>Options>Parser Profiles>Windows>Set As Active>OK.

   

   Comme illustré dans la capture d’écran, le frame #441 est retransmis deux fois, ce qui signifie qu’il est transmis par l’expéditeur trois fois. Utilisez le même numéro de séquence TCP (2278877548) pour identifier cette trame.

3. Cliquez avec le bouton droit sur SequenceNumber dans Les détails du cadre, puis sélectionnez Ajouter une valeur sélectionnée pour afficher le filtre.

   

4. Désactivez le filtre précédent en ajoutant « // » comme suit :

   

5. Sélectionnez Appliquer. La séquence TCP complète avec ce numéro de séquence s’affiche comme suit :

   

   Ce résultat montre que le frame #441 d’origine n’est pas reçu par le serveur et qu’il est retransmise par l’expéditeur. La retransmission d’une trame se produit si aucun accusé de réception de la séquence n’est reçu. Pour comprendre le fonctionnement de TCP, consultez l’établissement d’une liaison tridirectionnel via TCP/IP et description des fonctionnalités TCP Windows. Ensuite, copiez le TCP.SequenceNumber == <value> filtre de séquence à partir de la trace du client et collez-le sur la trace du serveur.

   Sur le serveur, un seul paquet de la séquence donnée est reçu, comme indiqué dans le résultat suivant :

   

   Ce résultat prouve qu’il existe une perte de paquets de l’expéditeur vers le récepteur sur les périphériques réseau intermédiaires. Les paquets quittent l’expéditeur, mais n’atteignent jamais le destinataire. Il s’agit d’un problème lié à la mise en réseau sous-jacente et doit être résolu par les administrateurs réseau.

Performances de bouclage TCP

Avec la version de Windows Server 2019, le modèle de traitement de bouclage TCP/IP a été modifié pour résoudre certains goulots d’étranglement des performances qui existaient dans les versions précédentes de Windows. Cette section décrit les options de configuration disponibles pour modifier le comportement du traitement de bouclage TCP/IP.

Les paramètres de configuration sont disponibles via l’outil de configuration netsh. Chaque paramètre peut être défini individuellement pour IPv4 et IPv6. Les valeurs par défaut peuvent varier de différentes versions de Windows.

Note

Sur les ordinateurs Windows à usage général, les valeurs par défaut ne doivent pas être modifiées.

Si un développeur d’applications détermine que le chemin de données de bouclage est la cause racine des performances insuffisantes des applications, les commandes suivantes peuvent être utilisées pour adapter la configuration aux besoins individuels de l’application.

netsh int ipv6|ipv4 set gl loopbackexecutionmode=adaptive|inline|worker
netsh int ipv6|ipv4 set gl loopbackworkercount=<value>
netsh int ipv6|ipv4 set gl loopbacklargemtu=enable|disable

Explication

Loopbackexecutionmode
Worker

Dans ce mode, les paquets sont mis en file d’attente côté expéditeur et traités par un thread de travail côté récepteur. Ce mode favorise le débit par rapport à la latence.

Inline

Dans ce mode, le traitement est effectué dans le contexte des threads d’application à la fois côté expéditeur et récepteur. Ce mode favorise la latence par rapport au débit.

Adaptive

Les premiers paquets du flux de données traitent inline, puis les paquets sont différés vers les threads de travail. Ce mode tente d’équilibrer la latence et le débit.

Loopbackworkercount

Permet de configurer le nombre de threads de travail utilisés.

Loopbacklargemtu

Permet de configurer l’utilisation de grandes MTU, cela doit être activé.