過去對系統的更新相對簡單。當開發人員需要修改他們已經分發給公眾的東西時，會發布一個更新程序供人們運行。用戶將運行更新程序，允許用新文件替換舊文件并添加新文件。然而，即使有了這些“相對簡單”的更新，也有一個問題。當用戶安裝好的系統處于意外狀態時會發生什么？升級中斷時會發生什么？當各種設備都在線時，這些問題同樣重要，有時需要重要的安全更新。

今天的許多更新都是通過無線、空中下載技術（OTA）的方式提供的，連接不良、信號突然丟失或斷電的可能性可能會對應該是次要更新的內容造成災難性的影響。這些是你在計劃提供 OTA 更新時需要考慮的三大策略。

1. 驗證

TCP 協議內置了很多驗證功能，因此當你 向設備發送數據包 時，通常可以確信每個數據包都已完好無損地收到。但是，TCP 無法報告它不知道的錯誤，因此由你來驗證以下內容：

• 你是否已發送更新所需的所有文件？設備無法接收沒有發送的內容。
• 收到的文件和你發送的文件一樣嗎？至少，檢查 SHA 和以驗證文件完整性。
• 如果可能，請使用數字簽名 確保文件來自受信任的來源。
• 在允許更新開始之前，你必須驗證設備能夠應用更新。在提交更新之前檢查權限和電池狀態，并確保你的更新過程覆蓋任何意外的用戶事件，例如計劃的重新啟動或休眠。
• 最后，你必須驗證聲稱已成功完成的更新是否已實際完成。在將更新正式標記為系統已完成之前，請檢查目標設備上的文件位置和完整性。

2. 回退和故障狀態

更新的最壞情況是設備處于損壞狀態，以至于它甚至不能繼續被中止的更新。在這種情況下，更新程序文件存在于目標設備上，但該過程已被中斷。這可能會使設備處于未知狀態，其中一些文件已被更新版本替換，而其他文件尚未被替換。在最壞的情況下，已更新的文件與尚未更新的文件不兼容，因此設備無法按預期運行。

有一些策略可以解決這個問題。初始更新步驟可能是安裝專用于完成更新的特殊引導鏡像或環境，并在系統上設置“標志”以確認更新正在進行中。這樣可以確保即使設備在更新過程中突然斷電，更新過程也會在下次啟動時重新啟動。僅在驗證更新后才刪除表示更新成功的標志。

根據目標設備的安全策略和你要更新的內容，特殊的引導鏡像可能不可行或不需要。不過，原理還是一樣的。當啟動后，更新必須建立一個環境，在這個環境中，待處理的更新是解決問題之前的唯一途徑

但是，在更新被授予啟動權限之前，用戶（如果有的話）應該能夠延遲或忽略更新。

3. 附加更新

在許多邊緣和物聯網設備中，目標設備的底層是不可變的。更新只會添加到系統的已知狀態。 Fedora Silverblue 之類的項目正在證明這種模式可以在許多領域發揮作用，因此這種奢侈的做法可能會變得司空見慣。不過，在那之前，成功應用更新的一部分是了解你將要影響的環境。

不過，你不需要不可變的核心來應用附加更新。你可以構建一個使用相同概念的系統，將更新作為添加庫或包的一種方式，而無需修改舊版本。作為此類更新的最后一步，具有更新路徑的可執行文件是你所做的唯一實際修訂。

OTA 更新

世界越來越無線化。對于手機、物聯網設備和 邊緣計算，OTA 更新通常是唯一的選擇。實施 OTA 更新策略需要仔細規劃并仔細考慮不可能的情況。你最了解你的目標設備，因此請在開始編碼之前規劃好你的更新架構。