着手开展新的物联网项目之前，必须考虑哪种通信模式最适用该项目。 事实上甚至在决定采用哪种协议、通信框架和中间件之前就应该考虑这些模式。 原因很简单： 这些决定能够防止您陷入必须分解解决方案的代码、架构、安全性或互操作性才可以摆脱的困境。
通过遵守标准和开放规范，可以显著增强互操作性。 同样，通过使用现有的开放式、标准化、可互换组件，也可以避免构建昂贵的中间件。 部分模式可能包括在项目前期增加灵活性，不过相比于在项目生命周期末因无法预料但可规避的问题（包括与集成相关的问题）所产生的成本，这种成本显得微不足道。
请求/响应
请求/响应也许是最常见的通信模式。 它包括客户端，或呼叫者（请求服务器提供服务），或响应者（图 1）。 HTTP 使用这种通信模式，它也是服务导向型架构、Web 服务和表达性状态转移的基础。 该模式非常实用，尤其在您拥有客户端-服务器或主-从架构的时候。 支持该模式的其他协议包括 Constrained Application Protocol (CoAP) 和可扩展消息传递和到场协议 (XMPP)。
图 1. 请求/响应通信模式
这种模式的缺点是，参与方之间存在不平等性，这一点在互联网拓扑中也非常明显。 双方可能难以互相请求信息的双向通信，尤其在存在防火墙的情况下。 必须决定哪方为客户端，哪方为服务器。 如果传感器为客户端，中间件为服务器，传感器可在进行选择后报告数据，而中间件无法简单地在需要的时候获取信息。 如果传感器为服务器，中间件为客户端，中间件可以在需要的时候收集数据，但传感器可能不会处于防火墙之下，任何设备都可连接该传感器。 因此，事件与事件订阅或安全性的管理并非易事，而且如果网络中使用了防火墙，有时需要使用其他服务或大量资源。
事件订阅
事件订阅模式支持客户端从服务器订阅特定类型的事件。 事件触发后，服务器通知客户端，无需持续轮询服务器（图 2）。 高级事件订阅机制包含何时需要事件以及须具备哪些条件等特定于客户端的要求。 使用这种模式的优势是，随着事件的推移，一半的信息不再需要，而且更新延迟保持最低。 支持这种模式的协议包括 CoAP、XMPP 和通用事件通知架构 — HTTP 的扩展版，通用即插即用架构的一部分。
图 2. 事件订阅通信模式
异步消息传递
异步消息传递是指能够在网络中的对等伙伴 (peer) 之间发送消息。 该模式假设消息能够双向传输，以及参与方之间不存在隐含的等级差异（图 3）。 如果某协议支持异步消息传递通信模式，其他所有的通信模式都可基于其构建。 支持这种模式的协议包括 XMPP、高级消息队列协议 (AMQP)、以及 IP 层级上的用户数据报协议 (UDP) — 尽管这种协议可能存在防火墙问题。
图 3. 异步消息传递通信模式
可靠消息传递
对于关键应用来说，必须了解信息已一次性准确传递至目的地，异步消息传递通信模式可实现这点。 消息可能会在途中丢失，而使用请求/响应模式，可以重新尝试发送消息，直至目的地返回接收（或响应）信号。 由于消息以及响应都有可能丢失，因此这种方法可确保消息至少一次性传递至目的地，但最多一次 - 或至少一次 - 对部分应用（比如要求交易或执行计数的应用）来说是不够的。 可靠消息传递能够确保消息一次性准确传递至目的地。 支持可靠消息传递的协议包括消息队列遥测传输 (MQTT)、AMQP 和 — 通过发布的开放扩展指令集 — HTTP 和 XMPP。
多播
上述通信模式涉及的是两个实体之间的通信。 不过有时要求同时将相同信息发送至多个实体，这时需要采用更高效的通信模式。 最简单的模式是多播通信模式。 发件人通过媒介（代理或路由器）发送一条消息，然后分发至多个均已请求参与通信的接收者（图 4）。 这种模式可以显著节省带宽，因为发件人无需自己将信息发送至各方。 事实上，发件人甚至无需知道接收者是谁。 这种模式有多种使用方法。例如，同步多个实体或将消息分发至多个接收者。 支持多播模式的协议包括 XMPP、AMQP 和 UDP。
图 4. 多播通信模式
不过有一点值得注意： 尽管使用这种模式可以节省带宽，但它通常用来克服所选协议的局限性并支持事件订阅模式。 此外，多播通常难以确保其安全性，而且只有在接收者实际使用最多传输值的情况下才具有带宽高效性。 如果在需要使用事件订阅但无法使用时，频繁使用多播来降低网络中的延迟，可能会大幅增加所需带宽。
发布/订阅
发布/订阅通信模式是多播模式的扩展，其主要区别在于传输的消息也保存在中间节点上。 消息或消息参考然后会根据协议分发至相应的订阅者。 根据所选的协议或有关媒介的设置，媒介上只保存最新消息、特定数量的消息或所有消息。 分发整条消息，还是只分发消息参考，这一点非常重要，会通过所使用的带宽影响解决方案的性能。 与多播通信模式相同，如果订阅者使用大部分消息，会提高转发消息的效率。 但是，如果仅按需使用，发送较短的参考会比较高效，因为这些消息较短，订阅者仅使用一小部分就可获取实际消息。 在后者情况下获取消息时，需要单独执行请求/响应行为。 支持发布/订阅模式的协议包括 MQTT、AMQP 和 XMPP。
队列
队列 - 或先进先出队列 - 这种通信模式支持一个或多个实体向队列发布消息或工作项目，然后支持一个或多个接收者以有序的方式接收消息（图 5）。 队列通常驻留在连接所有参与方的中间节点或网络上。 如果从多个源收集的工作项目需要分发至现有 worker（性能可能各不相同），队列是帮助平衡负载的理想工具。 通过使用队列，可以避免数据提供者与 worker 之间的硬链接，从而轻松扩展或压缩数据提供者与 worker 的集（取决与实际工作负载）。 在上述介绍的协议中，只有 AMQP 以本机形式支持队列。
图 5. 队列通信模式
消息代理
从本质上来说，消息代理属于标准化中间件组件，可有效解决防火墙阻止网络中对等伙伴之间的双向通信问题。 它们的工作原理是，支持实体连接至消息代理，然后在已连接客户端之间代理传递消息。 因为所有连接在设备和代理之间形成，因此只需通过互联网访问代理即可。 防火墙无需像使用严格对等协议要求的那样，接受或将入站连接转发至设备。
除代理传递消息外，代理还可为已连接实体提供重要的服务，比如在多播模式、发布/订阅和队列模式中充当媒介。 消息代理通常还可提供客户端验证服务 -— 分布式网络中的已连接设备处理起来颇为棘手的问题。 因此，如果代理转发通信中包含的以验证方身份，实体将可以利用该信息制定安全性决策，无需在各台设备中实施定制验证。 尽管许多解决方案都可以选择对等通信，但必须独自处理客户端验证，以确保安全。 如果使用包含消息代理的协议，运行解决方案时可以不必开发自己的中间件。 以某种形式使用代理的协议包括 XMPP、AMQP 和 MQTT。
联合
联合是一种重要的通信模式，其中全局网络划分成不同的逻辑部分，以支持全局扩展和有机增长（图 6）。 此处的关键是使用分治方法，在不影响现有网络性能的情况下支持增长。 在未代理通信中，比如使用 HTTP 或 CoAP，联合模式在域层面上执行。 每个域指向托管自己的 Web 服务器的 IP 地址集。 您可以在新的域上添加新的 Web 服务器，不会限制访问现有 Web 服务器。 这已成为帮助万维网成功扩展的关键特性。
图 6. 联合
使用支持联合的代理协议时，代理相互连接以路由或转播消息。 每个代理处理自己域上的验证，并识别如何连接至其他域以向它们转发消息。 支持联合的最著名的代理协议是简单邮件传输协议 (SMTP)。 在上述介绍的代理协议中，只有 XMPP 支持联合模式。 联合代理网络支持巧妙地向每个实体分发全球全局身份。
发现
大规模分发场景中会出现一些问题。 首先，物体在生产期间不知道网络身份或所有者身份。 它们仅知道其概念身份。 （最好使用一些零配置技巧完成）安装和配置后，它们可以知道新的网络身份（而非所有者身份）。 相反，通过扫描盒子上的贴签，所有者可以知道自己的网络身份和物体的概念身份。 发现通信模式能够创建一种机制，使用对物体概念身份的通用知识匹配物体的网络身份和所有者的网络身份（图 7）。 这可以使用在网络上提供给物体和所有者的物体注册表来进行。 物体通过注册表注册概念身份，所有者仅使用概念身份声明该物体。 如果成功，它们的网络身份可以发送至对方，双方都知道如何与对方通信。 XMPP 的扩展版支持这种模式。
图 7. 发现
信任授权
在互联网中，必须能够制定明智的安全决策。 在信任授权这种通信模式中，物体向强大、可信的实体实时转发请求，然后在收到响应后根据响应内容执行操作（图 8）。 可信实体既可使用机器学习，也可直接与物体所有这通信，以了解如何在与物体所属相关的网络上响应新请求。 必须使用实时异步双向消息传递，才能执行这种通信模式。 XMPP 的扩展版支持这种模式。
图 8. 信任授权通信模式
其它信息
如欲了解更多有关这些协议的信息，请访问以下网站：