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

Технические вопросы

Speedtest отрапортовал 290 Мбит/с. А реальная скорость до серверов в ЕС выходит около 38 Мбит/с. Разрыв почти в восемь раз трудно не заметить, и почти всегда он объясняется длинным международным маршрутом, а не вашим оборудованием и не нашим сервисом.

Коротко

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

Как выглядит разрыв

Вот одна и та же линия, замеренная дважды с разницей в минуты. Сначала Speedtest против сервера, который он выбрал сам.

Результат Speedtest, 290,64 Мбит/с на приём и 25,95 Мбит/с на отдачу до сервера Deutsche Telekom в Лейпциге, по нескольким соединениям

Две детали на этой панели и объясняют почти всю цифру. В строке "Connections" стоит "Multi", значит цифра сложена из нескольких потоков сразу. А выбранный сервер стоит в той же стране. Теперь та же линия против серверов, которые реально возят вебинары, на шаге "Speed" нашего тестера связи.

Шаг Speed в тестере, 37,58 Мбит/с к вам и 15,98 Мбит/с от вас

Приём просел примерно в восемь раз. Отдача сползла всего с 26 до 16, спуск куда мягче. Ни та, ни другая цифра не говорит о неисправной линии, а куда уходит каждая, разбирает остаток статьи.

Вторую панель стоит читать внимательно. "TO YOU" это приём, а "FROM YOU" отдача. Ведёте вебинар сами? Тогда важна именно цифра "FROM YOU", ведь камера, микрофон и показ экрана уходят наверх. Участнику, который только смотрит, важна "TO YOU". В замере выше 15,98 Мбит/с на отдачу это примерно десятикратный запас для ведущего.

Подписи на снимках английские, ведь интерфейс снят в английской версии. В русской те же пункты называются по-русски и стоят на тех же местах.

Что на самом деле меряет Speedtest

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

  • Он берёт ближайший сервер. Speedtest выбирает узел с наименьшей задержкой, обычно внутри сети вашего провайдера или в том же городе. Трафик до него идёт коротким путём и международных каналов вообще не касается.
  • Он открывает много соединений разом. Speedtest поднимает несколько потоков TCP сразу, обычно от 4 до 16, и складывает их скорость. Так обходится предел одного соединения на длинном маршруте, о нём следующий раздел. Реальные программы часто работают в один поток или в два, и такой прибавки им не достаётся.
  • Задержка минимальна. На коротком маршруте круговое время, оно же RTT, всего несколько миллисекунд, и TCP успевает разогнаться до полной скорости линии.

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

Произведение полосы на задержку и окно TCP

Основная часть разрыва держится на одном механизме.

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

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

Чтобы забить линию целиком, окно должно быть не меньше произведения полосы на задержку, оно же BDP.

BDP = полоса × RTT

Подставим ту самую линию на 290 Мбит/с и задержку до сервера в ЕС около 50 мс.

BDP = 290 000 000 бит/с × 0,05 с = 14 500 000 бит = 1,81 МБ

Значит в каждый момент в полёте должно висеть около 1,8 МБ данных, иначе линия не насытится. Застряла одна из сторон на ограниченном окне, то есть на классических 64 КБ без масштабирования окна? Тогда потолок одного соединения выходит такой.

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

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

Задержка и физика длинных каналов

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

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

Дальше задержка на каждом промежуточном узле. Роутер обрабатывает пакет, ставит его в очередь и отправляет дальше. По дороге к серверу в ЕС таких узлов, они же хопы, обычно от 10 до 20, и каждый добавляет свою долю. Чем выше итоговый RTT, тем ниже потолок одного соединения по формуле выше.

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

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

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

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

На практике цифры выглядят страшно. При RTT в 50 мс и обычном MSS даже 0,1 процента потерь держат одно соединение около 7 Мбит/с. Процент потерь опускает его примерно до 2,3 Мбит/с, а два процента ниже 1,7 Мбит/с. На длинных транзитных маршрутах потери от 1 до 2 процентов в час пик совершенно обычны. Там, где они дорастают до таких значений, они кусают сильнее оконного предела. Отсюда и маршрут, который утром просто медленный, а вечером уже непригодный.

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

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

Отсюда несколько типовых бед. Маршрут может уходить через третью страну, хотя есть путь короче, и тогда растут и задержка, и риск потерь. Ещё трафик пересекает стыки между сетями, то есть точки пиринга и транзитные каналы. Забитый стык это ровно то место, где скорость и падает. Часто встречается асимметричная маршрутизация, когда пакеты уходят одним путём, а возвращаются другим, и диагностика становится мутной. А международную ёмкость ещё и покупают, поэтому у сэкономившего провайдера в час пик её не хватает.

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

Локального трафика, по городу и по стране, у большинства провайдеров с запасом. Потому Speedtest до ближнего сервера всегда и показывает высокое число. Международные каналы дороже и покупаются в ограниченном объёме, а вечером в пик именно они становятся узким местом. Отсюда и заметные скачки скорости до ЕС в течение дня при стабильно высоком локальном Speedtest.

Прочие технические факторы

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

MTU и фрагментация. Если MTU на маршруте меньше ожидаемого, пакеты дробятся, и эффективность падает. Криво настроенный PMTUD, то есть определение MTU на пути, доводит до чёрных дыр и зависших передач.

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

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

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

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

Почему дело не в оборудовании и не в сервисе

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

И ещё одно, прежде чем гнаться за цифрами. Вебинару нужно куда меньше, чем передаче файлов, поэтому 20 Мбит/с до ЕС нас вполне устраивают. Ведущему нужно около 1,6 Мбит/с на отдачу, а с показом экрана около 3,2. Участнику нужна полоса на каждого спикера в эфире, и всё это раскладывают технические требования. Стабильность здесь важнее голой скорости. Если мероприятия идут гладко, разрыв со Speedtest это курьёз, а не поломка.

Как проверить самому

Несколько проверок укажут на причину.

  • Запустите Speedtest вручную и выберите сервер в Германии или в Финляндии. Все наши серверы стоят в ЕС, в Германии, Франции, Нидерландах и Финляндии, но эфир везут именно немецкие и финские машины. Нидерландские и французские рассылают приглашения на ближайшие мероприятия, так что замер против них расскажет о маршруте, которым ваши вебинары не ходят. Германия и Финляндия покажут настоящую скорость по рабочему маршруту, а не до ближайшего локального сервера.
  • Проследите маршрут. Команда tracert в Windows или traceroute в macOS и Linux до нашего сервера выдаст цепочку узлов с задержкой на каждом. Потери и задержку нагляднее показывает утилита mtr, в Windows это WinMTR, и её стоит оставить работать на несколько минут в час пик.
  • Сравните одно соединение с несколькими. Загрузка в несколько потоков быстрая, а в один поток медленная? Это и подтверждает оконный предел TCP на длинном маршруте.
  • Есть техническая возможность? Померьте пропускную способность до дальнего узла напрямую через iperf3, сначала в один поток, потом в несколько.

В нашем тестере оборудования есть и ссылка на отдельную проверку качества интернета, где видны скорость, пинг и джиттер. Быстрый способ зафиксировать состояние линии в конкретный момент.

Что делать

Проверки показали высокую задержку или потери пакетов на международном участке? Идите к провайдеру с конкретикой, то есть с трассировкой маршрута и показаниями mtr, где отмечено время суток. Править маршрут или расширять международную связность это работа провайдера. С нашей стороны мы дадим адреса серверов для точечной диагностики и поможем прочитать результаты. Напишите в онлайн-чат, и мы их пришлём.

Итог

Результат Speedtest около 290 Мбит/с подтверждает, что линия здорова. Просадка ниже 40 Мбит/с на серверах в ЕС ожидаема. Держится она на задержке длинного маршрута, оконном пределе одного соединения TCP, потерях пакетов и загрузке международных каналов провайдера. Эти причины сидят в сети между вами и нами, а не в вашем оборудовании и не в нашем сервисе. Простая диагностика маршрута покажет, какая из четырёх вредит.

Часто задаваемые вопросы

Стоит ли купить линию побыстрее, чтобы это вылечить?

Нет. Вебинару нужно куда меньше, чем передаче файлов, и 20 Мбит/с до ЕС нас вполне устраивают. Ведущему нужно около 1,6 Мбит/с на отдачу, а с показом экрана около 3,2, и все цифры раскладывают технические требования. Стабильность здесь важнее голой скорости. Если мероприятия идут гладко, разрыв со Speedtest это курьёз, а не поломка.

Приём упал в восемь раз, а отдача почти не сдвинулась. Что из этого важно?

Отдача, если ведёте вебинар вы. Камера, микрофон и показ экрана уходят наверх, а это цифра "FROM YOU". Участнику, который только смотрит, важна "TO YOU", поэтому один и тот же замер читается по-разному в зависимости от роли на мероприятии. В замере выше отдача сползла всего с 26 до 16 Мбит/с, а это примерно десятикратный запас для ведущего.

Какой сервер Speedtest выбрать для честного сравнения?

В Германии или в Финляндии. Все наши серверы стоят в ЕС, в Германии, Франции, Нидерландах и Финляндии, но эфир везут именно немецкие и финские машины. Нидерландские и французские рассылают приглашения на ближайшие мероприятия, поэтому замер против них расскажет о маршруте, которым ваши вебинары не ходят.

Что из этого можно починить своими силами?

Начните со своей стороны. Wi-Fi вместо кабеля, перегруженный домашний роутер, антивирус или VPN на устройстве сажают реальную скорость. Здесь чисто, а проверки всё равно показывают высокую задержку или потери на международном участке? Дальше дело провайдера, и идти к нему надо с конкретикой, то есть с трассировкой маршрута и показаниями mtr с отметкой времени суток. Адреса наших серверов для точечной диагностики дадим мы, только напишите в онлайн-чат.

Почему утром маршрут нормальный, а вечером непригодный?

Международные каналы покупаются в ограниченном объёме и вечером в пик становятся узким местом. Локального трафика хватает с запасом, поэтому Speedtest до ближнего сервера держится высоко весь день. Потери пакетов идут по той же кривой, и от 1 до 2 процентов на длинных транзитных маршрутах в час пик совершенно обычны. При RTT в 50 мс процент потерь держит одно соединение около 2,3 Мбит/с, и вот это превращает просто медленный маршрут в непригодный.

Начните сегодня

Готовы провести вебинар, который окупится?

Мы помогаем проводить вебинары с 2013 года. Начать можно абсолютно бесплатно

Бесплатный план навсегда • Без банковской карты • Запуск за 2 мин