Введение
Два посетителя 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) к задаче не относится. Каждое посещение запрашивает список, сведения, программу и снова сведения по постоянному соединению. Постоянное означает, что соединение остаётся открытым для нескольких обменов запросами и ответами.
Отфильтруйте HTTP-сообщения Aspen:
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-запроса и кадром разбора соответствующего ответа в этой записи. 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. Сделайте ответ опорной точкой, прочитайте относительное время запроса программы и снимите точку. Эта пауза — вторая метрика: интервал между двумя указанными кадрами разбора, а не общее измерение времени размышления пользователя.
Здесь кадр 46 отмечен *REF*. Прочитайте Time кадра 48: 0.000312566 секунды — примерно 0.3 ms. Отдельный столбец Time since request у кадра 46 по-прежнему описывает его собственную пару запрос-ответ; это разные интервалы.
Создайте /home/labex/project/event-page/output/timing.csv во втором терминале Desktop с помощью Mousepad. Снова откройте 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 возникает после предыдущего ответа, но перед следующим запросом. Запись пакетов устанавливает это положение. Она не различает таймер клиента, работу приложения и человека, откладывающего действие. Не называйте это ошибкой фронтенда без дополнительных доказательств.
Повторите для Maple с фильтром ip.addr == 127.0.0.5 && http. Его первый запрос сведений, ответ и запрос программы — кадры 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 сохранена для сравнения. Конфигурация сервера не менялась, и более сильное утверждение о внутренней причине не требуется.
Резюме
Вы использовали ссылки запросов, Time since request и временные опорные точки Wireshark, чтобы сравнить два разных положения ожидания. Вы сохранили обычный эталон и независимо читаемые соединения. Вывод локализует наблюдаемое ожидание, не утверждая ненаблюдаемую внутреннюю причину приложения или сети.
