ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % COMP5311 Projekt: Leistungsanalyse von TCP und UDP
newpage
Ich frage mich sogar, warum sich der Chrome-Browser beim Ansehen von YouTube-Videos so viel schneller anfühlt als Firefox? Das tue ich, und als neugieriger Student habe ich Wireshark gestartet und etwas Datenverkehr erfasst, und was ich gefunden habe, ist Folgendes.
Laut Wiki 1 wird QUIC von mehr als der Hälfte aller Verbindungen vom Chrome-Webbrowser zu den Servern von Google verwendet.
QUIC ist ein Protokoll, das darauf abzielt, Webanwendungen, die derzeit TCP 2 verwenden, durch die Einrichtung einer Reihe von gemultiplexten UDP zu verbessern. Einige nennen es sogar „TCP/2“. Das kommende HTTP/3 (Internet-Entwurf vom Februar 2021) soll angeblich auch QUIC verwenden.
Warten Sie ... Wir verwenden UDP, um TCP zu ersetzen? Uns wurde gesagt, dass UDP unzuverlässig sei. Wie kommt es, dass es darauf abzielen kann, TCP zu „veralten“. Der Vergleich der beiden Protokolle (TCP und UDP) ähnelt dem Vergleich von Zug mit Flugzeug und nicht von Boeing mit Airbus (beide Transport ). Wir können sie jedoch immer noch mit einigen Schlüsselkennzahlen vergleichen, um einen Eindruck davon zu bekommen, was dieser QUIC mit UDP verbessert hat.
newpage
newpage
Der Vergleich des Transportschichtprotokolls ist keine leichte Aufgabe, da es viele Faktoren gibt, die das Ergebnis beeinflussen können:
Einige Parameter innerhalb des Protokolls (z. B. TCP) bleiben der Implementierung überlassen (was zu TCP/IP-Fingerprinting führt und es böswilligen Akteuren ermöglicht, unter anderem das Betriebssystem des Hosts zu identifizieren), was bedeutet, dass diese Unterschiede subtile Auswirkungen auf das haben könnten Messung der Leistung
Der unmittelbare Weg, den die Pakete nehmen, würde sich sicherlich auf das Ergebnis auswirken, sodass auch die unmittelbaren Router, dazwischen liegende Engpassverbindungen und anderer Datenverkehr die Ergebnisse beeinflussen könnten.
Wie oben erwähnt, sind wir uns oft nicht sicher über die Bandbreite dieser unmittelbaren Verbindungen oder einfach über die Verbindung zwischen Client und Server. In einem der erwähnten Artikel wurde davon ausgegangen, dass der Link keine Kollisionen aufweisen würde.
Wir haben gesehen, dass der Puffer die Leistung dieser Protokolle beeinträchtigt haben könnte, und nicht nur die Softwareseite ist relevant, sondern auch die Hardwareseite, und oft konnten wir diese Details auf niedrigerer Ebene nicht ganz kontrollieren.
In den meisten früheren Arbeiten implementieren Autoren häufig ein benutzerdefiniertes Programm zur Durchführung des Experiments. Wir müssen auch die Auswirkungen dieser Softwareimplementierungen auf das Ergebnis berücksichtigen, beispielsweise das Intervall, in dem UDP-Pakete gesendet werden, und ob es Einschränkungen gibt die Sprache, die für unseren vorliegenden Zweck bezüglich der Sendeintervalle verwendet wird.
Unter Berücksichtigung all dieser Überlegungen werden wir eine einfache Netzwerktopologie mit möglichst realitätsnahen Einstellungen verwenden. Wenn die zugrunde liegenden Details wie Pufferwarteschlangengröße oder Protokolle angegeben sind, verwenden wir für beide Protokolle dasselbe. Daher werden wir TCP und UDP über IPv4 in einem kabelgebundenen Eins-zu-eins-Host vergleichen und dabei den Durchsatz, die durchschnittliche Verzögerung und den durchschnittlichen Jitter als Leistungsindikatoren verwenden.
Wir senden 10, 100 und range(1e4, 1e5, 1e4) Pakete mit jeweils 1472 Bytes in einer UDP-Anwendung und der entsprechenden Anzahl von Bytes in einer TCP-Anwendung, um die Flüsse von TCP- und UDP-Anwendungen zu beobachten.
JitterSum enthält die Summe aller End-to-End-Verzögerungs-Jitter-Werte (Verzögerungsvariation) für alle empfangenen Pakete des Flusses. Hier definieren wir den Jitter eines Pakets als die Verzögerungsschwankung relativ zum letzten Paket des Streams, d. h
newpage
Die erste Frage bei der Gestaltung dieses Experiments ist, ob es simuliert werden soll oder nicht. Die Simulation könnte in unserer Studie besser sein, da wir mehr Kontrolle über die genannten Überlegungen haben können. Der größte Nachteil ist, wie können wir sicher sein, dass das Ergebnis „echt“ ist? Die Antwort darauf ist, dass wir eine Vorstellung davon haben können, wie „real“ die Ergebnisse sein können, solange wir einen klar definierten Umfang für das Experiment haben und diese Bereiche regelmäßig auf ihre Richtigkeit überprüfen.
ns-3 ist ein Open-Source-Netzwerksimulator für diskrete Ereignisse, der hauptsächlich für Forschungs- oder Bildungszwecke verwendet wird und in C++ geschrieben ist. Für den Simulator selbst steht online eine umfassende Dokumentation zur Verfügung.
Für unseren vorliegenden Zweck müssen wir nur die Hauptabstraktionen von ns-3 verstehen
{Breite=75%}
Es ist wie bei Prozessen in unserem Computer, er verwendet „Sockets“, um Daten an die untere Ebene zu senden. Wir werden eine handelsübliche BulkSendApplication in ns-3 installieren, die einen TCP-Socket und einen UDPClient und einen UDPServer zum Senden von UDP-Paketen sowie einen FlowMonitor für beide Fälle zur Überwachung der Pakete verwendet.
Wir senden Pakete in einem Intervall von 2 Mikrosekunden, was der unten angegebenen Verzögerung des zugrunde liegenden Kanals entspricht
Hier ist die Nutzlast gemeint. Da MTU 1500 beträgt, möchten wir natürlich 1500 Bytes verwenden. Der IP-Header und der UDP-Header benötigen jedoch 20 + 8 Bytes, daher sollten wir 1472 statt 5 verwenden. Dies wird in der Simulation bestätigt; Die Verwendung von 1500-Byte-Paketen könnte die Durchsatzleistung beeinträchtigen.
BulkSendApplication„Dieser Verkehrsgenerator sendet Daten einfach so schnell wie möglich bis zu MaxBytes oder bis die Anwendung gestoppt wird (wenn MaxBytes Null ist). Sobald der Sendepuffer der unteren Schicht gefüllt ist, wartet er, bis Platz frei ist, um weitere Daten zu senden, und behält im Wesentlichen einen ständiger Datenfluss.
Wir setzen MaxBytes auf die Gesamtbytes (PacketCount * PacketSize) von UDP, um die Leistung zu vergleichen, und SendSize spielt bei einigen Experimenten keine Rolle
Wird auch InternetStackHelper genannt, der normalerweise UDP, TCP-Sockets, IPv4 und für unseren vorliegenden Zweck einen TrafficControlLayer enthält, der eine Warteschlange enthält und die obere Schicht benachrichtigt, wenn diese voll ist
Dies betrifft sowohl die Hardware (Netzwerkschnittstellenkarten, NICs) als auch deren Softwaretreiber und beinhaltete auch eine Warteschlange für Pakete, sodass es in ns-3 zwei Warteschlangenebenen gibt
Es sind die Endhosts, auf denen wir Application , InternetStack und NetDevice installieren können, ähnlich wie auf unserem Computer. Wir werden zwei Node erstellen und sie mit etwas Ähnlichem wie einem Ethernet-Kabel verbinden.
Stellt Node einen Kommunikationskanal zur Verfügung und wir verwenden einen CSMA-Kanal (wie Ethernet). Die wichtigen Details hier sind die Auswahl dieser zur Optimierung verfügbaren Attribute: MTU, DataRate und Verzögerung. Wir verwenden Standard-MTU (kein Jumbo-Frame, manchmal für bestimmte Netzwerke verfügbar), Gigabit und eine Verzögerung von 2 Mikrosekunden. Der Grund für 2 Mikrosekunden liegt darin, dass Licht 600 m zurücklegen muss, im Vergleich zu anderen Studien, bei denen eine Verzögerung von 0 verwendet wurde.
newpage
Die Ergebnisse sind wie folgt:
Wir haben festgestellt, dass der Durchsatz für UDP für 14720, 147200 gesendete Bytes 1000 Mbit/s überstieg (unsere Bandbreite beträgt 1 Gbit/s). Anschließend haben wir uns den Paketverlust angesehen
Wir können sehen, dass bei 147200 Bytes 97 von 100 Paketen verloren gehen. Man kann mit Fug und Recht sagen, dass wir diese beiden Dinge aufgeben und weitere Untersuchungen durchführen sollten
Wir können auch sehen, dass der TCP-Durchsatz allmählich zunahm und sich bei etwa 400 Mbit/s einpendelte.
Aufgrund der fehlenden Verkehrskontrolle können UDP-Pakete in den Warteschlangen der unteren Schicht „stecken bleiben“. Das Ergebnis könnte auch darauf zurückzuführen sein, dass unsere schnellen, ständig aktiven Pakete die Überlastung verursachen. Zur Bestätigung sind weitere Untersuchungen erforderlich, beispielsweise eine Verringerung des Puffers, um festzustellen, ob die Verzögerung tatsächlich zunimmt.
Die durchschnittliche Verzögerung zeigte kurz nach dem „Höhepunkt“ Einbrüche und stieg dann allmählich wieder an. Dies könnte daran liegen, dass cwnd die Stauvermeidung angepasst hat. Weitere Untersuchungen sind erforderlich, da wir bestätigen müssen, dass der Algorithmus zur Überlastungskontrolle tatsächlich solche Muster erzeugt, da es in ns-3 viele Möglichkeiten dafür gibt (Veno, Cubic usw.).
Es wird erwartet, dass der durchschnittliche Jitter abnimmt, wenn das System „stabilisiert“ wird und die Variation in der Verzögerung geringer wird.
Das Fehlen einer Verkehrskontrolle bei UDP bedeutet, dass die Pakete kontinuierlich im Stapel nach unten verschoben und ohne Störungen gesendet werden. Die Variation in der Verzögerung sollte nur minimal sein, während die Paketverzögerung aufeinanderfolgender Pakete aufgrund der besagten Verkehrskontrolle groß sein könnte.
newpage
Die BulkSendApplication stellte sicher, dass sie wartet, sobald der Sendepuffer der unteren Schicht gefüllt ist. Der einzige Ort, an dem wir Pakete verwerfen könnten, ist also der Kanal, in den wir Fehler einbringen müssen.
UDPClient verfügt über keine solche Verkehrskontrolle, sodass wir den Verlust von Paketen beobachten konnten.
Könnte einfach am Durchsatz (höherer Durchsatz) und am Jitter (geringere Verzögerungsschwankungen) liegen. Die größere durchschnittliche Verzögerung ist hauptsächlich auf die mangelnde Verkehrskontrolle zurückzuführen, die der QUIC anstrebt, um den „Überlastungskontrollalgorithmus in den Benutzerraum … und nicht in den Kernelraum“ zu verlagern 1 .
https://github.com/alfredtso/ns-3-project
newpage
NS-3-Schulungsressourcen
HTTP/3-Entwurf
SCHNELL ↩ ↩ 2
QUIC GoogleDoc ↩
Yuan-Cheng Lai, Ahsan Ali, Md. Shohrab Hossain, Ying-Dar Lin, Leistungsmodellierung und Analyse von TCP- und UDP-Flüssen über softwaredefinierten Netzwerken, Journal of Network and Computer Applications, Band 130, 2019, Seiten 76–88, ISSN 1084-8045 ↩
Jingyi He, S.-H.Gary Chan, TCP- und UDP-Leistung für das Internet über optische paketvermittelte Netzwerke, Computer Networks, Band 45, Ausgabe 4, 2004, Seiten 505–521, ISSN 1389–1286 ↩
Eric Gamess, Rina Surós, An Upper Bound Model for TCP and UDP Throughput in IPv4 and IPv6, Journal of Network and Computer Applications, Band 31, Ausgabe 4, 2008, Seiten 585-602, ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor, Raaid Alubady, Wisam Abduladeem Kamil, Simulierte Leistung von TCP-, SCTP-, DCCP- und UDP-Protokollen über 4G-Netzwerke, Procedia Computer Science, Band 111, 2017, Seiten 2–7, ISSN 1877-0509 ↩
