一种URL数据挖掘方法及系统与流程

本申请涉及数据挖掘技术领域，尤其涉及一种url数据挖掘方法及系统。

背景技术：

url(uniformresourcelocator，统一资源定位符)，也称为网页地址，是互联网上标准的资源地址，通过url可以直接定位到互联网上指定的资源或者网页。上网行为管理产品是指帮助互联网用户控制和管理互联网的使用情况。包括对访问网页过滤、网络应用控制、带宽流量管理、信息收发审计、用户行为分析等。为了更好的获悉互联网的使用情况，需要通过上网行为管理产品获取比较全面的url数据信息，并对获取到的url数据进行合理的分类，使上网行为管理产品能够匹配用户网站访问分类记录日志，以用来统计用户上网行为，减少用户对不合法网站的直接访问。

为了收集网络上的url数据，可以通过网络爬虫、用户反馈和外网实验局设备匿名三种方式收集url数据。其中，网络爬虫方式是通过书写爬虫脚本来获取搜索引擎、域名统计网站和对已有url数据进行操作，对已经获取的url数据可以书写爬虫模拟人访问网站的操作，从而将网页html数据抓取保存，然后对保存数据进行解析，得到该网页html数据下的关联url数据。再通过书写程序对其关联url数据抓取，解析该关联url数据可以得到网站的其他url和友情链接等数据。

实际隶属于同一公司url数据量巨大，一般都是千万级别。如腾讯主页“www.qq.com”，其html数据中，包含新闻域名“news.qq.com”的相关信息，则通过爬虫操作抓取主页就能获取到“news.qq.com”等数据。可见，在海量数据中很有可能存在域名无法解析dns、服务器无法响应和服务器响应超时的情况。由于，对于一个无法访问的域名，通过爬虫操作解析dns发出请求到服务器响应需要较长的等待时间，以致爬虫程序会持续等待该域名完成或者超时结束再继续其他数据操作，严重降低数据挖掘效率。同时，对于网站延迟较高的情况，通过程序自定义超时时间，可能因网站响应时间超过等待超时时间阈值，而造成误判，导致无法获取该域名的数据。

技术实现要素：

本申请提供了一种url数据挖掘方法及系统，以解决传统url数据挖掘方法等待时间长，挖掘效率低的问题。

一方面，本申请提供一种url数据挖掘方法，包括：

获取url数据，所述url数据中包括多个url地址；

将所述url数据切割，依次添加至协程事件循环；

运行所述协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应；

根据所述请求响应获取响应数据；

检查所述响应数据是否包含js跳转代码；

若包含所述js跳转代码，解析所述js跳转代码，获取重定向url地址，再次接收响应数据；

按预设格式将url地址和响应数据存储在一个文件中。

可选的，获取url数据的步骤，包括：

通过外网反馈、设备匿名收集和censys官网分析项目，获取对整个ipv4地址空间扫描的结果数据；

解析所述结果数据，生成所述url数据。

可选的，将所述url数据切割，依次添加至协程事件循环的步骤，包括：

获取所述url数据中包含的url地址数，以及数据处理设备的内存容量；

根据所述内存容量和url地址数对url数据分组；

为每组url数据标记处理序号；

按照处理序号的顺序将每组url数据依次添加至协程事件循环。

可选的，运行所述协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应的步骤，包括：

获取数据处理设备的计算机性能信息；

根据所述计算机性能信息，定义协程事件循环中单次最大并发url连接数量；

通过协程事件循环以每次所述最大并发url连接数量，请求访问url数据中的各url地址；

接收每次访问的url地址所对应服务器的请求响应。

可选的，根据所述请求响应获取响应数据的步骤，包括：

在预设时间段内判断是否接收到请求响应；

如果接收到所述请求响应，根据所述请求响应获取响应数据；

如果未接收到所述请求响应，保持接收当前url地址的请求响应，以及通过协程事件跳转访问下一个url地址；

根据下一个url地址的访问结果循环判断是否接收到请求响应。

可选的，根据所述请求响应获取响应数据的步骤，还包括：

根据请求响应中的http响应代码，判断当前url地址响应是否正常；

如果所述http响应代码为200，确定当前url地址响应正常，根据所述请求响应获取响应数据；

如果所述http响应代码为重定向代码，确定当前url地址响应不正常，记录重定向url地址；

访问所述重定向url地址，接收重定向url地址服务器的请求响应；

根据所述重定向url地址服务器的请求响应获取响应数据。

可选的，根据所述请求响应获取响应数据的步骤，还包括：

判断所述请求响应是否存在响应超时和/或响应错误；

如果所述请求响应存在响应超时和/或响应错误，记录当前url地址、响应超时、响应错误类型到日志中；

结束当前url地址对应的协程事件。

可选的，检查所述响应数据是否包含js跳转代码的步骤，包括：

如果所述响应数据不包含js跳转代码，执行按预设格式将url地址和响应数据存储在一个文件中的步骤。

可选的，按预设格式将url地址和响应数据存储在一个文件中的步骤，包括：

根据响应数据抓取html数据；

通过二进制字符算法，将所述html数据中的换行符号替换为转义字符；

根据所述url地址和替换换行符号后的html数据，组合生成行数据；

将多个url对应的所述行数据，写入同一个数据文件，存储所述数据文件。

另一方面，本申请还提供一种url数据挖掘系统，包括相互建立通信连接的数据处理设备和上网行为管理设备；所述数据处理设备用于运行url数据挖掘程序；以及，将挖掘的数据发送给所述上网行为管理设备，以用于所述上网行为管理设备升级；

所述处理器被进一步配置为执行以下程序步骤：

获取url数据，所述url数据中包括多个url地址；

将所述url数据切割，依次添加至协程事件循环；

运行所述协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应；

根据所述请求响应获取响应数据；

检查所述响应数据是否包含js跳转代码；

若包含所述js跳转代码，解析所述js跳转代码，获取重定向url地址，再次接收响应数据；

按预设格式将url地址和响应数据存储在一个文件中。

由以上技术方案可知，本申请提供一种url数据挖掘方法及系统，所述方法包括：获取url数据，将url数据切割，依次添加至协程事件循环；通过运行协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应，并根据请求响应获取响应数据；再检查响应数据是否包含js跳转代码；若包含js跳转代码，解析js跳转代码，获取重定向url地址，再次接收响应数据；最后按预设格式将url地址和响应数据存储在一个文件中。所述方法将被动的获取url数据转变成主动获取，并且通过协程事件降低由于请求响应超时等待导致的线程、进程堵塞，提高数据挖掘效率。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一种url数据挖掘方法的流程示意图；

图2为本申请获取url数据的流程示意图；

图3为本申请对url数据进行分组的流程示意图；

图4为本申请将url地址添加到协程事件循环的流程示意图；

图5为本申请判断是否接收到请求响应的流程示意图；

图6为本申请根据http响应代码判断响应情况的流程示意图；

图7为本申请结束协程事件的流程示意图；

图8为本申请存储数据文件的流程示意图。

具体实施方式

下面将详细地对实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下实施例中描述的实施方式并不代表与本申请相一致的所有实施方式。仅是与权利要求书中所详述的、本申请的一些方面相一致的系统和方法的示例。

参见图1，为本申请一种url数据挖掘方法的流程示意图。由图1可知，本申请提供的url数据挖掘方法，包括以下步骤：

s1：获取url数据，所述url数据中包括多个url地址。

本申请提供的技术方案中，所述url数据挖掘方法可以应用于数据处理设备，对互联网中的url数据进行挖掘。应当理解的是，本申请所述的数据处理设备包括但不限于计算机、服务器、有数据处理功能的智能终端等。实际应用中，所述url数据挖掘方法可以通过应用程序的方式，内置于数据处理设备中。本申请可通过应用程序来自动根据部分url数据，来不断获取html数据，并以此方式来解析更多的url地址，即本申请在传统方法被动去收集设备的方式，和外网用户反馈方式的基础上，以主动方式来获取更多的url数据。

进一步地，在本申请的部分实施例中，在获取url数据的过程中为获取到更多有处理价值的数据，可采用以下数据获取方式，即如图2所示，获取url数据的步骤，包括：

s101：通过外网反馈、设备匿名收集和censys官网分析项目，获取对整个ipv4地址空间扫描的结果数据；

s102：解析所述结果数据，生成所述url数据。

本实施例中，获取的url数据不仅来自外网反馈和设备匿名收集，还从censys官网分析项目获取的对整个ipv4地址空间扫描的结果数据。其中，censys官网分析项目是一个洞察互联网秘密的新型搜索引擎。对上述获取的数据进行解析，以使得url数据为上述三种方式合并的结果。

s2：将所述url数据切割，依次添加至协程事件循环。

本申请提供的技术方案中，在获取到海量url数据后，即可将url数据添加至协程事件循环，逐一处理每个url地址。由于协程事件对计算机内存消耗较普通的多线程、多进程多很多，因此需要将海量url数据进行切割，不断加入循环，以解决计算机内存有限的问题。

上述url数据分割过程，可作为数据的预处理过程，即通过将url数据进行分割，可以解决协程事件内存占用过多问题。比如，当前url数据中包含有100万url地址，为了解决内存占用过多问题，可以通过相应的数据分割程序，将url数据分成10份，也就是每份包含10万个url地址。通过对完整数据进行分割，并且循环将其输入到协程事件中，来降低协程事件循环对内存的占用。

如图3所示，对海量url数据进行切割的具体切割方式，可以依据当前数据处理设备的硬件特点进行有针对的调整，即在本申请的部分实施例中，将所述url数据切割，依次添加至协程事件循环的步骤，包括：

s201：获取所述url数据中包含的url地址数，以及数据处理设备的内存容量；

s202：根据所述内存容量和url地址数对url数据分组；

s203：为每组url数据标记处理序号；

s204：按照处理序号的顺序将每组url数据依次添加至协程事件循环。

即，在本实施例中，在对url数据实时分割前，可以先获取url数据中所包含的url地址的个数。如果数量不多，即未超过预设数量阈值，可以无需对url数据进行切割，直接逐一处理即可；如果数量较多，即超过预设数量阈值，则需要对url数据进行进一步分割处理，再逐一针对切割后的数据添加至协程事件。

由于对协程事件处理的最大硬件限制条件为内存容量，因此在本实施例中，可以数据处理设备的内存容量作为url数据切割的判断依据。即获取内存容量后，根据内存容量和url地址数对url数据进行分组。为了便于后续添加至协程事件循环，在本实施例中，还可以对为每组url数据标记处理序号，以便按照处理序号的顺序将每组url数据依次添加至协程事件循环。

s3：运行所述协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应。

本申请提供的技术方案中，通过运行协程事件循环，可以逐一访问每组url数据中的url地址。由于协程事件的作用机理，即协程事件在执行函数a时，可以随时中断，去执行函数b，然后中断继续执行函数a，可以实现自由切换，使得本申请在访问一个url地址出现异常情况时，无需等待当前url地址响应结束，而是可以跳转至下一个url地址继续进行访问。

需要说明的是，协程事件的处理过程，并不是函数调用，即没有调用语句，这一整个过程看似像多线程，然而协程事件只有一个线程执行，因此对于数据处理设备而言，无需进行过多的硬件升级即可完成上述配置。

进一步地，如图4所示，运行所述协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应的步骤，包括：

s301：获取数据处理设备的计算机性能信息；

s302：根据所述计算机性能信息，定义协程事件循环中单次最大并发url连接数量；

s303：通过协程事件循环以每次所述最大并发url连接数量，请求访问url数据中的各url地址；

s304：接收每次访问的url地址所对应服务器的请求响应。

本实施例中，通过使用协程事件的信号量同步机制可以进行并发量限制，即根据不同的计算机性能，定义为协程事件单次最大并发url的连接数量。本实施例中，计算机性能信息可以包括处理器性能信息(如型号、核心数、主频等)、内存性能信息(如内存容量、内存频率、读写速度)、当前数据处理设备的繁忙程度信息(如内存占用情况、处理器温度等)以及网络信息(如网络带宽、网络延迟等)等。

本申请将url地址请求通过协程事件来完成，即通过在发起请求程序中，定义请求过程为协程调用过程，并且完成对信号量同步下的最大并发量限制。由于，并发量太大可能导致部分响应无法及时处理，而导致错误，因此最大并发量限制一般定义为200。通过获取计算机性能信息，可以针对性的调整单次最大并发url的连接数量，即同时处理的url数量。例如，对于计算机性能较好的数据处理设备，可以定义其单次最大并发url的连接数量也较多，以提高url数据的处理速度；而对于计算机性能不好的数据处理设备，可以通过定义其单次最大并发url的连接数量较少，以避免出现崩溃、死机的问题。

另外，在此协程事件循环中，对请求响应正常、重定向、js跳转、错误进行合理处理，使得请求程序可以持续运行。还可以使用多进程或者多线程来替换协程事件方法进行url地址请求，并进行其他相同的操作，以避免单个线程、进程遇到无法响应的请求，或者响应时间较高情况，就将堵塞等待，无法继续处理。

但是，在实际应用中，由于多进程或者多线程与之对应的需求是，更强悍的多核心cpu。而在进程线程运行个数限制在较高的情况时，会导致线程和进程之间频繁进行切换，而切换动作需要消耗时间，导致累积处理时间延长。因此采用更多的进程和线程数量的方式，由于会导致大多数时间消耗在切换上，一般是不可取的。实际应用中，还可以通过分布式实现，即将不同任务分发到多台数据处理设备上进行数据挖掘，以减少更多的时间，提高数据挖掘效率。

s4：根据所述请求响应获取响应数据。

在本申请提供的技术方案中，在运行每个协程事件循环时，如果一个url请求接收到响应，则接收其响应数据。并且这个步骤会一直运行，直到协程循环中无任何需要运行的事件为止，即当前url数据中的所有url地址均处理完毕为止。

具体地，如图5所示，在本申请的部分实施例中，根据所述请求响应获取响应数据的步骤，包括：

s411：在预设时间段内判断是否接收到请求响应；

s412：如果接收到所述请求响应，根据所述请求响应获取响应数据；

s413：如果未接收到所述请求响应，保持接收当前url地址的请求响应，以及通过协程事件跳转访问下一个url地址；

s414：根据下一个url地址的访问结果循环判断是否接收到请求响应。

本申请提供的技术方案中，每访问一个url地址，可以针对该url地址所对应的服务器进行请求响应的判断，以确定当前url地址是否能够正常响应。实际应用中，最直接的正常响应判断方法即是否接收到请求响应，可以对是否接收到服务器的请求响应进行判断，即：如果在预定的时间段内，接收到服务器反馈的请求响应，则直接根据请求响应获取响应数据即可。

而如果预定的时间段内，没有接收到服务器反馈的请求响应，则一般可能存在两种情况，一种为，当前url地址无法访问，导致对应的服务器没有反馈请求响应；另一种为，当前应用网络的网络状况不好，网络延迟较高，使得服务器反馈的请求响应未在设定时间内返回到数据处理设备中。对于第一种情况，等待再长时间也不可能接收到服务器反馈的请求响应，因此可以确定对应url地址出现响应错误；而对于第二种情况，在等待足够长的时间后，即可收到服务器反馈的请求响应，因此可以确定对应url地址出现响应超时的异常情况。

由于在实际应用中，协程事件循环的目的在于提高url数据的处理效率，因此在本实施例中，每个循环等待反馈请求响应的时间不宜过长，并且可以根据当前网络的延迟时间设定等待时间，例如，当前网络的平均延迟为200ms，则通过当前网络，数据传递的最高延迟时间为200×2＝400ms，因此可以设置预设时间段为1s，则能够避免大部分因网络延迟造成的影响。进一步地，在本申请提供的技术方案中，还可以针对请求响应进行进一步判断，确定当前url地址对应的服务器是否包含其他类型的异常情况。如图6所示，根据所述请求响应获取响应数据的步骤，还包括：

s421：根据请求响应中的http响应代码，判断当前url地址响应是否正常；

s422：如果所述http响应代码为200，确定当前url地址响应正常，根据所述请求响应获取响应数据；

s423：如果所述http响应代码为重定向代码，确定当前url地址响应不正常，记录重定向url地址；

s424：访问所述重定向url地址，接收重定向url地址服务器的请求响应；

s425：根据所述重定向url地址服务器的请求响应获取响应数据。

本实施例中，可以根据接收到的请求响应，判断当前url地址响应是否正常。由于服务器针对请求的响应，一般符合标准的互联网规范，即请求响应中必然包含http响应代码，因此，可以通过http响应代码直接对响应情况进行判断。具体的，如果所述http响应代码为200，确定当前url地址响应正常，根据所述请求响应获取响应数据；如果所述http响应代码为301、302等重定向代码，确定当前url地址响应不正常。此时，需要记录重定向url地址，并且以上述相同的方式访问重定向url地址，以接收服务器的请求响应。

实际应用中，通过对http响应代码的判断，可以逐个对url地址的响应是否正常进行判断，从而使数据处理设备能够通过响应正常的url地址获取到更多可以进行分析的数据，使后续分类结果更具有应用价值。

另外，如图7所示，在本申请的部分实施例中，根据所述请求响应获取响应数据的步骤，还包括：

s431：判断所述请求响应是否存在响应超时和/或响应错误；

s432：如果所述请求响应存在响应超时和/或响应错误，记录当前url地址、响应超时、响应错误类型到日志中；

s433：结束当前url地址对应的协程事件。

本实施例中，如果响应事件出现响应超时或者其他任何响应错误情况，可以将其错误原因和请求的url地址一并记录到日志中，并结束这个事件。通过这种方式，可以避免协程事件在处理每组url数据中，单个url地址一直没有响应正常，所造成的重复处理时间消耗。即，如果确定当前url地址无法正常响应，则可以通过结束当前url地址对应的协程事件，以不再从当前url地址获取响应数据，从而缩短每组url数据的处理时间，提高整体处理效率。

s5：检查所述响应数据是否包含js跳转代码。

本申请提供的技术方案中，在获取响应数据后，可以针对响应数据的内容，判断其是否包含js跳转代码。其中，js跳转代码，即javasrcipt代码，是一种前端浏览器运行的代码，部分网站采用这种方式防止爬虫，或进行语言检查。代码被浏览器接收，浏览器解释js代码，最终结果会跳转到正常的网页。本申请按照预定义的特征，检查响应数据是否包含js跳转代码，可以获取到当前url地址对应的最终网页，因此可以获得更多有助于进行分类处理的数据。

s6：若包含所述js跳转代码，解析所述js跳转代码，获取重定向url地址，再次接收响应数据。

实际应用中，如果当前响应数据中包含js跳转代码，可以对js跳转代码进行解析处理，并对解析的结果进行判断，以便获取到重定向url地址。根据重定向url地址，可以通过再次执行s3步骤，再次发起访问请求，以致获取最终的响应数据。

进一步地，在本申请中，检查所述响应数据是否包含js跳转代码的步骤，还包括：如果所述响应数据不包含js跳转代码，执行按预设格式将url地址和响应数据存储在一个文件中的步骤。即在实际应用中，如果不包含js跳转代码，直接将其抓取得数据保存进存储设备即可。

s7：按预设格式将url地址和响应数据存储在一个文件中。

在本申请提供的技术方案中，由于后续分类处理的数据处理量非常巨大，机器学习模型不能也不需要在很短的时间内，对如此大量的数据进行处理，因此，在获取到url数据对应的目标数据后，需要对获取的数据进行存储。在本申请提供的技术方案中，可以按照预设格式将url地址和相应数据存储在一个文件中，以便后期直接调用该文件进行分类操作。

具体地，如图8所示，按预设格式将url地址和响应数据存储在一个文件中的步骤，包括：

s701：根据响应数据抓取html数据；

s702：通过二进制字符算法，将所述html数据中的换行符号替换为转义字符；

s703：根据所述url地址和替换换行符号后的html数据，组合生成行数据；

s704：将多个url对应的所述行数据，写入同一个数据文件，存储所述数据文件。

由以上步骤可知，在本申请提供的技术方案中，可以将数据作为一个文件进行存储，即将每次访问获取的响应数据按照“url+html数据”的方式，逐行写入数据文件中。由于采用每个一行保存，而html数据中存在换行等特殊字符，因此，需要按照二进制的字符算法，将换行符号替换为转义字符，避免数据中错误换行导致后续解析错误。

另外，由于万维网数据复杂的编码问题，即不同的地区使用的编码不一致，而程序可能不能正确处理编码，比如中文就有utf-8、gbk等编码，因此，按照二进制保存可以忽略编码转换导致的问题。

在本申请提供的技术方案中，将多个url数据写入同一个文件进行保存的方式，不仅避免了过多的占用硬盘存储空间，而且能够提高后续分类处理时的数据遍历效率。例如：如果请求10万个url，则按照一个url地址一个文件的存储方式，可以得到10万个html文件，那么遍历所有的文件将会很耗时，而在实际应用中，通过数据处理设备，获取的url数据中，url地址数量通常是千万级别的，这种级别的数据处理将消耗大量时间。需要说明的是，在本申请提供的技术方案中，也可以根据先前url数据的切割方式，来确定数据文件的生成个数。例如，先前数据切割为10组，则可以对应生成10个数据文件，以便于对数据的后续处理。

通过本申请提供的url数据挖掘方法，可以用来获取海量url数据，将被动的获取url数据转变成主动获取，并且降低部分由于请求响应超时等待导致的线程、进程堵塞的影响。本申请采用协程时间的处理方式，可以维护一系列url地址请求，比如当前有200个请求，其中有50个url无法访问，那么总共超时时间为8秒，而不是单线程的50×8＝400秒。

假如在1千万个url地址的url数据中有10万条目无法访问，单个响应等待超时时间为8秒，那么最终导致超时总时间超过(100000×8)/3600≥200小时，如果是单线程爬虫，那么最终导致8天时间被浪费在等待超时上，而采用本申请的方法，在分割为10组的情况下，共需要等待的时间也仅仅为10×8＝80秒。可见，本申请可以大大缩短异常请求的访问时间，提高数据处理效率。

基于上述url数据挖掘方法，本申请还提供一种url数据挖掘系统，包括相互建立通信连接的数据处理设备和上网行为管理设备；所述数据处理设备用于运行url数据挖掘程序；以及，将挖掘的数据发送给所述上网行为管理设备，以用于所述上网行为管理设备升级；

所述处理器被进一步配置为执行以下程序步骤：

s1：获取url数据，所述url数据中包括多个url地址；

s2：将所述url数据切割，依次添加至协程事件循环；

s3：运行所述协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应；

s4：根据所述请求响应获取响应数据；

s5：检查所述响应数据是否包含js跳转代码；

s6：若包含所述js跳转代码，解析所述js跳转代码，获取重定向url地址，再次接收响应数据；

s7：按预设格式将url地址和响应数据存储在一个文件中。

由以上技术方案可知，本申请提供一种url数据挖掘方法及系统，所述方法包括：获取url数据，将url数据切割，依次添加至协程事件循环；通过运行协程事件循环访问url地址，以及接收url地址服务器反馈的请求响应，并根据请求响应获取响应数据；再检查响应数据是否包含js跳转代码；若包含js跳转代码，解析js跳转代码，获取重定向url地址，再次接收响应数据；最后按预设格式将url地址和响应数据存储在一个文件中。所述方法将被动的获取url数据转变成主动获取，并且通过协程事件降低由于请求响应超时等待导致的线程、进程堵塞，提高数据挖掘效率。

本申请提供的实施例之间的相似部分相互参见即可，以上提供的具体实施方式只是本申请总的构思下的几个示例，并不构成本申请保护范围的限定。对于本领域的技术人员而言，在不付出创造性劳动的前提下依据本申请方案所扩展出的任何其他实施方式都属于本申请的保护范围。