长轮询与Websockets的区别

Question

长轮询与Websockets的区别

8

我正在开发一个使用HTML + JS编码的软件应用程序，我需要从服务器（Java代码）向此应用程序发送通知，该应用程序使用Nginx进行路由并托管在AWS上。我调查了实时通知的主题，我对Web套接字和长轮询之间感到困惑。在什么情况下会首选AJAX长/短轮询而不是HTML5 WebSockets？在一些文章中，我读到长轮询是旧的，不像WebSocket那样新且更好 (在什么情况下会首选AJAX长/短轮询而不是HTML5 WebSockets？) 我开始检查Gmail Facebook WhatsApp网页的元素。我看到Gmail+ Facebook使用长轮询，而WhatsApp则使用Web套接字。那么为什么这些公司仍然选择使用长轮询？ https://www.quora.com/Does-Facebook-use-WebSockets-for-any-of-their-applications-Are-they-really-useful-at-that-scale-especially-since-they-impose-a-stateful-architecture

- Ortal Blumenfeld Lagziel

这完全是看个人意见以及你所支持的环境。旧浏览器和一些服务器不支持Web套接字，因此在这些情况下，你需要长轮询。 - Mike Cluck

公司可能由于升级成本而不愿意升级某些技术。但是WebSocket确实比长轮询更好，传输的数据量较少，通信可以双向启动。以.NET SignalR为例，它会检查浏览器是否支持WebSocket，如果支持则使用WebSocket，否则回退到长轮询。 - Ji_in_coding

1

socket.io库将检测双方是否支持WebSockets，如果支持，则使用WebSockets。否则，它将使用长轮询。旧的服务可能已经通过长轮询使事情正常运行，并且现在没有必要重新设计，但是如果现在从头开始为现代浏览器设计，则WebSocket将成为通常的选择。 - jfriend00

大多数不支持WebSockets的后端都可以使用SSE（EventSource），在大多数情况下比长轮询更好。不使用Sockets的原因包括有限的遗留兼容性，长时间占用相同的服务器端口（SSE / comet可以汇集），某些公共热点（例如酒店）无法正确传输WebSockets，与Sockets相关的工具开发不足（与http相比：日志/身份验证/中间件/gzip等），以及Sockets是双向的，而给定项目只需要推送事件。 - dandavis

套接字ATM的一个主要缺陷：如果有人向服务器发送5GB的blob，大多数软件包中没有简单的方法可以1.告诉这个blob的大小，2.在不断开连接的情况下取消传输。此外，套接字往往存在于一个大池子中，如果一个客户端崩溃/过载了他的连接，就会影响其他用户，而php+apache+SSE不会像那样“崩溃”这么严重。 - dandavis

2个回答

-2

WebSockets更好，它只消耗较少的电力，客户端不必每隔一段时间请求内容，唯一的缺点是旧浏览器不支持它们。

如果您想获得更多信息，可以在另一个问题中找到完整的比较。

在什么情况下会优先选择AJAX长/短轮询而不是HTML5 WebSockets？

- Luis Tellez

1

“更好”并不是一个适当的术语来比较两个不 - dandavis

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- gzost · Accepted Answer

一些公司仍然使用长轮询的原因有几个：

WebSocket支持还不是100%，即使没有支持的旧版浏览器正在逐渐消失。因此，如果您像谷歌这样的公司，其产品必须在几乎所有浏览器上运行，那么您仍需要一个非WebSocket的备用解决方案。
如果您已经有了一个工作解决方案，则迁移到WebSocket的成本可能超过它带来的节省。