Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

31.6. Optimisation des connexions UDP

download PDF

Avant de commencer à régler Red Hat Enterprise Linux pour améliorer le débit du trafic UDP, il est important d'avoir des attentes réalistes. UDP est un protocole simple. Comparé à TCP, UDP ne contient pas de fonctions telles que le contrôle de flux, le contrôle de congestion et la fiabilité des données. Il est donc difficile d'obtenir une communication fiable via UDP avec un débit proche de la vitesse maximale du contrôleur d'interface réseau (NIC).

31.6.1. Détection des chutes de paquets

Il existe plusieurs niveaux dans la pile du réseau dans lesquels le noyau peut laisser tomber des paquets. Red Hat Enterprise Linux fournit différents utilitaires pour afficher les statistiques de ces niveaux. Utilisez-les pour identifier les problèmes potentiels.

Notez que vous pouvez ignorer un très faible taux de paquets abandonnés. Cependant, si vous rencontrez un taux significatif, envisagez des mesures de réglage.

Note

Le noyau laisse tomber les paquets réseau si la pile réseau ne peut pas gérer le trafic entrant.

Procédure

  1. Identifier si le contrôleur d'interface réseau (NIC) laisse tomber des paquets :

    1. Affiche les statistiques spécifiques au NIC et au pilote : 

      # ethtool -S enp1s0
NIC statistics:
     ...
     rx_queue_0_drops: 17657
     ...

      La dénomination des statistiques et leur disponibilité dépendent de la carte réseau et du pilote.

    2. Affiche les statistiques de l'interface : 

      # ip -s link show enp1s0
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
    RX:   bytes  packets errors dropped  missed   mcast_
    84697611107 56866482      0   10904       0       0
    TX:   bytes  packets errors dropped carrier collsns_
     5540028184  3722234      0       0       0       0

      RX représente les statistiques des paquets reçus et TX des paquets transmis.

  2. Identifier les chutes de paquets spécifiques au protocole UDP dues à des tampons de socket trop petits ou à la lenteur du traitement de l'application : 

    # nstat -az UdpSndbufErrors UdpRcvbufErrors
#kernel
UdpSndbufErrors           4    0.0
UdpRcvbufErrors    45716659    0.0

    La deuxième colonne de la sortie énumère les compteurs.

Ressources supplémentaires

31.6.2. Test du débit UDP avec iperf3

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 les deux hôtes ne provoque un trafic réseau qui affecte substantiellement le résultat du test.
  • Facultatif : vous avez augmenté la taille maximale des sockets UDP sur le serveur et le client. Pour plus d'informations, reportez-vous à la section Augmentation des tampons de socket UDP à l'échelle du système.

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: 10000Mb/s

  2. Sur le serveur :

    1. Affichez la taille maximale du tampon de lecture de la socket UDP et notez la valeur : 

      # sysctl net.core.rmem_max
net.core.rmem_max = 16777216

      La valeur affichée est en octets.

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

      # firewall-cmd --add-port=5201/tcp --add-port=5201/udp
# firewall-cmd --reload

      Notez que iperf3 n'ouvre qu'un socket TCP sur le serveur. Si un client souhaite utiliser le protocole UDP, il se connecte d'abord à ce port TCP, puis le serveur ouvre un socket UDP sur le même numéro de port pour effectuer le test de débit du trafic UDP. Pour cette raison, vous devez ouvrir le port 5201 pour les protocoles TCP et UDP dans le pare-feu local.

    3. Démarrer iperf3 en mode serveur : 

      # iperf3 --server

      Le service attend maintenant les connexions entrantes des clients.

  3. Sur le client :

    1. Affichez l'unité de transmission maximale (MTU) de l'interface que le client utilisera pour la connexion au serveur et notez la valeur : 

      # ip link show enp1s0
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
...

    2. Affichez la taille maximale du tampon d'écriture de la socket UDP et notez la valeur : 

      # sysctl net.core.wmem_max
net.core.wmem_max = 16777216

      La valeur affichée est en octets.

    3. Commencez à mesurer le débit : 

      # iperf3 --udp --time 60 --window 16777216 --length 1472 --bitrate 2G --client 192.0.2.1
      • --udp: Utiliser le protocole UDP pour le test.
      • --time <seconds>: Définit le temps en secondes pendant lequel le client arrête la transmission.
      • --window <size>: Définit la taille de la mémoire tampon de la socket UDP. Idéalement, les tailles sont les mêmes sur le client et le serveur. Si elles sont différentes, réglez ce paramètre sur la valeur la plus petite : net.core.wmem_max sur le client ou net.core.rmem_max sur le serveur.
      • --length <size>: Définit la longueur de la mémoire tampon à lire et à écrire. Réglez cette option sur la plus grande charge utile non fragmentée. Calculez la valeur idéale comme suit : MTU - En-tête IP (20 octets pour IPv4 et 40 octets pour IPv6) - En-tête UDP de 8 octets.

      • --bitrate <rate>: Limite le débit à la valeur spécifiée en bits par seconde. Vous pouvez spécifier des unités, telles que 2G pour 2 Gbps.

        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 à laquelle les périphériques sur le chemin de transmission ou le client peuvent les traiter, les paquets peuvent être abandonnés.

      • --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         Jitter    Lost/Total Datagrams
[ 5] 0.00-60.00 sec  14.0 GBytes   2.00 Gbits/sec  0.000 ms  0/10190216 (0%) sender
[ 5] 0.00-60.04 sec  14.0 GBytes   2.00 Gbits/sec  0.002 ms  0/10190216 (0%) receiver

    Dans cet exemple, le débit moyen était de 2 Gbps et aucun paquet n'a été perdu.

  5. Sur le serveur :

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

    2. Fermer le port 5201 dans firewalld: 

      # firewall-cmd --remove-port=5201/tcp --remove-port=5201/udp
# firewall-cmd --reload

Ressources supplémentaires

  • iperf3(1) page de manuel

31.6.3. Impact de la taille du MTU sur le débit du trafic UDP

Si votre application utilise des messages UDP de grande taille, l'utilisation de trames jumbo peut améliorer le débit. Selon la norme IEEE 802.3, une trame Ethernet par défaut sans balise VLAN (Virtual Local Area Network) a une taille maximale de 1518 octets. Chacune de ces trames comprend un en-tête de 18 octets, ce qui laisse 1500 octets pour la charge utile. Par conséquent, pour chaque 1500 octets de données que le serveur transmet sur le réseau, 18 octets (1,2 %) sont des frais généraux.

Les trames jumbo sont des trames non standardisées dont l'unité de transmission maximale (MTU) est supérieure à la taille de la charge utile Ethernet standard de 1500 octets. Par exemple, si vous configurez des trames jumbo avec le MTU maximum autorisé de 9000 octets de charge utile, l'overhead de chaque trame est réduit à 0,2 %.

Important

Tous les dispositifs du réseau sur le chemin de transmission et les domaines de diffusion concernés doivent prendre en charge les trames jumbo et utiliser le même MTU. La fragmentation et le réassemblage des paquets dus à des paramètres MTU incohérents sur le chemin de transmission réduisent le débit du réseau.

Les différents types de connexion ont certaines limites MTU :

  • Ethernet : le MTU est limité à 9000 octets.
  • IP over InfiniBand (IPoIB) en mode datagramme : Le MTU est limité à 4 octets de moins que le MTU InfiniBand.
  • Les réseaux en mémoire prennent généralement en charge des MTU plus importants. Pour plus de détails, voir la documentation correspondante.

31.6.4. Impact de la vitesse de l'unité centrale sur le débit du trafic UDP

Dans les transferts de masse, le protocole UDP est beaucoup moins efficace que le protocole TCP, principalement en raison de l'absence d'agrégation de paquets dans le protocole UDP. Par défaut, les fonctions Generic Receive Offload (GRO) et Transmit Segmentation Offload (TSO) ne sont pas activées. Par conséquent, la fréquence de l'unité centrale peut limiter le débit UDP pour les transferts de masse sur les liaisons à haut débit.

Par exemple, sur un hôte réglé avec une unité de transmission maximale (MTU) élevée et des tampons de socket importants, une unité centrale de 3 GHz peut traiter le trafic d'une carte d'interface réseau de 10 GBit qui envoie ou reçoit du trafic UDP à pleine vitesse. Cependant, vous pouvez vous attendre à une perte de vitesse de 1 à 2 Gbps pour chaque 100 MHz de vitesse de CPU en dessous de 3 GHz lorsque vous transmettez du trafic UDP. De plus, si une vitesse de CPU de 3 GHz peut atteindre 10 Gbps, le même CPU limite le trafic UDP sur une carte réseau de 40 GBit à environ 20-25 Gbps.

31.6.5. Augmentation des tampons des sockets UDP dans l'ensemble du système

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 UDP 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 laisse tomber tout nouveau paquet UDP 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.

Important

La définition d'une taille de tampon trop importante entraîne un gaspillage de mémoire. Chaque socket peut être réglé sur 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 a besoin de 512 Go de RAM (512 KiB x 1 million) uniquement pour l'espace tampon de socket potentiel.

Conditions préalables

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

Procédure

  1. Créez le fichier /etc/sysctl.d/10-udp-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.core.rmem_max = 16777216
net.core.wmem_max = 16777216

    Spécifiez les valeurs en octets. Les valeurs indiquées dans cet exemple fixent la taille maximale des tampons à 16 Mio. Les valeurs par défaut des deux paramètres sont 212992 bytes (208 KiB).

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

    # sysctl -p /etc/sysctl.d/10-udp-socket-buffers.conf

  3. Configurez vos applications pour qu'elles utilisent des tampons de socket plus grands.

    Les paramètres net.core.rmem_max et net.core.wmem_max définissent la taille maximale de la mémoire tampon que la fonction setsockopt() d'une application peut demander. Notez que si vous configurez votre application pour ne pas utiliser la fonction setsockopt(), le noyau utilise les valeurs des paramètres rmem_default et wmem_default.

    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.

  4. Redémarrez les applications pour utiliser les nouvelles tailles de tampon UDP.

Vérification

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

Ressources supplémentaires

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.

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

© 2024 Red Hat, Inc.