Почему текущие реализации клиента websocket не поддерживают прокси?

Question

Веб-сокет обнаруживает присутствие прокси-сервера и автоматически настраивает туннель для прохождения через прокси. Туннель устанавливается путем выдачи инструкции HTTP CONNECT на прокси-сервер, который запрашивает у прокси-сервера открытие соединения TCP / IP с определенным хостом и портом. После настройки туннеля связь может проходить беспрепятственно через прокси. Поскольку HTTP / S работает аналогичным образом, безопасные веб-сокеты через SSL могут использовать ту же технику HTTP CONNECT. [1]

ОК, звучит полезно! Но в клиентских реализациях, которые я видел до сих пор (Go [2], Java [3]), я не вижу ничего, связанного с обнаружением прокси.

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

[1] http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

[2] http://golang.org/src/pkg/websocket/client.go

[3] http://github.com/adamac/Java-WebSocket-client/raw/master/src/com/sixfire/websocket/WebSocket.java

Answer 1

Позвольте мне попытаться объяснить различные показатели успеха, с которыми вы могли столкнуться. Хотя сам протокол HTML5 Web Socket не знает о прокси-серверах и брандмауэрах, он поддерживает HTTP-совместимое рукопожатие, поэтому HTTP-серверы могут совместно использовать свои порты HTTP и HTTPS по умолчанию (80 и 443) со шлюзом или сервером Web Sockets.

Протокол Web Socket определяет префикс ws: // и wss: // для обозначения соединения WebSocket и WebSocket Secure, соответственно. Обе схемы используют механизм обновления HTTP для обновления до протокола Web Socket. Некоторые прокси-серверы безвредны и прекрасно работают с веб-сокетами; другие будут препятствовать правильной работе веб-сокетов, вызывая сбой соединения. В некоторых случаях может потребоваться дополнительная настройка прокси-сервера, а некоторые прокси-серверы могут нуждаться в обновлении для поддержки веб-сокетов.

Если незашифрованный трафик WebSocket проходит через явный или прозрачный прокси-сервер на своем пути к серверу WebSocket, то, независимо от того, ведет ли себя прокси-сервер так, как должен, соединение почти наверняка оборвется сегодня (в будущем, прокси-серверы могут стать осведомленными о веб-сокете). Поэтому незашифрованные соединения WebSocket следует использовать только в самых простых топологиях.

Если используется зашифрованное соединение WebSocket, то использование Transport Layer Security (TLS) в соединении Web Sockets Secure гарантирует, что команда HTTP CONNECT будет выполнена, когда браузер настроен на использование явного прокси-сервера. Это устанавливает туннель, который обеспечивает низкоуровневую сквозную связь TCP через прокси-сервер HTTP, между клиентом Web Sockets Secure и сервером WebSocket. В случае прозрачных прокси-серверов браузер не знает о прокси-сервере, поэтому HTTP CONNECT не отправляется. Однако, поскольку трафик в зашифрованном виде зашифрован, промежуточные прозрачные прокси-серверы могут просто пропустить зашифрованный трафик, так что гораздо больше шансов, что соединение WebSocket будет успешным, если используется Web Sockets Secure. Использование шифрования, конечно, не бесплатно, но часто обеспечивает самый высокий уровень успеха.

Одним из способов увидеть его в действии является загрузка и установка Kaazing WebSocket Gateway - высокооптимизированного шлюза WebSocket с поддержкой прокси, который обеспечивает встроенную поддержку WebSocket, а также полную эмуляцию стандарта для старых браузеров.

Answer 2

Ответ заключается в том, что эти клиенты просто не поддерживают прокси. -Occam

Answer 3

Канал связи уже установлен к тому времени, когда протокол WebSocket выходит на сцену. WebSocket построен поверх TCP и HTTP, поэтому вам не нужно заботиться о том, что уже сделано этими протоколами, включая прокси.

Когда соединение WebSocket установлено, оно всегда начинается с соединения HTTP / TCP, которое позже «обновляется» на этапе «рукопожатия» WebSocket. В это время туннель установлен, так что прокси прозрачны, о них не нужно заботиться.

Answer 4

websocket-client, пакет Python, поддерживает прокси, по крайней мере по безопасной схеме wss://, так как в этом случае прокси не нужно знать о трафике, который он передает.

https://github.com/liris/websocket-client/commit/9f4cdb9ec982bfedb9270e883adab2e028bbd8e9

Answer 5

Вы упомянули прокси-серверы Java, и в ответ на это я хотел упомянуть, что Java-Websocket теперь поддерживает прокси-серверы.

Информацию об этом можно посмотреть здесь: http://github.com/TooTallNate/Java-WebSocket/issues/88

Answer 6

Что касается клиентов веб-сокетов и прозрачных прокси, Я думаю, что соединения клиента websocket в большинстве случаев не будут работать по следующим причинам (не проверено):

• Если соединение ясно, так как клиент не знает, что он обменивается данными с прокси-сервером http, он не отправит инструкцию «CONNECT TO», которая превращает прокси http в прокси tcp (необходимо). для клиента после рукопожатия websocket). Это может работать, если прокси-сервер изначально поддерживает websocket и обрабатывает URL-адрес по схеме ws иначе, чем http.

• Если соединение в SSL, прозрачный прокси не может знать, к какому серверу он должен подключиться, поскольку он расшифровал имя хоста в запросе https. Это может быть либо путем создания самоподписанного сертификата на лету (например, для SSLStrip), либо путем предоставления собственного статического сертификата и расшифровки соединения, но если клиент проверяет сертификат сервера, произойдет сбой (см. https://serverfault.com/questions/369829/setting-up-a-transparent-ssl-proxy).