①

先来矫情下再说正事，自从有人说我就喜欢矫情后，我决定矫情和正事儿一块儿说，看你们怎么吐槽。
晚上和某人聊天的时候提到了『倾国倾城』这首歌。这首歌是10年听到的，国庆的时候，那时候是合肥体育馆搞的一场晚会，好像是宣传旅游的，旁观席的票子，和同学一块儿坐得离舞台好远好远，人都看不清。后面黑压压的，死气沉沉，就舞台正对面那一块儿方形的地方热热闹闹锣鼓喧天哨声齐鸣。后来看到电视上再放这场晚会的时候，竟然热闹异常……顿觉原来果然眼见为实，虽然眼见的也不一定为实。
这首歌是那场晚会的主题曲，第一次听到的时候便很喜欢。喜欢那听起来凄婉的旋律和哀伤的歌词，却透露着幸福的窝心，好似极不容易才走到一起的两个人，终于只剩下相守的约定。当时我和@丁建康 说，我以后结婚就要放这首歌，他歪着头看我说，你不觉得很破坏气氛吗。我说不啊，这首歌多凄婉动人，真挚的感情总是很难相守的。

那年国庆回家的火车上对着某人说，我决定找一个在自己身边的女友了。
然后两年过去了，我却依然在这里矫情，守着有或没有的未来。

 

②

来写点和GitHub有关的东西吧，貌似这两天因为这东东搞得我有点颇受关注，亏得我不用新浪微博（我会告诉他们其实我有吗，就是不发而已……），而他们也不会在腾讯微博上转这件事儿……
晚上回来就在回复邮件，回复讨论区的各个帖子，微博的私信和艾特，总数加起来五六百，回复地差不多的时候已经快十点半了。真心累死，白天改脚本饭都没来得及吃，晚上又把时间全部砸进去了。 

被关注的原因很简单，他们说我把GitHub这个世界性的源码托管网站给DDOS了。起因是我把订票助手给开源到GitHub上了，然后捎带引用了点资源，后来15日小高峰到来时，GitHub的Ops团队在我的项目上file了一个Issue，大意是他们检测到12306.cn引用了这个repository里的一个资源，然后这个资源对他们的服务产生了负面的影响，所以这个仓的所有raw功能已经被禁止（其实这也就是后面很多人说音乐不响了的原因）。好了，由此引发所有的笑话。
关于这个的起因，需要从很早以前说起。

引入自动更新。
由于12306订票助手是个很特殊的东西，依赖于铁道部的网站而存，并且其运行极度依赖网站本身的功能以及页面结构，所以随着铁道部的改进，很容易失效（虽然他们的前台样子从开始到现在，一年多了几乎就没变过……他喵的为什么我又要用年做单位说时间，真伤心）。因此为了保证功能的正常，订票助手在很早的版本开始就引入了自动更新机制（1.4开始）。最开始的更新都是放在自己网站上的，并且区分了Firefox和Chrome。
最初的助手是以UserScript的模式出现的，调试在Firefox下调试。在Firefox下时，Scriptish提供了支持跨域的GM_xmlHttpRequest功能，可以直接用ajax访问我的网站。但是在Chrome下，则没有这样的便利，不支持跨域ajax，所以用的是引入script脚本的方式检测更新。在后来Firefox和Chrome分支完全合并后（最开始针对不同的浏览器分离的，后来发现同步实在太麻烦了），舍弃了一些特异的功能（如GM_xmlHttpRequest），为一些功能做了适配（如桌面通知），更新也就用下来了。
但是后来不知道什么时候开始，这个更新机制突然失效了。为啥呢，这要从另一件事开始说起。

那就是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证书什么的但是我去申请的时候，连那提供商的网站自己都证书错误了。

于是事情都解决。
但是后来Chrome下的更新通知越来越烂，这是很早以前的事情了，到后来演化到几乎不通知的地步。
后来才发现，GitHub对于第三方引用的资源，正常返回的概率是很低的。就算很少人用的时候，也几乎是每请求5-6次才肯返回一次正确的内容，其它的时候，全部返回403错误（也许是我以为很少人用？）。
本来没在意，不肯返回就不返回吧，反正总有那么一次会返回的。 但是后来问题越来越严重，严重到几乎没有人能获得新版本的推送，直到有人拿着上世纪的版本来问我问题的时候，我才发觉原来他们竟然从来没看到过更新通知。
因为之前的更新放在登录页，可是有多少人会去反复刷新登录页？所以这个方案太糟了。几乎没用，遇到了GitHub，几乎死定。

好吧。觉得应该换地方放。
可是又求了一圈儿后， 发现有服务器的人不少，有HTTPS服务器的人影儿都没见到。
于是越想越郁闷。心里一横，丫不是返回403么，不是总爱让人重试几次么，那就重试好啦。一次403就隔五秒，总会又一次返回的吧？
可是测试下居然要将近半分钟才能获得，问题是这是登录页啊谁会那么二呆这里等你重试。于是就把这个检测代码放到了主框架中(根路径/otsweb/ 或主页面 /otsweb/main.jsp) ，让它后来重试吧。
测试的时候工作蛮好。可是我觉得这样效率实在太低了，所以单独为Firefox重写了一段检测代码，启用GM_xmlHttpRequest来检测更新，直接从我的服务器上获得数据。
此时发布是3.9版，也就是10天前发布的版本。 

自从过了国庆后，订票的人每天都在增多，直到五天前，我发觉重试也不是办法。GitHub的服务器属牛的，人一多你重试也肯定碰一脸灰。所以一边在琢磨着找HTTPS的服务器，一边看看有没有新的替代方法。
终于在4.1.0版中找到了全新的方法，完全绕开Chrome的安全性设置直接访问http的资源，虽然限制不少，但起码可以甩掉GitHub这个不靠谱的家伙了（也不能这么说，源码仓毕竟不同于文件服务器，请求一次的代价很大）。但是问题是，他喵的GitHub不肯返回正确的版本文件，已经下载Chrome版本的人全部无法获得更新通知，他们根本不知道有更新。
4.1发布距3.9只有8天，但是因为这之间下载的人迟迟获得不了更新通知，所以我也对如何让他们更新束手无策，一筹莫展。 

好嘛……16号GitHub的Ops就file了一个Issue，也就是之前的那个事情。我提到有重试机制，那位仁兄啊了一下，把返回的403改成了空的200错误，于是说一下子流量下去了哎。
我想那必须的。但是……等下，这伙计竟然能改响应？那为啥不让他帮我重定向到正确文件上，这样所有人的升级推送就全都正常了，GitHub这边也会随着他们的不断升级访问越来越少？（新的更新机制和GitHub没有半毛钱关系）。
这同学很爽快地答应了。开始时我天真地让他重定向到我的服务器上，结果后来……果然又让Chrome的安全机制给拦截了，阴谋被识破。
所以这才发现原来还是要HTTPS的才可以……

很晚的时候突然想起了SAE。虽然SAE不是为了这个托管用途的，但毕竟版本信息文件很小（约100-200字节），并且随着人的更新，访问会不断减少，所以应该没问题。稍微看了下sae的文档，貌似HTTPS并发每秒是500，什么的当然都要比HTTP的低，但作为临时使用，应该没问题。
这时候已经是下班路上了（琢磨服务器的事情将近八点才回） 。路上猎豹的LL留言我说，微博上疯传你搞挂了GitHub啦。我看到这消息的时候囧囧的，想这事儿很大吗，怎么微博上有人说？然后我说准备临时转移到SAE上。LL说，你觉得SAE能扛得住么？
我囧囧的，肿么会有那么大量吗？完全不会啊，何况会随着更新越来越少的。
晚上就在SAE上开通了空间，放了过去，艾特了GitHub Ops Team的那伙计让转，他很快速地response了~稍等片刻起效。

然后神奇的事情就发生了，新浪SAE的一位工作人员在半小时后从北京给我打来电话，弱弱地问我说看到微博上传你决定来祸害SAE了，然后我看了下，你确定要用HTTPS么……（声音忒小，我怀疑是弱弱的，祸害这个词是我YY出来的……）
然后我跟他解释留下为啥要用HTTPS。然后他开始说个不停了 =。= 不得不说这伙计耐性一定很好，说话速度极慢，而且一件事要重复好几遍，大概觉得我是个门外汉完全不了解事情的严重性。
大义就是，SAE是计算密集型嘀，用于文件托管会性能很差；HTTPS性能比HTTP低很多，然后并发十万是绝对扛不住的，一定要上CDN云云。
然后跟我凿凿地说，上十万并发一定要CDN，万一真扛不住我们可以给你提供临时的CDN（咦？不错的说），但是HTTPS没法CDN啊。
我嘿嘿奸笑，说你知道不，12306就是HTTPS的CDN。那伙计显然懵了 =。=
再后来？我欣然接受他的建议给文件设了过期时间（话说主动设置过期时间的确有很大用处，虽然这里只是一次提醒，升级了就不会再访问），然后还一通安抚说，放心吧不会把SAE搞挂嘀，我会随时看嘀，万一有问题会随时联系你们嘀。

我心想，不就是些老用户么，撑死了几万，升级一个少一个，哪来那么多访问的，GitHub会那么严重，是因为死活只肯返回403导致类似的一个风暴行为，代码逻辑有够弱，但我也实在没想到GitHub是如此铁骨铮铮的汉子就是一个字节都不肯返回 =。=
事实也证明了我的推测，没那么严重，还十万并发嘞 =。=

话说因此事昨晚新浪微博的一位编辑还邮件说让我说说我和助手背后的故事，肿么感觉听起来怪怪的。今天InfoQ的一位编辑也说给我一个访谈，我心想喵了个咪的人家林X静是写脚本受访，你们让我搞挂GitHub受访啊，大大的居心不良啊！
后来InfoQ的编辑邀请我明年四月去北京参加一个什么秘密大会，可以看到GitHub上Ops团队那个和我沟通的人，我心想丫的我去就是犯二了，不是去找抽么……
不过总的说来就是我这人很懒很懒，不愿生太多枝节，还是钟情于平静的生活的，因此也就什么都婉拒了。只是惊闻后来有Google和微软的一些大牛也在那个Issue里出没，真心郁闷，他们不会因此把我弄上黑名单吧，要知道我在GoogleCode上也有两个托管项目啊。
只不过因为邮箱里被GitHub的邮件轰炸了，500+的邮件，大多数人也都是观光神马的，真心烦躁，于是直接删掉了Repository。我虽是个容易心软的人，但是决定做什么事后，还是比较坚决和坚持的。可怜那些国外的IT同仁们的评论淹没在中文的水中，真心对不住他们，就是丢不起这个脸啊，到处观光团神马的。

最后贴一张今天SAE全部的请求图。最高一分钟671，总请求十几万。没那么多，对吧？不过也不错了，以后说不定还真能玩玩SAE，要知道我就是随便申请的 =。=

然后我默默感慨下，就这样的流量能把GitHub搞挂？我低估了重试的能量，也高估了GitHub的负载能力……不过话说回来，如果这些人后面始终刷票，那么累积起来的请求以5秒的频率发的话，还真难以想象后面的请求数……所以对于无限重试的这回事儿确实要很小心谨慎啊。然后我还对GitHub返回一次403需要消耗多少资源有点儿兴趣。

[UPDATED]————–
看到有人把此事归结为我把GitHub当CDN，然后还煞有介事地分析起用GitHub当CDN的利害，我竟然没有任何想法，只想说，你们……想得太多了。至于说我人品有问题的，我也不屑去解释。只不过，我用别人说的loadJS直接从GitHub加载整个JS文件了吗？我是因为自己服务器扛不住不想自己出服务器才去GitHub上引用资源的吗？我说过只是为了取得一个版本信息，不知道你们从何处看出来我想把GitHub当CDN的。我是在没有找到解决办法之下才不得已用的，因为那时没想到其它解决办法，也并没有想到会有那么多人用。这样就能归结出我把GitHub当CDN而且人品有问题，真不知道是你们的逻辑太强盗还是我太幼稚。在找到iframe能解决之后我当下就换掉了，在GitHub的Ops提交那个Issue之前就换掉了，只不过之前的老版本因为这个问题没法更新所以才导致问题的发生，我把GitHub的源码仓彻底删除都挡不住你们这样去议论是是非非啊。我可以说以你们这是以小人之心度君子之腹吗。
整件事归结起来就是因为GitHub之前对文件喜欢返回403错误的诱导+程序逻辑上没有足够考虑的缺陷，一个简单的原因怎么都能让你们牵扯到CDN和人品上去了，语文水平是看门大爷教的人表示真心理解不了。