Pourquoi mon débit TCP est-il beaucoup plus élevé que le débit UDP?

Je n'ai rien fait d'inhabituel à mes configurations matérielles ou de noyau (tous les paramètres par défaut, nouvelle installation du système d'exploitation, pile TCP / IP du noyau Linux 3.11) et je fais en moyenne environ 3,83 millions de messages par seconde via TCP alors que je ne fais que 0,75 en moyenne millions de messages par seconde via UDP. Cela semble complètement défier ce que j'attends des deux protocoles.

Quelle est la cause la plus probable de la différence radicale et comment puis-je la diagnostiquer sur Ubuntu 13.10?

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304      64   10.00     7491010      0      383.5     28.97    24.751
212992            10.00     1404941              71.9     25.03    21.381

Pour ce test, j'ai deux serveurs de test identiques et directement connectés via un câble croisé 10G. Les cartes réseau utilisées dans ce cas sont des Intel X520 avec des configurations prêtes à l'emploi et connectées à un emplacement PCIe 3.0 x8 sur la carte mère, qui communique avec le CPU via un contrôleur NUMA.

— elleciel
source

Comment avez-vous établi les repères? Contre quoi vous avez envoyé ces colis?

— Braiam

J'ai utilisé netperfpour les tests de performances, les tests UDP_STREAM et TCP_STREAM, fixés sur le même CPU et des tailles de message de 64 octets.

— elleciel

Cela ne répond pas à la question de @ Braiam. La topologie du réseau est et la méthode de test détaillée est importante, ici.

— Pavel Šimerda

@ PavelŠimerda Désolé, je pensais qu'il ne demandait que la méthodologie de test. Concernant la topologie du réseau, les deux serveurs de test sont identiques et directement connectés via un câble croisé 10G. Les cartes réseau utilisées dans ce cas sont des Intel X520 avec des configurations prêtes à l'emploi et connectées à un emplacement PCIe 3.0 x8 sur la carte mère, qui communique avec le CPU via un contrôleur NUMA. Est-ce que cela répond à votre question?

— elleciel

Oui, @elleciel, cela répond définitivement à ma question. Bien que dans ce cas, je n'ai pas l'expertise pour vous donner la réponse pour les machines directement connectées. Je vois que vous avez modifié la question elle-même, ce qui est formidable. Sera la question comme maintenant je suis aussi intéressé.

— Pavel Šimerda

En plus de ne pas obtenir d'informations détaillées sur votre configuration de test, le principal problème semble être que vous utilisez une taille de message de 64 octets. Ceci est loin du MTU habituel de 1500 octets et rend UDP très inefficace: alors que TCP fusionne plusieurs envois en un seul paquet sur le câble (sauf si TCP_NODELAY est défini) pour utiliser efficacement le lien, chaque message UDP se traduira par un paquet séparé. En chiffres: environ 23 messages de taille 64 octets seront combinés en un seul paquet TCP de taille MTU, alors qu'il aura besoin de 23 paquets simples pour UDP pour la même quantité de données. Chacun de ces paquets signifie une surcharge avec l'envoi de l'hôte, la transmission sur le câble et la réception par l'homologue. Et comme dans votre cas, environ 80% des paquets UDP sont perdus car votre matériel n'est pas assez rapide pour transmettre et recevoir tous ces paquets.

Donc, ce que vous pouvez apprendre de cette référence est:

UDP n'est pas fiable (80% de perte de paquets)
UDP est inefficace s'il est utilisé avec des tailles de paquets bien inférieures à MTU
TCP est hautement optimisé pour tirer le meilleur parti du lien

Quant à votre attente, cet UDP devrait être meilleur: vous êtes-vous déjà demandé pourquoi tous les principaux transferts de fichiers (ftp, http, ...) sont effectués avec des protocoles basés sur TCP? La référence vous montre la raison.

Alors pourquoi les gens utilisent-ils UDP?

Avec les données en temps réel (par exemple la voix sur IP), vous ne vous souciez pas des messages plus anciens, vous ne voulez donc pas que l'expéditeur combine les messages en paquets plus gros pour utiliser efficacement le lien. Et vous acceptez plutôt qu'un paquet se perde plutôt que de le faire arriver trop tard.
Avec les liaisons à latence élevée (comme avec les satellites), le comportement par défaut de TCP n'est pas optimal pour utiliser efficacement la liaison. Dans ce cas, certaines personnes basculent vers UDP et réimplémentent la couche de fiabilité de TCP et l'optimisent pour les liaisons à latence élevée, tandis que d'autres ajustent la pile TCP existante pour mieux utiliser la liaison.
"jeter" les données: il est parfois plus important d'envoyer les données et de ne pas se soucier de la perte de paquets, comme avec les messages de journal (syslog)
Interactions courtes: avec TCP, vous devez établir une connexion et maintenir un état, ce qui coûte du temps et des ressources au client et au serveur. Pour les interactions courtes (comme les demandes et les réponses courtes), cela peut représenter une surcharge. À cause de cela, DNS se fait généralement avec UDP mais a construit des tentatives sur UDP.

— Steffen Ullrich
source

Vous devriez également consulter votre perte de paquets de 80% avec UDP. Il semble que votre matériel ne soit pas assez rapide pour traiter les paquets à la même vitesse qu'ils reçoivent. Alors que TCP s'adapte à ce type de perte de paquets avec ralentissement, UDP n'enverra que la même vitesse et continuera à perdre des paquets. Mais à la fin, ce n'est pas la vitesse à laquelle vous pouvez envoyer, mais ce que vous recevez.

— Steffen Ullrich

Une autre chose qui pourrait être un facteur est l'accélération / le déchargement TCP vers la carte réseau (si elle la prend en charge).

— cpugeniusmv

L'envoi de paquets peut être plus efficace que la réception, surtout si le dernier est piloté par interruption.

— Steffen Ullrich

les gens utilisent également UDP pour un périphérique intégré pour diffuser les données qu'il recueille sur un fil et ne se soucient pas de la configuration de la connexion

— ratchet freak

Vous êtes probablement IO lié par le bus PCI express. Le déchargement de segment TCP sera probablement activé sur les cartes réseau. Cela signifie que les transferts TCP seront envoyés à la carte comme un gros bloc, puis la carte les découpera en tranches et les mettra en paquets. Il n'y a pas d'équivalent pour UDP, donc le résultat est une transaction PCIe (et tous les frais généraux associés) pour chaque paquet.

— alex.forencich