不锈钢罐厂家
免费服务热线

Free service

hotline

010-00000000
不锈钢罐厂家
热门搜索:
技术资讯
当前位置:首页 > 技术资讯

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

发布时间:2020-03-10 11:31:55 阅读: 来源:不锈钢罐厂家

A5交易A5任务 SEO诊断淘宝客 站长团购

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

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

问题排查

我很快就意想到,所有谷歌的服务我们都不能连接上乃至包括连接 8.8.8.8,谷歌的公共DNS服务器因而,我从清查DNS开始。

$ dig +trace

下面是我在探测的域名服务器时得到的回复:

. 172800 IN NS .

. 172800 IN NS .

. 172800 IN NS .

. 172800 IN NS .

;; Received 164 bytes from 192.12.94.30#53() 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 (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@o01 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@o01 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这样的大网络公司里工作的工程师,很大1 部份工作就是和其它世界各地的网络工程师保持联系。当探明问题后,我联系到了Moratel公司的一名同事,告知他产生了什么事。他大概在太平洋标准时间 下午6:50分/世界标准时间清晨2:50分修复了这个问题。3分钟后,路由恢复了正常,谷歌的服务重新可以工作了。

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

构建更好的互联网

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

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

卓尔发展(天津)有限公司

中华联合人寿保险股份有限公司

中国联通集团河北省通信有限公司石家庄市分公司