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