这篇文章描述了如何使用Cloudflare的IPFS网关来建立一个端到端安全的网站，同时保持Cloudflare边缘网络提供服务的性能和可靠性优势。如果您想先阅读IPFS背后的概念介绍，可以在我们的公告中找到。或者，您可以直接跳到开发人员文档，学习如何建立自己的网站。我所说的"端到端安全性"是指站点所有者和用户都不必像现在这样信任Cloudflare来提供正确的文档。这类似于使用HTTPS意味着您不必相信ISP不会修改或检查流量。使用通用SSL的CNAME安装程序第一步是为你的网站选择一个域名。网站应该被赋予自己的域名，而不是通过根哈希直接从网关提供服务，这样浏览器就可以将它们视为不同的来源。这主要是为了防止缓存中毒，但也有一些功能上的优势。它为网站提供了自己的localStorage实例和自己的cookiejar，这些cookiejar被恶意的第三方文档检查和操纵。它还允许他们无冲突地运行服务人员，并请求用户的特殊权限，如访问网络摄像头或GPS。但最重要的是，拥有域名可以使网站更容易识别和记忆。现在您已经选择了一个域，而不是按原样使用它，您需要添加"ipfs-sec"作为最左边的子域。例如，你可以使用"ipfs"-sec.example.com网站"而不是仅仅"example.com网站". ipfs-sec子域是特殊的，因为它向用户和他们的浏览器发出信号，表明您的网站能够提供端到端的完整性服务。除此之外，ipfs-sec域需要正确设置DNSSEC以防止欺骗。与标准HTTPS不同，DNS欺骗通常不会导致路径上的攻击者攻击，这正是DNS欺骗对IPFS所做的，因为网站的根哈希存储在DNS中。许多注册者只需按一下按钮就可以轻松地启用DNSSEC，尽管有些注册者根本不支持DNSSEC。使用ipfs-sec域，您现在可以按照开发人员文档了解如何从ipfs为通用静态网站提供服务。请注意，您需要使用CNAME设置并保留对DNS的控制，而不是简单地注册Cloudflare。这有助于在管理DNSSEC签名密钥的一方和向最终用户提供内容的一方之间保持适当的分离。请记住，CNAME的设置往往是有问题的，并且会遇到难以调试的情况，这就是为什么我们将它们保留给技术成熟的客户的原因。您现在应该能够通过HTTP和HTTPS访问您的网站，并得到我们的网关的支持。验证网关服务HTTPS有助于确保用户和Cloudflare的边缘网络之间没有人篡改连接，但它不能确保Cloudflare真正为用户请求的内容提供服务。为了解决这个问题，我们构建了两个相互连接的项目：一个修改的网关服务和一个浏览器扩展。首先，我们分离了go ipfs存储库，并让它能够提供加密证明，证明它是诚实地提供内容的，每当它看到HTTP报头X-ipfs-Secure-Gateway:1的请求时，它都会这样做。最简单的情况是当用户通过散列从网关请求一个文件时——网关所要做的就是提供重新计算给定哈希所需的内容和任何元数据。更复杂的情况是用户从目录请求文件。幸运的是，IPFS中的目录只是包含从文件名到文件散列的映射的文件，非常大的目录可以透明地拆分成几个较小的文件，并构造成一个名为hash Array Mapped Trie（HAMT）的搜索树。为了使客户机确信网关正在为正确文件的内容提供服务，网关首先服务于目录对应的文件，或者如果目录是HAMT，则服务于搜索路径中的每个节点。客户机可以散列这个文件（或搜索树节点），检查它是否等于他们请求的目录的哈希值，并从目录的内容中查找所需文件的哈希值。然后网关提供所请求文件的内容，客户机现在可以对其进行验证，因为它知道预期的哈希值。最后，到目前为止最复杂的情况是客户机希望通过域名访问内容。这很复杂，因为用于验证DNS的协议DNSSEC只有很少的客户端实现。DNSSEC也没有得到广泛的部署，尽管有些注册器使它比设置HTTPS更容易。最后，我们编写了我们自己的简单DNSSEC验证解析器，它能够输出一个具有密码说服力的证据，证明它正确地进行了一些查找。它的工作方式与HTTPS中的证书验证方式相同：我们从底部开始，由某个权威机构的签名声明example.com网站他们要我们提供的DNS记录。然后，我们从一个声称是.com的权威机构查找一个委托（DS记录），该机构说example.com网站"是拥有这些公钥的机构"，而这些公钥又由.com授权机构的私钥签名。最后，我们从根机构ICANN（我们已经拥有了其公钥）中查找一个委托，以证明.com权威机构使用的公钥。所有这些查询捆绑在一起形成了一个认证链，从ICANN开始，到我们想要提供的确切记录结束。这些就是证据。信任链DNSSEC公司我们构建的第二个项目是一个浏览器扩展，它从IPFS网关和IPFS sec域请求这些证明，并且能够验证它们。该扩展使用webRequest API位于浏览器的网络堆栈和它的呈现引擎之间，防止向用户显示任何意外的数据或执行意外的代码。浏览器扩展的代码可以在Github上找到，并且可以通过Firefox的插件商店安装。我们也很高兴能增加对Chrome的支持，但在他们的bug tracker中的问题得到解决之前，这一进展是无法实现的。另一方面，如果用户没有安装扩展，网关将看不到X-Ipfs-Secure-gateway头，并且将像普通网站一样提供页面服务，没有任何证据。这为使用IPFS提供了一个优雅的升级路径，可以通过我们使用第三方网关的扩展，也可以通过在浏览器中运行适当IPFS节点的另一个浏览器扩展。示例应用程序到目前为止，我最喜欢的IPFS网站是IPFS团队在protocollabs上建立的英文Wikipedia镜像。它速度快，玩起来很有趣，最重要的是有实用价值。但有一个突出的问题是，镜子没有搜索功能，所以你要么知道你想看的网页的网址，要么通过谷歌找到它。土耳其语镜像有应用内搜索功能，但它需要调用同一主机上的动态API，而且不能通过Cloudflare的网关工作，因为我们只提供静态内容。我想提供一个使用IPFS的安全、高性能的应用程序的例子，这使得构建一个搜索引擎似乎是首选。我们没有窃取协议实验室的"IPFS上的Wikipedia"的想法，而是决定收集所有不同StackExchange网站的Kiwix档案，并在此基础上构建一个分布式搜索引擎。你可以在这里玩成品：ipfs-cloudexchange.cloudexchange-ipfs.com网站.它的构建方式实际上非常简单，至少就搜索引擎而言是这样的：我们构建一个反向索引，并与每个StackExchange的其余部分一起发布，以及一个JavaScript客户端，它可以读取索引并快速识别与用户查询相关的文档。建立索引需要对数据进行两次传递：第一个过程决定了我们要允许用户搜索的单词/令牌。令牌不应该太受欢迎（比如英语中的前100个单词），因为包含该令牌的所有文档的列表将非常庞大，而且无论如何也不会改善搜索结果。它们也不应该太少（比如精度低于秒的时间戳），因为这样索引就会充满无意义的标记，而这些标记只出现在一个文档中。你可以得到一个很好的估计最频繁的K令牌，只使用常量空间，与真正简单的节省空间算法从本文。既然第一次传递给了我们要跟踪的标记，那么第二次遍历数据实际上构建了反向索引。也就是说，它构建一个从每个令牌到包含该令牌的文档列表的映射，称为postings列表。当客户机只想找到一个单词的列表时，他们只想找到一个单词的列表。这听起来没有它的效率——实际上，即使在最坏的情况下，帖子列表也很小（