上鏈(9):文件鏈

by 楊學成

基於HTTP協議的互聯網應用,一度大幅度提高了文件分享的效率,產生了目前流行的互聯網應用方式,但也導致了一系列自身無法克服的問題:

上鍊(9):文件鏈

首先,HTTP是一種客戶端-服務器邏輯,文件集中存儲在服務器上,而客戶端通過網址來尋找相應的服務器,並經服務器允許後獲取文件資源。這種請求-響應的方式不利於文件的分佈式存儲和分散化調用,容易帶來資源壟斷。

其次,集中存儲在服務器的方式導致資源很容易被篡改和刪除。只要在服務器端抹除了相關文件,或者禁止客戶端的請求,那麼文件就很難被使用。與此同時,集中化的數據存儲,讓數據中心高度依賴於骨幹網,這樣有利於監管機構進行內容審查和封鎖,但骨幹網的損壞或者路由表丟失卻會帶來巨大的問題。

第三,HTTP協議會產生文件內容的大量冗餘,一旦一個文件被從某個服務器下載下來之後,就可以被隨意分發,導致一份文件在整個網絡空間出現大量的拷貝,甚至經由多個主體的隨意篡改之後,文件面目全非。這不僅浪費了存儲資源,還引發了嚴重的版權問題。

針對以上問題,2014年Juan Benet發佈了一個開源代碼項目,旨在創建一個持久且分佈式存儲和共享文件的網絡傳輸協議,最初由Protocol Labs在開源社區的幫助下發展,後來就演化出星際文件系統(InterPlanetary File System,簡稱IPFS),這是一種可尋址的對等超媒體分發協議。

不同於傳統的搜索方式,用戶要先找到服務器的地址(IP地址),然後使用路徑名稱在服務器尋找文件,通過IPFS,用戶搜索的是內容。當文件被添加到IPFS節點上,它就得到一個新的名字,這個名字實質上是一個加密哈希,它是從文件內容中被計算出來的,所以這個哈希值只代表文件內容,而加密意味著文件內容不會被修改,任何改動都會導致哈希值完全不同。

用戶訪問的時候,IPFS可以通過分佈式哈希錶快速找到擁有數據的節點,從而檢索該數據並通過哈希值驗證數據是否準確,這將大大提高文件搜索的效率。

在文件存儲方面,IPFS採用分佈式存儲方式,一個大文件可以被切成很多小顆粒度的文件分佈在不同的地方存儲,節點下載文件的時候既可以採用傳統的方式從單一服務器下載,也可以從多個服務器上同步下載,從而形成了一種小顆粒度的、分佈式的、易於聚合的內容分發網絡。

此外,IPFS會查找並且刪除網絡中具有相同哈希值的文件,清除網絡中的文件冗餘和重複。同時,跟蹤文件的各個不同歷史版本記錄,確保了相同文件僅在IPFS網絡中存儲一份並永久保存。

雖然IPFS被冠以谷歌顛覆者的頭銜,有望顛覆現有互聯網的底層技術協議,但目前的IPFS仍處於初級階段,還沒有真正取代現有的網站存儲系統,未來還有很遠的路要走。

結論:不要因為胃口不好去抱怨食物……


分享到:


相關文章: