Introduction
Two Grove visitors report waiting while opening Lantern Photography information. The normal reference and both affected visits are recorded in one capture. You will find whether the long interval occurs after a request has been sent or before the next request appears.
You should know the previous lab's HTTP filters, Follow TCP Stream and request/response links. This lab starts in a fresh independent Desktop environment. You will learn time references and two precisely defined intervals; no programming or server repair is required. These controlled recordings support packet-timing conclusions, not claims about browser rendering or server CPU.
Measure a Request and Its Response
In this step, you will measure Aspen's first details transaction. Begin in Desktop, open Applications → Terminal Emulator from the bottom-left desktop menu, and launch Wireshark with the new input.
wireshark /home/labex/project/event-page/input/casebook.pcapng
Maximize Wireshark. The service is 127.0.0.1:18182. Maple (127.0.0.5) is the normal reference, Aspen (127.0.0.6) and Elm (127.0.0.7) are the two reported visits, and Pine (127.0.0.8) is unrelated. Each visit requests list, details, programme, then details again on a persistent connection. Persistent means the connection stays open for several request/response exchanges.
Filter Aspen's HTTP messages:
ip.addr == 127.0.0.6 && http
Select the first details GET. Expand HTTP and read X-Request: aspen-02. Use Response in frame → right-click → Go to Linked Packet to locate its actual response, then check the reverse Request in frame link. The input frames are request 42 and response 46.
On the response, locate Time since request. Right-click it and choose Apply as Column. The value is about 1.6017 seconds. A second is 1,000 milliseconds, so this is about 1601.7 ms.
This is the interval between the request's HTTP parsing frame and the corresponding response's HTTP parsing frame in this recording. Wireshark may decode the complete message on its final reassembly segment. Do not call this server CPU time, browser page-load time, or time to the first response byte.
Check the interval visibly with a time reference. Select request frame 42 and choose Edit → Set/Unset Time Reference; in this version the shortcut is Ctrl+T. In View → Time Display Format, select Seconds Since Beginning of Capture. This format uses your time reference when one is set. The request is marked *REF* and acts as zero; the corresponding response is about 1.6017 seconds later. Right-click the time-reference packet and use the same reference command to unset it after the comparison.
Do not use Seconds Since Previous Captured Packet or Previous Displayed Packet for this pairing. A neighbor in the current list need not be the matching request. Changing the filter also changes which packet is the previous displayed one. Time references are not permanently saved in the capture: record explicit frame numbers and the measured interval so another analyst can reproduce it.
Now find the following programme request, aspen-03, at frame 48. The gap from details response 46 to request 48 is about 0.3 ms. Set the response as the reference and read the programme request's relative time, then unset the reference. This gap is the second metric: the interval between those two named parsing frames, not a general measurement of user think time.
Here frame 46 is marked *REF*. Read frame 48 in the Time column: 0.000312566 seconds is approximately 0.3 ms. The separate Time since request column on frame 46 still describes its own request/response pair; these are different intervals.
Create /home/labex/project/event-page/output/timing.csv using a second Desktop terminal and Mousepad. Open Applications → Terminal Emulator again, then run:
mousepad /home/labex/project/event-page/output/timing.csv
The columns identify the visit, the first details request, its response, the next programme request, both measured intervals in milliseconds, and the observed stage. Use after for a long request-to-response interval, before for a long gap before the next request, and normal when neither is long. In these training records long intervals exceed 800 ms; that is a teaching threshold, not a production performance objective. Values rounded within 5 ms are accepted.
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
Save with Ctrl+S. The evidence places Aspen's long wait after its details request. It does not identify the server's internal cause or prove every network component healthy.
Compare the Gap and Preserve the Evidence
In this step, you will compare Elm and the normal Maple visit with Aspen, then preserve the required complete conversations. Begin in Desktop, returning to Wireshark and the original input. Unset any time references before starting a new measurement.
Filter Elm:
ip.addr == 127.0.0.7 && http
Follow the first details request's actual response using the HTTP frame links. elm-02 is request 74 and response 78. Its request-to-response interval is about 0.3 ms. Find the next programme request, elm-03, at frame 80. Set frame 78 as a time reference; frame 80 appears about 1.6012 seconds later. Unset the reference afterward.
Elm's long interval occurs after the previous response but before the next request. The packet record establishes that location. It cannot distinguish a client timer, application work, or a person delaying an action. Do not label it a frontend bug without additional evidence.
Repeat for Maple using its address filter, ip.addr == 127.0.0.5 && http. Maple's first details request, its response and its programme request are frames 12, 16 and 17. Both intervals are below one millisecond. This normal reference shows what the same sequence can look like without the long wait.
Return to Mousepad and replace the table with all three visits, preserving Aspen's row. Use the original input's frame numbers and milliseconds:
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
Save the file. The two affected visits have a similarly conspicuous delay in different positions. A connection's total Duration cannot distinguish them. Nor would keeping only the last request in each stream correctly pair the repeated details requests.
In Wireshark, inspect a programme response. Its HTTP body is larger and split across TCP segments. Select the response and inspect Reassembled TCP and the complete JSON title Lantern Photography. The extra trailing whitespace is synthetic training padding, not extra JSON objects. The parsing-frame interval includes this message's completion; this illustrates why the metric is not automatically first-byte time.
Now keep the complete Maple, Aspen and Elm connections. || means either condition can match. Replace the display filter with:
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
Do not add && http: the export needs the earlier TCP segments too. Choose File → Export Specified Packets, select Displayed → All packets, and save PCAPNG as /home/labex/project/event-page/output/evidence.pcapng. Exclude Pine. If a previous output exists, confirm replacement only for this course output file, never for the original input.
Open the export and check all three visits and their complete responses. The exported frame numbers may differ; your table explicitly refers to the original input. If the export is incomplete, reopen the input and repeat the full-connection export. If a new filter produces no rows, check that you opened the expected file and entered the client address correctly; clear the filter to recover the packet list.
Your useful conclusion is precise: Aspen's long interval follows a details request, while Elm's long interval precedes its next programme request. The normal Maple transaction is preserved for comparison. No server configuration was changed, and no stronger internal-cause claim is required.
Summary
You used Wireshark's request links, Time since request and time references to compare two different waiting positions. You preserved a normal reference and independently readable conversations. Your conclusion locates the observed wait without claiming an unobserved application or network root cause.
