Question Débit TCP bien meilleur que UDP


Je surveille les performances d'un lien WAN avec iperf entre deux machines Windows aux deux extrémités.

Étonnamment (pour moi), la fenêtre TCP par session unique atteint un débit de 12 Mbps, tandis que la limite UDP (perte de paquets de 0%) est d'environ 4 Mbps. La bande passante supérieure à 5 Mbps amène UDP à des pertes de paquets inacceptables (> 20%).

Comment peut-il être?

Ces résultats sont également confirmés par du trafic réel UDP envoyé sur la liaison (à une bande passante inférieure à la capacité attendue), ce qui entraîne une perte de paquets.

Merci d'avance pour toute suggestion.

MODIFIER: oublié de mentionner un détail important: il s'agit d'un réseau privé, ce n'est donc pas un lien encombré et le trafic supplémentaire sur le lien pendant ces tests (à la fois avec iperf et avec du trafic réel) est presque négligeable.

MODIFIER: Quelqu'un peut-il donner des conseils sur la façon de dépanner (dans quelle partie du réseau) ce trafic est abandonné?


3
2017-07-15 08:07


origine


Le trafic traverse-t-il un routeur? Quoi d'autre dans le chemin, par ex. traverse-t-il un commutateur d'un port 1 Gbps à un port 100 Mbps? Il existe de nombreux points de congestion cachés sur un réseau. - Ron Maupin
Oui, il traverse: un réseau commuté A ----- routeur A ---- routeur B ----- réseau commuté B. En cas de dépannage, le problème semble se poser dans un réseau commuté. Oui, il croise les commutateurs des ports de 1 Gbit / s à 100 Mbit / s. - kuma
@kuma On dirait qu'il y a une partie du chemin qui n'est pas cohérente. TCP peut s'adapter, UDP ne peut pas. - David Schwartz
Il y a beaucoup d'endroits où le trafic est abandonné. Un port 100 Mbps ne peut pas suivre un flux de trafic de 1 Gbps, et beaucoup de trames seront supprimées (les commutateurs ont des tampons minuscules). UDP n'a aucune méthode pour demander que le trafic perdu soit renvoyé car l'hôte récepteur ne s'attend pas à ce que quelque chose arrive. TCP remarquera que le trafic a été supprimé et il renverra le trafic. Les routeurs ne fonctionnent généralement pas à wirepeed, et donnent souvent la priorité au protocole TCP sur UDP, sauf configuration différente. Sans une conception de réseau et des configurations, il faut savoir où se trouve le problème. - Ron Maupin
proposez-vous de définir tous les ports impliqués dans cette communication UDP (hôtes et commutateurs) sur 100 Mbits / s? - kuma


Réponses:


Iperf n'a aucune logique pour optimiser l'efficacité du trafic UDP sur une liaison WAN. Windows, à l’instar de la plupart des systèmes d’exploitation modernes, a déployé des efforts considérables pour obtenir chaque goutte de débit TCP possible.

TCP a des accusés de réception qui ajustent une fenêtre, une stimulation de transmission sophistiquée, etc. Iperf envoie simplement les paquets UDP à intervalles réguliers.

Il n'y a pas de comparaison.


2
2017-07-15 08:19



Je comprends les optimisations effectuées au niveau du système d'exploitation. Mais je ne comprends toujours pas parler au niveau des liens. Si l'on s'attend à ce que cela fournisse un débit de 15 Mbps, pourquoi l'envoi de 5 Mbps UDP entraîne-t-il une perte de paquets aussi élevée? Quel article est responsable de telles pertes? N'est-ce pas un symptôme de problème de réseau? Cela se produit également avec le trafic UDP réel (pas iperf) - kuma
@kuma Encore une fois, il y a une raison pour laquelle tant de recherches et d'efforts ont été consacrés à la conception de TCP et à son contrôle de la congestion, à la réduction, à la stimulation de la transmission, etc. UDP n'a rien de tout ça. C'est pourquoi nous utilisons le protocole TCP pour les données volumineuses qui ont de l'importance (comme le téléchargement de fichiers) et nous utilisons UDP pour les petites requêtes sensibles à la latence (comme le DNS). UDP n'a aucun moyen sensé de réagir à la congestion à moins que l'application ne l'implémente. Iperf ne le fait pas. - David Schwartz
J'ai édité la question en ajoutant quelques détails. La question est principalement liée à d'éventuels problèmes au sein du réseau, car le lien n'est pas censé être encombré (tests très inférieurs à la capacité de liaison), plutôt que sur le fonctionnement de TCP / UDP. - kuma