继续改进我们的IPFS网关

显示全部楼层 · 发表于 2019-6-20 18:00:46

去年我们推出星际文件系统（IPFS）网关时，我们被积极的反馈所震惊。无数人为我们提供了宝贵的改进建议，并为使通过我们的网关提供内容服务变得容易做出了开源贡献(许多人在我们的开发人员文档中提供帮助)。从那时起，我们的网关已经发展到每秒定期处理超过一千个请求，并已成为几个IPFS网站的主要访问点。（本文由IPFS中国社区编译）

我们致力于帮助发展IPFS，并采用自我们最初发布以来学到的知识来改进我们的网关。到目前为止，我们已经完成了以下工作：

自动缓存清除

我们最初设置时尝试提高网关性能的方法之一是设置非常高的缓存TTL。毕竟，IPFS上的内容在很大程度上意味着是静态的。我们听到的抱怨是，网站所有者对网站的更改需要等待几个小时后才能进行广播感到沮丧。

当IPFS网关接收到给定域的请求时，它知道要提供什么内容的方法是通过查找与该域相关联的TXT记录的值——DNSLink记录。此TXT记录的值是整个站点的哈希值，如果网站的任何一位发生更改，则会更改。所以我们写了一个工人对DNS.1进行DNS-over-HTTPS查询的脚本，如果它发现域的DNSLink记录与最初缓存内容的时间不同，则绕过缓存。

检查DNS会产生一个低得多的缓存TTL的错觉，并且通常会为请求增加不到5毫秒的时间，而使用对源的请求重新验证缓存可能需要30毫秒到300毫秒。作为额外的可用性奖励，当Cloudflare客户更改其DNS记录时，1.1.1.1缓存会自动清除。不使用我们管理DNS记录的客户可以使用此工具清除缓存。

Orange-to-Orange的Beta测试

我们的网关最初基于一个名为SSL for SaaS的功能。这调整了我们的边缘工作方式，允许任何人（Cloudflare客户与否）将自己的域名CNAME到我们网络上的目标域，并让我们将他们看到的域名流量发送到目标域的来源。SSL for SaaS在Cloudflare数据库中保留这些域的有效证书（因此得名），并在到达原点之前将目标域的配置应用于这些请求（例如，强制执行页面规则）。

SSL for SaaS的优点在于它不需要在Cloudflare网络上。新人可以通过我们的网关与他们现有的DNS提供商开始提供他们的网站，而不是迁移所有东西。所有Cloudflare设置都从目标域继承。这是一个巨大的便利，但也意味着源域即使迁移也无法自定义其设置。

这可以通过Cloudflare Edge团队的一个名为Orange-to-Orange（O2O）的实验性功能得到改善。O2O允许Cloudflare上的一个区域到另一个区域的CNAME，并在图层中应用这两个区域的设置。例如，cloudflare-ipfs.com始终使用HTTPS由于各种原因关闭，这意味着通过我们的网关提供的每个站点也可以。O2O允许网站所有者覆盖此设置，方法是为他们的网站启用“始终使用HTTPS”（如果他们知道这没关系），以及添加自定义“页面规则”和“工作人员”脚本以嵌入各种复杂的逻辑。

基于子域的网关

要在IPFS上托管应用程序，为您的应用程序设置自定义域非常重要。我们在帖子中讨论了所有这些原因，即使用IPFS的端到端完整性，实质上是因为浏览器只在域级别的沙盒网站，直接从网关的URL提供应用程序是不安全的，因为另一个（恶意的）应用程序可以窃取其数据。

拥有自定义域可以为应用程序提供一个保护用户数据的安全位置，但也可以让控制域名DNS的任何人在没有警告的情况下更改网站内容。为了提供应用程序的安全上下文以及永恒的不变性，Cloudflare在cf-ipfs.com上建立了一个基于子域的网关。

cf-ipfs.com不响应对根域的请求，仅在子域中，它将子域解释为要服务的内容的哈希值。这意味着对https：// .cf-ipfs.com的请求相当于访问https://cloudflare-ipfs.com/ipfs/ 。唯一的技术性是因为域名不区分大小写，所以必须将哈希从Base58重新编码为Base32。幸运的是，标准IPFS客户端为此提供了实用程序！

举个例子，我们将在IPFS上采用经典的维基百科镜像：

https://cloudflare-ipfs.com/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/

首先，我们将哈希转换QmXoyp...6uco为base32：

$ipfs cid base32 QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco
bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq

告诉我们我们可以去这里：

https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.cf-ipfs.com/wiki/

子域方法的主要缺点是对于没有加密SNI支持的客户端，散列作为TLS握手的一部分泄漏到网络。这可能对隐私不利，并启用网络级审查。

启用会话关联

加载网站通常需要从后端服务器获取多个资产，而且通常情况下，“多个”更像是“十几个”。当通过IPFS加载该网站时，它会显著提高性能。 IPFS节点可以建立一个连接并为所有资产重新使用它。

幕后，我们运行了几个IPFS节点，以减少中断的可能性并提高吞吐量。不幸的是，通过最初设置的方式，网站上不同资产的每个请求可能会转到不同的IPFS节点，并且必须再次进行所有这些连接。

我们通过用我们自己的负载平衡替换原始后端负载均衡器来解决这个问题支持会话关联性的产品，自动将来自同一用户的请求定向到同一IPFS节点，从而最大限度地减少冗余网络请求。

与Pinata连接

最后，我们配置了我们的IPFS节点，以维持与Pinata运行的节点的持久连接，Pinata是一家帮助人们将内容固定到IPFS网络的公司。对于网络上的内容，持久连接可显著提高网关请求的性能和可靠性。Pinata写了自己的博客文章，它描述了如何将网站上传到IPFS并使用Cloudflare和Pinata的组合保持在线。

与往常一样，我们期待看到社区建立在我们的工作之上，并了解Cloudflare如何改善互联网。

作者：Brendan McMillion
本文由IPFS中国社区编译。

ntprihsxfyv.png

继续改进我们的IPFS网关

相关帖子