从谷歌宕机事件认识互联网工作原理

简介:         这是Oschina.net上看到的一篇文章,觉得不错,转过来。原文地址:http://www.oschina.net/news/35141/why-google-went-offline        译者注:本文中提到CloudFlare是一家总部位于美国旧金山的内容分发网络(CDN)服务公司,由Project Honey Pot项目的三位前开发人员成立于2009年。
   
    这是Oschina.net上看到的一篇文章,觉得不错,转过来。原文地址:http://www.oschina.net/news/35141/why-google-went-offline

   

    译者注:本文中提到CloudFlare是一家总部位于美国旧金山的内容分发网络(CDN)服务公司,由Project Honey Pot项目的三位前开发人员成立于2009年。2011年10月被华尔街日报评为最具创新精神的网络科技公司。

    今天,谷歌的服务经历了短暂的宕机事件,持续大概27分钟,对部分地区的互联网用户造成了影响。此次事件的原因深究起来需要进入互联网络那深邃的、 黑暗的角落。我是CloudFlare公司的一名网络工程师,在帮助谷歌从此次宕机中恢复回来提供了一臂之力。下面就是事情发生的过程。

    大约在太平洋标准时间2012年11月5号下午6:24分/时间标准时间2012年11月6号凌晨2:24分,CloudFlare的员工发现谷歌 的服务中断了。我们使用谷歌的电子邮件等服务,所以,当它的服务不正常时,办公室的人会很快发现。我在网络技术小组工作,因此我立刻接上网络查看是什么情 况——是局部区域问题还是全球问题。

问题排查

   我很快就意识到,所有谷歌的服务我们都不能连接上——甚至包括连接 8.8.8.8,谷歌的公共DNS服务器——于是,我从追查DNS开始。

$ dig +trace google.com

    下面是我在探测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

    无法探测到任何服务器的结果证明确实有什么地方出了问题。尤其是,这意味着从我们的办公室将连接不到任何的谷歌DNS服务器。

    我开始网络层查找问题,看看是否是在这个通信层出了问题。

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): Time to live exceeded

    这里出现了奇怪的信息。通常,我们不应该在谷歌的路由信息中看到一个印度尼西亚的网络服务提供商(Moratel)的名字。我立即进入一个 CloudFlare的路由器中查看发生了什么事。与此同时,Twitter上世界其它地方的报告显示了我们并不是唯一遇到问题的地方。

互联网路由

    为了理解是出了什么问题,你需要知道一些互联网是如何工作的基础知识。整个互联网是由很多的网络组成,这些网络被称为是“自治系统(AS)”。每个 网络都有一个唯一的数字来标志自己,被称为AS号。CloudFlare的AS号是13335,谷歌的AS号是15169。各个网络通过一种叫做边缘网关 协议(BGP)的技术互相连接。边缘网关协议被称为是互联网的粘合剂——由它来声明哪个IP地址属于哪个网络,由它来建立从某个自治网络到另外一个自治网 络的路由。一个互联网“路由”跟这个词的表意完全一样:由一个自治网络里的IP地址到另外一个自治网络里的另一个IP地址的路径。

    边缘网关协议是基于一个相互信任的体制。各个网络基于信任的原则告诉其它网络哪个IP地址属于哪个网络。当你发送一个数据包,或发送一个穿越网络的请求,你的网络服务提供商会联系它的上游提供商或对等提供商,询问它们从你的网络服务提供商到网络目的地,哪条路线最近。

    不幸的是,如果当一个网络发出声明说某个IP地址或某个网络在它的内部,而事实不是这样,如果它的上游网络或对等网络信任了它,那么,这个数据包最终将会迷路丢失。这里发生的就是这个问题。

    我查看了边缘网关协议传递的谷歌IP的路由地址,路由指向了Moratel (23947),一个印度尼西亚的网络服务提供商。我们的办公室在加利福尼亚,离谷歌的数据中心并不远,数据包绝不应该经过印度尼西亚。很有可能是,Moratel声明了一个错误的网络路由。

    当时我看到的边缘网关协议发来的路由是:

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

路由泄漏

    像这样的问题在行业内被认为是起源于“路由泄漏”,不是正常的,而是“泄漏”出来的路由。这种事情并不是没有先例。谷歌之前曾遭受过类似的宕机事件, 当时推测是巴基斯坦为了禁止YouTube上的一个视频,巴基斯坦国家ISP删除了YouTube网站的路由信息。不幸的是,他们的这种做法被传递到了外 部,巴基斯坦电信公司的上游提供商——电讯盈科(PCCW)信任了巴基斯坦电信公司的做法,把这种路由方式传递到了整个互联网。这个事件导致了 YouTube网站大约2个小时不能访问。

胖手指 辛普森

    今天发生的事情属于类似情况。在Moratel公司的某个人很可能是“胖手指”,输错了互联网路由。而电讯盈科,Moratel公司的上游提供商, 信任了Moratel公司传递给他们的路由。很快,这错误的路由就传到了整个互联网。在边缘网关协议这种信任模式中,与其说这是恶意的行为,不如说这是误 操作或失误。

修复

    解决方案就是让Moratel公司停止声明错误的路由。作为一个网络工程师,尤其是像CloudFlare这样的大网络公司里工作的工程师,很大一 部分工作就是和其它世界各地的网络工程师保持联络。当探明问题后,我联系到了Moratel公司的一位同事,告诉他发生了什么事。他大概在太平洋标准时间 下午6:50分/世界标准时间凌晨2:50分修复了这个问题。3分钟后,路由恢复了正常,谷歌的服务重新可以工作了。

    从网络传输图上观察,我估计全球整个互联网用户的3-5%收到了此次宕机事故的影响。重灾区是香港,因为那是电讯盈科的总部。如果你所处的地区在当时无法访问谷歌的服务,你现在应该知道是什么原因了。

构建更好的互联网

    我说这些就是想让大家知道我们的互联网上如何在一个相互信任的机制下建立起来的。今天的事故说明,即使你是一个像谷歌这样的大公司,外部你无法掌控 的因素也会影响到你的用户,让他们无法访问你,所以,一个网络技术小组是非常必要的,由他们来监控路由,管理你与世界的联系。CloudFlare公司每 天的工作就是确保客户得到最佳的路由。我们照看互联网上的所有网站,确保他们的以最快传输速度提供服务。今天的事情只是我们工作内容的一个小片段。

相关文章
|
9月前
|
人工智能 新能源 调度
中国信通院栗蔚:云计算与AI加速融合,如何开启智算时代新纪元?
中国信通院栗蔚:云计算与AI加速融合,如何开启智算时代新纪元?
250 17
|
关系型数据库 应用服务中间件 nginx
基于Docker的LNMP环境微服务搭建
基于Docker的LNMP环境微服务搭建
基于Docker的LNMP环境微服务搭建
|
11月前
|
存储 供应链 安全
探索区块链技术在供应链管理中的应用
本文深入探讨了区块链技术在供应链管理中的应用,分析了其如何提高透明度、安全性和效率。通过具体案例研究,展示了区块链如何解决传统供应链中的信任问题,降低成本,并促进更高效的物流管理。文章还讨论了实施区块链技术面临的挑战和未来发展趋势。
|
算法 C语言 开发者
C语言手撕实战代码_单链表
本文档详细介绍了使用C语言实现单链表的各种基本操作和经典算法。内容涵盖单链表的构建、插入、查找、合并及特殊操作,如头插法和尾插法构建单链表、插入元素、查找倒数第m个节点、合并两个有序链表等。每部分均配有详细的代码示例和注释,帮助读者更好地理解和掌握单链表的编程技巧。此外,还提供了判断子链、查找公共后缀等进阶题目,适合初学者和有一定基础的开发者学习参考。
142 2
|
12月前
|
运维 安全 网络安全
绿盟防火墙忘记密码串口重置
绿盟防火墙忘记密码串口重置
|
关系型数据库 MySQL 持续交付
使用阿里云服务器如何搭建网站?超简单教程!
在阿里云服务器上搭建网站非常简单,尤其是使用轻量应用服务器。只需从应用镜像中选择WordPress镜像,系统将自动安装WordPress及所需环境(PHP、MySQL等)。全过程自动化,无需手动部署。约2-3分钟后,通过服务器公网IP或绑定阿里云域名即可访问和管理网站。详细步骤可参考官方文档。
646 5
|
存储 自然语言处理 vr&ar
大师学SwiftUI第20章 - 国际化
苹果的产品遍布一百多个国家,使用几十种语言和方言发行应用,但通常我们只能创建一个版本的应用,所以就需要对不同市场进行适配。这不仅仅是翻译,还有用户界面中元素的排列、数字的格式等等。这一客制化的过程称为本地化。在SwiftUI中,大多数本地化会自动完成。例如,SwiftUI视图的内容采用靠前(leading)和靠后(trailing)约束来根据文字顺序(从左到右或从右到左读)的不同来表示左和右,日期和充其量单位等值会自动根据所在地进行格式化(参见示例4-32)。但文本还是需要我们来翻译。为此Xcode提供了字符串名录(String Catalogs)。
236 0
|
Linux 编译器 C语言
【Linux】第八站:gcc和g++的使用
【Linux】第八站:gcc和g++的使用
270 0
|
Web App开发 测试技术 API
WebGpu VS WebGL
首先是Web 和 WebGPU 上的图形简史.如果您还没有阅读,请阅读 - 这篇文章在很大程度上是从那篇文章开始的。我将介绍WebGPU在实践中与WebGL的比较,我在Web游戏引擎Construct中添加WebGPU支持时学到的东西,以及它对未来的意义。
353 0
|
缓存 Windows
Windows 技术篇 - 如何查看cpu支持的指令集、型号、属性等详细信息,使用cpu-z工具查看处理器、内存、显卡、主板、缓存、SPD信息方法
Windows 技术篇 - 如何查看cpu支持的指令集、型号、属性等详细信息,使用cpu-z工具查看处理器、内存、显卡、主板、缓存、SPD信息方法
2741 0
Windows 技术篇 - 如何查看cpu支持的指令集、型号、属性等详细信息,使用cpu-z工具查看处理器、内存、显卡、主板、缓存、SPD信息方法