Desconexión de HAProxy + WebSocket

Estoy usando HAProxy para enviar solicitudes, en un subdominio, a una aplicación node.js.

No puedo hacer que WebSockets funcione. Hasta ahora solo he podido lograr que el cliente establezca una conexión WebSocket, pero luego hay una desconexión que sigue muy poco después.

Estoy en Ubuntu. He estado usando varias versiones de socket.io y node-websocket-server . El cliente es las últimas versiones de Safari o Chrome. La versión HAProxy es 1.4.8

Aquí está mi HAProxy.cfg

 global maxconn 4096 pidfile /var/run/haproxy.pid daemon defaults mode http maxconn 2000 option http-server-close option http-pretend-keepalive contimeout 5000 clitimeout 50000 srvtimeout 50000 frontend HTTP_PROXY bind *:80 timeout client 86400000 #default server default_backend NGINX_SERVERS #node server acl host_node_sockettest hdr_beg(host) -i mysubdomain.mydomain use_backend NODE_SOCKETTEST_SERVERS if host_node_sockettest backend NGINX_SERVERS server THIS_NGINX_SERVER 127.0.0.1:8081 backend NODE_SOCKETTEST_SERVERS timeout queue 5000 timeout server 86400000 server THIS_NODE_SERVER localhost:8180 maxconn 200 check 

He rastreado la web y la lista de correo pero no puedo conseguir que funcionen las soluciones sugeridas.

(ps esto podría ser para serverfault, pero hay otra pregunta de HAProxy en SO, así que he elegido publicar aquí)

Actualice a la última versión de socket.io (0.6.8 -> npm install socket.io@0.6.8 , que está parcheado para trabajar con HAProxy) y descargue la última versión de HAProxy.

Aquí hay un archivo de configuración de ejemplo:

 global maxconn 4096 # Total Max Connections. This is dependent on ulimit nbproc 2 defaults mode http frontend all 0.0.0.0:80 timeout client 5000 default_backend www_backend acl is_websocket hdr(Upgrade) -i WebSocket acl is_websocket hdr_beg(Host) -i ws use_backend socket_backend if is_websocket backend www_backend balance roundrobin option forwardfor # This sets X-Forwarded-For timeout server 5000 timeout connect 4000 server server1 localhost:8081 weight 1 maxconn 1024 check server server2 localhost:8082 weight 1 maxconn 1024 check server server3 localhost:8083 weight 1 maxconn 1024 check backend socket_backend balance roundrobin option forwardfor # This sets X-Forwarded-For timeout queue 5000 timeout server 5000 timeout connect 5000 server server1 localhost:8081 weight 1 maxconn 1024 check server server2 localhost:8082 weight 1 maxconn 1024 check server server3 localhost:8083 weight 1 maxconn 1024 check 

Es probable que su cliente esté usando la versión 76 de WebSockets. En ese caso, no puede usar “modo http” porque el intercambio de información de WebSockets infringe HTTP. Parece que hay una ambivalencia en el comité sobre si el protocolo de enlace WebSockets debe ser compatible con HTTP o no. De todos modos, el problema con el apretón de manos v76 es que los datos brutos se envían con el apretón de manos (el fragmento de sum de comprobación).

La discusión relevante de HAProxy: http://www.mail-archive.com/haproxy@formilux.org/msg03046.html

A partir de la discusión, parece que podría haber una forma de pasar por defecto al modo TCP y recurrir a HTTP para conexiones que no sean WebSockets.

Estamos utilizando una implementación de Netty https://github.com/ibdknox/socket.io-netty y aquí está el archivo HAProxy que funcionó para nosotros. El truco para conseguir que no vuelva a recurrir a XHR-Polling, sino que utilice Websockets, es poner HAProxy en modo TCP. Configuración HAProxy:

 global daemon maxconn 32000 defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms listen http-in bind *:80 server server1 1.1.1.1:8000 check server server2 1.1.1.1:8000 check listen socketio-in mode tcp bind *:8080 balance source timeout queue 5000 timeout server 86400000 timeout connect 86400000 server server1 1.1.1.1:8080 check server server2 1.1.1.1:8080 check 

Donde 1.1.1.1 es su IP

Intenta usar Socket.io en lugar de node-websockets-server, es una capa de abstracción con errores en muchos métodos diferentes de comunicación instantánea entre el navegador y el servidor.

Si bien es cierto que los WebSockets infringen HTTP 1.0, no infringen HTTP 1.1, por lo que debería poder utilizarlos como proxy con cualquier servidor capaz de utilizar HTTP 1.1

Intereting Posts