ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % Projet COMP5311 : Analyse des performances de TCP et UDP
nouvelle page
Je me demande même pourquoi le navigateur Chrome semble tellement plus rapide que Firefox lorsque vous regardez des vidéos Youtube ? Je le fais et en tant qu'étudiant curieux, j'ai lancé Wireshark et capturé du trafic et ce que j'ai trouvé est ceci.
Selon le wiki 1 , QUIC est utilisé par plus de la moitié de toutes les connexions du navigateur Web Chrome aux serveurs de Google.
QUIC est un protocole visant à améliorer les applications web utilisant actuellement TCP 2 en établissant un certain nombre d'UDP multiplexés et certains l'ont même appelé "TCP/2". Le prochain HTTP/3 (Internet-Draft en février 2021) est censé utiliser également QUIC.
Attendez... Nous utilisons UDP pour remplacer TCP ? On nous a dit qu'UDP n'était pas fiable, comment se fait-il qu'il puisse viser à « rendre obsolète » TCP. La comparaison des deux protocoles (TCP et UDP) est similaire à la comparaison entre Train et Avion plutôt que Boeing et Airbus (les deux transports ). Cependant, nous pouvons toujours les comparer avec certaines mesures clés pour avoir un aperçu de ce que QUIC a choisi d'améliorer UDP.
nouvelle page
nouvelle page
Comparer le protocole de la couche transport n’est pas une tâche facile, car de nombreux facteurs peuvent affecter le résultat :
Certains paramètres du protocole (TCP par exemple) sont laissés à l'implémentation (ce qui donne lieu au TCP/IP Fingerprinting, permettant à un acteur malveillant d'identifier, entre autres, le système d'exploitation de l'hôte), ce qui signifie que ces différences pourraient avoir un effet subtil sur le protocole. mesure des performances
L'itinéraire immédiat emprunté par les paquets affecterait certainement le résultat, de sorte que les routeurs immédiats, les liens goulots d'étranglement entre les deux et tout autre trafic pourraient également affecter les résultats.
Comme mentionné ci-dessus, nous ne sommes souvent pas sûrs de la bande passante de ces liens immédiats ou simplement du lien entre le client et le serveur. L'un des articles mentionnés a émis l'hypothèse que le lien n'entraînerait aucune collision.
Nous avons vu que le tampon aurait pu avoir un impact sur les performances de ces protocoles et que non seulement le côté logiciel est pertinent, la partie matérielle compte également et souvent nous ne pouvions pas vraiment contrôler ces détails de niveau inférieur.
Dans la plupart des travaux précédents, les auteurs implémentent souvent un programme personnalisé pour mener l'expérience. Nous devons également considérer l'effet de la façon dont ces implémentations logicielles pourraient affecter le résultat, par exemple l'intervalle selon lequel les paquets UDP sont envoyés, et existe-t-il des limitations dans la langue étant utilisée pour, dans le cadre de notre propos actuel, les intervalles d'envoi.
Compte tenu de toutes ces considérations, nous utiliserons une topologie de réseau simple avec des paramètres aussi proches que possible de la réalité. En ce qui concerne les détails sous-jacents tels que la taille de la file d'attente du tampon ou les protocoles, nous utiliserons les mêmes pour les deux protocoles. En tant que tel, nous comparerons TCP et UDP sur IPv4 dans des hôtes filaires un à un en utilisant le débit, le délai moyen et la gigue moyenne comme indicateurs de performances.
Nous enverrons des paquets de 10, 100 et range(1e4, 1e5, 1e4) , chacun de 1472 octets dans une application UDP et le nombre équivalent d'octets dans une application TCP pour observer les flux des applications TCP et UDP.
JitterSum contient la somme de toutes les valeurs de gigue de délai de bout en bout (variation du délai) pour tous les paquets reçus du flux. Ici, nous définissons la gigue d'un paquet comme la variation du délai par rapport au dernier paquet du flux, c'est-à-dire
nouvelle page
La première question de la conception de ladite expérience est de simuler ou non. La simulation pourrait être meilleure dans notre étude car nous pouvons avoir plus de contrôle sur les considérations que nous avons mentionnées. Le plus gros inconvénient est de savoir comment être sûr que le résultat est « réel » ? La réponse à cette question est que tant que nous avons une portée clairement définie pour l'expérience et des contrôles fréquents de cohérence sur ces portées, nous pouvons avoir une idée de la « réalité » des résultats.
ns-3 est un simulateur de réseau open source à événements discrets utilisé principalement à des fins de recherche ou d'enseignement écrit en C++. Le simulateur lui-même dispose d’une documentation complète disponible en ligne.
Pour notre objectif actuel, il nous suffit de comprendre les principales abstractions de ns-3
{largeur=75% }
C'est comme les processus de notre ordinateur, il utilise des « sockets » pour envoyer des données à la couche inférieure. Nous installerons une BulkSendApplication prête à l'emploi dans ns-3 en utilisant un socket TCP et un UDPClient et un UDPServer pour l'envoi de paquets UDP et un FlowMonitor dans les deux cas pour surveiller les paquets.
Nous enverrons des paquets à un intervalle de 2 microsecondes, ce qui correspond au délai du canal sous-jacent spécifié ci-dessous.
Ici, il s'agit de la charge utile. Puisque MTU est de 1 500, nous souhaiterons naturellement utiliser 1 500 octets. L'en-tête IP et l'en-tête UDP nécessitent cependant 20 + 8 octets, nous devrions donc utiliser 1472 à la place 5 . Ceci est confirmé en simulation ; l'utilisation d'un paquet de 1 500 octets pourrait nuire aux performances de débit.
BulkSendApplication"Ce générateur de trafic envoie simplement les données aussi rapidement que possible jusqu'à MaxBytes ou jusqu'à l'arrêt de l'application (si MaxBytes est nul). Une fois le tampon d'envoi de la couche inférieure rempli, il attend que l'espace soit libre pour envoyer plus de données, gardant essentiellement un flux constant de données.".
Nous définissons le MaxBytes sur le nombre total d'octets (PacketCount * PacketSize) d'UDP pour comparer les performances et le SendSize n'a pas d'importance dans certaines expériences.
Également appelé InternetStackHelper qui comprend généralement UDP, TCP Sockets, IPv4 et, pour notre objectif actuel, un TrafficControlLayer , qui comprend une file d'attente et lorsqu'elle est pleine, elle en informe la couche supérieure.
Cela correspond à la fois au matériel (cartes d'interface réseau, cartes réseau) et à leurs pilotes logiciels et inclut également une file d'attente pour les paquets, il y a donc deux niveaux de file d'attente dans ns-3
Ce sont les hôtes finaux sur lesquels nous pouvons installer Application , InternetStack et NetDevice , comme notre ordinateur. Nous allons créer deux Node et les connecter avec quelque chose de similaire à un câble Ethernet.
Fournit un canal de communication à Node et nous utiliserons un canal CSMA (comme Ethernet). Les détails importants ici sont le choix de ces attributs disponibles pour les ajustements : MTU, DataRate et Delay. Nous utiliserons le MTU standard (pas de trame Jumbo, parfois disponible sur un réseau spécifique), le gigabit et un délai de 2 microsecondes. La raison pour laquelle 2 microsecondes sont nécessaires est que la lumière parcourt 600 m, par rapport à d'autres études utilisant un délai de 0.
nouvelle page
Les résultats sont les suivants :
Nous avons observé que le débit pour UDP pour 14 720, 147 200 octets envoyés dépassait 1 000 Mbps (notre bande passante est de 1 Gbps). Nous avons ensuite regardé la perte de paquets
Nous pouvons voir que dans 147 200 octets, 97 paquets sur 100 sont perdus. Il est prudent de dire que nous devrions abandonner ces deux éléments et enquêter plus en profondeur.
Nous pouvons également constater que le débit TCP a progressivement augmenté et s'est stabilisé à environ 400 Mbps.
En raison du manque de contrôle du trafic, les paquets UDP peuvent être « bloqués » dans les files d'attente des couches inférieures. Le résultat pourrait également être dû à notre envoi rapide et permanent de paquets provoquant une congestion. Des investigations plus approfondies seront nécessaires pour confirmer, par exemple en réduisant le tampon pour voir si le délai augmente réellement.
Le retard moyen a connu des baisses juste après le « pic », puis a augmenté à nouveau progressivement. Cela pourrait être dû à l’ajustement cwnd pour éviter les embouteillages. Une enquête plus approfondie est nécessaire car nous devons confirmer que l'algorithme de contrôle de la congestion produit réellement de tels modèles car il existe de nombreux choix dans ns-3 (Veno, Cubic... etc.)
La gigue moyenne devrait diminuer à mesure que le système se « stabilise » et la variation du retard serait moindre.
L'absence de contrôle du trafic dans UDP signifie que les paquets seront continuellement poussés vers le bas de la pile et envoyés sans interférence, la variation du délai ne devrait être que minime alors que le retard des paquets consécutifs pourrait être important en raison dudit contrôle du trafic.
nouvelle page
BulkSendApplication s'est assuré qu'une fois le tampon d'envoi de la couche inférieure rempli, il attendrait. Ainsi, le seul endroit où nous pourrions supprimer des paquets est dans le canal dans lequel nous devrons introduire une erreur.
UDPClient n'a pas un tel contrôle du trafic, nous pouvons donc observer la perte de paquets.
Cela pourrait simplement être le débit (plus grand débit) et la gigue (moins de variation du délai). Le délai moyen plus élevé est principalement dû au manque de contrôle du trafic, le QUIC visant à déplacer « l'algorithme de contrôle de la congestion dans l'espace utilisateur… plutôt que dans l'espace noyau » 1 .
https://github.com/alfredtso/ns-3-project
nouvelle page
ressources de formation ns-3
Brouillon HTTP/3
QUIC ↩ ↩ 2
RAPIDE GoogleDoc ↩
Yuan-Cheng Lai, Ahsan Ali, Md. Shohrab Hossain, Ying-Dar Lin,Modélisation et analyse des performances des flux TCP et UDP sur des réseaux définis par logiciel, Journal of Network and Computer Applications, Volume 130, 2019, Pages 76-88, ISSN 1084-8045 ↩
Jingyi He, S.-H.Gary Chan, Performances TCP et UDP pour Internet sur réseaux optiques à commutation de paquets, Réseaux informatiques, Volume 45, Numéro 4, 2004, Pages 505-521, ISSN 1389-1286 ↩
Eric Gamess, Rina Surós, Un modèle de limite supérieure pour le débit TCP et UDP dans IPv4 et IPv6, Journal of Network and Computer Applications, Volume 31, Numéro 4, 2008, Pages 585-602, ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor, Raaid Alubady, Wisam Abduladeem Kamil, Performances simulées des protocoles TCP, SCTP, DCCP et UDP sur le réseau 4G, Procedia Computer Science, Volume 111, 2017, Pages 2-7, ISSN 1877-0509 ↩
