# 通过 Swarm 连接加速 IPFS

By [Feng](https://paragraph.com/@feng) · 2022-02-11

---

通过 Swarm Connect 建立直接连接
-----------------------

![](https://storage.googleapis.com/papyrus_images/f3ea494d9404befe97a5ba3b533738e718d0ea59d424c968617942de4e188ccf.png)

[本周为Pinata](https://pinata.cloud/)平台的常用部分带来了新功能：我们的[pin by hash 功能](https://pinata.cloud/documentation#PinHashToIPFS)。

我想花一些时间来解释这个新功能，并深入了解围绕这个更新的 IPFS 机制。

事不宜迟，让我们开始吧。

IPFS 固定——它是如何工作的
----------------

在 IPFS 节点上固定内容有两种主要方法：

1.  \*\*将本地文件添加到 IPFS 节点：\*\*添加本地文件是内容首先成为 IPFS 网络的一部分的方式，并且当您使用我们的[pinFileToIPFS](https://pinata.cloud/documentation#PinFileToIPFS)端点将文件上传到 pin 时会发生什么。本质上，我们通过 API 接收您的文件，然后将其直接发送到我们的节点进行固定。
    
2.  \*\*通过其哈希（内容标识符）检索内容并将其固定：\*\*IPFS 还允许您固定存在于 IPFS 网络上但不在本地计算机上的内容。当您使用我们的[addHashToPinQueue](https://pinata.cloud/documentation#AddHashToPinQueue)或[pinHashToIPFS](https://pinata.cloud/documentation#PinHashToIPFS)端点时会发生这种情况，也是我们将在本文中重点介绍的用例。
    

哈希固定——更深入的了解
------------

快速提醒：将文件添加到 IPFS 节点时，节点会返回文件的内容标识符 (CID)。从 IPFS 节点返回的 CID 是通过[加密](https://github.com/multiformats/multihash)哈希函数运行文件的直接结果运行文件的直接结果。正因为如此，CID 通常被称为内容的“散列”，我们将在本文的其余部分使用 CID。

双氢睾酮
----

当一个节点连接到 IPFS 网络时，该节点所拥有的内容会经常通过 IPFS 分布式哈希表 (DHT) 进行广播。这意味着该节点正在告诉所有其他节点它具有某些内容。这使得如果有人向这些节点询问该内容，他们将知道将请求节点指向哪个节点。

![](https://storage.googleapis.com/papyrus_images/7ac3e8bf77de4f2fe2442f05ecccd2dd05199c4291b7c54536b00a69697848b6.png)

多地址
---

这里要理解的一个关键概念是，当节点使用 DHT “搜索内容”时，它实际上是在搜索拥有该内容的人。请求节点使用 DHT 找出哪些节点具有它正在寻找的内容以及这些节点所在的位置。如果请求节点能够找到一个包含它正在寻找的内容的节点，IPFS 网络最终将返回该节点的“多地址”托管所需的内容。多地址看起来像这样：

    /ip4/123.456.78.90/tcp/4001/ipfs/QmAbCdEfGhIjKlMnOpQrStUvWxYzAbCdEfGhIjKlMnOpQr
    

多地址的格式可以不同，因此“多地址”的“多”部分，但需要注意的重要一点是多地址为请求节点提供了一些东西：

*   使用哪些协议与节点通信
    
*   节点的IP位置
    
*   节点可以到达哪个端口
    
*   节点的唯一 Peer ID
    

稍后我们将详细讨论如何找到节点的多地址。但是，现在，让我们谈谈为什么这个地址很重要。

内容检索
----

如上所述，请求节点使用 DHT 来查找托管他们正在寻找的内容的对等点的多地址。一旦他们找到了这个多地址，请求节点就会通过 IPFS 的[“群”](https://docs.ipfs.io/reference/api/cli/#ipfs-swarm)功能直接连接到主机节点并开始检索内容。

与请求节点如何使用 DHT 来定位他们想要消费的内容类似，想要固定网络上已经存在的内容的节点也使用 DHT 来定位他们想要固定的内容。

一个常见的问题是，通常需要一段时间才能找到托管内容的节点。

这是由许多原因造成的。两个常见的原因是：

*   托管节点最近刚刚连接到 IPFS 网络
    
*   托管节点连接到很少的其他节点
    

这两个问题都源于这样一个事实，即请求内容的节点和托管该内容的节点之间通常存在一定程度的分离。

如果我们能加快这个过程不是很好吗？

加快内容发现
------

如果请求节点的所有者已经知道内容存储在特定节点上，那么该节点遍历 DHT 以找出哪个节点具有该内容没有多大意义。

幸运的是，IPFS 允许我们手动连接到我们已经知道的节点。[我在上一篇文章](https://medium.com/pinata/how-to-keep-your-ipfs-nodes-connected-and-ensure-fast-content-discovery-7d92fb23da46)中谈到了这种机制。快速回顾一下：如果我们知道 IPFS 节点的多地址，我们可以使用 IPFS 的[“群连接”手动连接到它](https://docs.ipfs.io/reference/api/cli/#ipfs-swarm-connect)功能手动连接到它。

那么这对我们有什么好处呢？
-------------

通过直接连接，请求节点在主机节点上具有用于内容发现的“快速通道”。当请求节点发出内容请求时，不必等待其对等节点找出谁在托管该内容，这些对等节点之一实际上将是托管内容的节点。这允许近乎即时的响应时间。一旦请求节点发现主机节点具有它想要的内容，它将检索内容以进行固定。

![](https://storage.googleapis.com/papyrus_images/82fe467346e43d2c8fbed2ce4016cc6666ff7e131d0adc85662d5adaf36e2e05.png)

在这种情况下，我们已经减少了请求节点用于搜索所需内容位置的大量初始时间。

这是如何在 Pinata 中实现的
-----------------

我们本周的新功能可以在我们的[addHashToPinQueue](https://pinata.cloud/documentation#AddHashToPinQueue)或[pinHashToIPFS](https://pinata.cloud/documentation#PinHashToIPFS)端点中看到。现在，在提供要固定的哈希时，您可以提供最多五个您的内容已经驻留在其上的节点的多地址。

如果我们的 API 注意到您在请求中提供了主机节点，我们将在尝试固定您的内容之前直接连接到这些节点！这使我们能够通过减少固定内容的节点发现过程来利用本文前面提到的速度优势。

查找您的多地址
-------

要查找您正在运行的节点的多地址，只需运行：

    ipfs id
    

您的回复应如下所示：

    {
    "ID": "NodeID",
    "PublicKey": "NodePublicKey",
    "Addresses": [
    "/ip4/127.0.0.1/tcp/4001/ipfs/NodeID",
    "/ip4/XXX.XXX.XXX.XXX/tcp/4001/ipfs/NodeID",
    "/ip6/::1/tcp/4001/ipfs/YourNodeID",
    "/ip6/YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY/tcp/4001/ipfs/NodeID",
    "/ip6/YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY/tcp/4001/ipfs/NodeID",
    "/ip6/YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY/tcp/4001/ipfs/NodeID",
    "/ip4/XXX.XXX.XXX.XXX/tcp/4001/ipfs/NodeID",
    ],
    "AgentVersion": "go-ipfs/0.4.17/",
    "ProtocolVersion": "ipfs/0.1.0"
    }
    

在响应中，您应该看到一个“地址”数组，其中列出了您节点的不同多地址。根据您的网络配置，您可能会列出一些条目，但您需要注意的是包含您机器的“外部”IP 地址的条目。要仔细检查您的机器外部地址，请查看[这个方便的工具](https://www.whatismyip.com/)或在服务器的命令行中运行以下命令：

    dig +short myip.opendns.com @resolver1.opendns.com
    

如何在您的请求中提供主机节点
--------------

[要在addHashToPinQueue](https://pinata.cloud/documentation#AddHashToPinQueue)或[pinHashToIPFS](https://pinata.cloud/documentation#PinHashToIPFS)请求中提供主机节点的多地址，只需将“host\_nodes”属性添加到请求 POST 正文中，如下所示：

    {
        hashToPin: (Your Content's Hash Goes Here),
        host_nodes: [
            /ip4/host_node_1_external_IP/tcp/4001/ipfs/node_1_peer_id,
            /ip4/host_node_2_external_IP/tcp/4001/ipfs/node_2_peer_id,
            .
            .
            .
        ]
    }
    

就是这样！通过为您的主机节点提供多地址，您可以享受明显更快的已托管内容的固定时间。对于试图将内容固定在最近刚刚连接到网络的节点或对等连接计数较低的节点上的客户来说，这种速度改进将特别明显。

结论
--

在已经知道哪些节点正在托管所需内容的情况下，通过在进行 pin 尝试之前让接收节点与主机节点建立手动 IPFS 游泳连接，可以显着降低内容检索/固定时间。这消除了接收节点在检索内容之前通过 IPFS DHT 搜索主机节点的需要。

与往常一样，如果您对这篇文章或 IPFS 有任何疑问，请随时在 Twitter上的 @[MattOber1发表评论或与我联系！](https://twitter.com/MattOber1)

---

*Originally published on [Feng](https://paragraph.com/@feng/swarm-ipfs)*