Как диагностировать низкую скорость сети

Краткий ответ: Идите по цепочке: (1) тест с параллельными потоками (iperf3 -P 8), чтобы исключить лимиты одного TCP-потока, (2) проверка нагрузки сервера и диска, (3) измерение задержки и потерь через MTR, (4) сравнение разных конечных точек, чтобы локализовать медленный сегмент. Большинство случаев «медленной сети» оказываются физикой расстояния, перегруженным приложением или линией самого клиента.

Обзор

Пропускная способность = окно ÷ RTT: один TCP-поток физически не может заполнить порт 1G через путь в 200 мс, если окна не огромны, а потери не нулевые. Добавьте узкие места диска, CPU steal или насыщенный домашний канал — и сеть часто ни при чём. Методичное исключение бьёт гадание.

Что нужно иметь

• Определение «медленно» цифрой: ожидаемое против измеренного, какое направление, один файл или всё вместе.
• Готовые инструменты тестирования на сервере (iperf3, wget) и знание скорости порта.

Пошаговая инструкция

1. Воспроизведите с параллельными потоками:

   iperf3 -c TARGET -P 8      # если -P 8 быстро, а -P 1 медленно => задержка, не ёмкость

2. Проверьте, что сервер не узкое место:

   uptime                      # нагрузка
   iostat -x 2 3               # диск занят? (пакет sysstat)
   top                         # CPU steal (st) на загруженном хосте

3. Измерьте путь: mtr -rwc 100 TARGET — высокий RTT объясняет лимиты одного потока; потери объясняют зависания (см. потерю пакетов).
4. Триангулируйте: тест до/со второй точки в другой сети. Медленно везде = сторона сервера; медленно только с одного провайдера = тот путь/клиент.
5. Проверьте уровень приложения: TLS, PHP, время базы доминируют в задержке малых запросов — быстрый порт не ускорит бэкенд-ответ в 900 мс.

Типичные проблемы

• Один поток через межконтинентальный путь признан «сломанным»: 100–300 Mbps на поток при 200 мс RTT — ожидаемо; для далёких пользователей — CDN/параллелизм.
• Собственный аплинк клиента: офисные 100 Mbps обрежут любой тест до 100 Mbps независимо от сервера.
• Тест во время бэкапов: ночные задачи съедают порт — посмотрите vnstat -h, что ещё качалось.

Когда обращаться в поддержку

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

Частые вопросы

Почему одна загрузка медленная, а параллельные быстрые?

Пропускная способность TCP на поток ограничена размером окна и временем оборота. На больших расстояниях это физика — решением являются CDN и параллельные потоки.

Как исключить сам сервер?

Проверьте нагрузку в uptime, насыщение диска через iostat и CPU steal в top. Занятый сервер передаёт медленно в любой сети.

Какие доказательства собрать перед тикетом?

Результаты iperf3 с -P 1 и -P 8, скорости wget с тестовых файлов, MTR в обоих направлениях, метки времени и перечень конечных точек, до которых тестировали.

Похожие статьи

• Как проверить скорость сети
• Как диагностировать потерю пакетов
• Что означает порт 1G / 10G / 20G?
• Как сообщить поддержке о проблемах с сетью

Нужна помощь? Связаться с поддержкой Cloud2Y →