IPFS网关如何使用？一键get高性能“挖矿”新优势

这是玛雅矿机的第191篇文章

我们之前写过一篇相对简略的关于Cloudflare-IPFS网关发布的文章，今天就怎样使用Cloudflare的IPFS网关以建立端到端安全的网站，还有Cloudflare边缘网络提供的性能与可靠性的优势保持，两大方面进行阐释，具体使用教程请往下看。

通过“端到端安全性”的方式，网站所有者与用户都无需依赖Cloudflare来提供正确的文档。这就相当于使用HTTPS的方式但并不需要信任所用的ISP修改或流量检查。

用通用SSL进行CNAME设置

首先为你的网站选择一个域名。使用自己的域名，而非用root哈希直接从网关提供的，这将被浏览器视为不同的来源。这样做的目的是防止缓存中毒，其中也有一些功能优势，它给网站提供了自己的localStorage实例，还有cookie jar，这些cookie都是通过恶意第三方文档的检查和操作进行沙盒处理的。此外，还允许无冲突地运行Service Workers，并允许用户的特殊权限请求，举例，如是否访问网络摄像头或者GPS等。最重要一点是，拥有域名能使网站更易于识别与记忆。

选择一个域之后，不要按原样使用，需添加“ipfs-sec”作为最左侧的子域。比如使用“ipfs-sec.example.com”而不仅是“example.com”.ipfs-sec拥有特殊的子域，它会向用户和浏览器发出信号，表明我们使用的网站能够提供端到端的完整性。

另外，ipfs-sec域还需正确设置DNSSEC，以此防骗。与标准HTTPS不同，DNS的欺骗往往不会导致中间人攻击，这恰是DNS欺骗对IPFS的影响，原因是网站的根Hash存储在DNS中，很多注册商令启用DNSSEC像按下按钮一样简单。

如果使用ipfs-sec域，可按照开发人员文档了解怎样从IPFS提供通用静态网站。需要注意的是，由于CNAME设置常会出现问题并进入难以调试的情况，要使用CNAME设置并保留对DNS的控制权，而不仅是注册Cloudflare的简单操作。这样在管理DNSSEC签名密钥方与向最终用户提供内容方，能够保持合适的分离，然后就可以通过网关支持的HTTP和HTTPS访问网站了。

网关服务内容的验证

HTTPS能够帮助确保用户和Cloudflare边缘网络之间无人篡改连接，但还无法确保Cloudflare事实上为用户要求的内容提供服务。开发人员构建了两个连接项目来解决这个问题，一个是修改后的网关服务，一个是浏览器扩展。

开发人员先是分叉了go-ipfs存储库，并使其能够提供加密证据，证明它正在诚实地提供内容，只要它见到带有HTTP标头的请求，就会进行X-Ipfs-Secure-Gateway:1的运算。当用户通过其散列从网关请求单个文件时，全部网关必做的是提供内容，还有重新计算给定散列所需的所有元数据。

有些比较复杂的情况，即用户从目录请求文件。IPFS中的目录只是包含从文件名到文件Hash的映射的文件，较大的目录可透明地被分成多个小文件，构造成一个名为Hash Array Mapped Trie（HAMT）的搜索树。

为了说服客户端网关正在提供的正确文件内容，网关先要提供与目录对应的文件，如果目录是HAMT则提供搜索路径中的每个节点。客户端可以散列此文件，检查它是不是相当于他们要求的目录的散列，然后在目录内容中查找想要的文件散列。接着网关提供所请求文件的内容，客户端就能验证该文件了，因为它知道预期的Hash。

迄今最复杂的一种情况是，客户希望通过域名访问内容。由于极少有客户端能够实现用于验证DNS的协议（以下称为DNSSEC），尽管一些注册商比设置HTTPS更容易，DNSSEC也没有得到广泛部署。最终，我们编写了自己的简单DNSSEC验证解析器，它能够输出一个令人信服的加密证据，证明自己正确地进行了某查找。

它的工作方式与HTTPS中的证书验证方式相同：从底部起始，有些权威机构的签名声称是他们希望被提供的DNS记录example.com.开发人员则称是.com的权限中查找委托，其中说“example.com是具有这些公钥的权限”，而该权限又由.com权限的私钥签名。最终从根权限ICANN中查找授权，证明.com权限使用的公钥。捆绑在一块的全部这些查找，形成一个经过身份验证的链条，从ICANN开始，到我们想要服务的确切记录结束就构成了证明。

DNSSEC中的信任链

IPFS构建的第二个项目是浏览器扩展，它从IPFS网关与ipfs-sec域请求这些证明，前提要能够验证。这个扩展使用webRequest API位于浏览器的网络堆栈，以及其呈现引擎间，防止向用户显示一切意外数据抑或执行意外代码。通过火狐的附加存储安装，浏览器扩展的代码能在Github上获得。

此外，若用户不安装扩展程序，网关也将看不到X-Ipfs-Secure-Gateway标题，并把像普通网站那样提供页面，但不需要任何证据。想要为使用IPFS提供了一个较好的升级路径，能通过使用第三方网关的扩展，或者在浏览器中运行正确IPFS节点的其他浏览器扩展。

示例应用

协议实验室IPFS团队提出的英语维基百科的镜像就是IPFS的一个应用，它快捷有趣也很实用。不过，镜像无搜索功能，要查看页面的URL或尝试通过Google才能找到它。在土耳其语镜下，在应用内搜索，它需要在同一主机上动态API的调用，并且不会通过CloudFlare的网关工作，原因是IPFS只提供静态内容。

开发人员采用所有不同StackExchange网站的Kiwix档案，并基于此构建分布式搜索引擎，这些是IPFS可能实现的各种安全，高性能应用程序的示例。

事实上，它的构建方式很简单。就搜索引擎而言，开发人员构建一个倒排索引并将其与每个StackExchange的其余部分一起发布，以及一个能读取索引并快速识别相关文档的JavaScript客户端到用户的查询。构建索引需要对数据进行两次传递：

第一遍是确定允许用户搜索的单词/标记。token不该太多，因为那时包含该token的所有文档的列表将很巨大，且它无论如何都不会改进搜索结果。它们也不应该太罕见，因为那时索引将充满无意义的token，每个token只出现在一个文档中。我们可以得到最频繁k token的一个很好的估计，仅仅使用恒定的空间，从非常简单的节省空间的算法。

第二遍传递数据实际上构建了倒排索引。它构建了从每个token至包含该token的文档列表的映射，称为发布列表。当用户希望仅查找包含一组单词/标记的文档时，他们会下载每个单独标记的列表并令其相交。这听起来效率低于实际效果，事实上，即使做最坏的打算，帖子列表也很小（

每个帖子列表中存储一些简单的统计信息，用来帮助对结果进行排名。从本质上说，包含查询token的文档的排名通常高于不包含查询token的文档。在查询中标记中，出现在较少文档中的标记对排名的影响大于许多文档中出现的标记。这就是为什么当搜索“AES SIV”时，第一个返回的结果是：如果MAC-and-encrypt不是最安全的方式，为什么SIV会成为事？以下是第四个结果，即使它的得分与总命中数高于第一个结果：为何不使用AES-SIV，而是AESKW，AKW1？其中，AES是一种非常流行且经常讨论的加密算法，而SIV是一种鲜为人知的AES方法。

由于搜索索引存储在IPFS中，用户可以说服自己没有修改，重新安排或省略任何结果而无需下载整个语料库。有一个小技巧可以使这个陈述成立：搜索客户端发出的所有请求都必须成功，若不成功则输出错误而没有搜索结果。

为什么呢？因为它必须对查询进行标记化并确定要下载哪些发布列表，而不是可以将用户查询中的所有单词编入索引。一个天真的解决方案是尝试无条件地下载每个单词的发布列表，并把非200HTTP状态代码解释为“此发布列表必须不存在”。在这种情况下，网络攻击者可以阻止搜索客户端访问导致不良结果的发布列表，从而导致客户端通过省略或重新安排输出误导性搜索结果。

我们所做的是将每个索引标记的字典存储在索引根目录中的文件中，客户端能下载一次字典并缓存，接着把它用于每次搜索。这样，搜索客户端可以查阅字典以找出哪些请求应该成功并且仅发送那些请求。

虽然IPFS网关和浏览器扩展需要一些时间才能成熟，并形成一个安全可靠的平台。但能够意识到将IPFS与Cloudflare结合起来的新途径和应用类型时，是很值得兴奋的。同时，通过第三方托管服务提供商和CDN安全地提供网页的能力非常强大，而密码学家和互联网安全专业人员长期以来一直在努力。

玛雅云算力已经重磅上线！玛雅云算力采用玛雅矿机D1、玛雅1号比特云算力、玛雅2号比特云算力等市场领先的矿机与超强算力，同时使用自建专业的托管矿场，每笔订单清晰可见，绝对透明放心的用户承诺和最佳的性价比，让用户没有后顾之忧的享受更低的投入、更便捷的操作和更高的收益回报！

玛雅云算力在公众号的首页菜单就可一键进入官网哦，感兴趣的朋友请持续关注“玛雅矿机”公众号，更多相关资讯尽在其中！

扫描二维码，进入公众号咨询