消息推送的实现方式

短轮询(Long Polling)

1. 
   
2. 网络资源：短轮询会产生大量的网络请求，尤其是当客户端轮询间隔很短时。这可能会导致大量的网络开销。
   
3. 服务器处理：对于每个轮询请求，服务器需要处理该请求并发送响应，即使没有新的数据。这会导致服务器频繁地处理请求，可能增加CPU和内存的使用。
   
4. 总结：如果更新频率很低，但客户端仍然频繁地发送请求，短轮询可能会造成资源浪费，因为大多数响应可能只是告知“无新数据”
   

长轮询(Long Polling)

• 
  
• 客户端发送请求到服务器，服务器如果没有准备好的数据，就保持连接开放，直到有数据可以发送。一旦数据被发送，客户端处理数据后再次发送新的请求，如此循环。
  
• 长轮询通常用于实时或近实时的通知和更新，比如活动通知。
  

1. 
   
2. 网络资源：相比短轮询，长轮询减少了无效的网络请求。服务器只在有新数据时才发送响应，从而减少了网络流量。
   
3. 服务器处理：长轮询可能导致服务器需要维护更多的打开连接，因为它会为每个客户端请求保持一个打开的连接，直到有新数据或超时。这可能会增加服务器的内存使用，并可能达到服务器的并发连接限制。
   
4. 总结：长轮询在某些场景下可以提供更高效的资源使用，尤其是当数据更新不频繁但需要快速传递给客户端时。但如果有大量的客户端同时进行长轮询，服务器可能需要处理大量的并发打开连接。
   

WebSocket:

• 
  
• WebSocket提供了一个全双工通信通道，使得服务器和客户端可以在任何时刻发送数据给对方。这是一个非常实时且高效的解决方案。适合实时聊天
  

1. 
   
2. 网络资源：WebSocket 在建立连接后只需要一个握手过程，之后数据可以在此连接上双向传输，不需要为每条消息进行新的请求和响应。这极大地减少了网络开销。
   
3. 服务器处理：一旦 WebSocket 连接被建立，它将保持打开状态，直到客户端或服务器决定关闭它。这意味着服务器必须维护所有活动的 WebSocket 连接，这可能会消耗内存和其他资源。
   
4. 总结：WebSocket 在数据频繁更新并且需要实时传递给客户端的场景中非常有效。尽管需要维护持久连接，但由于减少了网络开销，通常更为高效。
   

服务器发送事件(Server-Sent Events, SSE) :

• 
  
• 服务器发送事件是一种使服务器能够发送新数据到客户端的简单方法。它比WebSocket简单，但只允许服务器向客户端发送数据。活动通知和提醒
  

1. 
   
2. 网络资源：与 WebSocket 类似，SSE 也只需要一次握手来建立持久连接。一旦连接建立，服务器可以持续地向客户端推送消息。
   
3. 服务器处理：SSE 需要维护持久连接以发送数据，但与 WebSocket 相比，SSE 只是单向的。这意味着服务器不需要处理从客户端发来的消息。
   
4. 总结：SSE 是一种高效的技术，适用于只需要服务器向客户端推送数据的场景，例如实时消息通知。
   

HTTP/2 Server Push:

• 
  
• 
  

  HTTP/2协议支持服务器推送，允许服务器在客户端需要之前预先发送数据。这可以减少延迟，但通常只用于发送关联的资源，如CSS或JavaScript文件，而不是用于通用的消息推送。

  
  
  
• 
  

  主要用于提前发送关联资源如CSS、JavaScript文件，以减少加载时间，提高网页性能。

  
  
  
• 
  

  可以减少网页加载时间，提高用户体验。

  
  
  
• 
  

  不适用于通用的消息推送，且需要HTTP/2协议支持，实现可能需要特定的服务器配置。

  
  
  

MQTT协议

MQTT 全称(Message Queue Telemetry Transport)：一种基于发布/订阅（publish/subscribe）模式的轻量级通讯协议，通过订阅相应的主题来获取消息，是物联网（Internet of Thing）中的一个标准传输协议。

该协议将消息的发布者（publisher）与订阅者（subscriber）进行分离，因此可以在不可靠的网络环境中，为远程连接的设备提供可靠的消息服务，使用方式与传统的MQ有点类似。

TCP协议位于传输层，MQTT 协议位于应用层，MQTT 协议构建于TCP/IP协议上，也就是说只要支持TCP/IP协议栈的地方，都可以使用MQTT协议。

为什么要用 MQTT协议？

MQTT协议为什么在物联网（IOT）中如此受偏爱？而不是其它协议，比如我们更为熟悉的 HTTP协议呢？

• 
  
• 首先HTTP协议它是一种同步协议，客户端请求后需要等待服务器的响应。而在物联网（IOT）环境中，设备会很受制于环境的影响，比如带宽低、网络延迟高、网络通信不稳定等，显然异步消息协议更为适合IOT应用程序。
  
• HTTP是单向的，如果要获取消息客户端必须发起连接，而在物联网（IOT）应用程序中，设备或传感器往往都是客户端，这意味着它们无法被动地接收来自网络的命令。
  
• 通常需要将一条命令或者消息，发送到网络上的所有设备上。HTTP要实现这样的功能不但很困难，而且成本极高。
  

第三方推送服务:

• 
  
• 使用如Firebase Cloud Messaging (FCM), Apple Push Notification Service (APNs)等第三方推送服务来处理消息推送。
  

对比

WebSocket和Server-Sent Events提供了较低的延迟和较高的实时性，但可能需要更多的服务器资源。长轮询可能会有更高的延迟，并且可能不是最高效的解决方案。HTTP/2 Server Push和第三方推送服务可能更适合于不需要高度实时性的应用。消息队列和发布/订阅模型提供了一种解耦服务器和客户端的方式，但可能会增加系统的复杂性。

在选择实现方法时，需要考虑应用的具体需求，例如实时性的要求、服务器资源、网络条件以及开发和维护的复杂性。同时，也可以考虑将几种方法结合使用，以满足不同的需求。

• 
  
• 如果有大量的客户端并且数据更新不频繁，长轮询可能比短轮询更为有效，因为它减少了无效的网络请求。
  
• 如果服务器有并发连接的限制或资源有限，大量的长轮询请求可能会耗尽资源，导致服务器不稳定。
  
• 如果数据更新非常频繁，短轮询可能会比较合适，因为它可以更简单地处理频繁的请求。
  
• WebSocket 通常在需要实时通信的应用中更为有效和资源高效。它减少了网络开销，并提供了持续的、低延迟的双向通信。
  
• 短轮询 和 长轮询 可能更适合不需要持续连接的场景或当 WebSocket 不可用或不适用时的备选方案。
  
• WebSocket：提供双向通信，适用于需要实时双向交互的应用，如在线聊天。由于它是全双工的，可能需要更多的资源来处理双向的消息传输。
  
• SSE：提供单向通信，适用于只需要服务器推送数据的应用，如股票行情更新。通常，SSE 比 WebSocket 更轻量，因为它只处理单向通信。
  
• 短轮询：可能会产生大量网络开销，特别是在数据更新频繁的场景中。
  
• 长轮询：减少了网络开销，但可能需要服务器维护大量的打开连接，直到有新数据或超时。
  

从资源消耗的角度看：

• 
  
• WebSocket 和 SSE 都需要维护持久连接，但通常比短轮询和长轮询更高效，因为它们减少了网络开销。
  
• SSE 可能比 WebSocket 更轻量，因为它是单向的。
  
• 短轮询 可能是最耗资源的，尤其是在频繁请求且数据更新不频繁的场景中。
  
• 长轮询 在某些情况下可能比短轮询更高效，但仍然不如 WebSocket 或 SSE。