每年春运时铁道部和 12306 都要被喷死, 自己也和 12306 斗智斗勇了两三年, 这个冬天跟着 @scat 君折腾了很久, 随手写点什么说说这事.

提前说明我只是火车迷, 不是铁道部的人, 用不着帮铁道部把黑的说成白的, 我自己也有各种怨气要喷, 只是希望能提供一个相对客观的事实供大家来参考参考. 前半段跟喷子对喷和对 12306 的吐槽的会多点, 后面有一些胡思乱想的一些可能称得上是建议的东西.

喷子和不那么容易的 12306

然后以一个标准喷子的口气对那些说 12306 做的很烂随便找个本科生就能写的人骂一句, 去你大爷的什么时候国内的学生素质这么高你有多少我要多少; 再对一些所谓业内人士说的这种负荷找淘宝什么的能轻松解决的观点说句很抱歉, 这两个虽然在规模和突发性上有不少相似点, 但是还是有很多不一样的地方, 比如淘宝上一件商品如果有多件是无区别的, 而火车票一张就是一张, 有人买到上铺还不干非得换下铺, 而且这里面一张票就是一个锁, 而且淘宝超售了最多补货或退款, 火车可不是说加床或加位子就能加上去的, 而且要是先跟你说买到票了然后说不好意思超售了我们退钱给你, 不知道有多少人想直接穿过显示器把那边的服务器给砸了; 最后说说 12306NG 那帮人, 最近没关注, 一年前看了下那个论坛和所谓的发起人, 很可惜里面大部分都只是夸夸其谈一些自称砖家的喷子, 很多人估计都没做过百万规模的系统就敢各种意气风发指点江山, 这种人都能说出靠谱的整体解决方案和细节注意点来那就见鬼了.

喷爽了咱们来摆事实讲道理说说 12306 的各种不容易, 先说我们是怎么搞他的:

> 最早的 12306 基本上就是一个高校实验室的产品, 空闲时段可用, 用的也还凑合. 据说有收钱不出票的情况, 不过我还没遇到过, 所以不好评论. 退票的钱不是实时到账的, 快的几天慢的一个月我也都遇到过

> 等到了高峰期的时候, 开始各种登陆不上, 各种刷不开页面, 或提交不成功. 这时候最大的问题是带宽和前端服务器不够, 压根抢不到一个有效连接.

> 等把带宽问题基本解决后, 发现每一次页面加载都需要做太多次 GET 操作, 而且很多页面数据不优化不压缩, 虽然系统还用了 jQuery 什么的至少看起来算是跟上先进生产力的技术, 但是整体还是比较糙, 据说是用 CDN 和大量加机器来算扛住. // 不过到现在一次页面加载需要获取的资源还是太多, 而且一开始没做内部的负载均衡, 容易出现一个 ISP 解析过去都在少数几台机器, 所以同一地区不同 ISP 接入的速度会有明显差异 (比如北京联通用户多, 基本就卡成幻灯片, 用用户少的电信线路就相对靠谱点), 而且个人认为不少机器加的很浪费

> 有了缓存机制后发现一个巨坑爹的地方, 12306 似乎把后台实时数据和 CDN cache 在某些地方用反了, 比如余票等实时性非常强的数据反倒在前端有一个 cache, 平时还好, 但是高峰期放票瞬间这个 cache 就要命了, 如果你赶巧碰上一个更新较慢的 CDN, 估计等你刷到数据时票都被别人买完了 // 这个问题现在还是没有解决, 所以才有使用一些专线 CDN (比如传说中的海外线路) 可能会保证网络比较通畅 cache 更新也比较快的说法

> 等机器, 带宽, 缓存什么的搞差不多后, 开始有技术流的 hack 手段出现, 曾经有这样的刷票方法: 要买 2.3 的票, 但是还有几分钟才放票, 不确定自己是否一定能命中更新较及时的 CDN, 于是可以先查 2.2 的票找到对应车次的任意席位的票, 在填写乘车人信息时改 POST 请求中的参数, 把时间改成 2.3, 席位改成自己想要的 (比如硬卧), 然后强制提交, 只要到了放票时间, 不管自己连的前端服务器是否更新余票缓存, 都可以把这个请求提到后端进行处理. 这方法我用过, 很爽, 可惜现在被封了. // 封的手段是在提交订单时加了一个加密串, 发到站, 时间和车次必须和加密串对应才能提交. 不过这个加密串在同样条件下每次查询都可能不一样, 但是同一个验证码可以用无数次 (或者是一个比较长时间段内都可用, 没确认), 所以可以用大量的机器密集轮询 12306 不同的前端服务器获得对应的加密串, 一旦有这个数据就可以构建数据强制提交了. 此方法目前还可用且有人在用, 不过需要考虑 12306 现在开始限 IP 或限同 IP 的连接数了

> 12306 注册帐号需要提供证件号, 不能坑别人, 所以默认大家一人就是一个帐号, 同帐号只要有订单没完成, 就不能去下别的订单, 如果一次要买不同车的票, 那就疯了, 还好 12306 允许护照/港澳通行证什么的也可以注册, 谢天谢地又多几个帐号可以一起刷了, 果然办个护照什么的还是没坏处的. // 这个限制其实也能绕过去, 你收集一堆朋友的帐号给你抢一张票不就行了. 还有个更 ws 方法能很容易搞到成百上千的帐号, 个人使用怎么着也都够了, 具体方法还是不说了, 免得被封

> 能搞到提交所需数据, 也有足够的帐号去刷, 那接下来的问题就是怎么把能自动化的地方自动化. 各种抢票助手的原理大致都是做一个浏览器插件, 自动重试查询, 并且监控对应的票额, 然后把一些能自动完成的步骤自动完成 (比如点下一步什么的) // 这里还是有带宽的问题, 其实并不是每次都要把所有的流程都走完, 获取的数据也只要核心数据, 不少插件应该没考虑好这个, 还是对用户的网络有比较高要求. 另外 12306 也做了一些限制, 比如连续两次重试时间不能小于五秒, 偶尔也改一下 URL, 做个 302 跳转什么的. 不过整体而言这个封不了, 完全模拟用户行为, 后面的一些 hack 也基本是这个思路

> 一直到上一步, 应该说已经能将大部分操作自动化完成, 唯一的麻烦就是验证码. 12306 一直到 2013/01/25 用的都还是用一套非常弱的验证码, 字迹清晰颜色差异明显, 最关键的是字体似乎只有两种, 随便找个学过基本的图形学的本科生应该就可以搞定, 先做二值化提取出有字的部分, 然后做水平和垂直方向的投影, 按区块直接跟已知的单个验证码特征库最对比就可以了. 死猫君和其同伙用 C/C++ 实现, 能做到 1ms 一个验证码, 99%+ 的准确率, 12306 在这样的识别效率面前已经完全不设防, 想怎么搞就怎么搞. // 但是超简单的验证码已经从 2013/01/26 开始变成了一个相对复杂的, 原来的方法需要做一些优化才能用, 且识别率可能不那么高

> 就算验证码的识别率下降, 但哪怕只有一两成的成功率, 机器还是比人快的. 12306 的对策一开始是加浏览器参数校验, 如果是裸的 POST 请求就拒绝掉, 但是 http header 这种东西, 自己人肉走一遍流程把对应的数据扒下来让机器模拟还是毫无压力. 接下来 12306 是不停的改接口 URL, 虽然最后还是落到同一个处理接口上, 但是加上了跳转判断, 直接提到最终接口的会被拒绝, 到这就变成猫鼠游戏, 12306 改一次 URL 对应的机器行为就要跟着改一次. 估计是今年各种机器行为搞 12306 搞的比较疼, 虽然他们已经提供了超过一千个对外 IP, 也还是怕被这么搞, 接下来的一招是加了更严格的间隔时间限制, 这时候机器行为的成功率就很重要了, 一旦重试最少五秒就过去了, 而且有一些步骤加了很猥琐的隐藏等待时间, 机器提交太快会报错, 而慢一点接近人的速度就没事. // 最后那个限制真心无解, 不过对手快的人也是很伤的, 别人眼尖手快你还能不让别人买? 跟 @scat 吐槽说看来 12306 对他们的网络很有信心, 正常人五秒内是刷不开第二次或能提交上请求的. 另外机器重试时加个随机附加时间, 可以对人的行为模仿的更像, 这个 12306 没法做特征库来判断是人的行为还是被机器刷

> 攻防到这阶段, 两边基本就没什么办法了, 不过 12306 干了件更 NB 且 WS 的事情: 同 IP 限制登陆人数和封 IP. // 不知道 12306 怎么判断的, 反正 jike 他们那种抢法绝逼是要被封 IP 的, 但是很多企业对外出口就一个, 要赶上员工集体抢票, 结局就是集体悲剧, 反正我在公司悲剧过几次 -.-|

目前拉锯战就到此, 如果是真的搞技术的人, 要是自己的产品成天都在被一群这么蛋疼的人这么玩, 估计早就疯了, 所以说 12306 今年系统一直还可用 (虽然还是会卡还是没有票), 且一直在增强防御, 还是挺不容易的

关于 12306 和铁路客运的吐槽及建议

前面在同情了半天 12306 后还是吐槽没票这个现实, 没票的最大原因还是运力不足, 大家都想过年前一天到家, 那单日发送量必然爆表, 但车就那么多, 只能靠抢

运力不足有一些变通的方法, 比如加挂车厢, 动车重联等方式来提升已有运力, 这个大家都很爽; 比如卧代座 (硬卧车厢当硬座买, 一节车厢大概多卖 20 来张票), 这个大家也觉得还好, 遇上比较 nice 的车上铺还能爬上去轮流躺着睡觉; 比如开临客, 这个似乎就不那么灵光了, 大家对临客的印象还是又慢又破的绿皮车, 经常让车和晚点, 殊不知现在连高铁都有临客, 只是不挂 L 的车次, 临客最大的问题还是时间不好, 一般都半夜出发或到达, 除了这个其他都还好, 我坐过北京到南宁的临客, 空调车人也不多, 除了慢了点其他都巨爽; 比如提升车底周转率, 普速时代最多就是把长途车到终点后再开个短途, 把到下一次发车前的这段间隔用起来, 这个意义好像不大, 而且本来车还是要整备的, 但是动车和高铁时代提升周转率就很有意义了, 同样的北京到武汉 1225 公里, 一路不停按 250 的速度要至少五个小时, 但按 380 的速度跑就不到四个小时了, 同一列车底长短混跑, 一天可能就能多开一趟车, 可惜这个被现任铁道部的猪头领导以安全为由强制降速, 而且给动车组生产厂家的订单也不加, 导致需要车的时候没车, 单车底也还有检修里程限制, 不可能 7*24 连轴转, 坑爹啊这不是

另一个导致运力不足的问题是车票价格, 现行火车票价格已经十多年没变了, 期间还经历了六次大提速, 其他交通方式和物价已不知道涨了多少, 偏偏铁道部自己还涨不了价 (发改委什么的一堆流程要走), 所以只能绿皮改空调, 普速变快速 (虽然实际时间可能还慢了) 来曲线救国, 动车和高铁的票价是明显上了一个档次, 所以也能解释为什么有高铁后普速必然会少一堆, 大部分国人还是缺钱不缺时间的主, 特别是学生这种巨叽歪的群体. 造成同样结果的还因为人民群众的生活水平提高了, 也娇气了, 以前有硬座就很好, 现在很多人还非卧铺不坐, 最狠的是只要硬卧下铺的, 人家理由多充分: 软卧太贵硬座不爽上铺难爬, 需求就这样被密集化 (很多人都是只坐某趟特定车的某种特定铺)

在供给远小于需求的供需现状下怎么搞都无解, 那只能把问题退一步, 让大家怎样以一个 “公平” 的方式来搞. 我自己想过一个方案, 后面有一次问了 @cnberg 印度是怎么弄的, 发现跟我想的基本一样, 我先说说印度怎么订票:

1. 订票提前周期很长. 订票时
– 1.a 如果有票则付全款出票, 完成
– 1.b 如果没票则交押金 (大约 10 人民币) 进入一个排队队列
2. 排队过程中
– 2.a 可随时查询在队列里的位置, 当新票额放出或有人退票或退出排队, 你在队列里前进, 排到后付全款出票, 退押金, 完成
– 2.b 如果到开车时间还没排到有票的位置, 退押金, 完成
– 2.c 主动退出排队队列, 押金不退, 完成
3. 退票
– 3.a 退票收取大约 10% 的手续费, 完成

这里面最爽的是引入了排队机制和获知自己排队位置的查询接口, 让整个过程对乘客而言更透明. 但是当时我们讨论时也说到, 中国春运是刚需, 提前半年估计也会在订票的时候就把系统和队列压爆, 只是把现在提前 20 天的坑爹提前了而已, 而且对那些没法提前那么长时间确定行程的人是一种伤害. 而且估计印度网民远没中国多 (具体数据没查, 但是用脚也能想到), 所以系统压力没那么大

我的方案比这个更激进点, 不同的是
1. 排队时就可以先付全款, 这样一旦排到票马上就能出票, 不至于说排到票时自己不方便, 因为没法付款而导致被从队列里强制踢出去
2. 退票费按退票时间到开车时间的间隔依次递增, 越晚退票手续费越高, 这样也让那些买多张票备用但最后只用一张的人提前把资源让出来给有需要的人 // 现在就很多人买好几张票备着, 走之前才退, 结果其他有需要的人也来不及捡漏

这些都是比较大的系统性变化, 我们这些玩票也就吐吐槽, 如果有不妥或没考虑到的地方也欢迎讨论

落到 12306 本身, 感觉可以提供一个精简版入口来满足订票需求, 像界面/退票/添加修改常用联系人之类的操作很少用到, 没必要每次都为了兼容这些操作而走那套有巨多图片和 .js 加载的系统, 刷票助手什么的其实就是在帮忙减轻网络压力, 反正大家只要能定到票, 直接做个纯文本界面也无不可