Cloudflare 服務暫時中斷，及它和 Web3 的關係。
Cloudflare 是一家於 2019 年上市的 CDN 和安全服務公司，不過 2022 年 6 月 21 日（週二）因為它的服務暫時中斷，影響了大量的服務和平台正常運營。包括 FTX，Discord，Omegle，DoorDash 等等。
本篇文章，會講一下什麼是 CloudFlare，到底是個什麼公司，CloudFlare 和 Web3 的緣起，以及從技術上解釋一下本次故障的原因。
注: 本文版權歸原作者阿法兔所有，未經原作者允許不得轉載本文內容，否則將視為侵權，轉載或者引用本文內容請註明來源及原作者，以及本文所有引用文獻需一併轉載。本文內容僅用於信息展示和分享，不對任何經營與投資行為進行推廣與背書，本文不提供任何投資建議。
作者：阿法兔
提示：本文約 5000 字左右，閱讀時間需要 15-20 分鐘左右。
原用標題： Web3 底層基建？簡析昨天 CloudFlare 服務中斷的原因
本文結構
1. 事件背景
- 2022 年 6 月底（本週二）發生了什麼？
2. 什麼是 CDN（內容分發網絡）
- 什麼是 CDN
- 什麼是路由
- CDN 公司通常都是安全公司？
3. Cloudflare 是個什麼公司？4.Cloudflare 和 Web3 的緣起
- IPFS&以太坊
5. Cloudflare 為什麼會發生服務中斷？（技術分析部分）
- 和架構轉型有關
- 本次服務終端的時間線和背景
- 補救和後續步驟
- 結論
事件背景
6 月 21 日（週二）發生了一件事，就是因為 Cloudflare 的服務暫時中斷，影響了大量的服務和平台正常運營。包括 FTX，Discord，Omegle，DoorDash，Crunchyroll，NordVPN 和 Feedly 等等、還有 Zeroda，Medium.com，新聞媒體 Register，Groww，Buffer，iSpirt，Upstox 和 Social Blade 的，用戶無法訪問這些網站，甚至 Coinbase，Shopify 和英雄聯盟也受到了部分影響。
本篇文章，會講一下什麼是 CloudFlare，到底是個什麼公司，CloudFlare 和 Web3 的緣起，以及從技術上解釋一下本次故障的原因。
什麼是 CDN（內容分發網絡）
在講 Cloudflare 之前，我們先普及一個概念（CDN）
什麼是 CDN？
CDN，全稱為 Content Distribute Network(內容分發網絡) 或者 Content Delivery Network；那麼，什麼是內容分發網絡呢？是可以通過互聯網互相連接的電腦網絡系統，利用最近每位用戶的服務器，更快、更可靠地將音樂、圖片、視頻、應用程序及其他文件發送給用戶，來提供高性能、可擴展性及低成本的網絡內容傳遞給用戶。
形象的說，CDN 有點類似於京東物流模式，通過在全國各地建立物流點 (緩存服務器)，當有人從京東購買貨物時 (用戶資源請求)，京東上次可以根據用戶的收貨地址 (CDN 進行用戶域名解析) 找最近的或者最快的一個物流點進行派送 (將訪問用戶連接到最近的緩存服務器進行資源傳輸)。
CDN 服務可用於確保快速可靠地分發靜態內容，這些內容可以緩存，最適合在網速龐大的網絡中存儲和分發，這樣就能把主幹網絡通道空出來給必須實時傳輸的動態內容，比如網絡直播，降低時延。
我們舉個例子，比如有一家英國公司，主要客戶也在英國，如果給這家公司建立網站，那麼，通常會把網站服務器放在英國。但是，會存在延遲這樣的情況，影響用戶們的網站訪問體驗，不過，如果延遲是由於網絡阻塞導致的，那麼這種延遲是可以改善的。具體怎麼改善呢？
主要是通過提高點到點之間的帶寬、優化網絡路由來解決這些問題。舉個例子，比如從倫敦到牛津，增加這兩地之間光纖的數量，就是最容易的提高帶寬方法。
注意，這裡光纖數量主要是我們建設基礎設施如海底光纜、鐵路和高速公路的時候，同時鋪設的。因此，這些年我們用的帶寬一直在增加，你可以把增加網絡貸款理解為拓寬交通公路，就是個花錢鋪設的事情。
路由
我們前面提到過網絡路由，路由是啥呢？其實路由解決的主要問題，就是兩點之間的通信，究竟走什麼線路的問題。舉個例子，一旦倫敦到牛津的出現網絡堵塞，系統還可以選擇其他路由。有點像智慧交通，互聯網的路由優化也類似。所以這些年，儘管流量越來越大，但是網絡性能也是一直在改善的。
通俗一點講，就是給網站加速，部分網站由於原因使得打開變得極為緩慢，這就需要用 CDN 來進行加速。
CDN 也是一類較為先進網絡技術，解決內容在互聯網上的分發問題。什麼是內容分發網絡呢？這與交通網絡類似，也就是說，再快的飛機，也是有速度上限的，距離越遠，延遲越長。網絡也一樣，如果距離遠，就會出現網絡延遲的情況。
所以如果某個歐洲用戶想要訪問美國網站的內容，CDN 就是在歐洲建立一個服務器，把美國的內容翻譯到這個服務器。當歐洲用戶進入域名訪問時，由於 CDN 運營商知道這個用戶訪問來自歐洲系統，就把歐洲服務器的 IP 地址給這個用戶，用戶自然就訪問到歐洲的服務器了。
CDN 公司通常都是安全公司？
屬於 CDN 一個重要特點，是 CDN 天生具備安全屬性，因為 cdn 對哪些人在訪問用戶的網絡非常清楚，因此，可以幫助客戶阻擋網站攻擊。網絡安全是 cdn 公司的一項增值服務，儘管 cdn 的出現，遠遠早於雲計算，但是目前大家已經把 cdn 歸類成雲計算，原因是用戶通常會根據使用量，來對 cdn 服務進行按月付費和按照流量付費，這其實屬於典型的雲計算訂閱模式，同時 cdn 的服務器也不一定就是傳統的物理服務器，這些服務器可能也是來自公有云運營商的虛擬機，所以現在你完全可以把 CDN 看成一個雲計算的 IaaS 服務。
注：本部分關於 CDN 的解釋內容，部分來自於 Youtube 博主老科談科技股
Cloudflare 是個什麼公司？
2010 年，Cloudflare 正式創立，總部位於美國舊金山。是一家以其 CDN 和安全服務為主營業務的公司，Cloudflare 公司的主營業務是向客戶提供基於反向代理的內容分發網絡及分佈式域名解析服務（Distributed Domain Name Server）。從 2009 年開始，該公司由 Union Square Ventures 等風險投資參投，百度也參與了 Cloudflare 的 D 輪融資, 2019 年 8 月 15 日，Cloudflare 正式 IPO。
除此之外，Cloudflare 收購了一系列網絡服務和安全公司，2014 年收購 StopTheHacker 、CryptoSeal；2016 年收購 Eager Platform Co.；17 年及以後收購 Neumob、S2 Systems、Linc、Zaraz；今年收購了 Vectrix 和 Area 1 Security.
Cloudflare 和 Web3 的緣起
Cloudflare 是比較早就開始支持 Web3 開發的 CDN 公司，它的官網是這麼說的：Cloudflare 是用戶通往 Web3 的門戶，通過 Cloudflare，可以輕鬆訪問 IPFS 和 Ethereum 網絡。並且，官網提到，Web 1.0 讓世界有了快速傳播信息的能力，而 Web 2.0 則讓這些信息具有互動性。Web 3.0，或 Web3，被認為是互聯網的下一次迭代，建立在 IPFS 和以太坊等去中心化的技術之上。
Cloudflare 具備 IPFS Gateway，客戶可以在繼續使用 HTTP 協議的時候，同時享受 IPFS 的好處。
Cloudflare 以太坊網關允許客戶使用自己的域, 可以通過 HTTP 的 JSON RPC 查詢發送到自定義域名。Cloudflare 可以管理、維護和監控 Web3 基礎設施，構建者可以專注於重要的事情：構建 Dapp。Cloudflare 可以通過行業內領先的全球網絡，創建基於 Web3 技術的安全、可靠和快速服務。
Cloudflare 為什麼會發生服務中斷？
2022 年 6 月 21 日的 Cloudflare 服務中斷事件的官方解釋：
2022 年 6 月 21 日，Cloudflare 服務中斷，影響了 19 個數據中心的正常運行，而不幸的是，這 19 個地點處理了 Cloudflare 很大一部分全球數據。這次服務中斷是由一個長期運行項目出現的問題引起的，這個項目主要是想提高最繁忙數據中心的彈性而發起的。是因為，更改了部分位置的網絡配置，而導致服務中斷，中斷的具體時間是從 UTC 時間 06：27 開始，到了 06：58 UTC，第一個數據中心重新開始工作，到 07：42 UTC，所有數據中心都可以正常工作。根據用戶在世界上的不同位置，可能無法訪問依賴 Cloudflare 為基礎設施的網站和服務，不過在其他沒有受影響的地點，Cloudflare 繼續正常運行。
對此次中斷，Cloudflare 深表歉意，這是 Cloudflare 的錯誤，而不是因為攻擊或其他惡意活動的。
本次架構轉型的背景
在過去 18 個月，Cloudflare 一直致力於將所有最繁忙的數據中心的架構轉型，讓它們更為靈活、且更具彈性。目前，已經有 19 個數據中心，成功轉換為此架構，Cloudflare 內部稱其為 Multi-Colo PoP（MCP）; 這 19 個數據中心分別位於：阿姆斯特丹，亞特蘭大，阿什本，芝加哥，法蘭克福，倫敦，洛杉磯，馬德里，曼徹斯特，邁阿密，米蘭，孟買，紐瓦克，大阪，聖保羅，聖何塞，新加坡，悉尼和東京。
這個新架構被設計成 Clos 網絡，它的一個關鍵部分是增加了一個額外的路由層（見下圖），創造了一個網狀的連接。這個網狀結構使我們能夠輕鬆地禁用和啟用數據中心的部分內部網絡，以便進行維護或處理問題。這一層由下圖中標識為的 Spine 部分錶示。
注：Clos network 是一種多級交換網絡，由 Charles Clos 於 1953 年首次正式使用該術語，它代表了實際多級電話交換系統的理想化表示。當物理電路交換的需求超過了單 crossbar switch 的最大可實現容量的時候需要使用 Clos network。Clos network 的主要優勢點在於：所需的交叉點數量遠小於整個交換系統使用一個大的 Crossbar Switch 來實現所需的交叉點數量。
這種新的架構顯著改善了 Cloudflare 的可靠性，可以使 Cloudflare 能夠在這些地方進行維護，並且不中斷客戶流量。不過，由於這些地點同時也承載著 Cloudflare 流量的很大部分，任何這裡的問題都會產生非常廣泛的影響，不幸的是，這就是 6 月 21 日 Cloudflare 服務終端的原因所在。
服務中斷的時間線和影響
Cloudflare 應用了名為 BGP 的協議 (邊界網關協議，Border Gateway Protocol，是運行於 TCP 上的一種自治系統的路由協議 )。該協議的由運營商定義政策，決定有哪些前綴（相鄰 IP 地址的集合）會被廣播給對等的節點（他們連接的其他網絡）。這些策略有單獨的組成部分，按順序進行評估。最終的結果是，任何給定的前綴要么被廣播，要么不被廣播。政策的變化可能意味著以前會廣播的前綴不再被廣播，被稱為"撤銷"，這些 IP 地址將不再能在互聯網上正常運行。
運營商制定了某種策略，決定某些路由前綴可以被廣播（這裡的廣播指的是，路由可以被其他邊緣 bgp 路由器學習到，進而其他的 bgp 網絡知道這些路由變化，前綴就是 prefix，是用來唯一地標識著連入 Internet 的一個網絡號）
前綴通告策略更改時，術語的重新編排，導致 Cloudflare 必須撤回前綴的關鍵子集。
政策的變化可能意味著以前會廣播的前綴不再被廣播，Cloudflare 工程師在受影響的數據中心，對有問題部分進行恢復時，就遇到了額外困難，不過 Cloudflare 有處理此類問題的備份程序。
03：56 UTC：Cloudflare 將更改部署到第一個（數據中心）位置，所有位置都沒有受到此次更改的影響，因為這些位置使用的舊的架構。
06：17：部署更改到 Cloudflare 最繁忙的地點，但是沒有部署到具備 MCP（Multi-Colo PoP）體系結構的位置。
06：27：部署到達了啟用 MCP（Multi-Colo PoP）的位置，並且更改已部署到關鍵部位。這是服務中斷事件開始的時候，這個時候，19 個數據中心迅速離線。
06：32：Cloudflare 內部宣布本次服務中斷事件。
06：51：在路由器上進行的首次更改，以驗證根本原因。
06：58：排查故障，找出根本原因，還原出現問題的部分
07：42：最後一次還原已完成，網絡工程師開始檢查對方的更改，還原狀態，此時問題偶爾重新出現，因此延遲了一點。
08：00：服務中斷事件結束。
這些數據中心的重要性，可以從下圖全球範圍內處理的成功 HTTP 請求的數量中清楚地看出：
儘管這些出問題的數據中心，僅佔 Cloudflare 總網絡的 4%，但這次中斷影響了總請求的 50%；
（本部分有小部分代碼，此處略去，感興趣的網絡工程小伙伴可查看原文：
補救和後續步驟
本次服務終端事件造成了廣泛且嚴重的影響，Cloudflare 一貫對可用性是非常重視，目前已經提出了幾個需要改進的領域，而後將繼續努力，發現可能潛在導致服務終端的所有問題。
流程：雖然 MCP 計劃旨在提高可用性，但我們在更新這些數據中心方面的程序性差距，導致造成了嚴重影響。雖然 Cloudflare 確實為設計了交錯策略，但是它並不完美，部署過程和自動化中，需要包含 MCP 的測試和具體部署過程，以確保不會產生意外後果。
架構：路由器配置的錯誤會阻止正確的路由廣播，從而阻止了正常流量和基礎設施的運行。Cloudflare 將會重新設計路由廣播的策略語句，防止排序的錯誤。
自動化：Cloudflare 自動化套件中有可以降低此事件負面影響的部分。Cloudflare 將專注於自動化改進，為網絡配置的推出強制實施改進的交錯策略，並提供自動"提交-確認"回滾。前者將大大降低整體影響，後者將大幅度減少事件中的解決時間。
結論
儘管 Cloudflare 在 MCP 架構設計上投入了大量資金，提高服務可用性，但在本次服務中斷事件中，讓客戶失望了。對於服務中斷期間，無法訪問互聯網和數字資產的客戶，以及所有用戶，Cloudflare 深表歉意，已經開始著手進行所有的改進和優化，努力確保類似情況不會再次發生。
【參考文獻】
CDN 解釋部分：Youtube-老科談科技股-Cloudflare
企辰科技：雲、CDN、IDC 三個概念的區別是什麼？
https://techcrunch.com/2022/06/21/cloudflare-outage-crypto-exchanges/
https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
https://techcrunch.com/2022/06/20/cloudflare-outage-knocks-popular-services-offline/
https://en.wikipedia.org/wiki/Cloudflare#cite_note-13
https://en.wikipedia.org/wiki/Cloudflare
https://baike.baidu.com/item/%E8%BE%B9%E7%95%8C%E7%BD%91%E5%85%B3%E5%8D%8F%E8%AE%AE/2987527?fromtitle=BGP%E5%8D%8F%E8%AE%AE&fromid=1989644&fr=aladdin
https://www.cloudflare.com/zh-cn/web3/
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
