行对时，发送心跳包数据的频率较高，发送的总数据量较多，从而使得对时成本较高。因此，通过本实施例提供的对时操作，能够有效减少对时成本。
[0141]需要说明的是，上述发送请求时间及接收请求时间的形式可以为时间戳形式，本实施例不对上述时间的形式作具体限定。
[0142]304、终端向服务器发送业务请求。
[0143]本实施例不对终端向服务器发送业务请求的方式作具体限定，包括但不限于:通过网络以数据包的方式向服务器发送业务请求。
[0144]305、当服务器接收到终端发送的业务请求时，服务器至少根据发送请求时间、接收请求时间及行程时间，判断业务请求是否为无效业务请求，如果业务请求不为无效业务请求，则执行步骤306，如果业务请求为无效业务请求，则删除该业务请求。
[0145]由于终端侧可能会更改本地时间，因此，服务器在判断业务请求是否为无效业务请求之前，可计算发送请求时间与接收请求时间之间的第二差值。若第二差值与行程时间之间的差值不在预设数值范围之内，可向终端发送时钟更改标识，终端在接收到时钟更改标识后，可根据时钟更改标识，重新确定本地时间。
[0146]在终端侧未更改本地时间的情况下，考虑到网络延迟等因素，终端发送请求至服务器花费的时间应该与行程时间是大致相同的，即发送请求时间与接收请求时间之间的第二差值与行程时间应该是大致相同的。因此，第二差值与行程时间之间的差值应该在预设数值范围之内。当第二差值与行程时间之间的差值不在预设数值范围之内，则说明终端侧很可能更改了本地时间。
[0147]例如，以发送请求时间为14年12月16日19:03:00，接收请求时间为14年12月16日19:03:40，行程时间为I分钟，预设数值为30S为例。此时，发送请求时间与接收请求时间之间的第二差值为40秒，小于行程时间I分钟。其中，预设数值范围为(_30，30)，第二差值与行程时间之间的差值为-30S，在预设数值范围-30S至30S之间。因此，可确定终端未更改本地时间。当接收请求时间为14年12月16日19:04:40时，发送请求时间与接收请求时间之间的第二差值为100秒，大于行程时间I分钟。其中，第二差值与行程时间之间的差值为40S，不在预设数值范围-30S至30S之间。因此，可确定终端更改了本地时间。此时，服务器可向终端发送时钟更改标识，终端在接收到时钟更改标识后，可根据时钟更改标识，重新确定本地时间。
[0148]终端在重新确定本地时间，可按照上述步骤303中的内容，重新确定行程时间，即上述步骤303中的重新对时操作，本实施例对此不作具体限定。需要说明的是，由于终端之前更改了本地时间，发送的业务请求中的发送请求时间会发生错误，且行程时间不为最新的行程时间，从而可能会影响服务器后续对业务请求的处理。因此，根据实际情况终端可确定是否重新向服务器发送该业务请求，本实施例对此不作具体限定。
[0149]通过上述对时操作，能够保证终端的本地时间为正确的时间，从而避免了因终端本地时间出错，使得发送的业务请求中发送请求时间出错，进而导致后续判断业务请求是否为无效业务请求时的误判，提高了业务请求处理的准确率。
[0150]本实施例不对服务器至少根据发送请求时间、接收请求时间及行程时间，判断业务请求是否为无效业务请求的方式作具体限定，包括但不限于:将发送请求时间及行程时间相加，得到和值；将接收请求时间与和值相减，得到第一差值；判断第一差值是否大于预设阈值；若第一差值大于预设阈值，则确定业务请求为无效业务请求。
[0151]例如，以预设阈值为40秒，发送请求时间为14年12月16日19:03:00，接收请求时间为14年12月16日19:04:50，行程时间为I分钟为例。将发送请求时间及行程时间相加，得到和值为14年12月16日19:04:00。将接收请求时间与和值相减，得到第一差值为50秒。由于第一差值50秒大于预设阈值40秒，因此，可确定业务请求为无效业务请求。
[0152]需要说明的是，由于终端在向服务器发送业务请求时，可能会出现超时的情形，即终端发送的业务请求到服务器的时间超过了服务器预设的时间。此时，说明传输网络可能存在问题，终端发送的业务请求可能会存在安全隐患。鉴于上述原理，可通过上述判断第一差值是否大于预设阈值的过程，判断业务请求是否为无效业务请求，从而保证业务处理的安全性。
[0153]另外，由于终端可能会由于网络刷新等原因，导致在一段时间内向服务器发送重复的业务请求，使得服务器拥塞，进而导致服务器因处理大量的重复业务请求，造成资源的浪费。为了避免上述过程，在上述过程中判断第一差值是否大于预设阈值之后，若第一差值不大于预设阈值，则判断缓存中是否存储有校验数据，若缓存中存储有校验数据，则确定业务请求为无效业务请求。
[0154]例如，以缓存中存储有校验数据CD_1、CD_2及CD_3为例，若业务请求中的校验数据为CD_1，则可确定缓存中存储有该校验数据CD_1，从而可确定该业务请求为无效业务请求，进而可将该业务请求删除，不对该业务请求做任何处理。若业务请求中的校验数据为CD_4，则可确定缓存中未存储有该校验数据CD_4，从而可确定该业务请求不为无效业务请求，并对该业务请求做进一步地处理。
[0155]需要说明的是，在缓存中存储校验数据时，还可以同时存储业务请求的终端应用标识，本实施例对此不作具体限定。通过该过程，能够在非登录的情况下，准确地区分每一个终端的业务请求量，从而在对不区分用户的公共数据进行处理时，能够起到防刷新的作用。
[0156]由于服务器接收业务请求后，通常会将每个业务请求的校验数据在缓存中存储一段时间，若在缓存存储该校验数据的这段时间内，又有包含同样校验数据的业务请求到来。此时，可确定终端在一段时间内发送了重复的业务请求。因此，可通过上述判断过程，将重复的业务请求确定为无效业务请求，进而不对该业务请求作任何处理。通过上述过程能够避免服务器处理业务请求的接口因重复业务请求而被多次调用，防止非法用户刷访问量，屏蔽大部分的无效访问请求，从而能够避免服务器因重复的业务请求造成的拥塞以及资源的浪费，保证服务器接口不受接口被重复调用的影响，使得外部多次调用服务器的接口对服务器系统的影响是一致的，即保证了服务器的幂等性。另外，还可以避免同一个业务请求因在有限时间内多次请求，而造成数据的不一致性及破坏性，从而能保证数据的一致性，并保证数据的安全性。
[0157]另外，关于服务器至少根据发送请求时间、接收请求时间及行程时间，判断业务请求是否为无效业务请求的方式，本实施例对此不作具体限定，包括但不限于:根据业务数据及校验数据，判断业务请求是否为无效业务请求。
[0158]由于校验数据是终端侧根据业务数据，按照预设算法计算得来的，为了判断业务数据在传输过程中是否被篡改，服务器侧可按照预设算法重新对业务数据进行计算，将计算结果与校验数据进行比较。根据比较结果，判断业务数据在传输过程中是否被篡改。其中，若业务数据在传输过程中被篡改，则确定业务请求为无效业务请求。
[0159]现结合上述步骤302中，终端侧生成校验数据的过程，对根据业务数据及校验数据，判断业务请求是否为无效业务请求的过程进行解释说明。本实施例不对根据业务数据及校验数据，判断业务请求是否为无效业务请求的方式作具体限定，包括但不限于:按照预设算法对业务数据进行计算，得到计算结果；选取计算结果中预设位数的数据，作为待校验数据；将待校验数据与校验数据进行比对；若待校验数据与校验数据不一致，则确定业务请求为无效业务请求。由于在上述步骤302中生成校验数据的过程中，可先将密钥添加至业务数据，再对添加密钥的业务数据进行计算。因此，在本步骤305中，同样可先将密钥添加至业务数据，再对添加密钥的业务数据进行计算，以保证终端侧与服务器侧的运算过程一致，本实施例对此不作具体限定。
[0160]需要说明的是，服务器对业务数据进行计算时采用的预设算法，需要与终端侧生成校验数据时采用的预设算法一致，如都可以采用MD5，本实施例不对预设算法的类型作具体限定。服务器侧在选取计算结果中预设位数的数据时，预设位数的所在位置及位数的值需要与终端侧对应的预设位数一致。
[0161]例如，以预设算法为MD5，预设位数为计算结果的前7位，校验数据为“7815696”为例。若按照预设算法对业务数据进行计算后，得到的计算结果为“7825696ECBF1C96E6894B779456D330E”。此时，从计算结果中选取前7位的数据，得到的待校验数据为“7825696”。由于待校验数据与校验数据不一致，则可确定业务请求为无效业务请求。
[0162]通过上述校验比对的过程，能够防止数据在传输过程中被篡改，从而保证了处理业务时数据来源的安全性。
[0163]需要说明的是，在本步骤305中，服务器在判断业务请求是否为无效业务请求时，包含至少两个判断过程。第一个为根据发送请求时间及行程时间，判断业务请求是否为无效业务请求的过程。第二个为根据业务数据及校验数据，判断业务请求是否为无效业务请求的过程。上述两个过程可以按照一定时序先后执行，如可以先执行第一个过程，或者也可以先执行第二个过程，本实施例对此不作具体限定。当经由两个判断过程后，若业务请求都不为无效业务请求，则可确定该业务请求不为无效业务请求，并继续执行后续的步骤。
[0164]306、若业务请求不为无效业务请求，服务器对业务请求进行处理。
[0165]本实施例不对服务器对业务请求进行处理的方式作具体限定，包括不但限于:根据业务请求中的业务数据，对相应的业务进行处理。例如，以业务为上网业务，业务数据为待访问的网址为例。服务器可根据待访问的网址，获取对应的网页资源，向终端返回获取到的网页资源。
[0166]本发明实施例提供的方法，通过服务器接收终端发送的业务请求，至少根据发送请求时间、接收请求时间及行程时间，判断业务请求是否为无效业务请求，若业务请求不为无效业务请求，则对业务请求进行处理。由于能够根据发送请求时间、接收请求时间及行程时间，对业务请求进行判断，从而能够对重复的业务请求进行筛选，避免因重复业务请求而造成的服务器拥塞以及处理结果出错。因此，对服务器的负担较轻，业务处理的效果较佳。另外，在计算业务请求中的校验数据时，通过添加密钥及选取预设位数数据的方式，从而使得业务数据更加隐密，安全性更高。在对时操作时，通过简单地将行程时间及接收请求时间与发送请求时间之间的差值进行比较，根据比较结果决定是否重新对时，从而节省了对时成本。通过对业务请求进行筛选，在保证服务器幂等性及数据一致性的同时，能够防止非法用户刷访问量，从而保证了服务器处理业务时的安全性。
[0167]本发明实施例提供了一种服务器，该服务器用于执行上述图1或图3对应的实施例提供的业务请求处理方法中服务器所执行的功能。参见图4，该服务器包括:
[0168]接收模块401，用于接收终端发送的业务请求，业务请求中至少包括业务数据、业务数据的校验数据、发送请求时间、行程时间及终端应用标识，行程时间为终端第一次发送业务请求与服务器第一次接收到业务请求的时间差；
[0169]判断模块402，用于至少根据发送请求时间、接收请求时间及行程时间，判断业务请求是否为无效业务请求；
[0170]处理模块403，用于当业务请求不为无效业务请求时，则对业务请求进行处理。
[0171]作为一种可选实施例，参见图5，判断模块402，包括:
[0172]第一计算单元4021，用于将发送请求时间及行程时间相加，得到和值；
[01