Javascript 对于推送通知，是否必须使用 websocket？

For a push notification, is a websocket mandatory?

提问by John Franky

I have PHP on the server side, and HTML and javascript on the client side.

我在服务器端有 PHP，在客户端有 HTML 和 javascript。

I am making an app where a stakeholder types a message that is broadcasted to multiple recievers of a group in real time.

我正在制作一个应用程序，其中利益相关者输入一条消息，该消息实时广播给一个组的多个接收者。

I did some research on google and I understand I need to use WebSockets or Comet for real time push notifications. Is WebSocket or Comet mandatory for sending mass notifications to users?

我对谷歌做了一些研究，我知道我需要使用 WebSockets 或 Comet 来进行实时推送通知。WebSocket 或 Comet 是否必须向用户发送大量通知？

Is my understanding correct? Any references to start with?

我的理解正确吗？任何参考开始？

回答by jfriend00

If the client is a browser, then the ONLY two ways a standard browser can connect to a server is via an Ajax (e.g. http) request or a webSocket connection. So, if you want a client to get notified of something from the outside world it has to use one of those two mechanisms.

如果客户端是浏览器，那么标准浏览器连接到服务器的唯一两种方式是通过 Ajax（例如 http）请求或 webSocket 连接。因此，如果您希望客户端收到来自外部世界的通知，则必须使用这两种机制之一。

HTTP requests are transitory.The client makes a request of a server, the server responds. HTTP requests are perfect for the client requesting information from the server. They are not very good at the server sending information to the client because normally the client is not connected. There are hacks and work-arounds where the client "polls" the server on some interval and maybe even the server uses longer running requests to try to simulate a "push" type system, but they are sub-optimal hacks at best.

HTTP 请求是暂时的。客户端向服务器发出请求，服务器响应。HTTP 请求非常适合客户端从服务器请求信息。他们不太擅长服务器向客户端发送信息，因为通常客户端没有连接。有一些黑客和变通方法，其中客户端在某个时间间隔“轮询”服务器，甚至服务器可能使用更长的运行请求来尝试模拟“推送”类型系统，但它们充其量只是次优黑客。

webSockets are continuous connections.The client connects and the connection remains in place for as long as both sides want. This allows either side the ability to send a message to the other side whenever they want. That means the server can "push" data to the client whenever it wants. webSockets are efficient for push connections and are recommended (this is one of the main things they were designed for).

webSockets 是连续连接。客户端连接，并且只要双方需要，连接就会保持原状。这允许任何一方随时向另一方发送消息。这意味着服务器可以随时将数据“推送”到客户端。webSockets 对于推送连接很有效，推荐使用（这是它们设计的主要目的之一）。

Comet is a library that was originally built for using HTTP to try to "hack" or "simulate" push before webSockets were invented and then before they were widely supported. I can think of no reason why one would want to use Comet instead of a webSocket unless you had such an old browser that webSocket was not supported.

Comet 是一个库，最初是为了在 webSockets 被发明和广泛支持之前使用 HTTP 尝试“破解”或“模拟”推送而构建的。我想不出为什么要使用 Comet 而不是 webSocket ，除非你有一个不支持 webSocket 的旧浏览器。

So, if you are trying to do "realtime server push" to a browser, then you must have a continuously connected socket from the client which means webSocket (or something built on top of webSocket like socket.io).

因此，如果您尝试对浏览器进行“实时服务器推送”，那么您必须有一个来自客户端的持续连接的套接字，这意味着 webSocket（或构建在 webSocket 之上的东西，如 socket.io）。

For phone apps where you have access to the phone SDK, you can use the "push" system built into the OS to push some messages from server to client. This isn't quite the same as the two way webSocket channel, but since you asked about "push notifications", the OS push services available in both Android and IOS could also be an option for pushing notifications from server to client. Here's info on iOS notificationsand Google Cloud Messaging

对于可以访问手机 SDK 的手机应用，您可以使用操作系统内置的“推送”系统将一些消息从服务器推送到客户端。这与双向 webSocket 通道不太相同，但是由于您询问了“推送通知”，因此 Android 和 IOS 中可用的操作系统推送服务也可以作为将通知从服务器推送到客户端的选项。以下是有关iOS 通知和Google Cloud Messaging 的信息

As of 2016, one can also use Server-sent eventsin all modern browsers except Microsoft browsers (not supported yet in Edge or IE) to push data from server to client. Here's a browser compatibility table. Server-sent events use a long lasting HTTP connection, a special MIME type and a supporting client in order to be able to send events from server to client at any time. Unlike webSockets, server-sent events are one way only (from server to client). A client would then use a traditional Ajax call in order to be able to send data to a server (whereas with a webSocket data can be sent either way over the same webSocket connection).

截至 2016 年，除了 Microsoft 浏览器（Edge 或 IE 尚不支持）之外，还可以在所有现代浏览器中使用服务器发送的事件将数据从服务器推送到客户端。这是浏览器兼容性表。服务器发送的事件使用持久的 HTTP 连接、特殊的 MIME 类型和支持的客户端，以便能够随时从服务器向客户端发送事件。与 webSockets 不同，服务器发送的事件只是一种方式（从服务器到客户端）。然后客户端将使用传统的 Ajax 调用，以便能够将数据发送到服务器（而使用 webSocket 数据可以通过相同的 webSocket 连接以任何方式发送）。

Here's a good description of how server-sent events work: How do server-sent events actually work?

这里很好地描述了服务器发送的事件是如何工作的：服务器发送的事件实际上是如何工作的？

回答by Marcello Kad

Is your client application a SPA? (Single Page application)? It's very important because if not, you have to consider that everytime a client change page, connection with websocket server will be lost. In this case you have to manage a queue because if stakeholder send a multicast request when one client is disconnected, client won't receive nothing. Polling won't solve this situation too and it's an orrible solution because mobile clients (for example) with typical internet plan, will consume megabytes for unuseful "ping" traffic. A real example of polling is a child in a car asking his dad every minute if they are arrived to a destination! So, Is there a solution without using spa? Yes, using a "shared storage" between stakeholder and clients, and using websocket only for "wake up" online clients saying: Hey there is something new, go to check!

您的客户端应用程序是 SPA 吗？（单页应用程序）？这很重要，因为如果没有，您必须考虑每次客户端更改页面时，与 websocket 服务器的连接都会丢失。在这种情况下，您必须管理一个队列，因为如果利益相关者在一个客户端断开连接时发送多播请求，客户端将不会收到任何消息。轮询也不能解决这种情况，这是一个糟糕的解决方案，因为具有典型互联网计划的移动客户端（例如）将消耗兆字节用于无用的“ping”流量。投票的一个真实例子是一个孩子在车里每分钟问他的父亲他们是否到达目的地！那么，有没有不使用spa的解决方案？是的，在利益相关者和客户之间使用“共享存储”，并且仅将 websocket 用于“唤醒”

Everytime a client open a page it will receive from backend also not-read notifications, taken from the storage. When a stakeholder want to notify something, it will just store the notification message in the shared storage and send a "pulse" to notification server. Notification server will forward the "pulse" to online clients (just in case someone is stuck reading a page). If a "pulse" is lost because a client is changing page there is no problem because the client will bring notifications from the storage. Every page will contain this logic: Retrive number or unread notifications (server side) Connect to the notification server after 5 seconds (javascript side). Hope it helps.

每次客户端打开一个页面时，它都会从后端收到来自存储的未读通知。当利益相关者想要通知某事时，它只会将通知消息存储在共享存储中并向通知服务器发送“脉冲”。通知服务器会将“脉冲”转发给在线客户端（以防万一有人在阅读页面时被卡住）。如果由于客户端正在更改页面而丢失“脉冲”，则没有问题，因为客户端将从存储中带来通知。每个页面都将包含此逻辑： 检索编号或未读通知（服务器端） 5 秒后连接到通知服务器（javascript 端）。希望能帮助到你。

回答by Libby Lebyane

I would suggest that using webSockets is a more efficient way compared to other options, why is this? Well when a client receives a notification that there's a change in the server there is no need to create an AJAX call to the server to get that change, it can be sent to the client with the same webSocket connection more easily than AJAX. This means efficient code and a faster running App!

我建议与其他选项相比，使用 webSockets 是一种更有效的方法，为什么会这样？好吧，当客户端收到服务器发生更改的通知时，无需创建对服务器的 AJAX 调用来获取该更改，它可以比 AJAX 更容易地通过相同的 webSocket 连接发送到客户端。这意味着高效的代码和更快运行的应用程序！