CN103036969A - 用于提供文件下载地址的管理设备及方法 - Google Patents

Abstract

本发明公开了一种用于提供文件下载地址的管理设备及方法，其中，该方法包括：根据文件在数据源节点中的存储路径生成所述文件的资源定位信息；对所述文件的内容采用特定数据转换生成所述文件的内容摘要；至少根据所述文件的资源定位信息和所述文件的内容摘要，生成所述文件的下载地址，所述下载地址中至少包括所述文件的资源定位信息和所述文件的内容摘要。

Description

用于提供文件下载地址的管理设备及方法

技术领域

本发明涉及数据下载技术领域，具体涉及一种用于提供文件下载地址的管理设备及方法。

背景技术

现有CDN（Content Delivery Network，内容分发网络）通过将数据分发到各个边缘节点，拉近与客户端的距离来提高数据访问速度。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

但是，由于现有的每个CDN节点都会尽可能地缓存数据源中所有的文件，因此会带来较大的存储成本。而且有些文件的内容并没有发生变化，仅仅是下载地址，如文件的URL发生了变化，按照现有CDN的缓存方式，也会在一个节点中缓存多份内容相同、URL不同的文件，即重复数据缓存，从而进一步导致了存储的成本较高。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的用于提供文件下载地址的管理设备及方法。

依据本发明的一个方面，提供了一种用于提供文件下载地址的管理设备，包括：资源定位器，被配置为根据文件在数据源节点中的存储路径生成文件的资源定位信息；摘要生成器，被配置为对文件的内容采用特定数据转换生成文件的内容摘要；以及下载地址生成器，被配置为至少根据资源定位器提供的文件的资源定位信息和摘要生成器提供的文件的内容摘要，生成文件的下载地址，下载地址中至少包括文件的资源定位信息和文件的内容摘要。

可选的，下载地址生成器生成的文件的下载地址是文件的统一资源定位符ＵＲＬ。

根据本发明的又一方面，提供了一种用于提供文件下载地址的管理方法，包括：根据文件在数据源节点中的存储路径生成文件的资源定位信息；对文件的内容采用特定数据转换生成文件的内容摘要；至少根据文件的资源定位信息和文件的内容摘要，生成文件的下载地址，下载地址中至少包括文件的资源定位信息和文件的内容摘要。

根据本发明的实施例，可以将从所请求文件下载地址解析出的文件内容摘要作为缓存文件查询依据，在缓存中查询是否已经存储了所请求的文件，而不是根据文件的整个URL作为索引查询，同理，在缓存中存储文件时也是根据文件的内容摘要是否相同判断是否为同一份文件。因此，如果两个文件的URL不同，但文件的内容数据实质相同，那么该文件的内容摘要就是相同的，进而，如果该文件此前已经在边缘节点中缓存过了，那么后续即便是客户端设备再发来一个不同的文件下载地址URL，只要该文件的内容摘要和缓存中的一致，那么边缘节点也不会再去数据源节点重复下载该文件，而是直接根据该文件的内容摘要从缓存中找到该文件提供给客户端设备。由此，一方面减少了缓存中的重复数据，另一方面也提高了为客户端设备下载文件的效率。

进一步，边缘节点通过代理集群从数据源节点获取文件，当文件较大时，可以逐个部分的从数据源节点获取所请求文件的各部分，并同时向客户端设备传输所请求文件中已获取的部分，即非阻塞模式的回源，可以实现边缓存边让客户端设备下载。避免了使用CDN时，需要等到整个文件完全缓存才能下载的问题，整个过程客户端设备不用等待。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的数据下载系统示意图;

图2示出了根据本发明一个实施例的用于提供文件下载地址的管理设备示意图;

图3示出了根据本发明一个实施例的缓存器中的缓存逻辑示意图；

图4示出了根据本发明一个实施例的电信至网通的代理集群示意图；

图5示出了根据本发明一个实施例的数据下载系统示意图;

图6示出了根据本发明一个实施例的用于提供文件下载地址的管理方法流程图；以及

图7示出了根据本发明一个实施例的用于数据下载系统中的下载管理方法流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

请参阅图1，其为根据本发明一个实施例的数据下载系统示意图。该下载系统包括第一运营商网络的边缘节点100、第二运营商网络的边缘节点200、第一运营商网络至第二运营商网络的代理集群300、第二运营商网络至第一运营商网络的代理集群400、第一运营商网络的数据源节点500以及第二运营商网络的数据源节点600。此外，图中还示出了与该数据下载系统有数据交互的第一运营商网络的客户端设备700和第二运营商网络的客户端设备800。应当注意的是，该系统中包括的边缘节点、数据源节点、代理集群等都可以是一个或多个。

第一运营商网络的边缘节点100和第二运营商网络的边缘节点200中均包括下载管理设备110，该下载管理设备110具体包括缓存器102、解析器104、查找器106以及回源器108。第一运营商网络至第二运营商网络的代理集群300具体包括边缘侧第一运营商网络代理集群302、第一传输通道304以及源节点侧第二运营商网络代理集群306。第二运营商网络至第一运营商网络的代理集群400具体包括边缘侧第二运营商网络代理集群402、第二传输通道404以及源节点侧第一运营商网络代理集群406。第一运营商网络的数据源节点500包括数据源节点1、数据源节点2以及数据源节点n等多个处于第一运营商网络中的数据源节点。第二运营商网络的数据源节点600包括数据源节点1、数据源节点2以及数据源节点n等多个处于第二运营商网络中的数据源节点。

由于第一运营商网络的边缘节点100和第二运营商网络的边缘节点200中包括的下载管理设备110结构相同，数据处理流程也完全一样，仅仅是两个边缘节点所处的运营商网络不同，负责连接不同运营商网络的客户端设备，所以下面主要以第一运营商网络的边缘节点100的工作原理为例进行说明，第二运营商网络的边缘节点200的内部结构和工作原理参考第一运营商网络的边缘节点100的相关实施例内容即可，不再赘述。

在本发明的一个实施例中，某客户端设备700连接边缘节点100请求下载文件，具体而言，客户端设备700向边缘节点100发送一个文件下载请求，该下载请求包括所请求文件的下载地址，解析器104在获得文件下载请求后，根据该文件下载请求的下载地址解析出所请求的文件的内容摘要。在下载请求中包含所请求文件的下载地址，下载地址最常见的是所请求文件的URL（Uniform Resource Locator，统一资源定位符）。在本发明的一个实施例中，客户端设备700发给第一运营商网络的边缘节点100的所请求文件的URL与现有技术中的URL不同，现有技术中的URL一般包括协议类型、存放文件的主机域名、路径和文件名，URL的一般格式为(带方括号[]的为可选项)：protocol://hostname[:port端口]/path/[;parameters][?query查询]#fragment片段；而在本发明实施例中所请求文件的URL除了包含以上常规URL内容以外，还包括所请求的文件的内容摘要。

例如，传统上，请求文件的现有常规URL为：

http://wsdl11.yunpan.cn/share.php?method=Share.download&xqid=XXXX&nid=XXXX&cqid=XXXX&fname=1.txt&e=XXXX&st=XXXXX。其中，XXXX代表文件路径及文件名的具体信息。

而在本发明实施例中，请求文件的URL为：

http://wsdl11.yunpan.cn/share.php?method=Share.download&fhash=4c9a055de0a290341abf7fff6a4d8c0f2af7f155&xqid=XXXX&nid=XXXX&cqid=XXXX&fname=1.txt&e=XXXX&st=XXXXX。

通过对比以上两个URL可知，第二个URL比第一个URL多了一部分内容，即：

“fhash=4c9a055de0a290341abf7fff6a4d8c0f2af7f155”，这部分内容即为所请求文件的内容摘要。文件的内容摘要主要是指针对文件的内容采用特定数据转换方法来生成可以对文件内容进行标识的数据，内容摘要计算算法例如为安全哈希演算sha系列算法（sha1、sha224、以及sha256等）中的一种、信息摘要演算MD系列算法（如md3、md4以及md5等）中的一种、以及本领域已知的其他算法。只要内容摘要能够作为文件内容的唯一标识，相同内容的文件对应内容摘要相同，不同内容的文件对应的内容摘要不同，所以可以生成这种内容摘要的方法都在本发明的保护范围之内。一般而言，通过文件的全部内容进行特定数据转换后生成的内容摘要的唯一标识性比较强，但是也不排除在某些情况下，只根据文件的部分关键内容所生成的内容摘要的唯一标识性也可以满足实际需求，这种情况下也是可行的。

文件的URL一般是文件在上传到数据源节点时生成的。下面结合一个例子，介绍客户端设备100向第一运营商网络的边缘节点100发出的下载请求中所请求文件的URL是如何获得的。请一并参考图2，其示出了根据本发明一个实施例的用于提供文件下载地址的管理设备示意图，该管理设备210包括资源定位器212、摘要生成器214以及下载地址生成器216。该管理设备210可以设置于相应的数据源节点中，比如第一运营商网络的数据源节点500或者是第二运营商网络的数据源节点600，也可以独立于数据源节点之外设置。当管理设备210独立于数据源节点设置时，相当于各数据源节点基本仅作为文件存储服务器，而管理设备210则作为文件存储之外、负责文件相关管理、维护等工作的管理设备，但是管理设备210各数据源节点之间可以相互通信，能够获得彼此所需的各种信息。

具体而言，一方面，当某个文件上传到某个数据源节点之后，管理设备210中的资源定位器212就可以获得该文件在这个数据源节点上的存储路径，进而根据该存储路径生成文件的资源定位信息，即相当于生成该文件URL中路径和文件名这部分的内容，例如生成前面那个URL实例中的这部分内容:wsdl11.yunpan.cn/share.php?method=Share.download&xqid=XXXX&nid=XXXX&cqid=XXXX&fname=1.txt&e=XXXX&st=XXXXX。

另一方面，管理设备210中的摘要生成器214可以通过数据源节点知道该文件的具体内容，进而利用各种内容摘要计算方法计算该文件的内容以生成文件的内容摘要，前面已经介绍过文件内容摘要的各种具体实现方案，此处不再赘述。例如生成前面那个URL实例中的这部分内容：

fhash=4c9a055de0a290341abf7fff6a4d8c0f2af7f155。

此后，管理设备210中的下载地址生成器216根据资源定位器212提供的该文件的资源定位信息和摘要生成器214提供的该文件的内容摘要，生成该文件完整的下载地址，如URL，在该URL中至少包括该文件的资源定位信息和该文件的内容摘要。例如生成给前面那个URL实例中的完整URL：

http://wsdl11.yunpan.cn/share.php?method=Share.download&fhash=4c9a055de0a290341abf7fff6a4d8c0f2af7f155&xqid=XXXX&nid=XXXX&cqid=XXXX&fname=1.txt&e=XXXX&st=XXXXX。

由此可以看出，通过管理设备210可以为各种已经上传到某个数据源节点的文件生成对应的下载地址，如URL。进而，当客户端设备100需要下载某个文件时，就可以通过点击网站上的该文件或者查看该文件的URL等多种方式获得该文件的下载地址，然后向边缘节点发送包括该下载地址的下载请求。从而使得第一运营商网络的边缘节点100等边缘节点获得客户端设备100所请求的文件的URL,而且该URL中不仅包括常规的URL参数，还包括所请求文件的内容摘要。由此可见，本质上，边缘节点100获得的客户端设备700所请求文件的URL是管理设备210所提供的。

在本发明的一个实施例中，为了更好的保证数据传输的安全性，管理设备210在为文件生成URL的同时，还可以根据预置的签名生成方式及文件URL的全部内容或部分关键内容生成签名，比如根据URL中的文件内容摘要、文件存储路径等关键信息生成签名，当有客户端设备700需要下载该文件时，将文件URL和对应的签名一起提供给客户端设备700，进而客户端设备700向边缘节点100发送下载请求时包括文件URL和对应的签名。边缘节点100维护与管理设备210相同的签名生成方式，在边缘节点100接收到客户端设备700的文件下载请求后，解析器104根据所请求的文件URL以及预置的签名生成方式，自行生成该文件URL对应的签名，将自行生成的该签名与客户端设备700发送的文件下载请求中携带的签名对比，如果一致，则判断URL没有被修改，进行后续下载文件的相关处理；如果不一致，则说明客户端设备700发送的文件URL内容已经被修改，例如可能是被恶意篡改了URL中的文件内容摘要，进而会向客户端设备700返回错误或非法提示，不再进行后续相关的文件下载处理。

前面已经提到，边缘节点100的解析器104在接收到客户端设备700的下载请求后，还用于根据该文件下载请求的下载地址解析出所请求的文件的内容摘要。进而，边缘节点100中的查找器106根据解析器104解析出的所请求文件的内容摘要在缓存器102中查找，如果查找到所请求的文件，则直接将所请求的文件传输至客户端设备700，无需再去数据源节点获取该文件。

缓存器102缓存了从各数据源节点（如第一运营商网络的数据源节点500以及第二运营商网络的数据源节点600等各数据源节点）获得的各个文件以及各个文件的内容摘要。在本发明的一个实施例中，如果客户端设备700所请求的文件在缓存器102中有，则直接将缓存器中的该文件提供给客户端设备700；如果缓存器102中没有，就需要到相关的数据源节点去下载，从数据源节点获得所请求的文件后，一方面缓存到缓存器102以便后续使用，另一方面提供给客户端设备700。

通过上面的过程可以看出，缓存器102中存储的各个文件都是从数据源节点获得的。而且，由于解析器104可以解析出文件的内容摘要，如果缓存器102中没有该内容摘要对应的文件，就会根据文件下载请求从相关的数据源节点获取，而文件下载请求的下载地址中就包含文件的内容摘要，因此缓存器102在从数据源节点获得该文件后，就已经知道该文件对应的内容摘要是什么，进而缓存器102中就会缓存该文件以及该文件的内容摘要。前面提过，文件的内容摘要有多种具体实现方案，比如可以是文件的sha1，也可以是MD5。此外，由于sha1一般比较长、但唯一标识性更好，MD5比较短、更利于存储，因此，可以将sha1和MD5结合起来使用。比如，在所请求文件的URL中记录的文件内容摘要是sha1,但是缓存器102可以对sha1再进行一次数据转换，生成更短的hash值，即MD5，然后在缓存中存储的是文件以及文件对应的MD5，将这个MD5作为在缓存器102中查找文件数据的索引关键词key，如图3所示根据本发明一个实施例的缓存器中的缓存逻辑示意图。

可选的，缓存器102还可以为各文件设置缓存有效时间，因为缓存容量是有限的，通过设置缓存有效时间，可以及时清除长期不用的文件对缓存的占用。此外，还可以判断文件是否需要缓存，如果有些文件不适合缓存，即使从数据源节点获得了所需文件，缓存器108也不会对其进行缓存，后续如果有客户端设备700再请求该文件，边缘节点100会再从数据源节点获取文件提供给客户端设备700。另外，缓存器102还可以维护一个禁止下载名单，如果客户端设备700所请求的文件的内容摘要在该禁止下载名单中，则边缘节点100既不会从缓存器102中查找该文件发送给客户端设备700，也不会通过向数据源节点获取该文件发送给客户端设备700，而是告知客户端设备700该文件禁止下载。

由于缓存器102具有前面所说的缓存逻辑，因此查找器106可以根据所请求文件的内容摘要在缓存器102中进行查找，是否存在与文件内容摘要对应的文件，如果查找到，就直接将缓存中的该文件发送给客户端设备700。

应当注意的是，一般每个运营商网络都会有多个边缘节点，又会存在多个运营商网络，缓存器102的缓存逻辑可以是每个运营商网络的所有边缘节点共同维护一个，例如所有电信边缘节点共同维护一个缓存逻辑，即每个电信边缘节点获得的文件都存在同一个逻辑上的缓存器102中，进而该缓存器102中缓存的文件可以为所有电信边缘节点使用，即查找器106可以在这个所有电信边缘节点共同维护的缓存器102中去查找所需的文件。此外，还可以是以区域为单位，即同一个运营商的某个区域的多个边缘节点共同维护一个缓存器102，比如北京的多个电信边缘节点共同维护一个缓存器，上海的多个电信边缘节点共同维护另外一个缓存器，北京的电信边缘节点可以在北京的缓存器中查找是否有所需的文件，如果没有查找到，就认为没有，只能去数据源节点获取；上海的电信边缘节点可以在上海的缓存器中查找是否有所需的文件，如果没有，也只能再去数据源节点获取。再或者，还可以是每个边缘节点都单独维护一个缓存逻辑，即各自维护各自的缓存器102，每个边缘节点只能查找自己的缓存器，如果没找到，就需要到数据源节点去获取文件。总之，缓存器102的缓存逻辑可以根据实际需要进行不同设置，这些都在本发明的保护范围之内。

如果查找器106根据文件的内容摘要在缓存器102中没有查找到对应的文件，则通知回源器108，进而回源器108根据回源表和从所请求文件的下载地址从相关的数据源节点获取所请求的文件，并传输述客户端设备700，并且将所请求的文件提供给缓存器102进行缓存。具体而言，回源器108中维护一个回源表，该回源表中记录有文件的内容摘要和/或数据源节点编号，以及数据源节点地址之间的对应关系。

所谓数据源节点编号，可以理解为是数据源节点服务器或服务器集群的编号，仍然以前面的URL实例为例说明：

http://wsdl11.yunpan.cn/share.php?method=Share.download&fhash=4c9a055de0a290341abf7fff6a4d8c0f2af7f155&xqid=XXXX&nid=XXXX&cqid=XXXX&fname=1.txt&e=XXXX&st=XXXXX。该URL中“wsdl”后面的“11”就是数据源节点的编号，通过该标号可以在回源表中找到与该编号对应的主机地址，比如数据源节点的具体IP地址。如果该标号对应的是一个数据源节点的集群，那么通过该编号可以在回源表中查到多个数据源节点的主机地址，进而回源器108可以从其中的任何一个主机获得所需的文件。

前面提到，由于回源表中也可以保存文件的内容摘要和存放该文件的数据源节点地址之间的对应关系，因此，还可以利用所请求文件的内容摘要查找数据源节点的地址。在回源表中，同一个文件的内容摘要也可能对应着多个数据源节点地址，回源器108从中选择一个地址到相应的数据源节点去获取所需的文件。

无论是根据所请求文件的URL中的数据源节点编号查找存储该文件的数据源节点，还是根据所请求文件的内容摘要查找存储该文件的数据源节点，如果只找到一个数据源节点存储有所请求的文件，则直接根据回源表提供的该数据源节点地址去获取文件数据。如果找到多个数据源节点，则可以根据实际需要有多种选择方式。例如，可以优先从同一运营商的数据源节点获取所需的文件，如客户端设备700是第一运营商网络的，边缘节点100也是第一运营商网络的，那么，如果查找到的存储所需文件的多个数据源节点中既有第一运营商网络的数据源节点也有第二运营商网络的数据源节点，那么回源器108优先选择从第一运营商网络的数据源节点获取所需的文件。再例如，可以考虑存储所需文件的多个数据源节点的负载状况，即根据负载均衡的原理选择负载相对最轻的一个数据源节点获取所需文件。

回源器108维护的回源表中的内容，可以根据从各个数据源节点获取的信息生成。例如，每当有文件上传到某个数据源节点时，都会更新一条存储记录到回源表，该条记录中记录着该文件的内容摘要和/或存储该文件的数据源节点编号，以及对应的数据源节点的具体地址，进而，回源表中便可以记录各个文件以及存储该文件的数据源节点的地址信息。回源表不限于存储在边缘节点100中，也可以存储在其他专门的管理设备中，只要数据源节点能够和边缘节点100或者该专门的管理设备进行通信，使得回源表中的信息能够根据数据源节点存储文件的更新而更新，边缘节点100中的回源器108能够及时获取到回源表中的信息即可。前面提到，回源器108可以仅根据所请求文件的URL中的数据源节点编号查询相关的数据源节点地址，也可以仅根据所请求文件的内容摘要查询相关的数据源节点地址，因此对应的，回源表中也可以仅记录数据源节点编号和数据源节点地址之间的关联关系，或者仅记录文件的内容摘要和数据源节点地址之间的关联关系。当然，还可以优先使用数据源节点编号查询相关数据源节点地址，如果查找不到合适的，比如同一运营商网络的，再继续通过文件的内容摘要继续查询是否还有其他同一运营商网络的存储该文件的数据源节点，这种情况下对应的，回源表中就需要同时记录数据源节点编号、文件的内容摘要以及数据源节点地址之间的对应关系。

回源器108可以包括数据源查询模块、直接回源模块、代理回源模块以及缓存通知模块。具体而言，如果数据源查询模块根据已知的回源表和文件下载请求的下载地址，具体是根据回源表和根据下载地址得到的数据源节点编号或者是文件的内容摘要，查找到存储该文件的数据源节点与边缘节点100是同一运营商网络的，比如是第一运营商网络的数据源节点500，则直接回源模块将文件下载请求转发给查找到的数据源节点500，从该数据源节点500获取所需文件。由于边缘节点100和数据源节点500都是第一运营商网络的节点，因此他们之间直接进行通信速度很快，无需通过代理集群，所以可以直接连接下载。同时，缓存通知模块通知缓存器102对通过直接回源模块获取到的所请求的文件进行缓存。

如果第一运营商网络的边缘节点100中的数据源查询模块，在回源表中查找不到与边缘节点100属于同一运营商网络的数据源节点存储有所请求的文件，只找到第二运营商网络的数据源节点600存储了所请求文件，那么代理回源模块通过第一运营商网络至第二运营商网络的代理集群300从第二运营商网络相关的数据源节点600获取所请求的文件。同时，缓存通知模块通知缓存器102对通过代理回源模块获取的所请求的文件进行缓存。

为了更好的描述代理回源模块如何通过第一运营商网络至第二运营商网络的代理集群300从第二运营商网络的数据源节点600获取所请求的文件，下面先介绍下代理集群300的具体结构。代理集群300包括边缘侧第一运营商网络代理集群302、源节点侧第二运营商网络代理集群306，以及第一传输通道304。例如，图4所示的根据本发明一个实施例的电信至网通的代理集群示意图。该代理集群包括电信代理集群、网通代理集群，以及两个代理集群之间的光纤传输通道。其中电信代理集群412相当于边缘侧第一运营商网络代理集群302，网通代理集群416相当于源节点侧第二运营商网络代理集群306。电信代理集群412通过电信出口与电信下载节点（即电信边缘节点）进行通信，网络代理集群416通过网通出口与网通数据源节点进行通信。

首先，第一运营商网络的缘边节点100的回源器108根据客户端设备700的文件下载请求以及查找到的数据源节点600的地址，向代理集群300中的边缘侧第一运营商网络代理集群302发送请求从数据源节点600下载文件的请求，然后该边缘侧第一运营商网络代理集群302通过第一传输通道304，一般都是光纤，将文件下载请求传输至源节点侧第二运营商网络代理集群306。进而，源节点侧第二运营商网络代理集群306再向相关的第二运营商网络的数据源节点600发送文件下载请求，从该数据源节点600获得所请求的文件。源节点侧第二运营商网络代理集群306从数据源节点600获得了所请求的文件后，再将所请求的文件通过第一传输通道304传输至边缘侧第一运营商网络代理集群302，进而再由边缘侧第一运营商网络代理集群302将该文件传输给边缘节点100的代理回源模块，最终边缘节点100的代理回源模块108将该文件返回至客户端设备100。至此，第一运营商网络的客户端设备700通过第一运营商网络的边缘节点100、第一运营商网络至第二运营商网络的代理集群300从第二运营商网络的数据源节点成功下载了所请求的文件。

第二运营商网络至第一运营商网络的代理集群400的结构与第一运营商网络至第二运营商网络的代理集群结构雷同，故不再赘述，仅简单介绍。代理集群400包括边缘侧第二运营商网络代理集群402，接收来自第二运营商网络的边缘节点200的文件下载请求，以及向第二运营商网络的边缘节点200返回所请求的文件。第二传输通道404从边缘侧第二运营商网络代理集群402向源节点侧第一运营商网络代理集群406传输信息，以及从源节点侧第一运营商网络代理集群406向边缘侧第二运营商网络代理集群402传输信息；源节点侧第一运营商网络代理集群406根据通过第二传输通道404接收的来自边缘侧第二运营商网络代理集群402的文件下载请求，向第一运营商网络相关的数据源节点500发送文件下载请求，以及接收第一运营商网络相关的数据源节点500返回的所请求的文件，并通过第二传输通道404传输至边缘侧第二运营商网络代理集群200。

通过上面的描述可知，第一运营商网络的边缘节点100中的回源器108可以从数据源节点（如第一运营商网络的数据源节点500或第二运营商网络的数据源节点600）获取到客户端设备700所需的文件，并传输给客户端设备700。在本发明的一个实施例中，回源器108可以逐个部分地从数据源节点获取所请求的文件的各部分，并同时向客户端设备700传输该文件中所获取的部分，直到完全获取了该文件为止。具体而言，当数据源节点向边缘节点100中的回源器108返回文件标头header信息后，边缘节点100随即将该header信息返回给客户端设备700，客户端设备100获得header信息后便知道了所请求下载的文件的大小，然后会保持与边缘节点100的链接，等待并接受边缘节点返回的数据，直到下载整个文件为止。边缘节点100在连接到数据源节点后，会持续从数据源节点获得文件的内容数据，同时持续将获得内容数据直接发送给客户端设备700，直到该文件传输完毕为止。边缘节点100在从数据源节点获得整个文件之后，会将header信息和文件内容放入缓存中。

由此可以看出，边缘节点100可以一边从数据源节点获得所请求的文件，一边向客户端设备700传输已经获取到的该文件的部分内容，而不需要等边缘节点100完全从数据源节点下载到整个文件内容之后，再开始向客户端设备700传输该文件。此种情况下，边缘节点100中的回源器108可以看做是一个非阻塞回源器。

在本发明的一个实施例中，下载管理设备110可以通过varniash缓存服务器予以实现，或者说边缘节点的全部或部分通过varniash缓存服务器实现。通过varniash缓存服务器可以实现在从数据源节点下载文件的过程中，同步向客户端设备传输文件，即具有非阻塞回源器。具体请参阅图5，其示出了根据本发明一个实施例的数据下载系统示意图，其中，电信下载节点512是图1中第一运营商网络的边缘节点100的一个具体实例，电信下载节点512包括多个varniash节点；网通下载节点514是图1中第二运营商网络的边缘节点200的一个具体实例，网通下载节点514也包括多个varniash；电信—>网通代理集群516是图1中第一运营商网络至第二运营商网络的代理集群300的一个具体实例，其可以包括代理集群1、代理集群2等多个代理集群，彼此可以互为备份；网通->电信代理集群518是图1中第二运营商网络至第一运营商网络的代理集群400的一个具体实例，其也包括代理集群1、代理集群2等多个代理集群，可以互为备份；电信数据源520是图1中第一运营商网络的数据源节点500的一个具体实例，其可以包括多个数据源节点；网络数据源522是图1中第二运营商网络的数据源节点600一个具体实例，其可以包括多个数据源节点。每个varniash节点都对应的一组代理集群，因此利用Varnish节点自身的failover（失效备份）机制，可以在某个代理集群故障时，自动切换到其他的代理集群，从而降低了服务不可用的风险。

请参阅图6，其示出了根据本发明一个实施例的用于提供文件下载地址的管理方法流程图。

该管理方法始于步骤S610，在步骤S610中，首先根据文件在数据源节点中的存储路径生成该文件的资源定位信息。当某个文件上传到某个数据源节点之后，数据源节点或者其他与数据源节点能够相互通信的管理设备，就可以获得该文件在这个数据源节点上的存储路径，进而根据该存储路径可以生成文件的资源定位信息，即相当于生成该文件URL中的路径和文件名这部分内容。该步骤可以通过图2中的资源定位器212执行，相关技术可以参考前述各实施例中有关资源定位器212的描述，此处不再赘述。

一方面通过步骤S610生成文件的资源定位信息，另一方面，在步骤S620中，对该文件的内容采用特定数据转换生成文件的内容摘要。文件的内容摘要本质上是文件内容的标识信息，文件内容摘要与文件数据一一对应，不同内容的文件，内容摘要也不同。该步骤可以通过图2中的摘要生成器214实现，相关技术可以参考前述各实施例中有关摘要生成器214的描述，此处不再赘述。

应当注意的是，步骤S610和步骤S620之间的顺序是可以调整的，例如步骤S610可以在步骤S620之前、之后或者与步骤S620同时执行。

在通过步骤S610获得文件的资源定位信息，以及通过步骤S620获得文件的内容摘要之后，在步骤S630中，至少根据文件的资源定位信息和文件的内容摘要，生成文件的下载地址，如URL，该下载地址中至少包括文件的资源定位信息和文件的内容摘要。至此，文件的下载地址就生成了，此后，可以提供给需要下载该文件的客户端设备进行使用。例如，客户端设备在网站上点击某个文件或文件列表需要下载该文件时，即可获得该文件的URL，进而，后续客户端设备可以根据该下载地址向边缘节点发送文件下载请求，从而使边缘节点获得该文件的URL，该URL中不仅包括文件的存储路径等资源定位信息，还包括文件的内容摘要。该步骤可以通过图2中的下载地址生成器216实现，相关技术可以参考前述各实施例中有关下载地址生成器216的描述，此处不再赘述。

接着请参看图7，其示出了根据本发明一个实施例的用于数据下载系统中的下载管理方法流程图。该数据下载系统可以包括前面各实施例描述的边缘节点和数据源节点，进一步还可以包括前面各实施例描述的代理集群。

该下载管理方法始于步骤S710，在步骤S710中，边缘节点获得来自客户端设备的文件下载请求，并根据该文件下载请求的下载地址解析出所请求的文件的内容摘要。在前面图6给出的实施例流程中已经介绍过，客户端设备可以获得需要下载的文件的URL，而且该URL中还包含文件的内容摘要，因此客户端设备向边缘节点发送下载请求时，下载请求中的下载地址URL中会包含所请求文件的内容摘要。

在边缘节点通过步骤S710获得客户端设备的下载请求，并且根据下载请求解析出所请求文件的内容摘要之后，在步骤S720中，边缘节点根据所请求的文件的内容摘要在缓存中查找是否存在所请求的文件。如果是，则进入步骤S730：从缓存中获取所请求的文件传输至客户端设备。如果否，即在缓存中不没有所需的文件，则进入步骤S740：边缘节点从所请求的文件相关的数据源节点获取所请求的文件，并传输至客户端设备。

在一个实施例的步骤S740中，边缘节点可以逐个部分地从数据源节点获取所请求的文件的各部分，并同时向客户端设备传输所请求的文件中所获取的部分，直到完全获取了所请求的文件为止。通过这种无阻塞的回源方式，可以使边缘节点不必等从数据源节点获得整个文件之后再传输给客户端设备，可以在从数据源节点获得所请求的文件的过程中，同时向客户端设备传输，从而进一步提高了文件的下载速度。

在一个实施例的步骤S740中，为了进一步提高下载效率，如果边缘节点和数据源节点不是同一运营商网络的节点，那么边缘节点还可以通过代理集群从数据源节点获得所请求的文件，例如，数据下载系统还包括第一运营商网络至第二运营商网络的代理集群。步骤S740具体包括：首先边缘节点根据已知的回源表以及所请求的文件的下载地址查询所请求的文件相关的数据源节点；当边缘节点为第一运营商网络的边缘节点，并且查询到所请求的文件相关的数据源节点包括该第一运营商网络的数据源节点时，直接从该第一运营商网络的数据源节点获取所请求的文件；当边缘节点为第一运营商网络的边缘节点，并且查询到所请求的文件相关的数据源节点是第二运营商网络的数据源节点时，则通过第一运营商网络至第二运营商网络的代理集群从第二运营商网络相关的数据源节点获取所请求的文件。

对于边缘节点直接从同一运营商网络的数据源节点获取所请求的文件过程比较简单，不再详述，下面主要介绍下通过代理集群从非同一运营商网络的数据源节点获取所请求文件的过程。具体而言，第一运营商网络至第二运营商网络的代理集群包括边缘侧第一运营商网络代理集群、传输通道和源节点侧第二运营商网络代理集群，首先，边缘侧第一运营商网络代理集群接收来自第一运营商网络的边缘节点的文件下载请求，并通过传输通道传输至源节点侧第二运营商网络代理集群；源节点侧第二运营商网络代理集群在接收到文件下载请求后，据此向第二运营商网络相关的数据源节点发送文件下载请求，并接收该第二运营商网络相关的数据源节点返回的所请求的文件，以及将该文件通过传输通道传输至边缘侧第一运营商网络代理集群；进而，该边缘侧第一运营商网络代理集群再将该文件传输至第一运营商网络的边缘节点。

当边缘节点通过步骤S740获得客户端所请求文件的同时或者之后，在步骤S750中，将该文件的内容摘要以及从数据源节点获得的该文件内容进行缓存，以便后续再有下载该文件的下载请求时，边缘节点不需要再去数据源节点获取文件，直接通过步骤S730从自己的缓存中将该文件传输给客户端设备即可。通过步骤S750的不断积累，边缘节点缓存中的文件越来越多，在很大程度上能够为客户端设备直接提供所请求的文件，而无需再去数据源节点进行下载，由此提高的文件的下载效率，也减少了与数据源节点之间的通信次数，并减轻了数据源节点的负载负担。

在上述数据处理过程中，步骤S710可以通过图1中的解析器104执行，步骤S720和S730可以通过图1中的查找器106执行，步骤S740可以通过图1中的回源器108执行，步骤S750可以通过图1中的缓存器102执行，而且以上边缘节点执行的各步骤可以通过varniash缓存服务器执行。相关技术实现可以参考前述各实施例中对应部件的描述，此处不再赘述。

通过以上本发明的各实施例可以看出，边缘节点根据从所请求文件下载地址解析出的文件内容摘要作为索引关键词，在缓存中查询是否已经存储了所请求的文件，而不是根据文件的整个URL作为索引查询，同理，在缓存中存储文件时也是根据文件的内容摘要是否相同判断是否为同一份文件，即文件的内容摘要是文件内容数据的标识，只要文件的内容摘要不同文件数据本身就不同，反之，只要文件的内容摘要相同就说明文件数据本身就是同一个。因此，如果两个文件的URL不同，但文件的内容数据实质相同，那么该文件的内容摘要就是相同的，进而，如果该文件此前已经在边缘节点中缓存过了，那么后续即便是客户端设备再发来一个不同的文件下载地址URL，只要URL中该文件的内容摘要和缓存中的一致，那么边缘节点也不会再去数据源节点重复下载该文件并缓存，而是直接根据该文件的内容摘要从缓存中找到该文件提供给客户端设备。由此可以看出，一方面减少了缓存中的重复数据，另一方面也提高了为客户端设备下载文件的效率，同时减少了边缘节点到数据源节点的通信次数，进而减少了数据源节点的负载以及代理集群的带宽消耗。

进一步，有些情况下，文件URL没有发生变化，但实质文件的内容数据已经发生了更新。如果采用现有技术中只根据不携带文件内容摘要信息的URL作为查询缓存文件的索引关键词，那么很可能将实质内容数据已经发生变化、URL没变的文件发送给客户端设备，进而导致客户端设备下载不到最新、最正确的文件。而采用本发明实施例的方案，由于是根据文件URL中的文件内容摘要判断缓存中是否存在该文件，如果URL没变、实质数据内容变化的话，那么在通过文件内容摘要查询缓存时，已经找不到对应的文件了，于是就会自动从数据源节点获取最新的文件提供给客户端设备，即缓存中的文件及时得到了更新。换而言之，本发明实施例中缓存的更新是由边缘节点主动发起的，而不是像现有CDN网络中由数据源节点发起的，因此避免了使用现有CDN数据缓存更新效率低的问题。

再进一步，边缘节点通过代理集群从数据源节点获取文件，当文件较大时，可以利用边缘节点服务器（如Varnish）的Stream非阻塞模式，可以实现边缓存边让客户端设备下载。避免了使用CDN时，需要等到整个文件完全缓存才能下载的问题，整个过程客户端设备不用等待。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的管理设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (5)

1.一种用于提供文件下载地址的管理设备，包括：

资源定位器，被配置为根据文件在数据源节点中的存储路径生成所述文件的资源定位信息；

摘要生成器，被配置为对所述文件的内容采用特定数据转换生成所述文件的内容摘要；以及

下载地址生成器，被配置为至少根据所述资源定位器提供的所述文件的资源定位信息和所述摘要生成器提供的所述文件的内容摘要，生成所述文件的下载地址，所述下载地址中至少包括所述文件的资源定位信息和所述文件的内容摘要。

2.根据权利要求1所述的管理设备，所述下载地址生成器生成的所述文件的下载地址是所述文件的统一资源定位符ＵＲＬ。

3.一种用于提供文件下载地址的管理方法，包括：

根据文件在数据源节点中的存储路径生成所述文件的资源定位信息；

对所述文件的内容采用特定数据转换生成所述文件的内容摘要；

至少根据所述文件的资源定位信息和所述文件的内容摘要，生成所述文件的下载地址，所述下载地址中至少包括所述文件的资源定位信息和所述文件的内容摘要。

4.如权利要求3所述的管理方法，所述文件的下载地址是所述文件的统一资源定位符ＵＲＬ。

5.如权利要求3或4所述的管理方法，还包括：

将所述文件的下载地址提供给需要下载该文件的客户端设备。

Images