Один результат speedtest не показывает, где находится проблема. Скорость может ограничивать тариф, Ethernet-порт, Wi‑Fi, роутер, VPN, удалённый сервер или само приложение. Надёжная диагностика сравнивает повторяемые измерения по кабелю и радио, внутри локальной сети и через интернет.
1. Опишите симптом измеримыми признаками
Запишите время, устройство, подключение, приложение, направление передачи и ожидаемый тариф. «Интернет тормозит» может означать низкий throughput, высокий ping, потери, медленный DNS или перегруженный сервис.
| Симптом | Основная метрика | Первый тест |
|---|---|---|
| файл скачивается медленно | Мбит/с и стабильность | проводной speed test |
| видеозвонок заикается | latency, jitter, loss | ping и тест под нагрузкой |
| сайты долго начинают открываться | DNS и TTFB | nslookup/curl |
| медленно только по Wi‑Fi | RSSI, канал, PHY | iperf3 в LAN |
Единицы и пределы измерения
Тариф и iperf обычно показывают мегабиты в секунду, а загрузчик файлов — мегабайты. 100 Мбит/с теоретически соответствуют 12,5 МБ/с до накладных расходов. Для двоичных MiB преобразование другое; не сравнивайте числа без единиц. Ethernet 1 Гбит/с не обязан дать приложению ровно 1000 Мбит/с: часть полосы занимает framing, TCP/IP и служебный обмен. Wi-Fi PHY rate ещё дальше от полезной скорости и зависит от конкуренции за эфир.
Однопоточная TCP-передача может ограничиваться RTT и окнами, а многопоточный тест достигать большей суммарной полосы. Это не противоречие. Когда speedtest показывает высокий download, но один файл медленный, проверьте сервер файла, один TCP-поток, потери и приложение. Более десяти параллельных тестов создают дополнительную конкуренцию и не помогают локализации.
2. Подготовьте чистый проводной baseline
Подключите один компьютер гигабитным кабелем к проверяемому роутеру, отключите Wi‑Fi и VPN, остановите синхронизацию и загрузки. Проверьте согласованную скорость Ethernet: линк 100 Мбит/с не сможет показать гигабитный тариф.
Get-NetAdapter | Select-Object Name,Status,LinkSpeed,MediaType
Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
Sort-Object RouteMetric | Select-Object -First 3На корпоративной сети не обходите firewall или прокси без согласования.
Ethernet и ошибки интерфейса
В Linux проверьте negotiated speed и duplex, затем сравните счётчики до и после теста. Не задавайте вручную speed/duplex как универсальное решение: это может создать mismatch.
ip -s link show dev enp1s0
sudo ethtool enp1s0
sudo ethtool -S enp1s0Имя интерфейса подставьте из ip -br link. Рост CRC/frame errors указывает на тракт кабеля/порт/адаптер, drops требует контекста очередей и драйвера. В Windows полезны Get-NetAdapterStatistics и LinkSpeed. В маршрутизаторе сопоставьте LAN и WAN: гигабитный клиентский порт не подтверждает гигабитный uplink.
3. Повторите интернет-тест несколько раз
Выберите близкий сервер и выполните не менее трёх тестов загрузки и отдачи. Повторите в часы проблемы и вне пика. Браузер, CPU и расширения тоже влияют на результат, поэтому фиксируйте инструмент и сервер.
Сравнивайте медиану, минимальное значение и разброс. Единичный высокий показатель не отменяет провалов, а единичный низкий может быть случайной перегрузкой тестового узла.
4. Измерьте локальную сеть с iperf3
Чтобы отделить LAN и Wi‑Fi от провайдера, запустите iperf3 на двух доверенных узлах внутри сети. Сервер слушает порт 5201, клиент создаёт поток. Не публикуйте iperf3 в интернет без firewall и окна теста.
# На проводном сервере внутри LAN
iperf3 -s
# На проверяемом клиенте
iperf3 -c 192.0.2.10 -P 4 -t 30
iperf3 -c 192.0.2.10 -P 4 -t 30 -RКлюч -R меняет направление. Несколько потоков помогают увидеть доступную полосу, но не отражают поведение одного приложения.
Воспроизводимая лаборатория iperf3
Возьмите два узла с исправными гигабитными портами и кабелями. Сервер подключён проводом к тому же LAN; клиент сначала тоже подключите проводом, затем замените только клиентское подключение на Wi-Fi. Примерный адрес сервера 192.0.2.10 необходимо заменить фактическим частным адресом. Установите iperf3 из репозитория ОС, зафиксируйте версию на обоих узлах.
sudo apt-get update
sudo apt-get install iperf3
iperf3 --version
ip -br address
# На сервере, обычным пользователем, одна тестовая сессия:
iperf3 -s -B 192.0.2.10 -p 5201 -1-B ограничивает адрес прослушивания, -1 завершает сервер после одного теста. Для следующего прогона запустите его снова. Firewall разрешает 5201/TCP только от тестового клиента. Для UDP-теста нужен также 5201/UDP; управляющее TCP-соединение всё равно необходимо. Не выключайте весь firewall. В Windows используйте доверенную сборку по политике компании либо отдельную Linux-VM; у проекта ESnet нет обещания одинаковой поддержки всех сторонних Windows-бинарников.
# Клиент: сначала один поток, затем отдельный обратный тест.
iperf3 -c 192.0.2.10 -p 5201 -t 20 -O 3 -P 1 -J > lan-forward.json
# Перед этим сервер запускается снова.
iperf3 -c 192.0.2.10 -p 5201 -t 20 -O 3 -P 1 -R -J > lan-reverse.json-t ограничивает время, -O 3 исключает начальный разгон из статистики, -P 1 проверяет один поток, -R заставляет сервер отправлять данные клиенту. При обычном тесте клиент отправляет серверу: это направление upload относительно клиента. Обратный тест соответствует download относительно клиента. Выбирайте итоговую статистику receiver для полученной полезной полосы; sender и receiver могут немного расходиться.
Как прочитать JSON и не принять пример за измерение
После успешного TCP-теста поле end.sum_received.bits_per_second показывает итоговую принятую полосу. Объект error означает неуспешный тест; наличие файла ещё не означает готового измерения. Следующий небольшой анализатор работает с реально сохранёнными файлами, не подставляет выдуманные скорости.
import json
from pathlib import Path
for name in ("lan-forward.json", "lan-reverse.json"):
data = json.loads(Path(name).read_text(encoding="utf-8"))
if data.get("error"):
raise SystemExit(f"{name}: {data['error']}")
result = data["end"]["sum_received"]
print(name, round(result["bits_per_second"] / 1_000_000, 1), "Mbit/s")Пример 920 Мбит/с по кабелю и 180 Мбит/с по Wi-Fi при том же сервере позволяет локализовать ограничение в клиентском радиосегменте, но ещё не назвать причину: эфир, ширина канала, драйвер, сигнал и возможности устройства требуют отдельной проверки. 94 Мбит/с и по кабелю, и по Wi-Fi заставляют сначала искать 100-мегабитный порт на общем пути. Это учебные примеры, не результаты измерения вашего подключения.
5. Сравните кабель и Wi-Fi в одной точке
Сначала измерьте кабель, затем Wi‑Fi тем же устройством, сервером и маршрутом. Запишите диапазон, канал, ширину, уровень сигнала, модель точки и расстояние. Изменение нескольких условий сразу делает сравнение бесполезным.
Для Wi‑Fi важны не только Мбит/с, но и повторяемость. Высокая PHY-скорость в интерфейсе не равна полезной TCP-скорости: эфир делится с соседями и содержит служебный трафик.
6. Измерьте задержку, jitter и потери
Проверяйте сначала шлюз, затем стабильный внешний адрес и нужный сервис. Потери до шлюза указывают на локальный сегмент; только дальше — на WAN или маршрут. Некоторые узлы ограничивают ICMP, поэтому вывод подтверждают прикладным тестом.
ping -n 50 192.168.1.1
ping -n 50 1.1.1.1
pathping 1.1.1.1Особенно полезен тест под одновременной загрузкой: резкий рост задержки может показать очередь и bufferbloat.
Контролируемый UDP и bufferbloat
UDP не регулирует скорость как TCP. Без установленного -b и без понимания направления тест легко перегрузит сегмент. Начните с небольшой доли ожидаемой полосы, например 10 Мбит/с на гигабитном учебном LAN, и ограничьте время. Сервер заранее разрешает UDP-порт только клиенту.
iperf3 -c 192.0.2.10 -u -b 10M -t 15Читайте итог receiver: число потерянных датаграмм, процент loss и jitter. Повышайте нагрузку небольшими шагами при согласованном окне. Jitter iperf относится к этому потоку и не является универсальной оценкой качества любого видеосервиса. Потери на ограниченном UDP-тесте вместе с задержкой до шлюза помогают отличить радио от внешнего маршрута.
Для bufferbloat сначала измерьте ping без нагрузки, затем повторите тот же ping одновременно с ограниченным upload и отдельно download. Если RTT до внешней цели вырастает со стабильного уровня до сотен миллисекунд только при насыщении upload, изучите очередь исходящего канала и SQM/QoS. Если растёт уже RTT до локального шлюза, возможны радио, CPU роутера или его ICMP scheduling. Не диагностируйте провайдера по одному ping самого роутера.
7. Отделите DNS и приложение от полосы
Если speed test нормален, а сайт открывается медленно, измерьте DNS, TCP/TLS и время первого байта. Сравните несколько доменов и повторите без кеша. Не назначайте публичный DNS как универсальное лечение корпоративной сети: он может сломать внутренние зоны.
curl -o /dev/null -sS -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/
nslookup example.comDNS, TLS и первый байт: разности времён curl
Поля curl являются накопленными отметками от начала запроса. Оценка TCP-фазы — time_connect минус time_namelookup; TLS-фазы — time_appconnect минус time_connect для HTTPS. time_starttransfer включает разрешение, соединение, TLS и ожидание ответа. Поэтому нельзя назвать всё TTFB «медленной базой данных».
curl --connect-timeout 5 --max-time 20 -sS -o /dev/null \
-w 'code=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} tcp_at=%{time_connect} tls_at=%{time_appconnect} first_byte_at=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/Проверка certificate остаётся включённой; не используйте -k как ускорение. Повторение может попасть в DNS/TLS-кэш или другой CDN-узел, поэтому сохраняйте remote_ip и время. Маркетологу такой тест помогает отделить полосу доступа от начала ответа сайта; для вывода о backend нужны серверные метрики.
8. Проверьте роутер, QoS и ограничения
На пограничном устройстве смотрите CPU, память, загрузку интерфейсов, ошибки, drops, NAT sessions и фактическую скорость порта. IDS/IPS, VPN, PPPoE, QoS и аппаратное ускорение могут менять предел. После каждого изменения повторяйте одинаковый тест.
Если канал занят другими пользователями, снимите график интерфейса. Ограничение по тарифу отличается от насыщения uplink и от перегрузки CPU роутера.
9. Соберите матрицу результатов
Минимальная матрица содержит дату, устройство, подключение, направление, сервер, ping, download, upload и примечания. Для Wi‑Fi добавьте точку, диапазон и сигнал. Для каждой комбинации сделайте три прогона.
- LAN iperf3 по кабелю показывает предел локальных портов;
- LAN iperf3 по Wi‑Fi показывает радио без влияния провайдера;
- WAN-тест по кабелю показывает роутер и канал;
- WAN-тест по Wi‑Fi показывает совокупный пользовательский сценарий.
Такая таблица превращает жалобу в локализованную неисправность.
10. Сформулируйте вывод и данные для эскалации
Укажите доказанный участок: клиент, Wi‑Fi, LAN, роутер, канал провайдера, маршрут или сервис. После исправления повторите ту же матрицу. Эскалация провайдеру полезна, когда есть проводной baseline, точное время, договорная скорость, идентификатор линии, серия тестов и потери на внешнем участке.
Итоговый протокол для провайдера или администратора
В каждой строке отчёта укажите локальное время и timezone, интерфейс, сервер, направление, число потоков, длительность, объём трафика, скорость, RTT без нагрузки и под нагрузкой. Для трёх повторов считайте медиану и диапазон, сохраняя все исходные результаты. 20-секундный тест на 1 Гбит/с может передать примерно 2,5 ГБ в одном направлении; ограничьте окно на тарифицируемых каналах.
Если LAN исправен, а все WAN-серверы дают одинаковый предел, проверьте роутер, тариф и uplink. Если медлен только один endpoint, изучите маршрут и сервер. Если без VPN нормально, сравните туннель, шифрование, MTU и его endpoint, сохраняя корпоративную политику доступа. После исправления повторите исходную матрицу без изменения устройства и метода. Окончание теста включает остановку iperf3 и удаление только временного firewall-правила, если оно создавалось.
Источники: ESnet — iperf3 documentation, Cloudflare Speed Test, Microsoft Learn — Get-NetAdapter.
Дополнительная документация: ESnet: аргументы iperf3, curl: справочник.