Глубокий анализ: как работает сеть резидентных прокси? Объяснение архитектуры
Как на самом деле работает сеть резидентных прокси? Технический разбор SDK, маршрутизации пиров, балансировки нагрузки и оптимизаций.
Это вопрос, который часто задают люди в индустрии прокси. Ниже приведено объяснение примерной архитектуры каждой сети резидентных прокси.
Сначала определим, что такое резидентная сеть: это сеть пиров, которые могут маршрутизировать пакеты данных к пунктам назначения.
Проще говоря, сеть резидентных прокси маршрутизирует ваши интернет-запросы через устройства реальных людей. Эти устройства привлекаются через приложения, на использование которых получено согласие пользователя, сеть выбирает оптимальное устройство для каждого запроса, и ответ возвращается вам так, как если бы вы просматривали сайт с того места. Сложность под поверхностью — вот что отличает быструю и надёжную резидентную сеть от медленной и ненадёжной.
1. SDK
Пиры привлекаются через SDK (набор для разработки), который интегрирован в потребительские приложения. На основе согласия пользователя SDK позволяет сети резидентных прокси маршрутизировать пакеты через устройство к пунктам назначения. Это фундаментальный элемент, который обеспечивает маршрутизацию запросов через реальные резидентные устройства.
2. Стандартные и проксированные запросы
Вот как маршрутизируется стандартный HTTPS-запрос (уровень 4–7). Значения RTT ниже кумулятивны; каждый уровень добавляется к текущему итогу и предполагает новое соединение:
TCP-рукопожатие (этап: 1 RTT | Кумулятивно: 1 RTT)
Пользователь отправляет SYN пункту назначения
Пункт назначения отправляет SYN-ACK пользователю
Пользователь отправляет ACK пункту назначения (данные могут передаваться на этом последнем сегменте)
Стоимость этапа: 1 RTT, приводя кумулятивное время к 1 RTT. RFC 9293.
Уровень 5/6: (этап: 1 RTT для TLS 1.3 / 2 RTT для TLS 1.2 | Кумулятивно: 2 RTT с TLS 1.3 / 3 RTT с TLS 1.2)
Пользователь отправляет ClientHello пункту назначения
Пункт назначения отправляет ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished пользователю
Стоимость этапа: 1 RTT для современного TLS 1.3 (кумулятивно: 2 RTT) или 2 RTT для устаревшего TLS 1.2 (кумулятивно: 3 RTT)
Сам по себе TLS 1.3 — это рукопожатие с 1 RTT, а TLS 1.2 — с 2 RTT; приведённые здесь значения кумулятивны и включают TCP-раунд, поэтому TLS 1.2 добавляет полный дополнительный RTT (всего 3 RTT). TLS 1.3 также может выполнять возобновление с 0-RTT на повторных соединениях с известным компромиссом воспроизведения.
Уровень 7: уровень приложения (этап: 1 RTT | Кумулятивно: 3 RTT с TLS 1.3 / 4 RTT с TLS 1.2)
Пользователь отправляет запрос + заголовки пункту назначения
Пункт назначения отправляет ответ + заголовки пользователю
Стоимость этапа: 1 RTT, что даёт финальное время до первого байта данных 3 RTT при TLS 1.3 или 4 RTT при TLS 1.2
Как только вы добавите прокси, это всегда добавляет как минимум один прыжок и некоторую задержку: путь становится длиннее (пользователь → прокси → пункт назначения и обратно), и прокси добавляет своё собственное время обработки. Добавляет ли это дополнительные раунды, зависит от типа прокси.
Завершающий прокси (HTTP-прокси пересылки, использующий CONNECT, или резидентный шлюз, открывающий собственное исходящее соединение) добавляет их: клиент сначала выполняет рукопожатие с прокси, а для HTTPS запрос CONNECT и его ответ «200 Connection Established» сами по себе — это раунд перед началом сквозного TLS-рукопожатия, затем прокси выполняет рукопожатие с пунктом назначения.
Прозрачный переадресовщик уровня 3/4, который не завершает соединение, оставляет рукопожатия сквозными и не добавляет лишних раундов, только увеличивает путь. В любом случае большее расстояние и больше посредников означают большую задержку, и это именно то, на минимизацию чего направлена остальная часть этой статьи.
3. Проблема «дорожной пробки»
Резидентные сети крайне сложны, потому что при интеллектуальной маршрутизации запросов без замедления сети есть множество нюансов.
Хорошая аналогия — дорожная сеть. Если слишком много автомобилей выберут один маршрут, возникает пробка. Идеальное состояние — нулевая пробка на всех маршрутах, достижимая только при интеллектуальной маршрутизации запросов в зависимости от пропускной способности каждого маршрута.
Каждый пир имеет ограниченную пропускную способность, прежде чем перегружается. Сети резидентных прокси должны постоянно собирать информацию о пропускной способности каждого устройства на сетевом уровне для балансировки нагрузки между пирами, удовлетворяя клиентов без перегрузки пиров.
4. Оптимизация со стороны поставщика
4a. DNS и дата-центры
Резидентная сеть должна использовать высокоскоростную транспортировку уровня дата-центра, где это возможно. Например, если клиент в Западной Европе маршрутизирует трафик через пиры в Восточной Европе, сеть должна использовать DNS-балансировщик нагрузки для получения этих пакетов в Западной Европе и передавать их по прямому маршруту дата-центра к ближайшему шлюзу, значительно снижая накладные расходы на задержку.
4b. Оптимизация уровня 4 внутри сети
На узлах дата-центра шлюза сеть должна использовать прямые маршруты и распределять шлюзы по всему миру для хорошего охвата. Между шлюзами и пирами каждый шлюз должен поддерживать предварительно установленные TCP-соединения и использовать взаимное TLS-шифрование для защиты устройства и шлюза.
4c. Оптимизация уровня 4 снаружи
SDK может поддерживать предварительно установленные TCP-соединения с популярными пунктами назначения, чтобы сэкономить 1 RTT между пиром и пунктом назначения, поскольку уровень приложения всегда можно восстановить на основе существующего TCP-соединения.
4d. Конфигурация параметров
Параметры TCP можно настраивать в реальном времени, чтобы сделать передачу пакетов более эффективной и снизить использование CPU и ОЗУ со стороны SDK. Минимизация потребления ресурсов критична. Если SDK создаёт негативный опыт на устройстве пира, издатели прекратят контракт с SDK.
4e. Алгоритм интеллектуальной маршрутизации (на основе производительности)
Это самая сложная, но наиболее эффективная оптимизация. Сеть поддерживает базу данных реального времени в памяти на всех шлюзах, которая может быть мгновенно запрошена для ответа на вопрос: «Какое устройство лучше всего подходит для маршрутизации этого запроса?»
Без этого алгоритма каждый второй запрос рискует быть направленным на медленный или перегруженный пир, и сеть рухнет при скромной нагрузке.
4f. Алгоритм ограничения IP (на основе репутации)
Сети резидентных прокси заинтересованы в сохранении репутации IP для каждого пункта назначения. Если одна треть пула занесена в чёрный список пунктами назначения A, B и C, пользователи, нацеленные на эти пункты, видят коэффициент ошибок 33 %. Маршрутизируя только через оставшиеся 67 % и помещая IP-адреса из чёрного списка на период охлаждения, сеть обеспечивает значительно лучший опыт для клиентов.
Алгоритмы ограничения IP сложны в построении и поддержании, но дают значительные улучшения качества сети при правильном выполнении.
5. Оптимизация со стороны клиента
5a. Дата-центры
Клиенты должны использовать серверы в дата-центрах, расположенных максимально близко к ближайшему шлюзу для целевого региона пиров. Для пиров в Нидерландах дата-центры Амстердама — логичный выбор. Вы также можете выполнить traceroute к шлюзу и выбрать поставщика с кратчайшим путём.
5b. DNS
Передавайте само имя домена вместо его разрешённого IP-адреса. Это позволяет пиру выполнить DNS-разрешение, что может привести к более эффективной маршрутизации. Всегда включайте домен в поле SNI, чтобы TLS-рукопожатие могло завершиться успешно.
5c. Геотаргетинг
Хотя геотаргетинг может снизить задержку до целевых пиров, он имеет и недостатки. Если в конкретной геолокации недостаточно пиров для удовлетворения вашей параллельности, запросы будут завершаться ошибкой или задержка резко возрастёт. Изучите ограничения целевой геолокации и отслеживайте метрики её состояния, прежде чем полагаться на неё исключительно.
5d. Оптимизация уровня 4 и sticky-сессий
По стандартам отрасли аутентификация передаётся через закодированный в Base64 заголовок Proxy-Authorization, наряду с параметрами запроса, такими как sticky-сессия и геотаргетинг. Как только запросы прибывают на шлюз, эти параметры декодируются и применяются.
Профессиональный пользователь прокси поддерживает одно соединение на IP, отслеживает выходящий IP каждые 10–20 секунд, чтобы убедиться, что пир всё ещё активен, и балансирует нагрузку между пирами на основе производительности. Например, если целевой сайт ограничивает частоту запросов после 50 запросов, снижайте интенсивность на 25–30 или выполняйте ротацию при достижении лимита.
Основной принцип: когда пиров недостаточно, максимизируйте возможности каждого пира с точки зрения лимитов частоты запросов, скорости сети и управления перегрузками.
Опубликовано Алоном Леви, генеральным директором FlashProxy
Об авторе: Алон Леви — генеральный директор FlashProxy и имеет обширный опыт в инфраструктуре прокси, архитектуре сетей и технологиях крупномасштабной маршрутизации IP.
Свяжитесь в LinkedIn · Контакт: [email protected]
Часто задаваемые вопросы
Почему резидентные прокси медленнее прокси дата-центров?
Резидентные прокси маршрутизируют запросы через реальные потребительские устройства на домашних интернет-соединениях. Это добавляет как минимум один дополнительный сетевой прыжок, а для завершающих шлюзов — дополнительные раунды установки соединения, на фоне переменной скорости домашнего широкополосного доступа, что делает их медленнее, чем прокси, размещённые напрямую в дата-центрах.
Что такое sticky-сессия в прокси?
Sticky-сессия направляет запросы через один и тот же IP-адрес в течение установленного времени. Это полезно для задач, требующих непрерывности сессии, таких как сохранение состояния входа или удержание корзины покупок.
Почему IP-адреса резидентных прокси попадают в чёрные списки?
Когда резидентный IP отправляет слишком много запросов на конкретный пункт назначения, этот сайт может пометить и заблокировать его. Сети, которые перенасыщены или плохо управляются, ускоряют этот процесс, сокращая пригодный пул IP для всех пользователей.
Что такое пир прокси?
Пир прокси — это реальное потребительское устройство (телефон, компьютер или смарт-ТВ), интернет-соединение которого используется для маршрутизации трафика прокси с согласия владельца устройства через SDK, интегрированный в установленное им приложение.
Источники и ссылки
IETF RFC 9293, Transmission Control Protocol: https://datatracker.ietf.org/doc/html/rfc9293
IETF RFC 8446, TLS 1.3 (1-RTT handshake; 0-RTT resumption): https://datatracker.ietf.org/doc/html/rfc8446
IETF RFC 5246, TLS 1.2 (2-RTT handshake): https://datatracker.ietf.org/doc/html/rfc5246
IETF RFC 9110, HTTP Semantics (CONNECT method): https://datatracker.ietf.org/doc/html/rfc9110
IETF RFC 6066, TLS Server Name Indication (SNI): https://datatracker.ietf.org/doc/html/rfc6066
IETF RFC 7235, HTTP/1.1 Authentication (Proxy-Authorization): https://datatracker.ietf.org/doc/html/rfc7235
MDN Web Docs, HTTP CONNECT method: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT
Cloudflare, forward-proxy latency: https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/
Cloudflare Learning Center, What is SNI?: https://www.cloudflare.com/learning/ssl/what-is-sni/
Ilya Grigorik, High Performance Browser Networking: https://hpbn.co/
