Introduction
Deux visiteurs Grove signalent une attente en ouvrant les informations de Lantern Photography. La référence normale et les deux visites concernées sont enregistrées dans une capture. Vous déterminerez si le long intervalle survient après l’envoi d’une requête ou avant l’apparition de la suivante.
Vous devez connaître les filtres HTTP, Follow TCP Stream et les liens requête-réponse du laboratoire précédent. Celui-ci démarre dans un environnement Desktop neuf et indépendant. Vous apprendrez les références temporelles et deux intervalles précisément définis ; aucune programmation ni réparation de serveur n’est requise. Ces enregistrements contrôlés permettent des conclusions sur la chronologie des paquets, pas sur le rendu du navigateur ou le processeur du serveur.
Mesurer une requête et sa réponse
Vous allez mesurer la première transaction de détails d’Aspen. Commencez dans Desktop, ouvrez Applications → Terminal Emulator depuis le menu en bas à gauche et lancez Wireshark avec la nouvelle entrée.
wireshark /home/labex/project/event-page/input/casebook.pcapng
Maximisez Wireshark. Le service est 127.0.0.1:18182. Maple (127.0.0.5) est la référence normale, Aspen (127.0.0.6) et Elm (127.0.0.7) sont les visites signalées, et Pine (127.0.0.8) est sans rapport. Chaque visite demande liste, détails, programme, puis détails de nouveau sur une connexion persistante. Persistante signifie qu’elle reste ouverte pour plusieurs échanges requête-réponse.
Filtrez les messages HTTP d’Aspen :
ip.addr == 127.0.0.6 && http
Sélectionnez le premier GET de détails. Développez HTTP et lisez X-Request: aspen-02. Utilisez Response in frame → right-click → Go to Linked Packet pour trouver sa réponse réelle, puis vérifiez le lien inverse Request in frame. Les trames d’entrée sont la requête 42 et la réponse 46.
Dans la réponse, trouvez Time since request. Faites un clic droit et choisissez Apply as Column. La valeur est d’environ 1.6017 seconde. Une seconde vaut 1 000 millisecondes, soit environ 1601.7 ms ici.
Il s’agit de l’intervalle entre la trame où la requête HTTP est analysée et celle où sa réponse correspondante est analysée dans cet enregistrement. Wireshark peut décoder le message complet sur son dernier segment de réassemblage. Ne l’appelez pas temps processeur du serveur, temps de chargement du navigateur ou délai du premier octet de réponse.
Vérifiez visuellement l’intervalle avec une référence temporelle. Sélectionnez la requête 42 et Edit → Set/Unset Time Reference ; le raccourci de cette version est Ctrl+T. Dans View → Time Display Format, sélectionnez Seconds Since Beginning of Capture. Ce format utilise la référence lorsqu’elle est définie. La requête est marquée *REF* et sert de zéro ; la réponse apparaît environ 1,6017 seconde plus tard. Après comparaison, faites un clic droit sur le paquet de référence et utilisez la même commande pour la retirer.
N’utilisez pas Seconds Since Previous Captured Packet ni Previous Displayed Packet pour cette association. Un voisin dans la liste n’est pas forcément la requête correspondante. Modifier le filtre change aussi le paquet affiché précédent. Les références temporelles ne sont pas enregistrées durablement dans la capture : notez des numéros de trame explicites et l’intervalle mesuré pour qu’un autre analyste puisse le reproduire.
Trouvez ensuite la requête de programme aspen-03, à la trame 48. La pause entre la réponse de détails 46 et la requête 48 vaut environ 0.3 ms. Définissez la réponse comme référence, lisez le temps relatif de la requête de programme, puis retirez la référence. Cette pause est la seconde métrique : l’intervalle entre ces deux trames d’analyse désignées, pas une mesure générale du temps de réflexion de l’utilisateur.
La trame 46 est ici marquée *REF*. Lisez la colonne Time de la trame 48 : 0.000312566 seconde équivaut à environ 0.3 ms. La colonne séparée Time since request de la trame 46 décrit toujours sa propre paire requête-réponse ; ce sont deux intervalles différents.
Créez /home/labex/project/event-page/output/timing.csv avec un second terminal Desktop et Mousepad. Ouvrez de nouveau Applications → Terminal Emulator, puis exécutez :
mousepad /home/labex/project/event-page/output/timing.csv
Les colonnes identifient la visite, la première requête de détails, sa réponse, la prochaine requête de programme, les deux intervalles en millisecondes et la phase observée. Utilisez after pour un long intervalle requête-réponse, before pour une longue pause avant la requête suivante et normal si aucun n’est long. Dans ces enregistrements, un intervalle long dépasse 800 ms : c’est un seuil pédagogique, pas un objectif de production. Un arrondi à 5 ms près est accepté.
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
Enregistrez avec Ctrl+S. La preuve situe la longue attente d’Aspen après sa requête de détails. Elle n’identifie pas la cause interne du serveur et ne prouve pas le bon fonctionnement de tous les composants réseau.
Comparer la pause et conserver les preuves
Vous allez comparer Elm et la visite normale Maple à Aspen, puis conserver les conversations complètes requises. Commencez dans Desktop, en revenant à Wireshark et au fichier original. Retirez toute référence temporelle avant une nouvelle mesure.
Filtrez Elm :
ip.addr == 127.0.0.7 && http
Suivez la réponse réelle de la première requête de détails avec les liens de trame HTTP. elm-02 correspond à la requête 74 et à la réponse 78. Leur intervalle vaut environ 0.3 ms. Trouvez la requête de programme suivante, elm-03, à la trame 80. Définissez 78 comme référence ; 80 apparaît environ 1.6012 seconde plus tard. Retirez ensuite la référence.
Le long intervalle d’Elm se situe après la réponse précédente mais avant la requête suivante. Le relevé de paquets établit cette position. Il ne permet pas de distinguer une minuterie cliente, un traitement applicatif ou une personne retardant une action. Ne concluez pas à un défaut du frontend sans preuve supplémentaire.
Répétez pour Maple avec ip.addr == 127.0.0.5 && http. Sa première requête de détails, sa réponse et sa requête de programme sont les trames 12, 16 et 17. Les deux intervalles sont inférieurs à une milliseconde. Cette référence montre à quoi peut ressembler la même séquence sans longue attente.
Revenez à Mousepad et remplacez la table par les trois visites, en conservant la ligne d’Aspen. Utilisez les numéros de trame originaux et les millisecondes :
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
maple,12,16,17,0.3,0.1,normal
aspen,42,46,48,1601.7,0.3,after
elm,74,78,80,0.3,1601.2,before
Enregistrez. Les deux visites touchées présentent un retard aussi visible, à des positions différentes. La Duration totale d’une connexion ne les distingue pas. Ne garder que la dernière requête de chaque flux n’associerait pas non plus correctement les requêtes de détails répétées.
Dans Wireshark, inspectez une réponse de programme. Son corps HTTP est plus grand et réparti entre plusieurs segments TCP. Sélectionnez la réponse et examinez Reassembled TCP ainsi que le titre JSON complet Lantern Photography. Les espaces finaux sont un remplissage synthétique de formation, pas des objets JSON supplémentaires. L’intervalle des trames d’analyse inclut la fin du message : cette métrique n’est donc pas automatiquement le délai du premier octet.
Conservez maintenant les connexions complètes de Maple, Aspen et Elm. || signifie qu’une condition ou l’autre peut correspondre. Remplacez le filtre par :
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
N’ajoutez pas && http : l’export doit aussi contenir les segments TCP antérieurs. Choisissez File → Export Specified Packets, Displayed → All packets, et enregistrez le PCAPNG sous /home/labex/project/event-page/output/evidence.pcapng. Excluez Pine. Si une sortie existe déjà, confirmez uniquement le remplacement de ce fichier de sortie du cours, jamais du fichier original.
Ouvrez l’export et vérifiez les trois visites et leurs réponses complètes. Les numéros de trame exportés peuvent changer ; la table désigne explicitement le fichier original. Si l’export est incomplet, rouvrez l’entrée et répétez l’export des connexions complètes. Si un nouveau filtre ne montre aucune ligne, vérifiez le fichier ouvert et l’adresse cliente ; effacez le filtre pour retrouver la liste.
La conclusion utile est précise : le long intervalle d’Aspen suit une requête de détails, tandis que celui d’Elm précède sa prochaine requête de programme. La transaction normale Maple est conservée pour comparaison. Aucune configuration serveur n’a changé, et aucune affirmation plus forte sur la cause interne n’est nécessaire.
Résumé
Vous avez utilisé les liens de requête, Time since request et les références temporelles de Wireshark pour comparer deux positions d’attente. Vous avez conservé une référence normale et des conversations lisibles indépendamment. Votre conclusion situe l’attente observée sans affirmer une cause interne applicative ou réseau non observée.
