物联网的通信模式
在开始新的物联网项目之前，您应该考虑哪种通信模式最适合它。
获取新的 Intel® 物联网开发套件，这是一个完整的硬件和软件解决方案，允许开发人员使用 Intel® Galileo 和 Intel® Edison 主板创建令人兴奋的新解决方案。请访问 Intel® 物联网开发者专区。
在开始新的物联网项目之前，您应该考虑哪种通信模式最适合它。事实上，在您决定使用什么协议、通信框架和中间件之前，您就应该考虑这些模式。原因很简单：这个决定可以避免您陷入一个难以摆脱的困境，否则将不得不破坏解决方案的代码、架构、安全性或互操作性。
通过遵守标准和开放规范，您可以提高互操作性。同样，通过使用现有的开放、标准化、可互换的组件，您还可以避免构建昂贵的中间件。有些模式可能在项目早期增加额外的复杂性，但与项目生命周期后期可能出现且可避免的意外问题（包括与集成相关的问题）相比，这笔成本可能微不足道。
请求/响应
请求/响应可能是最常见的通信模式。它由一个客户端（或调用者）组成，该客户端请求服务器（或响应者）的服务（图1）。这是HTTP使用的模式，也是面向服务架构、Web服务和表征状态转移的基础。这是一种有用的模式，特别是如果您有客户端-服务器或主-从架构。支持此模式的其他协议包括受限应用协议 (CoAP) 和可扩展消息和存在协议 (XMPP)。
然而，这种模式的一个缺点是参与者不平等，这在互联网拓扑中也很明显。双向通信，即双方相互请求信息，可能很困难，特别是当存在防火墙时。您必须决定谁是客户端，谁是服务器。如果您将传感器设为客户端，将中间件设为服务器，则传感器可以在其选择的时间报告数据，但中间件在需要时将难以获取信息。如果传感器是服务器，中间件是客户端，则中间件可以在需要时收集数据，但传感器可能不受防火墙保护，导致任何人都可以连接到它。因此，事件和事件订阅或安全性难以管理，并且在网络中使用防火墙时有时需要额外的服务或大量资源。
事件订阅
事件订阅模式允许客户端订阅服务器上给定类型的事件。然后，服务器在每次事件触发时通知客户端，而无需持续轮询服务器（图2）。高级事件订阅机制可以包括客户端特定地在何时何种条件下需要事件的要求。使用此模式的好处是，随着时间的推移，一半的消息不需要发送，并且更新的延迟保持在最低限度。支持此模式的协议包括 CoAP；XMPP；以及通用事件通知架构，它是通用即插即用架构的一部分，是 HTTP 的扩展版本。
异步消息传递
异步消息传递是在网络中的对等体之间发送消息的能力。该模式假设消息可以在两个方向传播，并且参与者之间没有隐含的层次差异（图3）。如果一个协议支持异步消息传递通信模式，那么所有其他通信模式都可以建立在其之上。支持此模式的协议包括 XMPP；高级消息队列协议 (AMQP)；以及在 IP 层，用户数据报协议 (UDP)，尽管后者可能存在防火墙问题。
可靠消息传递
对于关键应用程序，了解消息已准确无误地一次性发送到目的地非常重要，而异步消息传递通信模式正是如此。消息可能在途中丢失，但使用请求/响应模式，您可以重试发送消息，直到从目的地返回确认（或响应）。由于消息及其响应都可能丢失，因此此方法确保消息至少一次发送到目的地，但至多一次——或至少一次——对于某些应用程序来说不够好，例如需要事务或进行计数的应用程序。可靠消息传递是一种确保消息准确无误地一次性发送到目的地的方法。支持可靠消息传递的协议包括消息队列遥测传输 (MQTT)、AMQP，以及通过已发布的开放扩展——HTTP 和 XMPP。
多播 (Multicasting)
之前的模式关注的是两个实体之间的通信。然而，有时如果相同的信息要同时发送给多个实体，则需要更有效的模式。最简单的这种模式是多播通信模式。在这里，发送方通过中间方（代理或路由器）发送一条消息，然后中间方将其分发给所有已请求参与通信的多个接收方（图4）。这种模式节省了带宽，因为发送方不必自己向所有方发送单独的消息。事实上，发送方甚至不必知道接收方是谁。这种模式在许多方面都很有用——例如，在同步多个实体或向许多接收方分发信息时。支持多播的协议包括 XMPP、AMQP 和 UDP。
然而，有一点需要注意：尽管您可以使用此模式来节省带宽，但它通常被用作克服所选协议及其对事件订阅模式支持的限制的一种手段。此外，多播本质上难以安全，并且仅当接收方实际使用大部分传输值时，它在带宽方面才更有效。如果您频繁使用多播来降低网络中的延迟，而该网络需要事件订阅但不可行，则多播模式可能会大幅增加而不是减少所需的带宽。
发布/订阅
发布/订阅通信模式是多播模式的扩展，主要区别在于传输的消息也存储在中间节点上。然后，根据协议，将消息或消息的引用分发给相应的订阅者。根据所选协议和中间节点的设置，只存储最新消息，存储给定数量的消息，或存储所有消息。分发整个消息和仅分发消息引用之间的区别很重要，并且会影响解决方案在消耗带宽方面的性能。如果订阅者消费大部分消息，则转发消息本身效率更高，如多播情况。然而，如果仅按需消费，则发送较短的引用效率更高，因为这些消息较小，并且订阅者将只使用其中一小部分来获取实际消息。在后一种情况下，为了获取消息，需要执行单独的请求/响应操作。支持发布/订阅模式的协议包括 MQTT、AMQP 和 XMPP。
队列
队列（或先进先出队列）是一种通信模式，它允许一个或多个实体向队列发布消息或工作项，然后让一个或多个接收器以有序的方式接收这些消息（图5）。队列通常位于所有参与者连接到的中间节点或网络上。队列是平衡负载的绝佳工具，当从多个来源收集的工作项需要分配给现有工人时，这些工人可能具有不同的性能。通过使用队列，您可以避免数据提供者和工人之间的任何硬链接，从而可以根据实际工作负载轻松扩展或限制数据提供者集和工人集。在本文讨论的协议中，只有 AMQP 本机支持队列。
消息代理
消息代理本质上是标准化的中间件组件，它们为防火墙对网络中对等体之间的双向通信施加的问题提供了优雅的解决方案。它们通过允许实体连接到它们，然后在连接的客户端之间代理消息来工作。因为所有连接都是从设备到代理，所以只有代理需要从互联网访问。防火墙不需要接受或转发传入连接到设备，而如果您使用严格的对等协议，则需要这样做。
除了代理消息之外，代理还可以为连接的实体提供重要的服务，例如在多播、发布/订阅和队列模式中充当中介。消息代理通常还提供客户端身份验证服务，这对于分布式网络中的连接设备来说可能很棘手。因此，如果代理转发通信中已验证方的身份，实体可以使用此信息做出安全决策，而无需在每个设备中实现定制的身份验证。尽管点对点通信对许多人来说可能是一个选择，但此类解决方案必须自行处理客户端身份验证以避免变得不安全。如果您使用包含消息代理的协议，您可能不需要开发自己的中间件来使您的解决方案工作。以某种形式使用代理的协议包括 XMPP、AMQP 和 MQTT。
联盟
联盟是一种重要的模式，其中全球网络被划分为逻辑部分，以实现全球可扩展性和有机增长（图6）。这里的关键是允许增长，而不通过分而治之的方法限制现有网络的性能。在非代理通信中，例如使用 HTTP 或 CoAP 进行的通信，联盟发生在域级别。每个域指向其自己的 IP 地址集，托管其自己的 Web 服务器。您可以在新域上添加新的 Web 服务器，而不会限制对现有 Web 服务器的访问。这是万维网成功和可扩展性的关键特征。
当使用支持联邦的代理协议时，代理之间会相互连接以路由或中继消息。每个代理在其自己的域上处理身份验证，并知道如何连接到其他域以将消息转发给它们。最著名的支持联邦的代理协议是简单邮件传输协议。在本文讨论的代理协议中，只有 XMPP 支持联邦。联邦代理网络提供了一种优雅的方式来为每个实体分配全局身份。
发现
在大规模分发场景中会出现几个问题。首先，设备在生产时既不知道网络身份，也不知道所有者的身份：它们只知道其概念身份。在安装和配置之后，最好使用零配置技术来实现，它们会学习其新的网络身份，但不知道所有者的身份。相反，所有者知道其自己的网络身份和设备的概念身份，这可能是通过扫描盒子上的贴纸来实现的。发现通信模式创建了一种机制，通过该机制，使用设备概念身份的共同知识，将设备的网络身份与所有者的网络身份进行匹配（图7）。这通过网络上对设备和所有者都可用的设备注册表进行。设备将其概念身份注册到注册表，所有者仅使用其概念身份声明设备。如果成功，彼此的网络身份会发送给对方，然后双方都知道如何相互通信。存在 XMPP 的扩展以支持此模式。
信任委托
在互联网上，能够做出良好的安全决策非常重要。信任委托是一种通信模式，其中一个“物”实时将请求转发给一个更强大、受信任的实体，然后根据响应内容执行操作（图8）。这个受信任的实体可以使用机器学习或与该“物”的所有者直接通信，以了解如何响应网络上与该“物”相关的新的请求。要使这种模式成为可能，需要实时异步双向消息传递。存在 XMPP 的扩展以支持此模式。
附加信息
有关这些协议的更多信息，请参阅以下网站