今天，Windows 11 系統獲得了首個補丁星期二活動日發佈的累積更新。 考慮到 Windows 11 系統才在 10 月 5 日發布，因此該累積更新的幅度並不大，只是修復了一些相容性問題，似乎也沒有引入什麼新的問題。 但如果你仔細觀察的話，你就會發現該累積更新的安裝速度要比 Windows 10 快了很多。

Windows 是一個用於全球各種環境的操作系統，特別是在這個混合環境中，每個人可能無法獲得最快的互聯網連接，但仍然需要通過安全補丁保持保護。 這就是為什麼補丁必須是小尺寸的，尤其是每月的累積更新包含了所有以前發佈的修復程式。

Windows 10 Version 1809 及以上功能更新採用了正向和反向差分壓縮（forward and reverse differential compression）。 它確保操作系統在服務時可以恢復到其基本版本作為中間狀態。 正如你可能注意到的，雖然正向和反向差分是對稱的，但它們的特點是內容非常不同。

微軟沒有利用雙向差分，因為一些轉換和補丁可能會刪除反向差分所需的數據。 為了確保非破壞性的轉換，反向 delta 首先需要存儲由正向 delta 增加和刪除的內容。

但由於內容上的不銜接，這個過程將不是很有效，至少與成對的正向和反向差分壓縮相比是這樣。 你可以在這裡的微軟白皮書中找到關於這個過程的更多細節。

在 Windows 11 系統中，微軟使用了反向更新數據生成（reverse update data generation）的方法，對這一過程進行了重大改變。 這是一個看似簡單和直觀的方法，它觀察 delta 指令，然後直接逆轉它們，而不經過成對的 delta 反向通道。 然而，在後端，這構成了一個重大的後端變化，它使用一個映射表來映射彙編代碼功能中的結果變化。 微軟解釋說。

映射的工作原理是對程式的彙編代碼進行逐個字節的反彙編，並確定虛擬位址。 虛擬位址在邏輯上對應於彙編代碼功能的入口點，並在彙編代碼被修復更新時發生轉移。 這些移動被 delta 引擎觀察到，並被一個映射表所捕獲。 關於 delta 應用的映射過程使這些變化的位址正常化，這也是現代架構上開明的 delta 演算法如此高效的很大一部分原因。

與基本的修補指令一樣，這些轉換可以被”觀察”和逆轉。 由於不是所有的映射都是 1：1 的，所以有一點開銷，當前向映射與觀察到的反向映射衝突時，必須使用額外的修補指令來對齊映射。 這可以在原地完成，反向映射將提供與反向 delta 幾乎相同的性能，其直接映射來自伺服器上完成的 delta 生成。

微軟聲稱，其反向更新數據生成方法使 Windows 11 更新的大小減少了 40%。 該公司表示，它在幾個月前還為這種方法申請了專利。 微軟是否會將這種技術也回傳到 Windows 10，還有待觀察。