“我害得 AOL 宕机了 19 个小时,全球电子邮件系统瘫痪了整整一周!”

2018 年 4 月 16 日 云头条 Simon Sharwood

事隔多年,当事人亲口讲述了1996年美国在线(AOL)的那次特大故障。


本周一位名叫“Bert”的读者讲述了那次经历,“将我们的思绪一下子带回到90年代中期,当时美国在线(AOL)是最大的在线服务最大的互联网服务提供商。当时我们拥有足足500万用户!


Bert负责确保AOL的电子邮件正常运行。这是一项颇具挑战性的任务:在1995年上班的头一天,他搭建了该公司的第四台入站邮件网关服务器。


过了一年多,Bert说AOL拥有“几十台入站互联网邮件服务器,我绞尽脑汁,竭力搞清楚如何让它们全部正常运行,又不造成任何问题。”


邮件交换(MX)记录是他面临的主要问题,因为“公司发展到了拥有众多MX的规模,结果我们的DNS数据包太大了,装不进512字节的UDP响应数据包,于是只好截断。”


Bert对我们说,截断的数据包引发了各种各样的问题,其中包括负载严重失衡。


“一小部分网站根本无法将邮件发送到我们,原因是如果DNS响应被截断,它们的系统就拒绝与任何方联系。虽然这类网站比例很小,但仍然数量庞大。显然得做点什么了。”


于是Bert做了。


“我想到了一个好点子,就是为少量常规名称列出多个IP地址,那样我们就可以最大限度地利用域名压缩技术。因此,a.mx.aol.com诞生了,b.mx.aol.com和c.mx.aol.com等网址也诞生了。等到灾难发生时,我们在DNS中列出了九个名称是我们的MX,每个有五个IP地址。我们所有的45台邮件服务器都可能在DNS中被列为是AOL的MX,仍装得进512字节的UDP响应数据包――只是很勉强。邮件再次顺利收发,DNS也没有截断,几乎每个人都很高兴。”


对Bert不满意的少数人指出,他其实需要在MX前面装一只负载均衡交换机。但Bert告诉我们“当时只有单单一个10Base-T接口;由于流量非常大,我们已经改而在邮件服务器的后端上使用FDDI。”


 “我们无法让所有这些流量通过一个小小的10Mbps以太网端口来传输。”于是他没有这么做。


但Bert确实作了安排,好让AOL的DNS团队有一家后备的异地名称服务提供商,“以免出现长时间的故障,那样人们仍可以查询我们的信息。ANS也是这么做的。”


再精心制定的计划也可能出岔子;1996年8月7日,Bert的计划就出了岔子。


“由于AOL网络部门的员工与子公司/骨干服务提供商ANS之间的一些错误计算和沟通上的误会,我们的网络宕机了19个小时。”


引起宕机的原因是“当你试图发送队列中的第一封邮件时,你会查询我们的MX,返回45个IP地址列表,开始尝试建立连接,就像正常那样。你会尝试连接到第一个名称的第一个IP地址,然后......等等。按照RFC,你要等两分钟让该连接超时中断。然后你尝试下一个IP地址。再等两分钟。然后你再尝试下一个IP地址。”


Bert说:“稍微算一下,就会发现单单尝试发送一封邮件就要花90分钟。而在此期间,这个邮件进程没干别的事情。”


但是互联网上的人都在干别的事情:发送更多的电子邮件。又由于那些电子邮件无法抵达AOL(1996年AOL拥有数量巨大的网民),电子邮件服务器“每隔60或30分钟(默认情况下)就会启动队列管理器(queue runner),以清空队列。该队列管理器会吸入整个队列,然后试着处理每一封邮件,逐一处理。”


“但是如果它在试图处理发给AOL的单单一封邮件就要耽搁90分钟,那么另一个队列管理器会在30或60分钟后开始启动,它会吸入整个队列,无法处理你已经在处理的那封邮件,但是它试图向AOL发送第二封邮件时,可能又会耽搁90分钟。”


没过多久,服务器会耗尽内存,开始将数据交换到磁盘上,随后耗尽磁盘上的交换空间,然后(别忘了那是在1996年,当时服务器性能低下),服务器可能会重启,试图修复文件系统,然后开始再次发送邮件。又由于邮件无法发送到AOL,结果可想而知。


Bert告诉我们,他的错误导致了知名的商业垃圾邮件分发者发来憎恨邮件。Bert说,他甚至接到了一两起死亡威胁。


Bert告诉我们:“我不记得那天有多少商家遇到了故障,因为它们无法查看电子邮件,也无法回复对方发送的重要邮件。”19个小时后,AOL才恢复正常。Bert告诉我们“差不多过了一周,邮件流量才最终恢复如初”,在这期间全世界只好等“所有积压的电子邮件逐渐处理完毕。”


Bert认为这起事件也有好处,因为直接促成开发出了qmail和postfix邮件传输代理,它们让全球电子邮件系统更具有弹性。


就绝对规模而言,很难有谁比Bert的故事还重大,但我们确信其他读者同样会有错误要讲述。如果有这类故事,欢迎联系,说不准下一期的主角就是你。


花絮:


AOL的这次故障是1996年的大新闻。


CNN(美国有线电视新闻网)的报道称,那次故障表明了人们在互联网上已变得多么依赖。


哥伦比亚广播新闻网甚至在2015年认为,那次事件值得回顾,指出AOL故障成为了当时的晚间新闻;AOL用户被迫重新拿起电话和传真,以满足实时通讯要求。


登录查看更多
0

相关内容

【复旦大学-SP2020】NLP语言模型隐私泄漏风险
专知会员服务
24+阅读 · 2020年4月20日
零样本图像识别综述论文
专知会员服务
56+阅读 · 2020年4月4日
【LinkedIn报告】深度自然语言处理的搜索系统,211页pdf
专知会员服务
105+阅读 · 2019年6月21日
ZigBee 网络安全攻防
计算机与网络安全
13+阅读 · 2019年4月15日
被动DNS,一个被忽视的安全利器
运维帮
11+阅读 · 2019年3月8日
去哪儿网开源DNS管理系统OpenDnsdb
运维帮
21+阅读 · 2019年1月22日
噩耗再次传来!华为,挺住!
FinTech前哨
4+阅读 · 2018年2月4日
停车入位不再是难题 详解自动泊车系统
物联网智库
5+阅读 · 2017年11月21日
“黑”掉自动驾驶汽车,只要给路标涂个大花脸
Visualizing and Measuring the Geometry of BERT
Arxiv
7+阅读 · 2019年10月28日
Arxiv
6+阅读 · 2018年3月27日
VIP会员
相关资讯
ZigBee 网络安全攻防
计算机与网络安全
13+阅读 · 2019年4月15日
被动DNS,一个被忽视的安全利器
运维帮
11+阅读 · 2019年3月8日
去哪儿网开源DNS管理系统OpenDnsdb
运维帮
21+阅读 · 2019年1月22日
噩耗再次传来!华为,挺住!
FinTech前哨
4+阅读 · 2018年2月4日
停车入位不再是难题 详解自动泊车系统
物联网智库
5+阅读 · 2017年11月21日
“黑”掉自动驾驶汽车,只要给路标涂个大花脸
Top
微信扫码咨询专知VIP会员