Einführung
Willow Games hat zwei Netzwerkverbindungen und zwei Arten von Aufgaben: kleine Spielstandsänderungen und große Audiodateien für die Probe. Beide Dienste laufen bereits. Die Verbindung mit der schnellsten Antwort überträgt eine große Datei jedoch nicht unbedingt am schnellsten.
Du probierst normale Übertragungen aus, vergleichst Verzögerung und Upload-Durchsatz zum selben Ziel über beide Pfade und stellst nach jedem Versuch die ursprüngliche Route wieder her. Vorausgesetzt werden grundlegende Terminalbedienung und das Lesen von Ziel, nächstem Hop und einer auf ein Ziel begrenzten Route, wie im vorherigen Routing-Projekt oder durch gleichwertige Übung. Programmierung, Medienkodierung, Verkehrsformung und iperf werden nicht vorausgesetzt.
Verwende Event Client für alle Befehle und Event Receipts zum Lesen der Empfängereinträge. Jedes Lab bereitet sein eigenes isoliertes Netzwerk vor; nichts aus einer vorherigen VM wird benötigt. Die Dauer von 45 Minuten ist eine Schätzung des Autors einschließlich Lesen und gewöhnlicher Fehler, keine mit Anfängern gemessene Bearbeitungszeit.
Eine kleine Aktualisierung und eine große Übertragung testen
In diesem Schritt nutzt du einen bereits funktionierenden Spielstandsdienst und sendest danach zwei echte Beispielübertragungen. Beginne in Event Client. Dieses Terminal ist die Administratorshell in einem isolierten Linux-Netzwerk-Namensraum und befindet sich bereits in /home/labex/project/event-links. Der Empfänger liegt in einem anderen Namensraum; beide teilen den Kernel einer VM. Verwende für diese Befehle keine Plattform-Shell. Das Öffnen des Tabs baut das Netzwerk nicht neu auf.
Willow Games braucht schnelle Spielstandsinteraktionen und vollständige Audiodateien für die Probe. Eine kleine Anfrage wartet einen großen Teil ihrer Zeit auf den Weg der Pakete; ein großer Upload braucht zusätzlich ausreichend Kapazität für seine Bytes. Latenz ist die Laufzeitverzögerung, Durchsatz die pro Sekunde übertragenen Nutzdaten. Keiner der beiden Werte beschreibt allein jede Aufgabe.
pwd zeigt das Arbeitsverzeichnis. cat zeigt eine Datei. Meldet ein Befehl eine fehlende Datei, vergleiche die Schreibweise und kehre mit dem folgenden vollständigen cd-Befehl zum Arbeitsverzeichnis zurück; ein Tippfehler erfordert keinen VM-Reset.
pwd
cd /home/labex/project/event-links
cat links.tsv
Die beiden Zeilen zeigen lane1 und lane2, ihre nächsten Hops und die Quelladressen dieses Clients. Ein nächster Hop ist der Nachbar, der ein Paket auf dessen Weg zum Ziel empfängt. Das Spielstandsziel ist 10.205.10.10; das Medienziel hat die andere Adresse 10.205.10.20. Beide lauschen auf Port 8080. Verzögerung und Kapazität der Verbindungen werden vom Setup vorbereitet; lasse Verkehrsformung, Adressen und Dienste unverändert.
Beginne mit einem vorhandenen funktionierenden Spielstand. curl überträgt eine HTTP-Ressource. --noproxy '*' umgeht die Proxy-Umgebungseinstellungen für alle Adressen; die Anführungszeichen verhindern die Platzhaltererweiterung durch die Shell. -f lässt HTTP-Fehler zum Fehlschlag führen, -s verbirgt die Fortschrittsanzeige und -S zeigt weiterhin Fehler. Zusammen schreibt man diese Optionen -fsS. --max-time 35 begrenzt die gesamte Übertragung auf 35 Sekunden. Die URL wählt tatsächliches Ziel, Port und Ressource.
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Erwartet werden warmup, der Spielstand 1–1 und preserved. Dieses normale Beispiel muss verfügbar bleiben. Es ist nicht deine neue Übertragung.
Lies den Beispielspielstand in JSON: Geschweifte Klammern umschließen benannte Felder, Zeichenketten stehen in doppelten Anführungszeichen und beide Spielstände sind ganze Zahlen.
cat source/demo.json
Erwartet werden das Spiel demo, Heim 1, Auswärts 0. -H setzt den HTTP-Inhaltstyp. --data-binary @source/demo.json liest genau diese Datei und sendet sie per HTTP POST; @ steht für einen Dateikörper. -w gibt nach der Antwort eine kurze Zeitmessung aus. In seiner einfach zitierten Zeichenkette bedeutet \n einen Zeilenumbruch und %{time_total} die verstrichenen Sekunden. Kopiere den gesamten Befehl als eine Zeile:
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/demo.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Lies match, Spielstände, peer_ip und local_ip im Beleg. Sie zeigen den akzeptierten Inhalt sowie tatsächliche Quelle und Ziel der Verbindung. Ein erneuter POST für dasselbe Spiel ersetzt dessen Beleg; er erzeugt keine doppelten Spiele.
Die vorbereitete demo.wav ist ein selbst erstellter zweisekündiger Soundcheck-Ton mit gültigem PCM-WAV-Audio. Du musst keine Medien erstellen oder kodieren. -T lädt den Dateikörper per HTTP PUT hoch. Ein erneuter PUT mit demselben Namen ersetzt diese eine Medienaufgabe.
curl --noproxy '*' -fsS --max-time 35 -T source/demo.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/demo.wav
Der Beleg enthält Bytezahl und SHA-256-Prüfsumme des Inhalts. Eine Prüfsumme fasst Bytes zusammen; gleiche Prüfsummen stützen die Inhaltsgleichheit, der Dateiname allein nicht. Lade die tatsächlich empfangene Datei zum Vergleich erneut herunter. -o speichert die Antwort am angegebenen Pfad. cmp vergleicht jedes Byte und gibt bei Erfolg nichts aus:
curl --noproxy '*' -fsS --max-time 35 -o received/demo.wav http://10.205.10.20:8080/media/demo.wav
cmp source/demo.wav received/demo.wav
Wechsle zu Event Receipts und wähle Refresh receipts. Öffne Existing demonstration receipts und suche deinen Spielstand demo und demo.wav. Die Seite liest die echten Empfänger über Event Client; fehlende Einträge werden niemals aus dem Quellordner ergänzt. Die Hauptkarten warten auf die neuen Aufgaben des nächsten Labs.
Der unten aufgeklappte Beispielbereich zeigt den akzeptierten Spielstand demo sowie Identität, Inhaltsprüfsumme und tatsächliche Verbindungsquellen von demo.wav. Wartende Hauptkarten sind in dieser Phase zu erwarten.
Beendet sich curl mit 7, konnte es keine Verbindung aufbauen: Kehre zu Event Client zurück und prüfe Adresse, Port und den als Nächstes erklärten Befehl ip route get. Code 28 bedeutet Zeitüberschreitung, keine HTTP-Ablehnung. Code 22 bedeutet einen HTTP-Fehler. Mit -f meldet curl den HTTP-Status, lässt aber den Fehlerantwortkörper weg; vergleiche den genauen Endpunktpfad und die bereitgestellte JSON- beziehungsweise Körperdatei. Lies die benannte Quelle mit cat und korrigiere den Befehl, ohne die bereitgestellten Dateien zu ändern. Eine erfolgreiche Verbindung mit der falschen Aufgabe bleibt ein falsches Geschäftsergebnis.
Verzögerung auf jedem Pfad messen
In diesem Schritt vergleichst du eine begrenzte Verzögerungsstichprobe zum selben Ziel über jede Verbindung. Beginne in Event Client. Alle Befehle laufen auf demselben Client; nur die Route zum Medienziel ändert sich. Lasse Spielstands- und Referenzrouten, Standardroute, Schnittstellen, Quelldateien und Verkehrsformung unverändert.
ip route show listet aktuelle Routen. /32 wählt genau ein IPv4-Ziel. ip route get fragt ab, welche Route und Quelle der Kernel verwenden würde; es sendet kein Paket. Lies die aktuelle Medienroute vor der Änderung:
ip route show
ip route get 10.205.10.20
Erwartet wird via 10.205.1.1 dev lane1 src 10.205.1.2. Merke dir diese ursprüngliche Route: Du stellst sie nach jedem Versuch wieder her. Der Kurs nutzt eine vorbereitete Standardroute innerhalb des isolierten Netzwerks; sie bietet keinen Internetzugang.
ip route replace ergänzt oder ersetzt nur die Route zum angegebenen Ziel. via wählt den nächsten Hop und dev die Ausgangsschnittstelle. Das Ersetzen eines /32 ersetzt nicht die Standardroute. Lege zunächst den Test über lane1 ausdrücklich fest:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping sendet ICMP-Echo-Anfragen. -n zeigt numerische Adressen, -c 4 stoppt nach vier Anfragen und -W 2 wartet höchstens zwei Sekunden auf eine Antwort. Die Umlaufzeit (RTT) enthält Hinweg und Antwort; sie ist weder Einwegverzögerung noch die Spielstandsantwort einer Anwendung.
ping -n -c 4 -W 2 10.205.10.20
Lies alle vier Antworten und die abschließende Zeile min/avg/max/mdev in Millisekunden (ms). Vergleiche Durchschnitt und Streuung, nicht nur den niedrigsten Wert. Diese Verbindung liegt im vorbereiteten Szenario meist bei etwa 11 ms RTT. Die erste Nachbarerkennung oder VM-Zeitplanung kann eine Messung verlangsamen.
Stelle nun nur dieses gleiche Ziel auf lane2 um:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
Erwarte vor der Messung via 10.205.2.1 dev lane2 src 10.205.2.2:
ping -n -c 4 -W 2 10.205.10.20
Dieser Pfad liegt meist bei etwa 180 ms RTT. Der Unterschied sollte groß sein; das ist kein Versprechen über einen echten Anbieter oder das Internet. Fehlende Antworten bedeuten nicht automatisch einen defekten HTTP-Dienst: ICMP und HTTP sind verschiedene Protokolle. Prüfe zuerst dieses Ziel, den nächsten Hop und die Schnittstelle. Liegen die Werte nahe beieinander, wiederhole dieselbe begrenzte Messung jeweils auf einem Pfad; starte keine parallelen Tests.
Stelle die ursprüngliche Route für das einzelne Ziel wieder her und bestätige sie:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Du hast zwei Laufzeiten beobachtet, ohne Eigenschaften der Verbindungen zu ändern. Prüfe als Nächstes, ob die schnellere Antwort auch Massendaten schneller transportiert.
Durchsatz in der benötigten Richtung messen
In diesem Schritt vergleichst du TCP-Upload-Durchsatz auf denselben beiden Pfaden. Beginne in Event Client, wobei die Medienroute wieder über lane1 führt. Der vorbereitete Empfänger betreibt einen iperf3-Server auf Port 5201. Der Client startet einen Test; der Server empfängt Testdaten und meldet, was angekommen ist. Diese Testbytes sind nicht deine Medienübertragung.
iperf3 -c wählt die Serveradresse und -t 5 begrenzt den Datentest auf fünf Sekunden. Der Standard-TCP-Test sendet vom Client zum Server, also in derselben Richtung wie der Medienupload der Veranstaltung. Wir nutzen nicht -R, das die Richtung umkehrt. Kurze Einrichtungs- und Ergebnisaustausche können den gesamten Befehl etwas länger als fünf Sekunden dauern lassen.
Bestätige die Route vor dem ersten Test:
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Lies die letzte Zeile receiver. Die Spalte Bitrate kann Mbits/sec (Mbps) verwenden: Millionen Bits pro Sekunde. Ein Byte hat acht Bits; teile Mbps daher durch acht, um MB/s ungefähr zu berechnen. Beispielsweise sind 2 Mbps höchstens rund 0,25 MB/s vor Protokollaufwand. MBytes in der Übertragungsspalte ist eine Datenmenge, keine Rate. Die Empfangsrate über lane1 liegt meist nahe 1,9 Mbps.
Warte auf das Ende des Befehls, bevor du die Route änderst. Miss dasselbe Ziel über lane2:
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Lane2 liefert trotz längerer RTT meist mehrere zehn Mbps. TCP-Anlauf, Bestätigungen, Protokollaufwand, Zeitplanung und das kurze Beobachtungsfenster beeinflussen die Rate. Die Nenngeschwindigkeit einer virtuellen Schnittstelle ist kein gemessener Durchsatz. Meldet der Server einen laufenden Test, warte auf dessen begrenztes Ende und versuche es einmal erneut; starte keinen weiteren Server und keine überlappenden Tests.
Stelle die ursprüngliche Medienroute wieder her und bestätige sie:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Die Verbindung mit niedriger RTT passt zu kleinen Interaktionen, die mit hohem Durchsatz zu diesem großen Upload. Diese Aussage gilt für die vorbereiteten Pfade und die gemessene Richtung. Du hast weder WLAN noch öffentliche Internetkapazität oder Produktionszuverlässigkeit gemessen. Im nächsten unabhängigen Lab setzt du diese Beobachtungen für neue Geschäftsinhalte ein.
Zusammenfassung
Du hast einen echten Spielstand und abspielbares Audio gesendet, dasselbe Ziel über zwei Pfade verglichen, RTT und TCP-Empfängerdurchsatz interpretiert und die begrenzte Route wiederhergestellt. Messungen beschreiben einen Pfad und eine Richtung; die nächste Aufgabe macht daraus getrennte Routen für die Geschäftsaufgaben.
