with the websockets and persistent TCP connections how are load balancers going to cope with the 64k port limit if they are handling a large farm of servers in the backend? need. someideas on setting up the infra for an app that can. potentially have 100k connections.
Your question appears to assume a SNAT (aka NAPT) translating load balancer. Here's some ideas about solving the 64k ephemeral ports problem. My experience is with F5 Networks' BIG-IP product (so the links are to their site), but the concepts are the same for other vendors:
More advanced approaches:
I should point out that Websockets are a special challenge for traditional HTTP load balancers, as the connections live much longer - people do run into the ephemeral ports problem when they may never have before. In my view, the best solution is one that removes the SNAT requirement (first or third solutions above). Scaling is much improved, and the load on the load-balancer is reduced. The added complexity is worth it.
Here is a good article on the issue, from F5's Lori MacVittie: HTML5 Web Sockets Changes the Scalability Game
Keep in mind that a socket is a tuple of sec/dst address, src/dst ports and protocol and, as such, the number of permutations is a lot more than 64k. There are some situations where outbound connections on proxy servers might have issues based on particular implementations but port numbering hasn't been a big issue traditionally.
I know this question is old but I have some things to add in case someone else googles "WebSockets Load Balancer"...
WebSockets don't need load balancers. There, I said it. The reason is that browsers don't make outbound WebSocket connections until after the page has loaded.
Scaling up WebSocket applications is trivial... Just add more servers. Whenever you do that just add them to your outbound connection list. They can be located anywhere in the world--even at different domains/origins!