SOCKS- и HTTP-прокси: различия, скорость и выбор протокола
HTTP- и SOCKS-прокси соединяют программу с адресатом через посредника. Для браузера, парсера или API-клиента разумно начать с HTTP-прокси, который поддерживает CONNECT. SOCKS5 полезен, когда программа рассчитана на SOCKS, работает с другими TCP-протоколами или умеет передавать UDP через прокси. Оба варианта подходят для подключения к HTTPS-сайтам.
Протокол определяет, как программа общается с прокси. Происхождение выходного IP, ротация и выделенный или общий доступ — отдельные характеристики, разобранные в руководстве по типам прокси и выбору подключения. Сам по себе переход с HTTP на SOCKS не меняет ни одну из них.
Как HTTP и SOCKS передают соединение
HTTP-пересылка: прокси обрабатывает веб-запрос
При обычном незашифрованном HTTP-запросе клиент передаёт прокси целевой URL, метод и заголовки. Прокси обрабатывает запрос и получает ответ от адресата. Он может применять правила для HTTP, менять заголовки или использовать кеш, если это предусмотрено настройками. Это возможные функции HTTP-прокси; конкретный сервис не обязательно включает их все.
SOCKS5: прокси открывает соединение для программы
Клиент согласует способ аутентификации, при необходимости проходит её и передаёт адрес и порт назначения. Затем прокси устанавливает нужное TCP-соединение и пересылает данные программы. Через такой механизм могут работать HTTPS, SSH и другие поддерживаемые протоколы поверх TCP. Для пересылки прокси не требуется разбирать HTTP-запросы.
HTTPS через CONNECT: способы работы становятся ближе
При открытии HTTPS-сайта через обычный HTTP-прокси клиент, как правило, отправляет запрос CONNECT. Когда прокси подтверждает создание туннеля, клиент устанавливает внутри него TLS-соединение с сайтом. Прокси пересылает зашифрованные данные. SOCKS5 после своего согласования может передавать такой же TLS-обмен.
Это важно для сравнения скорости и конфиденциальности: HTTP-прокси с HTTPS-туннелем не разбирает каждый зашифрованный запрос страницы. Оба типа пересылают защищённый трафик. Последовательность действий и отличие пересылки HTTP от туннелирования разобраны в статье «HTTP- и HTTPS-прокси».
Краткое сравнение HTTP и SOCKS5
Ниже сравнивается именно SOCKS5. Более старые SOCKS4 и SOCKS4a имеют меньше возможностей и прежде всего нужны там, где их требует существующее ПО.
| Возможность | HTTP- / HTTPS-прокси | SOCKS5-прокси |
|---|---|---|
| Веб-запросы | Пересылка HTTP; для HTTPS обычно создаётся туннель CONNECT. | Программа передаёт HTTP или HTTPS через установленное соединение. |
| Другие TCP-приложения | Возможны через CONNECT, если клиент это умеет, а порт назначения разрешён. | Подходит программам со встроенной поддержкой SOCKS; правила сервиса тоже действуют. |
| DNS адресата | Прокси может разрешить имя, переданное в запросе или адресе назначения CONNECT. | Клиент может передать имя для удалённого разрешения или сначала получить IP локально. |
| Защита соединения с прокси | HTTPS-прокси использует TLS на этом участке. Обычный HTTP-прокси — нет. | Обычные режимы без аутентификации и с логином и паролем не шифруют это соединение. |
| Контроль доступа | Методы HTTP-аутентификации и/или правила сервиса, например список разрешённых IP. | Согласуемые методы аутентификации и/или правила сервиса, например список разрешённых IP. |
| UDP | Обычного CONNECT недостаточно. Нужен дополнительный поддерживаемый механизм туннелирования UDP. | Предусмотрен протоколом, но должен быть реализован в клиенте и сервисе. |
| Скорость | При открытии нового HTTPS-туннеля может потребоваться меньше обменов с прокси. Скорость передачи также зависит от реализации и маршрута. | Есть собственные этапы согласования. Отсутствие разбора HTTP не гарантирует более быструю передачу HTTPS. |
Что быстрее: HTTP или SOCKS5?
Новое HTTPS-соединение может быстрее открыться через HTTP CONNECT: при обычном подключении требуется меньше обменов с прокси. Ниже показано, при каких условиях возникает эта разница. Готовый туннель можно использовать для длительной загрузки или следующих запросов. По скорости передачи через уже открытое соединение ни у одного протокола нет постоянного преимущества.
Новые соединения: считаем обмены
Считаем сообщения после того, как TCP-соединение с прокси уже открыто: программа отправляет запрос и ждёт ответ, прежде чем перейти к следующему этапу. В этом сравнении TLS до прокси не используется. HTTP-аутентификация либо не нужна, либо проходит с реквизитами, отправленными в первом запросе CONNECT.
| Способ подключения | Обмены до готовности туннеля |
|---|---|
HTTP CONNECT | 1: запрос CONNECT и успешный ответ. |
| SOCKS5 без протокольной аутентификации | 2: выбор метода, затем запрос соединения и ответ. |
| SOCKS5 с логином и паролем | 3: выбор метода, проверка логина и пароля, затем запрос соединения и ответ. |
При этих условиях SOCKS5 добавляет один обмен туда и обратно между клиентом и прокси без аутентификации или два — со стандартной аутентификацией по логину и паролю. Время такого обмена называется RTT: сообщение должно дойти до прокси, а ответ — вернуться. При условном RTT 50 мс дополнительные обмены дают примерно 50 или 100 мс ожидания. Это оценка по последовательности протокола, а не результат испытания сервиса и не полное время запроса.
В обоих случаях прокси также должен подключиться к адресату, а клиент — установить TLS-соединение с сайтом. Время DNS, обработки и ожидания в сети может различаться. Запрос HTTP-аутентификации от прокси добавляет обмены; TLS до HTTPS-прокси требует собственного согласования. При сравнении реальных конфигураций эти этапы нужно учитывать.
Повторное использование: начальная разница распределяется между запросами
Пул соединений сохраняет подходящие подключения для следующих запросов. Повторное использование HTTPS-соединения позволяет не выполнять заново TCP-подключение, согласование с прокси и TLS-рукопожатие с сайтом для каждого запроса. Если клиент и адресат поддерживают HTTP/2, через одно установленное соединение могут идти несколько потоков запросов. Это возможно и внутри HTTP-туннеля CONNECT, и через SOCKS5: прокси не обязан разбирать сообщения HTTP/2 внутри TLS.
Если создавать новый экземпляр HTTP-клиента для каждого URL, его пул соединений может теряться. Здесь речь о повторном использовании объекта программы и его подключений, а не о закреплении выходного IP у прокси. При многократных обращениях к одним сайтам сохранение соединений может сэкономить больше времени, чем смена протокола прокси. Для новых серверов, закрытых соединений и изменённых настроек прокси всё равно могут потребоваться новые туннели.
Большие передачи: смотрим на доступную полосу
После открытия туннеля скорость скачивания зависит от маршрута, потерь пакетов, доступной полосы, нагрузки прокси и ограничений сервиса. Передача HTTPS через CONNECT уже сводится к пересылке байтов. Утверждение «SOCKS5 быстрее, потому что не читает HTTP» не учитывает этот случай.
При незашифрованном HTTP на результат могут влиять настроенное кеширование или обработка содержимого. Ответ из кеша — другая нагрузка, чем получение тех же данных с исходного сервера. Для корректного сравнения эту разницу нужно учитывать.
Как выбрать протокол для большого веб-скрипта
Веб-скрипт формирует HTTP-запросы и при использовании SOCKS5: выбор прокси меняет способ подключения к серверу. Для нового скрипта, который загружает веб-страницы или обращается к HTTPS API, начните с проверенного HTTP-клиента и HTTP CONNECT, если конкретная задача не требует другого решения. Вынесите выбор прокси в конфигурацию, чтобы проверить SOCKS5 с той же логикой запросов. Если такое сравнение важно для проекта, выбирайте библиотеку с поддержкой обоих вариантов.
| Нагрузка | С чего начать |
|---|---|
| Много коротких запросов, часто к новым хостам | Сначала попробуйте HTTP CONNECT. Более короткое согласование может помочь при частом создании туннелей. Измеряйте полностью выполненные успешные запросы. |
| Много запросов к небольшому набору API или сайтов | Используйте постоянный экземпляр клиента, пул соединений и HTTP/2 при наличии поддержки. Сравнивайте HTTP и SOCKS5 после проверки повторного использования. |
| Большие файлы или длительные TCP-сессии | Выберите хорошо поддерживаемый протокол и проверьте скорость длительной передачи и обрывы. Время подключения занимает меньшую часть задачи. |
| Другие TCP-протоколы или обязательная функция UDP | Рассмотрите SOCKS5, если программа поддерживает нужный режим. Если требуется UDP, проверьте, что программа и сервис действительно обмениваются датаграммами через прокси. |
Асинхронная программа может работать и с HTTP, и с SOCKS5. Протокол прокси не определяет, выполняются ли запросы параллельно. Проверьте, умеет ли библиотека отправлять одновременные запросы через выбранный режим прокси, сохранять пул соединений и ограничивать число выполняемых операций. Повышайте параллельность, наблюдая за результатами и ошибками: когда прокси, сеть или целевой сервер достигнут предела, новые подключения могут лишь увеличить очереди и число повторных попыток.
Как сравнить скорость перед масштабированием
- Используйте одну программу, одинаковые запросы к адресатам, размеры ответов и параллельность. По возможности сравнивайте протоколы с одним выходным IP и маршрутом; иначе подберите сопоставимые регион выхода и ограничения сервиса и зафиксируйте различия.
- Проведите одну серию с новыми соединениями и другую — с обычным пулом после прогрева. Сохраните одинаковые режимы DNS, защиту TLS, аутентификацию, версию HTTP и правила повторных попыток либо укажите, почему они отличаются.
- Измеряйте число успешно завершённых операций в секунду и время выполнения всей задачи с учётом повторных попыток. Также записывайте медиану и 95-й перцентиль времени завершения, таймауты и неудачные операции. 95-й перцентиль показывает время, в которое укладываются 95% измеренных операций.
- Для скачивания файлов записывайте количество полезных полученных байтов в секунду. Для коротких запросов отделяйте установление соединения от времени до первого байта и времени получения полного ответа. Ожидание первого байта включает и время подготовки ответа адресатом.
- Повторите чередующиеся прогоны через обе конфигурации и проверьте нужный маршрут через прокси. Если один тест использует другой пул выходных IP или переходит на прямое подключение, результат не позволяет выделить влияние протокола.
Выбирайте конфигурацию, которая быстрее выполняет реальную задачу при приемлемом уровне ошибок. Быстрый отказ в аутентификации или неполный ответ не увеличивают полезную производительность. При близких результатах предпочтительнее вариант, который проще поддерживать в выбранной программе.
Почему сначала проверяют поддержку в программе
Поле «прокси» не обещает поддержку всех протоколов и способов аутентификации. Например, встроенный режим SOCKS5 в Chrome обслуживает TCP-запросы, но не реализует SOCKS5-аутентификацию по логину и паролю и пересылку UDP. Даже если сервис SOCKS5 предоставляет эти возможности, неподдерживаемый режим браузера не начнёт ими пользоваться.
Для SSH, передачи файлов и других TCP-приложений удобна встроенная поддержка SOCKS. HTTP CONNECT тоже может передавать другие TCP-протоколы, если программа умеет создавать туннель, а прокси разрешает нужный порт назначения. Поэтому «HTTP-прокси» не всегда означает «только веб-трафик».
Настройки прокси в браузере также не распространяются автоматически на другие программы или на все функции самого браузера. У внешних адаптеров своя область действия и ограничения. Различия версий и согласование соединения разобраны в статье «SOCKS5- и SOCKS4-прокси».
Кто определяет IP целевого сервера по имени
При использовании SOCKS5 программа может получить IP адресата локально и передать его прокси либо отправить имя для разрешения на стороне прокси. В curl префикс socks5:// выбирает локальное разрешение имени адресата, а socks5h:// — разрешение через прокси. Дополнительная буква выбирает поведение клиента, а не создаёт новый протокол SOCKS.
HTTP-прокси тоже может получать IP по имени, переданному в URL или запросе CONNECT. Поэтому DNS на стороне прокси доступен с обоими протоколами. Такой поиск может вернуть адрес другого сервера и избавляет клиента от локального поиска именно этого адресата. При этом имя самого прокси всё ещё может потребоваться определить локально, а другие программы сохраняют свои настройки DNS. Выбирайте нужное поведение в программе, а не по одному названию протокола.
Какое соединение зашифровано?
Разделяйте защиту содержимого сайта и защиту подключения к прокси. При работе с HTTPS-сайтом данные приложения обычно остаются зашифрованными между клиентом и сайтом через оба вида туннелей. Это предполагает обычную проверку сертификатов и отсутствие настроенного перехвата TLS.
HTTPS-прокси добавляет TLS между клиентом и прокси. На этом участке защищаются запрос к прокси и реквизиты доступа. В адресе прокси префикс https:// обычно обозначает именно такое защищённое подключение. Настройка с названием «прокси для HTTPS-сайтов» может означать обычный HTTP-прокси с поддержкой CONNECT.
Реквизиты HTTP Basic, отправленные обычному HTTP-прокси, и стандартный обмен логином и паролем SOCKS5 доступны тому, кто может наблюдать этот незащищённый сетевой участок. Последующее TLS-соединение с сайтом не защищает уже переданную аутентификацию прокси. Если такая защита требуется, обычному SOCKS5 нужен отдельный защищённый транспорт.
Прокси остаётся участником собственного TLS-соединения и знает, куда его просят подключиться. Если конечный адресат использует обычный HTTP, TLS до прокси не шифрует дальнейшее HTTP-соединение. Пересылка через SOCKS тоже не скрывает открытый текст лишь потому, что прокси не обязан его разбирать.
Меняют ли UDP и HTTP/3 выбор протокола?
Для программы, которой действительно нужен UDP, SOCKS5 предусматривает UDP ASSOCIATE. Клиент и сервис должны его реализовать, а сетевой маршрут — пропускать датаграммы. Обычный HTTP CONNECT создаёт TCP-туннель. Передача UDP через HTTP возможна с дополнительными механизмами, например CONNECT-UDP, но их должны реализовать обе стороны.
HTTP/3 использует QUIC поверх UDP. Успешная загрузка HTTPS-страницы через прокси не доказывает работу HTTP/3: клиент мог выбрать HTTP/2 или HTTP/1.1 поверх TCP. Для веб-скрипта такой запасной вариант может подходить, но он не заменит UDP для функции, которой нужны датаграммы. Пути передачи и их ограничения разобраны в статье «UDP и QUIC через прокси».
Лучше ли SOCKS скрывает клиента?
При пересылке незашифрованного HTTP прокси может добавить заголовок, например Forwarded, со сведениями об исходном клиенте. Обычный HTTPS-туннель CONNECT не может вставить такой заголовок в зашифрованный запрос без завершения TLS-соединения сайта на посреднике. SOCKS5 также не добавляет HTTP-заголовки автоматически.
Это не превращает ни один протокол в гарантию анонимности или доступа к сайту. Оператор прокси может наблюдать метаданные соединений, а адресат — узнавать аккаунт, cookies или поведение программы. Репутация выходного IP и число его пользователей являются отдельными факторами. Переход с HTTP на SOCKS в одном сервисе не снимает блокировки автоматически и не сбрасывает сессию на сайте.
Как сделать окончательный выбор
Начните с протоколов и способов доступа, которые поддерживает программа. Для обычной веб-автоматизации HTTP CONNECT — разумный первый вариант; для приложения, рассчитанного на SOCKS или поддерживаемый режим UDP, лучше может подойти SOCKS5. Затем выберите нужное поведение DNS и защиту соединения с прокси и сравните скорость на своей нагрузке.
Используйте реальные имя хоста и порт сервиса для выбранного протокола. Замена http:// на socks5:// в конфигурации не включит SOCKS на сервере, который его не предоставляет. Перед масштабированием убедитесь, что запросы выходят через нужный прокси, а его отказ не вызывает нежелательный незаметный переход на прямой маршрут.