2024年Go最全物联网开发中常见的几个标准协议(2)，2024年阿里Golang高级面试题分享

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

博主介绍

🌊 作者主页：苏州程序大白

🌊 作者简介：🏆CSDN人工智能域优质创作者🥇，苏州市凯捷智能科技有限公司创始之一，目前合作公司富士康、歌尔等几家新能源公司

💬如果文章对你有帮助，欢迎关注、点赞、收藏（一键三连）和C#、Halcon、python+opencv、VUE、各大公司面试等一些订阅专栏哦

💅 有任何问题欢迎私信，看到会及时回复

前言

假设你正准备开始一个物联网项目，在开始项目之前你需要做很多选择，有可能你完全不知道从哪开始，这篇文章我们一起来看看如何选择标准的无线通信协议框架。

当然，这些无线通信协议框架是部署在你的设备内部进行通信的，物联网项目中还要考虑到一些外部的硬件，这些硬件都是在制作工厂完成的，所以本文讲重点关注一些使用比较广泛的通信产品。

让我们看看物联网目前的状况—，目前来说没有一个协议是比其他协议更加意义重大和具有绝对优势，物联网中的这些标准（协议）是根据具体问题选择最合适的，选择一个成本上可以接受和可实施性以及可扩展性，选择的时候你完全不用担心这些标准会过时。

所以，首先归结为技术上的限制，你需要思考:

• 带宽范围要求是什么？
• 网络中将支持多少个节点？
• 每个节点网络的覆盖范围多大？

无线网络的选择是一个很重要的环节，它还直接影响到了你对通信设备和资源的选择。例如，如果你有一个无线 Wi-Fi，你就需要相当大的 CUP 和内存，而如果我们选择 BLE 或者一些其他的双通道网络则需要很少的资源。另外我们还要考虑通信基础架构的扩展成本，如果我们使用 Wi-Fi 就要考虑在部署项目的地方是否有 Wi-Fi 的覆盖，这些 Wi-Fi 是否可靠，如果没有如何去大面积的覆盖，这些可能会使成本变的很高，尤其当你选择工业级的接入点的时候成本更高，所以我们要综合考虑这些因素的影响。

特定标准

在我们看来，我们发现的最大误解是:“难道不会有一个通信标准来统治它们吗？”，如果有这样的标准，那么物联网的发展是没有未来的，因为在物联网的领域永远不会存在一个相同的问题，我们解决的都是特定领域的特殊问题，所以接下来我们来看看不同的通信协议的特点，它们擅长解决那类通信问题，以及它们在 OSI 模型中的位置。

MQTT

有些人认为从设备到服务器进行通信是一个完整的通信协议，但事实并非如此。MQTT 协议只被用来定义通信中的一种数据格式，和具体的传输方式无关，可以通过任何方式传输，无论是 Wi-Fi 还是一些双工通信网络或者是 socket. MQTT 视图解决的是如何i当以一种操纵某些事物属性的方法，它以读写属性位核心，这样就很好的解决了物联网中的数据格式问题。从某些方面来说，MQTT 节省了很大的开发时间，可能在刚开始使用的时候你需要花费更多的时间去研究和更严谨的使用它，等你完成一次协议对接后，把这种方案保存下来，后面就可以极大的节约你的时间。

MQTT 是否已经好到你必须使用它的程度了？

不，它还没有达到那个水平，也不可能达到那个水平。现在而言 MQTT 只是一个方便设备和云端通信的一种标准，它提供了一种我们设备和云端的一致的通用语言，然而，MQTT 还需要我们去定义一些额外的文档，定义具体的读和写的属性，所以使用 MQTT 并没有让你从大量的工作中解脱。

Zigbee 和 Z-wave

同样从网络层开始，Zigbee 和 Z-wave 是大家都喜欢的网状网络的主要运营商。它们试图解决两个问题：提供一个合理的规范，将数据包从网格网络上的一个位置移动到另一个位置并建议如何组织这些包。所以，它们都在堆栈中向上延伸。例如，Zigbee 使用一种称为简档的系统，简档是功能的集合，例如智能能源简档或家庭自动化简档。当协议变得如此具体以至于说“这就是灯泡的功能”时，很难实现概要文件中没有的设备。虽然有自定义数据的规定，但在这一点上，您并没有真正使用交叉兼容的规范——只要您使用概要文件中未定义的设备，您就基本上脱离了标准。

这两种网络的另一个考虑因素是它们都是路由网状网络。我们使用一个节点通过中间节点与另一个节点通信。换句话说，我们可以将消息从 A 发送到 B、C 和 D，但实际上，我们已经将消息从 A 发送到 D。在路由网格中，每个节点都理解消息需要走的路径，并且与此相关的内存开销。而 Z-wave 和 Zigbee 在网络上的理论极限为 65,535 个节点(地址空间为16位整数)，实际极限接近几百个节点，因为这些设备通常是低功耗，低内存设备。路由也有时间成本，所以大型网状网络可能会对您的用例显示不可接受的延迟。另一个需要考虑的问题是，这些网状网络无法直接连接到互联网，这一点在推出云控制消费产品时尤为明显。网关、集线器、边缘服务器)与云通信。

最后一点需要说明的是，Z-wave 是一个单一来源的供应商——无线网络是由 Zensys 制造和销售的，所以你必须从他们那里购买。Zigbee 有一个认证程序，从 Atmel 到 TI，有多个无线电供应商。

蓝牙

你没法和蓝牙相关的电子产品进行数量比较，因为在仅在 2014 年就推出了 10，000 个基于蓝牙的 SKUs. 除了Wi-Fi，没有什么能与之相比。蓝牙最初是为个人区域网络设计的，最初的标准支持 7 个并发设备。现在我们有蓝牙低功耗(BLE)，理论上有一个无限的连接限制。BLE 在物联网挑战方面做了大量的优化工作。他们仔细观察了支持通信所需的能量。他们考虑了“低能量”的各个方面，不仅仅是无线电——他们考虑了数据格式、数据包大小、无线电需要打开多长时间来传输这些数据包、需要多少内存来支持它、内存的功耗是多少以及协议对中央处理器的期望，同时考虑了总的BOM成本。例如，他们发现无线网络每次智能在线1.5毫秒。这是很好的发现——如果你传输的时间更长，组件就会发热，因此需要更多的能量。他们还发现纽扣电池比连续电池更擅长在短时间内供电。此外，他们对其进行了优化，使其真正耐用，不受无线干扰，因为协议共享相同的无线电空间(2.4千兆赫)。

然后 CSR 出现了并通过蓝牙实现了网格标准。利用 BLE 提供的所有优势，然后获得网状网络的所有优势。蓝牙网格是泛洪网格，这意味着不是特定的节点路由，而是在所有节点之间不加区分地发送消息。因为没有内存限制，所以这比路由网格缩放得更好。对于物联网中的许多问题来说，这是一个很好的解决方案，大规模实施可能是最低的成本。

Thread

Thread 是一种正在兴起的标准，它建立在为 Zigbee 无线电提供动力的硅的基础上。它通过添加 IPv6 支持解决了网格节点无法直接与云通信的问题，这意味着网络上的节点可以发出完全合格的 internet 请求。这一标准背后有很大的分量。谷歌似乎认为在其上创建自己的协议(称为 Weave)已经足够有趣了。然后是 Nest Weave，这是谷歌编织的另一种版本。按照目前的情况，要让一个标准真正站稳脚跟需要很长时间，您可以立即看到使用 Thread 的情况有多么混乱，这不利于采用它。这也解决了一个问题，所以使用的设备很少。让我们以传感器为例。这些低功耗、轻量级、低成本、低内存、低处理、相当哑的设备需要直接发出互联网请求吗？有了线程，每个节点现在对世界有了更多的了解——例如，您的服务器在哪里，也许它们不应该关心这些事情，因为不仅设备的需求增加了，而且现在必须在现场更新它们的概率和频率也大大提高了。当涉及到实际的传感器和其他端点时，从哲学上讲，您希望将这些责任最小化，除非在需要离线耐久性、本地处理和决策制定的特殊情况下(这称为雾计算)。

当 Thread 去年宣布他们的产品认证时，只有 30 个产品提交。关于线程的采用，需要注意的另一点是网格 IPv6 问题以前已经解决了——实际上蓝牙4.2 中有一个规范将IPv6路由添加到蓝牙中，但是很少有人使用它。尽管北欧半导体公司认为这将是一件大事，并首先着手实施，但它在行业中并没有出现太多。

Thread 确实有一个优势，那就是它不再定义设备如何相互通信，以及设备如何格式化它们的数据——这样做可以让它成为未来的证据。这就是Weave的作用，因为它确实假设了数据应该如何构造。所以基本上，一种看待它的方法是 Weave + Thread = Zigbee/Z-wave 竞争对手。除了 Nest 之外，我们还没有看到谷歌以外的任何人真正在 Weave 上采取主动，他们已经做出了很好的营销努力，让它看起来像是在吸引他们。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

如果你需要这些资料，可以戳这里获取