websockets test socket nodejs ejemplo websocket

test - ¿Por qué las implementaciones actuales de cliente websocket no son compatibles con los proxies?



websocket test (6)

Un Web Socket detecta la presencia de un servidor proxy y configura automáticamente un túnel para pasar a través del proxy. El túnel se establece emitiendo una declaración HTTP CONNECT al servidor proxy, que solicita al servidor proxy que abra una conexión TCP / IP a un host y puerto específicos. Una vez que se configura el túnel, la comunicación puede fluir sin impedimentos a través del proxy. Dado que HTTP / S funciona de manera similar, los Web Sockets sobre SSL seguros pueden aprovechar la misma técnica HTTP CONNECT. [1]

OK, suena útil! Pero, en las implementaciones de clientes que he visto hasta ahora (Go [2], Java [3]) no veo nada relacionado con la detección de proxy.

¿Me estoy perdiendo algo o estas implementaciones son jóvenes? Sé que WebSockets es extremadamente nuevo y las implementaciones de los clientes pueden ser igualmente jóvenes e inmaduras. Solo quiero saber si me falta algo sobre la detección y el manejo de proxy.

[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

Con respecto a los clientes websocket y los proxies transparentes, creo que las conexiones de clientes websocket fallarán la mayoría del tiempo por las siguientes razones (no probadas):

  • Si la conexión es clara, dado que el cliente no sabe que se está comunicando con un servidor proxy http, no enviará la instrucción "CONECTAR A" que convierte al proxy http en un proxy TCP (necesario para el cliente después del websocket). apretón de manos). Podría funcionar si el proxy admite websocket de forma nativa y maneja la URL con el esquema ws de manera diferente a http.

  • Si la conexión está en SSL, el proxy transparente no puede saber a qué servidor debe conectarse ya que ha descifrado el nombre de host en la solicitud https. Puede generar un certificado autofirmado sobre la marcha (como para SSLStrip) o proporcionar su propio certificado estático y descifrar la comunicación, pero si el cliente valida el certificado del servidor, fallará (consulte https://serverfault.com/questions/369829/setting-up-a-transparent-ssl-proxy ).

El canal de comunicación ya está establecido en el momento en que el protocolo WebSocket entra en escena. El WebSocket está construido sobre TCP y HTTP, por lo que no tiene que preocuparse por lo que ya hacen estos protocolos, incluidos los proxies.

Cuando se establece una conexión WebSocket, siempre comienza con una conexión HTTP / TCP que luego se "actualiza" durante la fase de "handshake" de WebSocket. En este momento, el túnel está establecido para que los proxies sean transparentes, no hay necesidad de preocuparse por ellos.

La respuesta es que estos clientes simplemente no admiten proxies. -Occam

Permítame tratar de explicar las diferentes tasas de éxito que puede haber encontrado. Si bien el protocolo HTML5 Web Socket en sí mismo desconoce los servidores proxy y los firewalls, presenta un protocolo de enlace compatible con HTTP para que los servidores HTTP puedan compartir sus puertos HTTP y HTTPS predeterminados (80 y 443) con una puerta de enlace o un servidor Web Sockets.

El protocolo Web Socket define un prefijo ws: // y wss: // para indicar un WebSocket y una conexión WebSocket Secure, respectivamente. Ambos esquemas utilizan un mecanismo de actualización HTTP para actualizar al protocolo Web Socket. Algunos servidores proxy son inofensivos y funcionan bien con Web Sockets; otros evitarán que Web Sockets funcione correctamente y que la conexión falle. En algunos casos, es posible que se requiera una configuración adicional del servidor proxy y que ciertos servidores proxy deban actualizarse para admitir Web Sockets.

Si el tráfico WebSocket no cifrado fluye a través de un servidor proxy transparente o explícito en su camino hacia el servidor WebSocket, entonces, independientemente de que el servidor proxy se comporte como debería, es casi seguro que la conexión falle hoy (en el futuro, los servidores proxy pueden volverse consciente de Web Socket). Por lo tanto, las conexiones WebSocket sin cifrar se deben usar solo en las topologías más simples.

Si se usa una conexión WebSocket cifrada, entonces el uso de Seguridad de la capa de transporte (TLS) en la conexión segura de Web Sockets garantiza que se emita un comando HTTP CONNECT cuando el navegador está configurado para usar un servidor proxy explícito. Esto configura un túnel, que proporciona comunicación TCP de extremo a extremo de bajo nivel a través del proxy HTTP, entre el cliente seguro de Web Sockets y el servidor WebSocket. En el caso de servidores proxy transparentes, el navegador desconoce el servidor proxy, por lo que no se envía HTTP CONNECT. Sin embargo, dado que el tráfico por cable está encriptado, los servidores proxy transparentes intermedios pueden permitir simplemente el tráfico encriptado, por lo que existe una posibilidad mucho mayor de que la conexión WebSocket tenga éxito si se usa Web Sockets Secure. El uso del cifrado, por supuesto, no es gratuito, pero a menudo proporciona la mayor tasa de éxito.

Una forma de verlo en acción es descargar e instalar Kaazing WebSocket Gateway, una puerta de enlace WebSocket altamente optimizada y sensible al proxy, que brinda soporte nativo de WebSocket así como una emulación completa del estándar para navegadores más antiguos.