对于推送通知,Websocket 是必需的吗?

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

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

我在谷歌上做了一些研究,我知道我需要使用WebSockets或Comet进行实时推送通知。WebSocket或Comet是向用户发送大量通知的强制性要求吗?

我的理解是否正确?有什么参考资料可以开始吗?


答案 1

如果客户端是浏览器,那么标准浏览器连接到服务器的唯一两种方式是通过Ajax(例如http)请求或webSocket连接。因此,如果您希望客户端从外部世界获得某些通知,则必须使用这两种机制之一。

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

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

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

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

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

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

下面很好地描述了服务器发送的事件的工作原理:服务器发送的事件如何实际工作?


答案 2

您的客户端应用程序是 SPA 吗?(单页应用程序)?这非常重要,因为如果没有,您必须考虑每次客户端更改页面时,与websocket服务器的连接都将丢失。在这种情况下,您必须管理队列,因为如果利益干系人在一个客户端断开连接时发送多播请求,则客户端不会收到任何内容。轮询也不能解决这种情况,这是一个可行的解决方案,因为具有典型互联网计划的移动客户端(例如)将消耗兆字节的无用“ping”流量。一个民意调查的真实例子是,一个孩子在车里每分钟问他的父亲他们是否到达目的地!那么,有没有不使用水疗的解决方案?是的,在利益相关者和客户之间使用“共享存储”,并且仅对“唤醒”在线客户使用websocket,说:嘿,有新的东西,去检查!

每次客户端打开页面时,它都会从后端收到未读通知,这些通知是从存储中获取的。当利益干系人想要通知某些内容时,它只会将通知消息存储在共享存储中,并向通知服务器发送“脉冲”。通知服务器会将“脉冲”转发给在线客户端(以防有人无法阅读页面)。如果由于客户端正在更改页面而丢失“脉冲”,则没有问题,因为客户端将从存储中带来通知。每个页面将包含以下逻辑:回溯编号或未读通知(服务器端)5秒后连接到通知服务器(javascript端)。希望它有帮助。