Einführung
Zwei Grove-Besucher berichten von Wartezeiten beim Öffnen der Informationen zu Lantern Photography. Die normale Referenz und beide betroffenen Besuche sind in einem Mitschnitt aufgezeichnet. Du ermittelst, ob das lange Intervall nach dem Senden einer Anfrage oder vor dem Auftreten der nächsten liegt.
Du solltest die HTTP-Filter, Follow TCP Stream und Anfrage-Antwort-Links des vorigen Labs kennen. Dieses Lab beginnt in einer neuen, unabhängigen Desktop-Umgebung. Du lernst Zeitreferenzen und zwei genau definierte Intervalle; Programmieren oder Serverreparatur sind nicht nötig. Die kontrollierten Aufzeichnungen stützen Aussagen über Paketzeiten, nicht über Browserdarstellung oder Server-CPU.
Eine Anfrage und ihre Antwort messen
Du misst in diesem Schritt Aspens erste Detailtransaktion. Beginne in Desktop, öffne unten links Applications → Terminal Emulator und starte Wireshark mit der neuen Eingabe.
wireshark /home/labex/project/event-page/input/casebook.pcapng
Maximiere Wireshark. Der Dienst ist 127.0.0.1:18182. Maple (127.0.0.5) ist die normale Referenz, Aspen (127.0.0.6) und Elm (127.0.0.7) sind die gemeldeten Besuche; Pine (127.0.0.8) ist unbeteiligt. Jeder Besuch fordert Liste, Details, Programm und nochmals Details auf einer dauerhaften Verbindung an. Dauerhaft bedeutet, dass sie für mehrere Anfrage-Antwort-Austausche geöffnet bleibt.
Filtere Aspens HTTP-Nachrichten:
ip.addr == 127.0.0.6 && http
Wähle das erste Detail-GET. Klappe HTTP auf und lies X-Request: aspen-02. Finde mit Response in frame → right-click → Go to Linked Packet die tatsächliche Antwort und prüfe den Rückverweis Request in frame. In der Eingabe sind Anfrage und Antwort die Frames 42 und 46.
Suche in der Antwort Time since request. Klicke mit rechts und wähle Apply as Column. Der Wert beträgt ungefähr 1.6017 Sekunden. Eine Sekunde sind 1.000 Millisekunden, also hier etwa 1601.7 ms.
Dies ist das Intervall zwischen dem HTTP-Analyseframe der Anfrage und dem ihrer zugehörigen Antwort in dieser Aufzeichnung. Wireshark dekodiert die vollständige Nachricht möglicherweise erst auf dem letzten Segment der Zusammensetzung. Nenne diesen Wert nicht Server-CPU-Zeit, Seitenladezeit im Browser oder Zeit bis zum ersten Antwortbyte.
Prüfe das Intervall sichtbar mit einer Zeitreferenz. Wähle Anfrageframe 42 und Edit → Set/Unset Time Reference; in dieser Version lautet das Tastenkürzel Ctrl+T. Wähle unter View → Time Display Format die Option Seconds Since Beginning of Capture. Dieses Format verwendet eine gesetzte Zeitreferenz. Die Anfrage erhält *REF* und wirkt als Nullpunkt; die Antwort folgt ungefähr 1,6017 Sekunden später. Klicke nach dem Vergleich mit rechts auf das Referenzpaket und entferne die Referenz mit demselben Befehl.
Nutze für diese Zuordnung weder Seconds Since Previous Captured Packet noch Previous Displayed Packet. Ein Nachbar in der Liste ist nicht zwingend die passende Anfrage. Ein anderer Filter ändert zudem das vorherige angezeigte Paket. Zeitreferenzen werden nicht dauerhaft im Mitschnitt gespeichert: Notiere eindeutige Frame-Nummern und das gemessene Intervall, damit andere es reproduzieren können.
Suche die folgende Programmanfrage aspen-03 bei Frame 48. Die Lücke von Detailantwort 46 bis Anfrage 48 beträgt etwa 0.3 ms. Setze die Antwort als Referenz, lies die relative Zeit der Programmanfrage und entferne die Referenz. Diese Lücke ist die zweite Kennzahl: das Intervall zwischen diesen beiden benannten Analyseframes, keine allgemeine Messung menschlicher Bedenkzeit.
Hier ist Frame 46 mit *REF* markiert. Lies für Frame 48 die Spalte Time: 0.000312566 Sekunden sind ungefähr 0.3 ms. Die getrennte Spalte Time since request bei Frame 46 beschreibt weiterhin sein eigenes Anfrage-Antwort-Paar; das sind verschiedene Intervalle.
Erstelle /home/labex/project/event-page/output/timing.csv mit einem zweiten Desktop-Terminal und Mousepad. Öffne erneut Applications → Terminal Emulator und führe aus:
mousepad /home/labex/project/event-page/output/timing.csv
Die Spalten bezeichnen den Besuch, die erste Detailanfrage, ihre Antwort, die nächste Programmanfrage, beide Intervalle in Millisekunden und die beobachtete Phase. Nutze after für ein langes Anfrage-Antwort-Intervall, before für eine lange Lücke vor der nächsten Anfrage und normal, wenn keines lang ist. In diesen Übungsaufzeichnungen überschreiten lange Intervalle 800 ms; das ist eine Lehrschwelle, kein Produktionsziel. Auf 5 ms genau gerundete Werte werden akzeptiert.
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
Speichere mit Ctrl+S. Die Belege verorten Aspens lange Wartezeit nach seiner Detailanfrage. Sie benennen weder die interne Serverursache noch beweisen sie, dass alle Netzwerkkomponenten gesund sind.
Die Lücke vergleichen und Belege sichern
Du vergleichst jetzt Elm und den normalen Maple-Besuch mit Aspen und bewahrst die benötigten vollständigen Unterhaltungen. Beginne in Desktop, kehre zu Wireshark und der Originaleingabe zurück. Entferne vor einer neuen Messung sämtliche Zeitreferenzen.
Filtere Elm:
ip.addr == 127.0.0.7 && http
Folge über die HTTP-Frame-Links der tatsächlichen Antwort der ersten Detailanfrage. elm-02 ist Anfrage 74 und Antwort 78. Das Anfrage-Antwort-Intervall beträgt etwa 0.3 ms. Suche die folgende Programmanfrage elm-03 bei Frame 80. Setze Frame 78 als Zeitreferenz; Frame 80 erscheint etwa 1.6012 Sekunden später. Entferne danach die Referenz.
Elms langes Intervall liegt nach der vorherigen Antwort, aber vor der nächsten Anfrage. Der Paketmitschnitt belegt diese Position. Er unterscheidet nicht zwischen Clienttimer, Anwendungsarbeit oder einer Person, die eine Aktion verzögert. Bezeichne das ohne weitere Belege nicht als Frontendfehler.
Wiederhole dies für Maple mit ip.addr == 127.0.0.5 && http. Die erste Detailanfrage, ihre Antwort und die Programmanfrage sind Frames 12, 16 und 17. Beide Intervalle liegen unter einer Millisekunde. Die normale Referenz zeigt, wie dieselbe Folge ohne lange Wartezeit aussehen kann.
Kehre zu Mousepad zurück und ersetze die Tabelle durch alle drei Besuche; behalte Aspens Zeile. Nutze die Frame-Nummern der Originaleingabe und Millisekunden:
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
Speichere die Datei. Die beiden betroffenen Besuche haben ähnlich auffällige Verzögerungen an verschiedenen Stellen. Die gesamte Duration einer Verbindung unterscheidet sie nicht. Auch nur die letzte Anfrage jedes Streams zu behalten, würde die wiederholten Detailanfragen nicht korrekt zuordnen.
Untersuche in Wireshark eine Programmantwort. Ihr HTTP-Inhalt ist größer und auf mehrere TCP-Segmente verteilt. Wähle die Antwort und untersuche Reassembled TCP sowie den vollständigen JSON-Titel Lantern Photography. Zusätzliche Leerzeichen am Ende sind synthetische Übungsfüllung, keine weiteren JSON-Objekte. Das Analyseframe-Intervall schließt die Fertigstellung der Nachricht ein; daher ist die Kennzahl nicht automatisch die Zeit bis zum ersten Byte.
Behalte nun die vollständigen Verbindungen von Maple, Aspen und Elm. || bedeutet, dass eine der Bedingungen zutreffen darf. Ersetze den Anzeigefilter durch:
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
Füge kein && http hinzu: Der Export braucht auch die früheren TCP-Segmente. Wähle File → Export Specified Packets, Displayed → All packets, und speichere PCAPNG unter /home/labex/project/event-page/output/evidence.pcapng. Schließe Pine aus. Existiert bereits eine Ausgabe, bestätige nur das Ersetzen dieser Kursausgabe, niemals der Originaleingabe.
Öffne den Export und prüfe alle drei Besuche samt vollständigen Antworten. Exportierte Frame-Nummern können abweichen; deine Tabelle verweist ausdrücklich auf die Originaleingabe. Ist der Export unvollständig, öffne die Eingabe erneut und wiederhole den vollständigen Verbindungsexport. Zeigt ein neuer Filter keine Zeilen, prüfe die geöffnete Datei und die Clientadresse; leere den Filter, um die Paketliste wiederherzustellen.
Die nützliche Schlussfolgerung ist präzise: Aspens langes Intervall folgt einer Detailanfrage, während Elms langes Intervall vor seiner nächsten Programmanfrage liegt. Maples normale Transaktion bleibt zum Vergleich erhalten. Keine Serverkonfiguration wurde geändert; eine stärkere Aussage zur internen Ursache ist nicht erforderlich.
Zusammenfassung
Du hast mit Wiresharks Anfrage-Links, Time since request und Zeitreferenzen zwei unterschiedliche Wartepositionen verglichen. Du hast eine normale Referenz und unabhängig lesbare Unterhaltungen bewahrt. Deine Schlussfolgerung lokalisiert die beobachtete Wartezeit, ohne eine unbeobachtete interne Anwendungs- oder Netzwerkursache zu behaupten.
