Pourquoi ne devriez-vous pas appliquer la logique TCP à UDP

Tags:
Categories:
  • Pourquoi ne devriez-vous pas appliquer la logique TCP à UDP

Pourquoi ne devriez-vous pas appliquer la logique TCP à UDP ?

Différences structurelles

En-tête TCP
En-tête UDP

TCP comprend de nombreux concepts : établissement de chemin, utilisation des ressources, transmission de données, transmission fiable, retransmission basée sur l’acquittement cumulatif répété, retransmission sur expiration, somme de contrôle, contrôle de flux, contrôle de congestion, taille maximale de segment, accusé de réception sélectif, option d’échelle de fenêtre TCP, horodatage TCP, remise forcée de données, fin de chemin.

Toutes ces capacités sont fondamentalement absentes d’UDP, qui ne possède qu’une capacité de distinction des applications légèrement supérieure à celle de la couche de liaison. UDP est suffisamment simple pour être extrêmement flexible.

Si cela peut arriver, cela arrivera

Loi de Murphy :

S’il existe plus d’une façon de faire quelque chose, et que l’une de ces façons entraîne une catastrophe, quelqu’un choisira inévitablement cette méthode.

On dit souvent qu’UDP convient aux jeux, à la voix et aux vidéos, car quelques paquets erronés n’affectent pas l’activité. Pourquoi UDP convient-il à ces scénarios ? Le fait qu’UDP puisse être utilisé dans ces cas ne signifie pas qu’il s’agit de la solution optimale ; il doit y avoir des problèmes que TCP ne peut résoudre, ce qui pousse ces services à choisir le protocole UDP, malgré sa simplicité. Le fait que les paquets erronés n’affectent pas l’activité signifie simplement que TCP s’inquiète des paquets erronés, tandis qu’UDP ne s’en soucie pas, se concentrant davantage sur la transmission en temps réel et la continuité. UDP se distingue par son indifférence aux facteurs auxquels TCP accorde de l’importance, ces facteurs influençant la transmission en temps réel.

Dans l’implémentation du code, UDP nécessite simplement la création d’une socket et la liaison à un port pour commencer à envoyer et recevoir. Généralement, lorsque la socket est utilisée, le port l’est également.

Ainsi, je peux utiliser UDP de la manière suivante :

  1. Envoyer des paquets aléatoires à n’importe quel IP et n’importe quel port, pour voir quel port répond.
  2. L’expéditeur A envoie un paquet de requête du port A au port B du destinataire B ; B répond via le port C au port D de A.
  3. L’expéditeur A envoie un paquet de requête du port A au port B du destinataire B ; B délègue à C de répondre via le port C au port D de A.
  4. L’expéditeur A envoie un paquet de requête du port A au port B du destinataire B, mais modifie l’IP source du paquet pour celle de C ; B enverra alors la réponse à C.
  5. Les deux parties conviennent d’utiliser chacune 10 ports UDP, tout en recevant et en envoyant simultanément.

Ces méthodes sont naturellement impossibles avec TCP, mais avec le protocole UDP, tant que cela est faisable, quelqu’un le fera inévitablement. Par conséquent, appliquer la logique de TCP à UDP relève de l’idéalisme ; la réalité est souvent plus complexe que ce que nous pouvons énumérer.

L’en-tête UDP est très simple, et son utilisation est extrêmement flexible. À l’origine, il n’y a pas de concept de connexion, et il faut définir soi-même la connexion UDP. Après avoir essayé plusieurs méthodes de définition, aucune ne parvient à déterminer avec précision l’orientation de la connexion, ce qui nécessite d’accepter une certaine marge d’erreur. Après tout, il n’y a pas de définition officielle de la connexion UDP, et lorsque les parties ont des définitions différentes de la connexion UDP, cela entraîne inévitablement des comportements différents des attentes.

UDP du point de vue du client

Les activités vocales et vidéo entraînent souvent des pertes de paquets, mais différents modes de perte affectent différemment l’activité. Par exemple, une perte de 30 % uniformément répartie diffère sensiblement d’une perte concentrée sur une période spécifique, ce qui influence clairement l’expérience utilisateur. Évidemment, nous espérons une perte plus uniforme. Cependant, UDP ne dispose pas de méthode de contrôle de flux pour prévenir les pertes ; il existe néanmoins plusieurs façons de gérer les pertes. Bien que la communication UDP soit souvent décrite comme « best effort », différents types de « best effort » entraînent des effets variés.

UDP du point de vue du fournisseur de services

Dans une attaque TCP, le client doit supporter certains coûts, tels que la création et la maintenance de la connexion, ce qui signifie que l’attaquant doit payer un certain prix. En revanche, dans une attaque UDP, les coûts pour l’attaquant sont bien moindres. Si l’attaquant cherche à consommer la bande passante du service, UDP constitue un excellent moyen. Par exemple, si un service achète 100 Go de bande passante illimitée, avec une capacité de traitement de seulement 10 Mo/s mais une vitesse de réception de 1 Go/s, alors 90 % du trafic de requête est inefficace, bien que ce trafic ne soit pas gratuit. Le fournisseur de services devrait éviter de telles situations.

UDP du point de vue de l’opérateur

Une communication complète implique plusieurs terminaux et canaux de communication. On s’intéresse généralement au serveur et au client, mais le point de vue de l’opérateur est tout aussi crucial. Dans les attaques DDoS, nous nous concentrons souvent sur la consommation de ressources du serveur, mais les ressources de l’opérateur sont également limitées. Si le serveur ne répond simplement pas aux requêtes, mais reçoit tout de même le trafic, cela consomme déjà de la bande passante, bien que cette ressource appartienne généralement à l’opérateur. Nous utilisons souvent l’indicateur de « taux de perte de paquets » lors des tests de charge, qui reflète la perte de paquets sur toute la chaîne de communication, et non seulement celle du serveur. Les opérateurs perdent également des paquets. Du point de vue de l’opérateur, si un service achète 1 Mo/s de bande passante, mais que le client envoie à 1 Go/s, aucune des parties ne paie pour le trafic gaspillé, c’est l’opérateur qui supporte ce coût de bande passante. Par conséquent, l’opérateur cherchera inévitablement à bloquer ce type de trafic, c’est-à-dire la QoS UDP. TCP dispose d’un contrôle de congestion, mais UDP peut être contrôlé par l’opérateur via la perte de paquets. En pratique, les opérateurs sont encore plus directs : ils bloquent simplement le trafic des ports utilisés sur une longue période, ce qu’on appelle le blocage de ports UDP. Lors de tests réels d’appels WeChat, on a constaté que chaque appel utilise plusieurs ports côté client, dont un port UDP communique avec 6 ports UDP du même serveur, probablement pour contrer le blocage de ports par l’opérateur.

Conclusion

La flexibilité d’UDP se manifeste par la multiplicité des méthodes de réalisation d’un objectif, toutes légitimes tant qu’elles aboutissent à une communication stable, quelle que soit leur différence radicale avec TCP. Elles sont toutes « existantes parce que rationnelles ». Ainsi, nous ne pouvons pas appliquer entièrement les concepts TCP à UDP. Même si, pour la conception du produit, nous créons une nouvelle définition de connexion UDP, nous devrions anticiper et tolérer les erreurs, car « tolérer les erreurs » est la fonction principale d’UDP. C’est un avantage d’UDP, pas un inconvénient, c’est une capacité fondamentale du protocole choisie activement par le service, et non un défaut inévitablement accepté.

Pour en savoir plus