Сеть тормозит: как найти, где теряются пакеты (ping, mtr, traceroute)

Фраза «интернет тормозит» может означать что угодно: слабый Wi-Fi, перегруженный канал провайдера, неудачный маршрут между сетями или перегруженный сервер. Угадывать бесполезно. Ниже порядок проверки, после которого вы будете знать, на каком участке проблема, и сможете показать это поддержке в цифрах.

Ping: задержка, потери и джиттер

Начните с серии из нескольких десятков пакетов, а не с четырёх по умолчанию:

ping -c 50 example.com      # macOS и Linux
ping -n 50 example.com      # Windows

В итоговой статистике смотрите на три вещи:

• Потери: строка packet loss, в Windows Lost. Для исправной сети нормальное значение 0%. Даже небольшие постоянные потери заметно замедляют TCP: каждый потерянный сегмент приходится отправлять повторно, а протокол при этом снижает скорость.
• Задержка (RTT): время пакета туда и обратно. Linux печатает rtt min/avg/max/mdev, macOS round-trip min/avg/max/stddev, Windows минимум, максимум и среднее.
• Джиттер: разброс задержки, его показывают mdev и stddev. Если среднее ровное, а максимум в разы больше, сеть «дёргается». Это заметно в звонках, играх и при наборе текста по SSH.

Учтите, что часть серверов не отвечает на ping совсем. Отсутствие ответа ещё не значит, что сервер недоступен: проверьте его через TCP, об этом ниже.

Traceroute и tracert: путь до сервера

Пакеты идут к серверу через цепочку маршрутизаторов. Увидеть её можно так:

traceroute example.com      # macOS и Linux
tracert -d example.com      # Windows, -d отключает поиск имён узлов

Каждая строка соответствует одному узлу (хопу) и показывает время ответа на три пробных пакета. Звёздочки * * * значат, что узел не ответил. Это нормально: многие маршрутизаторы не отвечают на служебные запросы, а трафик через себя при этом пропускают.

В Linux traceroute по умолчанию отправляет UDP-пакеты, флаг -I переключает его на ICMP, а -T -p 443 на TCP к порту 443, для этого нужны права root. Windows tracert всегда использует ICMP. Главный недостаток traceroute: всего три замера на узел, и случайный всплеск по ним не отличить от настоящей проблемы. Для этого есть mtr.

mtr и pathping: статистика по каждому узлу

mtr объединяет ping и traceroute: он раз за разом опрашивает все узлы маршрута и копит статистику. Установка: sudo apt install mtr-tiny в Debian и Ubuntu, brew install mtr на macOS, запускать через sudo. Режим отчёта удобно сохранять и пересылать:

mtr --report --report-wide -c 100 example.com

-c 100 задаёт сто циклов замеров, --report-wide не обрезает длинные имена узлов. Полезные флаги: -n отключает поиск имён, -b показывает и имена, и IP-адреса, -z выводит номер автономной системы, то есть сети, которой принадлежит узел.

Если по пути отбрасывают ICMP или вы хотите проверить маршрут так, как идёт трафик к сайту, включите TCP-режим:

sudo mtr -T -P 443 --report -c 100 example.com

В Windows похожий инструмент встроен в систему: pathping -n example.com. Сначала команда строит маршрут, затем несколько минут собирает статистику потерь по каждому узлу. Дождитесь окончания: промежуточный вывод ещё не содержит итоговых цифр.

Как читать потери на промежуточных узлах

Здесь возникает больше всего ложных тревог. Маршрутизатор пересылает чужой трафик быстро и аппаратно, а на адресованные ему служебные пакеты отвечает процессором и по остаточному принципу. Многие узлы ещё и ограничивают частоту ICMP-ответов. Поэтому узел может «терять» половину пакетов mtr и при этом без потерь пропускать ваш трафик дальше.

Правило простое: смотрите, продолжаются ли потери до конца маршрута.

Помните, что обратный путь от сервера к вам может проходить через другие узлы, а traceroute и mtr показывают только прямой. Если есть доступ к серверу, запустите mtr и с его стороны, до вашего внешнего IP-адреса.

Дома, у провайдера или у сервера

Сначала исключите свою сеть. Узнайте адрес роутера: route -n get default на macOS, ip route в Linux, ipconfig в Windows, строка «Основной шлюз». Затем отправьте до него сотню пакетов, подставив свой адрес:

ping -c 100 192.168.1.1

Потери или большой разброс задержки до собственного роутера означают проблему в домашней сети: слабый сигнал Wi-Fi, помехи от соседних сетей, перегруженный роутер. Повторите проверку по кабелю или в другом диапазоне Wi-Fi, 5 ГГц вместо 2,4 ГГц.

Дальше смотрите на отчёт mtr:

• Потери начинаются с первого узла: домашняя сеть или роутер.
• Начинаются на ближайших узлах после роутера и держатся до конца: сеть провайдера. С отчётом mtr идите в его поддержку.
• Появляются на стыке сетей, где меняется номер автономной системы из -z: проблема в связности между операторами. Её решают провайдер или хостинг, иногда помогает другой маршрут.
• Видны только на последних узлах: сеть хостинга или сам сервер. Проверьте нагрузку на сервере и пишите хостеру.

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

DNS и curl: где уходит время в запросе

Медленное разрешение имён легко принять за медленную сеть: первый запрос к сайту долгий, следующие быстрые. Проверьте DNS отдельно:

dig example.com
dig @1.1.1.1 example.com
nslookup example.com 1.1.1.1    # Windows

В выводе dig смотрите строку Query time. Если системный резолвер отвечает заметно медленнее публичного, смените DNS-сервер в настройках системы или роутера.

Для HTTP-запросов curl умеет показать время каждого этапа:

curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com

Все значения в секундах и отсчитываются от начала запроса, поэтому сравнивайте разницу между соседними этапами:

Флаги -4 и -6 заставляют curl использовать только IPv4 или только IPv6. Так сразу видно, не работает ли один из протоколов хуже другого.

iperf3: пропускная способность

Ping и mtr показывают задержку и потери, но не скорость. Для неё нужен iperf3 на обоих концах. На сервере:

iperf3 -s

По умолчанию сервер слушает порт 5201, откройте его в межсетевом экране. На своём компьютере:

iperf3 -c адрес-сервера -t 30         # от вас к серверу
iperf3 -c адрес-сервера -t 30 -R      # от сервера к вам
iperf3 -c адрес-сервера -t 30 -P 4    # четыре параллельных потока

Если один поток медленный, а четыре вместе дают намного больше, канал свободен, но отдельное TCP-соединение упирается в задержку и потери. Режим -u -b 50M отправляет UDP с заданной скоростью и показывает джиттер и долю потерянных датаграмм. iperf3 полностью загружает канал, поэтому не запускайте долгие тесты на сервере с рабочим трафиком.

Что отправить в поддержку

Хостинг и провайдер быстрее реагируют на конкретные данные, чем на «у меня всё тормозит». Соберите:

• отчёт mtr --report --report-wide -c 100 до сервера, а лучше два: обычный и с -T -P 443;
• если есть доступ к серверу, такой же отчёт в обратную сторону, до вашего внешнего IP;
• дату и время проблемы с часовым поясом, а также постоянная она или появляется в определённые часы;
• вывод curl -w с разбивкой по этапам;
• тип подключения, Wi-Fi или кабель, и повторяется ли проблема из другой сети, например с мобильного интернета;
• результаты iperf3, если вопрос в скорости.

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

Коротко

• ping -c 50: потери, средняя задержка и разброс.
• Сначала проверьте ping до своего роутера, чтобы исключить Wi-Fi.
• mtr --report -c 100 вместо traceroute: статистика по каждому узлу.
• Потери в середине маршрута, которые не доходят до конца, не проблема.
• Реальные потери держатся от проблемного узла до последнего.
• mtr -T -P 443, если по пути отбрасывают ICMP.
• DNS проверяйте через dig, этапы HTTP через curl -w.
• Скорость меряйте iperf3, в обе стороны и в несколько потоков.
• В поддержку отправляйте отчёты mtr в обе стороны и время проблемы.