譯者注：本文中提到CloudFlare是一家總部位于美國舊金山的內(nèi)容分發(fā)網(wǎng)絡(CDN)服務公司，由Project Honey Pot項目的三位前開發(fā)人員成立于2009年。2011年10月被華爾街日報評為***創(chuàng)新精神的網(wǎng)絡科技公司。

　　今天，谷歌的服務經(jīng)歷了短暫的宕機事件，持續(xù)大概27分鐘，對部分地區(qū)的互聯(lián)網(wǎng)用戶造成了影響。此次事件的原因深究起來需要進入互聯(lián)網(wǎng)絡那深邃的、 黑暗的角落。我是CloudFlare公司的一名網(wǎng)絡工程師，在幫助谷歌從此次宕機中恢復回來提供了一臂之力。下面就是事情發(fā)生的過程。

　　大約在太平洋標準時間2012年11月5號下午6：24分/時間標準時間2012年11月6號凌晨2：24分，CloudFlare的員工發(fā)現(xiàn)谷歌 的服務中斷了。我們使用谷歌的電子郵件等服務，所以，當它的服務不正常時，辦公室的人會很快發(fā)現(xiàn)。我在網(wǎng)絡技術(shù)小組工作，因此我立刻接上網(wǎng)絡查看是什么情 況——是局部區(qū)域問題還是全球問題。

　　問題排查

　　我很快就意識到，所有谷歌的服務我們都不能連接上——甚至包括連接 8.8.8.8，谷歌的公共DNS服務器——于是，我從追查DNS開始。

　　下面是我在探測Google.com的域名服務器時得到的回復：

google.com.                172800        IN        NS        ns2.google.com.  
google.com.                172800        IN        NS        ns1.google.com.  
google.com.                172800        IN        NS        ns3.google.com.  
google.com.                172800        IN        NS        ns4.google.com.  
;; Received 164 bytes from 192.12.94.30#53(e.gtld-servers.net) in 152 ms  
 
;; connection timed out; no servers could be reached 

　　無法探測到任何服務器的結(jié)果證明確實有什么地方出了問題。尤其是，這意味著從我們的辦公室將連接不到任何的谷歌DNS服務器。

　　我開始網(wǎng)絡層查找問題，看看是否是在這個通信層出了問題。

PING 216.239.32.10 (216.239.32.10): 56 data bytes  
Request timeout for icmp_seq 0  
92 bytes from 1-1-15.edge2-eqx-sin.moratelindo.co.id (202.43.176.217): 

　　這里出現(xiàn)了奇怪的信息。通常，我們不應該在谷歌的路由信息中看到一個印度尼西亞的網(wǎng)絡服務提供商(Moratel)的名字。我立即進入一個 CloudFlare的路由器中查看發(fā)生了什么事。與此同時，Twitter上世界其它地方的報告顯示了我們并不是唯一遇到問題的地方。

　　互聯(lián)網(wǎng)路由

　　為了理解是出了什么問題，你需要知道一些互聯(lián)網(wǎng)是如何工作的基礎知識。整個互聯(lián)網(wǎng)是由很多的網(wǎng)絡組成，這些網(wǎng)絡被稱為是“自治系統(tǒng)(AS)”。每個 網(wǎng)絡都有一個唯一的數(shù)字來標志自己，被稱為AS號。CloudFlare的AS號是13335，谷歌的AS號是15169。各個網(wǎng)絡通過一種叫做邊緣網(wǎng)關(guān) 協(xié)議(BGP)的技術(shù)互相連接。邊緣網(wǎng)關(guān)協(xié)議被稱為是互聯(lián)網(wǎng)的粘合劑——由它來聲明哪個IP地址屬于哪個網(wǎng)絡，由它來建立從某個自治網(wǎng)絡到另外一個自治網(wǎng) 絡的路由。一個互聯(lián)網(wǎng)“路由”跟這個詞的表意完全一樣：由一個自治網(wǎng)絡里的IP地址到另外一個自治網(wǎng)絡里的另一個IP地址的路徑。

　　邊緣網(wǎng)關(guān)協(xié)議是基于一個相互信任的體制。各個網(wǎng)絡基于信任的原則告訴其它網(wǎng)絡哪個IP地址屬于哪個網(wǎng)絡。當你發(fā)送一個數(shù)據(jù)包，或發(fā)送一個穿越網(wǎng)絡的請求，你的網(wǎng)絡服務提供商會聯(lián)系它的上游提供商或?qū)Φ忍峁┥蹋儐査鼈儚哪愕木W(wǎng)絡服務提供商到網(wǎng)絡目的地，哪條路線最近。

　　不幸的是，如果當一個網(wǎng)絡發(fā)出聲明說某個IP地址或某個網(wǎng)絡在它的內(nèi)部，而事實不是這樣，如果它的上游網(wǎng)絡或?qū)Φ染W(wǎng)絡信任了它，那么，這個數(shù)據(jù)包最終將會迷路丟失。這里發(fā)生的就是這個問題。

　　我查看了邊緣網(wǎng)關(guān)協(xié)議傳遞的谷歌IP的路由地址，路由指向了Moratel (23947)，一個印度尼西亞的網(wǎng)絡服務提供商。我們的辦公室在加利福尼亞，離谷歌的數(shù)據(jù)中心并不遠，數(shù)據(jù)包絕不應該經(jīng)過印度尼西亞。很有可能是，Moratel聲明了一個錯誤的網(wǎng)絡路由。

　　當時我看到的邊緣網(wǎng)關(guān)協(xié)議發(fā)來的路由是：

tom@edge01.sfo01> show route 216.239.34.10                            
 
inet.0: 422168 destinations, 422168 routes (422154 active, 0 holddown, 14 hidden)  
+ = Active Route, - = Last Active, * = Both  
 
216.239.34.0/24    *[BGP/170] 00:15:47, MED 18, localpref 100  
                      AS path: 4436 3491 23947 15169 I  
                    > to 69.22.153.1 via ge-1/0/9.0 

　　我查看了其它路由，比如谷歌的公共DNS，它同樣被劫持到了相同的(不正確的)路徑：

tom@edge01.sfo01> show route 8.8.8.8   
 
inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden)  
+ = Active Route, - = Last Active, * = Both  
 
8.8.8.0/24         *[BGP/170] 00:27:02, MED 18, localpref 100  
                      AS path: 4436 3491 23947 15169 I  
                    > to 69.22.153.1 via ge-1/0/9.0 

　　路由泄漏

　　像這樣的問題在行業(yè)內(nèi)被認為是起源于“路由泄漏”，不是正常的，而是“泄漏”出來的路由。這種事情并不是沒有先例。谷歌之前曾遭受過類似的宕機事件，當時推測是巴基斯坦為了禁止YouTube上的一個視頻，巴基斯坦國家ISP刪除了YouTube網(wǎng)站的路由信息。不幸的是，他們的這種做法被傳遞到了外 部，巴基斯坦電信公司的上游提供商——電訊盈科(PCCW)信任了巴基斯坦電信公司的做法，把這種路由方式傳遞到了整個互聯(lián)網(wǎng)。這個事件導致了 YouTube網(wǎng)站大約2個小時不能訪問。

[[98876]]

　　今天發(fā)生的事情屬于類似情況。在Moratel公司的某個人很可能是“胖手指”，輸錯了互聯(lián)網(wǎng)路由。而電訊盈科，Moratel公司的上游提供商，信任了Moratel公司傳遞給他們的路由。很快，這錯誤的路由就傳到了整個互聯(lián)網(wǎng)。在邊緣網(wǎng)關(guān)協(xié)議這種信任模式中，與其說這是惡意的行為，不如說這是誤操作或失誤。

　　修復

　　解決方案就是讓Moratel公司停止聲明錯誤的路由。作為一個網(wǎng)絡工程師，尤其是像CloudFlare這樣的大網(wǎng)絡公司里工作的工程師，很大一部分工作就是和其它世界各地的網(wǎng)絡工程師保持聯(lián)絡。當探明問題后，我聯(lián)系到了Moratel公司的一位同事，告訴他發(fā)生了什么事。他大概在太平洋標準時間 下午6：50分/世界標準時間凌晨2：50分修復了這個問題。3分鐘后，路由恢復了正常，谷歌的服務重新可以工作了。

　　從網(wǎng)絡傳輸圖上觀察，我估計全球整個互聯(lián)網(wǎng)用戶的3-5%收到了此次宕機事故的影響。重災區(qū)是香港，因為那是電訊盈科的總部。如果你所處的地區(qū)在當時無法訪問谷歌的服務，你現(xiàn)在應該知道是什么原因了。

　　構(gòu)建更好的互聯(lián)網(wǎng)

　　我說這些就是想讓大家知道我們的互聯(lián)網(wǎng)上如何在一個相互信任的機制下建立起來的。今天的事故說明，即使你是一個像谷歌這樣的大公司，外部你無法掌控的因素也會影響到你的用戶，讓他們無法訪問你，所以，一個網(wǎng)絡技術(shù)小組是非常必要的，由他們來監(jiān)控路由，管理你與世界的聯(lián)系。CloudFlare公司每天的工作就是確保客戶得到***的路由。我們照看互聯(lián)網(wǎng)上的所有網(wǎng)站，確保他們的以最快傳輸速度提供服務。今天的事情只是我們工作內(nèi)容的一個小片段。

　　[本文英文原文鏈接：Why Google Went Offline Today and a Bit about How the Internet Works ]