Браузер не умеет слать «сырой» ping, поэтому тесты скорости замеряют HTTP-передачи. Как прогрев, размер данных, потоки и медиана формируют ваше число.
Главное
- Веб-страница не может отправлять ICMP-пинги и открывать «сырые» сокеты, поэтому любой тест скорости в браузере строится на HTTP- или WebSocket-передачах, которые засекаются по часам.
- Пропускная способность — это просто полученные байты, делённые на затраченное время, но осмысленна она только после разгона соединения, поэтому тесты делают прогревочную передачу и отбрасывают первые секунды.
- Решения в дизайне теста (один поток или несколько, размер данных, медиана или лучший прогон) меняют итоговое число на одной и той же линии.
- «Ping» в браузере — это HTTP-обращение туда и обратно, и оно включает обработку на сервере, а не только сам канал.
Тест скорости в браузере измеряет соединение так: передаёт настоящие байты по HTTP (или WebSocket) и засекает время высокоточными часами. Скорость загрузки — это объём полученных данных, делённый на время; задержка — время обращения с крошечным запросом и ответом. Всё остальное в устройстве теста нужно, чтобы это простое деление было честным. В статье разобран только механизм: что передаётся, что засекается, что отбрасывается и как получается одно число. Почему результаты различаются между запусками и инструментами, читайте в материале почему результаты теста скорости меняются, а что такое полоса, задержка и джиттер — в разборе метрик.
Что браузер вообще может измерить?
Веб-страница работает в песочнице. Она не может отправлять ICMP-эхо-запросы (классический ping), открывать «сырые» сокеты и видеть пакеты. Зато она может вызвать fetch(), XMLHttpRequest или WebSocket и прочитать часы. Стандартные часы — performance.now(), монотонный таймер, на который не влияет перевод системного времени.
Это единственное ограничение объясняет большую часть дизайна:
- Задержка — это HTTP-обращение туда и обратно. Браузер засекает маленький запрос до прихода ответа. В это время входит обработка на сервере и работа с соединением, поэтому значение обычно чуть выше ICMP-пинга до того же хоста.
- Пропускная способность наблюдается со стороны страницы. Тест считает байты по мере их поступления (или по завершении отправки) и делит на время. Он измеряет то, что страница реально способна передать, а это и важно для веб-сёрфинга.
Зачем тестам прогрев
Новое TCP-соединение не стартует на полной скорости. Контроль перегрузки начинает с маленького окна и увеличивает его по мере прихода подтверждений — эта фаза называется медленным стартом. Тест, замеряющий один небольшой файл, в основном меряет этот разгон и занижает возможности линии.
RFC 6349, методика IETF для тестирования пропускной способности TCP, подчёркивает то же: нужна устойчивая пропускная способность, которую путь способен держать, а не первые несколько обращений. На практике тесты решают это двумя способами: шлют одноразовый прогревочный запрос, результат которого отбрасывается, и берут достаточно большие данные, чтобы разгон занимал малую долю общего времени.
Отсюда же видно, почему крошечные файлы плохо годятся для замера полосы. Ответ в 1 КБ заканчивается раньше, чем окно успевает открыться, поэтому он говорит о задержке, а не о ёмкости.
Адаптивный размер данных
Фиксированный размер файла подходит немногим. Файл в 50 МБ на слабом мобильном канале качается минутами; на оптоволокне файл в 1 МБ заканчивается ещё до разгона соединения. Обычное решение — начать с малого и наращивать объём, пока передача не займёт целевое время, часто пару секунд. Медленные линии остаются короткими, а быстрым достаётся достаточно данных для выхода на устойчивый режим.
Один поток или много?
Здесь подходы действительно различаются.
- Несколько параллельных потоков. Многие коммерческие тесты открывают сразу несколько TCP-соединений. Это заполняет линии с большим произведением полосы на задержку (быстрые и дальние), которые один поток может не загрузить, и обычно даёт более высокий пик.
- Один поток. NDT от M-Lab в нынешнем виде ndt7 намеренно использует одно соединение на фиксированное время. По спецификации протокола передача идёт поверх WebSocket. Одно соединение здесь выбрано сознательно: цель — измерить, чего достигает один TCP-поток на этом пути.
Ни один подход не ошибочен. Они отвечают на разные вопросы: «сколько эта линия способна нести в сумме?» и «что получит одно соединение?». Один поток может занижать показания на очень быстрой линии; несколько потоков могут завышать результат там, где реальный трафик в основном идёт одним соединением.
От замеров к одному числу
Тест собирает много замеров, а затем сводит их к итоговому числу. Выбор имеет значение:
| Агрегация | Эффект |
|---|---|
| Среднее по всем прогонам | Занижается медленным разгоном и разовыми провалами |
| Медиана | Устойчива к выбросам; стабильная, осторожная оценка |
| Лучший прогон (или верхний процентиль) | Самое высокое число, ближе к пиковой ёмкости, наименее типично |
| Усечённое среднее (без крайних значений) | Компромисс между ними |
Одна и та же линия с теми же исходными замерами может показать заметно разные результаты в зависимости от того, что выбрал инструмент.
Задержка под нагрузкой
Задержка в простое и задержка при занятом канале — разные измерения. Линия с пингом 15 мс в тишине может подскочить до сотен миллисекунд, когда передача заполнит буферы. Черновик IETF IPPM по отзывчивости формализует такое измерение в виде числа обращений в минуту. Большинство браузерных тестов показывают только задержку в простое. Если у вас она растёт под нагрузкой, см. разбор bufferbloat.
Джиттер вычисляется, а не наблюдается
Джиттер никто не измеряет напрямую. Тест отправляет серию маленьких запросов, записывает задержку каждого и выводит джиттер из этого ряда. Инструменты расходятся в формуле: среднее абсолютное различие соседних замеров, стандартное отклонение всех замеров или сглаженная скользящая оценка вроде той, что в RFC 3550. На одних данных получаются разные числа, поэтому джиттер сравнивайте только между запусками одного инструмента. О том, как джиттер влияет на звонки и игры, читайте в материале джиттер и потеря пакетов.
Как это устроено в тесте BrowserInsight
В качестве примера — что делает наш тест скорости, один из нескольких допустимых подходов:
- Транспорт: HTTP-запросы к нашей собственной пограничной (edge) точке, по одному потоку за раз (последовательно, не параллельно).
- Прогрев: запрос примерно в 30 КБ, результат которого отбрасывается перед фазами загрузки и отправки.
- Размер данных: при загрузке передачи растут с 200 КБ до 1 МБ и до 3 МБ, затем подстраиваются примерно под две секунды передачи с потолком 10 МБ. Размер отправляемых данных масштабируется по скорости первой отправки в 200 КБ.
- Длительность: фаза загрузки длится, пока не наберётся и 15 секунд, и не менее трёх передач, но не дольше 30 секунд или десяти передач; фаза отправки делает не более трёх передач.
- Отсчёт времени: каждая передача засекается с момента отправки запроса до прихода последнего байта (или подтверждения отправки), поэтому в каждый замер входит одно обращение туда и обратно.
- Итоговая пропускная способность: медиана засечённых передач в каждой фазе.
- Задержка: среднее по трём HTTP-запросам по 1 КБ после одного отброшенного пробного запроса.
- Джиттер: среднее абсолютное различие между соседними замерами задержки.
Компромисс очевиден: один поток показывает, что получает одно соединение, но на очень быстрой линии может давать меньше, чем многопоточный тест. К тому же три замера задержки дают лишь грубую оценку джиттера: это быстрый ориентир, а не вердикт о качестве звонков. ICMP не используется, параллельных потоков нет, задержка под нагрузкой не измеряется.
Чек-лист для чтения описания любой методики
Прежде чем доверять числу, посмотрите:
- Потоки: одно соединение или несколько?
- Длительность: фиксированное время или фиксированный размер файла?
- Прогрев: отбрасывается ли разгон и как?
- Агрегация: медиана, среднее или лучший прогон?
- Расстояние до сервера: где конечная точка теста относительно вас?
- Определение задержки: в простое или под нагрузкой, HTTP или ICMP?
Инструмент, который открыто отвечает на эти вопросы, полезнее того, у кого число больше.
Частые вопросы
Может ли сайт измерить мой ping через ICMP?
Нет. Браузеры не дают веб-страницам доступ к ICMP и «сырым» сокетам. «Ping» в браузере — это время небольшого HTTP- или WebSocket-обращения туда и обратно, включающее обработку на сервере.
Почему тест сначала скачивает файл, который выбрасывается?
Чтобы пройти медленный старт TCP. Новое соединение начинается с маленького окна перегрузки, и первые байты идут медленно. Прогревочная передача (или отбрасывание раннего интервала) позволяет измерять устойчивую пропускную способность.
Однопоточный тест менее точен, чем многопоточный?
Не менее точен, а отвечает на другой вопрос. Один поток измеряет, чего достигает один TCP-поток; несколько потоков — общую ёмкость линии. На очень быстрой линии один поток может показывать меньше.
Почему задержка в браузере выше, чем у ping из командной строки?
HTTP-задержка помимо сетевого обращения включает обработку на сервере и работу с соединением, а ICMP-ping измеряет только сетевую часть.
Вывод
Тест скорости в браузере — это набор засекаемых HTTP-передач, форма которых определяется тем, что разрешено веб-странице. Прогрев, размер данных, число потоков и агрегация влияют на итоговое число сильнее, чем думает большинство. Читайте описания методик с этим в голове а затем запустите наш тест скорости сети, держа в уме описанное выше устройство.
Рекомендуем прочитать:
