Медленный запрос HTTP и TTFB в PCAP: проверка того, связана ли задержка с DNS, TCP, TLS или временем сервера
Как диагностировать медленные HTTP-запросы при захвате пакетов путем разделения задержки DNS, TCP-квитирования, TLS-квитирования, загрузки запроса, обработки сервера и времени до первого байта.
«Сайт работает медленно» и «Запрос API занимает 10 секунд» не являются диагнозами. Захват пакетов может разделить задержку на этапы: "поиск DNS, подтверждение TCP, подтверждение TLS, загрузка запроса, обработка сервера, загрузка ответа, повторная передача и поведение клиента." Время до первого байта часто является фразой, которую ищут пользователи. В доказательствах пакетов TTFB не является одним магическим полем. Это временная шкала.
Постройте график запроса
Для запроса HTTP или HTTPS проверьте:
- Начало DNS-запроса
- Время ответа DNS
- TCP-синхронизация
- Завершение TCP-квитирования
- TLS-клиентПривет
- TLS ServerHello и сертификат
- Отправлено байтов HTTP-запроса
- первый байт ответа
- полное завершение ответа
- повторная передача или сброс
Если DNS занимает пять секунд, сервер еще не медленный. Если TCP-квитирование происходит быстро, но первый байт ответа задерживается, проблема может заключаться в обработке сервера или восходящей зависимости. Если TLS зависает раньше HTTP, сосредоточьтесь на сертификате, шифре, SNI или поведении промежуточного блока.
HTTP через TLS требует осторожных границ
При перехвате HTTPS полезная нагрузка может быть зашифрована, но время по-прежнему имеет значение. Часто можно определить:
- начало соединения
- продолжительность рукопожатия
- зашифрованные данные приложения от клиента
- первые зашифрованные данные приложения с сервера
- потеря или повторная передача пакетов
- соединение закрывается или сбрасывается
Даже без расшифровки контента захват может показать, произошла ли задержка до или после отправки запроса.
Следите за повторными передачами
Медленный HTTP может быть вызван потерей пакетов. Если повторные передачи TCP или дублирующиеся подтверждения появляются во время загрузки запроса или доставки ответа, возможно, сервер не является основным владельцем. Большой ответ с потерями на пути от сервера к клиенту может выглядеть для пользователей как задержка серверной части.
В отчете должны быть выделены:
- время до того, как запрос покинет клиент
- сервер времени, похоже, обрабатывает
- время, потраченное на повторную передачу ответа
- поведение окна получения на стороне клиента
Это различие не позволяет бэкэнд-командам отслеживать сетевые проблемы.
Где подходит операция PCAP
PCAP Surgery полезен, когда исходный захват слишком велик или слишком чувствителен. Целенаправленное управление задержкой HTTP должно сохранить:
- Окно DNS
- TCP-квитирование
- Подтверждение TLS, если присутствует
- время запроса/ответа
- доказательства повторной передачи
- сброс или оповещение
- оригинальные временные метки
Если необходима анонимизация, сохраняйте время и размеры пакетов, когда они имеют значение. Удаление слишком большого количества контекста может сделать анализ TTFB невозможным.
Для таких запросов, как «медленный HTTP-запрос pcap», «время захвата первого байта пакета» или «задержка API Wireshark», ответом является поэтапная временная шкала, а не один ярлык виноватого.