具有负载均衡器可扩展性的 websocket
我的网站使用负载均衡器。浏览器启动与我的应用程序服务器的 Websocket 连接。打开的连接是否会消耗负载均衡器上的任何资源，还是直接在浏览器和应用程序服务器之间建立？如果LB上有一些开放的东西，那不是瓶颈吗？我的意思是，如果我的 LB 可以处理 X 个打开的连接，那么 X+1 用户甚至无法打开连接。
I use a load balancer with my web site. The browser initiates a websocket connection to my app server. Does the open connection consume any resources on the LB or is it direct between the browser and the app server? If there is something open on the LB isn't it a bottleneck? I mean if my LB can handle X open connections then the X+1 user could not even open a connection.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于！
最高效的负载均衡器监听请求，进行一些分析，然后转发请求；所有位都不经过负载平衡器。网络转发发生在比 http 更低的网络层（例如，它不是 http 302 重定向 - 客户端永远不知道它发生了，维护内部网络配置的隐私 - 这发生在 OSI 4 级（我认为）。
但是，某些负载均衡器添加了更多功能，例如充当 SSL 端点或应用 gzip 压缩。在这些情况下，它们在通过时处理位（在这种情况下加密/解密或压缩）。
图片可能会有所帮助。将第一张图与第二张图进行比较第三个此处，注意第一个中的重定向，而其他中则没有。
It depends!
The most efficient load balancers listen for requests, do some analysis, then forward the requests; all the bits do not travel through the load balancer. The network forwarding happens at a lower network layer than http (e.g., it is not an http 302 redirect - the client never knows it happened, maintaining privacy around internal network configuration - this happens at OSI Level 4 I think).
However, some load balancers add more features, like acting as SSL endpoints or applying gzip compression. In these cases, they are processing bits as they pass through (encrypt/decrypt or compress in this case).
A picture may help. Compare the first diagram with the second & third here, noting redirection in the first that is absent in the others.