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

2022 年第三季度網際網路中斷概觀

2022-10-18

閱讀時間:10 分鐘
本貼文還提供以下語言版本:English简体中文

Cloudflare 在 100 多個國家/地區的超過 275 座城市開展業務,我們與超過 10,000 家網路提供者互連,以便為數百萬客戶提供廣泛的服務。我們的網路和客戶群的廣度為我們提供了關於網際網路彈性的獨特視角,讓我們能夠觀察網際網路中斷的影響。在許多情況下,這些中斷可以歸因於實體事件,而在其他情況下,則是由於政府有意關停。在這篇文章中,我們回顧了 Cloudflare 在 2022 年第三季度觀察到的精選網際網路中斷,由 Cloudflare Radar 和其他內部 Cloudflare 工具的流量圖提供支援,並按相關原因或常見地理位置分組。新的 Cloudflare Radar Outage Center 提供了有關這些中斷以及其他歷史中斷的更多資訊。

Internet disruptions overview for Q3 2022

政府指示關停

遺憾的是,在過去十年間,世界各國政府開始以關閉網際網路作為控制或限制公民之間以及與外界通訊的手段。在第三季度,這是所觀察到的中斷的一個極常見原因,影響了非洲、中東、亞洲和加勒比地區的國家和地區。

伊拉克

正如我們在第二季度總結部落格文章中提到的,6 月 27 日,伊拉克庫爾德斯坦地區政府開始實施每週兩次(星期一和星期四)多小時的區域網際網路關停,預計將持續四週,旨在防止在高中期末考試作弊。如下圖所示,除 7 月 21 日外,這些關停在每週一和週四按預期發生,影響了伊拉克的三個省,持續時間為當地時間每天上午 06:30–10:30 (03:30–07:30 UTC)。

伊拉克埃爾比勒、蘇萊曼尼亞和杜胡克省(資料來源:地圖資料 ©2022 Google,Mapa GISrael

古巴

在古巴,當地時間 7 月 15 日 00:55-01:50 (04:55-05:50 UTC) 之間觀察到一次網際網路中斷,據報導,洛斯帕拉西奧斯和比那爾德里奧省在此期間發生了反政府抗議活動。

古巴洛斯帕拉西奧斯和比那爾德里奧(資料來源:地圖資料 ©2022 INEGI

本季度結束時,古巴觀察到另一次重大中斷,據報導是為了應對颶風伊恩之後對缺電的抗議活動。從下圖中可以看到,當地時間 9 月 29 日 20:30 到 9 月 30 日 03:15(9 月 30 日 00:30-07:15 UTC)之間,網路完全中斷。

阿富汗

報導,8 月 8 日上午,阿富汗喀布爾部分地區的電信服務被關停。根據下圖,流量從當地時間 09:30 (0500 UTC) 左右開始下降,11 小時後(大約在當地時間 20:30 (16:00 UTC) 恢復。

阿富汗喀布爾(資料來源:地圖資料 ©2022 Google

獅子山

獅子山弗里敦關於生活成本上漲的抗議活動可能推動了 8 月 10 日和 11 日在該國觀察到的網際網路中斷。第一次發生在當地時間 8 月 10 日 12:00-14:00 (12:00-14:00 UTC) 之間。儘管這次中斷被認為是政府指示的,作為平息抗議活動的一種手段,但管理 Sierra Leone Cable Limited 的 Zoodlabs 聲稱,中斷是「我們部分國際路線緊急技術維護」的結果。

在 8 月 11 日當地時間 01:00-07:30 (01:00-07:30 UTC) 之間觀察到第二次更長的中斷,如下圖所示。這些關停與過去幾年的情況相似,之前在該國選舉后,網際網路連線也被關閉。

獅子山弗里敦(資料來源:地圖資料 ©2022 Google,Inst. Geogr. Nacional

索馬里蘭地區

報導,索馬里蘭地方當局在預定的反對派示威之前於 8 月 11 日切斷了網際網路服務。下圖顯示,在當地時間 06:45-13:55 (03:45-10:55 UTC) 之間,沃戈伊加勒貝德州的網際網路完全中斷。

索馬里蘭地區沃戈伊加勒貝德州(資料來源:地圖資料 ©2022 Google,Mapa GISrael

在網路層級,觀察到的中斷是由於來自AS37425 (SomCable) 和 AS37563 (Somtel) 的流量丟失,如下圖所示。Somtel 是一家行動服務提供者,而 SomCable 專注於提供有線網際網路接入。

印度

印度政府指示的網際網路關停並不陌生,在過去十年間,此類事件發生過數百次。然而,隨著該國最高法院命令電子和資訊技術部 (MEITY) 披露其實施或核准網際網路關停的理由,這種情況將來可能會發生變化。在這個問題得到解決之前,該國範圍內的區域性關停仍不可避免。

阿薩姆邦,發生了關閉行動網際網路連線以防止考試作弊的情況。下圖顯示,這些關停在 8 月 21 日和 8 月 28 日每天實施兩次。雖然官方安排在當地時間 10:00-12:00 和 14:00-16:00 之間(04:30-06:30 和 08:30-10:30 UTC)進行關停,但據報導,部分提供者從清晨就開始暫停連線了。

印度阿薩姆邦(資料來源:地圖資料 ©2022 Google,TMap Mobility

伊朗

9 月下旬,由於馬薩·阿米尼 (Mahsa Amini) 的死亡,伊朗各地爆發了抗議和示威活動。阿米尼是一名來自伊朗庫爾德斯坦省的 22 歲女性,於 2022 年 9 月 13 日在德黑蘭被伊朗「道德警察」逮捕,該部門對女性執行嚴格的著裝規定。她於 9 月 16 日在警方拘留期間死亡。為應對這些抗議和示威,全國的網際網路連線經歷了多波中斷。

除了部落格文章中提到的 9 月 19 日至 21 日薩南迪傑和德黑蘭省的數小時中斷之外,三家行動網路提供者——AS44244 (Irancell)、AS57218 (RighTel) 和 AS197207 (MCCI)——實施了每日網際網路「宵禁」,通常發生在當地時間 16:00 至午夜 (12:30-20:30 UTC) 期間,不過幾天內的開始時間有所不同。這些定期關停在下圖中清晰可見,並一直持續到 10 月初。

伊朗薩南迪傑和德黑蘭(資料來源:地圖資料 ©2022 Google

正如部落格文章中所提到的,9 月 20 日起,伊朗還封鎖了對 DNS-over-HTTPS (DoH)DNS-over-TLS (DoT) 服務的存取,而且可能與此相關的是,從 9 月 22 日起,透過 HTTP/3QUIC 進行的連線也被封鎖,如來自 Cloudflare Radar 的下圖所示。

自然災害

地震和颶風等自然災害會對受影響的地區造成嚴重破壞,往往造成生命損失,並對所有類型的建築物造成重大結構損壞。基礎設施損壞也極為普遍,電力和電信基礎設施普遍受損。

巴布亞紐幾內亞

9 月 11 日,巴布亞紐幾內亞發生 7.6 級地震,導致山體滑坡、道路破裂和網際網路連線中斷。在當地時間 11:00 (01:00 UTC) 之後,前往該國的流量下降了 26%。下圖顯示,到第二天的流量也仍然較低。當地提供者 PNG DataCo 的公告指出,地震_「影響了莫爾斯貝港和馬當之間的 Kumul 海底電纜網路 (KSCN) Express Link 以及馬當和雪梨之間的 PPC-1 電纜的營運」。_他們表示,正是這些損壞導致觀察到的中斷和服務質量下降。

墨西哥

僅僅一個多星期後,當地時間 13:05 (18:05 UTC),墨西哥科利馬-米卻肯邊境地區發生了 7.6 級地震。如下圖所示,地震發生後,受災州的流量立即下降了 50% 以上,但恢復得相當快,在當地時間 16:00 (21:00 UTC) 左右恢復到正常水平。

地震震中,墨西哥阿吉利亞西南 35 公里處(資料來源: 地圖資料 ©2022 INEGI

颶風菲奧娜

9 月下旬,幾場大型颶風席捲北美東海岸,造成重大破壞,導致網際網路中斷。9 月 18 日,颶風菲奧娜造成的全島停電中斷了波多黎各的網際網路連線。如下圖所示,經過了 10 多天時間,流量才恢復到預期水平。當地電力公司 Luma Energy 透過定期更新其 Twitter 資訊,讓客戶了解維修進度。

兩天后,颶風菲奧娜襲擊了土克斯及開科斯群島,造成洪水和嚴重破壞,並中斷了網際網路連線。下圖顯示,9 月 20 日當地時間 12:45 (16:45 UTC) 左右,流量開始下降到預期水平以下。大約花費了一天時間復原,9 月 21 日當地時間 11:00 (15:00 UTC) 左右,流量恢復到預期水平。

颶風菲奧娜繼續向北移動,最終於 9 月 24 日在加拿大新斯科細亞省登陸,造成停電和網際網路連線中斷。下圖顯示,最顯著的影響發生在新斯科細亞省。隨著 Nova Scotia Power 努力恢復對客戶的服務,流量逐漸增加,如下圖所示。到 9 月 29 日,島上的流量已恢復到正常水平。

颶風伊恩

9 月 28 日,颶風伊恩在佛羅里達州登陸,是自 2018 年颶風邁克爾以來襲擊佛羅里達州的最強颶風。由於風暴造成的破壞,超過 400 萬客戶斷電,一些城市經歷了相關的網際網路中斷。從當地時間 15:00 (19:00 UTC) 開始,來自受影響城市的流量顯著下降,如下圖所示,恢復十分緩慢,兩週多後流量水平仍未恢復到風暴前的水平。

薩拉索塔、拿坡里、邁爾斯堡、珊瑚角、北港、夏洛特港、蓬塔戈爾達和佛羅里達州馬可島(資料來源:地圖資料 ©2022 Google,INEGI

停電

除了地震和颶風造成的停電外,第三季度還發生了許多其他停電事件,導致數小時的網際網路中斷。

伊朗

報導7 月 25 日,一棟關鍵資料中心大樓的停電中斷了伊朗當地 ISP Shatel 客戶的網際網路連線。如下圖所示,在當地時間 07:15 (03:45 UTC) 左右,流量顯著下降。不過幾乎立即開始恢復,到當地時間 08:30 (05:00 UTC) 時,流量接近預期水平。

委內瑞拉

電力問題經常導致委內瑞拉的網際網路連線中斷,無黨派的 @vesinfiltro Twitter 帳戶密切追蹤這些事件。8 月 9 日就發生了這樣的情況,當時電力問題中斷了多個州的連線,包括梅里達、塔奇拉、巴里納斯、波圖格薩和特魯希略。下圖顯示了兩次中斷的證據,第一次是當地時間 13:40 左右 (17:40 UTC),第二次是幾個小時後,從當地時間 16:15 左右 (20:15 UTC) 開始。在這兩次事件中,流量似乎都恢復得相當快。

委內瑞拉的梅里達、塔奇拉、巴里納斯、波圖格薩和特魯希略(資料來源:地圖資料 ©2022 Google。INEGI

阿曼

9 月 5 日,阿曼的一次停電影響了能源、航空和電信服務。後者在下圖中很明顯,該圖顯示在當地時間 15:15 (09:15 UTC) 之前中斷開始時,該國的流量下降了近 60%。儘管當局聲稱「電網將在四小時內恢復」,但直到第二天當地時間 9 月 6 日 04:00 點(9 月 5 日 UTC 22:00),也就是大約 11 小時後,流量才完全恢復到正常水平。

烏克蘭

在過去七個多月的烏克蘭戰爭中,我們觀察到由於基礎設施損壞和與戰爭相關的停電導致網際網路多次中斷。我們在第一季度第二季度的摘要部落格文章中介紹了這些中斷,並在它們發生時在我們的@CloudflareRadar Twitter 帳戶上持續追蹤報道。停電是 9 月 11 日、12 日和 13 日在卡爾可夫觀察到的網際網路中斷的原因。

下圖顯示,第一次中斷於當地時間 9 月 11 日 20:00 左右 (17:00 UTC) 開始。這次近乎完全的停電持續了超過 12個小時,流量在當地時間 12 日 08:30 (05:30 UTC) 左右恢復到正常水平。但是,當天晚些時候,發生了另一次部分地區停電,在當地時間 13:30 (10:30 UTC),流量下降了 50%。這次的流量影響時間要短得多,大約一個小時后開始恢復。最後,在當地時間 9 月 13 日 08:00 (05:00 UTC) 可以看到一次微弱的中斷,低於預期的流量持續約 5 小時。

電纜損壞

多年來,地面和海底電纜的損壞導致了許多網際網路中斷。最近據稱對海底北溪天然氣管道的破壞事件引起了歐洲媒體(包括瑞士法國出版物)對海底電纜對網際網路之重要性的關注,政策制定者也越來越關注這些電纜系統的安全性以及損壞它們的潛在影響。但是,下面回顧的三次電纜損壞實例都與地面電纜有關。

伊朗

據報導,8 月 1 日電信檢修孔起火導致的「光纖電纜」問題中斷了多個網路提供者的連線,包括 AS31549 (Aria Shatel)、AS58224 (TIC)、AS43754 (Asiatech)、AS44244 (Irancell) 和 AS197207 (MCCI)。中斷開始於當地時間 12:15 左右 (08:45 UTC),持續了大約四個小時。由於它影響了許多主要的無線和有線網路,所以影響在國家層面也很明顯,如下圖所示。

巴基斯坦

8 月,大雨和洪水造成的電纜損壞在巴基斯坦造成數次網際網路中斷。第一次明顯的中斷發生在 8 月 19 日,從當地時間 07:00 (02:00 UTC) 左右開始,持續了六個半小時。8 月 22 日,發生了另一次重大中斷,從當地時間 22:50 (17:50 UTC) 開始,到 23 日當地時間 05:30 (00:30 UTC) 進一步下降。第二次更顯著的下降十分短暫,僅持續了 45 分鐘,之後流量開始恢復。

海地

在對燃料價格上漲的抗議中,海地的光纖削減導致多家網路提供者的網際網路中斷。從當地時間 9 月 14 日 15:00 (19:00 UTC) 開始,AS27759 (Access Haiti) 的流量降至零。根據提供者的(翻譯的)推特貼文,他們有幾條光纖電纜在該國不同地區被切斷,道路阻塞使他們的技術人員「非常難以」到達問題區域。最終進行了修復,當地時間 9 月 15 日 08:30 (12:30 UTC) 左右,流量再次開始增加,如下圖所示。

Access Haiti(作為「上游」提供者)為 AS27774 (Haiti Networking Group) 提供網際網路連線,因此光纖切斷也影響了它們的連線,導致下圖所示的中斷。

技術問題

作為一個標題,「技術問題」可以包羅萬象,指代多種類型的問題,包括設定錯誤和路由問題。但是,有時這也是政府或電信公司對觀察到的網際網路中斷給出的官方解釋。

Rogers

可以說,今年迄今為止最嚴重的網際網路中斷發生在 AS812 (Rogers),這是加拿大最大的網際網路服務提供者之一。在 7 月 8 日 08:45 UTC 左右,觀察到流量幾乎完全丟失,如下圖所示。

下圖顯示了在中斷過程中從網路上看到的少量流量,但在將近 24 小時後,流量才恢復到正常水平。

Rogers CEO 發布的通知解釋說:「我們現在認為,我們已經將原因縮小到核心網路維護更新後的一次網路系統故障,這導致我們的一些路由器在周五早上出現故障。我們斷開了特定設備的連線並重新導向了流量,這讓我們的網路和服務也能隨著時間的推移重新上線,我們管理的流量也恢復到正常水平。」 Cloudflare 部落格文章即時報導了 Rogers 的中斷,重點介紹了相關的 BGP 活動和流量的小幅增長。

查德

8 月 12 日,查德在當地時間 10:45 至 13:00 (09:45 至 14:00 UTC)之間發生了一次幾乎完全的網際網路中斷,持續了將近四個小時。查德當局表示,中斷是因 Sudachad 與喀麥隆和蘇丹網路之間的連線存在「技術問題」而導致。

未知

基於服務提供者、政府官員的聲明或媒體對相關事件的報導,在許多情況下,觀察到的網際網路中斷都被歸因於內在原因。但是,對於部分中斷,找不到發佈的解釋或相關事件。

8 月 11 日,美國電信提供者 Centurylink 在科羅拉多州、愛荷華州、密蘇里州、蒙大拿州、新墨西哥州、猶他州和懷俄明州等州的客戶遭受了數小時的中斷影響,如下圖所示。在關聯自治系統 AS209 的流量圖中,也可以清楚看到此次中斷。

8 月 30 日,衛星網際網路提供者遭受了全球服務中斷,持續時間為 06:30-10:30 UTC,如下圖所示。

結論

在 9 月底的 Cloudflare Birthday Week 期間,我們推出了 Cloudflare Radar Outage Center (CROC)CROC 是我們新的 Radar 2.0 網站的一個部分,用於封存所觀察到的網際網路中斷的相關資訊。也可透過 API 獲得支援 CROC 的基礎資料 ,使相關方能夠將資料合併到他們自己的工具、網站和應用程式中。有關發生的網際網路中斷和其他網際網路趨勢的定期更新,請在 Twitter 上關注 @CloudflareRadar

在 Cloudflare TV 上觀看

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

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

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

在 X 上進行關注

David Belson|@dbelson
Cloudflare|@cloudflare

相關貼文

2024年9月27日 下午1:00

Network trends and natural language: Cloudflare Radar’s new Data Explorer & AI Assistant

The Cloudflare Radar Data Explorer provides a simple Web-based interface to build more complex API queries, including comparisons and filters, and visualize the results. The accompanying AI Assistant translates a user’s natural language statements or questions into the appropriate Radar API calls....

2024年9月23日 下午1:00

Network performance update: Birthday Week 2024

Since June 2021, we’ve been measuring and ranking our network performance against the top global networks in the world. We use this data to improve our performance, and to share the results of those initiatives. In this post, we’re going to share with you how network performance has changed since our last post in March 2024, and discuss the tools and processes we are using to assess network performance. ...

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. ...