前言
本文主要介绍IPFS相关的一下底层基础，包括分布式哈希表(DHT)、块交换协议(BitTorrent)、版本控制(Git)、自验证文件系统(SFS)、Merkle Tree和Merkle DAG
一、分布式哈希表(DHT)
首先让我们来了解一下以前的文件网络系统的工作原理：
第1代P2P文件网络主要依靠是一个中央数据库，这个数据库服务器接收所有的查询，服务器相应的向客户端返回其所需要的数据库地址列表。
缺点：这样的设计容易导致单点失效，更有甚者会导致整个网络瘫痪。
第2代分布式文件系统中，Gnutella使用消息洪泛方法(message flooding) 来定位数据，查询消息会公布给全网所有的节点，直到找到这个消息，然后返回给查询者。
缺点：盲目的请求会导致网络快速耗尽，网络请求量非常大，容易造成拥堵。
第3代分布式文件系统中，主要借助了 DHT(Distributed Hash Table),全网维护一个巨大的文件索引哈希表，形如<Key,Value>。这里的Key通常是文件中的某个哈希算法下的哈希值，Value则保存的是IP地址，通过提供Key就能从表中查询到存储节点的地址并返回给查询节点，极大的缩短了查询时间。
IPFS引用过有代表性的分区表类型有3种，分别是Kademlia DHT、 Coral DHT和S/Kademlia。
1.Kademlia DHT
KAD网络算法细节如下：
1）Kademlia 二叉状态树
首先Kademlia网络的节点ID是由一棵二叉树维护的。它具有以下特点：
1.每个网络节点从根节点出发，沿着它的最短唯一前缀到达。
2.每个网络节点都是叶子节点。
对于任意的一个树的节点，我们都可以沿着它的前缀作为路径，向下分解成一系列不包括自己的子树。
2）节点路由表K-Bucket
节点路由表用于保存每个节点与自己有一定距离范围内其他节点连接信息。每一条路由信息由如下3部分组成：IP Address、UDP port、Node ID。
2.Coral DSHT
Coral DSHT是Coral CDN最核心的部件之一。Kademlia协议使用的是XOR距离，即信息永远是存储中XOR距离最近的节点。这样设计的特点很比较明显，它忽略了节点之间的延时及数据的位置等因素，浪费了大量的网络带宽和存储空间。Coral则采用不同的思想，它将所有的节点评估连接情况，然后根据循环时间划分几个等级，根据不同的等级查询键值对。
Coral DSHT比较适用于软状态的键值对检索，也就是说同一个Key可能会保存多个Value。这种机制能把给定的Key映射到网络中的Coral服务器地址。
Coral DSHT 主要有以下几个特点：
1.索引机制和分层
2.基于键值对的路由层
3.Sloppy存储
3.S/Kademlia DHT
Kademlia用于完全开放的P2P网络， 如果不提供任何安全措施， 它
很容易受到来自恶意节点发动的各类攻击。基于Kademlia协议，S/K协议在节点ID中加入隐式身份认证和兄弟广播。
S/K 能抵御常见的日蚀攻击(eclipse attack)和女巫攻击(Sybil attack)。
二、块交换协议(BitTorrent)
BitTorrent 是一种内容分发协议，它采用内容分发和点对点技术，减少中心化服务器的负载。在BitTorrent网络里，每个用户需要同时上传和下载数据，用户之间相互转发自己所拥有的文件部分，直到每个用户的下载全部完成。
BitTorrent涉及的术语：
.torrent: 它是服务器接收的元数据文件（通常结尾是.Torrent），一般用来记录下载数据的信息
tracker: 指互联网上负责协调BitTorrent客户端行动的服务器，用以帮助peers相互达成连接。
peer: peer是互联网上的另一台可以连接并传输数据的服务器。peer之间相互下载、上传。
seed： 一个特定的torrent完整拷贝的计算机称为seedy。在初次发布时，实现初次共享。
.swarm:连接一个torrent的所有设备群组。
Chocking： Chocking阻塞是一种临时拒绝上传策略，BitTorrent 需要每个peer相互上传，
对于不合作的peer，会采用临时阻断策略。
Pareto效率： 帕累托效率(Pareto efficiency) 指的是资源分配已经到了物尽其用的阶段。
针锋相对： 又叫一报还一报，在BitTorrent中表现为，Peer给自己贡献多少下载速度，那么也就相应贡献多少上传速度给他。
BitTorrent，是基于点对点的实现方式，它包括了内容发布，分块交换，片段选择算法等三个部分。
三、版本控制(Git)
版本控制系统是用于记录一个或若干个文件内容变化，以便将来查阅特定版本修订情况的系统。实现版本控制的软件有很多，不过也大致也可以分为三类：本地版本控制系统，中心化版本控制系统，分布式版本控制系统。
1.本地版本控制系统
这种方式就是我们常用的复制整个目录作为备份，有时也会加上备份时间或其他标识作为区分。后来有人开发了很多本地版本控制系统，采用某种简单的数据库来记录文件的历次更新差异。本地版本控制系统的缺点也比较明显，不能让不同系统上的开发者协同工作。
2.中心化版本控制系统
这类系统，比较常见的有CVS、Subversion,他们都有一个单一的集中管理服务器，保存所有文件的修订版本，所有协同工作的人们都可以通过客户端连到这台服务器，取出最新的文件或提交更新。
3.分布式版本控制系统
分布式版本控制系统避免了中心化版本控制系统单点故障的风险，比较常见的有Git、Mercurial等，它不只是提取最新版本的文件快照，而是把代码仓库完整镜像下来。任何一处协同工作服务器出现故障，都能用任何一个镜像出来的本地仓库恢复。
Git通常具有以下几个特点：
快照流： Git存储的是随时间改变的快照，也就是说每个人获取到的快照可能不一样。
本地执行操作： Git绝大多数操作只需要访问本地文件和资源。
只添加数据： 我们所有执行的Git操作，本质上在Git数据库中都是增加操作，并且所有的操作都是可逆的。
完整性校验： Git中所有数据在存储前都会计算校验和，然后以校验和来引用。
工作区与工作状态： Git的工作区包括工作目录、Git仓库及暂存区域。Git仓库又包括本地仓库和远程仓库。Git的工作状态包括已提交 （committed）、已修改（modified）和已暂存（staged）。
基本的Git工作流程 如下：
1.在工作目录中修改文件。
2.暂存文件，将文件的快照放入暂存区域。
3.提交更新，找到暂存区域的文件，将快照永久性存储到Git仓库。
分支： Git中的分支本质上仅是个指向commit对象的可变 指针。Git使用master作为分支的默认名字。主干可被克隆为其他分支，每条分支的可变指针在每次提交时都会自动向前移动。如下图：
四、自验证文件系统(SFS)
自验证文件系统（Self-Certifying File System， SFS） 是为了设计一套整个互联网共用的文件系统，全球的SFS系统都在同一个命名空间下。
实现全球共享的文件系统，最大的问题在于如果让服务端为客户端提供认证。对于这个问题，SFS采用的是将公钥信息嵌入文件名中，这样做的好处在于不再需要文件系统内部实现秘钥管理，并且用户可以根据需求，自行选择需要的加密方式。
SFS核心思想有如下几点：
1.SFS文件系统具备自验证路径名称， 不需要在文件系统内部实现密
钥管理。
2.在SFS上易于架设各种密钥管理机制， 包括各类组合机制。
3.SFS将密钥管理与密钥分发解耦。
4.实现全球范围的文件系统。
五. Merkle Tree和Merkle DAG
1.Merkle Tree
Merkle Tree(默克尔树) 是一种树，大多数是二叉树，也可以是多叉树。它具有以下特点：
1.Merkle Tree的叶子节点的value是数据集合的单元数据或者单元数据Hash.
2.非叶子节点的value是根据它的下面所有的叶子节点值，按照哈希算法计算而得出的。
Merkle Tree的应用
数字签名： 最初默克尔树在于高效处理Lamport单次签名。在此之前每一个Lamport秘钥只能被用来签名一个消息，然而与默克尔树结合起来之后可以签名多个消息。
P2P： 在P2P网络中，默克尔树用来确保从其他节点接收的数据块没有损坏并且没有被替换，甚至检查其他节点不会欺骗或者发布虚假的块。
比特币： Merkle Proof最早的应用是Bitcoin(比特币)，由中本聪创建。Bitcoin的BlcokChain利用Merkle proofs来存储每个区块的交易。这样的好处的在于简化支付验证。
2.Merkle DAG
Merkle DAG(默克尔有向无环图)，它是在默克尔树的基础上的构建的。
Merkle DAG在功能上也和Merkle Tree有很不同。Merkle DAG主要有以下3个功能：
内容寻址： 使用多重Hash来唯一识别一个数据块的内容。
防篡改： 可以方便的检查Hash值来确认数据是否被篡改。
去重： 内容相同的数据库块的Hash值是相同的，很容易去掉重复的数据。
总结
本文主要介绍了IPFS一些底层技术包括分布式哈希表(DHT)、块交换协议(BitTorrent)、版本控制(Git)、自验证文件系统(SFS)、Merkle Tree和Merkle DAG