教程：利用Cloudflare網關搭建訪問IPFS網站

原創

2018-09-29 22:26

最近，筆者的微信朋友圈被“Cloudflare網關”刷屏了，到底是怎麼回事呢？

原來在9月17日這天，IPFS項目團隊Protocol Labs發佈了一條推特，爲美國互聯網安全提供商Cloudflare的一款新產品打call。據悉，該產品可以幫助用戶更容易地訪問由Protocol Labs開發的去中心化存儲協議IPFS（星際文件系統）。

此信息一出，Cloudflare網關迅速成爲許多IPFS愛好者關注的焦點，各大新聞媒體及礦機廠商紛紛報道相關信息。

很多朋友要問了，Cloudflare的IPFS網關到底有何魅力讓協議實驗室以及衆多IPFS大佬爲其站臺宣傳呢？

筆者認爲，Cloudflare公司此次推出基於IPFS的分佈式web網關，是大型公司對與IPFS價值的又一肯定。Cloudflare是一家非常優秀的互聯網安全提供商，在國內外享有很高的知名度，這樣一個跨國公司肯定並參與到IPFS項目中，標誌着IPFS已經開始走向主流。

那麼，如何利用Cloudflare網關搭建訪問IPFS網站呢？黑螢科技從不來虛的，這次就手把手帶您體驗一番吧!

先聲明一下：本教程由黑螢科技首發，安裝部分只指針對Windows系統的用戶，其他系統安裝go-ipfs，請自行百度相關教程。

Cloudflare網關的一般使用

首先去ipfs官網下載對應版本的go-ipfs，放在任意目錄，打開cmd命令行工具，進入go-ipfs的目錄，初始化ipfs節點：

ipfs init

輸入ipfs daemon，啓動ipfs節點守護進程：

ipfs daemon

在go-ipfs根目錄下創建Cloudflare文件夾，在Cloudflare文件夾內新建一個index.html靜態頁面，內容自定義。然後重新打開一個cmd控制檯，進入go-ipfs目錄，輸入以下命令實現遞歸添加：

ipfs add -r Cloudflare

返回目錄和文件對應的hash

這個時候我們的靜態網站就被添加到ipfs主網上了，如果您能科學上網的話，就可以通過以下鏈接訪問到我們的靜態網站：

https://ipfs.io/ipfs/QmYvQQTs2Sx4cRB1k1XhAJGmYMkTygjVuTP5qizaaxtiBJ

到此爲止都和平時把文件上傳到IPFS網絡中再進行訪問一樣，如果我們不想通過ipfs.io的網關，而是用其他網關訪問也是一樣的，這裏我們就可以用CloudFlare的網關來訪問：

https://cloudflare-ipfs.com/ipfs/QmYvQQTs2Sx4cRB1k1XhAJGmYMkTygjVuTP5qizaaxtiBJ

使用cloudflare-ipfs.com網關訪問ipns也是一樣的，速度比/ipfs/要慢（ipns的解析何時能大力優化ToT），但比ipfs.io快得多：

https://cloudflare-ipfs.com/ipns/Qmb5c8NkxTk6m63tC5sKELASkNJYH1taExzoGeHD73txsU

HTTP域名通過Cloudflare網關解析到IPFS網絡

不過這並不完美，帶着QmYvQQTs2Sx4cRB1k1XhAJGmYMkTygjVuTP5qizaaxtiBJ這樣長串哈希的域名鏈接是很難讓人記憶並運用的。慶幸的是，Cloudflare充分考慮到了這一點，支持給網站自定義一個簡短好記的域名，步驟如下：

1、用於your.website指向的CNAMEwww.cloudflare-ipfs.com

2、_dnslink.your.website帶有該值的TXT記錄dnslink=/ipfs/

按照上面的步驟完成後，您就可以通過您解析的域名訪問到這個靜態網站了，如果有問題可以參考https://developers.cloudflare.com/distributed-web/ipfs-gateway/connecting-website/

Cloudflare網關爲什麼這麼好用

好了，以上的所有功能，ipfs.io上也都能實現，那麼Cloudflare還有什麼獨特之處呢？簡單來說有兩點：

1、無需使用梯子，至少目前還不用。

2、速度快！真的很快，小編用Cloudflare下載大文件都是滿速的！滿速的！速的！的！

那麼實現以上這些優點的基礎是什麼呢，我們來看一張示意圖：

我們假設有許多用戶購買了黑螢Ms.家用礦機，接入IPFS網絡成爲網絡節點，這些網絡節點的行爲不再贅述了。當我們（用戶）通過網關訪問IPFS網絡內容的時候，在沒有客戶端的情況下必須藉助網關訪問，比如ipfs.io和cloudflare-ipfs.com。這時的訪問過程大致可以分成以下幾個環節：

每個環節都有可能成爲完整交互的速度瓶頸，簡要分析如下：

1、環節一所需通信帶寬可以忽略不計，所以無需考慮其速度。

2、環節二的耗時主要受IPFS網絡可用性、文件分佈狀態的影響。

3、環節三的耗時主要受服務器帶寬、服務器位置的影響。

所以，環節二採用IPFS進行過通信，其耗時和網關無關，而環節三採用HTTP通信，我們以往分析IPFS和HTTP時所用提及的影響因素這裏也同樣適用。那麼仔細對比一下兩個網關：

l ipfs.io：（1）服務器處於美國，大陸訪問服務器的時候需要依賴國際主幹網絡。（2）我們通過這個網關獲取文件的速度不可能超過ipfs.io服務器提供的帶寬上限。

l cloudflare-ipfs.com：（1）Cloudflare本身有經營CDN業務，在全球有150多個HTTP緩存節點，在中國大陸就有21個緩存節點，根據用戶的位置，會直接由大陸的服務器來響應用戶的請求。（2）Cloudflare提供的帶寬非常巨大，速度上限極高。（3）150緩存節點之間爲CDN內部通信，十分快捷，文件在部分緩存節點上緩存過之後，其他節點再響應同個文件的請求時，可通過內部通信快速響應。