Introduction
Willow Games dispose de deux liaisons réseau et de deux types de travaux : de petites mises à jour de score et de gros fichiers audio de répétition. Les deux services fonctionnent déjà, mais la liaison qui répond le plus vite ne transporte pas forcément un gros fichier le plus vite.
Vous essaierez des livraisons normales, comparerez le délai et le débit montant vers une même cible par les deux chemins, puis rétablirez la route initiale après chaque expérience. Vous devez savoir utiliser un terminal et lire une destination, un prochain saut et une route à portée limitée, comme dans le projet de routage précédent ou une pratique équivalente. Aucune expérience en programmation, encodage multimédia, régulation du trafic ou iperf n’est supposée.
Utilisez Event Client pour toutes les commandes et Event Receipts pour consulter les enregistrements des récepteurs. Chaque TP prépare son propre réseau isolé ; rien d’une VM précédente n’est nécessaire. Les 45 minutes constituent une estimation de l’auteur incluant la lecture et les erreurs courantes, et non une durée mesurée auprès de débutants.
Essayer une petite mise à jour et une grosse livraison
Vous utiliserez ici un poste de score déjà opérationnel, puis effectuerez deux vraies livraisons de démonstration. Commencez dans Event Client. Ce terminal est le shell d’administration d’un espace de noms réseau Linux isolé, déjà placé dans /home/labex/project/event-links. Le récepteur est dans un autre espace de noms ; ils partagent le noyau d’une même VM. N’utilisez pas un shell de la plateforme pour ces commandes. Ouvrir l’onglet ne reconstruit pas le réseau.
Willow Games a besoin d’interactions rapides pour les scores et de fichiers audio de répétition complets. Une petite requête passe une grande partie de son temps à attendre le trajet des paquets ; un gros envoi nécessite aussi une capacité suffisante pour transporter ses octets. La latence est le délai de parcours, et le débit la quantité de données utiles livrées par seconde. Aucun de ces deux indicateurs ne décrit à lui seul tous les travaux.
pwd affiche le répertoire de travail. cat affiche un fichier. Si une commande signale un fichier absent, vérifiez l’orthographe et utilisez la commande cd complète ci-dessous pour revenir dans l’espace de travail ; une faute de frappe n’exige pas de réinitialiser la VM.
pwd
cd /home/labex/project/event-links
cat links.tsv
Les deux lignes identifient lane1 et lane2, leurs prochains sauts et les adresses sources de ce client. Un prochain saut est le voisin qui reçoit un paquet sur son trajet vers la destination. La destination des scores est 10.205.10.10 ; celle des médias est une autre adresse, 10.205.10.20. Les deux écoutent sur le port 8080. Le délai et la capacité des liaisons sont préparés par l’initialisation ; laissez la régulation, les adresses et les services inchangés.
Commencez par un score existant qui fonctionne. curl transfère une ressource HTTP. --noproxy '*' contourne les paramètres de proxy de l’environnement pour toutes les adresses ; les guillemets empêchent le shell de développer le caractère générique. -f fait échouer la commande en cas d’erreur HTTP, -s masque la progression et -S affiche tout de même les erreurs. Ces options combinées s’écrivent -fsS. --max-time 35 limite le transfert entier à 35 secondes. L’URL choisit la destination réelle, le port et la ressource.
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Vous devez voir warmup, un score de 1–1 et preserved. Cet exemple normal doit rester disponible. Ce n’est pas votre nouvelle livraison.
Lisez le score de démonstration, représenté en JSON : les accolades entourent les champs nommés, les chaînes utilisent des guillemets doubles et les deux scores sont des entiers.
cat source/demo.json
Vous devez trouver le match demo, domicile 1, extérieur 0. -H définit le type de contenu HTTP. --data-binary @source/demo.json lit ce fichier exact et le soumet par HTTP POST ; @ désigne un corps provenant d’un fichier. -w affiche un bref résultat de chronométrage après la réponse. Dans sa chaîne entre apostrophes, \n désigne un saut de ligne et %{time_total} le nombre de secondes écoulées. Copiez la commande entière sur une ligne :
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
Lisez match, les scores, peer_ip et local_ip dans l’accusé. Ils identifient ce que le récepteur a accepté ainsi que la source et la destination réelles de la connexion. Répéter un POST pour le même match remplace son accusé ; cela ne crée pas de matchs en double.
Le fichier préparé demo.wav est une tonalité originale de test sonore de deux secondes, au format audio PCM WAV valide. Vous n’avez pas à créer ni encoder de média. -T envoie le corps du fichier par HTTP PUT. Répéter un PUT avec le même nom remplace cette tâche multimédia.
curl --noproxy '*' -fsS --max-time 35 -T source/demo.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/demo.wav
L’accusé contient le nombre d’octets et l’empreinte SHA-256 du contenu. Une empreinte résume les octets ; des empreintes identiques étayent l’identité du contenu, contrairement au seul nom du fichier. Pour comparer le fichier réellement reçu, téléchargez-le à nouveau. -o enregistre la réponse au chemin indiqué. cmp compare chaque octet et n’affiche rien en cas de succès :
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
Passez à Event Receipts et sélectionnez Refresh receipts. Ouvrez Existing demonstration receipts et recherchez votre score demo et demo.wav. La page lit les récepteurs réels via Event Client ; elle ne complète jamais les enregistrements absents à partir du dossier source. Les cartes principales attendent les nouvelles tâches du TP suivant.
La section de démonstration dépliée ci-dessous montre le score demo accepté ainsi que l’identité de demo.wav, son empreinte et les sources réelles des connexions. À ce stade, il est normal que les cartes principales restent en attente.
Si curl se termine avec 7, la connexion a échoué : revenez à Event Client et vérifiez l’adresse, le port et la commande ip route get enseignée ensuite. Le code 28 signifie que le délai maximal est dépassé, pas un refus HTTP. Le code 22 signale une erreur HTTP. Avec -f, curl indique le statut HTTP mais omet le corps de la réponse d’erreur ; comparez le chemin exact du point d’accès et le fichier JSON ou corps fourni. Lisez le fichier source nommé avec cat et corrigez la commande en préservant les fichiers fournis. Une connexion réussie avec la mauvaise tâche reste un résultat métier incorrect.
Mesurer le délai sur chaque chemin
Vous comparerez ici un échantillon borné de délai vers la même destination par chaque liaison. Commencez dans Event Client. Toutes les commandes s’exécutent sur ce même client ; seule la route de la destination multimédia change. Conservez les routes des scores et de référence, la route par défaut, les interfaces, les fichiers sources et la régulation.
ip route show liste les routes actuelles. /32 sélectionne exactement une destination IPv4. ip route get demande quelle route et quelle source le noyau utiliserait ; aucun paquet n’est envoyé. Lisez la route multimédia actuelle avant de la changer :
ip route show
ip route get 10.205.10.20
Le résultat attendu est via 10.205.1.1 dev lane1 src 10.205.1.2. Retenez cette route initiale : vous la rétablirez après chaque expérience. Ce cours utilise une route par défaut préparée dans le réseau isolé ; elle ne donne pas accès à Internet.
ip route replace ajoute ou remplace uniquement la route de la destination indiquée. via choisit le prochain saut, et dev l’interface de sortie. Remplacer un /32 ne remplace pas la route par défaut. Rendez d’abord explicite le test par lane1 :
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping envoie des requêtes d’écho ICMP. -n affiche des adresses numériques, -c 4 s’arrête après quatre requêtes et -W 2 attend une réponse au maximum deux secondes. Le temps aller-retour (RTT) comprend l’aller et la réponse ; il ne s’agit ni d’un délai à sens unique ni d’une réponse de score applicative.
ping -n -c 4 -W 2 10.205.10.20
Lisez les quatre réponses et la ligne finale min/avg/max/mdev, en millisecondes (ms). Comparez la moyenne et la dispersion, pas seulement l’échantillon le plus bas. Cette liaison donne généralement environ 11 ms de RTT dans le scénario préparé. La première découverte des voisins ou l’ordonnancement de la VM peuvent ralentir un échantillon.
Basculez maintenant uniquement cette même destination vers lane2 :
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
Vous devez obtenir via 10.205.2.1 dev lane2 src 10.205.2.2 avant de mesurer :
ping -n -c 4 -W 2 10.205.10.20
Ce chemin donne généralement environ 180 ms de RTT. L’écart doit être important ; ce n’est pas une promesse concernant un fournisseur réel ou Internet. L’absence de réponse ne signifie pas automatiquement que le service HTTP est en panne : ICMP et HTTP sont des protocoles différents. Vérifiez d’abord cette destination, le prochain saut et l’interface. Si les valeurs sont proches, répétez ce même échantillon borné un chemin à la fois ; ne lancez pas de tests parallèles.
Rétablissez la route initiale visant une seule destination et confirmez-la :
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Vous avez observé deux temps de parcours sans changer les propriétés des liaisons. Vérifiez ensuite si la réponse la plus rapide transporte aussi plus vite les données volumineuses.
Mesurer le débit dans le sens nécessaire
Vous comparerez ici le débit TCP montant sur les deux mêmes chemins. Commencez dans Event Client, avec la route multimédia rétablie sur lane1. Le récepteur préparé exécute un serveur iperf3 sur le port 5201. Le client démarre un test ; le serveur reçoit les données de test et indique ce qui est arrivé. Ces octets de test ne sont pas votre livraison multimédia.
iperf3 -c choisit l’adresse du serveur et -t 5 limite le test de données à cinq secondes. Le test TCP par défaut envoie du client au serveur, dans le même sens que l’envoi multimédia de l’événement. Nous n’utilisons pas -R, qui inverse le sens. Les courts échanges de préparation et de résultats peuvent porter la durée totale légèrement au-delà de cinq secondes.
Confirmez la route avant le premier test :
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Lisez la ligne finale receiver. La colonne Bitrate peut utiliser Mbits/sec (Mbps) : des millions de bits par seconde. Un octet contient huit bits ; divisez donc les Mbps par huit pour estimer les Mo/s. Par exemple, 2 Mbps représentent au maximum environ 0,25 Mo/s avant les surcoûts du protocole. MBytes dans la colonne de transfert est une quantité de données, pas un débit. Le débit reçu par lane1 est généralement proche de 1,9 Mbps.
Attendez la fin de la commande avant de changer de route. Mesurez la même destination par 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 livre généralement des dizaines de Mbps malgré son RTT plus long. Le démarrage de TCP, les acquittements, les surcoûts du protocole, l’ordonnancement et la courte fenêtre d’observation influencent le débit. La vitesse nominale d’une interface virtuelle n’est pas un débit mesuré. Si le serveur indique qu’un test est en cours, attendez la fin du test borné actuel et réessayez une fois ; ne lancez ni autre serveur ni tests supplémentaires simultanés.
Rétablissez la route multimédia initiale et confirmez-la :
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
La liaison à faible RTT convient aux petites interactions, tandis que celle à haut débit convient à cet envoi volumineux. Cette conclusion se limite aux chemins préparés et au sens mesuré. Vous n’avez mesuré ni le Wi-Fi, ni la capacité de l’Internet public, ni la fiabilité en production. Le TP indépendant suivant vous demande d’utiliser ces observations pour livrer de nouveaux contenus métier.
Résumé
Vous avez envoyé un vrai score et un fichier audio lisible, comparé une même cible par deux chemins, interprété le RTT et le débit du récepteur TCP, puis rétabli la route à portée limitée. Les mesures décrivent un chemin et un sens ; la prochaine tâche transforme ces observations en routes métier distinctes.
