自从DeepsteramHub开工以来，在实时技术世界中跑了几个月，我想很多人对这个世界上很多的概念有很多误解。Deepsteram.io是一个开放的实时服务器，让您可以在现有应用程序中构建实时功能，而无需担心任何后端的魔术。几乎所有的深水流作品在websockets上，这在实时世界中是完全有意义的。然而，几个月前，deepstream也决定发布一个HTTP API。其中一个主要原因是，当涉及到IoT传感器时，Websockets不是真正的选择。这让我好奇，我想深入挖掘推理。

我们从有关IoT传感器可能使用的三个主要协议的一些背景开始：

1. HTTP
2. MQTT
3. 的WebSockets

的WebSockets

   如前所述，websockets目前是实时世界的主要参与者之一。Websockets允许持续连接同时进行双向通信。它们具有HTTP的所有好处，因为websockets最初作为HTTP握手开始，然后升级到在Websockets中继续其余的通信。

   websockets的本质是基于推送的策略。这意味着与轮询或长时间轮询不同的是，如果存在任何新数据，则按照定时间隔来询问服务器，即使在基于推送的情况下，服务器本身也会在有新的数据可用时向有兴趣的客户端发送消息。这被称为发布订阅范例或简称pub / sub。这在websockets（与HTTP）中是可能的，因为websockets保持连接断开，直到由双方之一（即客户端或服务器）故意关闭。

MQTT

   MQTT（消息队列遥测传输）是一种轻量级应用级协议，允许您在服务器和客户端之间建立持久连接。它最适合与低功耗设备一起使用，这只是IoT传感器的情况。它支持发布订阅架构。此外，它还提供某些其他功能，如QoS（服务质量），允许您从几个可用选项中选择通信质量，从而确保保证交付的水平

HTTP / HTTP2

    在互联网的这一演变过程中，您最可能知道HTTP（超文本传输​​协议）是一种无状态协议，通常可以通过TCP / IP协议工作，并允许使用通用请求 - 响应范例进行通信。它不被认为是实时意义上的合适协议，因为它提供非持久连接，即每当客户端希望与服务器通信时建立新的请求 - 响应周期。

    可以在HTTP服务器上进行轮询或长时间轮询，以便在给定频率下持续要求更新。HTTP还带有一个“持久连接”功能，可以使用它来保持连接的打开状态。另外，新的HTTP / 2协议本质上支持持久连接。但HTTP和HTTP / 2都不支持pub / sub或者特定的，它们不是基于push的。那么，HTTP在实时生态系统中是无法工作的。对！？

所以现在怎么办？

   所有这些协议都具有自己的优点，用例以及任何其他已经设计的协议的缺点。但是在这里我们特别关心使用低功耗的IoT传感器。

现在不同种类的传感器需要不同的频率来发送它们的更新。在大多数情况下，这是触发传感器发送一些数据的事件。在其他情况下，他们可能每小时左右发送更新。传感器连续向服务器发送一些信息是非常罕见的。现在，不要误会我，传感器当然可以不断地监视一些数据，但这并不一定意味着它正在发送它监控的所有数据。

   因此，在这种具有持续连接的情况下，只会吓倒这些传感器，并且仅仅是开销。然而，令人惊讶的是，MQTT在许多情况下仍然是一个解决方案。虽然MQTT是持久性的，但它的重量非常轻，并被设计用于这种低功率器件。现在，如果你考虑，使用MQTT有很大的意义吗？

可是等等！

   正如我前面提到的，评估基于用例的持久连接的需求是非常重要的。如果正在监控其环境中的某些变化的传感器只需要让客户端或服务器知道一个事件，那么我们可以简单地使用HTTP来实现此目的。这是一种简单的老式办法，事实证明是最好的办法！事实上，在一些低功耗设备中，持续连接将要求它们始终处于活动状态，而可能在其他状态下睡眠，从而节省了大量电池和其他因素。

   因此，虽然HTTP协议似乎不是在实时使用中使用的HTTP协议，但它是IoT传感器的最佳选择之一，因为感测设备发送更新后会发生什么，仍然可以实时实施，魔术本质上延续。在一些使用情况下，持久连接实际上是有意义的，MQTT将是与之相伴的。但是，在我看来，websockets从来不是一个选择，因为设置哪些是不值得的好处，太多的开销，至少考虑到IoT设备的低功耗场景。

这实际上是延伸HTTP支持的任何实时框架/ API /服务器背后的主要原因。