风雪围城

IPFS 网关(一)

本篇是一篇译文，原文IPFS Gateway。
本篇是翻译 IPFS 网关的第一部分，主要描述网关提供者和所提供的网关类型。

说到网关，这里想补充几句，它就像是一座桥梁，或者一道门，连接着两个体系，从 HTTP 网络到 IPFS 网络。它不负责存储，而是进行转发，甚至包装后再转发，是一个不同协议之间的转换器，适配器。

这篇文章讨论以下内容：

  • 一些网关类型
  • 网关在 IPFS 使用过程中扮演的角色
  • 网关使用适用的场景
  • 不应该使用网关的场景
  • 实现指南

在本文中，你可以：

  • 在概念层面理解网关是如何满足 IPFS 的使用需求
  • 决定是否使用网关以及使用哪种网关类型
  • 在概念层面理解如何使用网关满足自己的使用需求

1. 概述

IPFS 部署，致力于在所有流行浏览器以及工具中，包含对 IPFS 的原生支持。网关，为那些原生不支持 IPFS 的应用提供了 IPFS 的使用环境。比如，当浏览器不支持 IPFS 但是却试图根据标准格式 ipfs://{CID}/{optional path to resource} 访问 IPFS 中的内容时，将会发生错误。一些其它仅仅依赖于 HTTP 工具，比如 Curl 和 Wget,如果要访问 IPFS 的内容时也将遇到类似的错误。

有些工具可以处理上面这种错误，比如 IPFS Companion(译注：IPFS 伴侣？)，然而，这需要一定的电脑配置支持。

IPFS 网关，提供了一种基于 HTTP 的服务，允许那些不支持 IPFS 的浏览器和工具访问 IPFS 内容。

2. 网关提供者

不管是谁来部署，也不管网关在哪，任何 IPFS 网关都会解决通过 内容身份（或者说内容id，CID） 访问 IPFS 内容的问题。因此，在你需要网关服务的时候，就使用一个离你最近的就行了。

2.1 你的本地网关

你可能会在设备上开启一个本地的网关服务，比如 localhost:8080。如果你安装了 IPFS Desktop 或者其他 IPFS 节点，就可以在本地开启这样一个服务。

2.2 私有网关

运行 IPFS Desktop 或则其他 IPFS 节点，这些节点将试图连接其他 IPFS 节点。私有的网络管理员可能会认为这种连接会有潜在的安全隐患。IPFS 网关也可以运行在私有网络下，并运行可信代码。

将网关置于防火墙内，是私有网关的一种方式。通常，当网关被配置成只能由指定的域名访问，或者只能允许互联网部分的请求访问，即可认为其为私有网关。这篇文章 tutorial configuring an IPFS gateway on a Google Cloud platform 包含了对受限访问描述。

2.3 公共网关

公共网关的运营方式包括：

  • 由 Protocol Labs 部署的公共网关 https://ipfs.io
  • 第三方公共网关，比如 ttps://cf-ipfs.com

Protocol Labs 维护了 公共网关列表 以及它们的状态。

3. 网关类型

网关的分类包含以下几个维度：

  • 读/写支持
  • 授权支持
  • 地址解析方式

这些网关的使用，存在安全/性能以及其他功能的影响。

3.1 只读和可写入型网关

我们上文所说的，通过 HTTP GET 方法获取 IPFS 内容的就是只读 HTTP 网关。可写入的 HTTP 网关还支持 POST / PUT 以及 DELETE 方法。

3.2 授权网关

如果网关提供者想要通过授权限制请求的访问，他们可以配置反向代理，开发 IPFS 插件或者基于 IPFS 设置缓存层。
配置反向代理是处理授权最常用的方式。

提供商可以设计自己的中心化验证服务，比如 Infura IPFS Auth 或者去中心化的授权验证服务，比如 IPFS W3Auth

3.3 解析方式

这里存在三种解析方式：

  • 路径解析
  • 子域解析
  • DNSLink
3.3.1 路径解析
1
https://{gateway URL}/ipfs/{content ID}/{optional path to resource}

路径解析式的网关，实际上是违反 同源政策 的，这样使用比较危险，所有文件共享同源。

3.3.2 子域解析

子域解析的方式，是符合同源政策的（译注：相对而言更加安全）。它的标准访问形式是：

1
https://{CID}.ipfs.{gatewayURL}/{optional path to resource}

这种方式下，将导致浏览器将每种文件都认为是不同的来源。

子域解析支持是从 Go-IPFS 的 0.5.0 版本开始的。

当 IPFS 中的数据内容发生变化时，其将基于数据内容生成新的 CID。许多应用需要访问到最新的文件或者网站，但是它们并无法得知数据版本的变化。
InterPlanetary Name Service(IPNS) 允许一个版本独立的 IPNS id 作为当前版本的 IPFS CID.
版本独立的 IPNS id 包含一个哈希。当网关处理 https://{gatewayURL}/ipns/{IPNS identifier}/{optional path} 这样的请求时，网关将使用 IPNS，将 IPNS id 作为当前版本的 CID，并获取相应的内容。
但是，IPNS id

当网关识别到 IPNS id 中包含 example.com 时，DNSLink 开始解析。比如，URL https://libp2p.io 将返回当前版本的存储在 IPFS 上的网站。具体过程如下：

  1. 网关收到如下形式的请求：

    1
    https://{gateway URL}/ipns/{example.com}/{optional path}

  2. 网关将搜索 DNS 文本记录，查找域名 {exapmle.com} 所对应的记录，形式为 dnslink=/ipfs/{CID} 或者 _dnslink=/ipfs/{CID}。

    1
    2
    3
    dig +noall +answer TXT \_dnslink.docs.ipfs.io
    > \_dnslink.docs.ipfs.io. 30 IN TXT "dnslink=/ipfs/bafybeieenxnjdjm7vbr5zdwemaun4sw4iy7h4imlvvl433q6gzjg6awdpq"

    如果找到了，网关将使用这个 CID 构成 ipfs://{CID}/{optional path}.正如路径解析一样，这种形式的 DNSLink 解析也违反了同源政策。域名运营商也许可以确保同源政策—交付当前版本的内容—通过在 DNS 上添加 Alias 记录（译注：应该是 CNAME-canonical name 吧，域名别名）将其指向合适的 IPFS 网关地址。

  3. Alias 记录将重新向任何访问 example.com 的请求到指定的网关。因此，浏览器中访问 https://{example.com}/{optional path to resource} 将被重定向到 Alias 所指定的网关地址上。

  4. 网关利用 DNSLink 解析，从 IPFS 上获取当前内容版本。

  5. 浏览器不会认为官网作为内容的源，因此，会强制执行单源策略以保护 example.com。

参考链接

Address IPFS on the web
Publish content path

IPFS IPFSGateway

© 2024 YueGS