訂閱以接收新文章的通知:

2024 年第二季網際網路中斷摘要

2024-07-16

閱讀時間:4 分鐘
本貼文還提供以下語言版本:EnglishFrançaisDeutsch日本語한국어Español简体中文

Cloudflare 的網路覆蓋 120 多個國家/地區的 320 多座城市,我們與 13,000 多家網路提供者互連,以便為數百萬客戶提供廣泛的服務。我們的網路和客戶群的廣度為我們提供了關於網際網路復原能力的獨特視角,使我們能夠觀察網際網路中斷的影響。得益於今年早期發佈的 Cloudflare Radar 功能,我們可以從路由角度以及流量角度探索網路位置層級的影響。

Q2 2024 Internet disruption summary

正如我們前幾年所看到的,第二季,多個中東和北非國家舉行了全國性考試,隨之而來的是政府指示的網際網路關停。陸地和海底電纜切斷導致許多國家的網際網路中斷,其中 ACE 海底電纜是一個特別的問題根源。維護停電技術問題也會中斷網際網路連線,還有一些網際網路連線由未知問題導致。自衝突開始兩年多以來,我們經常看到烏克蘭的網際網路連線因俄羅斯的襲擊而受到影響。

正如我們過去所指出的那樣,本文旨在對觀察到的中斷進行概括總結,而不是羅列該季度內所發生問題的詳盡或完整的清單。

政府指示

Government directed

敘利亞、阿爾及利亞、伊拉克

每年春天,中東和北非 (MENA) 地區多個國家的政府都會命令當地電信提供者關閉或中斷全國範圍內的網際網路連線,以防止學生在全國中學和高中考試中作弊。這些關停/中斷通常在數週的時間內每天發生幾個小時。我們報告了 2023 年2022 年2021 年發生的此類事件,這些事件發生在敘利亞、蘇丹、阿爾及利亞和伊拉克等地。

6 月,我們發表了《敘利亞、伊拉克和阿爾及利亞最近的考試期間網際網路關停情況》,其中調查了伊拉克和敘利亞每天發生的網際網路關停情況,以及阿爾及利亞每天兩次持續幾個小時的中斷,這似乎是採取內容封鎖策略,而不是在全國範圍內全面關停。這篇文章研究了這些關停對網際網路流量的影響,並分析了來自其他 Cloudflare 服務的路由資訊和流量,以更好地瞭解這些關停的實施情況。

除了先前提到的部落格文章中介紹的關停之外,伊拉克還實施了第二輪關停,從 6 月 23 日開始,並至少持續到 7 月 14 日。其中一些關停影響了第一輪中看到的同一組網路,還有一些影響了北部庫德斯坦自治地區的網路。

在第二組中,AS206206 (Kurdistan Net)AS59625 (Korek Telecom)AS48492 (IQ-Online)AS21277 (Newroz Telecom) 皆於 6 月 23 日、6 月 26 日、6 月 30 日、7 月 3 日、7 月 7 日和 7 月 10 日當地時間 06:00 至 08:00(世界標准時間 03:00 至 05:00)實施了關停。

在庫德斯坦自治地區之外,包括 AS59588 (Zainas)AS199739 (Earthlink)AS203214 (HulumTele)AS51684 (Asiacell)AS58322 (Halasat) 在內的網路在 6 月 23 日、6 月 24 日、6 月 26 日、6 月 27 日、6 月 29 日、6 月 30 日、7 月 1 日和 7 月 2 日當地時間 06:00 至 08:00(世界標準時間 03:00 至 05:00)之間實施了網際網路關停。

上述兩輪關停似乎都遵循了與先前部落格文章中介紹的第一輪相同的方法。

肯亞、蒲隆地、烏幹達、盧安達、坦尚尼亞

由於擔心肯亞政府在因「2024 年財政法案」中提出增稅而產生的計劃性抗議期間關停網際網路,多個組織簽署了一份聯合聲明。聲明強烈敦促肯亞政府不要執行任何

網際網路關停或資訊控制,並強調此舉可能帶來「災難性經濟影響」。對此,肯亞通訊事務管理局發表了一份新聞稿,表示:「為消除疑慮,本事務管理局無意關閉網際網路流量或乾擾連線品質。這樣的行為將背叛整個《憲法》,特別是言論自由和我們自己的精神。

隨著 6 月 25 日抗議活動升級肯亞的網際網路流量在當地時間 16:30(世界標準時間 13:30)下降。最初,這次中斷被認為是由於一條或多條向該國提供國際連線的海底電纜出現問題,SafaricomAirtel 的社交媒體貼文支持了潛在原因。

蒲隆地烏幹達盧安達坦尚尼亞也在同一時間觀察到類似的網際網路流量下降,如下所示。如果上游網際網路連線依賴一個國家/電纜,則當連接到該國家的海底電纜發生問題時,可能會影響其他國家/地區的網際網路連線。因此,在這四個國家觀察到的中斷並非超乎尋常。為此,MTN 烏幹達在 X 上發布的一篇貼文(隨後被刪除)指出:「尊敬的客戶,由於我們途徑肯亞的連線供應出現中斷,我們所有的網際網路服務都出現了服務品質下降的情況。我們的技術團隊和合作夥伴正在共同努力,力求在最短的時間內解決該問題,在此期間,我們建議我們的客戶使用 *165# 來存取 Mobile Money 和其他基於應用程式的服務,謝謝。

然而,非洲網際網路基礎設施界的其他參與者對海底電纜中斷的解釋提出了質疑。烏幹達 IXP 執行董事 Kyle Spencer 在 X 上發文稱,「我聽說肯亞政府下令海纜登陸站斷開電路。Liquid Intelligence Technologies(泛非網路基礎設施提供者)的集團首席資訊長 Ben Roberts 表示,「本週沒有電纜損壞。」此外,海底電纜的中斷很少(如果有的話)在幾個小時內解決,由此導致的服務中斷通常會持續數天或數週。

6 月 26 日,Safaricom 執行長聲稱「這次服務中斷是由於某些承載網際網路流量的電纜頻寬減少造成的」,這與該公司最初的說法相矛盾。Airtel 或肯亞通訊管理局沒有提供更多資訊,但如上所述,一些業內人士認為,影響肯亞、蒲隆地、烏幹達、盧安達和坦尚尼亞連線的中斷是由肯亞政府指示的,而不是由海底電纜中斷造成的。

Cable cuts

電纜切斷

海地

4 月 28 日當地時間 17:36(世界標準時間 21:36),Digicel Haiti 在 X 上發佈了一條「重要說明」,其中部分內容如下(翻譯版本):「2024 年 4 月 27 日,該公司位於 1 號國道 Drouya 地區的國際光纖基礎設施遭受多次攻擊。該地區連續幾天發生武裝衝突後,光纖因彈藥筒的撞擊而損壞。它影響了網際網路(數據)、簡訊、MonCash 和國際電話等多項服務。目前,我們很高興地通知民眾,所有服務均已 100% 恢復」。下圖顯示了光纖損壞的影響,AS27653 (Digicel Haiti) 遭受了持續近 24 小時的網際網路中斷,從 4 月 27 日當地時間 17:30 左右(世界標準時間 21:30)到 4 月 28 日當地時間 16:00 左右(世界標準時間 20:00),此後流量迅速恢復。

然後在 5 月 3 日,Digicel 海地總幹事在 X 上發文表示(翻譯版本):「Digicel 很遺憾地告知公眾,今天凌晨 2 點,其國際光纖基礎設施又遭受了兩次損壞。我們已恢復 Moncash 服務、簡訊和光纖連線。我們的工作人員已經前往解決迦南地區明顯的山體滑坡問題。」此次光纖損壞造成的中斷持續了大約八個小時,時間為當地時間 02:15 至 10:30(世界標準時間 06:15 至 14:30),如下圖所示,看上去只對流量產生了微弱的影響。

肯亞、馬達加斯加、馬拉威、莫三比克、盧安達、坦尚尼亞、烏幹達

5 月 12 日(星期日),EASSySeacom 海底電纜的問題再次中斷了與東非的連線,近三個月前發生的一系列電纜切斷影響了諸多國家,其中一些國家在此次中斷中再次受到影響。我們在《東非網際網路連線再次受到海底電纜切斷的影響》部落格文章中詳細介紹了這些早期電纜切斷和五月份電纜損壞的初步影響。

多個受影響國家的流量水準在接近當地時間 11:00(世界標準時間 08:00)時下降。各個國家/地區最初受影響的程度不同,肯亞烏幹達馬達加斯加莫三比克的流量最初下降了 10-25%,而盧安達馬拉威坦尚尼亞的流量比前一週下降了三分之一或更多。整體影響在坦尚尼亞、馬達加斯加和盧安達最為顯著,如下圖所示。在接下來的一週裡,流量陸續恢復到預期水準,肯亞在一天半後(5 月 13 日)恢復,盧安達在一週後(5 月 19 日)恢復。

ESSAy 和 Seacom 電纜的修復已於 5 月 31 日完成。截至 7 月 9 日,對 2 月損壞的電纜的修復工作仍在進行中,因為這些電纜位於戰區,使得修復工作變得複雜。

查德

報道,5 月 25 日,喀麥隆的光纖電纜被切斷,導致 Moov Africa TChad 客戶的網際網路連線中斷。中斷持續了三個小時,發生在當地時間 15:15 至 18:15(世界標準時間 14:15 至 17:15),其影響在國家層面也很明顯。路由也受到干擾,Moov Africa Tchad 宣告的 IPv4 /24 首碼(256 個 IPv4 位址)數量在中斷期間從 8 個減少到 3 個。

該事件與 1 月 10 日發生的事件類似,當時 Moov Africa Tchad 和國家層面的流量中斷了超過 12 個小時,「原因是來自喀麥隆的光纖被切斷,查德透過該光纖接入網際網路」。在那次事件期間,從路由角度也觀察到了顯著的波動,因為在中斷期間,宣告的 IPv4 位址空間的數量在網路國家層面頻繁變化。正如我們上一季所指出的,作為一個內陸國家,查德依賴與鄰國之間的地面網際網路連線,AfTerFibre 電纜地圖顯示查德對穿過喀麥隆和蘇丹的有限電纜路徑的依賴。

甘比亞、茅利塔尼亞、塞內加爾

Maintenance

報道非洲海岸至歐洲 (ACE) 海底電纜 6 月 5 日發生「網路中斷」,導致岡比亞、茅利塔尼亞和塞內加爾的網路流量中斷。AS25250 (Gamtel)AS29544 (Mauritel)AS37649 (Free/Tigo) 的流量均在當地時間 23:00(世界標準時間 23:00)左右下降。如下圖所示,中斷持續了近 11 個小時,直到當地時間 6 月 6 日 10:00(世界標準時間 10:00)才恢復流量。Mauritel 幾乎完全中斷,而 Gamtel 和 Free/Tigo 的影響則不太嚴重,可能是因為它們能夠將流量轉移到備份連結

維護

幾內亞、甘比亞、獅子山、賴比瑞亞

我們在上面討論了 6 月 5 日 ACE 海底電纜意外網路中斷導致多個國家停電的情況。然而,兩個月前,一次計劃的電纜維修工作中斷也中斷了多個非洲國家的連線。幾內亞郵電和數位經濟部發佈的一份公報中指出(翻譯版本):「...ACE(非洲海岸到歐洲)網路將於 2024 年 4 月 8 日午夜至凌晨 2 點期間在以下國家/地區進行計劃中斷:幾內亞、塞內加爾、甘比亞、獅子山和賴比瑞亞。這次約 2 小時的中斷將影響網際網路流量和國際電話。

下圖顯示了計劃的兩小時修復時段對所列國家/地區的流量影響,不過,修復時段結束後流量似乎並未完全恢復到預期水準,目前尚不清楚為什麼流量仍然略有下降。此外,儘管塞內加爾被列為受影響國家/地區之一,但其流量並未受到影響。

Power outage

幾內亞

據報道,GUILAB 對 ACE 海底電纜進行的計劃性維護工作導致 AS37461 (Orange Guinea) 和國家層面服務中斷數小時,持續時間為當地時間 12:15 至 15:45(世界標準時間 12:15 至 15:45)。(GUILAB 是負責管理 ACE 海底電纜上配置給幾內亞的容量的公司。)Orange Guinea 在兩篇 X 貼文(12)中報道了維護工作,但隨後刪除了這些貼文。

停電

肯亞

5 月 2 日當地時間 18:30(世界標準時間 15:30),肯亞電力公司在 X 上發佈了「停電警報」,其中表示「2024 年 5 月 2 日(星期四)下午 5:40(美國東部時間),我們經歷了一次系統故障,對電網造成乾擾,導致全國大部分地區供電中斷。」下圖顯示了該國網際網路連線受到的影響,當地時間 17:30 至 17:45(世界標準時間 14:30 - 14:45)期間流量急劇下降。流量下降一直持續到當地時間約 21:30(世界標準時間 18:30),同一時間肯亞電力公司在 X 上發佈了「恢復供電」通知,強調該國部分地區已恢復供電。儘管根據圖中所示,斷電後峰值表明對線上內容的需求被壓抑,但從肯亞網際網路流量的長期檢視來看,前兩天的流量高峰也出現在同一時間(當地時間 22:00,世界標準時間 19:00)。

厄瓜多

6 月 19 日,厄瓜多爾全國停電,除了造成網際網路連線嚴重中斷外,還影響了醫院、家庭和地鐵。下圖顯示厄瓜多爾的網際網路流量在當地時間 15:00(世界標準時間 20:00)之後急劇下降。公共工程部長 Roberto Luque 在 X 上發文解釋道(翻譯版本):「我們從 CENACE 收到的即時報告是,輸電線路出現故障,導致級聯斷電,因此出現全國範圍內的停電。」隨後的貼文指出底層系統缺乏投資,並指出截至當地時間晚上 18:41(世界標準時間 23:41),「95% 的能源已經恢復」。在最初的急劇下降之後,流量開始相當快速地恢復,並在上述時間有效地恢復到預期水準。

阿爾巴尼亞、波士尼亞、蒙特內哥羅

Military action

由於高溫導致用電量增加,以及電力系統受到高溫影響,導致阿爾巴尼亞、波士尼亞和蒙特內哥羅在 6 月 21 日發生大規模停電。據報道,停電起源於蒙特內哥羅,一條 400 千瓦的輸電線路爆炸。雖然停電通常更集中在單一國家或一個國家內的地區,但作為跨巴爾幹電力走廊 (Trans-Balkan Electricity Corridor) 的一部分,巴爾幹半島各國之間的配電系統相互連接。

已發佈的報告(MSNReuters)指出,電網在當地時間 12:00 至 13:00(世界標準時間 10:00 至 11:00)出現故障,受影響國家的電力供應商在下午三點左右開始恢復供電,並且到晚上就基本恢復了。下圖顯示,來自阿爾巴尼亞、波士尼亞和蒙特內哥羅的流量在當地時間 12:00(世界標準時間 10:00)左右開始下降,阿爾巴尼亞和波士尼亞的流量在當地時間 12:30(世界標準時間 10:30)達到最低點,蒙特內哥羅的流量在當地時間 13:00(世界標準時間 11:00)達到最低點。隨著電力恢復,流量在接下來的幾個小時內逐漸恢復,並於當地時間 15:30(世界標準時間 13:30)恢復到預期水準。

據報道,克羅埃西亞也受到了停電的影響,但在其他國家的連線中斷期間,並未看到停電對國家層級的流量造成明顯的不利影響

Technical problems

軍事行動

烏克蘭

俄烏衝突兩年多來,烏克蘭電網經常成為俄羅斯空襲的目標。當烏克蘭的電力基礎設施因這些攻擊而受損時,網際網路連線也會中斷。5 月 21 日的襲擊導致烏克蘭多個地區停電。受影響最嚴重的是蘇梅,當地時間 5 月 22 日 00:00(世界標準時間 21:00),該地區的流量比前一週下降了 82%。如下圖所示,基輔、哈爾科夫和文尼察的流量在幾個小時內也低於前一週,並於 5 月 22 日當地時間 08:00(世界標準時間 05:00)左右恢復到預期水準。

\

技術問題

馬來西亞

正如我們在前幾季的貼文中所介紹的那樣,網際網路中斷並不總是由於惡劣天氣、停電或電纜切斷等大規模的重大事件造成的。有時,當使用者嘗試存取網際網路時,更常見的技術問題可能會導致問題。4 月 15 日,在馬來西亞就發生了這樣的情況,當時 Time Internet 的客戶經歷了近兩個小時的網路中斷。該公司在其 Facebook 頁面上發佈了一篇道歉貼文,解釋了此次中斷的原因,並指出:「這次網際網路服務中斷是我們歷史上迄今為止最嚴重的一次,影響了大約 40% 的客戶。……今天下午 5 點 38 分,我們的主要和輔助安全 DNS 伺服器都無法存取。這意味著任何需要 DNS 位址解析的瀏覽器或服務都無法連線其預期網站。」由於用戶無法存取 Time Internet 的 DNS 解析程式,他們也就無法解析網際網路服務、網站和應用程式(包括 Cloudflare 提供的服務、網站和應用程式)的主機名稱。這導致了如下圖中所示的流量下降,該下降在當地時間 17:00(世界標準時間 05:00)之後開始,並在大約一個小時後開始恢復。該公司沒有提供有關 DNS 伺服器故障原因的任何其他資訊。

Unknown

尼泊爾

在尼泊爾,包括 AS45650 (Vianet)AS139922 (Dishhome) 在內的許多本地網際網路服務提供者都依賴印度提供者 Bharti Airtel 提供上游連線,以支援他們存取網際網路的其他部分。一份已發表的報告強調了這種依賴,並指出「尼泊爾網際網路服務提供者 70% 的網際網路都是從 Airtel 購買的。

4 月 25 日,這些網際網路服務提供者警告稱,他們的服務可能會中斷,因為尼泊爾政府沒有向他們提供外匯服務,以支援他們向 Airtel 等頻寬廠商付款,據報道,他們欠 Airtel 3000 萬美元。5 月 1 日,Airtel 通知拖欠的尼泊爾提供者,由於逾期付款,網際網路服務可能隨時中斷,5 月 2 日,Airtel 中斷了服務。下圖顯示,Vianet 的流量在當地時間 16:15(世界標準時間 10:30)降至接近零,六小時後恢復到預期水準。一小時後,當地時間 17:15(世界標準時間 11:30),Dishhome 的流量大幅下降,但沒有 Vianet 嚴重。大約六個小時後,Dishhome 的流量也恢復了。

Dishhome 可能沒有像 Vianet 那樣經歷近乎完全中斷的情況,因為 Bharti Airtel 是其母公司使用的四家上游提供者之一,而 Bharti Airtel 是 Vianet 的兩家上游提供者之一

一個月後的 6 月 3 日,尼泊爾的 AS45650 (Vianet)AS17501 (Worldlink) 經歷了網際網路中斷,據報道,這是由 Bharti Airtel 網路的路由問題引起的。在 Worldlink 上,流量下降發生在當地時間 12:15 至 14:00 之間(世界標準時間 06:30 至 08:15),而在 Vianet 上,流量下降發生在當地時間 12:15 至 13:15 之間(世界標準時間 06:30 至 07:30)。

未知

本部落格文章系列中涵蓋的大多數網際網路中斷都有一個已知的根本原因,無論是受影響的提供者承認/陳述的原因,還是與現實世界事件(惡劣天氣、停電等)密切相關。然而,還觀察到了一些中斷,受影響的提供者甚至也公開了這些中斷,但沒有公開中斷的根本原因。

馬來西亞

5 月 21 日,CelcomDigi (AS10030) 在 X 上發文稱,其網路出現中斷,正在努力盡快解決該問題。然而,僅僅 12 分鐘後,它就發佈了第二篇貼文,稱其已經完全恢復了 Celcom 的網際網路服務。這些貼文分別於當地時間 21:35 和 21:47(世界標準時間 13:35 和 13:47)發佈。然而,如下圖所示,流量已提前一個多小時恢復到預期水準,因為觀察到的 Celcom 網路中斷持續時間為當地時間 18:00 至 20:15(世界標準時間 10:00 至 12:15)。(請注意,下圖中顯示的第二次中斷是由於內部 Cloudflare 資料管道問題造成的,而不是 Celcom 網路的任何問題。)

Starlink

SpaceX Starlink 的衛星網際網路服務的獨特之處在於它擁有國際用戶群,因此其網路中斷比覆蓋單一國家/地區的網際網路服務提供者問題產生的影響更為廣泛。世界標準時間 5 月 29 日凌晨 01:59,Starlink 在 X 上分享稱,目前遇到網路中斷,正在積極實施解決方案。28 分鐘後,又發佈網路問題已完全解決」。從下圖可以看出,這次短暫的中斷表現為流量略有下降。然而,特別有趣的是,在中斷解決後,從 Starlink 網路到 Cloudflare 的流量激增。服務恢復後流量曲線的急劇增加和快速下降表明,這可能與某種自動化連線檢查有關,而不是被壓抑的使用者對內容的需求。

查德

6 月 5 日當地時間 08:15 至 12:00(世界標準時間 07:15 至 11:00)期間,查德觀察到網際網路幾乎完全中斷,如下圖所示。路由也受到影響,因為該國網路提供者宣告的 IPv4 /24 位址區塊(256 個 IPv4 位址)數量在中斷期間下降了 75%。

有關這次中斷的新聞報導指出,在中斷期間,只有 Starlink 用戶保留了網際網路存取權限。報告還指出,自 2016 年以來,查德面臨反覆出現的網際網路中斷問題,要麼是因為光纖電纜問題,要麼是政府以國家安全名義下令關停。目前還不清楚最終是什麼導致了這次特殊的中斷。

印度

據估計,Reliance Jio 的用戶群超過 4.6 億,任何影響 Reliance Jio 網路 (AS55836) 的網際網路中斷都將對整個印度產生廣泛影響。6 月 18 日,Reliance Jio 在當地時間 13:15 至 17:15(世界標準時間 07:45 至 11:45)期間發生了兩次中斷。每次中斷持續時間不到一小時,流量水準下降到一週前同一時間的大約一半。行動和光纖連線均受到影響,Reliance Jio 未提供更多有關連線問題根本原因的資訊。

結論

隨著我們越來越依賴可靠的網際網路連線,我們必須認識到,連線本身依賴於物理、技術和政治因素的複雜且相互關聯的基礎。這些基礎元件中任何一個出現故障,無論是由於電纜切斷、斷電、設定錯誤還是政府行為,都可能產生重大影響,從而中斷數百萬使用者(可能跨越多個國家/地區)的網際網路連線。雖然可以透過備援和最佳做法來提高物理和技術元件的彈性和可靠性,但政治因素可以說是最難解決的。然而,像 AccessNow 這樣的組織透過他們的 #KeepItOn 活動,動員全球人民、社群和民間社會參與者反對政府指示的網際網路關停,這可能會產生重大的財務影響

造訪 Cloudflare Radar,瞭解有關網際網路中斷、路由問題、網際網路流量趨勢、安全性和攻擊以及網際網路品質等的更多見解。在社交媒體上關注我們:@CloudflareRadar (X)、noc.social/@cloudflareradar (Mastodon) 和 radar.cloudflare.com (Bluesky),或透過電子郵件聯絡我們

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
Cloudflare RadarInternet TrafficInternet ShutdownInternet QualityOutageConsumer Services

在 X 上進行關注

David Belson|@dbelson
Cloudflare|@cloudflare

相關貼文

2024年9月20日 下午2:00

Cloudflare incident on September 17, 2024

On September 17, 2024, during planned routine maintenance, Cloudflare stopped announcing 15 IPv4 prefixes, affecting some Business plan websites for approximately one hour. During this time, IPv4 traffic for these customers would not have reached Cloudflare and users attempting to connect to websites using addresses within those prefixes would have received errors. ...