介绍
两位 Grove 访客反映打开 Lantern Photography 信息时需要等待。正常参考访问和两次受影响访问录制在同一个抓包中。你将判断长区间是在请求发出后，还是在下一请求出现前。
你应掌握上一实验的 HTTP 过滤器、Follow TCP Stream 和请求响应链接。本实验在全新、独立的 Desktop 环境开始。你将学习时间参考和两个精确定义的区间；无需编程或修复服务器。这些受控录制支持数据包时间分析，不能据此判断浏览器渲染或服务器 CPU 状况。
测量请求及其响应
本步骤将测量 Aspen 的第一次详情事务。从 Desktop 开始，在左下角桌面菜单打开 Applications → Terminal Emulator，使用新的输入启动 Wireshark。
wireshark /home/labex/project/event-page/input/casebook.pcapng
最大化 Wireshark。服务为 127.0.0.1:18182。Maple（127.0.0.5）是正常参考，Aspen（127.0.0.6）和 Elm（127.0.0.7）是两次投诉访问，Pine（127.0.0.8）与本任务无关。每次访问都在持久连接上依次请求列表、详情、日程，再次请求详情。“持久”表示连接保持打开，供多次请求响应交换复用。
过滤 Aspen 的 HTTP 消息：
ip.addr == 127.0.0.6 && http
选择第一个详情 GET。展开 HTTP，读取 X-Request: aspen-02。使用 Response in frame → right-click → Go to Linked Packet 找到实际响应，再核对反向的 Request in frame 链接。输入中的请求帧为 42，响应帧为 46。
在响应中找到 Time since request。右键选择 Apply as Column。值约为 1.6017 秒。一秒等于 1,000 毫秒，因此约为 1601.7 ms。
这是本录制中请求 HTTP 解析帧与其对应响应 HTTP 解析帧之间的区间。Wireshark 可能在最后一个重组分段上解码完整消息。不要将此值称为服务器 CPU 时间、浏览器页面加载时间或响应首字节时间。
通过时间参考直观核对该区间。选择请求帧 42，执行 Edit → Set/Unset Time Reference；本版本快捷键为 Ctrl+T。在 View → Time Display Format 中选择 Seconds Since Beginning of Capture。设置参考后，该格式以参考为基准。请求标记为 *REF*，相当于零；对应响应在约 1.6017 秒后。比较后右键时间参考包，使用相同命令取消参考。
不要用 Seconds Since Previous Captured Packet 或 Previous Displayed Packet 进行这种配对。当前列表中的相邻包未必是匹配的请求。改变过滤器也会改变前一个显示包。时间参考不会永久保存在抓包中：记录明确帧号和测量区间，便于他人复现。
找到随后的日程请求 aspen-03，位于帧 48。详情响应 46 到请求 48 的间隙约为 0.3 ms。将响应设为参考，读取日程请求的相对时间，然后取消参考。这个 gap 是第二项指标：两个指定解析帧之间的区间，不是对用户思考时间的一般测量。
这里帧 46 标为 *REF*。读取帧 48 的 Time 列：0.000312566 秒约为 0.3 ms。帧 46 另设的 Time since request 列仍描述它自己的请求响应对；这是两个不同区间。
在第二个 Desktop 终端中用 Mousepad 创建 /home/labex/project/event-page/output/timing.csv。再次打开 Applications → Terminal Emulator，运行：
mousepad /home/labex/project/event-page/output/timing.csv
各列依次表示访问、第一次详情请求、其响应、下一个日程请求、两个毫秒区间以及观察到的阶段。请求到响应区间较长用 after；下个请求前的间隙较长用 before；两者都不长用 normal。在这些训练录制中，超过 800 ms 算长区间；这是教学阈值，不是生产性能目标。允许四舍五入后误差在 5 ms 内。
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
按 Ctrl+S 保存。证据将 Aspen 的长等待定位在详情请求之后。它不能确定服务器内部原因，也不能证明所有网络组件均正常。
比较间隙并保留证据
本步骤将 Elm 和正常 Maple 访问与 Aspen 比较，再保留所需完整会话。从 Desktop 开始，返回 Wireshark 和原始输入。开始新测量前，取消全部时间参考。
过滤 Elm：
ip.addr == 127.0.0.7 && http
使用 HTTP 帧链接找到第一次详情请求的实际响应。elm-02 的请求为 74、响应为 78。请求到响应区间约为 0.3 ms。找到下一个日程请求 elm-03，位于帧 80。将帧 78 设为时间参考；帧 80 约在 1.6012 秒后出现。随后取消参考。
Elm 的长区间发生在前一个响应之后、下一个请求之前。数据包记录确定了这个位置，但无法区分客户端定时器、应用工作或人为延迟操作。没有额外证据，不应称其为前端缺陷。
使用地址过滤器 ip.addr == 127.0.0.5 && http 对 Maple 重复操作。Maple 的第一次详情请求、其响应和日程请求分别为帧 12、16 和 17。两个区间均不到一毫秒。这个正常参考说明相同序列在没有长等待时的表现。
返回 Mousepad，将表格替换为全部三次访问，同时保留 Aspen 行。使用原始输入帧号和毫秒：
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
保存文件。两次受影响访问都有类似明显的延迟，但位置不同。连接的总 Duration 无法区分两者。只保留每个流的最后一个请求，也无法正确配对重复详情请求。
在 Wireshark 中检查一个日程响应。其 HTTP 正文较大，分布于多个 TCP 分段。选中响应，检查 Reassembled TCP 和完整 JSON 标题 Lantern Photography。额外的尾部空白是合成训练填充，不是更多 JSON 对象。解析帧区间包含消息完成时间；这说明该指标不能自动等同于首字节时间。
现在保留 Maple、Aspen 和 Elm 的完整连接。|| 表示任一条件匹配即可。将显示过滤器替换为：
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
不要添加 && http：导出也需要前面的 TCP 分段。选择 File → Export Specified Packets，选 Displayed → All packets，将 PCAPNG 保存为 /home/labex/project/event-page/output/evidence.pcapng。排除 Pine。如果已有输出，仅确认替换本课程输出文件，不能替换原始输入。
打开导出文件，检查三次访问及完整响应。导出帧号可能不同；表格明确引用原始输入。如果导出不完整，重新打开输入，再导出完整连接。新过滤器没有显示行时，检查是否打开预期文件、客户端地址是否输入正确；清空过滤器可恢复列表。
有用的结论应精确：Aspen 的长区间位于详情请求之后，而 Elm 的长区间位于下一个日程请求之前。保留正常 Maple 事务用于比较。无需改变服务器配置，也无需做更强的内部原因判断。
总结
你使用 Wireshark 请求链接、Time since request 和时间参考，比较了两种不同的等待位置。你保留了正常参考及可独立读取的会话。结论定位了观察到的等待，并未将未经观察的应用或网络内部原因当作事实。
