负载均衡器如何绕过 64k 端口限制?

负载均衡器如何绕过 64k 端口限制?

当请求到达时,它会被重新路由到多个可用服务器之一。但只有 64k 个端口可用,因此在任何给定时间最多只能有 64k 个传出请求。那么一些网站如何能够处理数百万个并发请求呢?如果有人能消除这种困惑,那就太好了。谢谢!

答案1

已经链接高流量站点如何服务超过 65535 个 TCP 连接? Stack Overflow 上的其他问题解释了 5 元组,以及这个(略小于)64K 的限制是如何实现的每个 IP- 每个临时端口都有一个连接。这仍然适用于“负载平衡器”工作负载,它也是该端的 IP 软件堆栈。

假设您在 IP 203.0.113.80 端口 443 上运行一项服务。不知何故,172.16.0.0/12 中的 100 万个 IP 中的每一个都单独访问它。64K 端口无关紧要,因为它们已经按 IP 地址唯一。172.16.0.1 客户端可以建立 64K 个连接,172.16.0.2 客户端也可以。因为这些流程不同:

Proto Source IP port Target IP  port
TCP 203.0.113.80 443 172.16.0.1 44321
TCP 203.0.113.80 443 172.16.0.2 44321

实际上,后端服务和代理连接的设备需要进行调整和扩展才能达到一百万。你需要很多主机您可以调整它们的 TCP 堆栈以达到那么高的值。

通常,只有在使用负载测试实用程序时,同一 IP 在同一端口上才会发生数万个连接。大多数单个 IP 的工作量不足以设置数千个并发连接。

答案2

这取决于所涉及的第 4 层协议。

对于 UDP 和其他无连接传输协议(UDP-Lite、RUDP、DCCP 和其他一些协议),这无关紧要。因为没有连接,所以您不必担心套接字与特定远程主机持续关联,因此不必担心端口号是 16 位整数。您只需将消息发送到目标后端,并跟踪事情的进展情况。但是,根据负载平衡软件及其配置方式,对后端服务器的未完成请求的功能限制可能是 65536 个。

对于 SCTP 和其他本质上多路复用的面向连接的传输协议(例如 TIPC,尽管几乎没有人使用它),这实际上也无关紧要。您只需从负载均衡器到每个后端服务器建立一个连接,然后通过该连接多路复用您需要的任意数量的流,因为传输协议支持这样做。实际上,某些应用层协议也可以执行相同的操作,例如 HTTP/2(但不是 HTTP 1.1 或更早版本)或 SSH 协议。

对于 TCP 和其他单流连接导向传输协议,情况会变得有些棘手。有些配置会通过一定数量的持久连接多路复用请求(通过保持连接持久,可以节省时间,因为设置 TCP 连接非常慢),而其他配置则使用应用程序层的专有扩展通过单个连接多路复用事物。

对于上述任何一种情况,还可以选择使用多个后端网络,无论是通过多个物理网络、通过 VLAN 还是通过其他网络多路复用技术。这种方法在后端服务器是虚拟机时最常见,但在其他情况下也仍然被广泛使用。通过为每个后端系统设置一个单独的子网,您的 64k 端口限制将从每个前端变为每个后端(也就是说,您的负载平衡器不再只允许所有后端服务器有 64k 个活动连接,而是可以处理 64k 到每个后端服务器(英语:back-end server),将瓶颈归结为后端的数量以及每个后端的功能有多强大。

相关内容