系统更新曾经相对简单直接。当开发者需要修改已经发布给公众的内容时，会发布一个更新程序供人们运行。用户运行更新程序，旧文件被新文件替换，并添加新文件。然而，即使是这些“相对简单直接”的更新，也存在一个问题。当用户的安装处于意外状态时会发生什么？当升级中断时会发生什么？当今各种设备都在线，有时需要重要的安全更新，这些问题仍然非常重要。如今，许多更新都是通过无线、空中下载 (OTA) 方式交付的，连接不良、信号突然丢失或电源丢失的可能性可能会对本应是小更新的内容造成灾难性影响。以下是在计划交付空中下载更新时需要考虑的三个最重要的策略。
1. 验证
TCP 协议内置了很多验证机制，因此通常情况下，当您向设备发送数据包时，您可以确信每个数据包都已完整接收。但是，TCP 无法报告它不知道的内容的错误，因此您需要验证以下事项：
-
您是否已发送更新所需的所有文件？设备无法接收未首先发送的内容。
-
接收到的文件是否与您发送的文件相同？至少，检查 SHA 校验和以验证文件完整性。
-
如果可能，请使用数字签名以确保文件来自可信来源。
-
在允许更新开始之前，您必须验证设备是否能够应用更新。在提交更新之前，检查权限和电池状态，并确保您的更新过程覆盖任何意外的用户事件，例如计划的重启或休眠。
-
最后，您必须验证声称已成功完成的更新是否真的已完成。在允许系统正式将更新标记为已解决之前，检查目标设备上的文件位置和完整性。
2. 回退和故障状态
更新的最坏情况是设备处于损坏状态，以至于它甚至无法用于继续中止的更新。在这种情况下，更新程序文件存在于目标设备上，但进程已中断。这可能使设备处于未知状态，其中某些文件已被更新版本替换，而其他文件尚未触及。在最坏的情况下，已更新的文件与尚未更新的文件不兼容，因此设备无法按预期运行。
有几种策略可以处理这种情况。初始更新步骤可以是安装一个专用的引导镜像或环境来完成更新，并在系统上设置一个“标志”以表明更新正在进行中。这确保了即使设备在更新过程中突然断电，更新过程也会在下次启动时重新开始。“标志”指示更新成功，只有在更新经过验证后才会删除。
特殊的引导镜像可能不可行或不必要，具体取决于目标设备的安全策略以及您要更新的内容。但是，原理仍然相同。一旦更新开始，它必须建立一个环境，在该环境中，待处理的更新是唯一的前进方向，直到问题解决。
但是，在更新获得开始许可之前，用户（如果有用户）应该有能力延迟或忽略更新。
3. 增量式
在许多边缘和物联网设备中，目标设备的基础是不可变的。更新仅添加到系统的已知状态。像 Fedora Silverblue 这样的项目正在证明这种模式可以在许多市场中发挥作用，因此奢侈品可能会变得司空见惯。但在那之前，成功应用更新的一部分是了解您即将影响的环境。
但是，您不需要不可变的核心来应用增量更新。您可能能够设计一个系统来使用相同的概念，使用更新作为添加库或包的方式，而无需修改旧版本。作为此类更新的最后一步，具有更新路径的可执行文件是您进行的唯一实际修改。
OTA 更新
世界正在变得越来越无线化。对于手机、物联网设备和边缘计算，空中下载更新通常是唯一的选择。实施 OTA 更新策略需要仔细的计划和对不太可能发生的情况的仔细考虑。您最了解您的目标设备，因此在开始编码之前，请先规划好您的更新模式，以便您的初始架构设计用于稳健且安全的 OTA。
1 条评论