数据下载控制方法及系统与流程

本发明涉及数据下载领域，具体而言，涉及数据下载控制方法及系统。
背景技术：
：随着通信技术的迅猛发展，智能设备已经深深的融入到了人们的日常生活中，常见的智能设备如手机、平板电脑、台式电脑等等。人们可以使用智能设备进行各种活动，比如浏览网页、在线观看视频等等，其中最常用的一种操作便是下载操作，大部分的用户行为也均与下载操作有关。从用户主观行为的角度进行分类，下载行为可以分为善意下载行为和恶意下载行为，对于善意的下载行为，下载服务器通常是支持的，但对于恶意的下载行为，则通常需要加以管制。在进行管制前首先需要对下载行为进行检测，以判断下载行为是否是恶意下载行为，在传统方案中，一般会对用户的下载次数进行监控，如果下载次数过多则会被认为是恶意下载行为，进而对其进行管控，但此种监控方式并不能很好的适用在任一种下载环境中。技术实现要素：本发明的目的在于提供数据下载控制方法，以提高针对碎片型数据进行下载的控制的准确程度。第一方面，本发明实施例提供了数据下载控制方法，包括：获取关于客户端的至少两个第一下载情况；每个第一下载情况分别用于描述客户端在不同的碎片云中下载碎片数据的情况；存储在不同碎片云中的碎片数据用于相配合的组合成完整数据；计算至少两个第一下载情况之间的匹配程度；根据匹配程度进行下载控制。结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，第一下载情况包括以下的一种或多种下载情况说明数据：下载的碎片数据的标识、指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量、下载碎片数据的时间长度、下载碎片数据所在的时间段、在同一个碎片云中读取碎片数据的次序、在同一个碎片云中读取碎片数据的位置、用户标识。结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，步骤计算至少两个第一下载情况之间的匹配程度包括：获取匹配列表，匹配列表中记载了预设的至少两个第一下载情况；根据实际关联关系和预设关联关系的相似程度确定匹配程度；实际关联关系是根据获取的至少两个第一下载情况确定的，预设关联关系是根据预设的至少两个第一下载情况确定的。结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，其中，在步骤获取关于客户端的至少两个第一下载情况前还包括：获取关于客户端的至少一个第二下载情况；每个第二下载情况用于描述客户端在指定的碎片云中下载碎片数据的情况；根据第二下载情况满足预设条件的情况，确定是否执行步骤获取关于客户端的至少两个第一下载情况。结合第一方面，本发明实施例提供了第一方面的第四种可能的实施方式，其中，步骤根据第二下载情况满足预设条件的情况，确定是否执行步骤获取关于客户端的至少两个第一下载情况包括：若第二下载情况满足预设的第一条件，则执行步骤获取关于客户端的至少两个第一下载情况；若第二下载情况满足预设的第二条件，则对客户端的下载行为进行控制；若第二下载情况满足预设的第三条件，则终止当前流程。结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，其中，还包括执行如下一个或多个判断步骤，并根据指定的判断步骤的判断结果确定第二下载情况满足预设的第一条件、第二条件或第三条件：判断客户端在指定的碎片云中的下载数量是否大于历史下载量阈值；判断客户端在指定的碎片云中的下载数量是否大于标准下载量阈值；判断客户端在指定的碎片云中进行下载操作时所在的时间段是否不与历史下时间段重合；判断客户端在指定的碎片云中进行下载操作时所在的时间段是否不与标准下时间段重合；判断客户端在指定的碎片云中进行下载操作时所使用的网络地址的数量是否超过标准值；判断在目标网络地址的上登陆过的客户端的数量是否超过预设的标准值，目标网络地址是客户端在指定的碎片云中进行下载操作时所使用的网络地址。结合第一方面，本发明实施例提供了第一方面的第六种可能的实施方式，其中，步骤根据匹配程度进行下载控制包括：若匹配程度满足预设的第一条件，则在预定时间内拒绝客户端的下载请求；若匹配程度满足预设的第二条件，则对客户端设置可执行下载操作的时间段，并将可执行下载操作的时间段向客户端发送；若匹配程度满足预设的第三条件，则调取客户端的历史下载数据，并依据历史下载数据对客户端进行控制。结合第一方面，本发明实施例提供了第一方面的第七种可能的实施方式，其中，存储在不同的碎片云中的碎片数据的数量/大小是不相同的。结合第一方面，本发明实施例提供了第一方面的第八种可能的实施方式，其中，还包括：获取安全用户端所发出的匹配信息修改请求；匹配信息修改请求中携带有选择代码；在候选列表中选择与选择代码相对应的下载情况作为匹配列表中预设的第一下载情况；在本地和安全用户端中均存储有内容相同的候选列表，且在候选列表中记载有多个不同的下载情况信息。第二方面，本发明实施例还提供了数据下载控制系统，包括：监控服务器、至少两个碎片云和客户端；每个碎片云均分别与监控服务器和客户端通讯连接；监控服务器用于执行如第一方面的方法；客户端用于向碎片云发起下载碎片数据的请求；碎片云用于向客户端发出存储在本地的碎片数据，以及向监控服务器传输下载情况。本发明实施例提供的数据下载控制方法，采用关联监控的方式，与现有技术中的只是针对单一的下载情况进行监控，导致监控的并不彻底、并不客观相比，其先获取关于客户端的至少两个第一下载情况；每个第一下载情况分别用于描述客户端在不同的碎片云中下载碎片数据的情况；存储在不同碎片云中的碎片数据用于相配合的组合成完整数据；而后，计算至少两个第一下载情况之间的匹配程度；最后根据匹配程度进行下载控制。由于碎片数据是关联的存储在不同的碎片云中的，并且，单独的碎片数据是无法起到作用的，因此，客户端通常需要关联性的在不同的碎片云上进行下载，因此，如果客户端没有关联的进行下载，则说明其可能是恶意下载，进而可以对其下载行为进行控制。为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。附图说明为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。图1示出了本发明实施例所提供的数据下载控制方法的基本流程图；图2示出了本发明实施例所提供的数据下载控制方法的第一个细节流程图；图3示出了本发明实施例所提供的数据下载控制方法的第二个细节流程图；图4示出了本发明实施例所提供的数据下载控制系统的网络架构图。具体实施方式下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。相关技术中，已经出现了各种针对用户的下载行为进行检测和进行控制的方法，但这种控制方法通常较为单一，仅仅是依据用户的单一下载行为进行的监控，比如查看用户的下载量/次数是否过大，如果过大，则对该用户的下载行为进行管控，进而避免过多的恶意下载行为。但是这种下载检测、控制的方式过于单一，黑客容易进行规避，并且，对于分布式的碎片数据存储而言并不很适用。进而，本申请提供了一种针对分布式碎片数据存储技术的数据下载控制方法，如图1所示，该方法包括：s101，获取关于客户端的至少两个第一下载情况；每个第一下载情况分别用于描述客户端在不同的碎片云中下载碎片数据的情况；存储在不同碎片云中的碎片数据用于相配合的组合成完整数据；s102，计算至少两个第一下载情况之间的匹配程度；s103，根据匹配程度进行下载控制。需要说明的是，本申请所提供的技术方案主要是针对碎片数据的分布式云存储系统而设计的。其中，碎片数据指的是将一个完整数据拆分后得到的多个碎片式的数据，且，单独的碎片数据是无法表达特定含义，或者说无法表达完整数据真实含义的。具体而言，此处的碎片数据指的是将完整数据(如一篇文章、一句话、一个单词)拆分得到的完整数据的部分数据，并且碎片数据是无法反应出完整数据的含义的(任意两个碎片数据之间均是不相同的)。例如原字段(完整数据)为数字55，可以将55拆分为50和60两个字段(不能拆分为55和0)，那么50和60均无法反应原字段55的含义，这样便起到了将数据表中的字段的真实含义，同时通过50/2+60/2，便可以计算出55，这样以拆分的方式进行隐藏的功能；又如，可以将55拆分为5和11(不能拆分为55和1)，5*11＝55，也就还原出了原始的55。又如，在某种场景下，汉字“我”的代码是8116，进而可以将8116拆分为1247和1881，进而，在用户取得了1247和1881这两个代码后，可以通过1247*3+1881*1来还原成8116，由于1881和1247本身还对应有其他的汉字，因此，在不知晓该代码已经被拆分过，且不知晓还原公式(x*3+y*1)的前提下，用户是无法知晓完整数据的真正含义的。此种碎片数据的使用目的在于：使得单独或多个的碎片数据无法表示原有共享数据的含义。实际上，碎片数据也可以理解为一种可还原的加密手段，但将碎片数据还原的前提是获取到全部的碎片数据(如拆分完整数据得到的碎片数据共有5个，则将碎片数据还原的一个前提便是获取到这5个碎片数据)，以及得到还原公式，或者对应的拆分公式(一般情况下，拆分公式和还原公式是完全对应的)。正是由于在进行碎片数据存储的时候，是将完整数据拆分成了多个碎片数据，并且，这多个碎片数据是分别存储在不同的碎片云中的，使得第三方无法轻易得到每个碎片数据，即使其得到了每个碎片数据，由于第三方并不知晓数据合成规则，导致其也无法还原得到完整数据。进而，如果正常用户想要取得完整数据(碎片数据无法表达实际含义，只有得到完整数据才能够表达实际含义，也就是只有取得完整数据才有意义)，就必然需要得到全部的碎片数据，因此正常用户进行下载的话，必然是多个碎片云中都会下载碎片数据，而不是只在一个碎片云中下载数据，进而可以依据用户是否在两个或多个碎片云进行关联性的下载(如下载的数据是相关联的，即都是从一个完整数据中拆分得到的不同部分，又如下载时间是相近的，又如下载使用的ip地址是相同的等等)来判断用户的下载行为是否是合理的下载行为。进而，在执行步骤s101之前，碎片云中会预先存储碎片数据，且存储在不同碎片云中的碎片数据是可以用来组成呈一个或多个完整数据的。下面以碎片云(碎片云a和碎片云b)有两个为例进行说明。如预先可以在碎片云a中存储碎片数据1-10，在碎片云b中存储碎片数据11-20；其中，碎片数据1-3与碎片数据11-14是用来组合成语句x的，碎片数据4-6与碎片数据14-17是用来组合成语句y的；碎片数据7-10与碎片数据18-20是用来组合成语句z的。也就是说，碎片云a中的碎片数据可以分成三组，第一组是碎片数据1-3，用来组成语句x，第二组是碎片数据4-6，用来组成语句y，第三组是碎片数据7-10，用来组成语句z。用户在进行下载的时候，如果是想合成语句z，则需要从碎片云a中下载碎片数据7-10，并在碎片云b中下载碎片数据18-20。类似的，如果共有3个碎片云，则可以将拆分完整数据得到的多个碎片数据存储在这三个碎片云上，如拆分得到10个碎片数据，则可以是1-4个碎片数据存在第一个碎片云上，5-8个碎片数据存在第二个碎片云上，9-10个碎片数据存在第三个碎片云上。需要说明的是，本申请所提供的方法在执行的时候，至少会涉及两端，分别是碎片云和客户端，其中，客户端是直接与碎片云进行交互的(客户端分别与每个碎片云通讯连接)，进而下载碎片云中存储的碎片数据。执行步骤s101之前，首先需要生成第一下载情况，第一下载情况通常是由碎片云将碎片数据下传给客户端的同时，直接生成的。一般来说，执行步骤s101-s103的主体(当然也是执行其他步骤的主体)可以是碎片云(由于实现本方案所涉及的碎片云至少有两个，因此，通常可以将执行步骤s101-s103的主体确定为至少两个碎片云中的一个，此时，执行步骤s101-s103的碎片云应当分别与其他所有碎片云通讯连接)；类似的执行步骤s101-s103的主体(当然也是执行其他步骤的主体)也可以是独立的第三方服务器等具有计算功能的网络端，此时，该计算功能的网络端分别与每个碎片云通讯连接。需要说明的是，存储在多个碎片云上的碎片数据有两种情况，第一种情况，只使用存储在碎片云上的多个碎片数据就可以组合成完整数据，此种情况下，如果拆分完整数据得到的碎片数据共有10个，则可以将这10个碎片数据均存储在碎片云上。即，拆分完整数据所得到的碎片数据均存储在碎片云上。第二种情况，只使用存储在碎片云上的多个碎片数据是无法组合成完整数据，此种情况下，如果拆分完整数据得到的碎片数据共有10个，则可以将这10个碎片数据中的8个存储在碎片云上，另两个存储在客户端/安全用户端(用户所使用的安全性较高的客户端)中。即，拆分完整数据所得到的多个碎片数据中，一部分存储在碎片云中，另一部分存储在客户端/安全用户端中。步骤s101中，关于客户端的第一下载情况指的是，客户端在某碎片云中下载碎片数据的情况，当然，一个第一下载情况描述的是客户端在一个碎片云中下载碎片数据的情况。其中，第一下载情况中具体可以有一种或多种下载情况说明数据。下载情况说明数据如：下载的碎片数据的标识(区分不同碎片数据的符号)、指定次数内下载碎片数据的数量(可以指个数，也可以是总大小)、指定时间内下载碎片数据的数量(可以指个数，也可以是总大小)、下载碎片数据的时间长度(开始下载第一个碎片数据至下载完最后一个碎片数据之间所经历的时间长度，也可以是开始访问碎片云至下载完最后一个碎片数据/停止访问碎片云之间所经历的时间长度)、下载碎片数据所在的时间段(如在10点-11点之间、15点30分-16点之间进行的下载)、在同一个碎片云中读取碎片数据的次序(如同一个碎片云中存储有拆分完整数据得到的4个碎片数据，即碎片数据a-d，此时读取碎片数据的次序指的就是读取这四个碎片数据的先后顺序，如顺序可以是acdb，也可以是cbda)、在同一个碎片云中读取碎片数据的位置(如同一个碎片云中有不同的存储区，客户端读取的是a存储区中的碎片数据，还是b存储区中的碎片数据)、用户标识(即区分不同用户/客户端的标识)。其中，读取的意思有两种，一种是下载前，将数据提取出来的过程，另一种指的是提取+下载的整个过程。为了确定合理的匹配程度，应当有一个标准的第一下载情况，也就是记载了碎片云a中的哪些碎片数据对应着碎片云b中的哪些碎片数据，进而，使得计算匹配程度的时候有更为准确的依据。进而，如图2所示，步骤s102，计算至少两个第一下载情况之间的匹配程度包括：s1021，获取匹配列表，匹配列表中记载了预设的至少两个第一下载情况；s1022，根据实际关联关系和预设关联关系的相似程度确定匹配程度；实际关联关系是根据获取的至少两个第一下载情况确定的，预设关联关系是根据预设的至少两个第一下载情况确定的。也就是匹配列表中记载了预设的第一下载情况，并且，匹配列表中记载的预设的第一下载情况应当是与用户约定好的，或者是在确定好之后告知用户的。优选的，该匹配列表中的信息(预设的至少两个第一下载情况)是在独立的可信第三方机构随机生成的，并且，在将碎片数据进行存储的时候，应当根据该匹配列表中的信息来进行存储(如碎片数据1-4存储在碎片云a中，碎片数据5-9存储在碎片云b中…)。如前文中的说明，用户应当关联性的下载碎片数据，才能够使用这些碎片数据组合得到完整数据，因此，理论上，客户端下载碎片数据的情况应当是相匹配的。即，在确定了至少两个第一下载情况后，应当执行步骤s102中，可以确定出至少两个第一下载情况之间的匹配程度。具体而言，匹配程度有三种具体情况，下面仅以第一下载情况中包含有下载的碎片数据的标识。第一种情况，如将完整数据拆分后得到了6个碎片数据，碎片数据1-3(碎片数据的标识)存储在碎片云a上，碎片数据4-6(碎片数据的标识)存储在碎片云b上，那么客户端下载的时候应当是即下载碎片数据1-3，也下载碎片数据4-6。进而如果一个第一下载情况中包含有碎片数据1-3的代码，另一个第一下载情况中包含有碎片数据4-6的代码，并且这两个第一下载情况中均有且只有碎片数据的代码的话，则说明这两个第一下载情况之间的匹配程度是100％。此时，则说明客户端的下载碎片数据的行为是正常的，进而步骤s103中，则应当对该客户端的下载行为进行放行。第二种情况，相对应的，如将完整数据拆分后得到了6个碎片数据，碎片数据1-3存储在碎片云a上，碎片数据4-6存储在碎片云b上，那么客户端下载的时候应当是即下载碎片数据1-3，也下载碎片数据4-6。进而如果一个第一下载情况中包含有碎片数据1-3的代码，另一个第一下载情况中包含有碎片数据7的代码，并且这两个第一下载情况中均有且只有碎片数据的代码的话，则说明这两个第一下载情况之间的匹配程度是0％。此时，则说明客户端的下载碎片数据的行为是异常的，进而步骤s103中，则应当对该客户端的下载行为进行管控(如拒绝该客户端的下载行为，或者将该客户端列入黑名单，或者是调取该客户端之前的下载历史并进行更进一步的判断)。第三种情况，如将完整数据拆分后得到了6个碎片数据，碎片数据1-3存储在碎片云a上，碎片数据4-6存储在碎片云b上，那么客户端下载的时候应当是即下载碎片数据1-3，也下载碎片数据4-6。进而如果一个第一下载情况中包含有碎片数据1-3的代码，另一个第一下载情况中包含有碎片数据5和6的代码，并且这两个第一下载情况中均有且只有碎片数据的代码的话，则说明这两个第一下载情况之间的匹配程度是67％。此时，则说明客户端的下载碎片数据的行为是近似异常的(由于客户端可能出现了网络故障、数据处理故障，导致某些下载没有进行，即是由于系统处理故障而导致的下载异常，而不是人为主观上不期望下载，因此，应当有一定的容错率，而不是将所有匹配率不是100％的都人为是异常)，进而步骤s103中，则应当对该客户端的下载行为进行进一步的确认。如调取该客户端之前的下载历史，来了解其之前是否有过下载异常或者近似异常的情况，如果经常下载异常，则可以将本次下载行为也视作异常，反之则可以放行，当然，网络维护人员可以依据具体情况来进行调整(如匹配程度超过60％则可以认为是正常行为，匹配程度40-60％认为是近似异常，小于40％则是异常行为)。上述三种情况介绍了第一下载情况中携带了下载的碎片数据的标识时，计算匹配程度的方式，与该种方式相类似的，还可以依据一种或多种下载情况说明数据来计算匹配程度。如在碎片云上按照等量的方式均匀的存储碎片数据，那么匹配程度的数值就也可以按根据a与b的比值得出(理论上a与b应当相等，因此，二者相差越多，则匹配程度越低)，其中a是客户端在第一个碎片云上下载碎片数据的数量，b是客户端在第二个碎片云上下载碎片数据的数量。当然，如果不同碎片云上存储的碎片数据的数量是按照一定比值、或其他函数关系对应的，那么a与b的关系也应当对应的满足比值或者其他的函数关系，越偏离该比值或函数关系的话，则匹配程度越低。又如，客户端在指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量、下载碎片数据的时间长度均可以按照这种方式来计算匹配程度。如果下载情况说明数据是下载碎片数据所在的时间段则通常需要本地与客户端预先约定好规则，比如，在第一个碎片云上下载碎片数据的时间段应当与在第二个碎片云上下载碎片数据的时间段相距x小时，在在第二个碎片云上下载碎片数据的时间段应当与在第三个碎片云上下载碎片数据的时间段相距x+1小时等等。如果偏离了这个规则，则偏离越大，匹配程度越差。类似的，在同一个碎片云中读取碎片数据的次序，也是需要采取预先约定的方式进行。比如可以预先约定客户端应当在第一个碎片云中按照由前至后的顺序来读取，在第二个碎片云中按照由后至前的顺序来读取，如果偏离该读取方式，则匹配程度降低。在同一个碎片云中读取碎片数据的位置，则是指在碎片云中也存在不同的分区，每个分区中均存储有相同的数据，可以本地与客户端预先约定，如果在第x个碎片云中的第n个分区取碎片数据的话，则应当在第y个碎片云中的对应的w个分区取碎片数据，其中x和y为数值不等的自然数；n与w均为自然数，且呈预定的函数关系。即，如果在至少两个第一下载情况中的在碎片云中读取碎片数据的位置没有按照上述规则来取，则应当相应的降低匹配程度。用户标识主要是区分是否是同一个客户端/终端设备所进行的下载行为，其目的确定同一个客户端是否在不同的终端设备上进行了下载行为，如客户端在终端a上从碎片云a上下载了碎片数据x，客户端在终端a上从碎片云b上下载了碎片数据y，这样的话，就说明客户端可能存在恶意下载，此时如果a与b的距离相距越远(也可以采用其他的规则)，则匹配程度越低。需要说明的是，上述内容列举出了单独使用一个下载情况说明数据来计算匹配程度的方式，还可以是依据上述下载情况说明数据中的至少两个来计算匹配程度，具体而言，可以先按照上述说明的方式分别依据各个下载情况说明数据来计算出多个子匹配值(即按照上述方式单独依据下载的碎片数据的标识计算出关于的匹配程度、按照上述方式单独依据指定次数内下载碎片数据的数量计算出关于的匹配程度等等)，而后，再按照加权计算的方式，依据得到的多个子匹配值来计算匹配程度，如可以按照如下公式计算匹配程度，f＝ax+by+cz，其中f是步骤s102中的匹配程度，abc均为权值，xyz分别为依据不同的下载情况说明数据计算得到的子匹配值。计算的方式/公式可以是由网络维护人员进行定义，此处不再做过多的限定。但需要说明的是，如果使用了下载的碎片数据的标识这一说明数据的话，一般是不需要出现指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量这两个数据的，因为出现了代码，通常就可以表征下载碎片数据的数量了，但某些情况下，同一个代码可能会代表多个碎片数据，此时，则还可以是指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量和下载的碎片数据的标识同时出现在第一下载情况中。当然，二者同时出现也可以起到校验的作用。实际上，匹配程度可以按照最为简单的方式来进行确定，即，下载的碎片数据的标识、指定次数内下载碎片数据的数量、指定时间内下载碎片数据的数量、下载碎片数据的时间长度、下载碎片数据所在的时间段、在同一个碎片云中读取碎片数据的次序、在同一个碎片云中读取碎片数据的位置、用户标识这些下载情况说明数据可以是用户与云端预先约定好的，比如，在不同的碎片云中下载碎片数据的时间长度，或时间段应当是基本相同的，并且可以依据具体的差距来调整匹配程度。又如，客户端在不同的碎片云中应当按照既定的次序来读取(读取可以理解为下载、或者是浏览)碎片数据如在第一个碎片云中按照由前至后的顺序读取，则在另一个碎片云中应当按照由后之前的顺序读取。上述内容介绍了依据碎片数据的特性(碎片数据只有全部取出后才能够组合成完整数据，因此，正常用户通常会将位于多个碎片云中的关于同一个完整数据的碎片数据按照既定的规则全部取出，来使其能够组合成完整数据，如果是黑客的话，则不会按照这既定的规则全部取出来)来对多个碎片云进行匹配监控方法。但发明人发现，如果每一次均按照此种方式进行判断的话，则对数据安全不利(主要是每次均需要得到至少两个第一下载情况，因此，需要对至少两个碎片云进行下载情况的监控，监控后还需要通过网络传输这些监控得到的信息，这期间容易泄露数据)，也增加系统负担。因此，发明人认为，可以采取先单独监控一个碎片云的情况，如果出现异常再进行匹配监控的方式。具体的，本申请所提供的方法中，如图3所示，在步骤获取关于客户端的至少两个第一下载情况前还包括：s301，获取关于客户端的至少一个第二下载情况；每个第二下载情况用于描述客户端在指定的碎片云中下载碎片数据的情况；s302，根据第二下载情况满足预设条件的情况，确定是否执行步骤获取关于客户端的至少两个第一下载情况。需要说明的是，第二下载情况和第一下载情况的内容可以是相同/相似的，但二者后续的作用却完全不同，第二下载情况的作用是判断客户端对某一个碎片云中的碎片数据的下载行为是否异常(依据一个第二下载情况进行独立判断)，第一下载情况的作用是判断客户端对某多个碎片云中的碎片数据的下载行为是否异常(依据至少两个第一下载情况进行组合、匹配式的判断)。步骤s302中，需要依据第二下载情况的具体情况来确定是否执行步骤s101，也就是依据第二下载情况来执行相应操作的话，是有多种可能性的结果的，具体而言，有如下三种结果：若第二下载情况满足预设的第一条件，则执行步骤获取关于客户端的至少两个第一下载情况；若第二下载情况满足预设的第二条件，则对客户端的下载行为进行控制；若第二下载情况满足预设的第三条件，则终止当前流程。其中，第一条件、第二条件和第三条件的具体标准应当是没有交集的，即第二下载情况不应当同时满足这三个条件中的任意两个，当然，更不可能是同时满足这三个条件。实际操作中，第一条件、第二条件和第三条件的具体内容可以是网络维护人员依据具体的情况、场景来确定的。比如，第一条件、第二条件和第三条件可以是下载行为所持续的时间长度，如第一条件是2-3小时，第二条件是超过3小时，第三条件是小于两小时，进而，当符合第一条件的时候，说明下载行为是近似恶意的，执行步骤s101-s103；当符合第一条件的时候，则说明下载行为是恶意的，此时应当对该下载行为进行及时的管控(如终止本次下载行为、将客户端列在黑名单中、在一定时间内拒绝客户端的所有下载请求等等)；当符合第一条件的时候，则说明下载行为是正常的，此时，应当终止监控的流程，等下一次客户端再进行新的下载行为时再进行监控。下面列举出了几种具体的判断条件，即本申请所提供的方案中，还包括执行如下一个或多个判断步骤，并根据判断步骤的判断结果确定第二下载情况满足预设的第一条件、第二条件或第三条件：判断客户端在指定的碎片云中的下载数量是否大于历史下载量阈值；判断客户端在指定的碎片云中的下载数量是否大于标准下载量阈值；判断客户端在指定的碎片云中进行下载操作时所在的时间段是否不与历史下时间段重合；判断客户端在指定的碎片云中进行下载操作时所在的时间段是否不与标准下时间段重合；判断客户端在指定的碎片云中进行下载操作时所使用的网络地址的数量是否超过标准值；判断在目标网络地址的上登陆过的客户端的数量是否超过预设的标准值，目标网络地址是客户端在指定的碎片云中进行下载操作时所使用的网络地址。需要说明的是，判断客户端在指定的碎片云中进行下载操作时所使用的网络地址的数量是否超过标准值指的是，客户端是否经常在不同的网络地址上进行下载，如果客户端经常在不同的网络地址上进行下载，这说明客户端登录可能存在异常。判断在目标网络地址的上登陆过的客户端的数量是否超过预设的标准值，目标网络地址是客户端在指定的碎片云中进行下载操作时所使用的网络地址，指的是在指定的网络地址上，是否有很多不同的客户端登录过，如果是的话，则说明使用者是通过更换下载客户端的方式来恶意的从碎片云中下载碎片数据。并且，根据判断步骤的判断结果确定第二下载情况满足预设的第一条件、第二条件或第三条件的具体确定规则可以是本地与用户预先约定好的。相对应的，当符合不同条件的时候，还应当进行相应的操作，下面列举三个优选的操作。即，步骤根据匹配程度进行下载控制包括：若匹配程度满足预设的第一条件，则在预定时间内拒绝客户端的下载请求；若匹配程度满足预设的第二条件，则对客户端设置可执行下载操作的时间段，并将可执行下载操作的时间段向客户端发送；若匹配程度满足预设的第三条件，则调取客户端的历史下载数据，并依据历史下载数据对客户端进行控制。其中，设置可执行下载操作的时间段，作用是约束客户端的下载时间使得该用户端更容易被监管，也是将该客户端下载的时间放在网络压力较小的时间段(一种惩罚方式)。依据历史下载数据对客户端进行控制指的是查看客户端历史下载数据后，查看客户端曾经是否有过不良记录，如果有过，则可以对其进行管控，如果没有过，则可以采取惩罚方式教轻的策略进行管控。整体来看，依据历史下载数据对客户端进行控制，主要体现的是相对控制的思想，即单纯依据当前的条件(第二下载情况)不好确定客户端是善意的还是恶意的，因此，需要调取历史数据进行辅助判断。优选的，存储在不同的碎片云中的碎片数据的数量/大小是不相同的。这也能够避免恶意客户端在下载的时候，平均的在每个碎片云上都下载一些，进而规避管控。为了保证匹配列表中的第一下载情况是相对安全的(不会被黑客窃取走)，用户与本地确定匹配列表中的第一下载情况的内容时，不应当将具体内容直接写在修改请求中。而是，本地与用户预先约定好可选方案，然后每次修改的时候，用户只需要将可选方案的代码发送出来，进而避免了直接发送具体内容，避免黑客截取到具体内容。进而，本申请所提供的技术方案还包括：获取安全用户端所发出的匹配信息修改请求；匹配信息修改请求中携带有选择代码；在候选列表中选择与选择代码相对应的下载情况作为匹配列表中预设的第一下载情况；在本地和安全用户端中均存储有内容相同的候选列表，且在候选列表中记载有多个不同的下载情况信息。其中，安全用户端可以是客户端(如果客户端的安全级别足够高)，也可以是独立于客户端的第三方机构。候选列表可以是本地与安全用户端协商形成的，也可以是本地形成后告知安全用户端，还可以是安全用户端形成之后发送给本地进行存储的。具体的，候选列表的形式可以是如下表1所示，表1选择代码下载情况信息的内容1001aaaaaa1002bbbbbb1003cccccc1004dddddd进而，在本地接收到安全用户端所发出的匹配信息修改请求后，直接根据匹配信息修改请求中的选择代码来查找相应的下载情况信息，并将查找到的下载情况信息作为匹配列表中预设的第一下载情况。这种确定预设的第一下载情况的方式，在本地与安全用户端之间没有进行实际内容的交互(即没有在匹配信息修改请求中携带下载情况信息的内容)，而是携带了代码，这样即使有第三方窃取到该匹配信息修改请求也不会知晓验证的规则，保证了安全性。与上述方法相对应的，本申请还提供了数据下载控制系统，如图4所示，包括：监控服务器、至少两个碎片云和客户端；每个碎片云均分别与监控服务器和客户端通讯连接；监控服务器用于执行如上述的方法；客户端用于向碎片云发起下载碎片数据的请求；碎片云用于向客户端发出存储在本地的碎片数据，以及向监控服务器传输下载情况。功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本
技术领域：
的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。当前第1页12