本发明涉及网络技术领域，特别是涉及一种url查询方法和url查询服务器。
背景技术：
统一资源定位符(uniformresourcelocator，url)是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的url，它包含的信息指出文件的位置以及浏览器应该怎么处理它。用户可以通过url访问互联网上的各种资源。
由于互联网上的资源爆炸式增长，各种类型的资源都充斥在网络上，对于大部分企业而言，员工使用企业内部的终端访问某些互联网上的资源一方面会影响正常的办公效率，另一方面也可能对企业的网络信息安全造成影响。
因此，目前采用url识别技术来限制企业内部终端所访问的url，使企业内部终端仅能访问与工作相关的互联网资源。url识别主要是依靠专业设备上的url识别模块来完成的，在url识别模块中预设url库，将终端访问的url与url库中的预设规则进行匹配，根据预定义的动作决定该访问是否可以放行。但互联网中的资源数量非常巨大，而且在不断地快速增长，对于本地设备上的url识别模块而言，受到性能的限制，以及url库的规模显示，已无法满足需求。因此，目前还为企业提供了云端识别url的能力，当本地设备的url识别模块遇见无法识别的url时，该设备将url发送至云端进行查询。云端存储有海量的url规则，能够满足对url的识别需求。
但云端在接收到url查询请求时，在海量的url规则中进行匹配查询耗时较长，当接收到海量的本地设备并发的url查询请求时，查询时间会更长。而本地设备只有接收到云端返回的url查询结果才能判断终端本次的url访问是否可以放行，当云端的查询速度较慢时，将影响用户访问url的速度，严重影响用户体验。
技术实现要素：
本发明实施例的目的在于提供一种url查询方法和url查询服务器，提高了对url查询的效率。
本实施例具体技术方案如下：
第一方面提供一种url查询方法，所述方法包括：
接收网络设备发送的url查询请求，所述url查询请求中包括待查询的第一url；
从所述第一url中提取域名；
从所述域名中提取前n个字符，查找与所述前n个字符对应的规则桶，所述n为大于0的正整数；
在查找到的规则桶内根据所述第一url的域名查询所述第一url的所属分类；每个所述规则桶包含至少一组url分类规则，所述url分类规则记录url的域名和所属分类，所述一组url分类规则记录的url的域名的前n个字符相同，所述规则桶包含的url分类规则数量在预设数量范围内；
将所述第一url的所属分类发送给所述网络设备。
第二方面提供一种url查询服务器，所述url查询服务器包括：
接收模块，用于接收网络设备发送的url查询请求，所述url查询请求中包括待查询的第一url；
处理模块，用于从所述第一url中提取域名；从所述域名中提取前n个字符，查找与所述前n个字符对应的规则桶，所述n为大于0的正整数；在查找到的规则桶内根据所述第一url的域名查询所述第一url的所属分类；每个所述规则桶包含至少一组url分类规则，所述url分类规则记录url的域名和所属分类，所述一组url分类规则记录的url的域名的前n个字符相同，所述规则桶包含的url分类规则数量在预设数量范围内；
发送模块，用于将所述第一url的所属分类发送给所述网络设备。
本发明实施例提供的url查询方法和url查询服务器，由位于云端的url查询服务器执行，在接收网络设备发送的url查询请求后，从url查询请求中携带的待查询的第一url中提取域名；然后从域名中提取前n个字符，在与前n个字符对应的规则桶内查询第一url的所属分类，其中，每个规则桶内存储至少一组域名的前n个字符相同的多个url分类规则，且每个规则桶内的url分类规则数量在预设数量范围内；将第一url的所属分类发送给网络设备后，使得网络设备确定终端访问第一url的所属分类，由于将url分类规则分配在多个规则桶内，一个规则桶内的url分类规则数量有限，在一个规则桶内查询第一url的所属分类速度较快，因此将提高对url进行查询的效率，从而提高用户体验。当然，实施本发明的任一产品或方法必不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的url查询方法实施例一的流程图；
图2为本发明实施例提供的url查询方法实施例二的流程图；
图3为本发明实施例提供的url查询服务器实施例一的结构示意图；
图4为本发明实施例提供的url查询服务器实施例二的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
对于企业所使用的办公网络，为了保证网络安全，以及提高办公效率，一般都配置有具有url识别能力的网络设备。目前，大部分的网络交换机都具有url识别功能，用户可以通过在交换机中预设url的识别规则，控制交换机连接的终端访问url的权限。一般地，url识别的目的一方面是为了保证网络和数据安全，阻止终端访问具有安全隐患的url，另一方面是为了阻止终端访问与企业工作内容无关的url，例如阻止访问视频网站、购物网站等。
但对于部署在企业的办公网络本地的网络设备，虽然具有url识别功能，但由于设备性能的限制，以及url规则库大小的限制，对url识别的能力有限，仅能对常见类型的url进行识别，有很大一部分url无法进行识别。因此，在此引入了云端的url查询方法。由网络运营商或第三方提供有云端url查询服务器，企业的本地网络设备在遇见无法识别的url时，可以将无法识别的url发送至云端的查询服务器。云端的查询服务器的处理能力较强，且存储空间巨大，能够存储海量的url分类规则，且能够满足多个并发的url查询请求。云端的url查询服务器在对网络设备发送的url进行匹配查询后，得到该url对应的分类规则，并将分类规则发送给网络设备，使得网络设备可以根据url对应的分类规则确定对该url的处理方法。
但随着互联网信息的爆炸式增长，云端存储的url分类规则越来越多，云端的url查询服务器在海量的url分类规则中查询到相应的分类规则的速度也越来越慢，这将影响对url进行识别的效率。另外，随着具有url识别能力的网络设备的普及，越来越多的网络设备可能需要请求云端的url分类服务器对url进行查询。而云端的url分类服务器也将难以处理海量的并发查询请求，同样将影响对url进行识别的效率。
因此，本发明实施例提供一种url查询方法，用于提高云端的url查询服务器对url的查询效率。
图1为本发明实施例提供的url查询方法实施例一的流程图，如图1所示，本实施例提供的方法包括：
步骤s101，接收网络设备发送的url查询请求，url查询请求中包括待查询的第一url。
由于不同用户对网络安全和网络控制的需求不同，因此，云端的url查询服务器一般仅对网络设备发送的url进行类型查询，将查询到的url所属分类反馈给网络设备后，由位于用户本地网络中的网络设备根据云端反馈的url所属分类，根据网络设备本地存储的url规则确定是否允许url的访问。因此，位于云端的url查询服务器仅对接收到的url进行类型查询，其中，url的类型例如包括：新闻、购物、视频、游戏、论文等等。
在用户本地网络中的网络设备上，根据用户的实际需求设置有对于不同类型的url的访问权限控制规则，例如对于一般的科研类企业，为了不影响工作，在办公用电脑上不允许访问购物、视频、游戏等娱乐类网站，并且，为了便于工作中查询资料，允许访问论文、学术类网站，对于这类企业本地网络中的网络设备，存储的url规则相应地应阻止上述娱乐类型网站对应的url的访问，且允许论文、学术类型网站的url访问。而对于提供视频服务的企业，就需要允许视频类网站的url访问。
当用户本地的网络设备在获取到终端访问的第一url后，首先根据本地存储的url规则确定第一url的所属分类，然后根据第一url的所属分类确定第一url的访问权限。若本地网络设备使用本地存储的url规则对第一url进行识别后，无法确定第一url的所属分类时，网络设备将向云端的url查询服务器发送url查询请求。url查询请求中包括待查询的第一url。
步骤s102，从第一url中提取域名。
云端的url查询服务器接收到url查询请求后，从中获取第一url，随后在存储的url分类规则中查询第一url所属分类。云端的url查询服务器存储有较完整的url分类规则，一般可以认为存储有互联网上绝大部分的url的分类规则。但在现有技术中，在海量的url分类规则中对第一url的分类规则进行查询的效率较低。因此，本实施例考虑对url的分类规则进行分桶处理，将海量的url分类规则分配到多个url规则桶中，其中，每个规则桶中的url分类规则的数量维持在一个预设的数量范围内。在对url分类规则进行分桶处理后，首先确定第一url所对应的url规则桶，然后再在相应的url规则桶内查询第一url的分类规则，这样将能够提高对第一url进行分类查询的效率。
在查找第一url对应的url规则桶时，需要采用一种快速高效的方式进行匹配，避免在查找url规则桶时产生过多的运算量。在对url的格式进行分析后，确定使用url中的域名作为对url分类规则进行分桶的基础。
其中，url的格式为：scheme://host:port/path。其中，scheme表示url所请求访问资源的互联网资源类型，例如scheme为http表示万维网服务器，scheme为ftp表示ftp服务器等。host表示url访问的资源所在服务器的域名，host也可以使用域名所在主机的ip地址表示。port为端口号，对于某些url资源的访问，需要提供相应的端口号。path表示路径，即访问的url资源在主机中的路径。
目前，大部分的网站中，采用子网站的域名的方式来区分不同类型的业务，例如，在域名为sina.com.cn的网站中，就是采用子网站的域名的方式区分不同类型的业务。其中，news.sina.com.cn为新闻类资源对应的子网站的域名，games.sina.com为游戏类资源对应的子网站的域名，sports.sina.com.cn为体育类资源对应的子网站的域名。为了便于对网站的维护和管理，大部分的网站都采用标准的命名作为子网站的域名的名称，也就是说，从url的域名中就可以确定出该域名所对应的资源的类型。因此，就可以采用url中的域名作为对url分类规则进行分桶的基础。那么，在获取到第一url后，首先从第一url中提取域名。
步骤s103，从域名中提取前n个字符，查找与前n个字符对应的规则桶，n为大于0的正整数。
步骤s104，在查找到的规则桶内根据第一url的域名查询第一url的所属分类；每个规则桶包含至少一组url分类规则，url分类规则记录url的域名和所属分类，一组url分类规则记录的url的域名的前n个字符相同，规则桶包含的url分类规则数量在预设数量范围内。
再进一步的，网络中具有海量的域名，采用完整的域名作为对url分类规则对应的规则桶进行分桶的基础显然也不现实。在对各种子网站的域名进行分析后，可以看出，在采用子网站的域名表示的域名中，域名中起始单词的含义一般表示子网站的域名对应的资源类型。那么，就可以将域名中的前n个字符作为对url分类规则进行分桶的基础，即将域名的前n个字符相同的多个url分类规则放在相同的一个url规则桶内，那么一个规则桶内的多个url分类规则有很大的概率具有相同或相似的url分类规则。再考虑到在每个规则桶内进行url分类规则的查询时，需要保证查询的效率，因此每个规则桶内包含的url分类规则的数量应该在一个预设的数量范围内。每个规则桶内包含的url分类规则的数量可以根据云端的url查询服务器的能力确定，该数量的确定原则是需要使url查询服务器在每个规则桶内进行url分类规则的查询时所需的时间小于一个时间阈值，这个时间阈值是用户能够接受的url查询响应时间，例如500毫秒。并且，每个规则桶内包含的url分类规则的数量也不能太少，否则会导致规则桶的数量较多，在对待查询的域名进行规则桶的匹配时会消耗过多时间。
在对url分类规则进行分桶时，一般可以先根据url查询服务器的能力，确定一个每个规则桶内url分类规则的数量上限，再根据预设的规则桶的数量上限，每个规则桶内包含的url分类规则的数量下限。其中预设的规则桶的数量上限也是根据url查询服务器的能力，考虑到对域名进行规则桶的匹配时所需的匹配时间阈值确定的。然后对所有待分桶的url分类规则中域名的前n个相同字符的数量进行依次判断。首先判断域名的第一个相同的字符的url分类规则的数量，例如若域名的第一个字符为g的url分类规则的数量未超过每个规则桶内url分类规则的数量上限，且大于该数量下限，那么就可以将第一个字符为g的url分类规则放在一个规则桶内。再判断域名的第一个字符为a的url分类规则的数量加上域名的第一个字符为e的url分类规则的数量之和未超过每个规则桶内url分类规则的数量上限，且大于该数量下限，那么就可以将域名的第一个字符为a和e的url分类规则放在同一个规则桶内。也就是说，一个规则桶内可以存储两组以上的域名的前n个字符相同的多个url分类规则。再例如，若域名的第一个字符为1的url分类规则的数量超过每个规则桶内url分类规则的数量上限，那么，可以再取域名中的前两个字符进行判断，例如域名的前两个字符为11、12、13、14的url分类规则的数量之和未超过每个规则桶内url分类规则的数量上限，且大于该数量下限，那么就可以将域名的前两个字符为11、12、13、14的url分类规则放在同一个规则桶内。依次类推，对云端的url查询服务器中的所有url分类规则都进行上述分桶处理，即可得到若干个url分类桶，每个分类桶中存储至少一组域名的前n个字符相同的多个url分类规则，且每个规则桶内的url分类规则数量在预设数量范围内。其中，url分类规则记录url的域名和所属分类。
当url查询服务器获取到第一url中的待查询域名后，提取该待查询域名的前n个字符，在与前n个字符对应的规则桶内查询第一url的所属分类。这样就可以降低对第一url进行查询所需的时间，提高查询效率。在海量的查询请求并发的情况下，可以将多个查询请求分别在多个分类桶中分别进行查询，同样可以提高并发查询的效率。
步骤s105，将第一url的所属分类发送给网络设备。
在获取到第一url的所属分类后，云端的url查询服务器即可将第一url的所属分类发送给发送url查询请求的网络设备。网络设备中存储有不同分类的url的访问权限，那么网络设备即可根据第一url的所属分类确定请求访问第一url的终端访问第一url的访问权限，完成对url的识别。
本实施例提供的url查询方法，由位于云端的url查询服务器执行，在接收网络设备发送的url查询请求后，从url查询请求中携带的待查询的第一url中提取域名；然后从域名中提取前n个字符，在与前n个字符对应的规则桶内查询第一url的所属分类，其中，每个规则桶内存储至少一组域名的前n个字符相同的多个url分类规则，且每个规则桶内的url分类规则数量在预设数量范围内；将第一url的所属分类发送给网络设备后，使得网络设备确定终端访问第一url的所属分类，由于将url分类规则分配在多个规则桶内，一个规则桶内的url分类规则数量有限，在一个规则桶内查询第一url的所属分类速度较快，因此将提高对url进行查询的效率，从而提高用户体验。
在云端的url查询服务器中，具有海量的url分类规则，对海量的url分类规则进行的分桶可以是预先设置在url查询服务器中的。当然，也可以是url查询服务器根据自身的处理能力，根据获取到的url分类规则和每个规则桶内的url分类规则数量在预设数量范围进行分桶的。url查询服务器对url分类规则进行分桶的具体方法在图1所示实施例中已经进行了详细阐述。
进一步的，为了提高对获取到的第一url进行规则桶匹配的效率，url查询服务器在根据各url分类规则中域名的前n个字符将url分类规则分配至多个规则桶中之后，还可以将每个规则桶中的url分类规则存储到一个哈希表中，生成多个与每个规则桶一一对应的哈希表。每个不同的url规则桶对应一个唯一的哈希表。那么，当从待查询的域名中提取到前n个字符后，首先确定与提取的前n个字符对应的第一规则桶，然后在第一规则桶对应的哈希表中进行查询第一url的分类规则。哈希表是一种常用的数据存储方法，在一个哈希表中包括多个哈希冲突链，每个哈希冲突链上包括若干个节点，每个节点中存储一个数据。每个哈希冲突链的长度根据哈希算法确定的冲突链长度确定，每个哈希冲突链具有一个相应的索引号，确定了哈希表中哈希冲突链的索引号后，即可在相应的哈希冲突链上查询数据。哈希表能够有效提高对数据进行查询的效率，因此，将每个规则桶内的url分类规则存储到一个哈希表中，将能够进一步的提高对url进行查询的效率。
具体而言，在对url分类规则进行分桶时，首先确定将url分类规则进行分桶，为每个url规则桶确定一个对应的哈希表，然后根据预设的哈希算法确定哈希表中哈希冲突链的长度。然后根据每个url规则桶内url分类规则的数量确定哈希表中哈希冲突链的数量，随后将每个url分类规则存储到哈希冲突链上的一个节点中，其中，每个节点的键为url分类规则中url的域名，节点的值为url分类规则对应的url所属分类。那么在对待查询的第一url分类进行查询时，首先提取第一url中的域名，然后确定与第一url中域名的前n个字符对应的规则桶。确定了规则桶后，即可确定与该规则桶对应的哈希表。然后对第一url的域名进行计算，得到一个索引号，根据该索引号可以确定第一url的域名所对应的url分类规则在哈希表中的哈希冲突链。随后根据第一url的域名在确定的哈希冲突链上查找与第一url的域名对应的第一节点，第一节点所对应的值即为第一url的所属分类。
由于不同url分类规则对应的规则桶包含的url分类规则可能对应域名的前若干的字符，也就是不同规则桶对应的域名所取的字符数量可能不同。那么为了实现对域名进行规则桶的匹配，可以从1开始，依次从待查询的第一url的域名中提取前n个字符，每次提取前n个字符后，确定与提取的前n个字符对应的规则桶，也就是在存储的多个规则桶中查找与提取的前n个字符对应的规则桶，当提取的前n个字符对应的规则桶为所述多个规则桶中的任一个时，确定n＝n。也就是确定了所提取的前n个字符的数量，然后在与提取的前n个字符对应的规则桶对应的哈希表内查询第一url的所属分类。例如，先提取待查询的第一url的域名的第一个字符，在存储的所有规则桶内查找是否有与该字符对应的规则桶，若找到相应的规则桶，则在相应规则桶对应的哈希表内进行url分类规则的查询。若未找到相应的规则桶，则再提取待查询的第一url的域名的前两个字符，在存储的所有规则桶内查找是否有与前两个字符对应的规则桶，依次类推，直至在存储的所有规则桶内查找到与提取的前n个字符对应的规则桶。
考虑到在哈希冲突链上进行查询的方式是依次进行的，即确定了待查询的哈希表和哈希冲突链后，按照各节点在哈希冲突链上的排列顺序，依次匹配待查询的第一url的域名和各节点的键，如果第一url的域名与节点的键匹配，则该节点被命中，即该节点对应的url分类规则被命中。那么为了进一步的提高在哈希冲突链上对url分类规则进行查询的效率，可以在哈希冲突链上按照url分类规则的查询命中次数依次存储各url分类规则。即在哈希冲突链上排序越靠前的节点对应的url分类规则的查询命中次数越多，那么在进行url分类规则查询时，被查询命中的次数较多的url分类规则被查询到的速度越快，这样将能够进一步的提高url的查询效率。
进一步的，在哈希表的每个冲突链上，各节点在冲突链上排序的依据是每个节点对应的url分类规则的查询命中次数，而在每次对待查询的url进行分类查询后，每个节点对应的url分类规则的查询命中次数将发生变化。那么为了进一步地提高在哈希表中查找第一url对应的url所属分类的效率，每次查询第一节点对应的url的所属分类之后，还可以修改哈希冲突链上第一节点的查询命中次数。当第一节点的查询命中次数超过哈希冲突链上位于第一节点之前的第二节点的查询命中次数时，将第一节点在哈希冲突链上的位置调整在第二节点之前。也就是说，哈希冲突链上的节点的排列顺序是动态调整的，从而可以进一步的提高在哈希中查找第一url对应的url分类规则的效率。
云端的url查询服务器需要承担海量的网络设备的url查询请求，若每次哈希中第一节点的查询命中次数发生变化后，都对第一节点的排序进行判断和调整，会导致对哈希冲突链上节点的调整次数过多，影响url查询服务器的处理效率。因此，在每次与第一节点对应的域名进行查询之后，还可以在第一节点的查询命中次数增加达到预设次数时，再判断第一节点的命中次数是否超过哈希冲突链上位于第一节点之前的第二节点的命中次数。当第一节点的查询命中次数超过第二节点的查询命中次数时，再将第一节点在哈希冲突链上的位置调整在第二节点之前。例如，当某一节点被查询命时，将该节点的命中次数加1，当增加达到k次(即预设次数)时，再对哈希冲突链上的该节点的排列顺序进行判断及调整，如此可以尽可能地减少对哈希冲突链上节点的调整次数。
具体地，调整哈希冲突链上各节点的排列顺序可以是递归式的比较，即每次进比较哈希冲突链上每个节点的查询命中次数与相邻的前一个节点的查询命中次数。例如某一时刻哈希冲突链上前5个节点的查询命中次数分别为10、7、6、8、3，此时比较第四个节点的查询次数为8大于前一个节点的查询命中次数6，因此调整哈希冲突链上这5个节点的顺序。此时哈希冲突链上前5个节点的查询命中次数分别为10、7、8、6、3，再经过比较后，第三个各节点的查询命中次数为8大于前一个节点的查询命中次数7，因此调整哈希冲突链上这5个节点的顺序，最终将哈希冲突链上前5个节点的查询命中次数分别为10、8、7、6、3。此时各节点的查询命中次数均由大到小排列，不再进行调整。
进一步的，从待查询的域名中提取前n个字符，在与前n个字符对应的规则桶内查询第一url的所属分类之后，若在与前n个字符对应的规则桶内未查询到查询第一url的所属分类，则向网络设备发送无法识别第一url的信息。云端的url查询服务器中虽然可以存储海量的url分类规则，但是由于互联网上的url资源数量巨大，并且更新速度极快，因此仍然会存在url查询服务器中也未没有存储相应分类规则的url。那么，若通过图1所示实施例的方法进行了url查询后，并未查询到第一url的所属分类，url查询服务器将向网络设备发送无法识别第一url的信息。网络设备在接收到无法识别第一url的信息后，将根据预设的规则，确定是否允许终端访问第一url。一般地，为了保证网络安全，网络设备将阻止终端访问无法识别分类规则的url。
图1所示实施例以及上述可选的实施方式中，对本发明实施例提供的url查询方法进行了详细阐述。但是，上述实施例阐述的内容仅对url为通过子网站的域名的方式区分不同业务类型的url的查询方法进行了说明。在url的表示方式中，还有一种采用域名和路径区分业务的类型的表示方式。例如对于域名为weihailife.com的域名，就是采用域名加路径的方式来区分不同业务的类型。其中weihailife.com/news的路径对应新闻类资源，weihailife.com/jobs的路径对应求职类资源等。对于通过域名和路径区分业务的url，仅通过比对规则桶内的url分类规则将无法确定url对应的分类规则。这是由于采用子网站的域名方式表示的url中，进行url分类规则的比对采用的是是否相同的比对方式，即在获取第一url并确定对应的规则桶后，在规则桶中判断是否有与第一url的域名相同的url分类规则。但对于通过域名和路径区分业务的url，由于不同url的域名是相同的，因此需要对整个url进行比对，判断整个url中是否包含相应的统一资源标识符(uniformresourceidentifier，uri)分类规则。对于第一url，若确定第一url为通过域名和路径区分业务的类型，那么需要根据预设算法查询第一url是否包含预定义的uri分类规则，若第一url包含预定义的uri分类规则，则根据第一url包含的预定义的uri分类规则确定第一url的分类规则。
例如第一url为“abc.com/news/sport/123.html”，某个uri分类规则为“abc.com/news”对应新闻分类，那么在对第一url进行比对后，可以确定第一url的分类规则为新闻分类。
具体地，对于通过域名和路径区分业务的类型的url，在url规则桶内，将该类url对应的域名的所属分类分配为制定的特殊分类，该特殊分类不是一个确定的分类类型。当url查询服务器将待查询的第一url在规则桶内进行查询后，若得到第一url的所属分类为该特殊分类，则url查询服务器即可确定第一url为通过域名和路径区分业务的类型的url。url查询服务器提取第一url的域名和路径，在指定的规则库中查找匹配的uri分类规则，匹配的uri分类规则记录的url的域名和路径包含第一url的域名和路径，或者，匹配的uri分类规则记录的url的域名和路径与第一url的域名和路径相同。随后url查询服务器即可确定第一url的所属分类为匹配的uri分类规则记录的所属分类。
进一步的，在对通过域名和路径区分业务的url进行url查询时，还可能出现一个url与多个uri分类规则向匹配的情况。即一个url可能同时包含多个uri分类规则，此时，若第一url包含至少两个预定义的uri分类规则，则根据第一url包含的预定义的uri分类规则中长度最长的uri分类规则确定第一url的分类规则。这是由于uri分类规则中长度越长的uri分类规则包含约细致的分类规则。
例如第一url为“abc.com/news/sport/123.html”，某个uri分类规则为“abc.com/news”对应新闻分类，另一个uri分类规则为“abc.com/news/sports”对应体育分类，那么在对第一url进行比对后，确定第一url同时包含上述两个uri分类规则，由于uri分类规则为“abc.com/news/sports”长度较长，因此在进行比对后，可以确定第一url的分类规则为体育类。
在对通过域名和路径区分业务的url进行查询时，例如可以采用ac算法进行判断。但本发明实施例不对该算法进行限制，能够实现对通过域名和路径区分业务的url进行查询的各种方法都在本发明的保护范围之内。
图2为本发明实施例提供的url查询方法实施例二的流程图，如图2所示，本实施例提供的方法包括：
步骤s201，接收到网络设备发送的第一url查询请求。
步骤s202，从第一url中获取域名。
步骤s203，从域名中提取前n个字符，确定与提取的前n个字符对应的第一规则桶，根据第一url计算第一url在第一规则桶对应哈希表的哈希冲突链上的索引序号。
步骤s204，在索引序号对应的哈希冲突链上查询对应的第一节点。
步骤s205，若在哈希冲突链上查询到第一节点，则判断第一url的所属分类是否为特殊分类。
步骤s206，若第一url的所属分类不是特殊分类，则将第一节点对应的所属分类确定为第一url的所属分类。
步骤s207，若第一ur的所属分类是特殊分类，根据ac算法查询第一url是否包含预定义的uri分类规则。
步骤s208，若在哈希冲突链上未查询到对应的第一节点，或者根据ac算法查询第一url不包含预定义的uri分类规则，则向网络设备发送无法识别第一url的信息。
步骤s209，将第一节点对应的所属分类或根据ac算法查询第一url包含的预定义的uri分类规则对应的所属分类发送给网络设备。
步骤s210，更新第一节点的查询命中次数，调整哈希冲突链上各节点的排序。
进一步地，在步骤s201之前，还包括，步骤s211，对存储的url分类规则分配到不同的url规则桶内。步骤s212，将不同url规则桶内的url分类规则存储到不同哈希表中。
图3为本发明实施例提供的url查询服务器实施例一的结构示意图，如图3所示，本实施例提供的url查询服务器包括：
接收模块31，用于接收网络设备发送的url查询请求，所述url查询请求中包括待查询的第一url。
处理模块32，用于从所述第一url中提取域名；从所述域名中提取前n个字符，查找与所述前n个字符对应的规则桶，所述n为大于0的正整数；在查找到的规则桶内根据第一url的域名查询所述第一url的所属分类；每个所述规则桶包含至少一组url分类规则，所述url分类规则记录url的域名和所属分类，所述一组url分类规则记录的url的域名的前n个字符相同，所述规则桶包含的url分类规则数量在预设数量范围内。
发送模块33，用于将所述第一url的所属分类发送给所述网络设备。
本发明实施例提供的url查询服务器用于实现图1所示的url查询方法的技术方案，其实现原理和技术效果类似，此处不再赘述。
图4为本发明实施例提供的url查询服务器实施例二的结构示意图，如图4所示，本实施例提供的url查询服务器在图3的基础上，还包括：
存储模块34，用于将每个所述规则桶中的url分类规则存储到一个哈希表中，每个哈希表包括至少一个哈希冲突链，所述哈希冲突链包括至少一个节点，所述一个节点对应一条url分类规则，所述节点的键为对应的url分类规则中url的域名，所述节点的值为所对应的url分类规则中url的所属分类。
进一步地，在图4所示实施例中，处理模块32，具体用于确定所述前n个字符对应的哈希表；对第一url的域名进行计算得到索引号；在确定出的哈希表中所述计算得到的索引号对应的哈希冲突链上，以所述第一url的域名为键，查找对应的第一节点，将所述第一节点的值作为所述第一url的所属分类。
进一步地，在图4所示实施例中，处理模块32，还用于在查找到对应的第一节点时，将所述第一节点的命中次数加1；当所述第一节点的命中次数增加达到预设次数时，比较第一节点与第二节点的命中次数，所述第二节点与所述第一节点位于同一个哈希冲突链，且第二节点为第一节点的前一个节点；当第一节点的命中次数大于所述第二节点的命中次数，将所述第一节点在所述哈希冲突链上的位置调整在所述第二节点之前。
进一步地，在图3或图4所示实施例中，处理模块32，还用于若查询到的所述第一url的所属分类为指定的特殊分类，则提取所述第一url的域名和路径，在指定的规则库中查找匹配的uri分类规则，所述匹配的uri分类规则记录的url的域名和路径包含所述第一url的域名和路径，或者，所述匹配的uri分类规则记录的url的域名和路径与所述第一url的域名和路径相同；将所述匹配的uri分类规则记录的url的所属分类作为所述第一url的所属分类。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。