I confirm, based on our own tests, that configuring ELB on TCP/SSL, instead oh HTTP/HTTPS, makes the trick with WebSockets. The drawbacks are two:
1) As already pointed by arturnt, you cannot get stickyness.
2) You will lose the ability to retrieve the identity of the clients. The originating IP seen by your WebSocket server will be always the ELB one and, differently from the HTTP/HTTPS configuration, no X-Forwarded-For header will be added to the requests.
UPDATE July 2013: Amazon has just added support for Proxy Protocol, which solves drawback number 2 above. With the Proxy Protocol, a header containing the client's originating IP is added even when ELB works at TCP level, rather than HTTP. Full details: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html
UPDATE August 2016: Amazon has just announced new AWS Application Load Balancer, which supports WebSocket at Layer 7 (as well as HTTP/2.0 and content-based routing). See https://aws.amazon.com/it/blogs/aws/new-aws-application-load-balancer/
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…