使用 websockets 和持久 TCP 连接，如果负载均衡器在后端处理大量服务器，它们将如何应对 64k 端口限制？需要。一些关于为可能有 100k 个连接的应用程序设置基础设施的想法。
答案1
您的问题似乎假设 SNAT（又称 NAPT）转换负载平衡器。以下是一些解决 64k 临时端口问题的想法。我的经验是使用 F5 Networks 的 BIG-IP 产品（因此链接指向他们的网站），但其他供应商的概念是相同的：
不要使用 SNAT。如果源端口未转换，则不会有 64k 的限制。要关闭 SNAT，您需要将负载平衡器的内部地址设置为内部服务器上的路由（通常是默认路由）。
使用 SNAT 池。这将为负载均衡器提供一组内部 IP 地址以供转换。例如，SNAT 池中的两个 IP 地址将为您提供 128k 个临时端口，因此可同时提供 128k 个 TCP 连接。
更高级的方法：
- 使用“n 路径路由”（这是 F5 的术语，其他人可能称之为“直接服务器返回”）。这不会转换客户端地址或者端口（或目标 IP，就此而言！），因此也使临时端口问题消失。来自服务器的响应绕过负载平衡器。实现此目的的方法是使用环回适配器在所有服务器上托管相同的 IP，以便它们接受流量。
我应该指出，Websockets 对传统 HTTP 负载均衡器来说是一个特殊的挑战，因为连接持续时间更长——人们确实会遇到以前从未遇到过的临时端口问题。在我看来，最好的解决方案是消除 SNAT 要求（上面的第一个或第三个解决方案）。扩展性大大提高，负载均衡器的负载也减少了。增加的复杂性是值得的。
以下是 F5 的 Lori MacVittie 就此问题撰写的一篇好文章：HTML5 Web Sockets 改变了可扩展性游戏
答案2
请记住，套接字是 sec/dst 地址、src/dst 端口和协议的三元组，因此排列数远大于 64k。在某些情况下，代理服务器上的出站连接可能会根据特定实现出现问题，但端口编号传统上并不是一个大问题。
答案3
答案4
我知道这个问题已经很老了，但我有一些内容需要补充，以防其他人在谷歌上搜索“WebSockets 负载均衡器”...
WebSocket 不需要负载均衡器。我说的没错。原因是浏览器直到后页面已加载。
因此，如果页面已加载完毕，并且您有权执行 JavaScript，那么为什么此时还需要负载平衡器呢？您不需要。您可以做一些简单的事情，例如从数组中随机选择一个 ws:// 或 wss:// 连接，或者您可以发挥想象力，进行 AJAX 调用，返回要连接的特定 WebSocket 服务器。您甚至可以通过模板将 WebSocket URL 从服务器端代码放入页面中。
扩展 WebSocket 应用程序很简单...只需添加更多服务器。无论何时执行此操作，只需将它们添加到出站连接列表中即可。它们可以位于世界任何地方 - 甚至位于不同的域/来源！
WebSockets 也没有常规 HTTP(S) URL 的跨源限制。从以下地址建立到 wss://foo.com 的连接：http://bar.com。它会正常工作！几乎所有与扩展 Web 应用程序相关的传统问题都已通过 WebSocket 解决。一旦建立连接，您甚至可以通过 WebSocket 提供 CSS、图像、JavaScript 和其他任何内容（现在也可以在浏览器中本地缓存这些文件！）。降级负载平衡器和 CDN 之类的东西已经过时了。