Серверные прокси IPv4: откуда берутся адреса дата-центров

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

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

Что стоит за серверным адресом на уровне железа

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

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

Адрес при этом закреплён за оборудованием площадки постоянно. Он не меняется от перезагрузки, не зависит от абонентского оборудования и не уходит в общую трансляцию вместе с сотнями соседей. Мы держим свой парк именно в таком виде, поэтому серверные прокси IPv4 на собственном оборудовании работают ровно под нагрузкой в сотни одновременных соединений.

Путь блока IPv4: от регистратора до порта в стойке

Адреса раздаются иерархией из трёх уровней. Наверху стоит IANA, она распределяет крупные блоки между пятью региональными регистраторами. Регистраторы известны по названиям: RIPE NCC обслуживает Европу и Ближний Восток, ARIN Северную Америку, APNIC Азию и Тихоокеанский регион, LACNIC Латинскую Америку, AFRINIC Африку.

Второй уровень это участники регистратора, к ним относятся операторы связи, хостинговые площадки и крупные организации со своей сетью. Участник получает блок и вносит его в базу регистратора. Минимальный блок, который принято анонсировать наружу, это /24 на 256 адресов: маршруты мельче большинство сетей в глобальную таблицу не принимает.

Третий уровень это назначение внутри блока. Площадка делит полученный диапазон на части и расписывает их по своим задачам и клиентам, отмечая назначение отдельными записями. В базе такая запись отличается статусом: у выданного регистратором блока стоит ALLOCATED PA, у назначенного внутри него участка ASSIGNED PA.

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

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

Автономная система и номер AS: как блок попадает в маршруты

Одной записи в базе для работы мало, блок нужно анонсировать. Здесь появляется автономная система: набор сетей под единым управлением с общей политикой маршрутизации. У каждой такой системы есть номер вида AS64512, выдаёт его тот же региональный регистратор.

Анонс идёт по протоколу BGP. Площадка сообщает соседним сетям: диапазон 192.0.2.0/24 доступен через AS64512. Соседи передают маршрут дальше, и через несколько минут запись расходится по глобальной таблице. Обратный трафик к любому адресу из этого диапазона начинает приходить на оборудование площадки.

Рядом с анонсом живут две проверочные записи. Объект route в базе регистратора связывает диапазон с номером автономной системы. Подпись ROA в системе RPKI закрепляет эту же связку криптографически, и крупные операторы отбрасывают анонсы, которые с подписью расходятся. Обе записи публичны, поэтому пара диапазон плюс номер AS проверяется кем угодно за пару секунд.

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

Как площадка определяет принадлежность адреса

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

# кто владеет диапазоном и где его границы
whois 192.0.2.55 | grep -iE "inetnum|netname|descr|country|org|status|mnt-by"

# номер автономной системы для адреса
whois -h whois.cymru.com " -v 192.0.2.55"

# то же самое через DNS, без установки клиента whois
dig +short 55.2.0.192.origin.asn.cymru.com TXT

# обратная запись имени
dig +short -x 192.0.2.55

Ответ whois разбирается по полям. inetnum показывает границы диапазона, netname короткое имя сети, descr описание владельца, country страну регистрации записи, org организацию, status тип выдачи, mnt-by того, кто ведёт запись. Крупные площадки берут отсюда владельца и сопоставляют его со своими списками.

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

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

Здесь же становится понятно, почему счётчики частоты нередко работают по целому блоку. Границы диапазона известны публично, поэтому площадке ничего не стоит агрегировать обращения по всему /24 сразу. Разбор этой механики вынесен в отдельный материал про подсеть и диапазон адресов.

Почему серверные адреса отвечают быстро и ровно

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

Маршрут короткий, потому что дата-центр стыкуется с магистральными операторами напрямую и присутствует в точках обмена трафиком. Трассировка до крупной площадки укладывается в 8 или 12 переходов. Канал широкий и симметричный: отдача равна приёму, поэтому сотня параллельных запросов не упирается в узкое горлышко на исходящем направлении.

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

# замер по фазам соединения через посредник
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" \
  -x http://192.0.2.55:8000 https://example.com/catalog

Смотрим на две величины из вывода, они разделяют ответственность между сетью и целевым сайтом. Поле time_connect показывает установку соединения и отражает сетевую задержку до посредника. Поле time_starttransfer показывает время до первого байта ответа и включает работу целевого сайта. Когда первое стабильно, а второе гуляет, дело в целевой площадке, и настройки посредника тут ни при чём. Порядок правильного замера с прогревом соединений разобран в материале про скорость и время отклика.

Где серверный адрес видно в логах

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

В журнале веб-сервера адрес стоит первым полем строки доступа. Формат combined у nginx и Apache пишет туда переменную remote_addr, дальше идут время, метод, путь, код ответа и заголовок User-Agent. Когда запрос прошёл через посредник, сюда попадает адрес посредника, и исходный адрес клиента до сервера не доходит.

192.0.2.55 - - [12/Feb:04:18:31 +0000] "GET /catalog/page/7 HTTP/1.1" 200 18422 "-" "Mozilla/5.0"

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

Received: from mail.example.net (unknown [192.0.2.55])
        by mx.example.org with ESMTPS id 4a91c2b0

Отдельная тема это заголовки, которые добавляет сам посредник. Простые HTTP-посредники умеют вписывать поля X-Forwarded-For и Via с исходным адресом клиента, и тогда принимающая сторона видит обе точки сразу. Мы лишних полей к запросу не добавляем, что легко проверить запросом к сервису эхо-заголовков.

curl -s -x http://192.0.2.55:8000 https://httpbin.org/headers

Как площадки относятся к серверным диапазонам

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

Что реально смотрит принимающая сторона: частоту обращений с адреса и с его диапазона, полноту и согласованность заголовков браузера, работу с куками и сессией, порядок обхода страниц, скорость перехода между разделами. Ровный прогон с человекоподобным темпом и корректным набором заголовков проходит спокойно. Прогон в тысячу потоков без пауз и с пустым User-Agent заметен на любом источнике.

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

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

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

Под какие задачи серверный набор подходит лучше всего

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

Массовый сбор открытых данных стоит первым. Каталог поставщика на 40 000 карточек, прайсы, остатки, характеристики: тут нужны сотни параллельных соединений и ровный отклик на протяжении многих часов. Трафик на всех пакетах безлимитный, поэтому объём выкачки на планирование не влияет и считать гигабайты незачем. Тем, у кого прогоны идут круглосуточно, подходят пакеты с безлимитным трафиком.

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

Четвёртая задача это почта и произвольные протоколы. Клиенты SMTP, IMAP и POP3 ходят по TCP на портах 465, 587, 993 и 995, поэтому здесь берут сокетный вариант: прокси SOCKS5 для почты и произвольных портов проводят трафик любого приложения и умеют разрешать имена на своей стороне.

Практический порядок запуска короткий. Перед покупкой доступен бесплатный тест до 2 часов под конкретный запрос: выбирается тип прокси под свой софт, дальше регистрация в кабинете, запрос теста из меню, указание своего адреса в настройках и активация. После оплаты пакет включается примерно за 5 минут, список забирается ссылкой или файлом в форматах IP:PORT и IP:PORT:LOGIN:PASS. Состав набора, сроки доступа и лимиты потоков собраны там, где оформляется серверный пул IPv4 и SOCKS5, а разбор пакетов по срокам лежит на странице, где можно купить прокси IPv4 на нужный срок.

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

Сколько адресов держится в серверном пуле?

В пуле около 12 000 активных IPv4 и SOCKS5, суточный онлайн держится примерно на этой же отметке. Список обновляется в режиме реального времени, поэтому строки, которые перестали отвечать, уходят из выдачи сами. Доступ к перечню открыт только клиентам сервиса.

Прокси каких стран есть в списке?

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

Какой протокол выбрать для серверного адреса?

В пакете доступны IPv4 с HTTP и HTTPS, а также SOCKS4 и SOCKS5. Мы рекомендуем SOCKS5: он проводит трафик любого приложения, работает с произвольными портами и разрешает имена узлов на стороне посредника. Адреса при этом одни и те же, меняется только строка подключения.

Чем проверить адреса из списка?

Для массовой проверки подходит чекер от Zennolab, у него есть демонстрационная версия. Список загружается целиком, дальше видно отвечающие строки, время отклика и тип прокси. Для точечной проверки хватает запроса через curl на сервис определения адреса и сверки значения со строкой из выдачи.

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