3月3日， CloudFlare經(jīng)歷了過去四年間第三次嚴(yán)重的事故。UTC時間9：47(北京時間3月3日17：47)，CloudFlare的邊緣路由器發(fā)生故障，這導(dǎo)致使用CDN和安全服務(wù)的785000多個網(wǎng)站受到影響。約30分鐘后故障被排除，事故持續(xù)影響了一個多小時。

CloudFlare的聯(lián)合創(chuàng)始人及CEO Matthew Prince在事故當(dāng)天就通過 blog對事故進(jìn)行了分析，并向用戶道歉。從廣泛的評論來看，主流輿論對于此次事故還是報以寬容和理解，對CloudFlare的勇于認(rèn)錯的態(tài)度和快速的行動進(jìn)行了肯定。

圖：CloudFlare的實(shí)現(xiàn)原理

據(jù)TechCrunch 報道，中國是除美國本土外CloudFlare的最大市場，盡管此次事故在國內(nèi)也引起了大量討論，但還沒有商業(yè)用戶的抱怨聲音(企業(yè)用戶每月需支付3000美元)。

去年四月，CloudFlare的月PV達(dá)到400億，目前這個數(shù)據(jù)已經(jīng)達(dá)到1000億。CloudFlare幫助網(wǎng)站節(jié)省帶寬、提高訪問速度，并過濾惡意攻擊。

什么引起了事故?

Matthew Prince在blog上表示：

CloudFlare 的管理團(tuán)隊(duì)發(fā)現(xiàn)一處DDoS攻擊，監(jiān)測工具顯示攻擊包大小在 99971 ~ 99985 bytes 左右(正常包大小是 1500 bytes，通常都在 500 ~ 600 bytes)，于是將其規(guī)則加入 Juniper 的 Junos 防火墻設(shè)置中，不過預(yù)期大小的包并沒有被攔截，因?yàn)閷?shí)際上并不存在這么大的數(shù)據(jù)包，取而代之的是匹配規(guī)則的數(shù)據(jù)包沖刷到內(nèi)存中，直到內(nèi)存耗盡，系統(tǒng)崩潰。

通常系統(tǒng)崩潰會自動重啟而恢復(fù)工作，但這次例外了。由于系統(tǒng)沒有正常啟動，管理端口沒有響應(yīng)控制，于是CloufFlare的管理中心只能電話通知全球 14 個國家的 23 個數(shù)據(jù)中心的管理員硬啟動機(jī)器，這個過程大概花費(fèi)了 30 分鐘。最早恢復(fù)的數(shù)據(jù)中心由于負(fù)荷了最多了訪問流量，仍然導(dǎo)致了 CloudFlare 服務(wù)的不穩(wěn)定性，加上等待 DNS 緩存更新等，服務(wù)恢復(fù)時已經(jīng)影響已持續(xù)超過 1 小時。

我們學(xué)到了什么?

網(wǎng)絡(luò)技術(shù)工程師 IKE123在微博上評論：

1、主因：flowspec的bug引起的加載filter的時候?qū)е碌膬?nèi)存泄露。

2、Crash以后未能自動重啟，所有收到該flowspec路由的邊緣設(shè)備全玩完。

3、非架構(gòu)問題，所以SDN/Openflow不會更好。

4、軟件都有bug，這只是flowspec用的少，才有低級錯誤，不過換SDN估計更差(使用案例更少)。

5、ISP玩PCEP(路徑計算單元通信協(xié)議)。

他特意向CSDN澄清：SDN和這次事故無關(guān)，只是有人提出來說SDN能有幫助。他認(rèn)為：ISP骨干應(yīng)該用PCEP，而不是Openflow。 PCEP是集中計算RSVP TE(基于流量工程擴(kuò)展的資源預(yù)留協(xié)議)，下發(fā)到設(shè)備上。Google是大驅(qū)動因素。

藍(lán)盾股份是國內(nèi)提供類CloudFlare服務(wù)的公司之一，該公司負(fù)責(zé)應(yīng)用安全產(chǎn)品線研發(fā)總監(jiān) 余志剛告訴CSDN：

我最近研發(fā)的產(chǎn)品是 云防線，技術(shù)架構(gòu)與CloudFlare類似。

CloudFlare 這種技術(shù)架構(gòu)中DNS服務(wù)集群充當(dāng)?shù)氖侨重?fù)載均衡、智能路由的角色，而其他的分?jǐn)?shù)據(jù)中心的運(yùn)作都將依賴全局的DNS智能集群，如果這個中心集群宕機(jī)，將導(dǎo)致整個系統(tǒng)癱瘓，哪怕分中心無任何問題，數(shù)據(jù)流量也將路由不到。

通過分析官方blog的內(nèi)容，我猜測CloudFlare 的DNS應(yīng)該是有熱備的，但可能這兩套系統(tǒng)都在這個核心路由器后面。路由器出問題后導(dǎo)致兩套系統(tǒng)都無法訪問。

余志剛認(rèn)為，這次事故反映出這種基于SaaS概念的安全系統(tǒng)需要完善一下幾個方面：

1、加強(qiáng)全局負(fù)載均衡，也就是DNS智能集群的安全防護(hù)及運(yùn)營水平。

2、在財力允許的情況下，盡量建立DNS智能集群的備份系統(tǒng)，兩套系統(tǒng)做到熱備。

3、將用戶管理系統(tǒng)也就是www.cloudflare.com這個網(wǎng)站管理系統(tǒng)和核心系統(tǒng)分開，當(dāng)DNS智能集群宕機(jī)，無法為用戶網(wǎng)站提供加速、防護(hù)服務(wù)后，保證管理系統(tǒng)能正常使用，然后給用戶提供快速切換到原有DNS解析服務(wù)器的選項(xiàng)。

陳利人認(rèn)為：

CloudFlare CDN加速的原理：當(dāng)用戶訪問已經(jīng)啟用CloudFlare CDN加速網(wǎng)站時，首先通過DNS重定向技術(shù)確定最接近用戶的最佳CDN節(jié)點(diǎn)，同時將用戶的請求指向該節(jié)點(diǎn)。當(dāng)用戶的請求到達(dá)指定節(jié)點(diǎn) 時，CloudFlare的服務(wù)器(節(jié)點(diǎn)上的高速緩存)負(fù)責(zé)將用戶請求的內(nèi)容提供給用戶。說白了，就是基于DNS的負(fù)載均衡。

在Hacker News上對此次事故有著瘋狂的 討論：

“如果你將Juniper和Cisco的設(shè)備放在一起，那么就會產(chǎn)生很多奇怪的問題。”

“最好不用只使用一家供應(yīng)商。”

“Junos的更新速度顯然慢了。”

“任何設(shè)備都不能保證網(wǎng)絡(luò)萬無一失。”

敏捷開發(fā)者、趴貓網(wǎng) 創(chuàng)始人 王龍：

自己運(yùn)營的主打產(chǎn)品不要用任何第三方的產(chǎn)品，金窩銀窩不如自己的草窩，所有東西自己來搭建，框架用自己開發(fā)的，平臺用自己運(yùn)維的，服務(wù)器用自己的，插件自己來寫，CDN自己搭建，云架構(gòu)自己部署，就不會出現(xiàn)這種由于第三方問題出現(xiàn)的問題，起碼問題是可控的。

行人23：

電話14個國家23個數(shù)據(jù)中心管理員只需要30分鐘，放到國內(nèi)廠商需要多久呢?

wanght1979：

作為剛剛從機(jī)房出來的苦逼，深刻理解其困擾。

如果你有任何觀點(diǎn)，不妨在評論中告訴我們。

國內(nèi)的類CloudFlare市場

在國內(nèi)， 安全寶、 知道創(chuàng)宇和云防線都提供類CloudFlare的服務(wù)。國內(nèi)兩大CDN 服務(wù)商網(wǎng)宿和藍(lán)汛這塊業(yè)務(wù)躍躍欲試，電信運(yùn)營商已經(jīng)參與這個市場。盡管市場競爭非常激烈，但和所有其它云計算服務(wù)一樣，用戶的 接受程度還很低，“目前來說用戶對這種SaaS概念的安全服務(wù)接受程度還比較有限。隨著發(fā)展，SaaS服務(wù)慢慢被大家接受，這肯定是未 來安全行業(yè)發(fā)展的方向”，余志剛表示。