感覺我們公司的產品是不是可以引入這種升級方式？
轉自http://impd.tencent.com/?p=27

直到Windows 8 之前，微軟都沒有像蘋果的一樣提供一個AppStore，所以在這個平臺上開發和使用軟件都是有一定門檻的：對于普通用戶而言，專門跑去電子市場買一套辦公或者娛樂軟件的光盤并不是所有人都喜歡的事情，而即使是軟件發展環境不太健康的中國市場，到各大軟件網站下載到無毒的軟件也不是一件容易的事情。

對于開發者而言更是如此，不僅要考慮完成軟件開發所預期的各種功能，還要處理諸如打包、防破解、注冊流程等等一系列的附加工作，這些事情對于所有運行于Windows平臺上的軟件都會遇到，它們的解決方案也大同小異，但Windows并沒有幫助開發者們處理這些問題。

我們今天要討論的一個主題——“升級”，也涵蓋在其中。如果您有多年使用Windows操作系統的經驗，那么應該會發現一個現象，目前的常用軟件都是這樣升級的：在幫助菜單中放置一個叫做“軟件升級”的菜單項，點擊后便會啟動一個查詢最新版本的loading界面，一旦查詢到新版本，便會提示用戶是否要下載并安裝。

這個功能的實現邏輯非常簡單，但對于很多需要持續運營的軟件而言，它是一個重要的“生命線”。因為只有讓用戶感受到這個團隊的努力，這個團隊才有維系下去的意義，而這就需要用戶能夠通過升級拿到新的版本。

然而，即使很多團隊將“查詢是否是最新版本”這個邏輯做成了軟件啟動后的“第一要務”，依舊只有一部分熱心用戶會選擇點擊“確定”按鈕，我們來看看他們的顧慮：

（1）    新功能我都用不上，沒有升級的必要。

（2）    新版本可能不穩定。

（3）    我是盜版用戶，升級了，破解補丁就無效了

（4）    升級一次下載一個很大的安裝包，要等很久，還要安裝，太折騰了。

前三個問題對于不同的產品都沒有通用的解決方案，相比于技術的問題，它們更像是產品本身的定位問題，或者開發團隊的素質問題，需要具體情況具體分析。但是對于第四種情況，的確是技術人員可以嘗試去挑戰的。

 【安全補丁】

記得就在幾年前，整個中國的網絡環境遠沒有現在那么舒適，當時除了部分高校內部的校園網有比較高的速度，1M bps的“小水管”還是占絕大多數。我們姑且稱這個時間段為“窄帶時代”，一個在線看視頻只能依靠P2P加速的時代。

而與龜速的網絡不相協調的是，安裝包的體積往往都是十幾兆甚至幾十兆，在這個環境下，等待一個新版本安裝包的下載完成是非常考驗耐心的，相信我們絕大多數人都有在緩慢的downloading界面點擊“取消”按鈕的經歷。

看來，簡單的下載新版本安裝包并執行安裝流程的方案，只適應于忠誠的用戶和特定的場景，那我們來關注下微軟的開發團隊采用了什么辦法？要知道Windows操作系統的開發團隊每天都會接到不止一個有關Windows的安全漏洞，而這些問題的修復不僅僅頻繁，而且緊急。

面對帶寬占用和安裝耗時的問題，微軟采用了安全補丁的辦法：所謂的安全補丁，本質上就是攜帶新邏輯一個或多個新版本程序文件，比如原來abc.dll中暴露了一個緩沖區溢出的漏洞，那我們就發布一個已經做過保護的abc.dll 2.0版，包裝成可以獨立安裝的安全補丁，然后下發給用戶，在用戶重啟Windows操作系統時完成替換（Windows在真正的初始化完成后，是很難替換其系統文件的，因為系統要面對占用問題，緩解的方法之一是hotfix技術，但是絕大多數場景下，依然需要用戶重啟后安裝）。

這個過程看似簡單，而且體積苗條的安全補丁不會在下載和安裝上浪費什么時間，按理來說是個很理想的措施。但實際在運營中卻是代價巨大的，甚至不是一般的團隊可以承擔的起的：

首先，一個足夠復雜的軟件，其各個模塊之間的關系必然是很緊密的，2.0版本的abc.dll往往需要一個2.0版本的“ddd.dll”、“eee.dll”… 除非一個dll中封裝的模塊非常非常獨立，否則不可能存在一個dll可以隨意替換到以往發布的任何一個版本中。這就需要一個高成本的工作——“定制”。言下之意，如果一款軟件在服役期的版本多達十幾個，我們需要提供十幾個abc.dll 2.0版，給特定的外部版本推送特定的補丁。

其次，任何補丁的發布都需要嚴格的測試，一個版本的測試可能要花費若干天的時間，那么十幾個版本的測試呢？代價可想而知。（例如Windows開發團隊每發布一批安全補丁都需要幾周的內部測試和外部測試，所以有專門的團隊來負責此事，而且規模還非?？捎^）

圖1: 補丁升級

只需用戶一個確認，整個過程便在后臺慢慢地執行（誠然，不厭其煩的重啟提示確實有些騷擾），雖然這么多年來，微軟一直在維系著這種安全、有效并且易于被用戶接受的方案，但不得不說，對于一般的開發團隊，這套方案顯得過于昂貴了。

【保持最新】

但我們也不必拘泥于這樣一種思路，要知道，微軟采用對特定版本推特定補丁的做法是有著它自身立場的一些考慮的，比如：

（1）    微軟的補丁程序在執行邏輯上其實很復雜，遠不止單純的文件替換這么簡單，這是一個操作系統復雜到一定階段后的產物。但對于一般的應用軟件，簡單的文件比對和替換基本能滿足絕大多數場景。

（2）    微軟肯定不希望XP或者Vista用戶無緣無故的升級到Win7，但對于普通的免費軟件，或者購買license后可以享受終身升級的付費軟件，這件事情未嘗不可。

如果拋棄上訴的兩個包袱，那么我們現在就可以設計一個方案，一切的一切，都始于一個簡單的想法，讓用戶本地的程序文件跟隨服務器的最新版本，我們稱之為“文件保持最新”。而且，這個方案的思想非常的簡單，就是由客戶端程序將自己的版本號上傳給升級服務器，由升級服務器確定當前用戶版本到最新版本需要更新那些文件，將這些需要更新的文件組織成一個file-list下發給用戶，而后由客戶端在運行過程中將file-list中羅列的文件逐個下載到本地，并在下次啟動程序前完成替換。

如果再進行一些更細致的考慮，我們還要關注一些編譯上的知識，比如我們知道一個PE文件（dll、exe等）頭部會攜帶一些本次編譯特有的信息，比如時間戳等等，而對于升級而言，只有數據段和代碼段的變化才是我們關注的，所以在進行版本間的文件比較時，我們需要去除掉這部分的干擾信息。

下圖是對這個簡單想法的描述：

圖2: 保持最新的思路

這個方案看似比較合理，但是我們都清楚一個事實，現在Windows上的應用軟件千千萬，但沒有幾個是采用上述思想進行升級的，為什么呢？

因為這個方案太過于理想化了：一個軟件如果是基于類似C++的編譯型語言開發，那么即使過濾掉頭信息的變化，兩個不同版本的程序文件也沒有多少是相同的，甚至一個都沒有。要解釋清楚這個現象，我們也要像上面一樣，再關注一些編譯和鏈接上的知識：

我們來看引發一個PE文件的差異的原因，其實主要源自三種因素（詳情可以參考http://www.daemonology.net/papers/bsdiff.pdf）：

（1）    頭信息變化：上面以及提及，這是編譯器每次生成二進制文件時都會參雜進去的信息，剛才也說了，這種信息很好規避。

（2）    代碼的變化：你修改了一個Project中的部分代碼，那么反映到二進制PE文件中就會有一段明顯而集中的差異。這是不可避免的。

（3）    間接的影響：我們知道編譯出的PE文件中有大量的信息是絕對的地址，如果你改變了一個指針的指向，那么所有引用這個指針的地址都會發生變化，好吧，你要接受一個事實：一行代碼的變化會被編譯器嚴重放大，而且一個PE文件的變化可能并非源自于這個Project自己的源代碼差異。

如果是一個由幾百萬行代碼組成的龐大系統，單單組成它的Project就多達上百個，各個模塊之間的依賴關系異常復雜，那么上面提及的第三種差異（即間接的影響），在決定程序文件的差異度上的作用就會被無限放大。

也就是說，如果采用這種方案，一個普通的應用軟件一次升級可能需要耗掉100M以上的帶寬。雖然最近幾年中國的網絡環境越發舒適，但我們都清楚，這個數量級還不是我們能夠接受的。所以我們可以回答剛才那個問題了“為什么沒有幾個軟件是采用上述思想進行升級的”。

【差間壓縮】

    稍微對軍事略感興趣的朋友都知道，20世紀最具創新意義的軍事武器，都是誕生于二戰后期，戰爭的需求極大地推動了技術的進步。同樣的，現代互聯網的很多需求也不斷地催生著技術的進步，比如說——游戲。

大型網游其實一直都面臨著類似的問題：首先，游戲資源文件大多是被打包在一起并進行加密的，尤其是3D網游，它們的資源包動輒過G。而另一方面，為了增加游戲的互動性已經節日活動，頻繁的更新也必不可少，那總不能每次升級都強迫用戶下載上G的更新文件吧？

安全的要求和運營的壓力本就矛盾，但技術團隊找到了一個“曲線救國”的方案，那就是不再只盯著一個個文件，而是縮小比較的粒度，將文件的差異縮小到Bit級，直接關注二進制差異。同樣的思路也可以被搬到這里：

如果一個DLL文件在前后兩個版本的迭代中發生了變化，那么肯定不是每個Bit都發生了差異，而只是其中一些Bit有所不同。如果我們將這些差異提取出來，做成二進制Patch，那么只需要由升級服務器向客戶端下發這些Patch，那么客戶端自己就可以根據這些Patch以及舊文件“合成”出新版本的文件。

如果一個5M的DLL發生了差異，往往只是因為修改了其中的一行代碼，那么使用上面的思想，我們就可以只產生一個不到1K的差異Patch，將其下發給客戶端，由5M到1K，我們節約了99.98%的帶寬。

圖3：將粒度縮小到bit

那么如何實現呢？

其實方法有很多，但是目前最普遍適用的是一種稱為“滑動比較”的方案，簡單用圖描述一下其思路大致如下：

圖4：滑動delta算法

上面說的這種思路，在計算機領用被稱之為“delta壓縮”，或者“差間壓縮”，比較典型的例子就是視頻壓縮領域的幀間差量，第二幀只保存較第一幀中變化的部分。

【PE文件】

但是對于PE文件，問題又出現了，地址變動引發的差異往往會稀疏得散落于整個文件的各個部分。（最壞的情況下，公共頭文件中一行代碼的改動，可以在最終生成的二進制文件中產生多大10%的差異。）仔細用Beyond Compare比對一下兩個版本的DLL文件，你會發現，每隔幾十個字節，一個地址變了，又過了十幾個字節，同樣的地址又變了。所以“滑動匹配”的方案又不適用，因為采用這種方法算出來的差異補丁往往不比實際文件小多少。

圖5：PE文件的差異

這個問題其實是方向性錯誤，還記得上面提到的PE文件差異原因時的第三類差異嗎？我們用了精確匹配的思想去對付一個不能精確比對的問題，就好像基因工程中的相似度比較，人和黑猩猩的基因差異可能不到1%，但是這1%的差異是散落于23對DNA的各個片段中。

圖6：尋找其中的規律

我們仔細看一下上面【圖6】中二進制變化，就會發現這里似乎存在著一些規律：

• 近似區域的差異源自指針地址的變遷
• 指向同一地址的指針會發生同樣的變化
• 臨近地址往往發生攜同性質的變化

于是乎，我們的算法需要對這些問題進行分類處理了。換句話說，由于代碼變化引起的二進制差異可以作為一類進行處理，因為這些差異即集中又明顯。而由于指針偏移間接引起的差異則要統計的收斂起來，這些差異往往都是同質的，往往幾十處的二進制差異源自一個指針的跳變。

圖7：分而治之的處理

如何在一段二進制程序段中尋找出這些差異并進行合理的壓縮，這個需求非常迫切，而且已經有了成熟的方案：

• BsDiff: Linux中的一個開源工具，致力于快速和輕量的更新Linux的操作系統漏洞（跟微軟的安全補丁類似），其算法的核心思想是基于統計學規律進行近似匹配，然后通過一系列的變化(比如BWT變換)提高“近似段”的壓縮率。
• Courgette: Google Chrome升級系統的核心模塊，基于BsDiff，但對其進行了一系列的改進，將平臺相關的信息（即x86匯編指令）融入其中，以期望更精確的定位指針，從而避免統計算法在差異明顯時候的錯誤率。

上述兩個模塊的內部原理還是很有意思的，前者是典型的學術思維，后者則是集大成的工程師風范，但為了避免打消您閱讀完此文的動力，我會在稍后的文章中再做補充。

如果不考慮跨平臺問題，毫無疑問Google的Courgette是做得更加優秀的，下面是根據Chrome團隊官網（http://dev.chromium.org/developers/design-documents/software-updates-courgette）上提供的統計數據制作出的圖標：

圖8：不錯的帶寬節省

由于二進制差異對帶寬的節省非常驚人，所以用戶通過很低的帶寬耗用下載到一個升級包，整個過程可以盡可能地減少對用戶的騷擾。比如在用戶在使用Chrome瀏覽器時，可以無感的升級到最新版本，盡可能地避免自己的瀏覽器漏洞不被非法網頁利用。

最重要的是，由于整個補丁包的制作過程基于統一的算法，所以整個過程可以進行自動化的收攏，從而將人從其中解放出來。即互諒網上存在該軟件很多不同的版本，但我們省去了最開始提到的為每個版本定制不同補丁時的重復工作，一切交給計算機來自動完成。

【回顧總結】

話題到這里基本就結束了，總的來說，本文概括了幾種常見的客戶端軟件升級方案，它們在實現方案上各有不同，但都為是為了解決某一問題而誕生。如所有的領域一樣，計算機這個領域的技術的進步就是在一次又一次的挑戰中不斷前進，不斷去嘗試，在各種苛刻的需求和棘手的問題面前不斷進化，才最終鑄造了我現在這個偉大的時代。