当我们去年启动我们的星际文件系统（IPFS）网关时，我们被这个积极的信号震惊了。无数的人为我们提出了宝贵的改进建议，并为通过我们的网关提供内容服务提供了开源贡献（许多都在我们的开发人员文档中获得）。从那时起，我们的网关已经发展到每秒处理超过1000个请求，并且已经成为多个IPF的主要访问点网站。我们'致力于帮助发展IPF，并将我们从最初发布以来学到的知识用于改进我们的网关。到目前为止，我们已经完成了以下：自动缓存最初设置网关时，我们试图提高网关性能的方法之一是设置非常高的缓存ttl。毕竟，IPFS上的内容在很大程度上是静态的。不过，我们听到的抱怨是，网站所有者在等待他们的网站更改为传播。那个IPFS网关在接收到给定域的请求时知道要服务什么内容的方式是通过查找与域相关联的TXT记录的值-DNSLink记录。这个TXT记录的值是整个站点的哈希值，如果站点的任何一个位发生变化，它就会改变。因此，我们编写了一个Worker脚本，该脚本对1.1.1.1进行DNS over HTTPS查询，如果它发现某个域的DNSLink记录与最初内容不同，则绕过缓存缓存。正在检查DNS提供了一个低得多的缓存TTL的假象，并且通常为请求增加不到5毫秒的时间，而通过向源服务器请求重新验证缓存可能需要30毫秒到300毫秒的时间，作为额外的可用性奖励，当Cloudflare客户更改其DNS记录时，1.1.1.1缓存会自动清除。不与我们一起管理其DNS记录的客户可以使用此清除其缓存工具测试版Orange到OrangeOur网关的测试最初是基于SaaS的SSL特性。这调整了edge的工作方式，允许任何人（无论是否为Cloudflare客户）将其自己的域CNAME到我们网络上的目标域，并让我们将其域的流量发送到目标域的源。sslforsaas将这些域的有效证书保存在Cloudflare数据库中（因此才是名称），并在这些请求到达之前将目标域的配置应用于这些请求（例如，强制执行页面规则）起源地SSL for SaaS的好处在于它不需要在Cloudflare网络上。新用户可以开始通过我们的网关与他们现有的域名服务提供商服务他们的网站，而不是迁移一切。所有Cloudflare设置都是从目标域继承的。这是一个巨大的方便，但也意味着源域不能自定义它们的设置，即使它们这样做了迁移。这个可以通过Cloudflare Edge团队的一个名为Orange to Orange（O2O）的实验特性加以改进。O2O允许Cloudflare上的一个区域CNAME到另一个区域，并在层中应用两个区域的设置。例如，cloudflare-ipfs.com网站总是因为各种原因关闭了HTTPS，这意味着通过我们的网关服务的每个站点也一样。O2O允许网站所有者覆盖此设置，方法是允许仅对其网站启用"始终使用HTTPS"，如果他们知道这是可以的，还可以添加自定义页面规则和辅助脚本来嵌入各种复杂的内容逻辑。如果您正在一个企业计划，并希望在您的领域尝试这一点，请联系。您的客户团队已收到此请求，我们将在未来为您启用此请求周。子域-基于网关要在IPFS上托管应用程序，为你的应用程序创建一个自定义域是非常必要的。我们在我们的帖子《IPFS端到端完整性》（End-to-End Integrity with IPFS）中讨论了造成这种情况的所有原因，主要是因为浏览器只在域级别上使用沙盒网站，直接从网关的URL提供应用程序不安全，因为另一个（恶意）应用程序可能会窃取其数据。有不管是谁，只要用户在没有域名的情况下控制域名，都可以让域名保持安全。为了为应用程序提供一个安全的上下文以及永恒的不变性，Cloudflare在cf上设置了一个基于子域的网关-ipfs.com.cf-ipfs.com网站不响应对根域的请求，仅在子域中，它将子域解释为要服务的内容的哈希。这意味着对https://的请求-ipfs.com网站相当于https://cloudflare-ipfs.com/ipfs/。唯一的技术问题是，由于域名不区分大小写，哈希必须从Base58重新编码到Base32。幸运的是，标准的IPFS客户机为此提供了一个实用程序！作为一个例子，我们将使用经典的维基百科镜像IPFS:https：//cloudflare-ipfs.com/ipfs/qmxoypizjw3wknijnklwhcnl72vedxjqkddp1mxwo6uco/wiki/First，我们将散列QmXoyp…6uco转换为base32:$ipfs cid base32 qmxoypizjw3wknijnklwhcnl72vedxjkddp1mxwo6ucobafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq告诉我们我们可以去这里相反：https：//bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.cf-ipfs.com/wiki/The子域方法的主要缺点是，对于没有加密SNI支持的客户端，散列作为TLS握手的一部分泄漏到网络中。可能会对网络隐私造成不利影响审查制度。使能当一个网站需要一个以上的文件时，通常只需要一个以上的服务器，当IPFS节点可以建立一个连接并为所有节点重用时，它显著地提高了性能资产。落后在幕布中，我们运行多个IPFS节点，以减少中断的可能性并提高吞吐量。不幸的是，按照最初的设置方式，在一个网站上对不同资产的每个请求可能会转到不同的IPFS节点，所有这些连接都必须进行又一次。我们通过用我们自己的负载平衡产品替换原来的后端负载平衡器来修复这个问题，该产品支持会话关联，并自动将来自同一用户的请求定向到同一个IPFS节点，最小化冗余网络请求。连接通过Pinata，我们配置了IPFS节点，以保持与Pinata运行的节点的持久连接，Pinata是一家帮助人们将内容固定到IPFS网络的公司。拥有一个持久的连接可以显著提高对我们的网关的请求的性能和可靠性，以获取其网络上的内容。Pinata写了他们自己的博客文章，你可以在这里找到，它描述了如何将一个网站上传到IPFS，并使用Cloudflare和皮纳塔·阿斯一直以来，我们都期待着看到社区在我们工作的基础上构建了什么，以及听到Cloudflare如何改进互联网。