Thread：让智能家居工作更稳定的数据包搬运工（系列文章之二）

按：本文是少数派会员专属内容，最初发布于 2022 年 8 月。随着 Matter 技术正式推出、获得广泛支持，Matter 设备选购和使用也受到很多关注。为此，我们将本文重新发布在首页，以便读者更好地理解 Matter 技术所使用的 Thread 协议是怎样运作的。

少数派新版会员自 2022 年夏季上线以来，已经积累了数十万字的优质内容；我们还于近日为年度会员上线了测试版的会员社区，可以直接通过少数派 iOS app（web 版即将上线）与志趣相近的朋友交流。如果你对与本文类似的内容感兴趣，请考虑进一步了解并加入少数派会员。

在上一篇文章中，我们简单地对 matter 所使用对用的通讯协议做了简单的科普。但作为数据包的搬运工，通讯协议很大程度上决定了智能家居设备的稳定性和相应速度。蓝牙和 Wi-Fi 相信大家已经非常熟悉了，而 Thread 相对于我们更加陌生，因此在本篇中我们会详细介绍并且剖析 Thread 协议的运作机制。

Thread 是什么

Thread 的物理层基于 IEEE 802.15.4，而 IEEE 802.15.4 又是一种低功耗和低传输速度的网络协议。因此，低功耗和低传输速度就是 Thread 的两个主要特征。

普通读者可能对于网络背后的技术细节可能没那么了解，直接说 Thread 背后的技术细节反而更不好理解，所以这次我们打算从智能家居的特征入手，反推 Thread 背后的优势。

首先很多的场景中的智能家居，最大的要求就是保持低功耗。小到传感器，大到控制开关，它们的都不能依赖于市电，否则部署场景就会受到很大的限制；而且经常需要更换电池也会降低传感器和控制开关的可靠性。所以使用 Thread 的设备可以保持在一个较低的功率上，但低功耗不意味着只能部署在电池供电的设备中，可能很多读者朋友已经拥有的 HomePod mini、Apple TV 4k（2021）以及 eero 路由器都已经内置了 Thread，关于这一点我们会在文章的下半篇展开。

其次，智能家居的数据交换量并不大，绝大多数的数据交换都是把几个属性的数据传递到设备上，因此相比于能传递更大的数据包，更快更稳定更针对性地传输反而更重要。

但在 Thread 之前，我们其实已经有其他的低功耗协议了，其中最具有代表性且相对成功的两种分别是：蓝牙 mesh 和 Zigbee。

三种协议都可以简单地分为三层：应用层、网络层和射频层（物理层）。为了方便没有网络基础的读者朋友正确理解这三层，我们可以继续使用上一篇文章中的那个寄快递的例子：

物理层，定义的是快递运送的方式，一个包裹可能是由自行车、汽车运送的，也可能是由飞机、火车运送的。

而网络层，就是负责运输包裹的快递公司，不同的公司对于快件的处理和方式都不一样，寄送不同大小的包裹效率上也有区别。其他的快递公司也不知道这个快递公司的快递单号是怎么处理的，但不同的快递公司也可以使用相同的运送方式（物理层），比如上图中的 Zigbee 和 Thread 物理层是一样的。

应用层，则是包裹信件里面所用的语言，不同的语言也需要相应的使用者才能读得懂。

和蓝牙 Mesh 与 Zigbee 相比，Thread 并没有定义自己的应用层；换个说法就是 Thread 更加自由，开发者可以通过 Thread 来传输自己的应用协议，matter 就是其中的一种。

此外，Thread 并不止局限于 matter 作为应用层，其他比如 HomeKit 或者 Google Home 现在也在使用 Thread 来传输自己的应用层。而相比之下 Zigbee 和蓝牙 Mesh 定义了应用层之后，简化了开发的过程但是也限制了其使用范围。

不过需要特别注意的是，Thread 网络协议中是带有 IP 协议的，这意味着很多原本基于以太网的应用也可以轻松的运行在 Thread 网络中，不过这一部分本文不展开讨论。

Thread 网络

Thread 设备在被添加到家庭之后，会自动的和其他在家庭中同样适用 Thread 功能的设备自动组成一张 Thread 网络。

和其他 Mesh 网络一样，Thread 网络也拥有自愈能力；而这些可以自愈的网络，会在某一个节点掉线之后，仍然可以保证其他节点的连通性。

以往基于蓝牙 mesh 和 Zigbee 的协议都是需要对应协议的网关，一旦网关如果网关掉线之后，所在网络的设备也会相应掉线。

但 Thread 得益于它优秀的节点管理机制，可以在任何的关键设备掉线以后，依然保持整个网络的可访问性和健壮性。

节点分类

设备接入 Thread 网络后会根据自己的特性和可以承担的任务被大致分为Router（路由）和 End Device（节点设备）两大类。

路由在 Thread 网络中负责构建 Thread 主网络和转发信息，就和我们日常生活中见到的路由器相似，一个设备产生的数据也会由路由选择最高效、合适的路径发送给对应的设备。

节点设备在同一时刻只会和一个路由器相连，节点设备也只会通过和自己相连的路由发送或接受消息。

Thread 之所以在任何一个关键设备掉线以后依然能保证整个网络可以正常使用，是因为某一类的 Thread 设备可以在路由身份或者节点设备身份之间转换的，这类设备在 Thread 网络中被称为 FTD（Full Thread Device）。FTD 也往往使用市电供电，所以它们才能在需要时可以升级为路由身份，在不需要时也可以降级为节点设备身份；那些只能通过电池供电的设备，也就是只能扮演节点设备身份的设备，在 Thread 网络中被称为 MTD (Minimal Thread Device）。而 FTD 和 MTD 又可以被进一步划分出更多的子设备种类：

FTD 可以细分成三种类型：

• 路由：负责构建 Thread 主网络和转发信息，可以降级到节点设备
• 符合路由条件的节点设备（REED, Router Eligible End Device）：可以升级为路由，但是作为节点设备存在在 Thread 网络中。
• 完整节点设备（FED, Full End Device）：无法升级为升级为路由的节点设备，通常而言比较少见。

MTD 可以细分为两种类型：

• 最低限度节点设备（MED, Minimal End Device）：始终会打开自身收发器的节点设备，无需从路由器中轮询消息。
• 休眠节点设备（SED，Sleepy End Device）：通常会关闭自身的收发器（也就是睡眠状态）的节点设备，偶然会打开收发器（唤醒）以从路由器中轮询消息。

在一个 Thread 网络中，还有另外两种特殊的路由：主路由器（Leader Router）和边缘路由器（Border Router）。

主路由器

主路由器负责管理 Thread 网络中所有的路由器，Thread 为了提高容错率会动态选择一个路由器作为主路由器，负责汇总和分发全网络的配置信息。可以简单理解成，像 Mesh 路由器的主路由一样，管理着所有的 Mesh 节点。

不过，一个 Thread 网络里的主路由器并不是固定的，同一个 Thread 网络会不定期更换主路由器增加容错率。任何可以作为路由的 Thread 设备都可能被选举为主路由器。

边缘路由器

边缘路由器是一种可以在 Thread 网络和其他网络（如 Wi-Fi 和 BLE）之间转发信息的设备。前面提到过，不同的「快递公司」快递信息并不互通，这时就需要一个「第三方公司」将快递数据从一方同步给另一方，而这个「第三方公司」就是边缘路由器。

一个 Thread 网络中可以有多个边缘路由器，哪怕其中一个或者几个失效，也可以保证剩下所有 Thread 设备的可访问性。一个边缘路由器除了会支持 Thread 协议以外，往往还会支持 Wi-Fi、BLE 等其他通讯能力，这样即使是家庭中 Wi-Fi 出现了问题，依然可以通过 BLE 访问。

节点的升降级

为了保证最佳性能，单个 Thread 网络所支持的设备类型数量是有限制的，在 Thread 网络中 Router 的数量会根据网络规模动态调节以达到最大的覆盖度和最快的消息转发速度。

在一个 Thread 网络中，Thread 会尝试将 Router 的数量保持在 16 ～ 23 之间。如果一个 REED 作为 End Device 加入，并且网络中的 Router 数量低于 16，那么它将自动升级为 Router 以增加 Thread 网络的覆盖度以及路径多样性。

意外情况发生的时候，Thread 会如何处理

设备掉线：

• 其中一个普通的路由掉线，如果路由之间还可以建立连接，那么主路由器会建立新的路由表；如果中间有一部分无法通过现有路由建立连接，那么可以建立连接的 REED 会升级成 Router，保证 Thread 网络的连通性。
• 如果主路由器掉线，那么会选举出一个新的主路由器。
• 如果其中一个或者若干边际路由器掉线，那么会通过其他可用的边际路由器与用户设备或者局域网建立连接。
• 如果 Thread 网络的其中一部分无法连接到 Thread 主网络，那么这部分会重新建立一个新的 Thread 网络，并同时选举出属于新网络的主路由器，并通过边际路由器与其他设备或者其他 Thread 网络建立连接。当 Thread 链接恢复，两个拆分的 Thread 网络也会被重新合并。

断网：

• 广域网断开连接，完全不影响 Thread 网络或者是使用 matter 协议的智能家居的正常运行。
• 如果无线网络出现了问题，Thread 网络中会由支持蓝牙的设备作为边际路由器，与终端建立连接，Thread 网络依然可用。
• Thread 网络与局域网均出现问题，所有的 Thread 设备会转为蓝牙与连接终端，依然可控。

IPv6

除了细致的节点分类和和完善的网络管理机制之外，Thread 还使用 IPv6 作为其通讯基础。 IPv6是互联网的下一代网络协议，旨在取代当前的网络 IPv4 。为了通过互联网进行通信，计算机和其他设备必须有发件人和接收地址。这些数字地址被称为互联网协议地址。IPv6 具有大量的地址，也因此相比 IPv4 更加适合物联网设备，此外 IPv6 还提供了许多其他好处：

• 端到端路由和可寻址性：两个 IPv6 设备，无论是在同一 Thread 网格上，跨网络还是在世界各地，都可以通过直截了当且易于理解的互联网路由端到端通信，而无需借助网关进行转化。
• 易于管理：与 IPv4 网络不同，IPv6 网络本质上是自动配置，无需用户和系统管理员担心地址分配、DHCP 服务器等。
• 成熟和稳定：IP 网络已经非常成熟，开发者也可以很快上手开发 Thread 的应用层。
• 灵活：支持多种上层协议，包括 TCP/UDP 等等经典的网络协议

在 matter 中，所有 matter 设备都将使用 IPv6 进行通讯，因此以往智能家居系统中的「网关」这一概念也会被逐渐淡化，Thread 和其他 IP 网络的通讯只需要 Border Router 进行转发即可。使用 IP 通讯的另一个隐形优势则是相比非 IP 网络的协议，Thread 可以用传统 IP 网络中的 debug 方法排错，开发者可以自己的 PC/Mac 上直接确认 Thread 网络的情况。

低功耗协议对比

了解完了 Thread 网络的机制，我们可以看看实际 Thread 网络与现在市面上主流的低功耗网络协议的对比。

首先介绍一下传统的蓝牙 Mesh 网络（比如米家）与 ZigBee 网络（HomeKit）中的低功耗网络是如何传递信息的：

蓝牙 Mesh

如果你在手机上发出一个关灯的指令，在米家中这个指令会经过这段路径：

手机 --> 路由器 --> 米家服务器（处理信息） --> 路由器 --> 蓝牙Mesh 网关 --> 蓝牙 Mesh Flooding.......（泛洪） --> 灯（蓝牙 Mesh）

ZigBee

手机 --> ZigBee 网关（处理信息） --> Zigbee Routing --> 灯（Zigbee）

Thread

手机 --> Thread Border Router --> Thread Routing --> 灯（Thread）

Flooding 与 Routing

在介绍三种协议的传输方式的时候上面出现了两个新名词 Flooding（泛洪）与 Routing（路由）。Thread 和 Zigbee 都采用了路由的方式来转发信息。数据包会通过 Router 中记录的路由表，以最短的路径将数据包发送给子设备。

而与之不同的则是使用泛洪的蓝牙 Mesh。泛洪的信息转发与路由不同，一个数据包会被逐级广播出去，接收到信息包的设备发现自己不是信息包的接收者，则会继续广播，直到传达给目标设备。当然蓝牙 Mesh 也提供了有限路由的方式，只不过需要用户自行设定，较为繁琐，本节不展开讨论。

简单的说，泛洪就好比所有的人都拿着一个大喇叭。从信息源头开始用喇叭告诉附近的人需要做什么，附近的人听到这个消息之后发现并不是针对自己的，就又拿起喇叭告诉自己附近的人，如此重复直到告诉消息的目标。

而路由则更有效率一些，信息源从一开始就会记住所有设备的位置和传递信息的最短路径。当有指令发出的时候，会仅告诉最快能传递信息的人，同样网络里面剩下的设备也一样，每一条消息都有固定的传递路径。

细心的读者可能已经发现了，路由相比于泛洪要高效很多，但是与之对应的负责路由的 Zigbee 和 Thread 的性能也相应提高，不仅要在存储中记录路由表，还需要计算最佳路径；而蓝牙 Mesh 对性能的要求则低很多。

两者相比路由在效率上、延迟、开销、带宽上都远胜于泛洪。泛洪也因为路径不固定的关系，无法准确控制消息传递给设备的时间因而无法做到设备之间的完全的同步。但是使用 Routing 所要求的芯片性能则远高于 Flooding，与之相对应的是成本和售价的提升。

Thread vs ZigBee vs Bluetooth Mesh

而从性能上讲，Thread 在实测中也远胜于 Zigbee 与蓝牙 Mesh，这里有一份来自于 SiliconLab 的关于三种协议对比的报告。

前面提到过，智能家居的数据交换量并不大，但对延迟和同步率很敏感。通常来说，操作智能家居之后，如果设备的响应时间在 200ms 以内，属于很难感知的延迟。当然这一延迟不仅仅是低功耗协议的传输延迟，也包括了局域网，广域网，以及信息处理的时间。

这组数据展示了不同大小数据包在经过四跳（也就是数据包的四次转发之后），三种协议的延迟。可以看到数据包大小达到 130 字节的时候，通常是一个温湿度传感器回报的数据，Thread 的延迟不到 100ms，而与之相对的蓝牙 Mesh 则有高达 800ms 的延迟，并且在应用层的设定上，蓝牙 Mesh 也无法传输体积更大的数据包。

而在小规模网络中传输 50 字节的数据包，Thread 的延迟低并且分布集中，ZigBee 做到了不错的集中性但是延迟稍高，集中性越好也就代表同步率也好。而蓝牙 Mesh 的延迟时间则分布在了各个区间中，很有可能出现下图的情况。

延迟分布所带来的最直观的感受就是多设备操控的同步性，Thread 的延迟分布较为集中，给用户带来的观感就是设备之间是完全同步的。而相对而言蓝牙 Mesh 则更会展现出设备逐一开启的体验。

而放到极大规模的网络中，Thread 也依旧保持了上述优点，依旧保持着较低的延迟与集中的延迟分布。此时蓝牙 Mesh 的延迟和分布已经达到了不可用的程度。

总结

本篇我们介绍了 Thread 协议，简述了其运作机制和性能优势，并且分析了各类状况下的应对措施。Thread 协议的先进不仅体现在延迟低上，还有极高的稳定性和容错率，不过作为用户无需担心 Thread 中复杂的节点分类和运作机制，所有的组网连接完全不需要用户手动参与。相比过去的低功耗设备添加流程，使用 Thread 协议的设备甚至不需要去为了他们专门购买网关，用户只需要按照 matter 的设备添加流程添加使用 Thread 通讯协议的设备就可以享受到 Thread 带给用户的所有便利了。

在刚刚的时间点，Thread 也发布了其 1.3 版本宣布了对 matter 的支持，不同厂商的 Thread 设备比如 HomePod mini、eero 6 系列路由器，以及 Nest Hub 等等，现在可以在同一个 Thread 网络中协同工作。

看完文章之后，相信你也对 matter 为什么会选择 Thread 作为其低功耗通讯协议有了些许了解，我们不妨在这里再做一个总结：

• Thread 使用 IPv6 作为网络通讯协议，和以太网与 Wi-Fi 设备保持了一致性降低了开发难度。
• Thread 并没有定义应用层，这让 matter 与 Thread 可以良好兼容。
• Thread 基于 802.15.4 低功耗协议，适合各类低功耗 IoT 设备。
• Thread 具有响应速度快，并且具有高健强性，在各种极端情况下都可以保证用户对设备有良好的控制能力。

作为 matter 协议首推的通讯协议，普及 Thread 无疑会让当前智能家居的体验得到极大的提升。而下一篇我们会着重剖析 Thread 传输的包裹—— matter 的运行和安全机制。

关联阅读：The New Wireless Thread Network Protocol - Technical Articles