Почему текущие реализации клиента websocket не поддерживают прокси?
Веб-сокет обнаруживает присутствие прокси-сервера и автоматически настраивает туннель для прохождения через прокси. Туннель устанавливается путем выдачи инструкции HTTP CONNECT на прокси-сервер, который запрашивает у прокси-сервера открытие соединения TCP/IP с определенным хостом и портом. После настройки туннеля связь может проходить беспрепятственно через прокси. Поскольку HTTP/S работает аналогичным образом, безопасные веб-сокеты поверх SSL могут использовать ту же технику HTTP CONNECT. [1]
ОК, звучит полезно! Но в клиентских реализациях, которые я видел до сих пор (Go [2], Java [3]), я не вижу ничего, связанного с обнаружением прокси.
Я что-то упустил или эти реализации просто молоды? Я знаю, что Web Sockets является чрезвычайно новым, и реализации клиента могут быть столь же молодыми и незрелыми. Я просто хочу знать, что я что-то упускаю из-за обнаружения и обработки прокси.
[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
6 ответов
Ответ заключается в том, что эти клиенты просто не поддерживают прокси. -Occam
Позвольте мне попытаться объяснить различные показатели успеха, с которыми вы могли столкнуться. Хотя сам протокол 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, а также полную эмуляцию стандарта для старых браузеров.
Канал связи уже установлен к тому времени, когда протокол WebSocket выходит на сцену. WebSocket построен поверх TCP и HTTP, поэтому вам не нужно заботиться о том, что уже сделано этими протоколами, включая прокси.
Когда соединение WebSocket установлено, оно всегда начинается с соединения HTTP / TCP, которое позднее "обновляется" на этапе "рукопожатия" WebSocket. В это время туннель установлен, так что прокси прозрачны, о них не нужно заботиться.
Вы упомянули прокси Java, и в ответ на это я хотел упомянуть, что Java-Websocket теперь поддерживает прокси.
Вы можете увидеть информацию об этом здесь: http://github.com/TooTallNate/Java-WebSocket/issues/88
Что касается клиентов websocket и прозрачных прокси-серверов, я думаю, что подключения клиентов websocket в большинстве случаев будут прерываться по следующим причинам (не проверено):
Если соединение установлено, так как клиент не знает, что он взаимодействует с прокси-сервером http, он не отправит инструкцию "CONNECT TO", которая превращает прокси-сервер http в прокси-сервер tcp (необходимый для клиента после веб-сокета). рукопожатие). Это может работать, если прокси-сервер изначально поддерживает websocket и обрабатывает URL-адреса по схеме ws иначе, чем http.
Если соединение в SSL, прозрачный прокси не может знать, к какому серверу он должен подключиться, поскольку он расшифровал имя хоста в запросе https. Это может быть либо путем создания самозаверяющего сертификата на лету (например, для SSLStrip), либо путем предоставления собственного статического сертификата и дешифрования соединения, но если клиент проверяет сертификат сервера, произойдет сбой (см. https://serverfault.com/questions/369829/setting-up-a-transparent-ssl-proxy).
websocket-client, пакет Python, поддерживает прокси, по крайней мере, по безопасной схеме wss:// поскольку в этом случае прокси не нужно знать о трафике, который он передает.
https://github.com/liris/websocket-client/commit/9f4cdb9ec982bfedb9270e883adab2e028bbd8e9