Прокси HTTP и SOCKS5: установка соединения и технические характеристики передачи данных

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

HTTP-прокси — это на самом деле две разные вещи

Термин «HTTP-прокси» обозначает два вида поведения, которые в сравнительных статьях обычно смешивают. В первом случае клиент отправляет обычный запрос, в строке запроса которого указан абсолютный URI, а не путь, и прокси принимает полноценное участие в процессе: он анализирует ваши заголовки, может кэшировать ответ, может его фильтровать и может добавлять свои собственные заголовки — заголовок Via, указывающий на себя, и X-Forwarded-For, содержащий ваш адрес. Это прокси-сервер переадресации, и он считывает всё.

Во втором случае клиент отправляет запрос CONNECT, указывая хост и порт вместо URL, и просит прокси перестать участвовать в HTTP-соединении. RFC 9110 описывает дальнейшие действия необычно простым языком: после ответа 2xx прокси-сервер превращается в туннель, который действует как «слепое» ретрансляционное устройство между двумя соединениями, не изменяя сообщения, и, как только туннель активирован, он вообще не считается участником HTTP-обмена. В спецификации в качестве сути этого механизма даже упоминается передача TLS через прокси-сервер, расположенный за общим брандмауэром.

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
>
< HTTP/1.1 200 Connection established
<
  ... every byte after this line is relayed untouched ...

Именно это различие определяет, насколько сохраняется стандартное сравнение. Поскольку в настоящее время практически весь трафик передается по HTTPS, в качестве HTTP-прокси вы фактически используете туннель, а не прокси-сервер перенаправления — а это означает, что кэширование, перезапись заголовков и фильтрация контента, которые в большинстве статей, сравнивающих HTTP и SOCKS5, приписываются стороне HTTP, просто не применимы к соединению, которое вы действительно будете открывать. Это реальные возможности прокси-сервера перенаправления, передающего открытый текст, и они по самой сути недоступны в туннеле.

Процесс установления соединения по протоколу SOCKS5, байт за байтом

Протокол SOCKS5, описанный в RFC 1928, никогда не узнаёт, какой именно протокол он передаёт. Обмен данными начинается с приветствия: клиент отправляет байт версии, количество поддерживаемых им методов аутентификации и сами коды методов. Сервер отвечает двумя байтами — версией и одним выбранным им методом. Если он отвечает 0xFF, это означает, что ни один метод не был приемлем, и клиент должен закрыть соединение.

Затем клиент отправляет запрос с указанием команды: 0x01 CONNECT для исходящего TCP-соединения, 0x02 BIND для входящего или 0x03 UDP ASSOCIATE. Тот же запрос содержит байт типа адреса — ATYP — который может принимать значение 0x01 для четырёхоктатного адреса IPv4, 0x03 для доменного имени, первый октет которого указывает его длину, или 0x04 для шестнадцатиоктатного адреса IPv6. Сервер отвечает, и начиная с этого ответа соединение представляет собой необработанные байты в обоих направлениях.

> 05 02 00 02              VER=5, 2 methods offered: none, user/pass
< 05 02                    server chose 02 (username/password)

> 05 01 00 03 0b 65 78 61  VER=5, CMD=01 CONNECT, RSV=00,
  6d 70 6c 65 2e 63 6f 6d  ATYP=03 domain, LEN=11 "example.com"
  01 bb                    port 443
< 05 00 00 01 ...          REP=00 succeeded, then raw bytes

Именно эта независимость от протоколов и составляет все преимущество SOCKS5, и это реальное преимущество. В приведённом выше обмене данными нигде не упоминается HTTP, поэтому один и тот же конечный узел может поддерживать сеанс SSH, SMTP-соединение, игровой клиент или внутренний бинарный протокол, для которого у HTTP-прокси просто не хватило бы «словарного запаса». В то время как HTTP-прокси требуется запрос, который он может проанализировать, или команда CONNECT, которую он может обработать, SOCKS5 нужны лишь адрес и порт.

Третья команда, UDP ASSOCIATE, является единственным исключением из правила «необработанных байтов TCP», и RFC 1928 оставляет некоторые её части опциональными — реализация, не поддерживающая фрагментацию, должна просто отбрасывать те датаграммы, с которыми она не может работать. Спецификация не может сказать, реализует ли данный сервер эту команду вообще, поэтому проверка прокси — это место, где можно решить этот вопрос в отношении конкретной конечной точки. Далее, за пределами этого предложения, эта тема на данной странице больше не затрагивается.

Одни и те же две фразы

HTTP CONNECT

1. Клиент прокси-серверу: CONNECT example.com:443

   Целью запроса является авторитетный сервер — хост и порт — а не URL с путем. Имя передается прокси по самой сути механизма, поэтому именно прокси занимается его разрешением.

2. Опционально: от прокси к клиенту: 407, затем от клиента к прокси: Proxy-Authorization

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

3. От прокси к клиенту: HTTP/1.1 200 Соединение установлено

   Начиная с этой строки, туннель уже существует. Прокси перестает участвовать в обмене данными.

4. От клиента к источнику через прокси: TLS, затем полезные данные

   Байты передаются без изменений в обоих направлениях. Прокси-сервер знает только ваше имя хоста и порт, и больше ничего.

SOCKS5

1. Клиент — прокси: версия 5 и список методов

   Приветственный запрос, в котором перечислены все методы аутентификации, которые клиент готов использовать; чаще всего это 0x00 (без аутентификации) и 0x02 (имя пользователя/пароль).

2. Прокси-сервер клиенту: выбранный им метод

   Два байта. Ответ 0xFF означает, что ни одно из предложенных значений не подходит, и клиент должен закрыть соединение.

3. По желанию — подэтап согласования в соответствии со стандартом RFC 1929

   Если выбран вариант с именем пользователя и паролем, клиент отправляет свои учетные данные, а сервер отвечает байтом статуса. Еще один цикл обмена данными.

4. От клиента к прокси-серверу: запрос с байтом ATYP

   Команда, затем тип адреса: 0x01 содержит четыре уже разрешенных октета, 0x03 — само доменное имя. Этот единственный байт является разветвлением для протоколов SOCKS5 и SOCKS5H.

5. От прокси к клиенту: сначала ответ, затем необработанные байты

   Код ответа 0x00 означает, что операция прошла успешно. Все, что следует за ним, относится к вашему протоколу и не проверяется.

Кто преобразует имя хоста в IP-адрес

Вопрос «Socks5 против Socks5h» вообще не имеет аналога в HTTP, и именно эта асимметрия является самым ярким существенным различием между этими двумя протоколами. HTTP-прокси по своей сути получает имя хоста: цель запроса CONNECT — это авторитетный сервер, а строка перенаправляемого запроса представляет собой абсолютный URI. В любом случае прокси получает имя и должен его разрешить, прежде чем сможет что-либо открыть. Не существует варианта взаимодействия с HTTP-прокси, при котором клиент уже выполнил поиск и вместо этого передаёт адрес.

SOCKS5 — единственный из этих двух протоколов, который предоставляет такой выбор, причем он передается в виде одного байта, а не в виде настройки. ATYP 0x01 указывает, что следующие четыре октета представляют собой адрес, который клиент уже разрешил. ATYP 0x03 указывает, что следующие байты представляют собой имя, которое прокси-сервер должен разрешить. Большинство клиентских библиотек по умолчанию выполняют разрешение локально, поэтому выбор обычно приходится делать сознательно.

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

В этом же байте скрывается ещё одно следствие. Поле ATYP 0x04 содержит IPv6-адрес длиной 16 октетов, поэтому SOCKS5-клиент, который локально преобразовал его в запись IPv6, может передать его напрямую — эта деталь имеет значение, если вы работаете с Мобильные прокси-серверы IPv6 и хотите узнать, какая сторона соединения выбрала семейство адресов.

Аутентификация и переход, который ни один из протоколов не шифрует

Эти два протокола используют совершенно разные механизмы аутентификации. HTTP-прокси, требующий учетных данных, отвечает на попытку подключения без аутентификации кодом состояния 407 «Proxy Authentication Required» и заголовком «Proxy-Authenticate», описывающим запрос на аутентификацию; клиент повторяет попытку, добавив заголовок «Proxy-Authorization». Это отказ, за которым следует повторная попытка, поэтому это требует одного цикла обмена данными, если только клиент не предоставит учетные данные заранее.

SOCKS5 никогда не отклоняет запросы и не выполняет повторные попытки. Метод согласовывается до того, как происходит что-либо другое: клиент перечисляет поддерживаемые им методы, сервер указывает один из них, и если этот метод равен 0x02, обе стороны проводят подсогласование в соответствии с RFC 1929 — байт версии 0x01, затем длина имени пользователя и само имя пользователя, затем длина пароля и сам пароль, каждый из которых составляет от одного до 255 октетов; в ответ передаётся двухбайтовый статус, в котором 0x00 означает успех. RFC 1928 также определяет значение 0x01 для GSSAPI, описанного отдельно в RFC 1961, хотя коммерческие прокси-серверы редко его поддерживают.

Различные механизмы, одинаковая позиция в плане безопасности: ни один из протоколов не шифрует канал связи между вами и прокси-сервером. В RFC 1929 прямо говорится об этом в отношении собственного метода, при этом содержится предупреждение: поскольку запрос передаёт пароль в открытом виде, использование субнегоциации не рекомендуется в средах, где перехват трафика возможен и практически осуществим. HTTP не лучше — авторизация через прокси со схемой Basic осуществляется с помощью кодировки base64, которая выбрана для обеспечения безопасности передачи, а не для шифрования, и может быть легко восстановлена любым устройством на пути передачи.

Это также самый наглядный способ понять, почему вопрос о протоколе и вопрос о конфиденциальности — это не одно и то же. Если вас на самом деле интересует, что именно скрывает прокси и от кого, а также чем это отличается от туннеля, который по своему дизайну шифрует первый узел, то это сравнение по-прежнему актуально прокси против VPN а не здесь.

Скорость: что поддается измерению, а что является мифом

Обычно утверждают, что SOCKS5 работает быстрее, поскольку не анализирует трафик. Это утверждение не выдерживает проверки на этапе установления соединения. Оба протокола прекращают анализ трафика в один и тот же момент — сразу после завершения установки соединения — и после этого оба становятся «слепыми» ретрансляторами, передающими одинаковые байты по одному и тому же TCP-соединению к одному и тому же источнику. Здесь нет никакой разницы в обработке на уровне отдельных байтов, которую можно было бы измерить, поскольку ни на одной из сторон обработка на уровне отдельных байтов не происходит.

Что касается задержки при установке соединения, то рейтинг здесь противоположен общепринятому мнению. HTTP CONNECT требует одного цикла обмена данными до получения первого байта полезных данных: отправка CONNECT, получение 200. SOCKS5 требует двух: приветствие, получение метода, отправка запроса, получение ответа. Если добавить аутентификацию по имени пользователя и паролю, то для SOCKS5 потребуется три цикла, в то время как для HTTP — только два, при условии, что клиент дожидается запроса на аутентификацию, а не отправляет учетные данные заранее. Эта арифметика принадлежит нам, а не RFC, но она прямо вытекает из количества сообщений, требуемых каждой спецификацией.

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

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

Что на самом деле хочет ваш клиент

Выбор протокола зависит от двух факторов: каков ваш трафик на самом деле и как клиент настраивает систему самостоятельно. Этот выбор не определяется каким-то общим правилом, поскольку в большинстве типичных случаев нет существенной разницы, на основе которой можно было бы сделать выбор.

Если прочитать последние две колонки, то можно прийти к объективному выводу: для HTTPS-трафика это один и тот же продукт. Если ваш трафик — это HTTPS-запросы из браузера, фреймворка для скрапинга или HTTP-библиотеки, оба решения туннелируют его одинаково, и правильным выбором будет то, которое изначально настроено в вашем инструменте.

Когда SOCKS5 — это то, что нужно

• Трафик вовсе не является HTTP — это SSH, SMTP, клиент базы данных, игровой клиент или внутренний бинарный протокол. Технически туннель CONNECT может передавать любой из них, но только в том случае, если клиент знает, как запросить его, а большинство клиентов, не использующих HTTP, этого не умеют.
• Вам нужна единая точка входа на уровне всей системы, на которую можно было бы настроить все компоненты компьютера, а не настройки HTTP-прокси для каждого приложения в отдельности, которые многие приложения просто игнорируют.
• Вам требуется разрешение имен на стороне прокси-сервера со стороны клиента, который поддерживает эту функцию только на тракте SOCKS, что является типичной ситуацией — настройка существует на стороне SOCKS и не имеет аналога в HTTP, который можно было бы включить или выключить.
• Вам нужна функция ретрансляции UDP, которую не поддерживает ни один HTTP-прокси. Реализует ли конкретный SOCKS5-сервер эту функцию — это отдельный вопрос, на который можно ответить только с помощью тестирования в режиме реального времени.

За пределами этих случаев более дешевый или простой вариант вполне подойдет, а выбор того, что уже поддерживает ваш клиент, не требует от вас никаких ощутимых затрат. PXM2 поставляется с поддержкой обоих вариантов на отдельных портах, поэтому выбор остается за клиентом, а не зависит от решения о покупке. Если вы все еще выбираете между категориями прокси, а не протоколами — а это уже другой вопрос, имеющий реальные финансовые последствия, — начните с объяснение типов прокси-серверов или Центр типов прокси.

Развертывание мобильных прокси-серверов HTTP и SOCKS5

Каждый мобильный прокси-сервер PXM2 предоставляет конечные точки HTTP и SOCKS5 на выделенных портах:

Часто задаваемые вопросы

Связанные руководства

Основы работы с прокси-серверами

Основные руководства по мобильным прокси-серверам