Тайминги загрузки: как антифрод вычисляет ферму по скорости отклика

Любая страница, открытая в браузере, оставляет за собой подробный протокол собственной загрузки: сколько миллисекунд заняло разрешение домена, сколько — установка соединения, сколько ждали первый байт от сервера, сколько парсился документ и когда отрисовался первый кадр. Этот протокол доступен обычному скрипту на странице через Performance API, без разрешений и без единого запроса к пользователю. И пока рынок накрутки обсуждает Canvas, шрифты и биометрию мыши, антифрод спокойно собирает с фермы профилей таблицу таймингов, по которой сорок «разных людей» из разных городов складываются в один кластер.

Причина в том, что тайминги — это не свойство профиля, которое можно подменить в настройках антидетекта. Это физика канала: маршрут пакета, качество линии, загруженность узла, тип подключения. Профиль врёт про видеокарту, но не врёт про то, сколько реально шёл ответ по проводу. Ниже — разбор того, что именно отдаёт браузер, какие аномалии выдают датацентровые каналы, чем живой мобильный интернет отличается от идеального, и как выстраивать сетевую часть, чтобы раскладка времени выглядела человеческой. Эта статья продолжает цикл про отпечатки и тесно связана с материалом про резидентские и мобильные прокси.

Что именно отдаёт браузер

Performance API — семейство интерфейсов, из которых для нашей темы важны два. Первый, PerformanceNavigationTiming, описывает загрузку самого документа и даёт около двух десятков временных меток. Второй, PerformanceResourceTiming, делает то же самое для каждого подгружаемого ресурса: картинок, стилей, скриптов, шрифтов, запросов счётчика. То есть с одной страницы с полусотней ресурсов снимается не одна раскладка, а полсотни — и это уже полноценная статистика по каналу.

Ключевые фазы раскладки

• Разрешение домена. Время между domainLookupStart и domainLookupEnd. Показывает, как быстро отвечает DNS-резолвер и был ли ответ уже в кеше.
• Установка соединения. Интервал от connectStart до connectEnd, внутри которого отдельно выделяется рукопожатие TLS. По сути — двойной или тройной оборот пакета до сервера, то есть прямое измерение задержки канала.
• Ожидание первого байта. От момента отправки запроса до responseStart. Складывается из времени работы сервера и обратного пути пакета.
• Скачивание ответа. От responseStart до responseEnd. Зависит от ширины канала и размера ответа.
• Парсинг и построение документа. Время до domInteractive и domContentLoadedEventEnd. Здесь работает уже процессор клиента, а не сеть.
• Отрисовка. Метки первой отрисовки и первой содержательной отрисовки, а также время до полной загрузки. Зависит и от сети, и от мощности устройства.

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

Отпечаток железа можно подменить в настройках. Тайминги подменить нельзя — их формирует физический маршрут пакета. Поэтому раскладка времени загрузки стала самым честным сигналом о том, откуда на самом деле пришёл визит.

Почему ферма выдаёт себя раскладкой времени

Представьте двадцать профилей, которые выходят в сеть через один прокси-сервер. Внешне это двадцать разных людей: разные устройства, разные куки, разная история. Но маршрут от прокси до целевого сайта у них один и тот же — те же узлы, та же длина пути, тот же провайдер на выходе. Значит, время установки соединения и время ожидания первого байта у всех двадцати будет колебаться в узком коридоре вокруг одного значения. Живые пользователи из одного города, но от разных операторов, с разным качеством линии и разной загрузкой домашней сети, дают несопоставимо более широкий разброс.

Дальше вступает вторая аномалия — слишком ровные значения. Датацентровый канал по определению стабилен: это его коммерческое свойство, за него платят. Сто загрузок подряд дают почти одинаковую задержку с разбросом в единицы миллисекунд. Живой канал так себя не ведёт никогда: домашний Wi-Fi проседает, когда кто-то в квартире смотрит видео, мобильная сеть скачет при переходе между сотами, вечером канал провайдера загружен сильнее, чем в четыре утра.

Третья аномалия — слишком быстро. Сервер в дата-центре нередко физически ближе к площадке, чем живой пользователь с домашним интернетом, и отвечает быстрее, чем это вообще возможно для розничного канала. Профиль, который заявляет мобильный телефон в небольшом городе, а по таймингам работает как сервер в соседней стойке с целевым сайтом, противоречит сам себе.

Таблица: раскладка таймингов у живого трафика и у фермы

Показатель	Живая аудитория	Ферма на одном канале
Разброс времени соединения между визитами	широкий, десятки миллисекунд	узкий коридор вокруг одного значения
Колебания внутри одной сессии	заметные, от ресурса к ресурсу	почти отсутствуют
Абсолютная скорость	обычная розничная	часто быстрее розничной
Зависимость от времени суток	есть, вечерние просадки	нет, график плоский
Разрешение домена	разные резолверы, разное время	один резолвер, одно время
Соотношение сеть/устройство	согласовано с классом устройства	быстрая сеть при слабом заявленном устройстве

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

Чем живой мобильный интернет отличается от идеального канала

Рваная картина вместо ровной

Мобильная сеть — это радиоканал с переменным качеством. Пользователь идёт по улице, телефон переключается между базовыми станциями, сигнал то сильнее, то слабее, соседние абоненты то занимают ёмкость соты, то освобождают. В результате раскладка таймингов у живого мобильного визита выглядит рвано: одна картинка загрузилась за сорок миллисекунд, следующая за триста, третья снова быстро. Это не «плохой канал», это нормальное поведение радиосреды.

Долгое первое соединение

У мобильного устройства первое соединение в сессии часто заметно дороже последующих: радиомодуль выходит из энергосберегающего состояния, поднимается канал передачи данных, только потом идёт полезный трафик. На графике это видно как выраженный «хвост» в начале сессии, которого у датацентрового канала нет в принципе.

Асимметрия

В мобильных сетях скорость отдачи заметно ниже скорости приёма, и это влияет на тайминги запросов с телом. Датацентровый канал симметричен. Мелочь, но она видна в статистике по большим выборкам.

Зависимость от времени суток

Живой трафик подчиняется человеческому расписанию, и качество канала тоже: вечерний пик нагружает и домашние сети, и сотовые. Ферма, работающая ровно круглые сутки, даёт плоский график и по количеству визитов, и по скорости — двойная аномалия, которая усиливает сама себя. Здесь действует общее правило суточного распределения нагрузки: как именно разложены визиты во времени, важнее их абсолютного количества.

Как антифрод превращает тайминги в детектор

1. Сбор. Счётчик снимает раскладку навигации и ресурсов на каждом визите — это десятки числовых признаков, а не один.
2. Построение профиля канала. Из раскладки выводятся устойчивые характеристики: типичная задержка, разброс, форма распределения, соотношение сетевой и клиентской частей.
3. Кластеризация. Визиты группируются по близости профиля канала. Совпадение профиля у большой группы «разных» пользователей — сильный признак общего источника.
4. Сверка с заявленным. Профиль канала сравнивается с тем, что рассказывают о себе user-agent, гео по IP, тип соединения и класс устройства. Ищутся невозможные сочетания.
5. Проверка стабильности. Слишком низкая дисперсия трактуется как признак искусственной среды. Живой канал шумит всегда.
6. Связка с другими сигналами. Тайминги кладутся рядом с сетевым отпечатком уровня протокола — тем самым, о котором мы разбирали в статье про JA3 и TLS-отпечаток, — и вместе они дают гораздо более уверенный вывод, чем по отдельности.

Почему искусственное ускорение вредит

Распространённая практика — резать загрузку ради экономии ресурсов: отключать картинки, блокировать сторонние скрипты, ставить агрессивное кеширование, гнать страницы в режиме, где не выполняется часть кода. Логика понятна: чем меньше грузим, тем больше сессий с одной машины. Но с точки зрения таймингов это катастрофа. Страница, которая полностью загрузилась и отрисовалась за время, за которое живой браузер только успевает установить соединение, — это не оптимизация, а явная метка. Плюс отсутствие запросов к ресурсам, которые должны были быть, само по себе аномалия.

Таблица: типовые аномалии таймингов и что их вызывает

Аномалия в раскладке	Техническая причина	Как лечится
Нулевое время разрешения домена у всех визитов	общий кеш резолвера на хосте фермы	изоляция сетевого стека профилей, разные резолверы
Дисперсия задержки близка к нулю	стабильный датацентровый канал	переход на розничные каналы, естественный джиттер
Время загрузки ниже физически правдоподобного	блокировка ресурсов, урезанный рендер	грузить страницу полностью, без экономии
Быстрая сеть при «слабом» устройстве	рассинхрон профиля и реального железа	согласовать класс устройства с профилем канала
Одинаковая раскладка у десятков профилей	общий выходной узел	разводить профили по разным подсетям и операторам
Плоский график скорости круглосуточно	равномерное расписание задач	расписание с суточной кривой и паузами

Как выстроить правдоподобный профиль таймингов

Качество канала важнее его цены

Основная работа делается не в браузере, а в сетевой части. Розничный канал — домашний или мобильный — даёт правдоподобную раскладку сам по себе, без всяких ухищрений, потому что он и есть то, чем притворяется профиль. Датацентровый канал придётся маскировать, и маскировка эта неполная: искусственно замедлить можно, а воспроизвести характерную форму распределения живого канала — задача существенно сложнее.

Один канал — ограниченное число профилей

Чем больше профилей висит на одном выходном узле, тем плотнее их кластер по таймингам. Здесь работает то же правило, что и при расчёте нагрузки на адрес: количество профилей на канал должно быть таким, чтобы группа не выглядела статистически выделенной. Подход к расчёту описан в материале про формулу количества ботов.

Естественный джиттер, а не случайная задержка

Просто добавить случайное число миллисекунд к каждому запросу — плохая идея. Живой джиттер имеет структуру: он коррелирован во времени (если канал просел, он просел на несколько запросов подряд, а не на один), у него асимметричное распределение с длинным хвостом медленных ответов, и он связан с типом ресурса. Модель шума должна воспроизводить эту структуру, иначе получится «случайность, не похожая на случайность» — ровно та же ошибка, что и с равномерными интервалами в биометрии, о которой шла речь в разборе эмуляции мыши и скролла.

Согласованность сетевой и клиентской частей

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

Полная загрузка страницы

Никаких урезанных режимов, блокировок картинок и отключённых сторонних скриптов ради экономии. Профиль должен грузить страницу так же, как её грузит живой посетитель: со всеми ресурсами, со всеми счётчиками, в естественном порядке. Экономия на этом всегда оплачивается качеством трафика.

Прогрев канала

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

Чек-лист проверки своей фермы по таймингам

1. Соберите с десяти профилей раскладку навигации на одной и той же странице и сравните время соединения и ожидания первого байта. Значения обязаны различаться не на проценты, а в разы.
2. Оцените разброс внутри одного профиля за двадцать загрузок подряд. Дисперсия, близкая к нулю, — красный флаг.
3. Проверьте время разрешения домена: если оно у всех нулевое, профили делят общий кеш резолвера.
4. Сравните полное время загрузки с тем, что показывает живой розничный канал на той же странице. Быстрее живого — плохо.
5. Сопоставьте время парсинга и отрисовки с классом устройства, который заявляет профиль.
6. Постройте график средней скорости по часам суток. Плоская линия означает отсутствие суточного ритма.
7. Убедитесь, что профиль подгружает все ресурсы страницы, а не выборочно.

Разбор кейса: ферма, которая работала слишком хорошо

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

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

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

Частые ошибки

• Гнаться за скоростью канала. Дорогой быстрый датацентровый канал хуже дешёвого розничного именно потому, что он лучше. Живые люди не сидят в стойке рядом с сервером.
• Резать загрузку ресурсов. Экономия трафика ломает раскладку таймингов и оставляет дыры в списке запросов, которые должны были быть.
• Добавлять равномерный случайный шум. Живой джиттер структурен и коррелирован во времени, а не размазан равномерно.
• Держать десятки профилей на одном выходном узле. Плотный кластер по таймингам сводит на нет всю работу с отпечатками.
• Игнорировать клиентскую часть раскладки. Мощный процессор при заявленном бюджетном телефоне — такой же рассинхрон, как несовпадение гео и языка.

Частые вопросы

Можно ли подменить тайминги прямо в браузере? Частично — перехватом соответствующих интерфейсов. Но это лечение симптома: подменённые значения должны быть согласованы между собой, с реальным временем прихода данных и с десятками ресурсов на странице. Проще и надёжнее иметь канал, раскладка которого правдоподобна сама по себе.

Мобильные прокси решают проблему полностью? Они решают её лучше всего остального, потому что дают настоящий радиоканал с настоящим шумом. Но и там есть нюанс: если через один мобильный адрес одновременно работает слишком много профилей, узкий коридор таймингов вернётся.

Насколько тайминги весомы по сравнению с отпечатками? Как отдельный сигнал — умеренно. Как подтверждающий — очень весомы, потому что их почти никто не маскирует, а собираются они бесплатно и на каждом визите. Сильные выводы антифрод делает на пересечении сигналов, а не по одному.

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

Вывод

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

Больше о поведенческом продвижении и других услугах — на главной странице ProfSEO24.