Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

31.5. Optimisation des connexions TCP pour un débit élevé

Réglez les paramètres relatifs à TCP sur Red Hat Enterprise Linux afin d'augmenter le débit, de réduire la latence ou d'éviter les problèmes, tels que la perte de paquets.

31.5.1. Test du débit TCP à l'aide de iperf3
Copier lien

L'utilitaire iperf3 propose un mode serveur et un mode client pour effectuer des tests de débit réseau entre deux hôtes.

Note

Le débit des applications dépend de nombreux facteurs, tels que la taille des tampons utilisés par l'application. Par conséquent, les résultats mesurés à l'aide d'utilitaires de test, tels que iperf3, peuvent être sensiblement différents de ceux des applications sur un serveur soumis à une charge de travail de production.

Conditions préalables

  • Le paquet iperf3 est installé à la fois sur le client et sur le serveur.
  • Aucun autre service sur l'un ou l'autre hôte ne provoque un trafic réseau qui affecte substantiellement le résultat du test.
  • Pour les connexions à 40 Gbps et plus, la carte réseau prend en charge la fonction ARFS (Accelerated Receive Flow Steering) et cette fonction est activée sur l'interface.

Procédure

  1. Facultatif : Affichez la vitesse réseau maximale du contrôleur d'interface réseau (NIC) sur le serveur et le client : 

    # ethtool enp1s0 | grep "Speed"
   Speed: 100000Mb/s
    Copy to Clipboard Toggle word wrap

  2. Sur le serveur :

    1. Ouvrez temporairement le port TCP 5201 par défaut de iperf3 dans le service firewalld: 

      # firewall-cmd --add-port=5201/tcp
# firewall-cmd --reload
      Copy to Clipboard Toggle word wrap

    2. Démarrer iperf3 en mode serveur : 

      # iperf3 --server
      Copy to Clipboard Toggle word wrap

      Le service attend maintenant les connexions entrantes des clients.

  3. Sur le client :

    1. Commencez à mesurer le débit : 

      # iperf3 --time 60 --zerocopy --client 192.0.2.1
      Copy to Clipboard Toggle word wrap

      • --time <seconds>: Définit le temps en secondes pendant lequel le client arrête la transmission.

        Réglez ce paramètre à une valeur qui devrait fonctionner et augmentez-la lors des mesures ultérieures. Si le serveur envoie des paquets à une vitesse supérieure à celle que les dispositifs sur le chemin de transmission ou le client peuvent traiter, les paquets peuvent être abandonnés.

      • --zerocopy: Active une méthode de copie zéro au lieu d'utiliser l'appel système write(). Cette option n'est nécessaire que si vous souhaitez simuler une application à copie zéro ou atteindre 40 Gbps et plus sur un seul flux.
      • --client <server>: Active le mode client et définit l'adresse IP ou le nom du serveur qui exécute le serveur iperf3.

  4. Attendez que iperf3 termine le test. Tant le serveur que le client affichent des statistiques toutes les secondes et un résumé à la fin. Par exemple, voici un résumé affiché sur un client : 

    [ ID] Interval         Transfer    Bitrate         Retr
[  5] 0.00-60.00  sec  101 GBytes   14.4 Gbits/sec   0   sender
[  5] 0.00-60.04  sec  101 GBytes   14.4 Gbits/sec       receiver
    Copy to Clipboard Toggle word wrap

    Dans cet exemple, le débit moyen était de 14,4 Gbps.

  5. Sur le serveur :

    1. Appuyer sur Ctrl+C pour arrêter le serveur iperf3.

    2. Fermez le port TCP 5201 dans firewalld: 

      # firewall-cmd --remove-port=5201/tcp
# firewall-cmd --reload
      Copy to Clipboard Toggle word wrap

Les tampons de sockets stockent temporairement les données que le noyau a reçues ou doit envoyer :

  • Le tampon de lecture de la socket contient les paquets que le noyau a reçus mais que l'application n'a pas encore lus.
  • La mémoire tampon de la socket d'écriture contient les paquets qu'une application a écrits dans la mémoire tampon, mais que le noyau n'a pas encore transmis à la pile IP et au pilote de réseau.

Si un paquet TCP est trop volumineux et dépasse la taille de la mémoire tampon ou si les paquets sont envoyés ou reçus à un rythme trop rapide, le noyau abandonne tout nouveau paquet TCP entrant jusqu'à ce que les données soient retirées de la mémoire tampon. Dans ce cas, l'augmentation des tampons de la socket peut empêcher la perte de paquets.

Les paramètres du noyau de la mémoire tampon du socket net.ipv4.tcp_rmem (lecture) et net.ipv4.tcp_wmem (écriture) contiennent trois valeurs : 

net.ipv4.tcp_rmem = 4096  131072  6291456
net.ipv4.tcp_wmem = 4096  16384   4194304
Copy to Clipboard Toggle word wrap

Les valeurs affichées sont en octets et Red Hat Enterprise Linux les utilise de la manière suivante :

  • La première valeur est la taille minimale de la mémoire tampon. Les nouvelles sockets ne peuvent pas avoir une taille inférieure.
  • La deuxième valeur est la taille de la mémoire tampon par défaut. Si une application ne définit pas de taille de tampon, il s'agit de la valeur par défaut.
  • La troisième valeur est la taille maximale des tampons automatiquement réglés. L'utilisation de la fonction setsockopt() avec l'option de socket SO_SNDBUF dans une application désactive cette taille maximale de tampon.

Notez que les paramètres net.ipv4.tcp_rmem et net.ipv4.tcp_wmem définissent la taille des sockets pour les protocoles IPv4 et IPv6.

Les tampons de socket TCP à l'échelle du système stockent temporairement les données que le noyau a reçues ou doit envoyer. Les paramètres des tampons de socket net.ipv4.tcp_rmem (lecture) et net.ipv4.tcp_wmem (écriture) contiennent chacun trois paramètres : Une valeur minimale, une valeur par défaut et une valeur maximale.

Important

La définition d'une taille de tampon trop importante entraîne un gaspillage de mémoire. Chaque socket peut être défini à la taille demandée par l'application, et le noyau double cette valeur. Par exemple, si une application demande une taille de tampon de socket de 256 KiB et ouvre 1 million de sockets, le système peut utiliser jusqu'à 512 Go de RAM (512 KiB x 1 million) uniquement pour l'espace tampon de socket potentiel.

En outre, une valeur trop élevée pour la taille maximale de la mémoire tampon peut augmenter la latence.

Conditions préalables

  • Vous avez rencontré un taux important de paquets TCP abandonnés.

Procédure

  1. Déterminez la latence de la connexion. Par exemple, faites un ping entre le client et le serveur pour mesurer le temps moyen d'aller-retour (RTT) : 

    # ping -c 10 server.example.com
...
--- server.example.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 117.208/117.056/119.333/0.616 ms
    Copy to Clipboard Toggle word wrap

    Dans cet exemple, la latence est de 117 ms.

  2. Utilisez la formule suivante pour calculer le produit de retard de la bande passante (BDP) pour le trafic que vous souhaitez régler : 

    connection speed in bytes * latency in ms = BDP in bytes
    Copy to Clipboard Toggle word wrap

    Par exemple, pour calculer le BDP d'une connexion de 10 Gbps ayant une latence de 117 ms : 

    (10 * 1000 * 1000 * 1000 / 8) * 117 = 10683760 bytes
    Copy to Clipboard Toggle word wrap

  3. Créez le fichier /etc/sysctl.d/10-tcp-socket-buffers.conf et définissez la taille maximale de la mémoire tampon en lecture ou en écriture, ou les deux, en fonction de vos besoins : 

    net.ipv4.tcp_rmem = 4096 262144 21367520
net.ipv4.tcp_wmem = 4096 24576 21367520
    Copy to Clipboard Toggle word wrap

    Spécifiez les valeurs en octets. Utilisez la règle empirique suivante lorsque vous essayez d'identifier les valeurs optimales pour votre environnement :

    • Taille de la mémoire tampon par défaut (deuxième valeur) : N'augmentez que légèrement cette valeur ou fixez-la à 524288 (512 KiB) au maximum. Une taille de tampon par défaut trop élevée peut entraîner l'effondrement du tampon et, par conséquent, des pics de latence.
    • Taille maximale de la mémoire tampon (troisième valeur) : Une valeur double ou triple du BDP est souvent suffisante.

  4. Charger les paramètres du fichier /etc/sysctl.d/10-tcp-socket-buffers.conf: 

    # sysctl -p /etc/sysctl.d/10-tcp-socket-buffers.conf
    Copy to Clipboard Toggle word wrap

  5. Configurez vos applications pour qu'elles utilisent une taille de tampon de socket plus importante. La troisième valeur des paramètres net.ipv4.tcp_rmem et net.ipv4.tcp_wmem définit la taille maximale de la mémoire tampon que la fonction setsockopt() d'une application peut demander.

    Pour plus de détails, consultez la documentation du langage de programmation de votre application. Si vous n'êtes pas le développeur de l'application, contactez-le.

  6. Si vous avez modifié la deuxième valeur du paramètre net.ipv4.tcp_rmem ou net.ipv4.tcp_wmem, redémarrez les applications pour utiliser les nouvelles tailles de tampon TCP.

    Si vous n'avez modifié que la troisième valeur, il n'est pas nécessaire de redémarrer l'application car l'auto-tuning applique ces paramètres de manière dynamique.

Vérification

  1. Facultatif : Testez le débit TCP à l'aide de iperf3.

  2. Surveillez les statistiques de chute de paquets en utilisant la même méthode que celle utilisée lorsque vous avez rencontré les chutes de paquets.

    Si les chutes de paquets se produisent toujours, mais à un taux plus faible, augmentez encore la taille des tampons.

31.5.4. Mise à l'échelle des fenêtres TCP
Copier lien

La fonction TCP Window Scaling, qui est activée par défaut dans Red Hat Enterprise Linux, est une extension du protocole TCP qui améliore considérablement le débit.

Par exemple, sur une connexion de 1 Gbps avec un temps d'aller-retour (RTT) de 1,5 ms :

  • Lorsque l'option TCP Window Scaling est activée, un débit d'environ 630 Mbps est réaliste.
  • Lorsque la fonction TCP Window Scaling est désactivée, le débit descend à 380 Mbps.

L'une des caractéristiques du protocole TCP est le contrôle de flux. Avec le contrôle de flux, un expéditeur peut envoyer autant de données que le récepteur peut en recevoir, mais pas plus. Pour ce faire, le récepteur annonce une valeur window, qui est la quantité de données qu'un expéditeur peut envoyer.

À l'origine, le protocole TCP prenait en charge des fenêtres d'une taille maximale de 64 KiB, mais lorsque les produits de délai de bande passante (BDP) sont élevés, cette valeur devient une restriction car l'expéditeur ne peut pas envoyer plus de 64 KiB à la fois. Les connexions à haut débit peuvent transférer beaucoup plus de 64 KiB de données à la fois. Par exemple, une liaison de 10 Gbps avec une latence de 1 ms entre les systèmes peut avoir plus de 1 Mio de données en transit à un moment donné. Il serait inefficace qu'un hôte n'envoie que 64 KiB, puis fasse une pause jusqu'à ce que l'autre hôte reçoive ces 64 KiB.

Pour éliminer ce goulot d'étranglement, l'extension TCP Window Scaling permet de décaler arithmétiquement vers la gauche la valeur de la fenêtre TCP afin d'augmenter la taille de la fenêtre au-delà de 64 KiB. Par exemple, la plus grande valeur de fenêtre de 65535 est décalée de 7 places vers la gauche, ce qui permet d'obtenir une taille de fenêtre de près de 8 Mio. Cela permet de transférer beaucoup plus de données à un moment donné.

La mise à l'échelle des fenêtres TCP est négociée au cours de la poignée de main TCP à trois voies qui ouvre chaque connexion TCP. L'expéditeur et le destinataire doivent tous deux prendre en charge la mise à l'échelle de la fenêtre TCP pour que la fonction fonctionne. Si l'un ou l'autre des participants, ou les deux, n'annoncent pas la possibilité d'échelonner la fenêtre dans leur poignée de main, la connexion revient à la taille de fenêtre TCP originale de 16 bits.

Par défaut, TCP Window Scaling est activé dans Red Hat Enterprise Linux : 

# sysctl net.ipv4.tcp_window_scaling
net.ipv4.tcp_window_scaling = 1
Copy to Clipboard Toggle word wrap

Si TCP Window Scaling est désactivé (0) sur votre serveur, rétablissez la configuration de la même manière que vous l'avez définie.

31.5.5. Comment TCP SACK réduit le taux d'abandon des paquets
Copier lien

La fonction TCP Selective Acknowledgment (TCP SACK), qui est activée par défaut dans Red Hat Enterprise Linux (RHEL), est une amélioration du protocole TCP et augmente l'efficacité des connexions TCP.

Dans les transmissions TCP, le récepteur envoie un paquet ACK à l'expéditeur pour chaque paquet qu'il reçoit. Par exemple, un client envoie les paquets TCP 1 à 10 au serveur, mais les paquets 5 et 6 sont perdus. Sans TCP SACK, le serveur laisse tomber les paquets 7 à 10 et le client doit retransmettre tous les paquets à partir du point de perte, ce qui est inefficace. Lorsque la fonction TCP SACK est activée sur les deux hôtes, le client ne doit retransmettre que les paquets 5 et 6 perdus.

Important

La désactivation de TCP SACK réduit les performances et entraîne un taux d'abandon de paquets plus élevé du côté du destinataire dans une connexion TCP.

Par défaut, TCP SACK est activé dans RHEL. Pour vérifier : 

# sysctl net.ipv4.tcp_sack
1
Copy to Clipboard Toggle word wrap

Si TCP SACK est désactivé (0) sur votre serveur, rétablissez la configuration de la même manière que vous l'avez définie.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat