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

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

1. 驗證

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

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

2. 回退和故障狀態(tài)

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

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

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

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

3. 附加更新

在許多邊緣和物聯(lián)網(wǎng)設(shè)備中，目標(biāo)設(shè)備的底層是不可變的。更新只會添加到系統(tǒng)的已知狀態(tài)。 Fedora Silverblue 之類的項目正在證明這種模式可以在許多領(lǐng)域發(fā)揮作用，因此這種奢侈的做法可能會變得司空見慣。不過，在那之前，成功應(yīng)用更新的一部分是了解你將要影響的環(huán)境。

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

OTA 更新

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