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.

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.