IPFS网络内容和性能测量

丁博文，徐跃东，王 亮

复旦大学 信息科学与工程学院 电子工程系，上海 200433

区块链技术因为其去中心化、安全保障和公开透明的特点，近来受到重视和广泛研究和应用，特别是在加密货币领域。除了最初以比特币为代表的加密货币外，以以太坊为代表，基于区块链实现的智能合约系统向我们展示了与各领域的系统和应用结合更加丰富的可能性。不过，出于区块链的安全性考虑，块的大小不能无限制地增长[1]，这带来了一个直接的缺陷：基于区块链的系统无法存储和处理大量的数据。这限制了在大数据等领域应用区块链技术。

星际文件系统（interplanetary filesystem，IPFS）[2]是一个P2P、去中心化的文件系统，因为其去中心化的特点以及在安全性、隐私和可靠性方面的优点，许多区块链系统应用将其作为数据存储的解决方案。IPFS将数据存储在互相连结的数据对象中，每个数据对象都由自身的密码散列值唯一确定，称为对象的“内容标识符（content identifier，CID）”。数据对象间的联系形式丰富多样，可以形成文件、目录、超链接图等多种数据结构，以满足不同应用领域数据形式的多样性需求。通过IPFS存储和获取数据的过程类似于BitTorrent，许多运行着IPFS的节点构成IPFS网络，任何一个需要获取数据的用户，根据所需数据的标识符，向网络中存储了这块数据的节点发起请求，从而获取数据。这样的特性实现了去中心化的数据存取，使得基于区块链等技术的去中心化应用可以将数据存取的任务通过IPFS实现，从而解决了区块链本身不能直接存放大量数据的问题。IPFS在物联网[3]、云计算[4]、文献和资料共享[5-6]等领域都提供了分布式数据存储的解决方案。

尽管IPFS已经在许多领域得到应用，关于IPFS和IPFS网络本身仍有许多尚待回答的问题。知道这些问题的答案在决定IPFS是否适合于某个应用目标，以及如何高效地利用IPFS时，可以提供有效的决策依据，例如：作为P2P网络，IPFS的网络规模、性质、结构如何；IPFS存储了怎样的内容，被用于什么类型的应用和目的；在实际中使用IPFS时，哪些因素是影响性能的关键因素等。

为了回答这些问题，从IPFS网络中存放的内容和通过IPFS存取内容的性能两大方面出发，对IPFS展开测量研究。本文的主要贡献有：

（1）就大家所知，首次对存储在IPFS网络上的数据内容作了测量分析，包括文件类型和大小分布，文件和目录网络的图特征。

（2）测量了IPFS网络的性质，包括网络的规模，以及节点之间互相连接的图的结构等。

（3）考察了影响通过IPFS进行数据存取的性能的因素，例如数据分片大小、工作的网络模式和提供者数量等。

1 研究背景

IPFS是一套P2P网络协议，协议涉及到节点身份、内容标记、网络路由、对等交换等众多方面。IPFS[2]这个名称既可以指这一套协议，也可以指实现了这套协议的客户端软件，又可以指一个由众多运行了IPFS软件的对等节点（peer）组成的网络。本章介绍构成IPFS的基本概念，以及影响其网络性能的重要概念和设计要点；最后介绍了类似的P2P文件系统及其相关的测量工作。

1.1 节点身份

IPFS是一个开放而动态的网络，任何人都可以运行IPFS，从而加入IPFS网络，成为网络中的一个节点。每个节点需要用一个唯一的标识符（identity，ID）在网络中标记自己，即节点的身份。通过使用不对称密码算法生成一对公私钥，节点的身份即其公钥的摘要。通常情况下不对称密码算法使用RSA2048，而摘要算法使用SHA256。为了未来的可拓展性，IPFS使用称为“Multi-Hash”的一种格式记录节点的身份，将使用何种密钥算法和摘要算法作为元信息，加上摘要本身，编码为一串字符，形如“QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN”。

为了防止女巫攻击（攻击者通过生成大量不同的身份从而造成P2P网络中的多数节点均由一个人控制），IPFS加入S/Kademlia[7]中提出的限制措施，即要求生成的公钥摘要满足一定条件，从而使得生成身份的操作需要消耗一定的时间，来增加攻击者发起攻击的时间成本，达到防御攻击的目的。

1.2 内容标记与数据结构

IPFS将每一块数据的哈希指纹作为其标识符，称为“内容标识符（CID）”。这么做有三个好处：（1）保证了每一块数据有唯一的标识符，不会发生重名的问题；（2）在传输中的可以轻易校验数据的完整性；（3）可以实现去重，即相同的数据块拥有相同的标识符，在系统中被当成同一对象处理。

IPFS使用名为MerkelTree[8]的数据结构来存放复杂的数据对象。一棵典型的MerkelTree中，叶子节点存放了真正的数据；而数量众多的叶子节点由若干父节点组织起来，父节点中记录了其下叶子节点的CID；这样的过程一直重复，直到形成一个根节点，这样这个根节点的CID就可以用来表示存储的这个复杂对象。CID的唯一性对简单的数据块成立，对由此构成的MerkelTree也成立，而且只要验证根节点的CID是否与其内容匹配，即可验证整个MerkelTree的数据完整性。

可以看出，内容标识符在MerkelTree中扮演了指针的作用。在此基础上，IPFS发展了不同类型的节点，包括只包含数据的简单节点，和包含指向其他节点的“链接”的复杂节点。可以向IPFS中的对象添加指向其他对象链接，这就使得两个MerkelTree可以发生联系，形成更为复杂的图结构（MerkelDAG），可以用于如文件和目录、超链接和版本链等复杂的应用场景，为IPFS作为文件系统提供了基础。

1.3 网络路由与内容存取

在IPFS中，同一个数据对象可以在多个网络节点处存在，每一个拥有这个对象的节点是这个对象的“提供者（provider）”，当有其他节点需要这个数据对象而发来请求时，提供者就会将其传送至请求的节点。当一个全新的数据对象出现在IPFS上时，只有上传这个对象的节点一个提供者；当其他节点获得这个对象后，它们就会成为新的提供者。

当一个节点没有某个对象而需要获取它时，这个节点会发起定位对象的请求：通过对象的CID，从IPFS网络中得知这个对象的提供者，从而向提供者发起获取数据的请求。定位请求由两种方式实现：

（1）在IPFS的分布式哈希表（distributed Hash table，DHT）中根据对象的CID查找对应的提供者。

（2）通过Bitswap协议，直接向当前连接的所有节点询问是否是所需对象的提供者。

算法1描述了通过对象CID获取对应的提供者的流程。

算法1查找CID对应的提供者

输入：对象CID cid

输出：提供者列表P

过程：

1.初始化：P←Ø

2.调用算法2，从DHT中查询cid的提供者Pdht

3.从已连接的节点中查询cid的提供者Plocal

4.P←P⋃Pdht⋃Plocal

5.返回P

算法2通过DHT查找CID对应的提供者

输入：对象CIDcid

输出：提供者列表P

过程：

1.初始化：P←Ø；起始节点集N←已连接的节点

2.forn∈Ndo：

3. ifd cid,n=1 then：

4.P←P⋃{n}

5. else：

6. 向节点n发送请求，从其d cid,n号k-桶中获得更接近的节点集Nn

7.N←N⋃N n

8. end if

9.end for

10.返回P

1.4 IPFS的DHT

可以想象，IPFS中存在数量庞大的对象和节点，为了存放这些对象和节点之间的对应关系（即哪些节点是哪些对象的提供者），需要分布式哈希表（DHT）。IPFS的DHT基于Kademlia DHT[9]，存放了用于定位数据对象和节点的重要信息。IPFS的DHT中存放了三类记录，都是以键值对的形式存放，分别是：

（1）数据对象到其提供者的映射；

（2）节点到其网络地址的映射；

（3）节点到其IPNS路径的映射。

（1）类记录可以使需要获取对象的节点得知拥有它的提供者；（2）类记录可以使节点得知某个节点的实际网络地址，从而可以发起通信；（3）类记录则是用于可变数据的更新。

DHT中的键就是数据对象或节点的ID，由于都是使用SHA256算法作哈希摘要，键通常是一个256位的整数。某条记录存放在哪个节点处，取决于其键和节点的ID之间的“距离”。根据Kademlia DHT的设计，两个ID之间的距离等于其异或的结果，即d x,y=x⊕y。对于一个节点x而言，它对于每一个距离值d x,y∈[1,256]保存k个节点，称为“k桶”，共有256个k桶。在IPFS中，k=20。

当在DHT中查询一个IDv时，发起查询的节点会迭代地向使距离d n,v减小的节点n发起请求，直到遇到使d n,v=1的节点，也即提供者节点。算法2描述了从DHT中查找对象提供者的过程。

与传统Kademlia DHT不同的是，当有新的节点可以加入一个桶时，IPFS的DHT不会检查桶中已有节点的连通性，剔除无法连通的节点，而是直接拒绝那个新节点的加入。只有当和某个节点的连接中断时，它才会被从桶中剔除。

1.5 IPFS的Bitswap

Bitswap是IPFS中处理节点之间交换数据的子协议。Bitswap受到BitTorrent的启发，但与BT不同的是，Bitswap处理的对象不是包含多个文件的“种子”，而是拥有自己ID的数据块。每个节点对其他发生过数据交换的节点维护一个“账本”，记录与之交换过的数据量：向其发送的数据记作“负债”，从其接受的数据记作“收入”，这样节点可以根据对方节点的“余额”决定是否与之交换数据。这样的测量可以阻止一部分只从他人处获取数据而不愿意为他人提供服务的节点，从而保持整个网络环境的健康。

1.6 相关研究

已有许多基于IPFS的应用被提出和发展。Big-ChainDB[10]是基于区块链的数据库系统，使用IPFS作为其存储。Alam等人[11]将IPFS用于存档互联网内容。文献[5]和[6]借助区块链和IPFS实现去中心化文档的版本控制和访问控制。

BitTorrent作为比较流行的P2P下载工具，其网络特性吸引了许多研究者开展测量工作。Pouwelse等人[12]测量了BitTorrent网络的用户规模和在线时长，种子的可用时长以及热度变化，和下载速率与用户数量的关系。Guo等人[13]分析了BitTorrent中节点的到达离开速率以及公平性，提出了基于图的模型，为跨种子间合作创造了可能。Yu等人[14]通过爬虫测量了KAD网络的路由表，发现用户ID重复会影响路由表的效率，以及较低的路由表可用性影响网络的性能。

针对IPFS的测量工作较为有限。Shen等人[15]在多个地理位置处布设节点建立私有集群，在集群中测量IPFS的性能，分别考察了IPFS在内容解析和实际传输阶段的性能，并与HTTP作对比。测量还评估了不同请求大小与应用访问的模式对IPFS性能的影响。

Henningsen等人[16]从网络结构的角度测量并分析了IPFS的DHT网络的特点。他们在IPFS的DHT网络中部署了爬虫程序，周期性地爬取DHT中的节点信息，包括节点数量，在线时长，地理位置和网络可达性。他们建立了节点间的相邻关系图，发现图节点的度分布满足幂律分布，证实IPFS的DHT网络结构与其他Kademlia系统一致。

现有的测量工作都主要集中于IPFS的网络和性能方面，未有重视其作为一个P2P文件系统相较于传统的P2P文件分享系统的重要不同，存储于IPFS上的文件内容也是影响IPFS网络和性能的重要因素。本研究着眼于现存在IPFS上的内容特点，以及IPFS在分发内容时的网络特性，同时兼顾性能方面的影响因素。

2 测量方法

2.1 实验环境

实验使用云服务器搭建了测量用的集群环境，在其中设置IPFS集群。集群由6台地理位置分散的服务器组成，分别位于东京、洛杉矶、纽约、新加坡、悉尼和伦敦。集群中服务器的软硬件配置如表1所示。

表1 实验环境配置Table 1 Configuration of experimental environment

2.2 内容测量方法

为了获取IPFS中存储的内容信息，使用一个节点连接公开IPFS网络，在其上部署监听程序（crawler）。监听程序的工作原理是，每当网络中某一个节点向IPFS中添加新的数据对象时，会向其连接的节点发送广播，通知这些节点添加的对象的CID；这些节点会将这个节点标记为这个CID的提供者。监听程序收到这样的广播时，会请求这个CID，从网络中获得一份拷贝，从中取得这个数据对象的特征信息，包括：对象的类型（例如，是文件还是目录）、文件大小、目录大小、文件类型等。对于目录类型的对象，监听程序会递归地检查目录中的子目录和文件。获得的测量结果数据集的时间跨度为2018年1月1日至2020年9月1日，包含约3 500万条文件的信息。

2.3 性能测量方法

网络节点特性的测量：通过在东京节点部署了DHT爬虫程序，爬取了IPFS的DHT中的节点信息。首先，程序随机生成一个初始CID，通过DHT查询这个CID的提供者。虽然随机生成的CID很可能不指向任何数据对象，因此也不存在任何提供者，但在查询的过程中，会逐步获得距离这个CID更接近的节点ID。爬虫程序记录遇到的这些节点，并通过节点的ID查找它的IP地址和连接到的节点。重复这个过程，从不同的初始CID出发爬取DHT，直到一次完整的爬取中，所有遇到的节点都是已经记录的节点，就标志着已经遍历了DHT中所有的节点。

数据传输性能的测量：测量在东京和洛杉矶的两台服务器之间传输测试文件的时间。使用的测试文件均为随机生成，且只存在于测试环境中的节点处，即这些节点不连接到IPFS公共网络，这保证了数据的提供者只有生成数据的一个节点，不存在从多个节点同时传输的情况。只要适合，同一组条件下的测量重复进行10次。

DHT解析性能的测量：测量从东京节点发起DHT查询开始，到获得任意一个提供者为止的时间。预先随机生成一个测试文件，使集群中一个或多个节点获取这个测试文件，成为其提供者；然后从东京节点查询这个文件的提供者。测量了在私有网络下和公开网络中两种不同情况下的DHT解析性能。

3 测量结果

3.1 内容测量

3.1.1 文件大小

图1中展示了存储在IPFS中的完整文件的大小分布。实验数据集包含了约3 500万个IPFS上的文件，可以看到，绝大多数（＞80%）的文件大小在1 MB以内，尤其是1 KB以内的文件占据了57%的数量。这部分小文件多是文本文件，特别是JSON文件，记录了供应用使用的少量数据。

图1 IPFS中存储的文件大小累积分布Fig.1 Cumulative distribution of sizes of files stored in IPFS

图2展示了IPFS中文件类型的分布情况，分别是不同类型的文件的个数占比和大小占比。图中可见，JSON文件（application/json）占到了文件总数的一半以上，而视频文件数量虽然只占0.3%，但占到了文件总大小的17.2%。大量的由各种应用使用的二进制文件（application/octet-stream），占到了总数的22.2%，更是占到了所有文件大小的62.5%；在文本文件（text）分类中，也存在大量HTML和CSS等以文本形式存在的源文件，为网页应用程序所使用。各种类型的文件，不同的大小和用途，显示了IPFS作为去中心化的HTTP和通用的文件系统，正在被各种不同的应用使用，为其提供去中心化的存储。

图2 IPFS中存储的文件类型占比Fig.2 Percentage of different file types in IPFS

IPFS允许按文件和目录的形式组织存储的数据，如同一般的文件系统。如果将每个文件或目录视作网络中的节点，目录对子目录、目录对文件的包含关系视作节点间的连边，可以建立一个网络。正式的定义如下：网络G=(V,E)由节点的集合V和节点间有向边的集合E构成；V中的节点是所有文件和目录；对于V中的目录节点j和任意一个节点i，如果目录j包含了文件或子目录i，则存在一条从i指向j的有向边e ij=＜i,j＞，E={e ij},i,j∈V。

3.1.2 文件与目录的网络性质

图3中展示了IPFS中目录与文件构成的网络的度分布。该网络是对原始数据集作5%均匀抽样所得的，包含了约310万个目录和文件节点。可以看到，在对数坐标下，网络的入度分布曲线接近线性，对线性段作拟合后的分布函数为：

图3 文件与目录构成的图的入度及出度分布Fig.3 Distribution of in-degree and out-degree of graph formed by files and directories

其中a是对数坐标下的截距，是与随机变量的下节xmin相关的参数，k是幂律分布的标度参数（scaling factor），通常有k∈[2,3][18]。这表明IPFS中内容的组织满足幂律分布：绝大多数节点都是文件，入度为1，出度为0；多数目录节点的入度较小，而极少数目录节点有很大的入度，构成网络中连接密集的中心。文献[17]出度分布的情况与之相似，大多数目录节点的出度较小，只有少量节点具有较大的出度，但带有一个较不规则的“长尾”，不符合幂律分布。

3.2 性能测量

3.2.1 节点的地理位置与网络协议

图4展示了IPFS网络中节点的地理位置分布，选取了前10个节点数量最多的国家和地区。需要注意的是一个节点可能会有多个网络地址，在图中会被多次计算。网络中大多数节点没有公开可达的IP地址，使得数量最多的是局域网IP，这是因为这些节点位于防火墙后，通过NAT访问互联网。在具有公开网络地址的和排名中，数量最多的是中国大陆，其次是美国和香港地区等。中国的节点数量较其他地区高出了一个数量级，这显示了国内对于IPFS非常热切的关注和大量的使用。本文的结果与文献[16]的结果相比，位于中国的IPFS节点数量均为最多；其次较多的为美国，分别位于第二位和第三位。中国香港地区、德国和法国等均出现在前十位的名单中，但相对排名不同。排名结果的差异主要是由爬虫节点本身所处的地理位置不同导致的，文献[16]的爬虫位于德国，因此在结果中德国和临近的法国的节点数量仅次于中国和美国之后。

图4 节点的地理位置分布Fig.4 Number of nodes by geolocation

图5显示的是IPFS网络中节点所使用的网络协议的分布。在所有地址（包括私有地址）中IPv4占了大多数，而IPv6也有相当数量的节点已经支持。有少数节点支持“p2p-circuit”这种网络连接方式，这是IPFS在没有公开可达IP地址的节点上使用的一种连接方式，即通过其他有公开可达地址的节点作中继，形成多跳的P2P回路。由于P2P回路通常速度低且不可靠，多数节点在连接到网络后会使用自己的IP地址作为连接方式，而弃用P2P回路，因此这个连接方式属于“瞬时”的连接，在所有节点中数量很少。“dns4”“dns6”和“dnsaddr”是IPFS支持的通过DNS域名表示的网络地址，这些节点通过在拥有的DNS域名中添加一条特殊的记录，将DNS域名与其IPFS的ID关联起来，可以使得其他节点通过DNS域名来访问IPFS上的这个节点。目前少有节点使用了这项功能。与文献[16]的结果相比，IPv4和IPv6均是绝大多数节点使用的协议，但本研究测量结果中支持IPv6的节点数量相对IPv4节点的数量较文献[16]少，这可能是由于本研究中较多节点位于国内，而国内IPv6网络建设尚在进行，各种网络基础设施尚未完全支持IPv6网络导致。

图5 节点的网络协议分布Fig.5 Number of nodes by network protocol

3.2.2 节点网络拓扑

通过爬取IPFS的DHT，可以获得网络节点之间的连接关系，从而获得IPFS网络的拓扑结构。类似于3.1.2小节中的文件目录网络，可以定义IPFS网络节点的连接关系图：如果某个节点vi的DHT表中记录了另一个节点v j，则视作存在一条连接这两个节点的有向边eij=＜v i,v j＞；由所有节点和边构成IPFS的网络拓扑图G=(V,E)。图6显示了图G中节点的入度和出度分布。

在图6中可见，在双对数坐标下节点的入度分布近似一条直线，意味着大多数节点的入度较小而少量节点有极大的入度，这是满足幂律分布的，拟合的概率密度函数为：

图6 IPFS网络拓扑图的度分布Fig.6 Degree distributions in graph of IPFS nodes

相较于入度分布，出度分布显示出完全不同的特点。在全部约15 000个节点中，仅约550个节点的出度不为0，而这些节点的出度均分布在100至200之间。这可能是由于在爬取DHT网络的过程中，这些节点成为主要的爬取对象，在需要其余节点的信息之前就完成了全部网络节点的爬取，因此没有向这些节点请求信息，导致多数节点的出度为0，发现与文献[16]的结果一致。

3.2.3 文件与分片大小对性能的影响

IPFS会对上传至其上的文件自动分片，形成包含文件片段的列表，并将列表对象的CID作为该文件的CID。请求者在请求列表的CID时，会递归地解析列表中的文件片段的CID，从DHT中获得每个片段的提供者，然后逐个从提供者处下载获得片段，最后当获取到所有片段后，将片段组织成原始的文件。分片的好处是，将大文件分成多个独立的片段，使得这些片段可以并行地、独立地传输和校验，而且可以根据片段的CID作去重。分片的过程包含在IPFS的上传命令中，通常使用256 KB的均匀的分片大小，也可以通过显式地指定分片大小来覆盖默认的大小。

不同的分片大小直接影响了文件在IPFS上的存储形式，因此对请求文件的性能产生了影响。IPFS首先需要解析所有分片的提供者，从而知道去何处获得这些分片。这个过程是通过查找DHT网络实现的，因此不同的分片越多，需要解析的DHT目标就越多，所需的时长也就越大。随机生成不同大小的随机内容的文件，按不同分片大小将文件分片后，从一台节点上传至IPFS，然后从另一台IPFS节点请求这个文件，并测量从请求开始到完整取得整个文件的时长，来探究不同分片大小和不同文件大小对请求时长的影响。

首先，考察了相同分片大小的情况下，不同文件大小所需的下载时长。图7展示相同分片大小（4 KB、64 KB）不同总文件大小（4 KB至4 MB，64 KB至64 MB）的若干文件从IPFS上下载的时间。图7（及后续类似的其他图）为箱线图，箱形的上下边分别为75%和25%分位数，箱中的横线为中位数，箱上下的横线为最大最小值。从图中可见，下载时长与文件大小接近线性关系，这符合对一般的网络传输过程的预期。但是对比图7（a）和7（b），相同文件总大小，但不同的分片大小和数量组合却有十分不同的下载时间。例如，同为256 KB总大小，4 KB×64和64 KB×4的组合相差了一倍以上。这表明IPFS的传输过程不仅与文件本身的大小有关，还与文件分片的大小有关。文献[15]对相同分片大小条件下的传输性能做了类似的测量，本文的测量结果与文献[15]的发现一致。

接着考察了在文件大小相同的情况下不同分片大小对性能的影响。图8中展示了相同大小的文件按1 KB至1 MB范围内的6个不同的分片大小分片，从IPFS上下载所需要的时间。可见，文件的下载时间随着分片大小的减小而增加，并也近似成线性关系。相同的文件大小意味着IPFS花费在传输上的时间应当是相同的，而出现下载时间随分片大小变化的情况是因为分片数量不同，这说明除了单纯的传输时间外，IPFS需要解析分片的提供者和提供者的网络地址，在这一部分工作上也需要花费可观的时间，并且花费的时间与分片数量成正比。

需要注意的是，改变分片大小对分片数量的影响可能不是线性的。图9展示两个大小相同的文件，按不同的分片大小划分后在IPFS中储存的情况。图中，A和B是相同大小的文件的在不同块大小下的两种可能的数据结构。A所使用的块大小可以容纳相当于4个CID大小的数据，B的块大小是A的一半。文件A由一个索引块和4个数据块组成，使用的分片大小是文件B的两倍，但文件B由8个一半大小的数据块和7个索引块构成，分片数量比文件A的两倍还多了5个，是文件A的1.5倍。导致这种情况的原因是IPFS将分片的CID记录在索引块中，CID本身也需要一定的空间（取决于所使用的摘要和编码算法），当数据块数量较多时，所需的存储CID的大小可能超出单个分片的容量，因此需要多个索引块来存放。在实际中，通常采用多层树状的结构，根节点记录第一层索引块的CID，随后每一层的索引块记录下一层的CID，树的叶子节点中存放实际的数据。这样的数据结构充分利用了IPFS CID作为数据链接的作用，但也导致在分片大小较小时，索引分片数量膨胀，相对于真正有意义的数据分片而言，有更多的空间用于了维护数据结构的额外开销，使得空间利用率下降，而且在请求文件时性能下降。实际上，IPFS使用SHA256作为生成CID的哈希算法，其大小为256位或32字节，在一个1 KB的块中只能容纳不到32个CID（除了CID外块中还需要记录有额外的信息），对于16 MB的文件，有50多万个CID需要记录，额外需要的索引块的数量十分庞大。

图9 IPFS中文件分块的示意图Fig.9 Schematic diagrarn of files split in IPFS

3.2.4 影响DHT解析时间的因素

为了进一步探究IPFS在解析分片时的性能表现，考察了影响DHT解析时间的若干因素。

图10展示不同大小的单个分片所需要的DHT解析时间。从图中可见，不同大小的分片对DHT解析时间是几乎没有影响的，由于并不实际下载分片，而仅仅是从DHT表中查找到分片的提供者及其地址信息，所需时间不和分片大小有关。

图10 不同大小的单个分片的DHT解析时间Fig.10 DHT resolution time of single chunk of different sizes

图11展示不同数量4 KB大小的分片的解析时间与分片数量的关系。这里的结果与图7（a）的结果相似，DHT解析时间随着分片数量的增加而近似线性地增加。在16个分片前后，曲线的斜率有所改变，即小于16个分片时，DHT解析时间随分片数量增加而增长得较慢，而大于16个分片时，增长的速率增加了。这显示了IPFS存在并行DHT查询的能力，当分片数量较少时，这些分片可以同时被解析，只有少量的维护请求队列的开销，使得消耗的时间增加较慢；并行请求的上限在16个分片左右，当超出这个数量时，有些请求就需要排队，因此导致请求的花费的时间显著增加。

图11 由不同数量4 KB的分片构成的文件的DHT解析时间Fig.11 DHT resolution time of file consisting of different number of 4 KB chunks

IPFS工作在哪种网络模式下也会对DHT解析性能有影响。图12（a）展示私有网络集群中不同提供者数量对同一个分片的解析时间的影响。1个提供者的情况下，需要约0.2秒完成解析；大于等于3个提供者时只需要几十毫秒即可完成解析。这与图12（b）公共网络中的情况形成了巨大差异。这是由于IPFS除了通过DHT作解析外，还可以通过向直接连接的节点发送广播的方式作查询。由于这些节点已经连接到发起查询的节点，如果它们是提供者，它们就会直接返回响应。在私有集群中，节点数量有限，广播查询可以很快就获得回应，并且同一个分片的提供者数量越多，广播回应者也就越多，因此查询的时间取决于最快的节点。在图中可以看到，解析时间随着提供者数量快速下降，当提供者数量大于3个时，解析时间实际上只取决于集群中到发起者延时最小的那个节点。

图12 不同提供者数量对DHT解析时间的影响Fig.12 Impact of different numbers of providers on DHT resolution time

图12（b）展示公共网络上构建的集群中上述实验的结果，注意纵坐标使用了对数坐标。相比图12（a）中的情况，解析时间高出了1个数量级，而且波动极大。在公共网络上，相比私有集群的情况，最大的不同是节点之间不再是已经互相连接的，因此查询往往需要通过查询DHT，逐跳接近目标，最后查询得到提供者节点。由于P2P网络内在的动态性，DHT查询的路径是随机的，这导致查询时延具有很大的方差。总体而言，提供者节点数量越多，在DHT表中查到其中任意一个节点的路径就越多，平均延时也就越短，这在图中1至3个提供者节点的情形中得到印证。多于3个提供者节点时，平均延时变化不大，也与私有集群中的情况类似。需要指出的是，在公开网络中进行DHT查询的时延方差极大，甚至可能超时而失败，是目前影响IPFS性能的主要因素。在IPFS 0.5版本中，针对这一问题做过改进，主要包括在DHT表中去除因为NAT等问题无法对DHT请求做出响应的节点等。

4 结束语

针对IPFS进行了内容和性能两方面的测量。内容方面，通过在IPFS网络中部署爬虫，收集了存储在IPFS中的文件信息，获得其类型、大小分布，分析了文件与目录构成的网络的特性，发现其度分布近似满足幂律分布。性能方面，通过爬虫爬取了IPFS网络上的节点，从节点数量、地理位置、使用的协议等方面获得了IPFS网络的概况。进一步，分析了这个网络的图结构，图的入度满足幂律分布，显示网络中存在被许多节点连接的“核心”节点，和很少被连接的边缘节点。最后，详细分析了在实际使用中影响IPFS性能的因素，发现分片的大小和数量是主要影响IPFS下载性能的因素，并且在私有集群和公开网络中，提供者的数量会影响DHT查询的性能。我们的测量结果对于分析和理解IPFS的网络和行为特点提供了重要的参考依据。