Глибокий аналіз: як працює мережа резидентних проксі? Пояснення архітектури
Як насправді працює мережа резидентних проксі? Технічний розбір SDK, маршрутизації пірів, балансування навантаження та оптимізацій.
Це питання часто задають люди в індустрії проксі. Нижче наведено пояснення приблизної архітектури, що стоїть за кожною мережею резидентних проксі.
Спочатку визначимо, що таке резидентна мережа: мережа пірів, які можуть перенаправляти пакети до пунктів призначення.
Простіше кажучи, мережа резидентних проксі маршрутизує ваші інтернет-запити через пристрої реальних людей. Ці пристрої залучаються через додатки, на які вони дали згоду, мережа вибирає найкращий пристрій для кожного запиту, а відповідь повертається до вас так, ніби ви переглядали з тієї локації. Складність під поверхнею — це те, що розрізняє швидку, надійну резидентну мережу від повільної, ненадійної.
1. SDK
Пірів залучають через SDK (Software Development Kit), який інтегрується у споживчі додатки. На основі згоди користувача SDK дозволяє мережі резидентних проксі маршрутизувати пакети через пристрій до пунктів призначення. Це фундаментальний елемент, який дозволяє проксирувати запити через реальні резидентні пристрої.
2. Стандартні та проксовані запити
Ось як маршрутизується стандартний HTTPS-запит (L4 до L7). Рахунки RTT нижче є сукупними; кожен рівень додається до поточного підсумку і припускає нове з'єднання:
TCP Handshake (Крок: 1 RTT | Сукупний: 1 RTT)
Користувач надсилає SYN до пункту призначення
Пункт призначення надсилає SYN-ACK користувачу
Користувач надсилає ACK до пункту призначення (дані можуть йти в цьому останньому сегменті)
Вартість кроку: 1 RTT, доводячи поточний сукупний час до 1 RTT. RFC 9293.
L5/L6: (Крок: 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 handshake, а TLS 1,2 — 2-RTT; загальні значення тут сукупні і включають TCP раунд-трип, тому TLS 1,2 додає ще один повний RTT (всього 3 RTT). TLS 1,3 також може робити 0-RTT resumption при повторних з'єднаннях, з відомим компромісом повтору.
L7: Прикладний рівень (Крок: 1 RTT | Сукупний: 3 RTT з TLS 1,3 / 4 RTT з TLS 1,2)
Користувач надсилає Request + Headers до пункту призначення
Пункт призначення надсилає Response + Headers користувачу
Вартість кроку: 1 RTT, доводячи остаточний час до першого байта даних до 3 RTT при TLS 1,3 або 4 RTT при TLS 1,2
Коли ви додаєте проксі, він завжди додає принаймні один хоп і деяку затримку: шлях довший (користувач → проксі → пункт призначення, і назад), а проксі додає власний час обробки. Чи додає він раунд-трип, залежить від типу проксі.
Завершуючий проксі (HTTP forward proxy, що використовує CONNECT, або резидентний шлюз, що відкриває власне вихідне з'єднання) додає їх: клієнт спочатку робить handshake з проксі, а для HTTPS запит CONNECT і його відповідь «200 Connection Established» — це раунд-трип самі по собі, перш ніж навіть розпочинається наскрізний TLS handshake, потім проксі робить handshake до пункту призначення.
Прозорий L3/L4 forwarder, який не завершує з'єднання, залишає handshakes наскрізними і не додає додаткових раунд-трипів, просто довший шлях. У будь-якому випадку, більша відстань і більше посередників означають більше затримки, що саме те, про мінімізацію чого йдеться в цій статті.
3. Проблема «пробки»
Резидентні мережі надзвичайно складні, тому що існує багато тонкощів у розумній маршрутизації запитів без гальмування мережі.
Хорошою аналогією є дорожна мережа. Якщо занадто багато автомобілів їдуть одним маршрутом, він стає закупореним. Ідеалом є нульова перевантаженість на кожному маршруті, досяжна лише розумною маршрутизацією запитів на основі пропускної здатності кожного маршруту.
Кожен піер має обмежену пропускну здатність, перш ніж він стане перевантажений. Мережі резидентних проксі повинні постійно збирати інформацію про мережеву пропускну здатність кожного пристрою, щоб балансувати навантаження на пірів, задовольняючи клієнтів без перевантаження пірів.
4. Оптимізації на стороні постачальника
4a. DNS та датацентри
Резидентна мережа повинна використовувати транспорт на рівні датацентру де це можливо. Наприклад, якщо клієнт в Західній Європі маршрутизується через східноєвропейських пірів, мережа повинна використовувати DNS load-balancer для отримання цих пакетів в Західній Європі і передачі їх через прямий маршрут датацентру до найближчого шлюзу, суттєво мінімізуючи навантаження на затримку.
4b. Оптимізація внутрішнього Layer 4
На глобальних вузлах датацентру шлюзів мережа повинна використовувати прямі маршрути і розповсюджувати шлюзи по всьому світу для хорошого покриття. Між шлюзами та пірами кожен шлюз повинен підтримувати розігріті TCP з'єднання і використовувати взаємне TLS шифрування для захисту як пристрою, так і шлюзу.
4c. Оптимізація зовнішнього Layer 4
SDK може підтримувати розігріті TCP з'єднання до популярних пунктів призначення, щоб заощадити 1 RTT між піром і пунктом призначення, оскільки прикладний рівень завжди можна перебудувати поверх існуючого TCP з'єднання.
4d. Конфігурації параметрів
TCP параметри можна налаштовувати в реальному часі, щоб зробити передачу пакетів більш ефективною і зменшити використання CPU/RAM SDK. Мінімізація споживання ресурсів критична. Якщо SDK створює негативний досвід на пристрої піра, видавці скасують контракт SDK.
4e. Алгоритм інтелектуальної маршрутизації (на основі продуктивності)
Це найскладніша, але найефективніша оптимізація. Мережа підтримує базу даних в реальному часі в пам'яті на всіх шлюзах, яку можна миттєво запитати, щоб відповісти: «Який пристрій найкраще підходить для маршрутизації цього запиту?»
Без цього алгоритму кожен другий запит ризикує бути маршрутизованим до повільного або перевантаженого піра, і мережа зруйнується під помірним навантаженням.
4f. Алгоритм обмеження IP (на основі репутації)
Резидентні мережі зацікавлені у збереженні репутації IP для кожного пункту призначення. Якщо одна третина пулу внесена в чорний список від пунктів призначення A, B та C, користувачі, що спрямовуються на ці пункти призначення, бачать рівень помилок 33 %. Маршрутизуючи лише через решту 67 % і розміщуючи IP з чорного списку на охолоджування, мережа доставляє значно кращий досвід для клієнтів.
Алгоритми обмеження IP складні для побудови та підтримки, але дають значні покращення якості мережі при правильному виконанні.
5. Оптимізації на стороні клієнта
5a. Датацентри
Клієнти повинні використовувати сервери в датацентрах, розташованих якомога ближче до найближчого шлюзу для їх цільового регіону піра. Для пірів в Нідерландах датацентри Амстердама — логічний вибір. Ви також можете зробити traceroute до шлюзу і вибрати постачальника з найкоротшим шляхом.
5b. DNS
Передавайте саму назву домену замість його розв'язаної IP адреси. Це дозволяє піру виконувати розпізнавання DNS, що може привести до більш ефективної маршрутизації. Завжди включайте домен в поле SNI, щоб TLS handshake міг успішно завершитися.
5c. Географічне спрямування
Хоча географічне спрямування може зменшити затримку до цільових пірів, воно також має недоліки. Якщо конкретна географія не має достатньо пірів для задоволення вашої одночасності, запити не виконуватимуться або затримка зросте. Вивчіть обмеження вашої цільової географії та стежте за її метриками здоров'я перед тим, як покладатися на неї виключно.
5d. Оптимізації L4 та Sticky Session
За стандартом індустрії, аутентифікація передається через Proxy-Authorization заголовок в Base64 кодуванні, разом з параметрами запиту, такими як sticky session та географічне спрямування. Як тільки запити прибувають до шлюзу, ці параметри розкодовуються та застосовуються.
Професійний користувач проксі підтримує одне з'єднання на IP, моніторує вихідну IP кожні 10–20 секунд, щоб підтвердити, що піер ще живий, та розподіляє навантаження на пірів на основі продуктивності. Наприклад, якщо цільовий обмежує після 50 запитів, зупиніться на 25–30 або виконайте ротацію, коли ліміт досягнуто.
Основний принцип: коли недостатньо пірів доступно, максимізуйте можливість кожного піра в плані обмежень швидкості, швидкості мережі та управління перевантаженням.
Опубліковано Алоном Леві, генеральним директором FlashProxy
Про автора: Алон Леві — генеральний директор FlashProxy та має великий досвід в інфраструктурі проксі, архітектурі мережі та великомасштабних технологіях IP-маршрутизації.
Зв'яжіться в LinkedIn · Контакт: [email protected]
Часті запитання
Чому резидентні проксі повільніші за датацентрові проксі?
Резидентні проксі маршрутизують запити через реальні споживчі пристрої на домашніх інтернет-з'єднаннях. Це додає принаймні один додатковий мережевий хоп, а для завершуючих шлюзів — додаткові раунд-трипи встановлення з'єднання, крім змінної швидкості домашнього широкосмугового з'єднання, що робить їх повільнішими за проксі, розміщені безпосередньо в датацентрах.
Що таке sticky session в проксі?
Sticky session зберігає запити маршрутизованими через одну і ту ж 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/
