12306

温故而知新,关于国内火车票

好几年前因为和 12306 各种搏斗,写了两篇关于订票的分析,详见 12306 和火车票那点事补遗: 12306 和火车票那点事,参考了当时能找到的其他国家地区的做法,提到两点可以改善的,目前看都已经实现了

1# 排队时就可以先付全款, 这样一旦排到票马上就能出票, 不至于说排到票时自己不方便, 因为没法付款而导致被从队列里强制踢出去

现在的候补购票已经全面推广了,先付钱,有新的空位直接出票,可以同时排不超过四趟车

2# 退票费按退票时间到开车时间的间隔依次递增, 越晚退票手续费越高, 这样也让那些买多张票备用但最后只用一张的人提前把资源让出来给有需要的人 // 现在就很多人买好几张票备着, 走之前才退, 结果其他有需要的人也来不及捡漏

退票费已经改成十五天前不扣费,十五天到两天 5%,两天到一天 10%,一天内 20%,而且对改签后退票执行改签前的时间席位计算,避免有人钻空子改签更后面的低级别席位来节省退票费。春运等时段不分提前量统一 20% 退票费,这个其实又把节奏退回一样了,但这种特殊时段,再提高估计正常出行的人要各种不爽,也没有太好的办法

年前买票完成

昨天刚继续吐槽了下买火车票, 今天就出事了

鉴于前两天用 UC 抢票没抢着, 考虑干恶事还是找流氓, 在虚拟机里装了个 360 浏览器. 打开看了下人工抢票还是一样的方式, 只是 360 好像把验证码自动识别填写做上去了, 果然还是要狠一点. 离线抢票看着就是猫君那一套了, 差别只在不能选预售期以外的, 车站车次做了下实时获取

上午 12306 做了个灰度更新, 验证码换了个样式, 之前的自动识别验证码估计要全挂

上午杭州东放票的时候, 不管是人肉还是 360 在线, 都撞上 HOST 没及时更新的坑, 压根没刷出来票, 离线抢票也挂了, 家喵在单位电话订票也没定上

转战下午上海南始发的票, 15:00 左右开始 12306 网站就各种不稳定登不上了, 快到 15:30 的时候看这网络怎么也不靠谱, 直接上电话打 95105105, 奇怪的是明明是上海南放票的时间, 怎么打杭州的电话会系统忙, 加 021 区号反倒很容易拨通, 咔咔给家喵定好回家的票, 大事落定方可心安

随手刷了下 12306 网站还是挂, 15:34 左右再拨电话订票, 居然还定到一张… 这, 好像不太好跟家里磨叽说我过年自己开车回去了?

定完两张票, 用手机 12306 刷了下居然还能看到余票两张, 不过提交订单的时候已经提示没了

想说什么呢?

  • 12306 网站, 电话, 手机 APP 都可以订票, 东边不亮西边亮, 多试下
  • 有一个渠道挂了的时候反倒是利好, 立马转别的渠道, 可能票额更多
  • 电话加不加区号还是有差别, 查好自己坐车铁路局管辖范围内的不同区号, 大城市的线路多拨通率可能会高点 (也可以反其道找没人的小地方)
  • 每年面对各家奇葩的抢票工具, 12306 应该还是留了几手的, 看什么时候放大招, 上午换验证码算一招, 下午自己挂了应该是用力过猛

补遗: 12306 和火车票那点事

两年前在北京折腾 12306 时写过一篇 12306 和火车票那点事, 后来想想还列了一堆东西可以写, 不过后来忙忘了 (其实就是懒…), 现在反正都过时了, 再列出来看看当时的一些吐槽现在是不是还有效 (下面说的都是 2013 年 2 月记录的内容, 关于 2013 年春运, 本文写于 2014 年 12 月, 关注 2015 年春运)

当时觉得 12306 可以提升的几点

  • 订票流程中随机步骤验证码插入, 以更多的抵抗机器行为

这个没法更好的插入, 今年 12306 干了个比较狠的事情, 如果你频繁切换 HOST 去查, 他会随机返回一个查询失败并且把你踢出登陆状态, 后面就算查到票要定时你还得重新登陆, 其实就是随机验证码插入

  • 提前显示票仓, 提升透明度

这个无解, 更透明就意味着没法人为操纵, 万一有突发事件了估计都没法周转. 而且现在是网络和电话提前 60 天卖票, 窗口和代售点延后两天, 还要考虑票额分配比例是否要动态化

公众关心的问题

  • 退票成本太低是当前游戏规则里的最大问题, 导致黄牛可以去刷票抢坑, 退票后再买给要转的人

2013 年底的时候退票费改革了一次, 2014 年底跟着预售期延长又改了一次, 某些程度上把退票成本拉高了 (但是还是有很大漏洞, 具体自己研究就好, 点到为止). 更狠的是退票后不马上退回票仓放出来, 这个就会导致退出来的票不一定自己能买到, 黄牛的压力还是变大了的

  • 开放给第三方的问题是没法保证 “公平性”, 而且, 这不就是代售点么?

目前来看还没有第三方敢去接这个明显供不应求的市场机制, 传闻 12306 也找过 BAT 的人, 做过大规模系统脑子正常的人都婉拒了, 阿里在排队系统上给了建议和帮助, 不过也还是没能解决本质上票不够的问题

  • 公知嘴脸: 铁道部亏钱就是浪费国家资产, 铁道部赚钱就是搜刮民脂民膏, 火车坐的人太多票价低是要担社会责任, 坐的人少票价贵是坑爹

过了两年, 现在公知似乎更像是贬义词了? 不过随着动车越来越多, 公知们又可以有不同的喷点

之前说可以参考下印度的机制, 不过从上面这个长微博里提到的情况看, 大部分时候还是我们对其他机制想的太乐观了…

一些抢票建议

  1. 使用 http://dynamic.12306.cn/otsweb/ 登陆
    a) 不要 https, 坑爹的证书不会用就不要乱来嘛, 而且这样之前 github 被拖挂也不存在了
    b) 不要直接从 12306 主站进, 外面套一堆花花绿绿的不烦么

这个地址已经不能用了, 12306 切了一套全新的, 而且现在就算用 http 也会被强跳到 https

  1. 多开浏览器是有用的
    a) 不确定浏览器的缓存机制, 总之 Chrome/Fx/IE 什么的能开的都开上
    b) 不同浏览器建议用不同的策略

这个还是有点用的, 但是用途不大

  1. 车次/车站别限那么死
    a) 春运等高峰期经常出临客, 而且现在 G/C/D/Z/T/K 都有可能是临客
    b) 前后看几站, 如果不是始发终到不一定有票, 而且非始发站有时候也会有少量票可以抢, 时间可能还错开的, 目标站如果不是该车终点, 有票概率也会偏低 (当然也有之前遇到过武昌福州车的硬卧只卖到武夷山的特殊情况…)

现在分车类型刷已经无效了, 都是一次查询出所有结果, 然后前端 JS 来做过滤, 换发到站还行, 但是 HOST 缓存太严重

  1. 刷余票时车型/是否过路/出发时间等组合变换
    a) 避免被缓存, 更大概率刷出来

同上

  1. 12306 的时间不一定是北京时间
    a) 前后一两分钟都是有可能的, 别傻乎乎按自己电脑的时间卡点
    b) 电话网络两手准备

这个还是有用的, 卡点会从提示预售时间变成预定, 但是票额不一定是马上出来的. 另外如果是学生可以考虑成人学生混刷, 据我观察学生票好像被缓存影响的小一点 (也可能是默认大家都在刷成人, 学生票刷的多了也一样坑)

原文的一些修正和补充

  1. 一个人多个证件的坑已经被补上了, 护照注册的帐号只能用护照买票, 其他同理
  2. 精简版其实就是现在各个浏览器助手做的事情, 当然浏览器助手还做了分布式查询余票 sec 等事情
  3. 现在的浏览器助手做的事情还是没跳出两年前说的那些事, 细节变化还挺大
    a) 分布式取余票的 sec. 这个没什么好说的, 现在就是注意会被踢出登陆, 但是查余票又不用登陆, 所以其实还是无影响, 考虑下全网同步强行提交就好
    b) 验证码识别. 这也没什么好说的, 12306 的验证码加强后还是很容易搞定的, 最多就是错一次重试, 或识别概率不高时主动切换一张验证码
    c) 12306 各种暗处的验证码. 昨天看了一下, 还是变了不少地方, 要重做的话还是要去抓一堆包

最后, 特么今年我的票还没搞定, 之前的工具一懒得修二来不及修, 今天用 UC 搞了一把还是挫, 难道要我去下个 360?

12306 和火车票那点事

每年春运时铁道部和 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 加载的系统, 刷票助手什么的其实就是在帮忙减轻网络压力, 反正大家只要能定到票, 直接做个纯文本界面也无不可