点击上方蓝字关注我们
本文由IPFS原力区收集译制，版权所属原作者
有趣的事实:如果您正在阅读本文，那么您正在使用分布式web。自2019年2月中旬以来，本博客一直通过IPFS和Cloudflare分布式Web网关提供蓝墨水服务。
去年11月，我写了一篇关于如何从IPFS运行静态网站的博客。我已经用我和我的家人使用的方式运行了几个应用程序，我觉得是时候迁移我的博客了。由于我处理了一些问题，其中一些问题将在下面解释，所以这比预期的要花的时间长一些，但是大约一个月前，我打开了(DNS)开关，并最终关闭了托管博客的单实例VM。
那个决定当时让我很焦虑，但一个月的情况看起来几乎完全好。
而黑客新闻Reddit的效果则不然
自从迁移到IPFS之后，发生了一些事情。
就在一周前，我发表了一篇关于Unicode字符串规范化重要性的博客文章，这篇文章几乎像病一样传播开来，在HackerNews的首页上排名第四，在r/programming上排名第一，并被一些流行的时事通讯收录。(谢谢你们的爱和热烈的讨论!)
然后，在周一我发布了一个新的开源项目Hereditas，它在Reddit上也得到了很好的曝光。
对于一个月平均浏览量不足3000页的博客来说，以下情况发生了:
3月13日周三，交通流量较上周同期增长5060%。在一天之内，蓝墨水的页面浏览量几乎是之前一个月的两倍。
尽管流量显著增加，以下是服务于网站的一个主要IPFS节点的CPU使用情况:
Nothing
由于通过IPFS分发内容，并通过CloudflareCDN提供服务，在流量激增5000%之后，BlueInk对性能和可用性几乎没有影响。
不仅如此:测试显示，对于世界各地的用户来说，该网站一直保持着惊人的速度。
MeetHugo
WithBlueInk是一个静态网站。我将内容写入一堆标记文件中，然后使用Hugo生成HTML页面。整个网站(内容、主题、脚本)都是开源的，并在italypalale/WithBlueInk的GitHub上发布。
当我三年前开始写这个博客时，我最初选择了Jekyll，另一个流行的静态站点生成器。但是，当我在处理向IPFS的迁移时，我必须用Hugo替换Jekyll，因为Jekyll不支持相对url。使用Jekyll，所有生成的URL都以/或固定的基本URL开始，当您通过基本URL是动态的IPFS浏览内容时，这将无法工作(请参阅我之前的IPFS指南，了解为什么这很重要)。
迁移到Hugo还带来了其他一些巨大的好处。Hugo是一个用Go编写的小应用程序，它比Jekyll(一个Rubygem)快得多。Hugo不仅在构建网站方面速度更快(实际上，它几乎是即时的)，而且由于它是一个独立的、自包含的二进制文件，所以它在CI环境中安装得更快。我的CI构建从5分钟多到不到1分钟。此外，Hugo有许多强大的、有趣的特性，并且得到了积极的维护。
MeetIPFS
星际文件系统(IPFS)是一种协议和网络，它以对等的方式分发不可变的内容。
如果您不熟悉IPFS，可以将其视为分布式CDN。一旦启动IPFS节点，就可以使用它在IPFS网络上发布文档，世界各地的其他人可以直接向您请求文档。最好的情况是，一旦有人向您请求一个文件，他们就立即开始向其他人传播它。这意味着在使用IPFS时，文档越流行，复制的就越多，因此其他人下载它的速度就越快。
通过IPFS分发文件可以非常快且非常有弹性。由于是分布式和对等的，IPFS网络能够抵抗审查和DDoS攻击。
此外，IPFS上的所有文档都是通过其内容的散列来寻址的，所以它们也是防篡改的:如果有人更改文件中的一个位，整个散列就会更改，因此地址也会不同。
IPFS的问题在于它只是一个内容分发协议，而不是存储服务。它更类似于CDN而不是NAS。我仍然需要一些服务器，目前我有3台服务器，配置在一个使用IPFS集群的集群中。它们是小型、廉价的B1msVMs(1vCPU,2GBRAM)，运行在Azure上，在世界上三个不同的区域。您可以阅读我在前一篇文章中如何设置它们。
由于使用IPFS，这个简单且相对便宜的解决方案能够提供“100%”的正常运行时间，并且具有ddos抗性。这些网站会自动复制到集群中的所有节点上，这些节点会立即开始播种这些网站，而使用分布在地理位置上的vm，全世界的用户都可以获得很高的速度。
让我们看看架构
博客的架构相对简单:
将一些新代码推送到GitHub上的主分支会触发Azure管道中的自动构建，后者克隆源代码并运行Hugo来构建网站(都是免费的!)您可以在azc管道中看到配置。回购文件中的yaml文件。
构建完成后，Azure管道将触发一个自动发布任务。发布管道有两个阶段(您可以阅读我在另一篇IPFS文章中如何配置它们):
?将文件复制到其中一个IPFSvm中，然后通过SSH调用IPFS-cluster-ctlpinadd命令将文档添加到集群中，并在所有节点上复制它们。
?调用Cloudflareapi来更新DNSLink，即TXTDNS记录_dnslink.withblue。包含网站的IPFS散列的墨水。
虽然第一阶段是自动发生的，但是在第二阶段运行之前，有一个gate需要管理员(我!)手动批准。这让我可以测试并确保网站通过IPFS成功加载(使用它的完整散列)，然后才允许任何人访问blue.ink。
发布管道完成后，任何运行IPFS守护进程的人都可以访问这个IPFS地址:
/ipns/withblue.ink
这很简单，也很容易记住。但是它只适用于那些有IPFS守护进程运行的人，或者知道如何使用网关的人(例如，尝试使用gateway.IPFS.io)。
如果您想尝试IPFS,Firefox和Chrome的IPFS-companion扩展允许您通过外部网关或内置网关轻松浏览IPFS网络。
大多数用户仍然在使用HTTP和普通的web浏览器，这时Cloudflare提供了帮助。Cloudflare网络中的边缘节点通过其(免费)分布式Web网关可以充当IPFS网关，并为通过IPFS网络发布的文档提供服务。设置非常简单，如果Cloudflare管理您的DNS，由于CNAME扁平化，您也可以使用根域名(如withblue.ink?withoutwww)!
学习从real-worldexperience
我通过IPFS提供web应用程序已经有6个月了，这个博客也有一个多月了。总的来说，我有一个积极的经验，但如果你正在考虑自己使用IPFS，那么我学到了一些值得分享的东西。
进展顺利
总的来说，依赖IPFS带来了一些有趣的好处。
通过IPFS网络为文档提供“100%”的正常运行时间。只要至少有一个对等点在提供内容，因为它最近浏览了网站(任何类型的客户端)，或者固定了它(我的三个服务器)，就可以通过IPFS访问博客。
速度:通过IPFS访问网站的用户越多，其他人访问该网站的速度就越快。
该网站还应该以一种自然的方式来抵抗ddos。
然而，实际上，大多数用户并不通过IPFS访问这个博客，而是通过Cloudflare网关通过HTTP访问它。这个方法仍然很有效:
由于IPFS中的每个文档都是不可变的，Cloudflare正在世界各地的每个edge节点中广泛缓存网站。只要DNSLink是相同的，CDN就不需要连接到上游服务器来检查新内容。来自全球多个位置的延迟测试显示一致的、快速的页面加载时间。当你的博客首页在大约3秒内加载完毕(包括图片)，并从地球上的每个角落或多或少地持续加载一个新的缓存时，这是相当令人印象深刻的。
设置非常简单。除了将CNAME指向Cloudflare网关并要求他们为我的域启用TLS证书之外，一切都很正常。不需要配置高可用性、负载平衡、跨多个服务器复制内容等。
CloudflareCDN还为您做了很多了不起的事情，包括支持HTTPS和HTTP/2.0(SPDY!)、gzipping响应等。
我学到的/还可以做得更好
HTTP在这个月已经有30年的历史了，而IPFS仍然是一项新技术。使用IPFS，有些东西的工作方式与我们习惯的不同，而另一些则根本不起作用。
IPFS不是serverless;当然也不是免费的。您确实需要至少一个服务器来播种您的数据。好消息是，您不需要大型服务器。一个易崩溃的单核VM提供了足够的CPU;但是，如果您也运行IPFS集群，则需要2GB内存。像我这样添加三个节点可能有点过火了(但这是一个很好的学习经验，而且非常有趣)。
您网站中的所有url必须是相对的。我在上一篇关于IPFS的文章中详细解释了这一点。简而言之，因为用户可以通过多个基本url访问您的网站(在我的例子中是https://withblue)。墨水/https://<网关>/施用肥料/withblue。或者https:///ipfs/)，您不能在HTML页面中使用绝对url。这也是我不得不从哲基尔转到雨果的主要原因。
正如我上面所写的，大多数用户不是直接通过IPFS浏览网站，而是通过Cloudflare。这意味着我们的实际正常运行时间取决于他们。虽然Cloudflare到目前为止对我来说运行得还不错，但他们并没有为他们的免费服务提供SLA，而且IPFS网关是否有SLA就更不清楚了。遗憾的是，目前我还没有多少访问者使用IPFS的数据，但我希望他们只是少数。
当使用CloudflareIPFS网关时，有些东西是不可用的，包括:
无法设置自定义HTTP头。在两种情况下，这可能是一个问题:当您想要启用HSTS时(根本没有办法这样做)，以及当您想手动设置内容类型时(IPFS网关根据文件扩展名确定内容类型，并使用一些启发式方法，请参阅这个问题)。
没有自定义404页面。
没有服务器端分析，甚至没有通过Cloudflare。您唯一的选择是使用像谷歌Analytics这样的托管解决方案。
我注意到的另一个问题是，当您更改DNSLink的值时，CloudflareIPFS网关并不总是可靠地清除缓存。每个人要花好几个小时才能看到最新的内容。这是迄今为止我遇到的最大问题。
在更新DNSLink值之后，可能会出现冷启动时间问题，第一个页面加载需要额外的几秒钟，但以我的经验来看，这并不太糟糕。之所以会发生这种情况，是因为Cloudflare网关中的IPFS客户机需要遍历DHT，以找到为您的内容提供服务的节点。一旦内容被复制，这就变得越来越快，到一定程度就不再是问题了。
最后，我在运行IPFS节点时遇到的一个问题是，它可以使用相当多的带宽，仅用于使网络工作(甚至不用于服务您的内容!)使用IPFS0.4.19可以极大地缓解这一问题，但是我的Azurevm仍然测量出大约160GB/月的出站流量(使用IPFS0.4.18可以测量到超过400gb的出站流量)。
上述许多问题，包括缓存、冷启动时间、服务器端分析、自定义HTTP头和404页面，都可以通过实现自定义IPFS网关而不是依赖Cloudflare来缓解。这是官方的ipfs。io网站也是如此;如果Cloudflare上的缓存问题没有得到改善，我正在考虑这个问题。
总部位于上海，深耕IPFS社区发展与商业生态建设。
Force系列产品布局IPFS商业应用，贯通视频娱乐、文件共享、浏览器入口、数据加密管理等服务，为企业与个人的使用提供一站式服务。
旗下IPFS原力区是IPFS顶级价值生态社区，聚集了众多技术大咖和IPFS爱好者，通过持续输出全面、精细、优质的IPFS咨询和技术支持，将生态中的爱好者转化为IPFS支持者和参与者，推动IPFS生态的健康发展。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。