IPFS-星际文件传输系统

【应用】(进阶)基于IPFS和Ngrok构建自维护资源网关

2018-04-21  本文已影响40人  嘉乐的SOHO

一、背景

上篇文章《【应用】(入门)基于IPFS和Ngrok构建自维护资源网关》,我们通过Ngrok为IPFS节点配置HTTP Tunnels,充分利用了其NAT穿越的特性,成功搭建了属于自己的资源网关,为他人提供IPFS节点服务。但是这仅仅是一个雏形,缺陷还很多,这篇文章来讲解对资源网关的种种优化和配置。

二、意义

之前一些朋友问到了这件事的意义,这边简单梳理了一下,我认为对于IPFS这块的开发者,需要部署私有集群的DevOps,以及未来想组建Filecoin矿场的矿工,这件事情都相对比较必要,具体如下:

2.1 IPFS资源网关的意义:

2.1.1. 目前主流浏览器还未全面支持 ipfs:// 协议,需要安装专门的客户端/插件

2.1.2没有安装IPFS Desktop,也可以通过HTTP方式与IPFS网络产生交互来获取IPFS 网络的内部资源。

2.2 自维护的意义:

2.2.1 ipfs.io 默认网关存在DNS污染现象:

ipfs.io IP解析所在的物理位置位于美国 ThePlanet机房

image

在国内,对ipfs.io的ping请求被解析为31.13.72.34 IP

image

此IP所在物理地址为:爱尔兰Fackbook分公司


image

ipfs.io存在DNS污染现象

2.2.2 默认的Bootstrap都是指向官方提供的节点:DigitalOcean 云计算中心

image

如果需要构造自己的IPFS私有网络,需要为本地的私有节点添加反向代理

2.2.3 增强网关访问安全性,将资源服务与代理服务用防火墙隔开

image

2.2.4. 官方提供的 Public Gateway 稳定性感人

两个月前的:

image

最近看了一下:

image

三、优化与进阶

3.1 个性公网域名+IPNS挂载

上传Hash为QmdzsNmvKiKQve8z15gamNo5s31g9bTWhzBg9SKG1YKTow的IPFS资源,并挂载到本地NodeID为QmeUGXG4K4hbNPbKDUycmNsWrU3nDN69LLgHkWU2yUN6FZ的IPNS上,如下图所示:

image

开放网关,进行效果对比测试:

image image

监控NAT请求效果:


image

一次个性公网域名(需要在Ngrok付费申请)+ IPNS挂载就完成了

多节点 IPNS 更换的方案

这边也介绍下多节点 IPNS 更换的方案,方便一些朋友更新网关资源的同时也可以保证对外的IPNS一致性:

ipfs key gen --type = rsa --size=2048 mykey 
ipfs name publish --key=mykey hashA
ipfs name publish --key=mykey hashB

3.2 网关资源优化 (缓存/带宽优化等)

3.2.1 针对同IPFS网络资源请求方:

设计了一种缓存自启动方案,解决存储和请求过程中的资源复用消耗:

st=>start: IPFS寻址请求(HTTP网关入口)
e=>end: 输出资源
op1=>operation: 提取Hash
op2=>operation: DHT匹配
op3=>operation: 写入Cache Record
op4=>operation: 以本地网关(localhost形式)
op5=>operation: 对DHT进行更新
op6=>operation: 以自建网关(Ngrok生成)

c1=>condition:  DHT匹配
c2=>condition: NodeID一致

sub1=>subroutine: My Subroutine|invalid
io=>inputoutput: catch something...|request

st->op1->c1
c1(yes, right)->c2
c1(no, right)->op3
c2(yes, right)->op4
c2(no, right)->op5
op3->op5->op6->e
op4->e

3.2.2 针对外部HTTP网络资源请求方:

设计了一种防作弊,解决过多带宽资源消耗的方案:

st=>start: IPFS寻址请求(HTTP网关入口)
e=>end: 以自建网关(Ngrok)输出资源
e2=>end: 拒绝本次请求(理解为短时间频繁恶意),节约带宽
op1=>operation: 自动降级Service(PHP APC实现)
op4=>operation: 慢请求数++
op5=>operation: 定期重置统计周期
op6=>operation: 设置降级标志(apc_add($is_degraded))
op7=>operation: 设置10s冷却时间($is_degraded 10秒失效)

c1=>condition: 是否降级标志(apc_fetch($is_degraded))
c2=>condition: 处理资源效率(kb/s)是否超过阈值
c3=>condition: 是否达到慢请求数阈值


st->op1->c1
c1(no, right)->c2
c1(yes, right)->e2
c2(yes, right)->op4
c2(no, right)->op5
c3(yes, right)->op6
c3(no, right)->op5
op6->op7->op5->e
op4->c3->e

这块一定注意区分两个场景概念:

优化方案按照不同场景有不同策略,之前很多朋友搞不清楚(确实,也容易混淆)。

3.3 自动化控制资源的分享权限

有时候针对我们自己构建的私有IPFS网络,需要将资源外放,但是外放需要策略来进行自动化控制(集成在业务环境里)

3.3.1 举个很简单的场景实例

我编写的业务应用需要接收到特定以太坊智能合约的转账回调函数,来自动开启对应智能合约中IPFS资源外放的开关

(eg:只有当买家遵守以太坊的智能合约支付了一定数量的ETH或者其他ERC2.0代币后,才能解锁获取到我存储在IPFS网路中的自拍照)

但这个IPFS网络往往很多时候是我自己部署的私有集群(不会搭建私有网络的朋友可以参考董哥的:IPFS指南: 私有网络(private network)的搭建与使用),默认对外是不提供公共的寻址网关的,我该如何控制?

3.3.2 资源分享权限实现

这边我们可以充分利用Ngrok的Client Restful API来对NAT进行自动化收放,从而实现整个业务场景下的程序化控制:

st=>start: 公链合约池
e=>end: 返回合约池
op1=>operation: 针对每次合约请求的回调
op2=>operation: 合约IPFS资源触发器
op3=>operation: 请求IPFS Swarm
op4=>operation: Start Tunnel
op5=>operation: Stop Tunnel

c1=>condition: Ngrok Client Restful API
c3=>condition: 是否达到慢请求数阈值

st->op1
op1->op2->op3
op3->c1
c1(yes, right)->op4->e
c1(no, right)->op5->e


3.3.3 Ngrok的Client Restful API Postman测试

image

四、IPFS资源网关应用面

当然这块还有很多的实践价值和我未曾想到的场景,欢迎对这块有兴趣继续研究的朋友一起交流,联系方式在文尾。

转载声明:特别鸣谢天一哥(飞向未来 IPFS指南公众号作者)ipfser.org早期在IPFS大量的布道工作,才有了博主致力于IPFS应用实践的想法,期望更多和我们一样对这个领域感兴趣的朋友能加入进来。

本文章版权归博主daijiale.cn所有,若想转载请联系作者授权,未经授权,禁止转载,如若发现,将通过个人律师以侵犯《中华人民共和国著作权法》起诉(奉陪到底),授权转载也请注明原出处。

已授权转载的公众号和媒体网站有:

欢迎对这块有兴趣的朋友加微信联系方式如下:

http://career-pic.oss-cn-beijing.aliyuncs.com/my-certificate/wechat-qrcode.jpeg

也欢迎加入我的知识星球:

五、参考文献

上一篇下一篇

猜你喜欢

热点阅读