【发布时间】：2016-07-17 09:01:00
【问题描述】：
我开始开发一个软件，使用 html + js 编码的应用程序我需要从服务器（java 代码）发送此应用程序通知，该应用程序使用 nginx 进行路由，并托管在 AWS 中。 我调查了这个实时通知的主题，我在网络套接字和长轮询之间感到困惑 In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?
在一些文章中，我读到长轮询是一种旧的，不像 websocket 更新更好（In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?） 我开始检查 gmail facebook whatsapp 网页的元素。 我看到 Gmail+ facebook 使用长轮询与使用 Websocket 的 whatsapp 不同。 那么为什么这些公司仍然选择使用长轮询呢？ 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
【问题讨论】：
-
这完全是见仁见智的问题，你支持什么环境。较旧的浏览器和某些服务器不支持 Web 套接字，因此在这些情况下您需要长轮询。
-
公司可能不希望升级某些技术，因为升级成本很高。但是 websocket 确实比长轮询“更好”。传输的数据更少，并且可以双向启动通信。以 .NET SignalR 为例。它检查浏览器是否支持 websocket。如果是，则使用 ws，如果不是，则回退到 longpolling
-
socket.io 库将检测两端是否支持 webSockets，如果支持，则使用它。如果没有，它将使用长轮询。较旧的服务可能会使用长轮询来解决问题，并且现在不需要重新设计，但如果现在为现代浏览器从头开始设计，webSocket 将是通常的选择。
-
大多数不支持 websockets 的后端都可以做 SSE（EventSource），这比大多数规则下的长轮询要好。不使用 Sockets 的原因包括遗留兼容性有限、长时间占用相同的服务器端口（SSE/comet 可以池）、一些公共热点（例如酒店）不能正确传输 WebSockets、围绕 Sockets 的工具开发不足（与 http：logs/auth/middleware/gzip/etc 相比），并且套接字是双向的，而给定的项目只需要推送事件。
-
sockets ATM 的一个主要缺陷：如果有人向服务器发送（）一个 5gb 的 blob，在大多数包中没有简单的方法来 1. 告诉 blob 有多大，以及 2. 取消传输在不断开连接的情况下。此外，套接字往往存在于一个大池中，如果一个客户端崩溃/过载他的连接，它会影响其他用户，而 php+apache+SSE 不会像那样“崩溃”。
标签： javascript websocket long-polling polling