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

Веб-Socket обнаруживает наличие прокси-сервера и автоматически настраивает туннель для прохождения через прокси-сервер. Туннель устанавливается путем выдачи оператора 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

Ответ 1

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

Что касается клиентов websocket и прозрачных прокси, Я думаю, что соединение с клиентом 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).

Ответ 5

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

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

Ответ 6

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

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