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

译者注：本文中提到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申明了一个 舛误的网络路由  。

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

p>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，它同样被劫持到了 雷同的(不正确的)路径：

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

tom@edge01.sfo01> show route 8.8.8.8

路由 透露

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

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

修复

解决 方案便是让Moratel公司 停留申明 舛误的路由  。作为一个网络工程师，尤其是像CloudFlare这样的大网络公司里工作的工程师，很大一 部分工作便是和其它世界各地的网络工程师 维持 联络  。当探明问题后，我 联络到了Moratel公司的一位 共事，告诉他 产生了什么事  。他大约在太平洋 标准 工夫下午6：50分/世界 标准 工夫凌晨2：50分修复了这个问题  。3分钟后，路由 复原了 畸形，谷歌的服务再一次 可以工作了  。

从网络传输图上 视察，我估量 寰球整个互联网消费者的3-5%收到了此次宕机 事变的影响  。重灾区是香港，由于那是电讯盈科的总部  。假如你所处的地域在当时 无奈 拜访谷歌的服务，你现在应该晓得是什么缘由了  。

构建更好的互联网

我说这些便是想让大家晓得我们的互联网上如何在一个 彼此信赖的机制下 构建起来的  。今日的 事变 注明， 即便你是一个像谷歌这样的大公司，外部你 无奈掌控的因素也会影响到你的消费者，让他们 无奈 拜访你，所以，一个网络技术小组是十分必要的，由他们来监控路由，治理你与世界的 联络  。CloudFlare公司天天的工作便是确保客户得到最佳的路由  。我们照看互联网上的全部网站，确保他们的以最快传输速度提供服务  。今日的 事件只不过我们工作内容的一个小片段  。