Hi Chris, Please read the article below: http://blog.exceliance.fr/2012/11/07/websockets-load-balancing-with-haproxy/
You may find answers ;) cheers On Wed, Feb 27, 2013 at 4:35 PM, Chris Yang <[email protected]> wrote: > > Hello again, > > Regarding the second problem (failure to establishing websocket connections > in supported browsers), I can confirm that it happens on both Chrome and > Firefox. And below is what I see for the '101 Switching Protocols' request > in Firefox when it happened: > >> Request URL: https://www.myexample.com/sockjs/673/nw56jyoj/websocket >> Request Method: GET >> Status Code: HTTP/1.1 101 Switching Protocols >> Request Headers >> User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 >> Firefox/18.0 >> Upgrade:websocket >> Sec-WebSocket-Version:13 >> Sec-WebSocket-Key:Fg8Z/EASgn6AlVh0hMYLtw== >> Pragma:no-cache >> Origin:https://www.playmymodel.com >> Host:www.playmymodel.com >> Connection:keep-alive, Upgrade >> Cache-Control:no-cache >> Accept-Language:en-US,en;q=0.5 >> Accept-Encoding:gzip, deflate >> Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> Response Headers >> Upgrade:websocket >> Sec-WebSocket-Accept:NxU0HFQKbhwr7VBCHf23qLXH/Ic= >> Connection:Upgrade > > > and below is what follows from the SockJS side: > >> Closed transport: websocket SimpleEvent(type=close, code=2007, >> reason=Transport timeouted, wasClean=false) > > > This failure of establishing websocket connection happen relatively often > now, with 4 - 5 Chrome processes running on my laptop, I can almost always > get at least 1 Chrome which encounters this. In addition, I have also tested > this with HAProxy 1.5-dev15, and the problem persists. For completeness, I > attach the updated config as below: > >> global >> log 127.0.0.1 local1 info >> log 127.0.0.1 local1 notice >> #log loghost local0 info >> maxconn 4096 >> chroot /usr/share/haproxy >> uid 99 >> gid 99 >> daemon >> #debug >> #quiet >> >> defaults >> log global >> mode http >> option httplog >> option dontlognull >> retries 3 >> option redispatch >> maxconn 500 >> timeout connect 6s >> timeout client 600s >> timeout server 600s >> timeout tunnel 1200s >> >> frontend public >> mode http >> bind 0.0.0.0:80 >> bind 0.0.0.0:443 ssl crt /etc/haproxy/ssl_wc/mysite.pem ciphers >> HIGH:!aNULL:!MD5 no-tlsv10 >> timeout client 300s >> option http-server-close >> option forwardfor except 127.0.0.1 >> reqadd X-Forwarded-Proto:\ https if { ssl_fc } >> reqadd X-Forwarded-Proto:\ http if !{ ssl_fc } >> # define ACLs below >> acl is_https ssl_fc >> redirect scheme https if !is_https >> # and other ACLs and rules (omitted here) >> >> backend sockjs_1 >> #timeout server 60s >> server sock1 127.0.0.1:8000 >> >> backend sockjs_2 >> #timeout server 60s >> server sock2 127.0.0.1:8060 >> >> backend nginx >> #timeout server 20s >> server nginx 127.0.0.1:8484 >> >> backend stats >> stats enable >> stats uri /haproxy/stats >> stats realm Haproxy\ Statistics >> >> backend www >> #timeout server 300s >> #option forwardfor header X-Client-IP >> #no option httpclose >> #option http-server-close >> server content 127.0.0.1:8080 > > > Again, backends sockjs_1 and sockjs_2 are what is being affected here. > > Could anyone comment on what may cause this undesirable websocket failures > here? Thanks a lot! > > > > Best, > Chris > > On Fri, Feb 22, 2013 at 8:40 AM, Chris Yang <[email protected]> wrote: >> >> >> Hello, >> >> I upgraded to dev17 from dev15. I am running Tornado servers behind >> HAProxy with SockJS support. Comparing to before the upgrade, I've noticed >> two problematic behaviors: >> >> 1. When a client is using IE with xhr-streaming protocol to connect to >> servers, such connections are closed (seeing 'Connection get reset by peer' >> error on the Python side) more often than before. Sometimes disconnection >> happened soon after connection (half a minute). I guess it might be related >> to timeout, but since I haven't changed any configuration on HAProxy, I >> wonder if this behavior is related to the upgrade of HAProxy itself. >> >> 2. From time to time, Chrome failed to finish the websocket handshake with >> the server, and instead used xhr-streaming. This didn't happen before the >> upgrade, but I've noticed at least 5+ such cases during the testing with >> dev17. >> >> I can confirm that both client-side library (sockjs-client) and >> server-side library (sockjs-tornado) have stayed the same since their last >> respective upgrade (months before dev17 came out). So the only variable >> which might have produced the observations above could be HAProxy. >> >> I attach below my HAProxy config (excluding most of the acls), and I'd >> much appreciate that if someone could take a quick look and let me know if >> some setting(s) may not play well with dev17 which might have caused the >> behavior above, or some new setting(s) should be added. Notice that backends >> sockjs_1 and sockjs_2 are the ones experiencing the problems. >> >> global >> log 127.0.0.1 local1 info >> log 127.0.0.1 local1 notice >> #log loghost local0 info >> maxconn 4096 >> chroot /usr/share/haproxy >> uid 99 >> gid 99 >> daemon >> #debug >> #quiet >> >> defaults >> log global >> mode http >> option httplog >> option dontlognull >> retries 3 >> option redispatch >> maxconn 500 >> timeout connect 6s >> >> frontend public >> mode http >> bind 0.0.0.0:80 >> bind 0.0.0.0:443 ssl crt /etc/haproxy/ssl_wc/mysite.pem ciphers >> HIGH:!aNULL:!MD5 no-tlsv10 >> timeout client 300s >> option http-server-close >> option forwardfor except 127.0.0.1 >> reqadd X-Forwarded-Proto:\ https if { ssl_fc } >> reqadd X-Forwarded-Proto:\ http if !{ ssl_fc } >> #option http-pretend-keepalive >> # define ACLs and use them below >> acl is_https ssl_fc >> redirect scheme https if !is_https >> # other acls omitted here >> >> backend sockjs_1 >> timeout server 60s >> server sock_1 127.0.0.1:8000 >> >> backend sockjs_2 >> timeout server 60s >> server sock_2 127.0.0.1:8060 >> >> backend nginx >> timeout server 20s >> server nginx 127.0.0.1:8484 >> >> backend stats >> stats enable >> stats uri /haproxy/stats >> stats realm Haproxy\ Statistics >> >> backend www >> timeout server 300s >> #option forwardfor header X-Client-IP >> #no option httpclose >> #option http-server-close >> server content 127.0.0.1:8080 >> >> Thanks very much! >> >> >> >> Best, >> Chris > >
