![websockets、负载均衡器和 64k 端口](https://linux22.com/image/588858/websockets%E3%80%81%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%99%A8%E5%92%8C%2064k%20%E7%AB%AF%E5%8F%A3.png)
使用 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 之类的东西已经过时了。