Почему ping хороший, а сайт медленный: разница между задержкой и полосой

MAATRIX

Классическая жалоба: ping до сервера показывает честные 20-30 мс, а сайт всё равно грузится по секунде-две, и заказчик или клиент недоумевает — «у вас же хороший пинг, почему так медленно». Дело в том, что ping и скорость загрузки страницы измеряют принципиально разные вещи. Ниже — почему они не связаны напрямую и как проверить каждую характеристику отдельно, не гадая.

Задержка и полоса — это два разных числа

Задержка (latency) — это время, за которое один пакет добирается от вас до сервера и обратно. Именно её показывает ping: он отправляет маленький ICMP-пакет и меряет round-trip time (RTT). Задержка зависит в основном от физического расстояния и маршрута — сигнал не может двигаться быстрее скорости света в среде передачи, и чем больше промежуточных узлов (хопов) на пути, тем больше накопленная задержка.

Полоса пропускания (bandwidth) — это объём данных, который канал способен прокачать за единицу времени. Она зависит от того, какой канал у сервера до аплинка, сколько соседей делят с вами физический порт (если это виртуальный сервер на общем оборудовании), и есть ли на маршруте узкое место — например, медленный пиринг между двумя операторами.

Аналогия, которая обычно снимает вопрос сразу: представьте трубу. Задержка — это время, за которое капля воды долетает от одного конца трубы до другого. Полоса — это диаметр трубы, то есть сколько воды пройдёт за секунду. Узкая длинная труба и широкая длинная труба дают одинаковую задержку — капля летит одно и то же время, — но по широкой можно перекачать в разы больше воды в секунду. И наоборот: труба может быть очень широкой, но если она длинная (через полмира), первая капля всё равно долетит не мгновенно.

Из этого следует главный практический вывод: низкий ping ничего не говорит о том, насколько толстый канал у сервера, а хорошая полоса ничего не говорит о том, сколько будет ждать первый байт ответа. Это ортогональные характеристики, и сайт может страдать от проблемы в любой из них — или в обеих сразу.

Почему хороший ping не спасает тяжёлую страницу

Если страница — это один HTML-файл на 5 КБ без картинок, при ping 20 мс она загрузится практически мгновенно почти при любой разумной полосе: узкий канал прокачивает 5 КБ настолько быстро, что разница между «толстым» и «средним» каналом не будет заметна на глаз.

Другое дело — тяжёлая страница с несколькими мегабайтами картинок, видео на автовоспроизведении, шрифтами, скриптами аналитики и рекламными баннерами. Здесь узкое место — именно полоса пропускания. Если у сервера канал ограничен (например, тарифный план с ограничением по скорости порта, или общий канал на плотно заселённом физическом хосте), передача каждого мегабайта займёт время независимо от того, какой у вас идеальный пинг. Задержка влияет на то, когда начнётся передача первого байта; полоса влияет на то, как долго будет передаваться весь остальной объём.

Отсюда частая ситуация: два сервера с одинаковым пингом 20 мс, но один отдаёт статику со скоростью, ограниченной портом в 100 Мбит/с, а другой — на канале в 1 Гбит/с. При загрузке лёгкой страницы разницы почти не будет видно. При загрузке страницы с несколькими мегабайтами изображений разница станет ощутимой — и виноват в этом не ping, а именно полоса.

Есть и третий фактор, который часто путают с задержкой сети: время ответа самого сервера (server response time, или Time To First Byte на стороне бэкенда). Если сервер тратит 800 мс на генерацию страницы — тяжёлый SQL-запрос без индекса, нераспарсенный шаблон, синхронный вызов внешнего API — эти 800 мс добавятся к сетевой задержке независимо от того, насколько хорош ping. С точки зрения пользователя это выглядит так же, как «медленный сайт», хотя причина не в сети вообще. Если после проверки задержки и полосы дело всё ещё в тормозах — стоит заглянуть в материал про диагностику тормозящего сайта на VPS, где разбираются именно серверные причины: диск, база данных, конфигурация веб-сервера.

TCP и round-trip'ы: почему для «лёгких» сайтов важнее задержка

Здесь начинается менее очевидная часть. Каждое TCP-соединение — это не мгновенная передача данных, а обмен пакетами с несколькими round-trip'ами ещё до того, как передан первый байт полезной нагрузки:

1. TCP-хендшейк (SYN → SYN-ACK → ACK) — минимум один полный RTT, прежде чем соединение вообще установлено.
2. TLS-хендшейк для HTTPS — ещё один-два RTT сверху (TLS 1.3 в лучшем случае укладывается в один RTT, TLS 1.2 обычно требует двух).
3. Сам HTTP-запрос и ответ — ещё как минимум один RTT для первого байта ответа.

Итого даже до получения HTML-страницы уходит 2-4 RTT, прежде чем начнётся передача самих данных. При пинге 20 мс это 40-80 мс служебных задержек — заметно, но терпимо. При пинге 150 мс (например, межконтинентальный маршрут) это уже 300-600 мс только на установление соединения, ещё до того, как браузер получил первый байт HTML.

Дальше — хуже, если страница состоит из множества мелких файлов. Классический сайт на WordPress без оптимизации может дёргать 60-100 отдельных ресурсов: CSS, JS, шрифты, иконки, трекеры аналитики. Современные браузеры переиспользуют уже установленное TCP/TLS-соединение и параллелят запросы по одному соединению (HTTP/2) или по нескольким (HTTP/1.1), но при высокой задержке и большом количестве последовательных зависимостей (скрипт А триггерит загрузку скрипта Б, который триггерит В) суммарное время всё равно растёт кратно задержке, а не объёму данных — потому что каждый такой раунд ожидания стоит фиксированный RTT независимо от того, насколько толстый канал.

Отсюда практический вывод: для сайта из большого числа мелких файлов и API с частыми короткими запросами задержка обычно важнее полосы. Лишние 100 мс RTT на каждый из десятков последовательных запросов складываются в секунды, и никакой гигабитный канал это не компенсирует — данных передаётся мало, а времени на «поездки туда-обратно» уходит много.

Когда решает полоса, а не задержка

Обратная ситуация — передача больших объёмов данных: скачивание файлов, стриминг видео, бэкапы, синхронизация больших датасетов. Здесь после установления соединения (тот самый 1-2-RTT оверхед на старте) данные начинают литься практически непрерывным потоком, и определяющим фактором становится именно пропускная способность канала — то есть сколько мегабит в секунду реально проходит между сервером и клиентом.

Задержка при этом не исчезает полностью — она влияет на TCP через механизм окна (window size) и медленный старт (slow start): при высокой задержке TCP дольше «разгоняется» до полной скорости, потому что подтверждения о получении данных (ACK) идут медленнее. Это явление иногда называют «bandwidth-delay product» — произведение задержки на полосу канала, определяющее, сколько данных может находиться «в полёте» одновременно. При большой задержке и маленьком TCP-окне канал может физически не успевать себя заполнить, даже если формально полоса широкая. Но это тонкая настройка на грани сетевого стека, а не то, с чем сталкивается большинство сайтов — для обычного веб-проекта или API это скорее теоретический потолок, чем практическая проблема.

Итого: для лёгких, быстрых, API-ориентированных сценариев низкая задержка обычно важнее толстого канала. Для тяжёлых загрузок, видео и файловых сервисов — наоборот, полоса выходит на первый план, а задержка отходит на второй.

Если хочется снизить именно влияние задержки на статику — это как раз задача для настройки CDN перед сервером: раздача через ближайшую к пользователю точку присутствия сокращает число дальних round-trip'ов, а не увеличивает саму полосу вашего сервера.

Как замерить задержку отдельно от полосы

Чтобы не гадать, какая из двух характеристик виновата, их нужно измерять раздельно.

Для задержки — обычный ping:

ping -c 20 example.com

В выводе важна не отдельная строка, а статистика в конце (rtt min/avg/max/mdev). Среднее (avg) — это и есть базовая задержка. Разброс (mdev) — джиттер, нестабильность соединения. Подробная методика измерения, включая traceroute и mtr для поиска узкого хопа на маршруте, разобрана в материале как измерить реальный пинг до сервера.

Важный нюанс: ping использует ICMP, а не тот протокол, которым реально пользуется браузер (TCP/TLS/HTTP). На некоторых маршрутах ICMP приоритизируется иначе, чем обычный трафик, поэтому чистую сетевую задержку для веб-сценария точнее показывает время TCP-соединения через curl (см. следующий раздел), а не голый ping.

Если задержка кажется завышенной именно из-за самого TCP-соединения — долгого хендшейка, ретрансмиссий, разрывов на середине — стоит заглянуть в материал про TCP-рукопожатие и типичные зависания: там разобрано, что происходит на уровне пакетов, если соединение устанавливается заметно дольше одного RTT.

Как замерить полосу и разложить загрузку страницы по стадиям

Полосу пропускания измеряют инструментами вроде speedtest-cli или iperf3 — они гоняют через канал заметный объём данных и считают, сколько мегабит в секунду реально прошло:

speedtest-cli --simple

Или, если нужно замерить именно канал между двумя конкретными серверами (а не публичный speedtest, который меряет до ближайшей тестовой точки провайдера), — iperf3 в связке клиент-сервер:

# на сервере
iperf3 -s

# с клиента
iperf3 -c IP_сервера -t 20

Это даёт число в Мбит/с или Гбит/с — реальную пропускную способность канала между двумя точками, без примеси задержки TCP-хендшейка. Подробнее про интерпретацию результатов — в материале про измерение скорости через iperf3.

Для диагностики именно загрузки веб-страницы полезнее не общий speedtest, а разбивка одного HTTP-запроса на стадии — это делает curl -w с форматной строкой:

curl -w "@curl-format.txt" -o /dev/null -s https://example.com

Где curl-format.txt:

    time_namelookup:  %{time_namelookup}s\n
       time_connect:  %{time_connect}s\n
    time_appconnect:  %{time_appconnect}s\n
  time_pretransfer:  %{time_pretransfer}s\n
time_starttransfer:  %{time_starttransfer}s\n
                 ----------\n
        time_total:  %{time_total}s\n

Что где искать:

• time_namelookup — сколько заняло DNS-резолвинг. Большое значение здесь — повод проверить DNS-провайдера, а не сеть до сайта.
• time_connect — время TCP-хендшейка, то есть чистая сетевая задержка для этого соединения (сравнимо с ping, но для TCP, а не ICMP).
• time_appconnect — добавляет TLS-хендшейк поверх TCP. Разница между time_connect и time_appconnect показывает, во сколько обходится именно шифрование соединения.
• time_starttransfer (это и есть TTFB, time to first byte) — момент, когда пришёл первый байт ответа. Если он сильно больше time_appconnect, задержка не сетевая, а серверная — сервер долго генерировал ответ.
• time_total — минус всё вышеперечисленное — и есть время собственно передачи тела ответа, которое как раз и определяется полосой пропускания и размером страницы.

Эта разбивка обычно и отвечает на исходный вопрос за один запрос: если time_connect маленький (пинг и правда хороший), а time_total большой из-за разницы между time_starttransfer и концом передачи — дело в полосе или в размере страницы. Если же большой именно time_starttransfer при маленьком time_connect — дело не в сети вообще, а в том, что сервер сам долго отвечает.

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