学习IPFS的实际应用经验
自2019年2月中旬以来，该网站博客With Blue Ink，已通过IPFS和Cloudflare分布式Web网关提供服务。
去年11月，我发表了关于如何从IPFS运行静态网站的博客。 我已经以自己和家人使用的方式运行了几个应用程序，我觉得是时候迁移我的博客了。 由于我处理了一些问题，其中一些问题在下面进行了解释，这比预期花费的时间要长一些，但是大约一个月前我开启了（DNS）交换机并最终关闭了托管博客的单实例虚拟机。
自从迁移到IPFS以来，发生了一些事情。
一个多星期前，我发布了一篇关于规范化Unicode字符串的重要性的博客文章，这些字符串几乎是病毒式的，在Hacker News首页的第4位达到顶峰，并获得了r /编程的头把交椅，并被列入热门。 （感谢你们的喜爱和精彩的讨论！）
随后，在周一，我发布了一个新的开源项目Hereditas，该项目在Reddit上也有很好的曝光率。
对于过去每月平均少于3,000次页面浏览量的博客，这种情况发生了：
3月13日星期三，浏览量比一周前的同一天高出5,060％。在一天之内，使用Blue Ink的页面浏览量几乎是之前一个月的两倍。
尽管流量显着增加，但这是为网站提供服务的主要IPFS节点的CPU使用情况：
由于通过IPFS分发内容并通过Cloudflare CDN提供服务，With Blue Ink在5,000％的流量高峰后几乎没有对性能和可用性方面的影响。
不仅如此：测试表明，该网站对于全世界的用户来说一直非常快。
认识Hugo
Hugo是最受欢迎的开源静态站点生成器之一。凭借其惊人的速度和灵活性，Hugo使建筑网站再次变得有趣。
With Blue Ink是一个静态网站。我在一些Markdown文件中编写内容，然后使用Hugo生成HTML页面。整个网站（内容，主题，脚本）是开源的，它发布在GitHub的ItalyPaleAle / WithBlueInk上。
三年前，当我开始使用这个博客时，我最初选择了另一个流行的静态网站生成器Jekyll。但是，当我正在努力迁移到IPFS时，我不得不用Hugo替换Jekyll，因为Jekyll不支持相关的URL。使用Jekyll，所有生成的URL都以/或固定的基本URL开头，当你通过基本URL为动态的IPFS浏览内容时，这根本不起作用（有关其重要性的详细信息，请参阅之前的IPFS指南）。
迁移到Hugo带来了其他的巨大好处。 Hugo是一个用Go编写的小应用程序，它比Jekyll快得多，它是一个Ruby gem。Hugo不仅在构建网站方面更快（实际上，感觉几乎是即时的），而且由于它是一个单独的，自包含的二进制文件，它在CI环境中的安装速度也更快。我的CI构建从五分钟缩减到少于一分钟。此外，Hugo拥有许多强大而有趣的功能，并且得到了积极的维护。
认识IPFS
如果您不熟悉IPFS，请将其视为分布式CDN。启动IPFS节点后，您可以使用它在IPFS网络上发布文档，世界各地的其他人可以直接向你请求文件。最大的好处是，只要有人向您请求文件，他们就会立即开始将其播种给其他人。这意味着当使用IPFS时，文档越流行，它就复制的越多，因此其他人下载它的速度就越快。
通过IPFS分发文件可以非常快速且非常有弹性。由于分布式和点对点的特征，IPFS网络可以抵御审查和DDoS攻击。
此外，IPFS上的所有文档都通过其内容的哈希来解决，因此它们也是防篡改的：如果有人要更改文件中的任何字节，则整个哈希值会发生变化，因此地址会有所不同。
IPFS的问题在于它只是一种内容分发协议，而不是存储服务。它更类似于CDN而不是NAS。仍然需要一些服务器，我目前有三台服务器，配置在具有IPFS集群的集群中。它们是Azure上小巧，便宜的B1ms 虚拟机（1个vCPU，2 GB RAM），运行在世界各地的三个不同地区。您可以在上一篇文章中阅读设置方法。
由于使用IPFS，这种简单且相对便宜的解决方案能够提供“100％”正常运行时间并且具有DDoS抗性。 网站会自动在群集中的所有节点上进行复制，这些节点会立即开始播种，并且随着虚拟机按照地理位置分布，用户将在全球范围内获得极高的速度。
我们来看看这个架构
博客的架构相对简单：
将一些新代码推送到GitHub上的主分支会触发AzurePipeline中的自动构建，该管道克隆源代码并运行Hugo来构建网站（都是免费的！）。您可以在代码库中的azure-pipelines.yaml文件中查看配置。
构建完成后，AzurePipeline将触发自动发布任务。发布渠道有两个阶段（可以在其他IPFS文章中了解如何配置它们）：
1.将文件复制到其中一个IPFS 虚拟机中，然后通过SSH调用ipfs-cluster-ctl pin add命令将文档添加到集群并在所有节点上将其复制。
2.对Cloudflare API进行REST调用以更新DNSLink，这是一个TXT DNS记录_dnslink.withblue.ink，其中包含网站的IPFS哈希值。
当第一阶段自动开始时，在第二阶段可以运行之前，入口需要管理员（我！）进行手动批准。这让我可以测试并确保网站通过IPFS（使用其完整哈希）成功加载，然后向访问withblue.ink的任何人提供。
发布渠道完成后，运行IPFS守护程序的任何人都可以访问此IPFS地址的网站：
/ipns/withblue.ink
这很简单，也很容易记住。 但它仅适用于那些运行IPFS守护程序或知道如何使用网关的人（例如，尝试使用gateway.ipfs.io）。
如果您想要尝试IPFS，Firefox和Chrome的ipfs-companion扩展可让您轻松浏览IPFS网络，使用外部网关或内置网关。
大多数用户仍在使用HTTP和普通的网络浏览器，这就是Cloudflare提供帮助的时候。 通过其（免费）分布式Web网关，Cloudflare网络中的边缘节点可以充当IPFS网关，并提供通过IPFS网络发布的文档。 设置非常简单，如果Cloudflare管理您的DNS，由于CNAME扁平化，您也可以使用根域（例如withblue.ink without www）！
从真正的经验中学习
我已经通过IPFS服务网络应用程序六个月了，这个博客已经有一个多月了。 总的来说，我有一个良好的体验，但如果您正在考虑自己使用IPFS，我已经学到了一些值得分享的东西。
总的来说，依靠IPFS已经带来了一些有趣的好处。
通过IPFS网络获得文档的“100％”正常运行时间。 只要至少有一个节点提供内容，由于它最近浏览过该网站（任何类型的客户端），或者已将其固定（我的三台服务器），就可以通过IPFS访问该博客。
速度：通过IPFS访问网站的用户越多，其他人就越快。
该网站也应该以自然的方式抵抗DDoS。
但实际上，大多数用户不通过IPFS访问此博客，而是通过Cloudflare网关通过HTTP（S）访问。但仍然运行得相当好：
由于IPFS中的每个文档都是不可变的，因此Cloudflare会在全球各个边缘节点中广泛缓存网站。 只要DNSLink相同，就不需要CDN连接到上游服务器来检查新内容。 来自全球多个地点的延迟测试显示了一致，快速的页面加载时间。 当你的博客首页在大约3秒钟内加载完成时（包括图像），并且从地球的每个角落或多或少地保持一致的新缓存，这是非常令人印象深刻的。
设置非常简单。 除了将CNAME指向Cloudflare网关并要求他们为我的域启用TLS证书之外，一切都还顺利。无需配置高可用性，负载平衡，跨多个服务器复制内容等。
Cloudflare CDN也为提供了很棒的功能，包括支持HTTPS和HTTP / 2.0（SPDY！），gzipping响应等。
HTTP截至本月已经三十岁了，而IPFS仍然是一项新技术。使用IPFS，有些东西的工作方式与我们习惯的不同，如果相同也根本就不起作用。
IPFS不是无服务器的;它也绝对不是免费的。您确实需要至少一台服务器为您的数据播种。好消息是你不需要大型服务器。一个可扩展的1核虚拟机提供足够的CPU;但是，如果您正在运行IPFS群集，则需要2 GB的内存。像我一样添加三个节点可能会有点超负荷（但这是一次很棒的学习经历 - 非常有趣）。
网站中的所有网址都必须是相对的。我在上一篇关于IPFS的文章中详细解释了这一点。简而言之，因为用户可以从多个基本URL访问你的网站（例如，https://withblue.ink/，https://<gateway>/ipns/withblue.ink或https://<gateway>/ipfs/<ipfs-hash>），不能在HTML页面中使用绝对URL。这也是我不得不从jekyll换到hugo的主要原因。
正如我上面所写，大多数用户不直接通过IPFS浏览网站，而是通过Cloudflare浏览网站。这意味着我们的实际正常运行时间取决于Cloudflare。虽然到目前为止Cloudflare对我来说效果不错，但他们没有为他们的免费服务提供SLA，而且如果IPFS网关有SLA则会变得含糊不清。可悲的是，我目前没有关于使用IPFS的访问者数据，但我认为他们只占少数。
使用Cloudflare IPFS网关时，某些内容不可用，包括：
无法设置自定义HTTP标头。在两种情况下，这可能是个问题：当您想要启用HSTS（根本就没有办法）时，以及当您想手动设置内容类型时（IPFS网关从文件扩展名中确定内容类型并使用某些启发式内容类型，查看此问题）。
没有自定义404页面。
没有服务器端分析，甚至没有通过Cloudflare。您唯一的选择是使用Google分析等托管解决方案。
我注意到的另一个问题是，当您更改DNSLink值时，Cloudflare IPFS网关并不能总是可靠地清除缓存。每个人都需要几个小时才能看到最新的内容。这是迄今为止我遇到的最大问题。
更新DNSLink值后，可能会出现一些冷启动时间问题，第一页可能需要额外几秒才能加载，但根据我的经验，这并不算太糟糕。发生这种情况是因为Cloudflare网关中的IPFS客户端需要接入DHT以查找为您的内容提供服务的节点。一旦内容被复制，速度就变得越来越快，到目前为止不再是一个问题。
最后，我在运行IPFS节点时遇到的一个问题是，它可以使用相当大的带宽，只是为了使网络运行（甚至不用于提供你的内容！）。 IPFS 0.4.19已经大大减轻了带宽的消耗，但我的Azure虚拟机仍在测量大约160GB /月呼出量（IPFS为0.4.18时超过400 GB）。
上述许多问题，包括缓存，冷启动时间，服务器端分析，自定义HTTP标头和404页面，都可以通过执行自定义IPFS网关来缓解，而不是依赖于Cloudflare。官方ipfs.io网站也是这样做的;如果在Cloudflare上缓存的问题没有改善，我正在想办法处理。
相关文章
头条焦点
精彩导读