在本系列的第1部分中 ，我們了解了IPFS，IPFS和HTTP之間的區別，后來又創建了一個文件以添加到IPFS中，并將其通過節點網絡訪問。

---

在本部分中，我們將把它提升到一個新的水平，我們將創建一個目錄結構并做實驗，以更多地了解IPFS的工作原理和功能，但在此之前，我們必須著眼于Christian Lundkvist博士的例子。

來自Christian Lundkvist博士的實例IPFS

IPFS （InterPlanetary文件系統）是經過充分測試的互聯網技術（如DHT ， Git版本控制系統和Bittorrent）的綜合 。 它創建一個允許交換IPFS對象的P2P群。 IPFS對象的整體形成一個密碼認證的數據結構，稱為Merkle DAG ，這個數據結構可以用來模擬許多其他數據結構。 我們將在本文中介紹IPFS對象和Merkle DAG，并給出可以使用IPFS建模的結構示例。

IPFS對象

IPFS本質上是一個用于檢索和共享IPFS對象的P2P系統。 IPFS對象是一個包含兩個字段的數據結構：

• 數據 - 大小<256 kB的非結構化二進制數據塊。
• 鏈接 - 鏈接結構的數組。 這些是到其他IPFS對象的鏈接。

鏈接結構有三個數據字段：

• 名稱 - 鏈接的名稱。
• 散列 - 鏈接的IPFS對象的散列。
• 大小 - 鏈接的IPFS對象的累積大小，包括其鏈接。

Size字段主要用于優化P2P網絡，在這里我們將主要忽略它，因為在概念上它不需要邏輯結構。

IPFS對象通常由Base58編碼的散列引用。 例如，讓我們使用IPFS命令行工具（請在家中嘗試此操作）來查看使用散列QmarHSr9aSNaPSR6G9KFPbuLV9aEqJfTk1y9B8pdwqK4Rq的IPFS對象：

$ ipfs對象獲取QmarHSr9aSNaPSR6G9KFPbuLV9aEqJfTk1y9B8pdwqK4Rq { “鏈接”：[ { “名稱”：“AnotherName”， “哈希”：“QmVtYjNij3KeyGmcgg7yVXWskLaBtov3UYL9pgcGK3MCWu”， “尺寸”：18 }， { “名稱”：“SomeName”， “哈希”：“QmbUSy8HCn8J4TMDRRdxCbK2uCCtkQyZtY6XYv3y7kLgDC”， “尺寸”：58 } ] “數據”：“Hello World！” }

讀者可能會注意到所有散列都以“Qm”開頭。 這是因為哈希實際上是一個多哈哈，這意味著哈希本身在多哈哈的前兩個字節中指定哈希函數和哈希長度。 在上面的例子中，前面兩個字節的十六進制數是 1220 ，其中 12 表示這是SHA256哈希函數，而 20 是哈希的長度（以字節為單位） - 32個字節。

數據和已命名的鏈接為IPFS對象的集合提供了一個Merkle DAG - DAG（指向無環圖）的結構， Merkle表示這是一個使用加密哈希來加密內容的加密認證的數據結構。 作為練習留給讀者思考為什么在這個圖表中不可能有循環。

為了可視化圖形結構，我們將通過節點中的Data以圖形形象化IPFS對象，并且Links將圖形邊緣定向到其他IPFS對象，其中鏈接的Name是圖形邊緣上的標簽。 上面的例子可視化如下：

---

現在讓我們做一些實際的東西來驗證它。 為此，我們將繼續第1部分 。 因此，在ipfsdir目錄下創建一個子目錄并將其命名為ipfssubdir。 在ipfssubdir下創建一個.txt文件并將其命名為 ipfsrocks.txt的內容為IPFS Rocks !!

當我們從ipfsdir外部輸入以下內容時，我們可以看到目錄結構。

$ ls -R ipfsdir / hello.txt ipfssubdir ipfsdir // ipfssubdir： ipfsrocks.txt

現在讓我們將這些文件和目錄添加到IPFS

$ ipfs add ipfsdir -r 添加了QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u ipfsdir / hello.txt 添加了QmdWAgBc1yjQz6G3wNSmeQk7ZFBAh7LvaL7GSiFDEvCMGT ipfsdir / ipfssubdir / ipfsrocks.txt 添加QmSC7kzH6k6W8Pf8i98NivocmT2jcYPgDhZtMWahmZUczg ipfsdir / ipfssubdir 添加了QmRuftkYACe3pCjyoZGXYyr1HdqctecmPcq8C9oFyMxgaS ipfsdir

我們可以看到，對于hello.txt文件，它已經生成了與第1部分中相同的散列。

現在，我將在ipfssubdir中添加一個與hello.txt相同內容的helloworld.txt文件， 即Hello World ，并將其添加到IPFS。

讓我們看看IPFS如何添加這些文件。

$ ipfs add ipfsdir -r 添加了QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u ipfsdir / hello.txt 添加了QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u ipfsdir / ipfssubdir / helloworld.txt 添加了QmdWAgBc1yjQz6G3wNSmeQk7ZFBAh7LvaL7GSiFDEvCMGT ipfsdir / ipfssubdir / ipfsrocks.txt 添加了Qmd2zXenEQVBGt1wbYYDXZFBQiXCvfU7JkZb7u1Sw7ujRd ipfsdir / ipfssubdir 添加了QmNoX6nF2ccQkH3AHKy4HvphK8WwHa19eez7YqjrxEUE2z ipfsdir

如果我們觀察，我們可以看到IPFS為ipfsdir / hello.txt和ipfsdir / ipfssubdir / helloworld.txt生成了相同的哈希碼，因為它們都具有相同的內容。 我將在短時間內對此進行更多解釋。

讓我們像之前那樣讓這些文件被節點網絡訪問

$ ipfs pin add QmNoX6nF2ccQkH3AHKy4HvphK8WwHa19eez7YqjrxEUE2z

現在啟動守護程序將IPFS機器連接到網絡并訪問文件

$ ipfs守護進程 正在初始化守護進程... 將當前ulimit調整為2048 ... ...................................

在新終端運行同行

$ ipfs swarm peers

運行下面的鏈接檢查目錄，完全加載到IPFS上： https ：//ipfs.io/ipfs/QmNoX6nF2ccQkH3AHKy4HvphK8WwHa19eez7YqjrxEUE2z

ipfsdir ipfssubdir

上面的例子以圖形方式顯示如下：

文件系統的版本控制

為了理解版本控制，我們現在將文件helloworld.txt的內容更改為Hello World IPFS。 我們可以看到已更改文件和相應目錄的哈希值的變化。

$ ipfs add ipfsdir -r 添加了QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u ipfsdir / hello.txt 添加了QmamMpGqGkkf3v1iApshHoTHjx2PXJPJWvqQ8y55eeeoYn ipfsdir / ipfssubdir / helloworld.txt 添加了QmdWAgBc1yjQz6G3wNSmeQk7ZFBAh7LvaL7GSiFDEvCMGT ipfsdir / ipfssubdir / ipfsrocks.txt 添加了QmWtucfHnZhbURkUAnzJtsoj7pVi8TmLp9K1WSD1C2jJqc ipfsdir / ipfssubdir 添加了QmbzoYKQ8FvWDTQ5KX8LpeRWt4w48QXRgaFaKuLq14pJ4M ipfsdir

正如我前面提到的那樣，IPFS確實像Git一樣進行版本控制。 我們舉例說明我們以前的文件系統目錄結構以及兩個提交：第一個提交是原始結構，在第二個提交中，我們已將文件helloworld.txt更新為Hello World IPFS，而不是原始Hello World。

上面的變化可以通過圖形顯示如下：

正如我們所看到的，IPFS有潛力取代或補充HTTP。 人們可以很容易地看到現在使用IPFS的一些主要優點，我會提到 - 數據 不可變性， 數據分布和速度數不多。

數據不可變性

正如我們所看到的，IPFS上的文件被賦予了一個生成的散列值。 正如上面的例子 -

QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u

這是非常漫長和獨特的。 兩個文件幾乎不可能具有相同的散列。 相同文件的哈希值相同，如果文件更改，哈希值也會更改。 我們可以將這些散列值視為地址。 使用這個地址可以訪問文件。 這就是系統如何實現不變性。 沒有地址改變，沒有人可以改變文件。 這也為我們提供了數據重復數據刪除。 如果偶然兩個人在IPFS上傳完全相同的文件，他們將得到相同的哈希地址。 所以，這是不變的。

數據分布和速度

正如我前面提到的那樣，IPFS是一種類似于BitTorrent的點對點協議。 當我下載一個文件時，其中一些數據可以與其他人共享。 因此，讓我們說一下San Fransisco的一臺電腦（客戶端）從波士頓市的一臺計算機（服務器）請求一個文件。 在傳統的HTTP客戶端 - 服務器模式中，由于SFO和波士頓市之間的距離，通信需要更長的時間。 此外，如果該文件很受歡迎，來自其他位置的許多客戶端會詢問該文件，從而在波士頓的服務器上創建負載。 如果萬一服務器機器出現故障，則會出現404錯誤。 而在IPFS中，San Fransisco的其他人可能已經從波士頓的服務器上下載了這個文件，然后我可以從他們那里下載它。 如果該文件很受歡迎，那么附近的更多節點將擁有共享副本，從而將負載從波士頓服務器上分離下來并分發。 在這種情況下，即使在波士頓的服務器出現故障，我仍然可以從其他節點訪問該文件，并且可以確信沒有人會因為我們不久前討論過的不變特性而篡改文件。

---

那么，我們正在走向一個分散和更永久的互聯網世界。 鏈接永遠不會返回404錯誤并減少對集中式服務器的依賴的世界。

---

https://medium.com/@itsromiljain/ipfs-the-permanent-distributed-web-continues-ffbe1919bb94

總結

以上是生活随笔為你收集整理的【译】IPFS — The Permanent, Distributed Web Continues…..的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。