ping и трассировка: что они показывают, а что нет

Ник у меня, конечно, обязывает, но вопрос детский.

Пингую целевую площадку, получаю 22 мс, красота. Открываю страницу, она грузится три с половиной секунды. Запускаю трассировку, на седьмом узле идут звёздочки и до конца так и не доходит.

Площадка лежит? Провайдер режет? Куда вообще смотреть после такого вывода.

Ни то и ни другое, скорее всего у вас всё в порядке.

Ping отправляет маленький пакет ICMP и ждёт такой же в ответ. Он меряет одно: сколько времени пакет летит туда и обратно. Ни соединения, ни шифрования, ни работы самой площадки в этих 22 мс нет вовсе.

Страница за три секунды это совсем другая цепочка: спросить имя у службы имён, поднять TCP, согласовать шифрование, отправить запрос, дождаться, пока сервер сходит в свою базу, забрать тело ответа. Из всего перечисленного ping закрывает только дорогу до двери.

Звёздочки в трассировке означают, что узел не ответил. Молчание узла и обрыв пути это разные вещи.

а звёздочки прямо совсем не страшно? их там четыре штуки подряд

Молчат узлы по трём причинам, и все три обычные.

Первая: ответы на такие пакеты идут мимо быстрого железа, их готовит слабый процессор внутри маршрутизатора, и приоритет у этой работы низкий. Загружен, значит ответит с задержкой или пропустит.

Вторая: у узла стоит ограничение по частоте на эти ответы, и он отвечает одному из десяти.

Третья: администратор просто выключил ответы.

Смотреть надо на последнюю строку. Дошла трассировка до цели, значит путь есть, а звёздочки в середине это шум.

И лучше сразу mtr вместо разовой трассировки, он гоняет пакеты по кругу и показывает потери на каждом узле в процентах.

Плюс к mtr: он же снимает главную путаницу с потерями. Потери на промежуточном узле почти ничего не значат, потери на последней строке значат много.

Ещё один приём для случая, когда ICMP режут целиком: трассировка по TCP на нужный порт. Идёт она теми же пакетами, какими пойдёт рабочий трафик, и часто доходит там, где обычная упирается в стену.

Проверил, дошло до конца. Тогда второй вопрос: а через посредника пинговать можно? Мне надо померить отклик именно того пути, по которому идёт сбор.

Нельзя, и это частая ловушка. Посредник передаёт TCP, а ping ходит пакетами ICMP, которые в такой канал не попадают вовсе. Что бы вы ни настроили в системе, ping уйдёт напрямую с вашей машины и покажет дорогу мимо посредника.

Мерить надо тем же способом, каким работаете. Берите время установки соединения и время до первого байта, curl отдаёт их одной строкой. Вот это будут честные числа.

Готовая команда, чтобы не собирать по кускам:

curl -o /dev/null -s -x http://user:pass@203.0.113.10:8000 \
  -w "connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n" \
  https://example.org/

Прогнать раз тридцать и взять середину, разовый замер тут ничего не стоит.

Добавлю сбоку. Трассировка с вашей машины показывает вашу дорогу до площадки. У посредника дорога своя, и она может идти совсем другими узлами. Поэтому красивая трассировка с рабочей машины ничего не обещает про рабочий путь.

Вот это место люди путают чаще всего, да.

Собрал у себя, чтобы не забыть.

Ping говорит про дорогу до узла и молчит про работу площадки. Звёздочки в середине трассы это норма, смотреть надо на последнюю строку. Через посредника ping не ходит вовсе, там мерят временем соединения и первого байта.

Мои три с половиной секунды оказались временем ответа самой площадки: соединение поднимается за 40 мс, а первый байт приходит через три секунды. Ушёл читать, чем они там заняты.