Скорость и задержка в мобильных прокси

Если коротко: выигрывает тот, у кого стабильный пинг, низкий джиттер и предсказуемая пропускная способность. «Мегабиты» важны, но исход рекламных кампаний, качество парсинга и точность антифрод-проверок чаще ломаются не из‑за недокачанного интернета, а из‑за непредсказуемых задержек, потерь и рывков сети. И именно мобильные прокси — с их особенностями радиосети, CGNAT и ротацией IP — усиливают эффект любой ошибки в настройках. Дальше разберем, почему это происходит, и что конкретно сделать, чтобы ваши бюджеты не сгорали на таймаутах, капчах и разрывах сессий. В статье — конкретные цифры, метрики и практические шаги от Стеценко Дениса, партнера «NET-Mart» и основателя LTE CENTER

Пинг и пропускная способность мобильных прокси — результат суммарного пути пакета: от вашего скрипта или браузера до модемного пула, через радиоинтерфейс (LTE/5G), базовую станцию, магистраль оператора, CGNAT, пиринг с целевым хостом/CDN — и обратно. Каждое звено добавляет задержку и может вносить джиттер (разброс задержек) или потери. Важно понимать, какие физические и логические факторы реально двигают цифры. Во‑первых, радиоусловия. Параметры RSRP/RSRQ/SINR определяют, насколько стабильно модем «слышит» базовую станцию. Сильный сигнал с хорошим SINR уменьшает количество ретрансляций на радиоканале, значит — ниже задержка и выше реальный аплинк/даунлинк. Агрегация частот (CA) и MIMO 2x2/4x4 дают прирост скорости, но при слабом SINR они не спасут от скачков пинга. Важно также, в каких диапазонах работает ваш модем: Band 3/7 часто быстрее, но более загружен в городе; Band 20 лучше держит связь внутри помещений, но с меньшим пиком. Во‑вторых, нагрузка ячейки и расписание ресурсов (scheduler) на eNB/gNB. В прайм‑тайм оператор перераспределяет ресурсы между абонентами, и «справедливый» доступ порождает пульсации задержки. Это классический источник джиттера в мобильных прокси. Отсюда два практических вывода: тестируйте в окнах 24/7 и ориентируйтесь на p95/p99, а не на красивый дневной миддл. В‑третьих, магистраль и пиринг. Даже при идеальном радиоканале плохой маршрут до нужного CDN/облака добавит сотни миллисекунд RTT. Нюанс мобильных прокси — CGNAT (массовый NAT оператора), очереди на нем и особенности маршрутизации по ASN. Отсюда — значимая разница между операторами и даже между APN одного и того же оператора. Иногда бизнес‑APN дает более предсказуемый джиттер, чем массовый.

В‑четвертых, сам прокси‑шлюз. Архитектура пула модемов, тип прокси (HTTP/HTTPS/SOCKS5), балансировщики, DNS‑резолвер, TLS‑терминация — всё это влияет на TTFB и стабильность. Узкое место — CPU/память на точке агрегации и быстрый диск/сокетная очередь для соединений. Неправильный backlog или агрессивная ротация сессий выливаются в таймауты. В‑пятых, клиентская сторона. Как вы тестируете? ICMP‑пинг не равен TCP‑RTT, а TTFB веб‑запроса зависит от DNS‑резолва, TCP‑и TLS‑рукопожатий. При HTTP/2 выигрывает мультиплексирование, но любая потеря пакета тянет вниз весь поток. Браузерные автотесты на headless‑движках особенно чувствительны к «пилам» пропускной способности. Наконец, ротация IP и «липкие» сессии. Мобильные IP уникальны для антифрода, но смена адреса в неподходящий момент разрушает соединения. Если прокси не обеспечивает предсказуемую «липкость» (sticky) на 15–30 минут, рост потерь и повторных рукопожатий неизбежен — и это замедляет любой сценарий, от загрузки креативов до парсинга.

• Радио и базовая станция: RSRP/RSRQ/SINR, агрегация частот, MIMO, загрузка ячейки, прайм‑тайм.
• Архитектура прокси: модемный пул, балансер, тип прокси (HTTP/SOCKS5), DNS, TLS‑терминация, ресурсы CPU/памяти.
• Маршрутизация: CGNAT, пиринг/ASN, путь до нужных CDN/облаков, бизнес‑APN против массового.

ICMP‑пинг — полезный индикатор, но решения о бизнес‑нагрузке принимайте по TCP‑RTT и TTFB (Time To First Byte). Меряйте: — TCP‑handshake time и TLS‑handshake time до целевых доменов; — DNS‑время (особенно если у вас собственный резолвер на прокси‑шлюзе); — TTFB по реальным GET/POST к страницам/endpoint’ам, а не «пустым» host. Инструменты: mtr (для маршрута и потерь), httping/curl -w (TTFB/namelookup/connect), iperf3 (линейная пропускная способность и стабильность), периодические транзакционные проверки из ваших скриптов. Оценивайте медиану, p90, p95, p99. В мобильной сети p50 может быть отличным (60–90 мс до регионального CDN), но p95 вылезает к 280–400 мс — и именно он будет «ломать» автоматизацию. Тестируйте по расписанию: день/вечер/ночь, в будни и выходные. Запускайте параллельные тесты (5–20 потоков) — многие проблемы проявляются не в соло, а под реальной нагрузкой.

Не вся «мобильная труба» одинаково быстра. Результат дают связки: модем категории не ниже Cat6 (лучше Cat12+ с CA), корректная прошивка, активное охлаждение, качественный USB‑хаб с внешним питанием (просадки питания = обрывы и скачки пинга), внешние MIMO‑антенны с точной наводкой на сектор базовой станции. Размещение — критично: окно/подоконник часто уступают крыше и мачте. Длина и качество кабеля влияют на аттенюацию. В городах иногда помогает принудительная фиксация на менее загруженной частоте (если позволяет оборудование). На стороне прокси‑шлюза — быстрый диск/логгирование, достаточный backlog для сокетов, актуальный OpenSSL, грамотно настроенный DNS‑кеш. И не забывайте о температуре: перегретые модемы «дросселят» и ухудшают радиоалгоритмы, что напрямую растит джиттер.

Скорость скачивания — удобная, но упрощенная метрика. В реальном мире кампаний решают стабильность и предсказуемость. Джиттер — разброс задержек между запросами — бьет по браузерным сценариям и формам: интерфейсы «замирают», сессии пересобираются, появляются «ложные» повторные клики. Потери пакетов провоцируют повторные передачи и увеличивают TTFB в геометрической прогрессии, особенно на HTTP/2. Пороговые значения, проверенные на практике: джиттер до 20–30 мс — комфортно для большинства задач; 30–60 мс — терпимо, но чувствительные скрипты уже «подкусывает»; выше — начинаются валидаторы, капчи, повторные авторизации. Потери выше 1% уже заметно снижают пропускную способность TCP‑соединений. Следите за стабильностью IP‑сессии: «липкость» 15–30 минут часто критична для рекламных кабинетов и антифрод‑сценариев, где важны последовательные действия под одним мобильным IP.

• Джиттер: контролируйте p95 разброса задержек, а не только среднее.
• Потери пакетов: держите ниже 1%, для чувствительных задач — ниже 0,5%.
• Стабильность сессии/IP: «липкость» 15–30 минут и отсутствие неожиданных ротаций.

Достаточно доступных инструментов и дисциплины. Ставим на прокси‑шлюз легкий мониторинг: периодические TCP‑пинги до целевых хостов, TTFB‑замеры curl/httping, mtr по расписанию для выявления «виноватых» узлов. Записываем медиану, p90/p95/p99, потери и джиттер, логируем время суток. Раз в неделю — iperf3 к ближайшим тестовым серверам для оценки общей «трубы» и симметрии аплинк/даунлинк. На стороне приложения (скрипт/браузер) — транзакционные проверки: замер времени входа, загрузки конкретной страницы, отправки формы. Результаты складываем в timeseries (Influx/Prometheus или даже csv+графики), чтобы видеть тренды и эффект изменений: новая антенна, другой APN, замена хаба, перенос точки установки — насколько реально улучшили p95.

Среднее (mean) в мобильных сетях часто обманывает: один хороший период «съедает» десятки плохих. Работайте с распределением. p95 — это ваша «почти всегда», p99 — «почти никогда, но случается». Планируйте на p95: если TTFB p95 держится ниже 900 мс — большинство задач в порядке. Если p95 1500–2000 мс, а p99 улетает за 3 секунды — ждите таймаутов и повторов. Разница между медианой и p95 — главный маркер джиттера. Сокращая хвосты, вы прямо повышаете конверсию в шаги, где есть сложная JS‑логика, двухфакторные формы, загрузка креативов и т.п.

Связка простая: стабильный TTFB и низкие потери = меньше разрывов, ошибок и перезагрузок страниц. На практике у клиентов LTE CENTER при снижении p95 TTFB со ~1400 мс до ~800–900 мс частота таймаутов в формах падала на 28–40%, а время выполнения парсеров — ускорялось на 35–60% за счет меньшего числа повторов. В рекламе более ровная сетевая «картинка» снижает аномалии в поведении пользователя/аккаунта и уменьшает фоновую нагрузку на антифрод‑триггеры. Результат — меньше лишних проверок, отказов в операциях и «замерзших» интерфейсов. Конечные KPI зависят от ниши, но тренд один: сгладьте сетевые хвосты — и у вас растет завершенность сценариев, а косты на поддержку падают.

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

• Реклама: быстрый и стабильный вход в кабинеты, предсказуемые операции, ровная работа визуальных интерфейсов.
• Парсинг: конвейерная загрузка страниц/endpoint’ов, минимум повторов, контролируемый RPS без «захлебов».
• Антифрод/верификация: предсказуемая сетевой латентность, отсутствие резких пауз и «пучков» запросов.

На рекламных кабинетах критичны TTFB p95 и джиттер. Допустимые рубежи: TTFB p95 до 900 мс, джиттер до 20–30 мс, потери меньше 0,5–1%. В одном из проектов (38 кампаний в трех гео) перевод модемного пула на внешние антенны и балансер с грамотным DNS‑кешем сократил p95 TTFB с 1350 до 880 мс, а количество «зависаний» при загрузке библиотек интерфейса — на 31%. Экономия проявилась в банальном: меньше перезапусков и ручных ретраев, скорость загрузки креативов выросла на 22%. По деньгам — минус 12–18% операционных часов на обслуживание кампаний. Секрет прост: ровная сетевая «петля» делает поведение пользователя/аккаунта предсказуемым и снижает фоновые аномалии.

Для парсинга важнее стабильность, чем экстремальный пик Mbps. Практический минимум: 8–15 Мбит/с на 50–100 одновременных легких запросов хватает, если потери ниже 1% и p95 TTFB держится в 900–1200 мс. Как только джиттер скачет до 60–100 мс и выше, число повторов растет лавинообразно. В кейсе с 50 потоками на HTTP/2 при джиттере ~18 мс шли ~1000 страниц/мин с ошибками <1,5%. Тот же конфиг при джиттере ~80 мс падал до 540–600 страниц/мин, а ошибки выросли до 6–8%. Оптимизируйте: держите «липкие» сессии на 15–30 минут, избегайте внезапной ротации в середине глубокой навигации, включайте HTTP/2 (мультиплексирование экономит RTT), кешируйте DNS, лимитируйте RPS плавно (token bucket).

Системы антифрода и верификации любят «ровные» временные профили. Резкие паузы, «комки» запросов и внезапные разрывы соединений создают аномалии. Здесь целитесь в джиттер < 20–30 мс, потери < 0,5–1%, TTFB p95 < 900–1200 мс. «Липкая» сессия 15–30 минут снижает вероятность дополнительных проверок. По данным LTE CENTER, выравнивание p95 и снижение потерь с 1,8% до 0,6% уменьшало частоту повторных верификаций на 17–23% без изменений логики клиента. Это прямое сокращение издержек на поддержку и рост конверсии в «чистые» события.

Итог и цифры. Для большинства задач на мобильных прокси целесообразно настраивать и держать: — TTFB p95: 800–900 мс — отлично; до 1200 мс — рабочая норма; выше — точка внимания. — Джиттер: до 20–30 мс; выше 50 мс — начнутся «пилы» интерфейсов и лавина повторов. — Потери пакетов: < 0,5–1%; выше 1,5% — неизбежное проседание TCP и рост ошибок. — Пропускная способность: 10–20 Мбит/с на 50–100 легких потоков; масштабируйте горизонтально. — «Липкие» сессии: 15–30 минут для сценариев с последовательными действиями. Как этого добиться: 1) Радио и антенны — внешние MIMO, точная наводка на сектор БС, качественный коаксиал, модем Cat12+; фиксируйте частоты по ситуации. 2) Питание и охлаждение — активное охлаждение модемов, хабы с внешним питанием, мониторинг температуры; устраняйте троттлинг. 3) Прокси‑шлюз — быстрый CPU/диск, грамотный backlog сокетов, актуальный OpenSSL, локальный DNS‑кеш, HTTP/2. 4) Маршрут — тестируйте разные операторы/APN, выбирайте лучшую связность до ваших CDN/облаков; следите за CGNAT/ASN. 5) Мониторинг — автоматические замеры медианы/p95/p99 TTFB, джиттера, потерь; mtr по расписанию; алерты по порогам. 6) Ротация IP — предсказуемая: избегайте смены на середине критических цепочек; используйте «липкие» сессии. Опыт показывает: выравнивание p95 TTFB хотя бы на 400–600 мс и снижение потерь до 0,5–1% дает ощутимый эффект — минус 20–40% таймаутов, плюс 20–60% скорость парсинга, минус 10–25% вспомогательных проверок. Это измеряемые деньги и более спокойная работа команд.

Q1: Сколько мегабит нужно для 50 потоков парсинга?
A1: При потерях <1% и джиттере <30 мс хватает 10–20 Мбит/с. Ключ — стабильность, а не пиковая «скорость».

Q2: Какую метрику считать главной?
A2: TTFB p95 по реальным целевым доменам. Он отражает совокупность DNS/TCP/TLS/серверной обработки.

Q3: Когда менять оператора или APN?
A3: Если при нормальном радио p95 стабильно >1500 мс и mtr показывает «просадку» на магистрали/CGNAT. Сравните 2–3 варианта в одно время суток.

Q4: Нужна ли агрессивная ротация IP?
A4: Нет. Важнее предсказуемая «липкость» 15–30 минут: меньше разрывов, ниже джиттер «хвостов».

Q5: Что чаще всего «ломает» стабильность?
A5: Плохой сигнал/перегрев модемов, «слабый» DNS/балансер и перегруженная ячейка в прайм‑тайм. Начните с антенны и питания — это дешево и эффективно.