Проверка скорости сети сервера

У каждого выделенного сервера собственный порт 10 Гбит/с. В этом руководстве показано, как правильно измерить его скорость, почему некоторые тесты показывают меньше и что отправить в поддержку, если вы подозреваете проблему. Вам понадобятся root-доступ и либо второй сервер, либо ближайший публичный сервер iperf3.

Чего ожидать

Канал 10 Гбит/с передаёт не более примерно 9,4 Гбит/с данных TCP при стандартном размере пакета 1 500 байт; остальное занимают заголовки протоколов. Ваш порт ни с кем не делится, но, как и в любой сети, аплинки за ним общие. Поэтому реальная пропускная способность зависит также от маршрута до другой стороны и от самой другой стороны.

Почему один поток или удалённый сервер показывают меньше

Одно TCP-соединение не может отправить за один цикл приёма-передачи (RTT) больше, чем позволяет его окно. При RTT 100 мс, чтобы загрузить канал 10 Гбит/с, в пути должно находиться 125 МБ данных — это намного больше стандартных лимитов буферов Linux. Кроме того, каждый потерянный пакет замедляет соединение на много циклов, и с расстоянием этот эффект усиливается. Несколько параллельных потоков скрывают оба ограничения.

У публичных тестовых серверов есть собственные ограничения: у многих порт 1 или 10 Гбит/с, который делят все, кто тестирует в этот момент. Однопоточный тест до другого континента больше говорит о маршруте, чем о вашем порте.

Тест с помощью iperf3

Установите iperf3 командой sudo apt install iperf3 или sudo dnf install iperf3. Выберите сервер рядом с вашей локацией из списка публичных серверов iperf3, запишите его порт и проверьте оба направления в восемь параллельных потоков:

iperf3 -c <iperf-server> -p 5201 -P 8 -t 30 -O 3        # your server sends
iperf3 -c <iperf-server> -p 5201 -P 8 -t 30 -O 3 -R     # your server receives

-P 8 открывает восемь потоков, -t 30 запускает тест на 30 секунд, -O 3 отбрасывает первые три секунды, пока TCP разгоняется, а -R меняет направление на обратное. --bidir проверяет оба направления одновременно.

Начиная с версии 3.16, iperf3 обрабатывает каждый поток данных в отдельном потоке выполнения. Более старые версии — например, в Debian 12 и в AlmaLinux или Rocky Linux 9 — обрабатывают все потоки на одном ядре CPU. Если top показывает, что iperf3 загружает ядро на 100%, запустите два-три экземпляра на разных портах; многие публичные серверы принимают диапазон портов, например 5200–5209.

Тест между двумя вашими серверами

Самый чистый тест — между двумя серверами, которыми вы управляете. На сервере A запустите сервер iperf3, который завершится после одного теста; с сервера B подключитесь к нему:

iperf3 -s -1                                  # on server A
iperf3 -c 203.0.113.10 -P 8 -t 30 -O 3        # on server B

На время теста откройте TCP-порт 5201 в файрволе сервера A, а после закройте его. Два сервера в одной локации проверяют сами порты; серверы в разных локациях — маршрут между ними.

Тест с помощью Speedtest CLI

Speedtest by Ookla измеряет скорость до серверов интернет-провайдеров по всему миру. Установите официальный CLI с speedtest.net/apps/cli, а не старый неофициальный Python-пакет speedtest-cli. Затем:

speedtest --accept-license -L          # list nearby servers
speedtest --accept-license -s 12345    # test against a server ID from that list

Пропускная способность серверов Speedtest сильно различается, поэтому попробуйте два-три сервера, прежде чем делать выводы.

Настройка Linux для передачи на большие расстояния

Увеличенные буферы TCP позволяют каждому соединению держать в пути больше данных. Сохраните эти настройки в файл /etc/sysctl.d/90-network-tuning.conf:

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.ipv4.tcp_mtu_probing = 1
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Примените их командой sudo sysctl --system. Размеры буферов соответствуют рекомендациям ESnet для хостов 10 Гбит/с на маршрутах с RTT до 100 мс и действуют также для IPv6. BBR обычно лучше справляется с потерей пакетов на длинных маршрутах, чем CUBIC, используемый по умолчанию; чтобы оставить CUBIC, удалите последнюю строку. Проверьте результат командой sysctl net.ipv4.tcp_congestion_control.

Как читать результаты

[SUM]   0.00-30.00  sec  32.8 GBytes  9.39 Gbits/sec  112             sender
[SUM]   0.00-30.00  sec  32.8 GBytes  9.38 Gbits/sec                  receiver

• Смотрите на строку receiver: она учитывает то, что действительно дошло.
• Число после скорости в строке sender — это количество повторных передач TCP. Некоторое их количество нормально для интернет-маршрутов; тысячи повторных передач в сочетании с низкой скоростью указывают на потерю пакетов.
• Скорость указана в битах. Чтобы получить байты, разделите на 8: 9,4 Гбит/с — это примерно 1,17 ГБ/с.
• Если результаты меняются в зависимости от времени суток или сильно различаются между целями, ограничение находится на маршруте или на удалённой стороне, а не на вашем порте.

Сообщить о проблеме

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

• IP-адрес вашего сервера и цели тестов;
• полные команды iperf3 и их вывод с временем каждого теста в UTC;
• отчёт mtr в обоих направлениях: от вашего сервера до цели и от цели (или из вашей собственной сети) обратно до вашего сервера.

mtr -rwbzc 100 <target-ip>

Установите mtr командой sudo apt install mtr-tiny или sudo dnf install mtr. Маршрутизация в интернете часто асимметрична: обратный путь может отличаться от прямого, поэтому одно направление редко даёт полную картину. Потери, которые видны на одном хопе, но не продолжаются до последнего, обычно означают, что маршрутизатор ограничивает частоту собственных ответов, а не реальную потерю пакетов.