从谷歌宕机工作看法互联网任务道理

2020-05-15 03:56

  译者注:本文中提到 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 谷歌.com

  下面是我在探测 Google.com 的域名效劳器时掉掉落的答复:

  谷歌.com. 172800 IN NS ns2.谷歌.com.

  谷歌.com. 172800 IN NS ns1.谷歌.com.

  谷歌.com. 172800 IN NS ns3.谷歌.com.

  谷歌.com. 172800 IN NS ns4.谷歌.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)

  这里出现了奇异的信息。平日,我们不应当在谷歌的路由信息中看到一个印度尼西亚的收集效劳供给商(Moratel)的名字。我立刻进入一个 CloudFlare 的路由器中检查爆发了甚么事。与此同时,Twitter 上世界其它中央的申报显示了我们其实不是唯一碰到后果的中央。

  互联网路由

  为了了解是出了甚么后果,你需求知道一些互联网是若何任务的基础常识。全部互联网是由很多的收集构成,这些收集被称为是“自治系统(AS)”。每个收集都有一个唯一的数字来标记自己,被称为 AS 号。CloudFlare 的 AS 号是 13335,谷歌的 AS 号是 15169。各个收集经过一种叫做边沿网关协定(BGP)的技巧相互连接。边沿网关协定被称为是互联网的粘合剂——由它来声明哪个 IP 地址属于哪个收集,由它来建立从某个自治收集到其余一个自治收集的路由。一个互联网“路由”跟这个词的表意完整一样:由一个自治收集里的

分享到:
收藏
相关阅读