According to white paper：
The InterPlanetary File System (IPFS) is a peer-to-peer distributed file system that seeks to connect all computing devices with the same system of files. In some ways, IPFS is similar to the Web, but IPFS could be seen as a single BitTorrent swarm, exchanging objects within one Git repository. In other words, IPFS provides a high throughput content-addressed block storage model, with content- addressed hyper links. This forms a generalized Merkle DAG, a data structure upon which one can build versioned file systems, blockchains, and even a Permanent Web. IPFS combines a distributed hashtable, an incentivized block exchange, and a selfcertifying namespace. IPFS has no single point of failure, and nodes do not need to trust each other.
?
讓我們提取一下這段話里的關鍵詞：
- P2P對等網絡
- 基于BT協議
- 類似Git倉庫的版本文件系統
- 內容尋址
- Merkle DAG的數據格式
- 無單點故障
下面逐一解釋；
P2P對等網絡
IPFS聲稱可以替代Web，內容不再通過中心服務器響應，而是以P2P的方式從鄰近的對等節點拉取；同時全網維護一個統一的路由表，每個節點作自我調整，以保證節點與數據的動態增刪、完整性、去冗余等細節問題。
根據官方網站介紹，傳統的HTTP協議具有以下不足之處：
- HTTP的效率低下，并且服務器昂貴。使用HTTP協議從中心化的服務器集群中一次需要下載一個完整文件，而P2P的方式可以從許多peers（對等節點）中下載不同的數據塊，經研究可以節省60%的帶寬成本。
- 歷史文件被刪除。我們在上網的過程中看到過太多的404，網頁的平均壽命是100天，部分網站數據不能得到永久保存。這也是受限于中心化服務器的高存儲成本。
- HTTP的中心化限制了發展機會。全球互聯網DNS根源上是由13個根服務器所提供。同時主要的云服務也由幾家重要的云服務商所提供。政府和機構可以在這些中心化集群前截取HTTP消息包，窺探和監控網民的生活；黑客們也可以很容易的通過DDOS等手段攻擊中心化的服務器集群導致網絡癱瘓。
-
網絡應用過于依賴主干網。當主干網因為不可抗力因素造成擁塞或宕機等，無法繼續服務時，應用也會受到影響。
HTTP協議誕生20年來，協議只是從1.0到2.0，但web應用本質上還是基于B/S架構的模式，它的根本劣勢仍然無法得到很好的改進。
?
基于BT協議
IPFS 中的BitSwap協議受到BitTorrent 的啟發，通過對等節點間交換數據塊來分發數據.
舉個例子：小明想要觀看一部視頻
- 小紅和小剛以前看過該視頻，于是他們將視頻文件加入IPFS網絡，得到相同的哈希指紋B。(現實中，若該視頻在周邊好幾個節點都持有，IPFS會把文件分塊去重，節省節點的存儲成本）
- 小明在本地通過哈希指紋B（形如 /ipfs/B 的路徑名），試圖從IPFS網絡拉取該視頻。小明不關心最終的視頻數據來自哪些節點。
- 小明的節點索引DHT（分布式哈希表）中的哈希值所對應的節點列表，并行地從這些節點下載部分數據塊。IPFS網絡會自動從各節點下載部分數據塊，再由本地的manager拼成完整的文件。
- 小明的節點獲得了這個視頻，不僅自己可以觀看，還可以為其他人提供資源。
IPFS每一個節點都維護了兩個列表：
- 已有的數據塊（have_list）
- 想要的數據塊（want_list）
當兩個節點建立連接后，他們會根據hava_list和want_list互通有無。
跟BitTorrent不一樣的是：BitSwap獲取數據塊的時候不限于從同一個torrent里面。
也就是說BitSwap可以從不屬于本文件的其他文件獲取數據塊(只要數據塊的哈希值一樣，數據內容必然是一樣的)，從全局考慮，這使得BitSwap的效率相比于BitTorrent更高。
對于p2p網絡，有一個很重要的問題是：如何激勵大家分享自己的數據？用過迅雷、BitTorrent、emule等p2p軟件的小伙伴應該都知道，如果只下載不上傳的話，很快你的節點就無法下載數據了或者下載數據變得很慢。每一個p2p軟件都實現了自己的數據分享策略。IPFS也不例外。
?
類似Git倉庫的版本文件系統
IPFS各節點本身使用類似git的版本控制系統，來管理本地文件與數據塊。這既保證了數據塊的去冗余，又提供了可追溯的歷史版本。
IPFS為模型化版本系統定義了一組對象模型，與Git很類似：
block：一個可變大小的數據塊。
list：塊或其他鏈表的集合。
tree：塊、鏈表和其他樹的集合。
commit：當前文件數在版本歷史記錄中的一個快照。
Blob
Blob對象代表一個文件，并且包含一個可尋址的數據單元。IPFS文件可以使用lists或者blobs來表示。但區別是Blob沒有鏈接。
List
List對象包含一個有序的隊列，該隊列由blob或list對象組成。
{
"data": ["blob", "list", "blob"],
// lists have an array of object types as data
"links": [
{ "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x","size": 189458 },
{ "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5","size": 19441 },
{ "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z","size": 5286 }
// lists have no names in links
]
}
Tree
在IPFS中，Tree對象與Git的tree類似：它代表一個目錄，或者一個名字到哈希值的映射表。哈希值表示blobs,lists,其他的trees，或commits。
Commit
在IPFS中，commit對象代表任何對象在版本歷史記錄中的一個快照。它與Git的commit也非常類似，但它可以指向任何類型的對象（Git中只能指向tree或其他commit）。
?
內容尋址
?
類似Git，IPFS使用哈希指紋來實現去重，內容一樣的文件哈希值一定相同；
Markle Tree 和DAG
關于在海量數據中尋找變量或增量，相比傳統方法中，數據中的改變需要傳輸整個文件才能進行驗證，而使用Markle Tree只需要時間復雜度O(Log n)，空間復雜度O(Log n)。
Merkle Tree本質上是二叉樹hash，IPFS的方案是，文件只儲存在leaf nodes中，非葉子節儲存left child+right child的hash值。
下面看一張長圖
總結來說：
- 每次有文件有改動，只需要傳輸相應的data，驗證根節點是否相同
- 文件拷貝時也只需要考慮改動的leaf node，及其與根節點之間的節點
As for the Merkle DAG： A Merkle DAG is a Merkle directed acyclic graph. That is a data structure similar to a Merkle tree but not so strict: such DAG does not need to be balanced and its non-leaf nodes are allowed to contain data.
?
無單點故障
基于以上幾個特征，IPFS沒有單點故障，并且節點不需要相互信任。
?
IPFS的應用和愿景
基于IPFS，我們可以實現一種更廉價、帶獎勵機制的分布式存儲方案（如FileCoin），這為IPFS生態的發展提供了十足的想象空間。
且IPFS本身是不消耗任何代幣的。
IPFS的實現得益于區塊鏈技術的發展。在區塊鏈誕生之前，對于IPFS的實現存在兩個問題：
- 節點網絡在維護路由表的一致性，特別是涉及到節點、資源的動態增刪，節點的信用以及防欺騙和防free loader等方面，往往不得不采用一些中心化的解決方案（例如迅雷下載P2P加速），而這又違背了去中心的理念。
- 對節點實行獎懲機制，涉及到賬本、信用管理，代幣發行以及交易事務處理等等，在分布式架構下難以保證高可靠、高可用和安全防篡改。過去的解決方案也是引入一個中心化的機構作背書。
這些問題在今天來看，使用區塊鏈技術，綜合效率和成本兩方面，是再合適不過的。
在接下來的10年，我們一定會看到IPFS在分布式應用方面大行其道。基于區塊鏈技術的殺手級應用，很可能也會因此到來。
