PixelDust

I'm actually working on a new `Future` trait that uses TimelineSemaphore by default. Timeline semaphore does simplify the implementation of Futures significantly. I'll share the concept here once I think...

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

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

测试了一下，慢速排队问题仍然存在。看一下我的 https://tra.ink/ticket （仍然有很多bug），在后端用了这套api 。我相当于重新写了12306的前端代码，并在后端做了个代理，而且发送请求的速度和时间，跟12306无差。但是，仍然在某些情况，会出现慢速排队的情况，只不过没有春运时期那么显著。我推测该慢速排队机制，绝不是仅仅通过时间控制那么简单 

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

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

并没有。 弃坑了 哈哈

I implemented a working prototype for iOS. https://github.com/Neotoxin4365/TrainK-iOS https://www.youtube.com/watch?v=vfzuN8sozR0 I'm writing it in Swift purely because I wanted to submit this project to Apple for a WWDC scholarship. Now the...

That sounds like a reasonable approach to take here. I'll get this updated ASAP.

同样遇到了这样的问题。我在template中使用了{% static "css/bootstrap.min.css" %}，但是编码结果中，/被编码为 %2F，导致oss 404.