12306 "慢速排队"功能

[Neo-Zhixing]

提交订单后，排队过程中，被“慢速排队”拦截， 排队时间超过30分钟。

http://www.techweb.com.cn/internet/2018-02-01/2635181.shtml

试用了多个脚本，均有这个问题。12306是通过什么样的方法，识别“可疑订单”的呢？脚本的请求频率并不频繁啊？作者找到破解的方法了吗？

[Why8n]

不好意思，很久没上github了。如果按您所说是“慢速排队”机制的话，猜测原理应该是对某些请求间隔进行了计时，那么可以尝试下对间隔请求进行延时，估计就可以越过这个机制。
后续如果有时间，我会抽空看下能不能解决。

[Neo-Zhixing]

我尝试对几个请求组进行了延时，但是看起来并没有什么用？排队时间普遍在15分钟以上，只有很少几率可以秒速排队通过。

[Why8n]

我试了一下，是可以的。我是对所有请求都延迟了2秒，都是成功下单了。这两天看下能不能找出具体的请求（只有一个账号囧）

[Neo-Zhixing]

最新现象：自春运基本结束后，该“慢速排队”系统似乎已经撤销（对服务器资源消耗大？），我这边订单经过多次测试，全都自然下单了，没有任何排队现象。也许等到下个售票高峰（国庆、五一等）他们还会开启？我们需要保持观察。

[Why8n]

今天测试了下，还是存在慢速这个问题。
具体来说，第一次请求时，需要在获取乘客信息后要暂停一点时间，模拟真实用户选择乘客情景。
然后，12306应该对很多请求都进行了监控，当一次提交失败后，下一次快速提交会导致慢速排队，目前的代码对前几次提交应该可以避免慢速排队问题，但若是提交多次，会被12306监控到，从而重新进入慢速排队。

[Neo-Zhixing]

测试了一下，慢速排队问题仍然存在。看一下我的 https://tra.ink/ticket （仍然有很多bug），在后端用了这套api

。我相当于重新写了12306的前端代码，并在后端做了个代理，而且发送请求的速度和时间，跟12306无差。但是，仍然在某些情况，会出现慢速排队的情况，只不过没有春运时期那么显著。我推测该慢速排队机制，绝不是仅仅通过时间控制那么简单

[Neo-Zhixing]

另一个思路：12306的手机App，和网页端使用的api，是不同的。我抓包了一下12306的手机app，以及几个第三方订票服务app，包括高铁管家等，发现他们请求的都是 mobile.12306.cn的API，但是内容都被加密了。是否有可能逆向12306手机App，然后得到相关的接口和解密算法？按照这些手机app的方法来发送请求的话，那些恼人的慢速排队/session验证/验证码，应该都会得到解决

[Why8n]

移动端和网页端的后台应该用的都是同一套逻辑，应该跟你说的加密解密没关系。
慢速我能想到的就是跟请求时间有关系，你可以试下直接对所有请求都进行延时，如果还会出现慢速，证明还有其他机制，如果没有，说明延时可以绕过这个机制（尝试的时候直接延时，因为如果你前面已经被慢速了，证明你的ip已经被12306监控了，可能会对你后面的操作造成干扰）。

[Neo-Zhixing]

现在，所有请求都有延时了，而且是根据真实用户操作进行的延时，但是仍然会出现慢速排队，说明仍然存在其他某种未知的机制。
IP的封禁和识别，现在12306已经很少使用了，因为很多地区的运营商将很多放在一个局域网内共享公网IP，这时候一旦一个用户使用抢票软件被发现，那么一整个小区的用户，使用都会受到影响。同样的事情还会发生在企业局域网、校园局域网等场景。
移动端和网页端的逻辑，似乎是不同的，因为我曾经抓过包，发现12306的官方app和高铁管家等app，调用的都是来自 mobile.12306.cn 的api，与网页端 kyfw.12306.cn/otn 那一套，似乎不同。而且，如果逻辑相同，为何还要使用两套api？只维护一套api，不是更加节省成本吗。况且，12306的web端，使用的是基于session的验证，跟移动端似乎不同。历史上，12306也曾在web端加入奇怪的js进行抢票软件的识别和验证，而这种验证在移动端是不好进行的。所以我推测，类似的“慢速排队”验证，也应该只在web端存在。

我有时间尽量再研究研究吧，看看到底是什么造成了这个慢速排队。

[zztiswb116]

现在，所有请求都有延时了，而且是根据真实用户操作进行的延时，但是仍然会出现慢速排队，说明仍然存在其他某种未知的机制。
IP的封禁和识别，现在12306已经很少使用了，因为很多地区的运营商将很多放在一个局域网内共享公网IP，这时候一旦一个用户使用抢票软件被发现，那么一整个小区的用户，使用都会受到影响。同样的事情还会发生在企业局域网、校园局域网等场景。
移动端和网页端的逻辑，似乎是不同的，因为我曾经抓过包，发现12306的官方app和高铁管家等app，调用的都是来自 mobile.12306.cn 的api，与网页端 kyfw.12306.cn/otn 那一套，似乎不同。而且，如果逻辑相同，为何还要使用两套api？只维护一套api，不是更加节省成本吗。况且，12306的web端，使用的是基于session的验证，跟移动端似乎不同。历史上，12306也曾在web端加入奇怪的js进行抢票软件的识别和验证，而这种验证在移动端是不好进行的。所以我推测，类似的“慢速排队”验证，也应该只在web端存在。

我有时间尽量再研究研究吧，看看到底是什么造成了这个慢速排队。
目前研究有什么进展么？

[Neo-Zhixing]

并没有。
弃坑了 哈哈

[tkp30]

现在，所有请求都有延时了，而且是根据真实用户操作进行的延时，但是仍然会出现慢速排队，说明仍然存在其他某种未知的机制。 IP的封禁和识别，现在12306已经很少使用了，因为很多地区的运营商将很多放在一个局域网内共享公网IP，这时候一旦一个用户使用抢票软件被发现，那么一整个小区的用户，使用都会受到影响。同样的事情还会发生在企业局域网、校园局域网等场景。 移动端和网页端的逻辑，似乎是不同的，因为我曾经抓过包，发现12306的官方app和高铁管家等app，调用的都是来自 mobile.12306.cn 的api，与网页端 kyfw.12306.cn/otn 那一套，似乎不同。而且，如果逻辑相同，为何还要使用两套api？只维护一套api，不是更加节省成本吗。况且，12306的web端，使用的是基于session的验证，跟移动端似乎不同。历史上，12306也曾在web端加入奇怪的js进行抢票软件的识别和验证，而这种验证在移动端是不好进行的。所以我推测，类似的“慢速排队”验证，也应该只在web端存在。

我有时间尽量再研究研究吧，看看到底是什么造成了这个慢速排队。

加解密用的是ECC，公钥能找到，私钥不知道
用的是阿里家的mPaaS方案，mobile.12306.cn/otsmobile/app/mgs/mgw.html