Cloudflare是一家於2019年上市的CDN和安全服務公司，不過2022年6月21日（週二）因為它的服務暫時中斷，影響了大量的服務和平台正常運營。包括FTX，Discord，Omegle，DoorDash等等。
本篇文章，會講一下什麼是CloudFlare，到底是個什麼公司，CloudFlare和Web3的緣起，以及從技術上解釋一下本次故障的原因。
本文結構
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官網
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%；
（本部分有小部分代碼，此處略去，感興趣的網絡工程小伙伴可查看原文：
https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/）
補救和後續步驟
本次服務終端事件造成了廣泛且嚴重的影響，Cloudflare一貫對可用性是非常重視，目前已經提出了幾個需要改進的領域，而後將繼續努力，發現可能潛在導致服務終端的所有問題。
流程：雖然MCP 計劃旨在提高可用性，但我們在更新這些數據中心方面的程序性差距，導致造成了嚴重影響。雖然Cloudflare確實為設計了交錯策略，但是它並不完美，部署過程和自動化中，需要包含MCP 的測試和具體部署過程，以確保不會產生意外後果。
架構：路由器配置的錯誤會阻止正確的路由廣播，從而阻止了正常流量和基礎設施的運行。 Cloudflare將會重新設計路由廣播的策略語句，防止排序的錯誤。
自動化：Cloudflare自動化套件中有可以降低此事件負面影響的部分。 Cloudflare將專注於自動化改進，為網絡配置的推出強制實施改進的交錯策略，並提供自動”提交-確認”回滾。前者將大大降低整體影響，後者將大幅度減少事件中的解決時間。
結論
儘管Cloudflare在MCP架構設計上投入了大量資金，提高服務可用性，但在本次服務中斷事件中，讓客戶失望了。對於服務中斷期間，無法訪問互聯網和數字資產的客戶，以及所有用戶，Cloudflare深表歉意，已經開始著手進行所有的改進和優化，努力確保類似情況不會再次發生。
【參考文獻】
CDN解釋部分：Youtube-老科談科技股-Cloudflare
企辰科技：雲、CDN、IDC 三個概念的區別是什麼？
Cloudflare outage hit crypto exchanges FTX, Bitfinex and more
https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
Cloudflare fixes outage that knocked 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/
