Как разложить загрузку страницы на этапы
Когда сайт открывается медленно, пользователь видит только итог. В дампе же каждый этап оставляет отдельный след со своей меткой времени, и разница между следами и есть задержка. Типичная последовательность выглядит так: DNS-запрос и ответ, три пакета TCP-рукопожатия, обмен ClientHello и ServerHello при шифровании, запрос приложения, пауза, пока сервер готовит ответ, затем передача данных.
Ваша задача — найти самую большую паузу и понять, чем она вызвана. Для этого нужен короткий, чистый дамп: закройте лишние программы, воспроизведите одну загрузку и остановите запись. Захват трафика допустим только на своём устройстве или в сети, где вам это разрешили.
Настройте столбцы. В меню «Вид» выберите «Формат времени» и вариант «Секунды с предыдущего отображаемого пакета»: в таком режиме столбец времени показывает паузу между соседними строками фильтра, и крупные значения бросаются в глаза. Ещё полезно добавить столбец с полем tcp.time_delta или tcp.analysis.ack_rtt через контекстное меню поля.
Поля времени и что они означают
Wireshark считает несколько величин, которые и нужны для разбора. Часть из них требует включённой опции подсчёта временных меток в настройках протокола TCP.
| Поле | Что показывает |
|---|---|
| frame.time_delta | Пауза от предыдущего захваченного пакета |
| frame.time_delta_displayed | Пауза от предыдущего показанного пакета при фильтре |
| tcp.time_delta | Время с предыдущего сегмента в этом же TCP-потоке |
| tcp.analysis.ack_rtt | Время между сегментом и подтверждением на него |
| dns.time | Время между DNS-запросом и ответом |
| http.time | Время между HTTP-запросом и ответом (для открытого HTTP) |
| tcp.stream | Номер TCP-потока для фильтрации одной сессии |
Чтобы tcp.time_delta заработало, откройте «Правка», «Параметры», «Протоколы», «TCP» и включите расчёт временных меток для соединений. Названия пунктов могут немного отличаться в разных версиях программы.
Пошаговая методика поиска узкого места
- Отфильтруйте DNS и посмотрите dns.time: если ответ идёт секунду и больше или запрос повторяется без ответа, проблема на этапе разрешения имени. Проверьте настройки DNS и другой резолвер.
- Найдите начало нужного TCP-потока: tcp.flags.syn == 1 && ip.addr == адрес. Разница между SYN и SYN-ACK — это круговое время до сервера. Значения в единицы миллисекунд типичны для локальной сети, десятки и сотни миллисекунд — для дальних узлов.
- Если задержка на SYN большая или пакеты SYN повторяются, до сервера трудно добраться: смотрите потери и маршрут, например с помощью mtr.
- Для шифрованных соединений проверьте промежуток между ClientHello и ServerHello. Большое значение говорит о медленном ответе узла или о повторной передаче.
- Найдите запрос приложения и первый ответ сервера. Пауза между ними — время обработки на сервере. Она не связана с сетью, и её не исправить настройкой домашнего роутера.
- Проверьте передачу данных: повторы, дублирующие подтверждения, нулевое окно.
Проще всего сопоставить симптом и причину так.
| Что видно в дампе | Вероятная причина |
|---|---|
| Долгий DNS-ответ | Медленный или недоступный DNS-сервер |
| Повторяющиеся SYN | Потери на пути или фильтр |
| Большая пауза между запросом и ответом при малом RTT | Медленный сервер или приложение |
| Много повторных передач | Потери в канале, слабый Wi-Fi |
| Нулевое окно приёма | Получатель не успевает читать данные |
| Малое окно и пилообразная скорость | Ограничения канала или перегрузка |
Графики Wireshark
Числа хорошо дополняют графики. В меню «Статистика» найдите «Графики TCP-потока»: временная диаграмма последовательностей показывает, как растёт номер отправленных байт. Ровная наклонная линия означает стабильную передачу, ступеньки и горизонтальные участки — паузы, а резкие возвраты назад — повторные передачи. График времени кругового обмена выводит RTT по ходу сессии: скачки в нём совпадают с перегрузкой канала.
Ещё один полезный график называется «Ввод-вывод» (I/O Graph). Он строит число пакетов или байтов в секунду. Если применить к нему фильтр tcp.analysis.retransmission, вы увидите, в какие моменты происходили повторы, и сопоставите их с провалами скорости.
Раздел «Анализ», «Экспертная информация» собирает предупреждения по всему дампу: повторные передачи, нулевые окна, сбросы. Начните с него, если дамп большой и непонятно, куда смотреть.
Как читать результат и не ошибиться
Помните три ограничения. Первое: метки времени фиксируются на месте захвата, поэтому сравнивайте задержки в одном дампе, снятом на одной стороне. Если вы захватывали на клиенте, RTT включает всё, что лежит между клиентом и сервером. Второе: дамп на компьютере с нагруженным процессором и Wi-Fi-адаптером может содержать искажения по времени и потерянные пакеты самого захвата; тогда сравните с тем, что показывает tcpdump на роутере или другом узле. Третье: шифрование скрывает содержимое, но не время: анализировать задержки можно и в HTTPS-потоках.
Итоговый вывод формулируйте измеримо: например, DNS занимает столько-то миллисекунд, TCP-рукопожатие столько-то, ожидание ответа сервера столько-то, скачивание столько-то. Такая раскладка убедительна для обращения к провайдеру или владельцу сайта, а цифры без раскладки — нет. Перед отправкой дампа третьим лицам удалите чужие пакеты и незашифрованные данные.
Отдельно стоит упомянуть повторные соединения. Современные браузеры держат соединение открытым и переиспользуют его, поэтому вторая загрузка той же страницы выглядит быстрее: DNS берётся из кэша, рукопожатия нет. При сравнении «до и после» изменений в настройках делайте замеры в одинаковых условиях: очищайте кэш, закрывайте вкладки и повторяйте по три раза. Иначе вы приписываете изменению то, что дала обычная работа кэшей. Если картина воспроизводится только в определённое время суток, фиксируйте время каждого дампа и записывайте, что именно делали в этот момент: это сильно облегчает разговор со специалистом.