IPFS 究竟是怎麼工做的？

簡介

咱們知道，一個存儲服務，最基本的功能就是存和取。IPFS 中提供了這兩種語義，那就是 add 和 get 操做。
在 IPFS 系統中執行 add 操做，就是執行了一次存操做，放在網絡的概念裏，就是「上傳」操做。而 get 就更好理解了，就是取操做，在網絡世界裏，也叫 「下載」。

IPFS 號稱點對點無中心化文件系統，沒有單點故障，也就是文件一旦被「上傳」到 IPFS 網絡中，就會被永久保存。而要想下載一個本地沒有的文件，只要 IPFS 網絡中有，簡單的執行 get 就很快能下載到數據。那麼 add 操做的背後到底作了什麼？get 又是怎麼獲取數據的？

這就是本文要探究的主題！

先來看一下 add 和 get 的基本操做過程

 

 

當一個 IPFS 節點執行 add 操做時，它會把文件進行分塊 block，經過構建一個 Merkle 樹根節點，來把每一個子塊節點都鏈接起來，每一個 block 都會用一個惟一的 Cid 進行標識。

block 數據會被保存到本地的 blockstore 中。可是須要注意的是，除此以外，block 數據並不會馬上主動上傳到 IPFS 網絡中（也即，與其鏈接的 peers 節點中）。除非，某 peer 節點曾經請求過該 block 數據。

add 執行邏輯以下圖所示：

 

 

理解這一點很是重要，由於，咱們很容易會把 IPFS 想象成一個會自動備份數據的分佈式數據庫，就像傳統的冗餘備份機制同樣。實際上，IPFS 並不會這樣作。這是由 IPFS 在公網環境中運行和傳統分佈式數據庫在私有網絡中運行的場景要求不同所致使的。做爲互聯網基礎設施，這種設計不只減小網絡帶寬佔用，還能爲網絡提供可靠、恆久的數據保存機制。

如今就來來了解一下 get 操做背後的原理，先看下圖：

 

 

上圖展現了 ipfs 執行 get 命令的執行流程。

對於當前節點來講，全部與其鏈接的 peers 節點會構成一個 swarm 網絡。

當本地節點發出一個 get 請求時，它首先會從本地的 blockstore 中查找請求的數據，若是沒有找到，它便會向 swarm 網絡發出請求，經過 DHT Routing 找到擁有該數據的節點，一旦找到一個擁有所請求數據的節點，該節點會把數據反饋回來。而後，本地節點會把收到的 block 數據緩存一份到本地的 blockstore 中，這樣，整個網絡中就至關於多了一份原數據的拷貝。當有更多的節點都請求該數據的時候，就變得更加容易，而因爲愈來愈多的節點都存有該數據，數據就變得幾乎不可丟失。

這也就是 IPFS 網絡可以永久保存數據的原理，只要有任何一個 IPFS 節點擁有某數據，這個數據就能夠被全網所獲取。

那麼，執行 IPFS 的 add 命令以後，爲何直接訪問 ipfs.io 網關就能獲取到數據呢？

好比，在瀏覽器中打開相似 https://ipfs.io/ipfs/QmR4WZy1rfXX868yFsTcqHun5y61c1jh2oQhDqWD97FEM2 這樣的網站地址，就能直接訪問到剛纔咱們添加的數據！

原理是這樣的：

IPFS 網關，即 ipfs.io，實際上扮演的是一個 IPFS 節點的做用，當咱們打開上述網站的時候，其實就是向 IPFS 網關發出了一次請求，IPFS 網關會代理咱們（由於咱們不是 IPFS 節點，咱們只是瀏覽器而已）向擁有這個數據的 Peer 節點（就是咱們本地節點）發出 get 請求，一旦獲取到數據，網關會先本身緩存一份，而後把請求到的數據經過 HTTP 協議轉發給咱們！

也就是說，任何一臺機器，只要打開瀏覽器，都能經過上述地址訪問到咱們剛纔執行 add 命令時添加的數據。一旦 IPFS 網關第一次緩存節點數據以後，再次請求時，它就無需再向原節點請求數據了，只要 Hash 值沒有變化，就能夠直接把以前緩存的數據返回給瀏覽器。

 

 

固然，這個緩存的數據是有時效的，一般是一週左右就會失效。這個是由 ipfs daemon 內置的默認時效所設定。由於做爲網關節點，其磁盤容量也是有限的，不可能無限保存全部的數據，採用緩存時效機制不只能解決資源訪問問題，還能避免數據膨脹給節點帶了的負擔，當愈來愈多的機器加入 IPFS 網絡而且承擔網關的做用，那麼數據時效的機率就會大大下降。

更多細節

實際上，Peer 節點在執行 add 命令時，還會廣播本身擁有的塊信息。同時，它還會維護一個該 swarm 網絡中全部已發給當前節點的 block 請求列表，一旦 add 命令都添加的數據知足請求列表，就會向對應節點主動發送數據，並更新該列表。