ВЫБОР СЕРВЕРА
Выбираем тестовый сервер
Измерьте производительность интернета и получите персональные рекомендации
Процесс теста скорости
Выбираем тестовый сервер
Измеряем скорость загрузки
Измеряем скорость выгрузки
Рассчитываем индексы
Современное интернет-соединение измеряется в мегабитах в секунду. Маркетинг фокусируется на этом числе. Обзоры сравнивают провайдеров по этому числу. Сайты speedtest показывают число гигантскими пиксельными цифрами. Это число оказывается одной из примерно пяти вещей которые решают, ощущается ли соединение хорошо или плохо, и большую часть времени оно не самое важное. Соединение 100 Mbps с jitter 80ms хуже для видеозвонков чем соединение 25 Mbps с jitter 2ms. Соединение 1 Gbps с bufferbloat выше 200ms превращает каждый звонок в Slack в заикающуюся кашу в момент когда кто-то в семье начинает скачивать фильм. Соединение 200 Mbps маршрутизированное через peering link через три датацентра ощущается медленнее чем 50 Mbps на хорошо маршрутизированной сети. Bandwidth-число это обложка; остальная история сидит за ним. Серьёзный speed test измеряет четыре ортогональных оси: чистая пропускная способность (Speed), консистентность во времени (Stability), определение типа соединения и проверка маршрута (Trust), и сравнение провайдер-vs-региона (Fairness). Первая ось это то что сообщает каждый другой тест. Остальные три это где появляются выводы по которым можно что-то решить. Дальше: какие числа реально предсказывают опыт, что bufferbloat и loaded latency показывают чего не показывает ping, и почему 100 Mbps ощущаются по-разному на разных сервисах даже у одного провайдера.
Четыре числа управляют тем как ощущается интернет-соединение. Bandwidth (Mbps). Заголовочное число. Ограничивает то насколько быстро может завершиться один большой transfer. Влияет на обновления ПО, скачивание видео, бэкапы. Не влияет напрямую ни на что что задействует мелкие частые пакеты. Latency (ms). Round-trip time до получателя. Влияет на всё интерактивное: игры, видеозвонки, голос, SSH, терминальные приложения, веб-страницы с многими мелкими запросами. Страница загружающая 60 отдельных ресурсов при latency 50ms тратит 3 секунды только на round-trips. Та же страница при 10ms тратит 600ms. Bandwidth не имеет отношения к этому расчёту пока каждый отдельный ресурс не упирается в throttling. Jitter (вариация ms). Среднеквадратичное отклонение latency между сэмплами. Катастрофически влияет на голос и видеозвонки. Среднее latency 50ms с jitter 2ms звучит чисто. Среднее latency 50ms с jitter 30ms имеет слышимые сбои. Голосовые кодеки (Opus, AAC-LD) терпят jitter в пределах буфера; за пределами буфера они теряют кадры или вставляют тишину. Speed test который сообщает только 'средний ping' это скрывает. Bufferbloat (loaded latency в ms). Прирост latency когда соединение под нагрузкой. Дешёвые домашние роутеры буферизуют исходящие пакеты агрессивно. Когда канал upload забит, latency до чего угодно может скакнуть с 30ms до 500ms. Видеозвонки превращаются в слайдшоу с задержкой полсекунды. Онлайн-игры обрываются по таймауту. Пользователь думает 'почему мой интернет плохой', а speed test, запущенный в спокойный момент, сообщает 100 Mbps и 30ms ping, всё зелёное. Диагностика пропустила весь режим отказа. Loaded latency это лекарство. Измерять ping пока bandwidth-тест работает. Разница между idle ping и loaded ping это число bufferbloat. Соединения с приростом до 50ms нормальны. 50-200ms значимо для real-time приложений. Выше 200ms сломано таким способом который пользователь чувствует даже если у него нет словаря для этого. Так же как тридцатисекундная задержка между вопросом и ответом делает телефонный разговор неудобным даже если каждое слово чёткое: технология работает, но ритм разговора пропал. Эти четыре оси взаимодействуют неочевидно. Fiber-соединение с 1 Gbps down и 50 Mbps up может делать bufferbloat на upload во время одиночного Zoom-звонка потому что 50 Mbps upload забивается первым. Пользователь видит симптом на стороне download (скачки latency во время входящего видео) но причина на upload. Диагностика требует тестирования обоих направлений под нагрузкой.
Два индекса которые тесты ориентированные на пропускную способность не показывают. Trust оценивает определение типа соединения и проверку маршрута. Мобильный оператор? Residential ISP? Датацентр? VPN? У каждого свои ожидаемые характеристики. 'Residential-соединение' возвращающее 800 Mbps до датацентра на побережье США с европейского IP подозрительно. Это датацентровая производительность, а не домашняя. Результат всё ещё полезен (у вас быстрый канал) но рамка 'как работает мой домашний интернет' тихо подменилась на 'как работает мой VPN до датацентра'. Trust помечает это чтобы пользователь знал что он реально измеряет. Так же как оценивать время бегуна на миле когда он на движущейся ленте: цифра честная, контекст другой. Проверка маршрута это часть Trust. Latency до соседних городов должна быть функцией физического расстояния. Лондон-Париж по оптике это около 6ms. Лондон-Франкфурт около 12ms. Лондон-Мадрид по прямым маршрутам около 25ms. Когда тест видит Лондон-Мадрид на 80ms, что-то маршрутизировано неправильно: трафик идёт через peering exchange в США, или BGP-путь сконфигурирован неверно. Соединение технически в порядке; маршрутизация плохая. Trust ловит это там где чистые speed-тесты не могут. Fairness сравнивает вашу производительность с ожидаемыми значениями для вашего провайдера и региона. Соединение 200 Mbps на Comcast в Бостоне в среднем 180 Mbps это нормально. Тот же тариф в том же городе в среднем 60 Mbps это замедление, перегрузка сети или перепродажа канала. Индекс Fairness требует референсного датасета (наш собран из анонимизированных тестов агрегированных за последние 90 дней) и вычисляет процентиль пользователя внутри его когорты. Контекстуальная рамка важнее сырого числа. 'Ваше соединение работает на 180 Mbps' звучит отлично пока не узнаёшь что 95% клиентов Comcast в Бостоне на том же тарифе на 200 Mbps. Либо вам режут скорость, либо ваш модем недостаточен, либо у линии проблемы с сигналом. Диагноз требует группы сравнения; speed test сам по себе её не имеет.
То же самое соединение работает по-разному в зависимости от того к чему вы подключаетесь. Покрытие CDN это первая переменная. YouTube, Netflix, Apple и Google держат отдельные edge-серверы внутри большинства крупных ISP-сетей. Трафик к ним никогда не покидает сеть провайдера и приземляется с latency меньше 10ms. Twitch напротив работает почти полностью из AWS us-east-1; европейские пользователи бьют по нему с 100-150ms независимо от bandwidth. То же соединение, очень разный опыт. Та же логика что жить через стенку от одного супермаркета и за сорок миль от другого: товары могут быть одинаковыми, дорога разная. ISP peering это вторая. Провайдеры взаимоподключаются через Internet Exchange Points. Соглашения между ISP A и ISP B определяют сколько bandwidth течёт между ними. Когда соглашение недоразмерено, перегрузка на exchange в часы пик деградирует производительность. У Cogent и Hurricane Electric был многолетний peering-конфликт в начале 2010-х, который производил предсказуемые вечерние замедления для любого трафика между их сетями. Современные эквиваленты существуют; пользователи видят их как 'стриминг плохой вечером, но нормальный днём'. Last-mile congestion это третья. Кабельные провайдеры делят пропускную способность на neighbourhood-узлах. Когда слишком много подписчиков смотрят стримы одновременно, восходящий канал узла насыщается. Пользователь видит как Mbps падают с заявленных значений до того что поддерживает деление на уровне узла. Speedtest.net обычно выбирает сервер внутри сети ISP для измерений, что означает тест проходит даже когда восходящий канал ISP это реальное узкое место. Помехи от middlebox это четвёртая. Некоторые провайдеры замедляют конкретные классы трафика (BitTorrent, Usenet, VPN-протоколы) или конкретных получателей в часы пик. Хорошо задокументированное замедление BitTorrent у Comcast в 2007 году было повторено похожими шагами Cox, AT&T и других; практика затихла под давлением сетевой нейтральности и вернулась в модифицированной форме после отмены правил в 2018. Трафик выглядит медленным только когда это замедленный класс. Speed test использующий HTTP к незамедленному получателю проходит, в то время как реальная нагрузка пользователя продолжает страдать. Диагностические следствия: одно число под названием 'скорость' ничего из этого не захватывает. Полезный speed test сообщает bandwidth в обоих направлениях, idle и loaded latency, jitter, получателя на котором тестировал, и оценку маршрутизации. Пять чисел, выведенных честно, рассказывают историю которую одно число под названием 'Mbps' специально скрывает. WHOX speed test запускает измерение по четырём осям (Speed, Stability, Trust, Fairness), тестирует против географически распределённых серверов, считает loaded latency и jitter под нагрузкой и на download и на upload, и выводит проверку маршрутизации отдельно чтобы пользователь мог отличить 'соединение медленное' от 'соединение нормальное, этот получатель плохо маршрутизируется'. Те же данные что генерирует собственный мониторинг провайдера, упакованные для клиента который хочет знать что его соединение реально делает.
Сырая скорость (Мбит/с) показывает только часть картины. Индекс Скорости учитывает как загрузку, так и выгрузку с соответствующими весами. Индекс Стабильности измеряет постоянство соединения — 100 Мбит/с соединение с высоким джиттером может работать хуже, чем стабильные 50 Мбит/с. Индекс Доверия отражает определение типа сети, а Честность сравнивает вашу производительность с ожидаемыми значениями для вашего провайдера.
Мы фокусируемся на практических выводах, а не просто на цифрах. Вместо простого '100 Мбит/с' мы говорим 'Отлично для игр, но высокий джиттер может повлиять на видеозвонки'. Мы также интегрируем определение сети WHOX, чтобы показать, находитесь ли вы на VPN, в дата-центре или на домашнем подключении, что влияет на то, как сервисы обрабатывают ваш трафик.
Наш адаптивный алгоритм отслеживает стабилизацию скорости. Когда измерения сходятся (менее 5% разброса между образцами), продолжение теста не улучшит точность. Это делает тесты быстрее как на медленных, так и на быстрых соединениях, сохраняя при этом точность.
Запускайте весь набор WHOX из одного блока: проверки утечек, fingerprint-пробы, сетевую диагностику, репутацию IP и тесты приватности.