Трафик резидентных прокси: как он считается и почему тает быстрее, чем кажется

Логика кажется железной: тариф резидентных прокси считается по гигабайтам, значит расход равен весу страниц, которые вы открываете. Открыли карточку товара на 400 килобайт - списали 400 килобайт. Собрали тысячу таких карточек - получили около 400 мегабайт. Удобно, предсказуемо и почти всегда неверно.

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

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

Из чего складывается гигабайт трафика?

Главное. Гигабайт трафика - это сумма всех байтов, прошедших через прокси в обе стороны, а вес финальной страницы на экране тут ни при чём.

Когда вы открываете любую современную страницу, браузер или парсер отправляет не один запрос, а десятки. Сначала приходит HTML-документ. В нём прописаны ссылки на стили, скрипты, шрифты, картинки, иконки, рекламные трекеры и вызовы к внутренним API. Каждый такой элемент загружается отдельным запросом. У запроса есть исходящая часть (адрес, заголовки, cookie, токены авторизации) и входящая (тело ответа). Прокси стоит посередине и считает оба потока. Для счётчика провайдера нет разницы, нужен вам этот файл или нет: если байты прошли через канал, они списаны.

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

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

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

Вывод из таблицы простой: текст, ради которого вы запускали сбор, занимает малую часть счёта. Основную массу гигабайтов съедает обвязка страницы, то, что человек в браузере даже не замечает, а робот честно скачивает.

Почему один запрос тянет больше, чем весит страница?

Главное. Между запросить страницу и получить нужные данные лежит цепочка технических действий, и каждое звено этой цепочки тоже считается в трафик.

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

Вторая причина - повторные попытки. Резидентный IP может ответить медленно или оборваться, и парсер отправляет запрос заново. Если на десятой доле запросов случается ретрай, вы уже платите за эти запросы дважды. На нестабильных пулах доля повторов выше, и трафик растёт незаметно.

Третья причина - headless-браузер. Когда сайт отдаёт контент только после исполнения скриптов, простым запросом HTML не обойтись, и в дело идёт полноценный браузер без окна. Он ведёт себя как настоящий: грузит картинки, шрифты, аналитику, рекламные пиксели, фоновые обращения к API. Одна страница в таком режиме может весить в несколько раз больше, чем её же HTML, полученный напрямую.

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

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

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

Сложите это вместе, и страница на 400 килобайт легко превращается в мегабайт списанного трафика. Не потому что провайдер химичит со счётчиком, а потому что канал реально прокачал этот объём.

Чем учёт трафика отличается у резидентных и датацентр-прокси?

Главное. Резидентные прокси почти всегда продаются по гигабайтам, потому что их ресурс дефицитный, а датацентр-прокси чаще берут по числу адресов или потоков, где трафик почти ничего не стоит.

Датацентр-прокси живут на серверах в дата-центрах. Канал там широкий и дешёвый, адресов можно поднять сколько угодно. Поэтому продавцу выгоднее считать количество IP или число одновременных соединений, а сам объём байтов не важен: вы платите за доступ, а сколько прокачаете, ваше дело. Для тяжёлого сбора с большим объёмом данных это часто выгоднее.

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

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

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

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

Как оценить расход трафика на задачу?

Главное. Точный расход даёт только замер на маленькой пробе; прикидка по весу страниц в браузере почти всегда занижает результат.

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

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

Замеряйте именно тем инструментом и в том режиме, в котором пойдёт боевой сбор. Замер через headless-браузер и замер через прямой запрос HTML дадут цифры, отличающиеся в разы. Если объёмы большие и стабильные, посчитайте, во сколько обойдётся помесячная оплата по гигабайтам, и сравните с фиксированным тарифом: бывает, что когда безлимитный тариф выгоднее оплаты за гигабайты, порог наступает раньше, чем кажется. Ориентир такой: чем тяжелее страницы и чем больше объём, тем быстрее гигабайтный тариф догоняет и обгоняет фиксированный.

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

Как сократить расход трафика?

Главное. Основная экономия приходит из одного правила: качать только нужные байты и не тянуть всё подряд.

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

Второе - ходить в API вместо HTML, когда это возможно. Многие сайты и маркетплейсы подгружают товары через внутренние запросы, которые возвращают компактный JSON. Такой ответ весит в разы меньше отрисованной страницы со всей обвязкой. Найти эти запросы можно в панели разработчика во вкладке сети.

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

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

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

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

Начните с малого. Возьмите одну свою задачу, прогоните пробную партию в сотню-другую страниц, посмотрите фактический расход в кабинете и сравните с тем, что вы прикидывали в уме. Разница вас, скорее всего, удивит и сразу подскажет, где резать: картинки, headless или ретраи. Тот, кто считает трафик заранее, платит за данные; тот, кто считает постфактум, платит за сюрпризы. А когда научитесь считать трафик заранее, загляните в остальные разборы и соберите под свои объёмы тариф, который не закончится к середине месяца.