言：一種新技術的誕生，總會面臨著不同境況：有狂熱的信仰者追捧，有沉穩(wěn)的中立者觀望，也有頑固的保守者評判，猶如達爾文的《物種起源》。

（一）前世——HTTP：拉開網絡信息時代的序幕，獨領風騷二十年

1991年8月6日，蒂姆·伯納斯·李在位于歐洲粒子物理研究所（CERN）的NeXT計算機上，正式運行世界上第一個Web網站（http://info.cern.ch ），建立起基本的互聯網基礎概念和技術體系，由此開啟了網絡信息時代的序幕。

1991年,HTTP/0.9版首次登上歷史的舞臺,版本極其簡單，只有一個命令GET。基于協議規(guī)定：服務器只能回應HTML格式的字符串，不能回應別的格式，服務器發(fā)送完畢，就關閉TCP連接。現在看來，是多么的簡陋單一，然而就是這一小小的變化，卻敲開一扇塵封已久的大門。

1996年5月，HTTP/1.0 版本發(fā)布，別看只是0.9與1.0數字上細微只差，但卻是一個分水嶺，為HTTP的后續(xù)發(fā)展提供了強勁的動力。

首先HTTP擴大了傳輸內容的類別，并非僅僅局限于文字，圖片、二進制文件、視頻等均囊括于內，這為互聯網的后續(xù)爆發(fā)奠定了基礎。其次，除了GET命令，還引入POST命令和HEAD命令，豐富了瀏覽器與服務器的互動手段，讓HTTP請求和回應的格式也有些改變。最后，也新增了一些的功能以此更好去服務互聯網。

技術一直在迭代更新，只為需求最優(yōu)的方案。半年后，HTTP/1.1 版本發(fā)布，HTTP/1.1進一步完善了 HTTP/1.0 協議，它引入持久連接（persistent connection）和管道機制（pipelining），改進了HTTP協議的效率，但卻存在著“對頭堵塞”的問題。即便如此，HTTP/1.1一直用到了20十多年后的今天，直到現在還是最流行的版本之一。

2009年，谷歌公開了自行研發(fā)的 SPDY 協議，主要解決 HTTP/1.1 效率不高的問題。基于這個協議在Chrome瀏覽器上證明可行后，便被當作 HTTP/2 的基礎。2015年，HTTP/2 發(fā)布，它不叫 HTTP/2.0，是因為標準委員會不打算再發(fā)布子版本，下一個新版本將是 HTTP/3，這也許意味一個時代的終結。

歷史告我們，一個英雄倒下了，下一個英雄崛起，開啟著屬于他的輝煌。

（二）今生——IPFS：極簡主義的布道者，后起之秀可爭雄

2014年5月，一個叫Juan Benet墨西哥的小哥與他的幾個斯坦福大學同學一起發(fā)明了IPFS。IPFS 的發(fā)明者Juan Benet是一位墨西哥移民也是一個傳奇人物，畢業(yè)于斯坦福大學的計算機科學專業(yè)。之前創(chuàng)立的一家公司在 2013 年被雅虎收購 ，隨后，他在Y Combinator 項目中成立了 Protocol Labs。

Protocal Labs剛一創(chuàng)立就加入美國硅谷頂級孵化器Y-Combinator，IPFS是他們做的第一個產品。Protocol Labs在創(chuàng)建IPFS的時候給它取名為“Inter Planetary File System（星際文件傳輸）”。對于這一點，Protocol Labs希望構建一個點對點的分布式文件系統，通過底層協議，讓全世界所有人都能夠輕松從IPFS系統上提取文件，且不受防火墻的影響。

愿景很美好，但每一條看似光鮮亮麗的道路上是荊棘遍地。IPFS主張將大文件分別存放于不同的塊中，但同時存在著一個隱患，即：如果一部分存放文件的節(jié)點統統下線不可用了，并且該文件沒有備份，那么整個文件都是不可用的。

簡而言之，就是需要激勵更多人去存儲信息和分發(fā)文件。此刻，Filecoin順勢而生，作為IPFS的激勵層，也可認為是IPFS網絡上的通證。Filecoin共發(fā)行20億枚，并在2017年7月進行代幣私募，8月進行了通證眾籌，融資超過2.5億美元。這意味著IPFS尚未正式啟動，市場價值已達到25億美元，其魅力可見一斑！

2018年1月2日，IPFS官方網站發(fā)布：自融資完成以來，IPFS一直致力于將Filecoin的巨大潛力變?yōu)楝F實 - 從Filecoin的實施到執(zhí)行協議的核心再到招募最優(yōu)秀的人才來發(fā)展團隊。直到現在，IPFS依然像一個典型的理工男一樣默默深耕技術，或許正因為這份堅毅的執(zhí)著和近似苛刻的嚴謹，才會讓IPFS走得更遠，真正將夢想照進現實。

他們還在為曾經的理想書寫著未來，默默地砥礪前行，離成功只差臨門一腳。

（三）技術間的博弈源于：是一個中心，還是多個中心？

其實一開始，Web的本意是去中心化，但它卻變得越來越中心化，今天越來越多的人依靠的是少數網站的服務。HTTP變成了一個脆弱的、高度集中的、無效的、過度依賴于骨干網的協議，像美國國家安全局這樣的組織，現在只需要在幾個點上攔截通信來進行監(jiān)視。對政府來說，阻止網站訪問這些高度集中化的資源變得容易，這也使通信容易遭受DDoS攻擊而面臨巨大的風險。

反觀IPFS，它不需要每個節(jié)點存儲所有發(fā)布到IPFS上的內容。相反，每個節(jié)點只存儲自己想要的數據。如果每個節(jié)點托管一點數據，所有數據通過累積就提供了比任何集中式HTTP更多的空間、帶寬和可用性。分布式網絡將很快成為世界上最快、最可用、以及最大的數據存儲。沒有人有能力關閉所有的節(jié)點，所以數據永遠不會丟失。

與此同時，比及HTTP協議，IPFS會讓文件下載速度更快，儲存空間價格變的更加低廉，網絡更加開放和安全。目前，在網絡結構里面，中心化服務器的傳輸壓力非常大，而個人電腦、家用網絡、數據帶寬的利用率卻很低，造成了資源的浪費，如果它通過把個人的帶寬資源利用起來，為用戶創(chuàng)造更好的網絡環(huán)境，同時還采用激勵的方式讓更多用戶貢獻自己的資源（參考Filecoin\HCC颶風生態(tài)），豈不是兩全其美。

誠然，IPFS在某些性能上占據了優(yōu)勢，但就目前的存儲市場而論，中心化存儲遠占上風，中心化存儲的市場占比高達90%以上。據了解，世界最大的芯片制造廠商 Intel 有大約10萬臺服務器，Facebook有3萬臺，而 Google有超過100萬臺服務器。

然而，伴隨著各行各業(yè)的數據一直在急劇猛增，勢頭如火如荼，未來對數據存儲、分發(fā)的門檻也會隨之拔高，傳統中心化存儲的性能難以為繼，HTTP或許會從框架上進行改進，但終究無法解決“集中性化”帶來的痼疾，IPFS也許能成為一個不錯的替代方案，卻也依然存在著監(jiān)管復雜等一些潛在的風險。

歸根結底，兩者之間的博弈核心還在于“中心化”還是多中心化的選擇。

（四）去中心化：展望未來，萬物皆是中心

正如我們現在對于互聯網使用習以為常一樣，IPFS實則是重構了我們傳遞、獲取、存儲信息的方式。為此出現新型的項目，像Filecoin則為這一系統建立了激勵體系來確保系統的運轉，又恰如HCC颶風生態(tài)以視頻為切入口，構建聚合數據儲存、處理及公鏈開發(fā)的雙底層智能生態(tài)。雖然諸如此類的項目層出不窮，但整個行業(yè)都朝著“萬物皆是中心”的良好趨勢前進，即便這個時間線很長。

或許，IPFS的前沿在不久的將來，會徹底改變我們看待信息的方式，成為我們日常生活的一部分。不管是區(qū)塊鏈本身帶來的金融自由，還是IPFS給我們帶來的信息自由，無疑都將是人類進化史上重要的一個里程碑。

是否還記得，那臺Tim Berners-Lee在CERN的NeXT電腦——世界上第一臺HTTP協議的Web服務器，主機箱上貼著一張醒目的紙條，上面寫著“這是一臺服務器，不要關機!”即便它現存于一家博物館，但它的“兄弟姐妹”依舊分布在全球各地，依舊貼著“不要關機”的字樣。或許多年后，服務器會擺脫這個無形的標簽，因為已經沒有了中心。

要：IPFS 和區(qū)塊鏈有著非常緊密的聯系， 隨著區(qū)塊鏈的不斷發(fā)展，對數據的存儲需求也越來越高。本文從IPFS 的底層設計出發(fā)， 結合源代碼， 分析了IPFS 的一些技術細節(jié)。

一、概述

IPFS 和區(qū)塊鏈有著非常緊密的聯系， 隨著區(qū)塊鏈的不斷發(fā)展，對數據的存儲需求也越來越高， 由于性能和成本的限制，現有的區(qū)塊鏈設計方案大部分都選擇了把較大的數據存儲在鏈外，通過對數據進行加密， 哈希運算等手段來防止數據被篡改， 在區(qū)塊鏈上只引用所存數據的hash 值, 從而滿足業(yè)務對數據的存儲需求。 本文從IPFS 的底層設計出發(fā)， 結合源代碼， 分析了IPFS 的一些技術細節(jié)。 由于IPFS還在不斷更新中， 文中引用的部分可能和最新代碼有所出入。

閱讀本文需要讀者

• 了解網絡編程

• 了解分布式存儲

• 了解基本的區(qū)塊鏈知識

二、什么是IPFS？

維基百科上是這樣解釋的：是一個旨在創(chuàng)建持久且分布式存儲和共享文件的網絡傳輸協議。

上面的解釋稍顯晦澀， 我的理解是：

1. 首先它是一個FS（文件系統）

2. 其次它支持點對點傳輸

既然是文件系統， 那它和普通的文件系統有什么區(qū)別呢？ 有以下幾點區(qū)別：

• 存儲方式: 它是分布式存儲的, 為了方便傳輸，文件被切分成多個block, 每個block 通過hash運算得到唯一的ID， 方便在網絡中進行識別和去重。 考慮到傳輸效率， 同一個block 可能有多個copy, 分別存儲在不同的網絡節(jié)點上。

• 內容尋址方式： 每個block都有唯一的ID，我們只需要根據節(jié)點的ID 就可以獲取到它所對應的block。

那么問題來了， 既然文件被切分成了多個block，如何組織這些block 數據，組成邏輯上的文件呢? 在IFPS中采用的merkledag, 下面是 merkledag 的一個示意圖：

簡單來說， 就是2種數據結構merkle 和DAG（有向無環(huán)圖）的結合， 通過這種邏輯結構， 可以滿足：

• 內容尋址: 使用hash ID來唯一識別一個數據塊的內容

• 防篡改: 可以方便的檢查哈希值來確認數據是否被篡改

• 去重: 由于內容相同的數據塊哈希是相同的，可以很容去掉重復的數據，節(jié)省存儲空間

確定了數據模型后， 接下來要做的事： 如何把數據分發(fā)到不同的網絡節(jié)點上， 達到分布式存儲和共享的目的？ 我們先思考一下， 通過網絡，比如HTTP， 訪問某個文件的步驟，首先我們要知道存儲這個文件的服務器地址， 然后我們需要知道這個文件對應的ID， 比如文件名。前者我們可以抽象成網絡節(jié)點尋址， 后者我們抽象成文件對象尋址； 在IPFS中， 這兩種尋址方式使用了相同的算法， KAD, 介紹KAD算法的文章很多，這里不贅述， 只簡單說明一下核心思想：

KAD 最精妙之處就是使用XOR 來計算ID 之間的距離，并且統一了節(jié)點ID 和 對象ID的尋址方式。 采用 XOR（按比特異或操作）算法計算 key 之間的“距離”。

這種做法使得它具備了類似于“幾何距離”的某些特性（下面用 ⊕ 表示 XOR）

• (A ⊕ B)==(B ⊕ A) XOR 符合“交換律”，具備對稱性。

• (A ⊕ A)==0 反身性，自身距離為零

• (A ⊕ B) > 0 【不同】的兩個 key 之間的距離必大于零

• (A ⊕ B) + (B ⊕ C) >=(A ⊕ C) 三角不等式

通過KAD算法，IPFS 把不同ID的數據塊分發(fā)到與之距離較近的網絡節(jié)點中，達到分布式存儲的目的。

通過IPFS獲取文件時，只需要根據merkledag, 按圖索驥，根據每個block的ID, 通過KAD算法從相應網絡節(jié)點中下載block數據， 最后驗證是否數據完整， 完成拼接即可。

下面我們再從技術實現的角度做更深入的介紹。

三、IPFS的系統架構

我們先看一下IPFS的系統架構圖， 分為5層：

• 一層為naming， 基于PKI的一個命名空間；

• 第二層為merkledag， IPFS 內部的邏輯數據結構；

• 第三層為exchange, 節(jié)點之間block data的交換協議；

• 第四層為routing, 主要實現節(jié)點尋址和對象尋址；

• 第五層為network, 封裝了P2P通訊的連接和傳輸部分。

站在數據的角度來看， 又可以分為2個大的模塊：

• IPLD（ InterPlanetary Linked Data） 主要用來定義數據， 給數據建模；

• libp2p解決的是數據如何傳輸的問題。

下面分別介紹IFPS 中的2個主要部分IPLD 和 libP2P。

3.1 IPLD

通過hash 值來實現內容尋址的方式在分布式計算領域得到了廣泛的應用， 比如區(qū)塊鏈， 再比如git repo。 雖然使用hash 連接數據的方式有相似之處， 但是底層數據結構并不能通用， IPFS 是個極具野心的項目， 為了讓這些不同領域之間的數據可互操作， 它定義了統一的數據模型IPLD， 通過它， 可以方便地訪問來自不同領域的數據。

前面已經介紹數據的邏輯結構是用merkledag表示的， 那么它是如何實現的呢？ 圍繞merkledag作為核心， 它定義了以下幾個概念：

• merkle link 代表dag 中的邊

• merkel-dag 有向無環(huán)圖

• merkle-path 訪問dag節(jié)點的類似unix path的路徑

• IPLD data model 基于json 的數據模型

• IPLD serialized format 序列化格式

• canonical 格式： 為了保證同樣的logic object 總是序列化為一個同樣的輸出， 而制定的確定性規(guī)則

圍繞這些定義它實現了下面幾個components

• CID 內容ID

• data model 數據模型

• serialization format 序列化格式

• tools & libraries 工具和庫

• IPLD selector 類似CSS 選擇器， 方便選取dag中的節(jié)點

• IPLD transformation 對dag 進行轉換計算

我們知道，數據是多樣性的，為了給不同的數據建模， 我們需要一種通用的數據格式， 通過它可以最大程度地兼容不同的數據， IPFS 中定義了一個抽象的集合， multiformat, 包含multihash、multiaddr、multibase、multicodec、multistream幾個部分。

3.1.1 multihash

自識別hash, 由3個部分組成，分別是：hash函數編碼、hash值的長度和hash內容， 下面是個簡單的例子：

這種設計的最大好處是非常方便升級，一旦有一天我們使用的hash 函數不再安全了， 或者發(fā)現了更好的hash 函數，我們可以很方便的升級系統。

3.1.2 multiaddr

自描述地址格式，可以描述各種不同的地址

3.1.3 multibase

multibase 代表的是一種編碼格式， 方便把CID 編碼成不同的格式， 比如這里定義了2進制、8進制、10進制、16進制、也有我們熟悉的base58btc 和 base64編碼。

3.1.4 multicodec

mulcodec 代表的是自描述的編解碼， 其實是個table， 用1到2個字節(jié)定了數據內容的格式， 比如用字母z表示base58btc編碼， 0x50表示protobuf 等等。

3.1.5 multistream

multistream 首先是個stream， 它利用multicodec，實現了自描述的功能， 下面是基于一個javascript 的例子； 先new 一個buffer 對象， 里面是json對象， 然后給它加一個前綴protobuf, 這樣這個multistream 就構造好了， 可以通過網絡傳輸。在解析時可以先取codec 前綴，然后移除前綴， 得到具體的數據內容。

結合上面的部分， 我們重點介紹一下CID。

CID 是IPFS分布式文件系統中標準的文件尋址格式，它集合了內容尋址、加密散列算法和自我描述的格式, 是IPLD 內部核心的識別符。目前有2個版本，CIDv0 和CIDv1。

CIDv0是一個向后兼容的版本，其中:

• multibase 一直為 base58btc

• multicodec 一直為 protobuf-mdag

• version 一直為 CIDv0

• multihash 表示為cidv0 ::=<multihash-content-address>

為了更靈活的表述ID數據， 支持更多的格式， IPLD 定義了CIDv1，CIDv1由4個部分組成：

• multibase

• version

• multicodec

• multihash

IPLD 是IPFS 的數據描述格式， 解決了如何定義數據的問題， 下面這張圖是結合源代碼整理的一份邏輯圖，我們可以看到上面是一些高級的接口， 比如file, mfs, fuse 等。 下面是數據結構的持久化部分，節(jié)點之間交換的內容是以block 為基礎的， 最下面就是物理存儲了。比如block 存儲在blocks 目錄， 其他節(jié)點之間的信息存儲在leveldb， 還有keystore, config 等。

3.2 數據如何傳輸呢？

接下來我們介紹libP2P， 看看數據是如何傳輸的。libP2P 是個模塊化的網絡協議棧。

做過socket編程的小伙伴應該都知道， 使用raw socket 編程傳輸數據的過程，無非就是以下幾個步驟：

1. 獲取目標服務器地址

2. 和目標服務器建立連接

3. 握手協議

4. 傳輸數據

5. 關閉連接

libP2P 也是這樣，不過區(qū)別在于它把各個部分都模塊化了， 定義了通用的接口， 可以很方便的進行擴展。

3.2.1 架構圖

由以下幾個部分組成，分別是：

• Peer Routing

• Swarm (傳輸和連接)

• Distributed Record Store

• Discovery

下面我們對它們做分別介紹, 我們先看關鍵的路由部分。

3.2.2 Peer Routing

libP2P定義了routing 接口，目前有2個實現，分別是KAD routing 和 MDNS routing, 擴展很容易， 只要按照接口實現相應的方法即可。

ipfs 中的節(jié)點路由表是通過維護多個K-BUCKET來實現的， 每次新增節(jié)點， 會計算節(jié)點ID 和自身節(jié)點ID 之間的common prefix, 根據這個公共前綴把節(jié)點加到對應的KBUCKET 中, KBUCKET 最大值為20， 當超出時，再進行拆分。

更新路由表的流程如下：

除了KAD routing 之外， IPFS 也實現了MDNS routing, 主要用來在局域網內發(fā)現節(jié)點, 這個功能相對比較獨立， 由于用到了多播地址， 在一些公有云部署環(huán)境中可能無法工作。

3.2.3 Swarm（傳輸和連接）

swarm 定義了以下接口：

• transport 網絡傳輸層的接口

• connection 處理網絡連接的接口

• stream multiplex 同一connection 復用多個stream的接口

下面我們重點看下是如何動態(tài)協商stream protocol 的，整個流程如下：

1. 默認先通過multistream-select 完成握手

2. 發(fā)起方嘗試使用某個協議， 接收方如果不接受， 再嘗試其他協議， 直到找到雙方都支持的協議或者協商失敗。

另外為了提高協商效率， 也提供了一個ls 消息， 用來查詢目標節(jié)點支持的全部協議。

3.2.4 Distributed Record Store

record 表示一個記錄， 可以用來存儲一個鍵值對，比如ipns name publish 就是發(fā)布一個objectId 綁定指定 node id 的record 到ipfs 網絡中， 這樣通過ipns 尋址時就會查找對應的record, 再解析到objectId, 實現尋址的功能。

3.2.5 Discovery

目前系統支持3種發(fā)現方式， 分別是：

• bootstrap 通過配置的啟動節(jié)點發(fā)現其他的節(jié)點

• random walk 通過查詢隨機生成的peerID， 從而發(fā)現新的節(jié)點

• mdns 通過multicast 發(fā)現局域網內的節(jié)點

最后總結一下源代碼中的邏輯模塊：

從下到上分為5個層次:

• 最底層為傳輸層， 主要封裝各種協議， 比如TCP，SCTP， BLE， TOR 等網絡協議

• 傳輸層上面封裝了連接層，實現連接管理和通知等功能

• 連接層上面是stream 層， 實現了stream的多路復用

• stream層上面是路由層

• 最上層是discovery, messaging以及record store 等

四、總結

本文從定義數據和傳輸數據的角度分別介紹了IPFS的2個主要模塊IPLD 和 libP2P：

• IPLD 主要用來定義數據， 給數據建模

• libP2P 解決數據傳輸問題

這兩部分相輔相成， 雖然都源自于IPFS項目，但是也可以獨立使用在其他項目中。

IPFS的遠景目標就是替換現在瀏覽器使用的 HTTP 協議， 目前項目還在迭代開發(fā)中， 一些功能也在不斷完善。為了解決數據的持久化問題， 引入了filecoin 激勵機制， 通過token激勵，讓更多的節(jié)點加入到網絡中來，從而提供更穩(wěn)定的服務。