Когда следует использовать HTTP-методы CONNECT и GET на прокси-сервере HTTP?
-
13-12-2019 - |
Вопрос
Я создаю библиотеку WebClient.Сейчас я реализую функцию прокси, поэтому провожу небольшое исследование и увидел код, использующий CONNECT
метод запроса URL.
Но проверив это в моем веб-браузере, он не использует CONNECT
метод, но вместо этого вызывает метод GET.
Так что я в замешательстве.Когда мне следует использовать оба метода?
Решение
Запрос Connect призывает ваш прокси устанавливать HTTP-туннель к удаленной конечной точке.
CONNECT www.google.com:443
.
Вышеуказанная линия открывает соединение от вашего прокси на www.google.com на порту 443.
После этого контент, который отправляется клиентом, передается прокси-сервером для www.google.com:443
.
Если пользователь пытается получить страницу http://www.google.com , прокси может отправить точно такой же запрос и Получить ответ для него, от его имени.
с SSL (https), только два удаленных конечных точка понимают запросы, а прокси не может расшифровать их. Следовательно, все, что он делает, открыт этот туннель, используя Connect, и позволяет двум конечным точкам (веб-серверу и клиенту) напрямую разговаривать друг с другом.
Если вы будете цепочками 2 прокси-серверов, это последовательность запросов, которые будут выпущены.
GET1 is the original GET request (HTTP URL)
CONNECT1 is the original CONNECT request (SSL/HTTPS URL or Another Proxy)
User Request ==CONNECT1==> (Your_Primary_Proxy ==CONNECT==> AnotherProxy-1 ... ==CONNECT==> AnotherProxy-n) ==GET1(IF is http)/CONNECT1(IF is https)==> Destination_URL
. Другие советы
ТЛ;ДР веб-клиент использует CONNECT
только тогда, когда он знает, что общается с прокси-сервером, и окончательный URI начинается с https://
.
Когда браузер говорит:
CONNECT www.google.com:443 HTTP/1.1
это значит:
Привет, прокси, пожалуйста, откройте необработанное TCP-соединение с Google;Любые следующие байты, которые я пишу, вы просто повторяете эту связь без какой -либо интерпретации.Да, и еще одна вещь.Делай это только в том случае, если вы поговорите с Google напрямую, но если вы используете другой прокси сами, вместо этого вы просто говорите им то же самое
CONNECT
.
Обратите внимание: здесь ничего не говорится о TLS (https).Фактически CONNECT
ортогонален TLS;у вас может быть только один, у вас может быть другой, или у вас могут быть оба.
При этом намерение CONNECT
это позволить сеанс TLS со сквозным шифрованием, поэтому данные нечитабельны для прокси (или всей цепочки прокси).Это работает, даже если прокси вообще не понимает TLS, потому что CONNECT
может быть выдан внутри обычного HTTP и не требует от прокси ничего, кроме копирования необработанных байтов.
Но подключение к первому прокси может быть TLS (https), хотя это означает двойное шифрование трафика между вами и первым прокси.
Очевидно, нет смысла CONNECT
при разговоре напрямую с конечным сервером.Вы просто начинаете говорить TLS, а затем запускаете HTTP GET
.Конечные серверы обычно отключаются CONNECT
вообще.
К прокси, CONNECT
поддержка добавляет риски безопасности.Любые данные могут быть переданы через CONNECT
, даже попытка взлома ssh сервера на 192.168.1.*, даже SMTP рассылает спам.Внешний мир рассматривает эти атаки как обычные TCP-соединения, инициированные прокси-сервером.Их не волнует, в чем причина, они не могут проверить, работает ли HTTP CONNECT
виноват.Следовательно, прокси-серверы должны защищать себя от злоупотреблений.
Как правило Thumb Get используется для простого http и подключения для https
Есть более подробные детали, поэтому вы, вероятно, хотите прочитать соответствующие RFC-S
http://www.ietf.org/rfc/rfc2068.txt http://www.ietf.org/rfc/rfc2817.txt