前陣子，百度網盤提供免費申請100G空間，當時一則出於好奇，二則自己移動硬盤由於使用了BT，悲催的經常出現報錯，就想借此機會將文件傳到百度上暫存下，騰出空間好好整理下移動硬盤，就也弄了一個帳號。100G，加上原來的5G，一共105GB到手，正好今天有時間，就准備將移動硬盤數據拷貝上去了。打開百度雲-網盤之后，出現下面圖：
注：此圖片來源網上，本地的截圖由於已經使用了極速控件，沒法操作。
下載安裝之后，就是個IE插件，然后我們來體驗下吧，體驗截圖如下：
前三個文件，狀態開始是文件比對...，而后，立馬上傳成功，果然秒傳啊，心想要按這個速度，上傳所有的文件基本上就是分分鍾的事情啊，結果，在第四個文件的時候，它開始慢悠悠的給我上傳了，速度穩定在60Kb左右，汗！這速度，要傳完所有的文件，那是得猴年馬月？這也算極速秒傳。石化片刻之后，我終於明白它這極速秒傳是怎么個一回事了。在讓我下載的插件無非就是個HASH工具，然后將我本地文件和服務器已有文件進行比對，如果有，就直接使用服務器文件 —— 這就是秒傳！ 沒有的文件，就慢悠悠的給你上傳。
好吧，如果按照他這個秒傳的概念，我們也非常容易的實現秒傳功能，就一個文件HASH嘛。那趁着現在還在上傳這檔口，來自己設計一個簡單的秒傳架構吧。
原理篇：
要實現秒傳，最核心的就是建立服務端與客戶端的文件比對功能，這個比對當下可以用的有MD5這樣的算法或者其他HASH算法。其步驟如下：
1. 讓用戶下載客戶端，這個可以是瀏覽器插件，也可以是客戶端軟件 —— 百度這里是IE插件；
2. 在文件上傳之初，將本地文件進行HASH計算，得出文件指紋；
3. 將文件指紋數據上傳到服務器；
4. 服務端將文件指紋和現存的文件指紋進行比對，並返回比對結果給客戶端；
5.客戶端獲取比對結果；
6. 如果是比對成功，則說明服務端已經有同樣的文件存在，則直接將文件名和指紋及文件標識符一並上傳到服務端，而服務端在接受到之后，只是將文件名存放在客戶的名下，文件則是映射到原有文件的路徑中，返回秒傳成功信息；
7. 如果比對不成功，就變得和普通上傳並無二致，老老實實的通過HTTP的方式，將文件1比特，1比特的上傳到服務端。
好吧，這就是玄乎的文件秒傳了。至於為什么要4GB的限制，這個個人初步認為是因為指紋計算也是需要消耗資源，如果文件過大，在計算指紋的時候，其占用資源也會相對較多，可能會造成一定的影響。真相具體為什么，還有請懂行的指點。
優勢：
1. 對於服務端：進行文件的服務端比對，而后進行文件映射的這種方式，對於大型的存儲來說，由於在服務端只存在一份文件實體，因此，對於系統的存儲消耗將能極大的降低。特別是在文件數量達到海量，並且有很多重復文件時（多用戶各自保存文件時），其效果更佳。
2. 對於傳輸的帶寬：對於用戶來說，由於服務端的海量文件，自己傳輸的如果是其中已存在的文件時，能夠極大的降低帶寬的占用情況。
劣勢：
由於要實現秒傳，並達到最優的效果，核心是要求服務端保存海量文件，而且及時所有用戶將文件刪除，服務端為了在下次實現秒傳，都必須將文件保存在服務端，而不能進行刪除。如果未被映射的文件數量巨大，這勢必會增加存儲成本。
隱患：
也許秒傳給客戶帶來了便利，讓我們感覺良好。但我們從秒傳的原理中也不難發現其中的隱患。由於文件必須在服務端保留，因此，如果你傳輸到服務端的文件包含隱私，那么，一旦上傳完成，你的隱私就永遠的存在於服務端了，這就很難保證你的這些隱私在將來不會泄漏。如果真要使用這么一些個服務的時候，我們需要仔細的分析其中的風險。並且做出必要的決斷。 —— 至少，在我看到這個功能之后，我當即就決定，只將自己的一些電影文件和其他不涉及隱私文件上傳到服務端，而涉及到隱私的，或稍微敏感些的其他文件，我將用其他辦法來處理。
沒有軟件能夠保護隱私安全，為了自身的利益，他們只會在最大的可能范圍能截取客戶隱私，要保護這些敏感信息，只能靠你自己！