Задержки до сетей доставки в 2026 году: замер с российского сервера

27 августа 2026 года мы измерили путь с нашего сервера (Москва, сеть Selectel) до восемнадцати публичных адресов. По пять попыток на адрес, в таблице лучшая. Время до первого байта разложено на составляющие:

Российские адреса отвечают за 40–72 мс, зарубежные — за 65–133. То есть разница между «своим» и «чужим» CDN из Москвы составляет несколько десятков миллисекунд, а не разы.

Причина видна в разложении: рукопожатие TLS у всех укладывается в 15–27 мс, а установка соединения — в 0–20. Сетевой путь до узлов Cloudflare, Google и CloudFront из Москвы короткий — эти сети держат точки присутствия в регионе или рядом, и трафик до них не уходит за океан.

Практический смысл для владельца сайта: выбор между российской и международной сетью доставки — это не выбор между «быстро» и «медленно». Разница в 30–60 мс на первом байте заметна в замере и почти не заметна человеку. Решать этот выбор стоит по другим основаниям — доступности поддержки, способам оплаты, требованиям к размещению данных.

Единственная составляющая, где разброс заметен, — DNS: у всех 15–21 мс, у Akamai 67. Это треть его общего времени, и здесь как раз видно, что резолвинг у него идёт дальше остальных.

Azure: 1 264 мс, и это не сеть. Мы повторили замер четыре раза подряд — 2,2, 2,3, 3,2 и 3,3 секунды. При этом DNS занимает 28–68 мс, соединение 67–100, рукопожатие TLS 152–170. То есть до сервера мы доходим быстрее, чем до большинства других, а он думает две-три секунды, чтобы отдать перенаправление. Проблема на стороне приложения, а не канала.

Это полезное различение вообще: если TLS быстрый, а первый байт медленный — канал ни при чём, ищите на сервере. Тот же приём мы описывали в разборе времени ответа: разница между ping и HTTP на одном хосте отделяет сеть от приложения.

aws.amazon.com не отвечает вовсе — код 000 на всех попытках. При этом соседние адреса того же поставщика работают отлично: d1.awsstatic.com отдаёт первый байт за 73 мс, docs.aws.amazon.com за 124.

Причину мы установить не смогли, и не станем её придумывать. Мы проверили гипотезу про IPv6 — адрес отдаёт AAAA-записи, а у нашего сервера IPv6 нет, — но принудительный запрос по IPv4 тоже не проходит. Значит дело не в этом. Из наших четырнадцати адресов с AAAA-записями остальные тринадцать работают без нареканий, то есть откат на IPv4 в целом отрабатывает верно.

• Одна точка наблюдения. Всё измерено с московского сервера в сети Selectel. Из Новосибирска или Екатеринбурга порядок будет другим, и никакой общий рейтинг сетей доставки из этих чисел не следует.
• Время до первого байта включает раздумья сервера. Это видно на примере Azure: канал быстрый, а показатель худший в таблице. Разделять эти вещи и нужно по разложению, а не по итоговому числу.
• Берётся лучшая из пяти попыток. Это сознательно: так меньше шума от разовых заминок, но значит, что таблица показывает достижимое время, а не типичное.
• Разные адреса отдают разное. Часть возвращает перенаправление, часть отказ доступа, часть полноценную страницу. Для измерения пути это не мешает, но сравнивать по объёму ответа нельзя.

Померить путь до собственного сервера можно в трассировке маршрута, а разложение времени ответа посмотреть в проверке заголовков.