Déconnexion HAProxy + WebSocket
J'utilise HAProxy pour envoyer des requêtes, sur un sous-domaine, à un noeud.js app.
Je ne suis pas en mesure de faire fonctionner WebSockets. Jusqu'à présent, je n'ai pu obtenir du client qu'une connexion WebSocket, mais il y a une déconnexion qui suit très peu de temps après.
je suis sur ubuntu. J'ai été en utilisant différentes versions de socket.io
et node-websocket-server
. Le client est soit la dernière version de Safari ou Chrome. La version HAProxy est 1.4.8
Voici mon 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
j'ai parcouru le web et la liste de diffusion, mais je n'arrive pas à trouver les solutions suggérées.
(p. S. cela pourrait être pour serverfault, mais il ya d'autres questions HAProxy sur S. O, donc j'ai choisi de poster ici)
4 réponses
mise à niveau vers la dernière version de socket.io (0.6.8 ->npm install socket.io@0.6.8
, qui est corrigé pour fonctionner avec HAProxy)
et téléchargez la dernière version de HAProxy.
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
il est probable que votre client utilise WebSockets version 76. Dans ce cas, vous ne pouvez pas utiliser "Mode http" parce que la poignée de main WebSockets viole HTTP. Il semble y avoir une ambivalence au sein du Comité quant à savoir si la poignée de main WebSockets devrait être compatible avec HTTP ou non. Quoi qu'il en soit, le problème avec la poignée de main v76 est que les données brutes sont envoyées avec la poignée de main (checksum chunk).
la discussion Ha'proxy pertinente: http://www.mail-archive.com/haproxy@formilux.org/msg03046.html
D'après la discussion, il semble qu'il y ait un moyen de passer par défaut au mode TCP et de revenir à HTTP pour les connexions non-WebSockets.
nous utilisons une implémentation de Nettyhttps://github.com/ibdknox/socket.io-netty et voici le fichier HAProxy qui a fonctionné pour nous. Le truc pour qu'il ne retombe pas sur XHR-Polling mais utilise des Websockets est de mettre HAProxy en mode TCP. HAProxy config:
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
où 1.1.1.1 est votre IPs
essayez D'utiliser Socket.io au lieu de node-websockets-server, c'est une couche d'abstraction avec des retombées sur de nombreuses méthodes différentes de communication instantanée entre navigateur et serveur.
alors que C'est vrai que les WebSockets violent HTTP 1.0, ils ne violent pas HTTP 1.1, donc vous devriez pouvoir les proxy avec n'importe quel serveur capable de proxy HTTP 1.1