Почему текущие реализации клиентов 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+55websocket

[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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

• Если подключение находится в ясном виде, поскольку клиент не знает, что он общается с HTTP -прокси -сервером, оно не будет отправлять инструкцию «Подключить», которая превращает прокси HTTP в прокси -сервер TCP (необходимо для клиента после WebSocketocket рукопожатие). Это может сработать, если прокси -сервер поддерживает национальный WebSocket и обрабатывает URL с схемой WS иначе, чем HTTP.

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

Answer 5

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

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

Answer 6

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

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