云天文化
湘潭分公司
www.wintoo.cc
平面设计、数字印刷、网站建设一站式全程解决方案
|
|
|
|
|
|
|
|
| |
 
服务范围

 平面设计
 数字印刷
 网站建设
86-731-22507127
QQ在线咨询:583284597
一站式服务:15973360996 王先生
       15115377182 潘女士
       15973366214 王先生
网站建设: 13975818321 颜先生
网站知识类别
 
 联系我们

公司总部·市场部
株洲市天元区泰山路海联创业园2楼
电 话:86-731-22507137
    86-731-22507127
传 真:86-731-22507127
网 址:www.wintoo.cc

公司厂址·生产部·一厂
湖南工业大学包装印刷实验楼
电 话:86-731-22180108
传 真:86-731-22991922
公司厂址·生产部·总厂
株洲天元区天台金谷工业园
电 话:86-731-22182666
    86-731-22188666
传 真:86-731-22188666

网络订单:QQ:583284597 
     QQ:435538216
     QQ:741771357
     QQ:1090721205  

 
12306抢票插件拖垮GitHub
发布日期:2013-1-27  浏览次数:1912

连城404在其微博上发布,12306抢票助手插件12306_ticket_helper因为引用了GitHub上的js文件,洪水般的用户请求拖慢了整个GitHub,以至于GitHub管理员不得不请求作者不要引用这些文件

微博上的精彩评论:

CSDN技术副总裁范凯robbin:

浏览器插件“12306订票助手”未来一两周随着越多人春节刷票,极可能拖垮Github。查看问题详细讨论作者自己描述的原因看下文的引用。代码逻辑很欠考虑,返回403就不应该不停的隔5秒轮询重试了,结果搞成了DDOS。

@cnsns:

是一个订票插件引用了GitHub的文件,而这个插件被金山的猎豹浏览器,和淘宝的某个服务使用,于是GitHub瘦不了了。特别建议点入那个链接,电梯直达下层,很欢。

Max_HeY:

这是在转嫁负载了,Github本身就不是高并发类型的使用需求,被一下猛戳上亿次挂了很正常,不能用这个解释铁道部那个最多值1万块软妹币网站的垃圾。

J-逍遥游:

开源的力量强大,建议发起者采用一个合适的license以便保护原创,吸引更多开发者拓展插件功能,规避法律责任和防止商用。

叶落孤舟:

「我说是抢票插件,果然是,猎豹抢票版。」目前综合多方分析,是因为该12306抢票插件被打包进猎豹浏览器抢票专版中,会去GitHub查询更新信息,由于该版本猎豹带来的访问量巨大,GitHub已经将该插件的访问重定向到作者自己的网站,目前GitHub已经恢复正常。据知情人士说,该服务将迁移到新浪云上。

ohnhax:

GitHub为什么会被一个抢票插件搞挂?第一,该插件用户众多,从原作者透露的信息,至少有10000+以上;其次,猎豹浏览器内置了该插件,并大量分发;再次,可能有大量无良投机分子非法将该插件重新包装在淘宝上销售。最后,最关键的一点是,铁道部太烂导致大家都要用抢票插件。

Chinainvent:

咱们买票,还伤害到国际友人了,对话还算诚恳@Bergwolf:12306躺枪啊,看ticket明明是某chrome/firefox的自动购票脚本开发者干的。GitHub也太不行了吧,会用脚本购票的人相对12306的访问量可以完全无视。

GitHub上的精彩评论

liyinkan:

其实我想说,这个插件非常畅销。12306是一个不巧的神话。“天王盖地虎,宝塔镇河妖。”猎豹浏览器也躺枪了~GFW其实是在保护全世界的人民,这是一盘很大的棋!

Twitter上的精彩评论:

Google搜索部门工程师Rui Lopes:

记住了同学们,服务器扩展性是多么重要,以及如何把GitHub当CDN用到爆;不知道GitHub有没有自我保护机制,这货看起来蛮容易DDOS的……

信息安全技术工程师Peck:

我们平时的扩展性都是纸上谈兵,.cn的扩展性才是实战。

12306订票助手”的开发者iccfish(木鱼)在GitHub上对此次事故做出的解释:

因为之前更新检查的js文件我一直放在GitHub上,所以GitHub上始终都是最新的,因此我一直用这里的js来检查更新。之所以这么选择的原因还有一个是:Chrome的安全特性,在HTTPS协议(12306)下,不允许运行从非安全协议(HTTP)下过来的文件,因此我手上没有任何可用的HTTPS服务器,GitHub正好是HTTPS,也就正好符合了这个要求。

但是GitHub的Raw有个限制(貌似是),具体限制多少不清楚,表现为:当访问稍微频繁点的话,就会返回403 Forbidden错误。因此导致更新推送几乎不可用。于是我没有经过深思熟虑便用了最简单的方式:重试。当加载返回403的时候,便延迟5秒尝试重新加载。

但是,越是这样执着,GitHub便越人死扣不肯返回正常的文件,直接导致反复重新加载。因此,5秒的周期会导致成为一个类似于DDOS的趋势。我实在无法估计到底有多少用户,因此也无法估计到底会有多少请求发送到GitHub.

当然,采取这样措施的时候还是有考虑到负载的。之前的更新检测放在查询页面,但是查询页面是个反复刷新或请求的页面,因此我估计这个已经会成为一个攻击的来源,因此将检测更新代码移至最顶层框架里面(也就是根路径/otsweb/或/otsweb/main.jsp),在反复刷票的情况下,这个框架基本上是很少被刷新的。不过很明显我低估了用户数和GitHub的执着度,虽然做了如此的变动,但还是导致GitHub收到影响。

由此得出的教训是:1.不要低估用户量;2.做事不要太执着,得不得的就非要获得,否则誓不罢休。

 

 
 
株洲市天元区泰山路海联创业园2楼  ■86-731-22507137 ■86-731-22507127 ■www.wintoo.cc
Copyright © 2006-2014 株洲云天文化传播有限公司 版权所有
网站设计:鑫冠公司     网站备案号:湘ICP备17010153号