Артём Савельев 
iperf3: как измерить реальную скорость канала — 14 команд с разбором цифр
Хостер продал гигабит, а файл едет на 300 Мбит/с. Спидтест в браузере показывает одно, копирование по SSH — другое. iperf3 отвечает на вопрос точно: сколько канал отдаёт между двумя вашими машинами, без веб-серверов, дисков и CDN в середине.
iperf3 — утилита для измерения пропускной способности сети между двумя хостами: один запускается сервером, второй подключается клиентом и они гонят друг другу синтетический трафик. Она измеряет только сеть: диск, веб-сервер и приложение в замер не попадают. Актуальная версия — 3.21 (апрель 2026), утилита есть в репозиториях всех распространённых дистрибутивов и собирается под Windows и macOS.
Что iperf3 показывает, а что нет
iperf3 измеряет канал между двумя точками, которые вы контролируете, — и больше ничего. Это его сила и его ограничение: результат нельзя интерпретировать как «скорость сайта».
| Вопрос | Ответит ли iperf3 |
|---|---|
| Сколько отдаёт канал между моим сервером и офисом | Да, это его прямая задача |
| Хостер режет полосу или нет | Да, при своём сервере на втором конце |
| Есть ли потери и джиттер на маршруте | Да, в режиме UDP |
| Почему медленно грузится сайт | Нет — там сервер, база, рендер |
| Какая скорость до пользователей в Новосибирске | Нет — нужен хост в Новосибирске |
| Доступен ли сайт прямо сейчас | Нет, это задача мониторинга |
Первый тест: сервер и клиент
iperf3 всегда требует два конца. На одной машине поднимается сервер, на другой запускается клиент. Порт по умолчанию — 5201, TCP и UDP.
# на сервере iperf3 -s # на клиенте iperf3 -c 203.0.113.10
Установка: apt install iperf3 в Debian и Ubuntu, dnf install iperf3 в RHEL-семействе, apk add iperf3 в Alpine. Версии 2 и 3 между собой несовместимы: iperf3-клиент не соединится с iperf-сервером второй ветки.
Второй клиент получит the server is busy running a test. Это не баг: запрос на поддержку нескольких клиентов закрыт разработчиками как wontfix. Если тестируете с нескольких машин — поднимайте несколько серверов на разных портах через -p.
Значения по умолчанию, которые стоит знать наизусть
Половина «странных» результатов объясняется тем, что человек не знал дефолт. Особенно это касается UDP: без -b тест пойдёт на 1 Мбит/с и покажет идеальную картину на любом канале.
| Параметр | По умолчанию | Чем грозит |
|---|---|---|
| Порт | 5201 | Закрыт файрволом — тест не стартует |
| Длительность | 10 секунд | Мало: половину съедает разгон TCP |
| Потоков | 1 | На длинном RTT занижает результат в разы |
| Интервал отчёта | 1 секунда | — |
| Битрейт TCP | без ограничения | — |
| Битрейт UDP | 1 Мбит/с | Тест «ничего не нашёл» на любом канале |
| Направление | клиент → сервер | Асимметричный канал не виден |
Ключи, которые нужны на практике
Из нескольких десятков опций в реальной работе используются полтора десятка. Вот они.
| Ключ | Что делает |
|---|---|
| -s / -c host | Режим сервера / клиента |
| -p 5202 | Другой порт — обойти фильтрацию или поднять второй сервер |
| -t 30 | Длительность в секундах. Меньше 20 — несерьёзно |
| -O 5 | Выбросить первые 5 секунд — обходит медленный старт TCP |
| -P 8 | Восемь параллельных потоков |
| -R | Реверс: сервер шлёт клиенту (проверка входящей полосы) |
| --bidir | Обе стороны одновременно |
| -u -b 500M | UDP с целевой скоростью 500 Мбит/с |
| -w 4M | Размер TCP-окна вручную |
| -i 0 | Отключить промежуточные отчёты |
| -J | Вывод в JSON — для скриптов и графиков |
| -M 1400 | Задать MSS — проверить гипотезу про MTU |
| -4 / -6 | Только IPv4 или только IPv6 |
| -1 | Сервер обслужит один тест и выйдет |
Как читать вывод TCP
В TCP-тесте четыре колонки, и самая полезная из них — не Bitrate, а Retr. Она показывает число ретрансмиссий: если оно не ноль, в канале есть потери или перегрузка.
[ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 112 MBytes 940 Mbits/sec 0 412 KBytes [ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 412 KBytes [ 5] 2.00-3.00 sec 109 MBytes 914 Mbits/sec 18 298 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ 5] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec 18 sender [ 5] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec receiver
| Колонка | Значение | Когда тревожно |
|---|---|---|
| Transfer | Объём за интервал | — |
| Bitrate | Фактическая скорость | Скачет между интервалами больше чем на 20% |
| Retr | Ретрансмиссии TCP | Больше нуля — потери в канале |
| Cwnd | Окно перегрузки на конец интервала | Проседает после каждого Retr |
Строки sender и receiver в итоге почти всегда расходятся на доли процента — это нормально, часть данных на момент завершения ещё была в пути.
Почему 940 Мбит/с на гигабите — это и есть сто процентов
Самый частый вопрос к iperf3: «канал гигабитный, почему 940?» Потому что гигабит — это скорость на проводе, а iperf3 считает полезные данные. Разницу съедают заголовки, и её можно посчитать точно.
| Что занимает место в кадре | Байт |
|---|---|
| Полезная нагрузка TCP | 1460 |
| Заголовок TCP | 20 |
| Заголовок IP | 20 |
| Заголовок Ethernet | 14 |
| Контрольная сумма FCS | 4 |
| Преамбула | 8 |
| Межкадровый интервал | 12 |
| Итого на проводе | 1538 |
1460 ÷ 1538 = 94,9%. От гигабита это 949 Мбит/с — теоретический потолок. Если в TCP включены timestamps (а они включены почти везде), полезной нагрузки остаётся 1448 байт, и потолок опускается до 941 Мбит/с. Именно эта цифра и появляется в выводе iperf3 на исправном гигабитном канале.
Гигабит: 930–950 Мбит/с — норма, 800–900 — стоит посмотреть Retr, ниже 700 — искать причину. Десять гигабит: расчётный потолок при MTU 1500 составляет около 9,4–9,5 Гбит/с, но одним потоком без тюнинга обычно выходит меньше — помогают jumbo frames и несколько потоков.
Почему один поток проседает на длинных маршрутах
Одно TCP-соединение не может отправить больше данных, чем помещается в окно, пока не дождётся подтверждения. Формула простая:
Максимум одного потока (бит/с) = Окно (байт) × 8 ÷ RTT (секунды) Нужное окно (байт) = Полоса (бит/с) × RTT (секунды) ÷ 8
| Канал | RTT | Нужное окно | Если окно 6 МБ |
|---|---|---|---|
| 1 Гбит/с, внутри города | 5 мс | 625 КБ | упирается в канал |
| 1 Гбит/с, Москва — Владивосток | 100 мс | 12,5 МБ | 480 Мбит/с |
| 10 Гбит/с, межрегион | 30 мс | 37,5 МБ | 1,6 Гбит/с |
| Без масштабирования окна (64 КБ) | 100 мс | — | 5,2 Мбит/с |
Отсюда практическое правило: на маршруте с RTT больше 20–30 мс всегда запускайте -P 4 или -P 8. Один поток на таком маршруте измеряет не канал, а размер TCP-окна.
Как тестировать UDP и что значит джиттер
UDP-режим отвечает на другой вопрос: не «сколько влезет», а «сколько теряется и насколько ровно идёт». Это важно для VoIP, видеосвязи, игровых серверов и VPN-туннелей.
iperf3 -c 203.0.113.10 -u -b 200M -t 30 [ ID] Interval Transfer Bitrate Jitter Lost/Total [ 5] 0.00-30.00 sec 715 MBytes 200 Mbits/sec 0.041 ms 212/517843 (0.041%)
| Показатель | Хорошо | Терпимо | Плохо |
|---|---|---|---|
| Потери для передачи данных | 0% | до 0,1% | больше 0,5% |
| Потери для голоса и видео | до 0,5% | до 1% | больше 2% |
| Джиттер | до 1 мс | до 20 мс | больше 30 мс |
Джиттер — это усреднённый разброс во времени прихода соседних пакетов. Канал может отдавать заявленную полосу и при этом быть непригодным для звонков, если пакеты приходят рывками.
Четырнадцать команд под конкретные задачи
# 1. Честный базовый замер: 30 секунд, первые 5 выбрасываем iperf3 -c 203.0.113.10 -t 30 -O 5 # 2. Проверить входящую полосу (сервер шлёт нам) iperf3 -c 203.0.113.10 -R -t 30 # 3. Обе стороны одновременно — ищем асимметрию iperf3 -c 203.0.113.10 --bidir -t 30 # 4. Длинный маршрут: восемь потоков iperf3 -c 203.0.113.10 -P 8 -t 60 -O 5 # 5. Дотянуться до гигабита вручную заданным окном iperf3 -c 203.0.113.10 -w 16M -t 30 # 6. UDP: держим 200 Мбит/с и смотрим потери iperf3 -c 203.0.113.10 -u -b 200M -t 30 # 7. UDP без ограничения — найти точку, где начинаются потери iperf3 -c 203.0.113.10 -u -b 0 -t 20 # 8. Проверить гипотезу про MTU: уменьшаем MSS iperf3 -c 203.0.113.10 -M 1400 -t 20 # 9. Обойти фильтрацию: тест поверх 443-го порта iperf3 -s -p 443 # на сервере iperf3 -c 203.0.113.10 -p 443 -t 30 # 10. Только IPv6 iperf3 -c 2001:db8::1 -6 -t 30 # 11. Машиночитаемый вывод для графиков iperf3 -c 203.0.113.10 -t 30 -J > result.json # 12. Забрать статистику серверной стороны в тот же вывод iperf3 -c 203.0.113.10 -t 30 --get-server-output # 13. Разовый сервер, который сам закроется после теста iperf3 -s -1 -p 5202 # 14. Скорость в мегабайтах в секунду, без промежуточных строк iperf3 -c 203.0.113.10 -f M -i 0 -t 30
Пять ошибок, которые портят замер
| Ошибка | Что получается | Как правильно |
|---|---|---|
| Тест на 10 секунд | Половину времени TCP разгоняется | -t 30 -O 5 |
| Один поток на дальнем маршруте | Замер окна вместо канала | -P 8 |
UDP без -b |
1 Мбит/с и нулевые потери | Задать целевой битрейт явно |
| Публичный чужой сервер | Мерите весь интернет, а не свой канал | Свой сервер на втором конце |
| Слабый VPS как второй конец | Упор в процессор, а не в сеть | Смотреть загрузку CPU во время теста |
Про многопоточность отдельно: до версии 3.16 iperf3 был полностью однопоточным и упирался примерно в 25 Гбит/с независимо от железа. С 3.16 каждый поток теста выполняется в своём потоке ОС — на канале 200 Гбит/с зафиксировано около 160 Гбит/с. Но выигрыш появляется только при -P больше единицы: один тестовый поток по-прежнему живёт на одном ядре.
Чего iperf3 не заменяет
iperf3 — это разовый замер двумя руками: нужен доступ к обеим машинам, свободное окно и человек, который запустит команду. Он отвечает на вопрос «какой канал сейчас», но не на вопрос «что было в три часа ночи, когда упали заказы».
Для постоянного контроля нужны другие инструменты: проверка отклика по ICMP покажет, дошёл ли пакет до хоста и за сколько, а проверка TCP-порта — принимает ли сервис соединения. Обе работают круглосуточно и не требуют доступа ко второму концу.
Пруфен проверяет доступность и время отклика с интервалом от 2 минут из 13 точек мониторинга и присылает уведомление в Email, Telegram или Макс, когда сервер перестал отвечать; если ресурс так и не поднялся, подключается голосовой звонок. iperf3 скажет, что канал сегодня отдаёт 940 Мбит/с; мониторинг скажет, что позавчера в 03:40 он не отдавал ничего сорок минут.