12306 订票助手插件拖垮 GitHub 事件原因始末

事件起因

春节临近，12306 订票难的问题再一次被引向风口浪尖。而这一次，各家浏览器厂商不失时机的推出了“春节专版”。这些林林总总浏览器的共同特点，是集成了一位网友 iFish(木鱼) 的“订票助手”插件。

不凑巧的是，这个插件的早期版本使用 GitHub 的 Raw File 服务作为 CDN，并对返回 403 错误代码的请求使用非常暴力的 5 秒重试。于是，在 1 月 15 日的时候，第一个订票小高峰到来的时候，GitHub 被间接的 DDos。

GitHub 的运维工程师 Jesse Newland 在发现服务器负载异常之后，不得不禁用了这个代码所在 Repo 的 Raw 服务，并在 Repo 里报告了一个 issue —— 他发现 12306 引用了这个 Repo 里的一个资源，由于访问量巨大，这个资源对 GitHub 的服务产生了负面的影响，希望有人可以联系到 12306 的工程师去除这个引用。

身在大洋彼岸的 GitHub 工程师在解决了 GitHub 的服务问题之余，显然不太清楚中国的两点情况：

1. 春运是什么，12306 是什么
2. 12306 的工程师是不可能被联系到的

大家疑问

大家的质疑，存在于两点:

1. 为什么一个浏览器插件需要从 GitHub 引用资源？
2. GitHub 的负载能力这么弱吗？

疑难解释

第一个问题，还是让插件作者木鱼自己来解释：

引入自动更新。

由于 12306 订票助手是个很特殊的东西，依赖于铁道部的网站而存，并且其运行极度依赖网站本身的功能以及页面结构，所以随着铁道部的改进，很容易失效（虽然他们的前台样子从开始到现在，一年多了几乎就没变过……他喵的为什么我又要用年做单位说时间，真伤心）。因此为了保证功能的正常，订票助手在很早的版本开始就引入了自动更新机制（1.4 开始）。最开始的更新都是放在自己网站上的，并且区分了 Firefox 和 Chrome。

最初的助手是以 UserScript 的模式出现的，调试在 Firefox 下调试。在 Firefox 下时，Scriptish 提供了支持跨域的 GMxmlHttpRequest 功能，可以直接用 ajax 访问我的网站。但是在 Chrome 下，则没有这样的便利，不支持跨域 ajax，所以用的是引入 script 脚本的方式检测更新。在后来 Firefox 和 Chrome 分支完全合并后（最开始针对不同的浏览器分离的，后来发现同步实在太麻烦了），舍弃了一些特异的功能（如 GMxmlHttpRequest），为一些功能做了适配（如桌面通知），更新也就用下来了。

但是后来不知道什么时候开始，这个更新机制突然失效了。为啥呢，这要从另一件事开始说起。

那就是 12306 的 HTTPS。

作为一个日点击 14 亿的网站，网宿科技的 CDN 还是很给力的，根据我收集到的资料，其加速节点上百个。但是，作为一个订票的网站又要 CDN 的，为什么会用 HTTPS 协议还是一个自签发的根证书，实在太让人费解。任何一个了解网络知识的人都知道，HTTPS 协议下服务器的负载能力要比 HTTP 的低很多，何况订票又不是什么机密的数据。 总会有人跳脚出来说订票啊多机密，我总是很反对，哪门机密了，车次还是余票数据？

这个 HTTPS 带来了很大的麻烦。

不知道哪个版本 Chrome 引入的安全机制，对于一个 HTTPS 网站，其所有引用的资源（Script 和 StyleSheet 之类的），也必须位于 HTTPS 的服务器上，否则拒绝执行。而我并没有 HTTPS 服务器，因此，Chrome 下自动更新华丽地挂了。 然后是 Firefox。Firefox 下播放不了音乐，我一直以为是 Firefox 不支持，后来才发现是 Firefox 的安全机制在作怪：HTTPS 的网页拒绝播放来自于 HTTP 的多媒体文件。 这俩奇葩让我伤透了脑筋。然后无意中瞥见 GitHub 竟然是 HTTPS 的，So…… 转移过去，变成了顺理成章的事情，我求爹爹告奶奶没求来一台 HTTPS 的服务器，虽说有免费的 SSL 证书什么的但是我去申请的时候，连那提供商的网站自己都证书错误了。

于是事情都解决。

而第二个问题，GitHub 的负载能力为什么这么弱，原因在于 GitHub 根本不适合作为 CDN 服务。著名博客比特客栈的文艺复兴，对此做了详细解释：

1. 它并非静态文件服务器，换句话说，所有请求访问都要先经过一堆服务器代码处理，降低了它的响应速度。
2. 它返回的 MIME 与文件无关（永远是 text/plain），某些浏览器，例如说 IE，不会执行 MIME 类型错误的 javascript 文件。
3. 它返回的 Cache-Control Header 不允许浏览器缓存文件，等于失去了 CDN 最基本的功能。 恰恰因为 12306 订票助手不运行于 IE，也不希望更新文件被缓存，Raw file 的后两个劣势才没有显现出来。但剩下的那个劣势，却让 Github 的响应速度大打折扣，不得不暂时封锁 Raw file 访问。

针对这个问题，原文作者直中要害的提供了两个层面的解决方案：

• 使用 GitHub 作为 CDN 的正确之道：

那么，Github 作为 CDN 的正道是什么？Github Pages。通过加入 gh-pages branch，你可以修改和发布自己 repo 的文件。值得提醒，Pages 虽然免费，并非资源无限，详见官方 Disk Quota 的描述——“虽然我们没设上限，但请各位合理使用。”

Github 轻描淡写的说合理使用，而不是严明规章到 MB、GB，其实是一种潜意识的相互信任。这是一种在贫富悬殊供求关系紧张的中国日益缺少的东西，12306 订票助手的存在就是一种印证：乘客不相信 12306，12306 不相信乘客，最后逼出一个 12306 订票助手，每天乃至每半天更新一次来满足中国人订票回家的需求。

• HTTPS 下如何引用 HTTP 资源：

请问 Google Reader，是怎么在 HTTPS 域下播放优酷与土豆等非 HTTPS 的视频？我们在去年 9 月发现了同样的问题，Google 自己是这样解决的——

Chrome 21 之后，在 SSL 加密页面 embed 非 SSL 的 Flash 会怎样呢？会被默默的屏蔽掉，只留下一句 console 报告。那 Google Reader 是怎么绕过这个问题看优酷与土豆视频的？他们 iframe 了一个非 SSL 页面，再在里面引用 flash（引用页连域名都是不同的）

同理也适用于 Javascript，这也是 12306 订票助手当前的解决办法（Firefox 除外）。不再需要 SSL 下的 CDN 了。

不是结束

也许一切自有冥冥天意。 Jesse Newland ，这位在“订票助手”Repo 中发出警告的 GitHub 员工，早在 2012 年 12 月份，就已受 InfoQ 之邀，确定参加 2013QCon 大会（北京站，4 月 25-27）。除了分享 GitHub 的架构演进之外，Jesse 还会分享他负责的项目——GitHub ChatOps 运维机器人。不过看来这次大会的演讲，他将不得不加入关于 12306 插件的话题。

订票助手的作者木鱼，不堪忍受各界观光团纷纷造访他本开源在 GitHub 上的订票助手代码仓库，最终删除了项目。但他表示仍将继续精简 / 改进这款订票插件。

因为这个插件，铁道部甚至投诉至工信部，要求其责令各家浏览器提供商停止提供附带抢票功能的浏览器的下载。不过就本文发表前，各家浏览器厂商均表示尚未接到相关通知。

这一切还都不是结束。