На этой странице
«Сеть тормозит» может означать низкую пропускную способность, высокую задержку, джиттер или потери пакетов, а причина может быть на вашем сервере, на удаленной стороне или где-то между ними. Описанные ниже инструменты позволяют отличить одно от другого. Сначала установите их.
Ubuntu и Debian (на вопрос, запускать ли iperf3 как демон, ответьте No):
apt install -y iperf3 mtr-tiny curlAlmaLinux и Rocky Linux
dnf install -y iperf3 mtr curlКакой скорости ожидать
Скорость порта — это «сырая» скорость линии. Часть ее занимают кадрирование Ethernet и заголовки IP и TCP, поэтому при стандартном MTU 1500 байт максимально возможная скорость передачи полезной нагрузки TCP составляет около 94% от скорости порта:
| Порт | Макс. полезная скорость TCP | В байтах |
|---|---|---|
| 1 Гбит/с | ≈ 940 Мбит/с | ≈ 117 МБ/с |
| 10 Гбит/с | ≈ 9,4 Гбит/с | ≈ 1,17 ГБ/с |
Таким образом, скорость 940 Мбит/с на порту 1 Гбит/с означает, что канал загружен полностью, а не работает хуже ожидаемого. Достижение такой скорости до конкретного адресата зависит также от удаленного сервера, его собственного порта и пути между ними, а для 10 Гбит/с обычно нужно несколько параллельных потоков. Трафик на портах DediJet безлимитный, поэтому тесты не требуют дополнительных затрат (см. Безлимитный трафик простыми словами). Тарифы с портом 1 Гбит/с можно перевести на 10 Гбит/с за
Измерение пропускной способности с помощью iperf3
iperf3 измеряет «сырую» пропускную способность TCP или UDP между двумя машинами, которыми вы управляете, без участия дисков и веб-серверов. Самый чистый тест — между двумя вашими собственными серверами: через публичную сеть или, если они находятся в одной локации, через бесплатную приватную VLAN, которая предоставляется по запросу.
Запуск теста
На принимающем сервере откройте порт и запустите одноразовый сервер, который завершит работу после одного теста:
ufw allow 5201/tcp
iperf3 -s -1С firewalld используйте firewall-cmd --add-port=5201/tcp; без --permanent правило исчезнет при следующей перезагрузке конфигурации. Затем на другом сервере выполните одну из этих команд, каждый раз заново запуская перед ней iperf3 -s -1:
iperf3 -c 203.0.113.20 -t 30
iperf3 -c 203.0.113.20 -t 30 -R
iperf3 -c 203.0.113.20 -t 30 -P 4Первая команда передает данные от клиента к серверу, -R меняет направление на обратное, а -P 4 запускает четыре параллельных потока. После теста удалите правило файрвола с помощью ufw delete allow 5201/tcp.
Как читать результаты
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.00 sec 3.28 GBytes 939 Mbits/sec 12 sender
[ 5] 0.00-30.04 sec 3.28 GBytes 938 Mbits/sec receiverВ этом примере вывода показан полностью загруженный канал 1 Гбит/с. Строка receiver — это то, что фактически дошло до получателя. Retr — число повторных передач TCP: несколько — это норма, а тысячи указывают на потери или перегрузку на пути.
- Один поток медленный, четыре — быстрые: ограничение на уровне отдельного потока, например окно TCP на большом расстоянии. Одному потоку нужно окно размером «пропускная способность × время приема-передачи (RTT)»: 1 Гбит/с × 150 мс ≈ 19 МБ — больше, чем позволяют настройки Linux по умолчанию.
- Быстро только в одном направлении: сравните результаты запусков с
-Rи без него. Проблема только в одном направлении — полезная информация для тикета. - Тесты на 10 Гбит/с: версии iperf3 до 3.16 выполняют все потоки на одном ядре процессора, которое может стать узким местом. Проверьте версию с помощью
iperf3 --versionили запустите несколько процессов iperf3 на разных портах с помощью-p.
Существуют публичные серверы iperf3, но ими пользуется множество людей и они часто загружены: их результаты больше говорят об их нагрузке, чем о вашем сервере. Чтобы измерить производительность процессора, памяти и дисков, а не сети, см. Тестирование производительности сервера.
Замер реальной загрузки с помощью curl
Чтобы проверить реальную передачу данных по HTTP, скачайте большой файл в /dev/null (так диск не участвует в тесте) и пусть curl выведет показатели:
curl -o /dev/null -s -w 'speed: %{speed_download} B/s ttfb: %{time_starttransfer}s total: %{time_total}s\n' https://mirror.example.com/large-file.isoИспользуйте большой файл на сервере с хорошим подключением рядом с интересующим вас направлением, например ISO-образ из списка зеркал вашего дистрибутива. speed_download указывается в байтах в секунду: 117 000 000 Б/с — это примерно 940 Мбит/с. Отдельная загрузка ограничена удаленным сервером и его подключением, поэтому, прежде чем делать выводы, сравните несколько источников. Добавьте -4 или -6, чтобы сравнить IPv4 и IPv6; если IPv6 не работает совсем, проверьте конфигурацию IPv6.
Задержка и джиттер: ping
ping -c 100 -i 0.2 203.0.113.20100 packets transmitted, 100 received, 0% packet loss, time 19804ms
rtt min/avg/max/mdev = 11.204/11.391/12.877/0.214 msavg — типичное время приема-передачи (RTT), а mdev, стандартное отклонение, — практическая мера джиттера. Для игровых серверов и голосовой связи стабильная задержка важнее пропускной способности как таковой: добивайтесь низкого mdev и 0% потерь. Значения в нашем инструменте проверки задержки — это оценки, рассчитанные по расстоянию, поэтому измеренные значения на реальном маршруте могут отличаться.
Поиск места сбоя: mtr и traceroute
mtr объединяет traceroute и ping: он раз за разом опрашивает каждый хоп на пути. Запустите его в режиме отчета с числом циклов, достаточным для значимого результата:
mtr -rwbz -c 100 203.0.113.20-r выводит отчет, -w не обрезает имена хостов, -b показывает имена и IP-адреса, -z добавляет номер AS каждого хопа, а -c 100 отправляет 100 зондирующих пакетов на каждый хоп.
HOST: web1 Loss% Snt Last Avg Best Wrst StDev
1. AS64500 198.51.100.1 0.0% 100 0.4 0.5 0.3 1.9 0.2
2. AS64500 198.51.100.9 38.0% 100 1.3 4.9 1.0 48.2 9.1
3. AS64501 192.0.2.17 0.0% 100 7.9 8.1 7.8 9.4 0.2
4. AS64501 203.0.113.20 0.0% 100 8.3 8.4 8.1 10.2 0.3Как читать отчет
- Значение имеют только потери, доходящие до последнего хопа. На хопе 2 видно 38% потерь, но на хопах 3 и 4 их нет: этот маршрутизатор ограничивает частоту ответов, которые генерирует сам, — это распространенное и безобидное явление. Реальные потери начинаются на каком-то хопе и сохраняются на всех следующих за ним, вплоть до адресата.
- С задержкой то же самое. Всплеск на одном промежуточном хопе, который не переходит на последующие хопы, означает, что этот маршрутизатор медленно отвечает, а не медленно пересылает трафик.
- Маршруты часто асимметричны. Обратный путь может проходить через другие сети, поэтому mtr с вашего сервера показывает лишь половину картины. Запустите его и в обратном направлении.
- ICMP фильтруется? Тогда проверяйте по TCP на открытый порт:
mtr -rwbz -T -P 443 -c 100 example.com.
Если mtr нет, traceroute -n 203.0.113.20 (из пакета traceroute) однократно выводит список хопов, а tracepath не требует прав root и также сообщает MTU пути.
Когда создавать тикет
Сначала проверьте страницу статуса. Затем создайте тикет в разделе Поддержка, если вы видите потери пакетов, которые сохраняются до адресата, пропускную способность между двумя машинами с хорошим подключением намного ниже приведенных выше значений или проблему, начавшуюся в определенный момент. Укажите:
- IP-адрес сервера и удаленный адрес, до которого вы проводили тест.
- Отчеты mtr в обоих направлениях: от вашего сервера до адресата и от адресата или затронутого пользователя обратно к вашему серверу, не менее 100 циклов в каждом.
- Результаты iperf3 или curl, время проведения тестов с указанием часового пояса, а также затронут ли IPv4, IPv6 или оба протокола.
- Является ли проблема постоянной или периодической и когда она началась.
Сбой сети обрабатывается как критическая проблема: мы стремимся дать первый ответ в течение 30 минут; по остальным тикетам целевое время первого ответа — 4 часа. Если вы подозреваете атаку, сначала прочитайте раздел Защита от DDoS.