Почему скорость до серверов в ЕС ниже, чем в Speedtest?

Частая ситуация: Speedtest показывает 600/700 Мбит/с, а реальная скорость при работе с серверами в Евросоюзе не превышает 20 Мбит/с. Цифры расходятся в десятки раз, и это вызывает закономерный вопрос. Ниже подробно разбираем, почему так происходит, и показываем, что причина почти всегда лежит на стороне магистральных каналов провайдера, а не в вашем оборудовании или в нашем сервисе.

Коротко о сути

Speedtest и реальное соединение с удалённым сервером измеряют принципиально разные вещи. Speedtest проверяет «ёмкость» вашего локального канала на коротком маршруте, а реальная работа с серверами в ЕС зависит от задержки, состояния международных каналов и качества маршрута. Высокий результат Speedtest подтверждает, что ваш канал исправен. Низкая скорость до ЕС объясняется физикой дальних соединений и загрузкой транзитных сетей.

Что именно измеряет Speedtest

Speedtest по умолчанию устроен так, чтобы показать максимально высокую цифру, поэтому к реальной работе с удалёнными серверами его результат применим лишь частично.

1. Выбор ближайшего сервера. Speedtest автоматически подбирает сервер с наименьшей задержкой. Чаще всего это сервер внутри сети самого провайдера или в том же городе. Трафик до него идёт по короткому маршруту и не выходит в международные каналы.

2. Множество параллельных соединений. Speedtest открывает несколько одновременных TCP-потоков (обычно от 4 до 16) и суммирует их скорость. За счёт этого он обходит ограничение, которое возникает у одиночного соединения на дальних маршрутах (подробнее об этом ниже). Реальные приложения нередко работают через одно или небольшое число соединений, поэтому такого «разгона» не получают.

3. Минимальная задержка. На коротком маршруте задержка (RTT) составляет единицы миллисекунд, и протокол TCP успевает выйти на полную скорость канала.

В результате Speedtest показывает «лабораторную» пропускную способность вашего канала, а не ту скорость, которую вы получите при обмене данными с сервером в другой стране.

Главная причина: произведение полосы на задержку и окно TCP

Это ключевой технический момент, который объясняет большую часть разницы.

Протокол TCP передаёт данные «окнами»: отправитель посылает порцию данных и ждёт подтверждения о доставке, прежде чем продолжить. Максимальная скорость одиночного TCP-соединения определяется простой формулой:

Скорость = Размер окна / Задержка (RTT)

Чтобы полностью загрузить канал, размер окна должен быть не меньше так называемого произведения полосы на задержку (Bandwidth-Delay Product, BDP):

BDP = Пропускная способность × RTT

Посмотрим на конкретный пример для канала 600 Мбит/с при задержке до сервера в ЕС около 50 мс:

BDP = 600 000 000 бит/с × 0,05 с = 30 000 000 бит = 3,75 МБ

Это означает, что для полной загрузки канала в «полёте» одновременно должно находиться около 3,75 МБ данных. Если же на одной из сторон активен старый или ограниченный размер окна (классические 64 КБ без масштабирования окна), потолок скорости одиночного соединения составит:

Скорость = 65 536 байт × 8 бит / 0,05 с ≈ 10,5 Мбит/с

Именно поэтому одиночное соединение с дальним сервером упирается в 10 до 20 Мбит/с, даже когда сам канал рассчитан на сотни мегабит. На коротком маршруте (RTT 2 мс) то же самое окно дало бы более 260 Мбит/с, поэтому в Speedtest проблема не проявляется. Чем выше задержка, тем сильнее этот эффект, и это не дефект оборудования, а фундаментальное свойство протокола.

Задержка (RTT) и физика дальних каналов

Задержка на дальних маршрутах складывается из нескольких составляющих, и часть из них принципиально неустранима.

Сигнал в оптоволокне распространяется со скоростью около 200 000 км/с, что заметно медленнее скорости света в вакууме из-за коэффициента преломления стекла. Каждая тысяча километров маршрута добавляет примерно 5 мс в одну сторону, то есть около 10 мс на путь «туда и обратно». Реальный маршрут редко идёт по прямой и обычно длиннее географического расстояния.

К этому добавляется задержка на каждом промежуточном узле (маршрутизаторе): обработка пакета, постановка в очередь, передача дальше. На пути до сервера в ЕС таких узлов (хопов) бывает от 10 до 20, и каждый вносит свой вклад. Чем выше итоговый RTT, тем ниже потолок скорости одиночного соединения по формуле выше.

Потери пакетов и их влияние на TCP

Даже небольшие потери пакетов на международном канале резко снижают итоговую скорость. TCP воспринимает потерю пакета как признак перегрузки и в ответ уменьшает скорость передачи, после чего наращивает её заново. Зависимость описывается уравнением Мэтиса:

Скорость ≈ MSS / (RTT × √p)

Здесь MSS это максимальный размер сегмента (обычно около 1460 байт), RTT это задержка, а p это доля потерянных пакетов. Из формулы видно, что скорость падает обратно пропорционально корню из уровня потерь и прямо зависит от задержки.

На практике это выглядит так: при RTT 50 мс и стандартном MSS даже потери в 0,1 процента ограничивают одиночное соединение примерно 73 Мбит/с, потери в 1 процент дают около 23 Мбит/с, а потери в 2 процента опускают скорость ниже 17 Мбит/с. На дальних транзитных маршрутах потери в 1 до 2 процентов в часы пик это обычное явление, и именно они часто становятся главным ограничителем.

Маршрутизация и пиринг

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

В результате возникает несколько типичных проблем. Маршрут может идти неоптимально, например через третью страну, что увеличивает и задержку, и риск потерь. Трафик проходит через стыки между сетями (точки пиринга и транзитные каналы), и если такой стык перегружен, скорость падает именно на нём. Часто встречается асимметричная маршрутизация, когда пакеты «туда» и «обратно» идут разными путями, что усложняет диагностику. Наконец, у бюджетных провайдеров международная связность может быть закуплена по остаточному принципу, и в пиковые часы её ёмкости не хватает.

Перегрузка международных каналов провайдера

Локальный (внутригородской и внутристрановой) трафик у большинства провайдеров имеет большой запас по ёмкости, поэтому Speedtest до ближнего сервера всегда показывает высокую цифру. Международные же каналы стоят дороже и закупаются ограниченным объёмом. В вечерние часы пик, когда нагрузка максимальна, именно эти каналы становятся «узким горлышком». Это объясняет, почему скорость до ЕС может заметно меняться в течение суток, тогда как локальный Speedtest стабильно высок.

Дополнительные технические факторы

Помимо основных причин, на скорость до удалённого сервера влияет ещё ряд моментов.

MTU и фрагментация. Если на маршруте размер MTU меньше ожидаемого, пакеты фрагментируются, что снижает эффективность. Некорректная настройка PMTUD (определения MTU вдоль пути) может приводить к «чёрным дырам» и зависаниям передачи.

Bufferbloat (раздувание буферов). Избыточные буферы на промежуточных узлах увеличивают задержку под нагрузкой и сбивают алгоритмы управления потоком TCP, дополнительно снижая реальную скорость.

Шейпинг и приоритизация (QoS). Некоторые провайдеры намеренно ограничивают или понижают приоритет международного либо определённого типа трафика, что напрямую сказывается на скорости.

Накладные расходы протоколов. Заголовки TCP, IP и шифрования (TLS) занимают часть полосы. На коротком маршруте это незаметно, а в сочетании с потерями и задержкой на дальнем маршруте вносит свой вклад.

Локальная среда. Wi-Fi вместо кабеля, загруженный домашний роутер, антивирус или VPN на устройстве также способны снижать реальную скорость, поэтому при диагностике их желательно исключить.

Почему это не проблема оборудования или сервиса

Высокий результат Speedtest однозначно подтверждает, что ваше оборудование, кабель и локальный канал исправны и обеспечивают заявленную скорость. Падение скорости при работе с серверами в ЕС вызвано задержкой на дальнем маршруте, ограничением окна одиночного TCP-соединения, потерями пакетов и состоянием международных каналов вашего провайдера. Все эти факторы находятся вне нашего сервиса и вне вашего оборудования: они относятся к участку сети между вашим провайдером и магистральными операторами.

Как проверить самостоятельно

Чтобы убедиться в причине, выполните несколько простых проверок.

1. Запустите Speedtest вручную с выбором сервера в нужной стране ЕС (например, в Германии или Нидерландах, где расположены наши серверы). Это покажет реальную скорость именно по тому маршруту, который используется в работе, а не до ближайшего локального сервера.

2. Постройте трассировку маршрута. Команда tracert (Windows) или traceroute (macOS, Linux) до нашего сервера покажет цепочку узлов и задержку на каждом из них. Для наглядной диагностики потерь и задержки удобна утилита mtr (или WinMTR на Windows), которую желательно запускать в течение нескольких минут в часы пик.

3. Сравните одно и несколько соединений. Если многопоточная загрузка идёт быстро, а одиночная медленно, это прямо подтверждает ограничение по окну TCP на дальнем маршруте.

4. При наличии технической возможности используйте iperf3 для прямого замера пропускной способности до удалённого узла как одним, так и несколькими потоками.

Что делать

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

Итог

Результат Speedtest 600/700 Мбит/с подтверждает исправность вашего канала. Снижение до 20 Мбит/с при работе с серверами в ЕС закономерно и объясняется задержкой на дальнем маршруте, ограничением окна одиночного TCP-соединения, потерями пакетов и загрузкой международных каналов провайдера. Это не связано ни с вашим оборудованием, ни с нашим сервисом, и точная причина выявляется простой диагностикой маршрута.

Последнее изменение: 21/06/2026