小米抢购页面源码分析2014年03月11号

这个是3月11号的源码分析，后来没有写18号的，因为18号抢到一个，而且自己还有脑残行为，虽然有重大发现，看25号的情况再说吧。。。

By:小宗

 3月11号又是抢小米的日子。。。。（今天出去了一下，回来没去实验室）

这次放聪明了一些，记得打开FireFox的网络分析，但是由于Firefox的缺陷（不能保存网络分析的信息或许是我没找到）和我的脑残重新预订的时候是要打开新页面的，所以网络分析的信息会重新刷新，额，所以说导致我虽然打开了网络分析，却只是稍微看了一下，没有深入的分析，就木有了。。。

仍旧是很枯燥，不喜欢的可以直接跳到结论

首先是我凭记忆写的网络请求分析。。。没有看到页面刷新（原本我觉得时间到了之后刷新页面的可能性比较大）。。。这样可以减轻服务器的压力吧
从抢购时间到了开始，首先发了一条“hdinfo”的请求（因为处理该请求的文件（夹）叫hdinfo），里面有两个参数，一个是callback=hdinfo，第二个叫_，仍然是两个时间戳，第一个是最后一次刷新页面的本地时间，第二个是抢购时间到了之后的时间戳（下面会讲，倒计时的时间是从服务器读取的），服务器返回的信息是这样的（事后从服务器读取的）

是一个函数调用，然后参数是JSON格式的数据，第一个变量stime存储的是时间戳，精确到秒（跟js的不一样）。login应该是是否登录什么的，后面hdstart和hdstop应该是抢购是否开始或是结束之类的，hdurl应该是与抢购网址有关的东西，其他的看变量名就不太好猜了。
然后请求了几张图片，这个没什么好说的，再后来就会发送一条叫做getmode的请求，参数只有一个就是_也是两个时间戳组成的字符串，第一个是最后一次刷新的本地时间，第二个就是发送这条请求的本地时间，返回值是一个叫mod的变量，今晚返回的值是9876，不知道什么作用（当然看源码肯定可以知道，只是我太懒）
然后又请求了些图片什么的，后来就是上次说到的那个hdget请求，经网络分析证实，第一个参数是phone代指产品类型为手机，然后是fk指验证码,_仍旧是那两个时间戳。对于这条请求服务器10-12秒后返回一个变量（我电脑的数据，可能是因为服务器压力比较大所以时间长），也是JSON格式的，具体内容不详。这条命令是多次发送的，最后返回了不知什么，然后就显示售罄。所以里面的数据应该是关于抢购结果的消息，没有抢到就重新发送，直到售罄。
所以在抢购的时候一共发送了三种请求，hdinfo、getmode和hdget，其中hdget是多次发送的，服务返回时间比较长。
分析一下我保存下来的源码。。。


这次的代码基本相似，只是多了一条百度统计的东西，这样看来上面的hm.js也是百度统计的代码。由于发售产品的差别其他的也有所改变。PS：firefox的美化代码原来也可以把16进制的数翻译成字符串，而且是每行一个哦，太爽了。

这次主要看了它的倒计时函数。。。


首先调用的函数是getStatus.init()这个函数是初始化倒计时的，Status应该是指，抢购前抢购时间到了的hdinfo请求中，抢购开始，和抢购结束等等。logoinInfo估计就是检测有没有登录的。后面加了几个事件，好像没有太大作用。
主要看getStatus.init()这个函数


这个主要还是用jsonInter发送了一个hdinfo的请求，然后确定了一下有没有获得服务器返回的时间。。。

使用上次寻找id的方法可以确定设置剩余时间的的是setTimeRemain，听名字就知道找对了。


首先是判断抢购时间有没有到，没有倒的话就会更改倒计时时间然后小于九分钟后，停用了一个计时器（还没看这个是干什么的），重新请求时间requestServertime()，这个依旧调用了那个innerJson函数，发送了resetServerTime请求，参数是callback=resetServerTime和两个时间戳组成的字符串。
当然，最重要的是时间到了之后的Timeup函数。


这个hdinfo还真的是在这里面发送的。。。恩

那我们看到的getmode请求怎么回事？

我发现，原来是我上次忽略了一个地方，就是在showBox函数里



原来getmode是在这里发送的。

最后，从源码来看一共只有这么4种类型的请求（抢到前）




内容就是上面说的，发送顺序是这样的

首先打开页面发送hdinfo，然后不知道什么条件下发送resetServerTime（这前面两个应该是对表用的），到了抢购的时候自动发送一条hdinfo（也是对表吧），然后发送一个getmode，不知道干什么，然后就是hdget，当然就是我说的那个喽。

下面总结一下

从上面的分析来看，服务器总共知道这么几条信息;

1、购买意向（预订的时候填的）

2、最后一次刷新页面的本地时间，和这个时候的服务器时间（服务器自己的时间它肯定知道喽）。

3、倒计时时，也会在某些条件下发送最后一次刷新页面的本地时间当前的本地时间和这个时候服务器的时间。

4、抢购开始的时本地时间和对应的服务器时间。

5、getmode的时间和对应的服务器时间

6、提交时的本地时间和服务器时间。（还有验证码和产品类型）

上面每一条时间都会发送最后一次刷新的本地时间。

在我看来2-4的作用是跟服务器对表用的，就是让服务器知道跟你电脑的差值，不知道5是干什么的，然后第6条是提交的本地时间然后就可以算出对应的服务器时间，也就知道你是什么时候提交的了。多次对表的原因可能就是考虑到网络延时，然后求平均吧。

一家之言仅供参考，更何况我还没分析，第三条的某些情况是什么。

我有这么一个想法，由于hdget请求是多次提交的，我想可以用Firefox网络分析的重新发送功能把第二个时间戳改到抢购后的500ms（是不是有点儿太小了或是800ms）。服务器不会认为我作弊给我封号吧。。。

又这么晚了，睡了，祝

Lucky！