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在分布式应用方面大行其道。基于区块链技术的杀手级应用，很可能也会因此到来。
