内容传送网络系统和能够在内容传送网络中操作的方法版权声明本专利文档包含受版权保护的内容。版权所有人不反对复制本专利文档或美国专利和商标局的文件中的任何相关材料，但是另外保留与版权有关的所有权利。相关申请本专利合作条约(“PCT”)申请与以下共有且共同未决的美国临时专利申请有关并且要求其优先权，其中的每一个的全部内容通过引用的方式完整地并入本文以用于所有目的：(1)于2011年12月14日递交的题为“ContentDeliveryNetwork”的美国申请No.61/570,448；以及(2)于2011年12月14日递交的题为“ContentDeliveryNetwork”的美国申请No.61/570,486。本申请与以下共有的美国专利和共同未决的专利申请有关并且要求其优先权，其中的每一个的全部内容通过引用的方式完整地并入本文以用于所有目的：1、于09/30/2002递交的、于10/26/2010公告的题为“ConfigurableAdaptiveGlobalTrafficControlAndManagement”的美国专利No.7,822,8712、于10/26/2007递交的、于12/28/2010公告的题为“Policy-BasedContentDeliveryNetworkSelection”的美国专利No.7,860,9643、于02/10/1998递交的、于02/06/2001公告的题为“OptimizedNetworkResourceLocation”的美国专利No.6,185,5984、于12/06/2001递交的、于11/25/2003公告的题为“InternetContentDeliveryNetwork”的美国专利No.6,654,8075、于10/31/2007递交的、于05/24/2011公告的题为“ControllingSubscriberInformationRatesInAContentDeliveryNetwork”的美国专利No.7,949,7796、于10/31/2007递交的、于05/17/2011公告的题为“ControllingSubscriberInformationRatesInAContentDeliveryNetwork”的美国专利No.7,945,6937、于03/13/2002递交的、于05/30/2006公告的题为“InternetContentDeliveryNetwork”的美国专利No.7,054,9358、于03/21/2009递交的题为“HandlingLong-TailContentInAContentDeliveryNetwork(CDN)”的美国公布的专利申请No.2009-02546619、于09/13/2010递交的题为“HandlingLong-TailContentInAContentDeliveryNetwork(CDN)”的美国公布的专利申请No.2010-033259510、于02/23/2009递交的、于09/06/2011公告的题为“Load-BalancingCluster”的美国专利No.8,015,29811、于09/13/2010递交的题为“Load-BalancingCluster”的美国公布的专利申请No.2010-0332664。
技术领域：
本发明涉及内容传送和内容传送网络。更具体地，涉及内容传送网络、以及支持内容传送和内容传送网络的系统、框架、设备和方法。附图说明在参照附图考虑以下描述和所附权利要求之后，本发明的其他目的、特征和特性以及结构的有关元件的操作方法和功能和部件组合和产品的经济性将变得更加显而易见，其中，所有附图形成了本说明书的一部分。图1示出了示例性内容传送网络(CDN)；图2和图3示出了CDN中的缓存群集站点；图4和图5示出了图2和图3的缓存群集站点中的缓存群集；图6示出了示例性缓存群集站点；图7示出了CDN的控制核心群集；图8和图9示出了内容传送网络的分层组织和CDN中的缓存的逻辑组织；图10示出了客户端与CDN之间的典型交互；图11示出了CDN中的请求-响应处理；图12A至图12C示出了多种数据结构；图13A是序列控制对象的逻辑描绘；图13B至图13D示出了序列和序列处理的示例；图14A至图14D示出了排序程序和处理程序的示例；图15A是示出了将缓存服务器添加至CDN的过程的流程图；图15B是示出了CDN中的示例性请求-响应处理的流程图；图15C示出了CDN中的多种缓存的操作；图16示出了在CDN中操作的示例性缓存服务器；图17是示出了示例性缓存服务器中用于请求-响应处理的主要功能模块的框图；图18和图19示出了由CDN使用的多种表格和数据库；图20A至图20C是描述示例性请求-响应处理流的流程图；图21A至图21H示出了示例性CDN及其操作的各个方面；图22示出了CDN的组件之间的交互；图23示出了典型的计算机系统；以及图24A至图24E、图25A至图25B以及图26描述了执行机构系统的各个方面。具体实施方式术语除非以其他方式使用，否则如本文所使用的，下面的术语或缩略词具有以下意义：CCS意味着客户配置脚本；CDN意味着内容传送网络；CNAME意味着规范名称；DNS意味着域名系统；FQDN意味着完全资格域名；FTP意味着文件传输协议；GCO意味着全局配置对象；HTTP意味着超文本传输协议；HTTPS意味着HTTP安全；IP意味着互联网协议；IPv4意味着互联网协议版本4；IPv6意味着互联网协议版本6；IP地址意味着在包括IPv4和IPv6的互联网协议中使用以识别诸如服务器等的电子设备的地址；MX意味着邮件交换；NDC意味着网络数据收集器；NS意味着名称服务器；QoS意味着服务质量；TCP意味着传输控制协议；URI意味着统一资源标识符；URL意味着统一资源定位符；以及VIP地址意味着虚拟IP地址。背景和概述内容传送网络——CDN——的主要目的是代表一个或更多个内容提供商优选地经由公共互联网高效地向客户机分发资源。CDN还可以提供用于在相反方向上——从客户端到源服务器——高效地发送内容的空中传输机制。终端用户(客户端)和内容提供商受益于使用CDN。通过使用CDN，内容提供商能够缓解其自己的服务器的压力。客户端通过能够以更少的延迟获得内容而受益。概述——结构图1示出了示例性CDN100，CDN100包括多个缓存102-1、102-2、……、102-m(统称为缓存102，单独称为缓存102-i)、会合机制/系统104-1…104-k(统称为会合机制/系统104，其由是一个或更多个会合机制104-j构成)、收集器机制/系统106(其是由一个或更多个收集器机制106-1…106-n构成)、以及控制核心108。CDN100还包括多种操作和/或管理机制109。如图2中所示，每一个CDN缓存102可以是包括一个或更多个缓存群集204的缓存群集站点202。缓存群集站点202可以包括路由机制206，路由机制206尤其用于提供去往/来自缓存群集202的数据。路由机制206可以执行诸如负载平衡等的多种功能，或者路由机制206可以仅传递去往/来自缓存群集204的数据。根据路由机制206的配置，路由机制206可以向多于一个缓存群集204传递输入数据。图3示出了具有p个缓存群集(标记为204-1、204-2、……、204-p)的示例性缓存群集站点202。如图4中所示，缓存群集204包括一个或更多个服务器208。缓存群集优选地包括诸如交换机等的路由机制210，路由机制210尤其用于提供去往/来自服务器208的数据。任何特定的缓存群集204中的服务器208可以包括缓存服务器212和/或流式传输服务器214。路由机制210向服务器208提供数据(优选地，分组数据)。优选地，路由机制210是以太网交换机。路由机制210可以执行诸如负载平衡等的多种功能，或者路由机制210可以仅传递去往/来自服务器208的数据。根据路由机制210的配置，路由机制210可以向多于一个服务器208传递输入数据。图5示出了包括k个服务器(标记为208-1、208-2、……、208-k)和交换机210’的示例性缓存群集204’。缓存群集站点的路由机制206可以与缓存器群集的路由机制210集成在一起或者位于同一位置处。图6示出了示例性缓存群集站点202”，该示例性缓存群集站点202”具有包括一个或更多个服务器208”的单个缓存群集204”。服务器208”可以是缓存服务器212”和/或流式传输服务器214”。如图6中的示例所示，缓存群集的路由机制210”和缓存群集站点的路由机制206”在逻辑上/功能上(以及可能在物理上)组合为单个机制(如图中的虚线所示)。缓存服务器站点可以是负荷均衡群集，例如，如于2009年2月28日递交的题为“Load-BalancingCluster”的美国公布的专利申请No.2010-0332664以及于02/23/2009递交的、于09/06/2011公告的题为“Load-BalancingCluster”的美国专利No.8,015,298中所述，其中每一个的全部内容通过引用的方式完整地并入本文以用于所有目的。在当前优选的实现中，缓存群集服务器208中的连接到特定交换机的一些缓存群集服务器208将共享相同的虚拟IP(VIP)地址。(每一个缓存群集服务器208还将优选地具有不同且唯一的IP地址。)在这些当前优选的实现中，为了CDN控制的目的，缓存群集的路由机制210和缓存群集站点的路由机制206在逻辑上/功能上(并且优选地在物理地)组合为单个机制——交换机。在这些实现中，缓存群集站点是指连接到(例如，插入到)交换机的所有机器。在该缓存群集站点内，缓存群集是由共享相同的VIP集合的所有机器构成。在于09/13/2010递交的题为“Load-BalancingCluster”的美国公布的专利申请No.2010-0332664以及于02/23/2009递交的、于09/06/2011公告的题为“Load-BalancingCluster”的美国专利No.8,015,298中描述了示例性缓存群集204，其中每一个的全部内容完整地并入本文以用于所有目的。再次参照图1，如下面更详细解释的，会合系统104用于引导客户端资源请求。会合系统104优选地是使用DNS实现的，并且包括一个或更多个DNS名称服务器。会合机制104-j优选地是执行基于策略的域名解析的域名服务器。在于09/30/2002递交的、于10/26/2010公告的题为“ConfigurableAdaptiveGlobalTrafficControlAndManagement”的美国专利No.7,822,871以及于10/26/2007递交的、于12/28/2010公告的题为“Policy-BasedContentDeliveryNetworkSelection”的美国专利No.7,860,964中描述了示例性会合系统104，其中每一个的全部内容完整地并入本文以用于所有目的。控制核心机制108控制CDN的操作，并且在下面被更详细地描述。在物理上，控制核心优选地由地理分布的机器集合构成，这些地理分布的机器集合优选地经由高速通行链路连接。例如，五个机器位于纽约、旧金山、芝加哥、伦敦和法兰克福。在逻辑上，控制核心如包含配置数据的单个鲁棒的数据库/web服务器组合一样操作。图7示出了示例性的控制核心机制108，控制核心机制108由五个不同的组件或机器(在图中标记为CC1、CC2、CC3、CC4、CC5)构成。虽然使用五个组件或机器示出了控制核心，但是本领域技术人员在阅读本说明书之后将认识和理解的是，控制核心可以由包括控制核心的任何数量的组件或机器形成。奇数是优选的，这是因为使用组件或机器进行投票。较大的数量将使控制核心更有效，但是响应得更慢。仅具有一个机器是一种退化情况，该退化情况可能在非生产情形中有用。形成控制核心的组件或机器一起作为单个高效群集操作，并且在大多数附图中被示出为单个实体。应当理解的是，与控制核心机制108的任何特定的交互将可能与其组件机器中的仅一个进行。控制核心机制108在本文中还被称作控制核心群集108或控制核心108。虽然在图1中仅示出了一个控制核心108，但是应当清楚的是，CDN可以具有多于一个控制核心，其中，不同的控制核心控制CDN的不同方面或部分。可以通过一个或更多个域名来寻址控制核心108。为了该描述，域名control.fp.net将用于控制核心108。在优选的实现中，控制核心群集由五个(5个)不同的且地理分布的控制核心机制构成，并且作为具有五个(5个)IP地址的多宿主位置操作。因此，当客户端要求DNS服务器解析控制核心的域名(例如，control.fp.net)时，DNS服务器将返回与该名称相关联的五个IP地址中的一个或更多个。然后，客户端可以在这些地址之一处访问控制核心。应当清楚的是，与客户端与CDN服务器会合在一起的方式类似，DNS服务器将向客户端提供与“附近的”控制核心服务器(即，向对于该客户端而言的“最佳”或“最优”的控制核心服务器)的会合。换言之，CDN的内部组件(缓存服务器、控制核心等)可以使用与CDN外部的实体所使用以与CDN组件会合在一起的会合机制相同的会合机制。在一些情况下，多种控制核心机制可以具有相同的IP地址，在该情况下，路由表格可以将客户端导向“最佳”或“最优”的控制核心机制。这也可以使用任播IP地址来实现。层和组CDN可以具有分层组织的一个或更多个缓存层。图8示出了包括多个缓存层的内容传送网络100。具体地，图8的CDN100示出了j个缓存层(在附图中标记为层1、层2、层3、……、层j)。每一个缓存层可以包括多个缓存，这些缓存被组织为缓存组。缓存组可以与缓存群集站点或缓存群集(图2至图5的202、204)相对应。层1的缓存也被称作边缘缓存，并且层1有时也被称作“边缘”或“CDN的边缘”。层2缓存(当CDN中存在时)也被称作父缓存。例如，在图8的CDN100中，层1具有n个缓存组(标记为“边缘缓存组1”、“边缘缓存组2”、……、“边缘缓存组n”)；层2(父缓存的层)具有m个缓存组(第i个组被标记为“父缓存组i”)，并且层3具有k个缓存组，以此类推。优选地，每一个层具有相同数量的缓存组，但是这不是必须的。图9示出了图8的CDN中的缓存的逻辑组织/分组。在图9的示例性CDN100中，每一个缓存层具有相同数量(n个)的缓存组。本领域技术人员在阅读该描述之后将知道和理解的是，每一个缓存组可以具有相同或不同数量的缓存。此外，缓存组中的缓存数量可以动态地改变。例如，可以将额外的缓存添加至缓存组中以处理组上增加的负载。缓存组中的缓存可以是同构的或异构的，并且缓存组中的每一个缓存可以包括共享相同名称和/或网络地址的物理缓存群集。在于09/13/2010递交的的题为“Load-BalancingCluster”的共同未决且共同拥有的美国公布的专利申请No.2010-0332664以及于02/23/2009递交的、于09/06/2001公告的题为“Load-BalancingCluster”的美国专利No.8,015,298中描述了这种缓存的示例，其中每一个的全部内容通过引用的方式完整地并入本文以用于所有目的。相同层和相同组中的缓存可以称作对等体或对等缓存。通常，对于每一个层j，层j中的缓存可以是彼此的对等体，并且层j+1中的缓存可以称作父缓存。在一些情况下，不同组和/或不同层中的缓存也可以被认为是对等缓存。应当清楚的是，对等体的概念是灵活的，并且多个对等布置在本文中是可能的且被设想。典型的CDN仅具有一个或两个缓存层。仅具有一个层的CDN将仅具有边缘缓存，而具有两个层的CDN将具有边缘缓存和父缓存。(CDN最低限度应当具有至少一个缓存层——边缘缓存。)层中的缓存的分组可以基于例如以下各项中的一项或多项：其物理或地理位置、网络邻近、正在供应的内容的类型、组中的机器的特性等。例如，特定的CDN可以具有六个组——四个缓存组在美国，其中，组1针对西海岸，组2针对中西部，组3针对东北部，组4针对东南部；以及一个组针对欧洲，一个组针对亚洲。本领域技术人员在阅读该描述之后将认识和理解的是，缓存组可以与缓存群集或缓存群集站点相对应。特定的CDN缓存优选地处于仅一个缓存组中。通常，每一个层中的缓存中的一些或全部可以与另一层中的缓存中的一些或全部交换数据。因此，父缓存中的一些或全部可以与边缘缓存中的一些或全部交换信息，等等。为了简化，在附图(图8)中，每一个缓存层被示出为可操作地连接到其上方和下方的每一个层，并且层3被示出为可操作地连接到层1(边缘层)。然而，在一些CDN中，可能优选的是，特定层中的缓存只能与相同组中的其他缓存(即，与对等缓存)和/或与不同层中的相同组中的其他缓存交换信息。例如，在一些CDN中，边缘缓存组k中的边缘缓存可以相互交换信息，并且可以与父缓存组k中的所有缓存交换信息，等等。内容提供商的/客户的服务器(或多个服务器)也可以被称作源服务器。内容提供商的源服务器可以由内容提供商拥有和/或操作，或者内容提供商的源服务器可以是由诸如主机提供商等的第三方提供和/或操作的服务器。特定内容提供商的主机提供商也可以向该内容提供商提供CDN服务。关于特定的订户/客户资源，订户/客户的源服务器是特定资源的权威来源。更一般地，在一些实施例中，关于任何特定的资源(包括来自CDN中的元件/机器的资源)，该特定资源的权威来源有时被称作协同服务器。CDN还可以包括CDN源/内容缓存层，CDN源/内容缓存层可以用于缓存来自CDN的订户(即，来自CDN订户的各自源服务器)的内容。本领域技术人员在阅读该描述之后将知道和理解的是，CDN可以支持一个或更多个内容提供商或订户，即，CDN可以用作支持大量内容提供商或订户的共享基础设施。CDN源层也可以由多个缓存构成，并且这些缓存也可以被组织(物理上和逻辑上)为多个区域和/或组。CDN源层中的缓存根据需要或者提前地或显式地预填充地从内容提供商的/订户的源服务器获得内容。概述——操作图10示出了客户端110与CDN100之间的典型交互。在该情况下，CDN100代表内容提供商112供应内容(资源)。如上所述，CDN包括可以向客户端提供/供应来自其的内容的多个位置(例如，附图中未示出的缓存站点)。将特定客户端(或者客户端请求)与CDN中的特定位置相关联的过程被称作会合过程。当特定的客户端(例如，客户端110)想要获得某一内容(例如，特定的资源)时，通常(经由某一会合机制104)将该客户端导向“最佳”(或“最优”)的位置。如本文所使用的，位置可以是例如服务器、服务器站点、服务器区域、缓存群集、缓存群集站点等。位置甚至可以是另一CDN或网络或CDN100之外的服务器。关于图1至图7，“最佳”或“最优”位置可以是但不限于缓存群集站点、缓存群集、组、层、或者其某一组合。本领域技术人员在阅读该描述之后将认识和理解的是，“最佳”或“最优”位置的概念取决于多个因素，包括但不限于以下各项中的一些或全部：网络负载、CDN服务器和其他组件上的负载、客户端计算机的位置等等。“最佳”或“最优”位置的概念可以随当天时间、内容的类型、内容提供商的策略、CDN策略等而改变。本发明不以任何方式受限于确定CDN中的“最佳”或“最优”位置的方式。可以通过服务器选择机制来选择“最佳”或“最优”服务器，如美国专利No.6,185,598、No.6,654,807、No.7,949,779、No.7,945,693和No.7,054,935中所描述的，其中每一个的全部内容完整地并入本文以用于所有目的。在当前优选的实现中，服务器选择机制是DNS系统的一部分和/或使用DNS系统。在当前优选的实现中，会合系统104使用DNS系统并且集成到DNS系统中，如于09/30/2002递交的、于10/26/2010公告的美国专利No.7,822,871和于10/26/2007递交的、于12/28/2010公告的美国专利No.7,860,964中所述的，其中每一个的全部内容完整地并入本文以用于所有目的。客户端110的DNS系统114与CDN的会合机制104进行交互以将对资源的特定客户端请求与优选地CDN100中来自其的请求资源将被供应给客户端的特定位置相关联。“最佳”或“最优”位置可以由会合机制104作为与CDN中的一个或更多个位置或与不同的CDN或网络相对应的一个或更多个IP地址或CNAME(域名)来提供。参照图10，CDN100(其中，客户端110想要获得特定资源)的示例性使用如下：客户端计算机110与会合机制104进行交互，以确定获得来自其的特定资源的“最佳”位置(在S1处)。当会合机制104集成到DNS系统中时，客户端的DNS系统114与CDN的会合机制104进行交互，以将客户端导向优选地CDN100中客户端可以获得(或尝试获得)来自其的资源的位置。当会合机制104集成到DNS系统中时，该请求(在S1处)可以是用于解析与特定资源相关联的域名的请求的一部分，并且会合机制可以向客户端提供CDN中的一个或更多个位置的一个或更多个IP地址或CNAME(在S2处)。如果会合机制提供(与多于一个“最佳”位置相对应的)多于一个IP地址，则客户端可以选择使用这些地址中的哪一个。在获得要获得来自其的特定资源的“最佳”位置之后，客户端计算机110然后请求来自CDN100中的位置的特定资源(在S3a处)。CDN100可能已经具有该位置处的特定资源的副本，在该情况下，CDN100向客户端计算机110提供(供应)资源(在S3b处)。如果CDN还未具有该位置处的特定资源的副本，则CDN尝试(从CDN中的另一位置或从内容提供商112(在S4a、S4b处))获得该位置处的副本。在(从CDN中的另一位置或从内容提供商112)获得资源之后，CDN100向客户端计算机110提供(供应)资源(在S3b处)。应当清楚的是，在一些情况下，与获取相反，可以在CDN中生成响应。这可以例如在从现有资源转换(例如，压缩/代码转换)的情况下发生，或者完全由(先前从内容提供商的源服务器提取的或者由控制核心作为属性配置的一部分提供的)脚本/进程生成。CDN还可以向内容提供商提供与代表其传送的资源有关的信息(例如，记录和性能数据)。因此，如图10中所示，CDN100可以向内容提供商112提供信息(在S5处)。为了简化上面的解释，图10仅示出了一个客户端计算机110、一个内容提供商112和一个CDN100。本领域技术人员在阅读该描述之后将认识和理解的是，典型的CDN可以代表多个内容提供商向多个客户端计算机提供内容。本领域技术人员在阅读该描述之后还将认识和理解的是，系统可以包括多个CDN，并且会合机制104可以使客户端请求被导向CDN中的不同CDN。例如，在美国专利No.7,822,871和No.7,860,964中描述了示例性会合机制104，其中每一个的全部内容通过引用的方式完整地并入本文以用于所有目的。如本文所使用的，术语“资源”和“内容”是指而不以任何方式限制于可以经由CDN提供给客户端计算机的任意和所有类型的资源和/或内容。资源和/或内容可以是包括任意比特序列的任何静态或动态数据项，而不论如何存储或发送这些比特，并且不论这些比特表示了什么。由CDN提供的资源可以包括表示另一资源的一些或全部的数据，包括以下各项中的一些或全部：文件、文件的一部分、数字消息、数字消息的一部分、数字图像、数字图像的一部分、视频信号、视频信号的一部分、音频信号、音频信号的一部分、软件产品、软件产品的一部分、存储器中的页面、网页；电影、以及电影的一部分。该列表是通过举例说明的方式给出的，而不旨在以任意方式是限制性的。图10示出了与CDN分离的客户端110。如下面将详细解释的，发明人认识到，CDN的各个组件本身可以用作关于CDN的客户端以获得CDN相关资源。因此，客户端可以是CDN元件或组件，例如，缓存。类似地，图10示出了与CDN分离的内容提供商112。如下面将详细解释的，发明人认识到，CDN的各个组件本身可以用作关于CDN的内容提供商，以向其他CDN组件提供CDN相关资源。因此，例如，如下面将进一步解释的，参照图1，当收集器机制106从缓存102获得信息时，该收集器机制106用作客户端，而缓存102是内容提供商。迄今已经围绕CDN的单独且不同的组件对CDN进行了描述。然而，应当理解的是，在CDN内，每一个对象(例如，要在CDN组件之间移动的所有数据)被视为web对象或资源，其中，例如，控制核心用作这些对象的“源层”。也即是说，每一个CDN对象具有URL(或由CDN使用的无论什么地址)，并且可以对每一个CDN对象进行请求、填充、无效、刷新等。每一个缓存具有它需要获得的知识(信息)，并且提供CDN对象。该方法允许CDN内的所有数据传输使用CDN自身。因此，CDN可以使用其自己的机制来处理CDN控制和/或管理相关信息(例如，控制核心数据)。因此，例如，任何CDN组件可以使用CDN来获得CDN数据。请求-响应处理在操作中，各个CDN组件(例如，缓存)接收对资源的请求，处理这些请求，并且提供响应(其可以包括例如所请求的资源、错误消息、或者在其他地方找到资源的指导)。图11示出了示例性CDN组件1102的请求-响应操作。虽然组件1102在附图中被标记为“服务器”，但是应当清楚的是，组件1102可以是缓存服务器或CDN的执行请求-响应处理的任何其他组件。如图中所示，客户端1103提出对服务器1102的资源的请求，并且接收针对该请求的响应。在处理该请求时，如下所述，服务器1102可以从一个或更多个其他数据源1110B获得信息。这些数据源1110B中的一些可以是其他CDN组件(例如，缓存1112或控制核心1116)。数据源1110B还可以包括源服务器1114，源服务器1114可以或可以不是CDN的一部分。应当清楚的是，客户端1103可以是另一CDN组件(例如，缓存)，或者它可以是CDN外部的客户端实体。服务器1102优选地支持HTTP/1.0和HTTP/1.1、以及HTTPS请求，但是不限于这些协议或者任何协议的任何特定版本。在网络工作组的请求注解：2616,June1999,“HypertextTransferProtocol--HTTP/1.1,”中定义了HTTP/1.1，其全部内容通过引用的方式完整地并入本文以用于所有目的。在网络工作组的请求注解：2818,May2000,“HTTPOverTLS,”中描述了HTTPS，其中每一个的全部内容通过引用的方式完整地并入本文以用于所有目的。除非另外专门声明，否则“HTTP”在该描述中用于指代任何版本或形式的HTTP请求，包括HTTP和HTTPS请求。本领域技术人员在阅读该描述之后将认识和理解的是，HTTPS在可能需要额外安全的情形中可能是优选的。还应当清楚的是，当在本文中提及HTTP请求时，可以在仍然利用CDN并且使用URL来给对象命名的同时使用可能包括专用协议的一些其他协议。服务器1102包括请求/响应机制1104(其优选地在服务器1102上通过软件结合硬件来实现)。请求/响应机制1104监听包括端口1106的多个配置的地址/端口上的请求。当提出请求时，请求/响应机制1104尝试识别与该请求相关联的客户。如本文所使用的，“客户”是被授权使其内容由服务器1102供应的实体。客户可以是外部实体，例如，CDN的订户，或者客户可以是另一CDN组件。为了确定请求是否与CDN的客户(或CDN自身)相关联，服务器1102需要与CDN的客户有关的至少一些信息。该信息可以作为全局数据1108存储在服务器1102上的数据库1106中。全局数据1108应当包括足够的数据来允许服务器1102拒绝请求(在不与客户相关联的资源请求的情况下)或者向客户端1103供应所请求的资源或者将客户端导向可以供应来自其的请求资源的另一源。如果服务器1102在客户端请求时不具有所需的全局数据1108，则服务器1102可以从数据源1110B(优选地，从控制核心1116或者从另一缓存)获得所需的全局数据1108。实际上，对于内部CDN数据而言，控制核心被认为是源服务器或协同服务器。如下所述，请求/响应机制1104可以执行作为请求/响应处理的一部分的客户特有的处理。为了执行客户特有的处理，请求/响应机制需要特定的客户特有的数据1110A。如果当前客户特有的数据1110A在请求/响应机制的数据库1106中不可用，则服务器1102可以从数据源1110B(优选地，从控制核心1116)获得所需的客户特有的数据(但是也可以从CDN中的另一缓存1112获得客户特有的数据)。对象、排序程序和处理程序由请求/响应机制1104执行的处理使用各种类型的对象，包括：注释对象、会话对象(sxn)和事务对象(txn)。参照图12A，注释对象1204是通用字符串密钥/值表格。图12B至图12C分别示出了会话对象(sxn1206)和事务对象(txn1208)。会话对象1206包含与特定的客户端会话(例如，客户端连接或内部启动(或引起)的会话)有关的信息。会话对象1206可以包含会话的分配上下文信息。事务对象(txn1208)通常与会话相关联，并且包含与单独的请求有关的信息。在会话期间，可以执行多个事务，并且在事务对象中承载与每一个事务有关的信息。例如，事务对象承载要满足的请求、针对响应的空间、与响应主体源自的位置有关的信息(例如，响应信道id)等。排序程序实质上是任务。排序程序使用序列控制对象，该序列控制对象由具有一个或更多个处理程序和处理程序参数的排序列表构成。图13A示出了示例性序列控制对象1301，示例性序列控制对象1301包括处理程序1302和处理程序参数1304。处理程序1302包括处理程序1302-1、1302-2、……、1302-n的排序列表。应当清楚的是，不是所有处理程序都需要参数，并且一些处理程序可以从其他位置获得其参数中的一些或全部。还应当清楚的是，序列控制对象可以仅具有单个处理程序和/或不具有参数。当运行时，排序程序按顺序调用其处理程序(实质上处理模块)。排序程序默认是双向的，使得在“进入”路径上按顺序并且在“离开”路径上按相反顺序调用(调取)排序程序的处理程序。处理程序可以修改序列，从而提供灵活性。图13B示出了执行来自(图13A的)序列控制对象1301的处理程序1302的序列。如图13B中所示，排序程序按进入序列的顺序“处理程序#1”、“处理程序#2”、……、“处理程序#n”来调用处理程序，然后按离开序列的相反顺序调用处理程序。因此，“处理程序#1”提出对“处理程序#2”的请求，以此类推，直到“处理程序#n”为止，然后最终从“处理程序#2”向“处理程序#1”传递回结果。处理程序可以是同步的或阻塞的。处理程序可以检查或修改它们所属的序列，并且处理程序可以启动其自己的排序程序。该过程有两种形式：一种形式是处理程序启动“子序列”。该子序列在与处理程序相同的排序程序中运行，并且暂停处理程序所在的序列，直到子序列完成为止。另一个示例是处理程序启动完整的排序程序。在该情况下，排序程序是单独的独立任务。该模型的一个强有力的方面在于，处理程序可以在进入序列的路径上启动该序列，允许处理继续，然后在离开序列的路径上挑选结果(如果需要的话，进行等待)。图13C示出了处理程序(处理程序#21302-2)在其中启动(或引起)另一序列(“序列2”，其由处理程序#2,11302-2.1、……、处理程序#2,k1302-2.k构成)的第一序列(“序列1”)的示例。如果序列2在与处理程序#2相同的序列中运行，则(序列1的)处理程序#3将直到序列2完成(即，直到处理程序#2,k完成)才开始。如果另一方面，序列2是作为独立且单独的任务被启动的，则序列1可以继续处理程序#3等，而无需等待序列2完成。图13D示出了处理程序(#2)在其中启动两个其他序列(序列#2,1和序列#2,2)的第一序列(“序列1”)的示例。序列#2,2启动子序列#2,2.1。处理程序的行为可以被分类为三个宽泛组(或类型)：●一次性的：当完成时从序列中移出处理程序。●智能的：处理程序可以操纵序列。●永久性的：在“进入”和“离开”路径上调用处理程序。这些标记用作处理程序行为的基本类型的描述性速写，并且应当清楚的是，该类型不由排序程序使用，并且不需要强制处理程序的“类型”，并且处理程序可以根据环境不同地操作。处理程序可以被命名(例如，“ssl”、“http-conn”、“http-session”、“strip-query”、“proxy-auth”等)以与它们要执行的功能相对应。序列控制对象可以以编译的形式被存储以便重用，因此无需不断地查找处理程序名称。下面是HTTP监听程序的序列规范的示例：在该示例中，处理程序是“http-conn”和“http-session”，参数是“address＝‘*.80’”。该监听程序任务提供了裸露的TCP或明文连接。第一处理程序(“http-conn”)是一次性处理程序，其根据明文连接创建HTTP连接。第二处理程序(“http-session”)是智能处理程序，其得到HTTP连接(已经由“http-conn”处理程序创建)，创建会话对象，并且处理整个会话。应当清楚的是，监听程序仅向客户端提供通信信道，并且相同的基本监听程序代码可以与不同的处理程序一起使用以执行除了HTTP之外的协议(例如，FTP)。举另一个例子，下面的序列规定了一般SSL监听程序：在该示例中，处理程序是“ssl”、“http-conn”和“http-session”，参数是“address＝‘*.443’”。除了SSL处理程序首先在裸露(加密)连接上创建SSL信道(这适合于http-conn处理程序)之外，该序列与(上面的)HTTP监听程序类似。虽然SSL处理程序是“一次性”处理程序，但是它需要阻塞，这是因为它必须执行SSL协商。也就是说，“ssl”处理程序必须在下一个处理程序可以开始之前完成。SSL处理程序负责实例化SSL信道。应当清楚的是，虽然ssl信道是永久性的，但是建立该ssl信道的处理程序无需是永久性的。“ssl”处理程序在明文信道上方实例化SSL信道。一旦该操作完成，(进行解密和加密的)SSL信道持续直到连接完成为止，即使“ssl”处理程序自身从序列中离开也是如此。因此，“ssl”处理程序自身不执行SSL操作，而是仅通过实例化必要的信道来执行SSL操作。图14A至图14D示出了排序程序和处理程序的示例。如上所示，序列可以用于解释请求并且知道响应可以被抽取。相同的基本排序机制可以用于执行可编程泵/滤波器，但是当然，处理程序自身现在正在执行不同的任务。图14A示出了作为泵/滤波器的一部分的双向序列。泵任务使用“直接传送”请求，例如，sendfile()，这是因为它本身无需查看数据。应当清楚的是，sendfile()不是请求，它仅是所涉及的信道执行直接传送请求的一种方式。传送序列由两个处理程序构成：●传送-监控器(账户字节，监控性能)；以及●信道-提交(向信道提交请求，等待响应)。信道可以是例如对象信道、下游信道等。如果过程需要例如计算抽取的数据的MD5，则排序程序可以在路径上建立MD5处理程序(例如，如图14B中所示)。MD5处理程序可以在数据传递时嗅探数据。在图14C中示出了自修改序列的示例。泵任务是使用直接传送请求，因此数据在用户空间中不可用。MD5处理程序在“进入”序列的路径上查看请求，并且在MD5处理程序“左侧”插入新处理程序(“直接缓存”)处理程序，使得它在MD5处理程序之前运行。“直接缓存”处理程序将直接传送翻译为缓存的读/写。序列可以被修改以改变操作顺序的方向。例如，在直接传送请求可能对于单个缓存的读/写太大的情况下，“直接缓存”处理程序可以改变序列方向以在序列的一侧执行多个操作(例如，如图14D中所示)。“直接缓存”处理程序左侧的处理程序仍然看见它们希望看到的操作，而“直接缓存”处理程序右侧的处理程序执行多个操作。脚本和客户特有的控制如上所述，请求/响应机制1104(图11)可以执行作为请求/响应处理的一部分的客户特有的处理。请求/响应机制需要特定的客户特有的数据1110A来执行客户特有的处理。请求/响应机制1104可以允许在请求/响应处理期间在多个位置(挂钩(hook))处包括客户特有的处理程序(或序列)。这些客户特有的处理程序可以在请求/响应路径上执行操作。要用于处理客户的请求的客户特有的脚本被称作客户配置脚本(CCS)，并且例如经由客户id与客户相关联。优选地，系统具有默认模式，在该默认模式下，系统将无需任何客户特有的处理程序来执行请求/响应处理。也即是说，优选地，客户特有的处理程序是可选的。应当清楚的是，脚本与序列不同。脚本用于指定要用于处理特定客户的请求的序列。脚本可以执行需要确定序列应当是哪些的不论什么操作(包括提出其自己的HTTP请求等)。例如，脚本也可以根据本地环境使用不同的序列。然而，一旦脚本完成该工作，在指示现在需要不同的序列的某一事件发生(例如，使脚本无效并且重新加载脚本)之前，使用得到的序列(而不重新运行脚本)。然而，注意，给定的处理程序可以用与配置脚本相同的语言被实现为请求/响应脚本，但是执行不同的工作。客户可以提供处理程序、现有处理程序的参数或处理程序将在处理的特定阶段调用的例程。应当清楚的是，因为如上所述，客户端1103本身可以是CDN的另一组件(例如，缓存或控制核心等)，因此CDN自身可以具有与之相关联的CCS。也即是说，从请求/响应处理的角度来看，CDN可以被认为是自身的客户。再次参照图11，服务器1102将需要与来自客户端1103的请求相关联的客户的CCS。CCS被存储在客户特有的数据1110A中的数据库1106中。如果当服务器正在处理客户端的请求时，服务器不具有该客户的存储在本地的CCS，则服务器1102将尝试从另一数据源1110B(通常从控制核心1116)获得CCS。如果找到CCS，则在请求/响应处理期间将在适合的位置(挂钩)中包括在CCS中指定的任何客户特有的处理程序(或序列)。总的来说，CCS通常运行一次。它建立客户特有的序列，然后在以编译的形式缓存客户特有的序列。如果这些序列存在且有效，则在无需重新运行CCS的情况下使用这些序列(参见图20A中的流程图中的“有效序列？”决策)。将新缓存添加至CDN当将新缓存机器添加至CDN时，控制核心需要得到与新缓存有关的信息(例如，它所在的组/区域、其IP地址、其VIP、一些容量信息等)。类似地，为了在CDN中操作，新缓存机器需要从控制核心得到当前客户配置数据和其他配置数据。新缓存可以被预配置使得当它连接到网络(例如，互联网)时，它向控制核心发送对它需要的资源的请求。关于控制核心，这些请求可以使用标准HTTP请求构成。新缓存可以例如向控制缓存请求单个配置对象，并且该配置对象本身可以包括缓存所需的其他配置对象的URL。控制核心可以被配置为类似地也以一个或更多个HTTP请求的形式向新缓存请求配置数据，但是优选地，新缓存将所需的信息作为其请求之一的一部分提供给控制核心。应当理解的是，适合的安全和加密可以用于防止与CDN的未授权连接。一旦新缓存机器具有足够的客户数据(全局数据1108)，新缓存机器然后就可以开始用作CDN缓存机器。在一些情况下，新缓存机器可以经过暖机阶段，在该暖机阶段中，它可以询问其邻居并且在接受任何输入的客户端连接之前抢先提取(例如，邻居处的受欢迎客户的)GCO和一些CCS数据。在一些情况下，缓存可以预先获取受欢迎的内容。在一些情况下，新缓存机器还可以影响本地负载平衡，使得在一段时间期间，它得到比群集的其他成员更少的业务(例如，直到其缓存故障率实质上与其作为成员所属的群集的剩余部分的故障率相同为止)。参照图15A中的流程图概述将缓存添加至CDN。参照图15A，新添加至CDN的缓存优选地首先向控制核心注册(1502处)。缓存优选地配置有控制核心的主机名称(例如，control.fp.net)，并且在连接到网络(例如，互联网)时，缓存联系控制核心并且执行某一初始注册。该过程允许控制核心确定缓存是否被授权加入CDN或者成为CDN的一部分。注册过程优选地由在缓存和控制核心上运行的程序自动化和执行。本领域技术人员在阅读该描述之后将认识和理解的是，新缓存可以是之前从未连接到CDN的缓存或者已经由于某一原因被断开的缓存。一旦被注册，缓存从控制核心获得配置数据(1504处)。缓存可以使用一个或更多个HTTP请求来请求配置数据。在一些情况下，例如，如上所述，新缓存可以向控制核心请求单个配置对象，并且该配置对象自身可以包括缓存所需的其他配置对象的URL。应当清楚的是，注册(1502处)可以与获得配置数据的过程(1504处)相结合。在该过程期间获得的配置数据中的一些可以与图11中的全局数据1108相对应，并且优选地包括GCO。因为CDN组件实质上相互供应内容(例如，控制核心向新缓存供应CDN配置内容(反之亦然))，因此从CDN组件的角度来看，如上所述，CDN有时可以被认为是客户。因此，CDN自身可以具有与之相关联的一个或更多个CCS。优选地，缓存从控制核心获得的配置数据(1504处)包括与CDN相关联的一个或更多个CCS。这些CDNCCS将允许缓存在向其他CDN组件供应CDN内容时执行适合的处理。控制核心可以从新缓存获得数据(1506处)。虽然缓存可以在初始注册过程期间向控制核心提供一些信息，但是控制核心也可以在注册之后从新缓存获得额外信息。该信息可以包括例如与新缓存的容量和类型有关的信息。新缓存还将优选地就系统/应用软件来验证它是最新的。这可能需要引导程序过程以RPM的形式从缓存/控制核心中提取新软件包，从而对其进行验证，对其进行安装和重启(直到并且包括重新启动服务器以挑选例如新操作系统组件)。此时，新缓存准备开始代表CDN供应内容。然而，在一些情况下，可能期望新缓存通过从其他缓存获得信息来“暖机”(1508处)。具体地，新缓存可以从预期代表这些客户供应内容的附近缓存获得客户数据(例如，CCS)。优选地，新缓存将询问群集的成员以获得受欢迎的CCS和受欢迎的内容。应当清楚的是，因为缓存正在使用主机名称连接到控制核心，因此CDN的会合机制可以将缓存与对于该缓存而言“最佳”或“最优”的控制核心机器会合。在一些情况下，一旦缓存已经发现(或已经被告知)哪些其他缓存是其群集的成员以及其对等体，它就可以取而代之地向这些缓存发出以控制核心为目的地的请求。这将减小控制核心上的直接负载并且加速取回这些数据。参照图15B描述了CDN组件处理资源请求。应当清楚的是，CDN组件可以是缓存(例如，边缘缓存、父缓存、源缓存、控制核心等)，并且所请求的资源可以是任何资源，包括CDN外部的客户端代表CDN的客户或订户请求的资源以及由其他CDN组件请求的资源，并且包括CDN数据(例如，记录文件等)。首先，缓存获得资源请求(1510处)。请求可以使用HTTP请求，并且包括HTTP报头中的信息。缓存需要GCO以确定所请求的资源是否可以被供应。GCO包括将允许缓存确定所请求的资源是否与CDN的客户的资源(或CDN资源)相对应的信息。因此，缓存获得GCO的当前版本(1512处)并且确定(1514处)是否可以供应资源。如果缓存需要来自控制核心的GCO或者其他信息，则缓存可以使用适合的HTTP(或FTP)请求来请求该信息，并且缓存可以从CDN中的其他缓存或其他位置获得GCO和/或其他所需的信息。例如，图15C示出了使用HTTPS提取从控制核心108提取数据的多种缓存(102)。为了发起这种提取，缓存将(使用数据的URL)提出对数据的HTTPS请求，并且将控制核心108识别为数据的源。缓存服务器应当根据由特定的客户设置的处理要求(例如，脚本等)向客户端供应该特定的客户的资源，因此，缓存需要与该客户相关联的CCS(如果有的话)。因此，在1516，缓存服务器获得与所请求的资源(即，与代表其供应所请求的资源的客户)相关联的CCS(如果有的话)。应当清楚的是，应当在获得资源之前提取CCS(这是因为CCS可能影响取回资源的位置/方式)。如果缓存确定(1514处)可以供应所请求的资源(即，缓存被授权供应资源)，则缓存可能需要获得资源的副本(1518处)。CCS(以及可能与请求相关联的信息，例如，HTTP报头信息)向缓存提供足够的信息以使该缓存定位资源的副本(如果需要的话)。缓存服务器可以从另一缓存或从源服务器获得所请求的资源。在一些实施例中，缓存服务器可以将客户端重导向获得来自其的内容的另一位置。在已经获得适合的CCS(如果存在的话)之后，缓存服务器然后使用CCS中的信息来供应资源(1520处)。如上所述，CCS在缓存甚至获得要供应的资源之前运行，这是因为CCS可以在影响请求自身并且因此影响即将供应的资源的挂钩点处对处理程序进行编程。示例图16示出了在CDN100中操作的示例性缓存(或流式传输)服务器1608。在操作中，服务器1608可以使用例如HTTP、FTP或HTTPS协议从一个或更多个源服务器获得资源。图16中的这些源服务器与图11中的源服务器1114相对应。这些资源可以是要向客户端(未示出)供应的资源。此外，服务器1608可以(例如，使用HTTP协议)从(与图11中的缓存1112相对应的)其他缓存(例如，从对等缓存)获得资源。服务器1608可以生成记录信息，并且收集器可以从服务器1608获得该记录信息和其他信息。收集器可以使用例如HTTP获得记录信息，并且使用在服务器1608上标识记录信息的适合URL请求该记录信息。实质上，服务器1608将记录信息作为资源供应给收集器。服务器1608需要特定的信息以在CDN内正确地工作。具体地，服务器1608可能需要与其他服务器(例如，其对等服务器、父服务器等)有关的信息；服务器1608需要与它可以代表其供应内容的内容提供商(例如，订户或CDN客户)有关的信息；服务器1608需要与无效(例如，失效)的内容、负载信息等有关的信息。对于负载信息，应当清楚的是，常规的缓存不需要来自内容核心的负载信息——它将其发送到控制核心(NDC)。然而，缓存可以利用来自群集中的其他机器的负载信息。服务器1608使用一个或更多个HTTP请求从控制核心108或CDN中的其他位置(例如，对等缓存)获得所需的信息。该信息至少部分地与图11中所示并且如上所述的全局数据1108和/或客户特有的数据1110A相对应。因为控制核心具有与之相关联的至少一个域名(例如，control.fp.net)，因此服务器1608所需的来自控制核心108的每一个对象/资源可以使用URL来命名并且可以使用URL和适合的协议(例如，HTTP)向控制核心108请求。当控制核心108优选地是由多于一个机器构成的分布式系统时，服务器1608将(例如，由DNS系统)导向包括控制核心108的机器之一，优选地，导向对于缓存服务器1608而言“最佳”或“最优”的控制核心机器。然后，服务器1608可以使用HTTP请求向控制核心108请求它需要的控制信息。众所周知并且如图中所示，HTTP、HTTPS和FTP使用下面的公知端口号：针对HTTP的80；针对HTTPS的443；以及针对FTP的21(图16中未示出)。本领域技术人员在阅读该描述之后将认识和理解的是，可以使用不同和/或额外的端口。应当清楚的是，可以使用用于将客户端请求导向CDN中的服务器的相同会合和选择机制来选择用于为缓存服务器1608提供服务的“最佳”或“最优”的控制核心组件。如图1中所示，CDN100包括操作/测量/管理机制109。这些机制包括用于获得并测量缓存102以及其他系统组件上的负载并且测量和维护与网络的状态有关的信息的机制。使用该信息中的一些，以例如生成用于确定资源请求的“最佳”或“最优”位置的表格和其他数据。测量机制1610测量和收集来自缓存1608的负载和其他信息，并且将该信息提供给表格生成机制。测量机制1610可以使用动态和静态测量测试，包括：ping、路由跟踪等。在美国专利No.6,185,598中描述了示例性表格生成机制，其全部内容完整地并入本文以用于所有目的。如上所述，从客户端(想要访问控制核心群集108或控制核心群集中的信息的任何实体)的角度来看，控制核心108被认为是可以例如通过其域名(例如，control.fp.net)来访问的单个实体。虽然特定的客户端可能始终从相同的控制核心群集组件得到内容，但是没有要求这种情况发生。例如，如果存在五个控制核心群集组件并且五个控制核心群集组件之一故障或以其他方式不可用，则客户端将在其他控制核心组件之一处透明地访问控制核心。本领域技术人员在阅读该描述之后将认识和理解的是，如本文所使用的，术语“客户端”是指尝试从控制核心108获得资源的任何实体，因此，客户端可以是缓存102或者CDN100的某一其他组件。此外，与来自内容提供商的源服务器的内容一样，源自控制核心的资源可以由对等服务器或父服务器供应给缓存，而无需每一个缓存直接从控制核心108提取。(控制核心可以被认为是它例如有权进行CDN控制的内容和配置数据的“源服务器”。)控制核心控制核心108(图1)维护当前CDN配置的权威数据库。在群集中的所有机器之间复制数据，并且群集使用诸如投票等的方法来确保更新和询问是一致的。在当前优选的实现(具有五个机器的群集)中，仅当五个群集机器中的三个达成共识时，认可才发生，并且仅当五个群集机器中的三个同意答案时，询问才返回答案。投票的使用是作为示例性实现给出的，并且本领域技术人员在阅读该描述之后将认识和理解的是，不同的技术可以与就询问进行投票结合使用或者替代就询问进行投票来使用。例如，诸如使用加标签的对象来检测损坏/篡改等的技术可能是适合的。在一些情况下，例如，系统可以确定它可以在无需投票开销的情况下信任来自单个服务器的答案。控制核心108包括多个数据库，这些数据库可以用于并且需要用于控制和操作CDN100的各个方面。这些数据库包括与以下各项有关的数据库：(i)系统配置；以及(ii)CDN的客户/订户。下面更详细地描述控制核心数据。缓存使用/需要这些数据库中的信息以代表内容提供商来供应资源。例如，每一个缓存需要知道内容何时仍然有效并且去哪里得到它不具有的请求内容，并且会合机制需要与CDN的状态有关的数据(例如，群集负载、网络负载等)，以知道将对资源的客户端请求导向的地方。在一些实施例中，控制核心108使用分布一致性算法——用于在实质上不可靠的处理器的网络中实现一致性的方法。如Jacobs等的美国专利No.7,921,169中所述：在Paxos算法(分布一致性算法的一个示例)中，服务器可以被网络服务器选择为用作主机或引导服务器，其中，网络服务器引导一系列“一致性循环”。在这些一致性循环中的每一个中，建议了新主机或引导服务器。循环继续，直到所建议的服务器之一被大部分或法定数量的服务器所接受为止。任何服务器可以通过发起循环来建议主机或引导服务器，但是系统可以被配置使得引导服务器始终发起用于主机服务器选择的循环。可以同时执行用于不同选择的循环。因此，可以通过循环数或一对值(例如，其中一个值引用循环并且一个值引用引导循环的服务器的一对值)来标识循环选择。一个此类循环的步骤如下，但是其他步骤和/或方法可以适合于特定的情形或应用。首先，通过引导器(leader)向群集中的其他服务器发送“收集”消息来发起循环。收集消息从群集中的服务器收集与这些服务器参与的先前进行的循环有关的信息。如果针对该特定的选择过程已经存在先前的一致性循环，则收集消息还向服务器通知不认可来自先前循环的选择。一旦引导器已经从例如至少一半群集服务器收集了响应，引导器就可以决定向下一个循环建议的值，并且将该建议作为“开始消息”发送给群集服务器。为了在该方法中使引导器选择要建议的值，必须从服务器接收初始值信息。一旦服务器从引导器接收到开始消息，它就可以通过发送“接受”消息(其声明服务器接受所建议的主机/引导服务器)来进行响应。如果引导器从大部分或法定数量的服务器接收到接受消息，则引导器将其输出值设置为在循环中建议的值。如果引导器未在指定时间段内接收到大部分或法定数量的接受(“一致性”)，则引导器可以开始新循环。如果引导器接收到一致性，则引导器可以向群集或网络服务器通知服务器应当认可所选择的服务器。可以通过任何适当的广播技术(例如，通过点到点的连接或多播传输)将该通知广播到网络服务器。可以通过建议利用与先前的循环有关的信息的选择来保证一致性方法的同意条件。该信息可能要求来自至少大多数网络服务器，使得针对任何两个循环，存在参与两个循环的至少一个服务器。引导器可以通过向每一个服务器询问服务器接受值的最新循环的号并且还可能询问接受的值来选择值。一旦引导器从大部分或者法定数量的服务器得到该信息，它就可以在响应中为新循环选择与最新循环的值相等的值。如果没有服务器参与前一个循环，则引导器也可以选择初始值。如果引导器接收到关于最后接受的循环是例如x的响应并且当前循环是y，则服务器可以暗示在x与y之间将没有循环被接受，以维持一致性。在当前优选的实现中，核心控制群集使用Lamport和Gray的Paxos算法作为其分布一致性算法。例如，在以下各项中的一项或多项中描述了该分布一致性算法的实现：题为“CheapPaxos”的美国专利No.7,856,502、题为“LeaderlessByzantineConsensus”的美国专利No.7,797,457、题为“SimplifiedPaxos”的美国专利No.7,711,825、题为“GeneralizedPaxos”的美国专利No.7,698,465、题为“FastByzantinePaxos”的美国专利No.7,620,680、题为“ByzantinePaxos”的美国专利No.7,565,433、题为“FastTransactionCommit”的美国专利No.7,558,883、题为“FastPaxosRecovery”的美国专利No.7,555,516、题为“CheapPaxos”的美国专利No.7,249,280、题为“SystemAndMethodForEffectuatingDistributedConsensusAmongMembersOfAProcessorSetInAMultiprocessorComputingSystemThroughTheUseOfSharedStorageResources”的美国专利No.6,463,532，其中每一个的全部内容并入本文以用于描述Paxos算法的目的。Paxos算法的各种商业实现存在并且可用。例如，Google在其Chubby分布锁定服务中使用Paxos算法(参见例如TheChubbylockserviceforloosely-coupleddistributedsystems,Burrows,M.,OSDI'06:SeventhSymposiumonOperatingSystemDesignandImplementation,Seattle,WA,November,2006)以在故障的情况下使副本保持一致。Google的Bigtable(Bigtable:ADistributedStorageSystemforStructuredData,Chang,F.etal,inOSDI'06:SeventhSymposiumonOperatingSystemDesignandImplementation,Seattle,WA,November,2006)和其他产品使用Chubby。Microsoft公司在来自其Bing产品的Autopilot群集管理服务中使用Paxos。Keyspace作为开放源代码的一致复制的密钥值存储设备，使用Paxos作为其基本的复制原语。本领域技术人员在阅读该描述之后将认识和理解的是，其他方法和算法可以替代Paxos算法使用或者与Paxos算法结合使用。记录缓存可以将其记录写入其机器上的文件中。除了或替代作为日志型资源保存，还可以从缓存流式传输记录。发明人认识到，记录可以被视为可以使用标准URL经由HTTP或HTTPS取回的普通缓存资源。因此，缓存可以使用它们将用于保存任何缓存的资源的相同机制来保存记录，不同之处在于，数据的资源在内部而不是外部。记录系统使用分层网络数据收集器来对记录进行收集、分类和有效地合并。记录是内部产生的资源，这些资源被缓存和固定(pinned)，直到被释放为止。优选地，以空间有效且易于解析和解释的格式存储记录。优选地，还以适当容错的方式或者在适当容错的设备上存储记录。通过常规HTTP请求对缓存进行记录访问，使得CDN可以用于从缓存收集记录。基于请求，相同的记录数据的不同估量(views)和子集是可能的。为了效率，可以将产生的响应缓存较短的时间。网络数据收集器(NDC)根据需要收集记录。在崩溃的情况下，可以使用一般的离线缓存内容访问机制来访问记录。应当清楚的是，这可能导致QoS问题，其原因在于，一些数据比其他数据更重要，并且可能需要不同的保留机制。例如，(与可能能够被重新加载的发布者的资源相反)，在丢失的情况下，本地发起的数据可能不是可重构的。因此，可以认为记录数据比发布者的资源更重要。记账数据(记录文件的特殊版本)可能最重要。在一些情况下，记录数据可能由于空间原因而被牺牲，但是记账数据应当保持到被提取为止。网络数据收集器(NDC)网络数据收集器(NDC)实质上是反向CDN。它优选地使用常规HTTP或HTTPS信道，并且具有一个关键扩展：单个请求可以导致被合并的多个填充。支持灵活的扇入和合并选项。通过脚本来定义扇入和合并选项。脚本本身是资源。脚本是下面所述的可扩展资源机制的示例。与CDN中的源服务器类似，NDC中的每一个收集操作的根是单个“源客户端”。组件的作用CDN系统的某些组件可以用作CDN的客户端和/或CDN的内容提供商。例如，如上所述，核心控制群集维护缓存使用/所需的信息以使其向客户端传送内容。当缓存从控制核心群集获得控制相关内容(资源)时，控制核心群集用作内容提供商并且缓存用作客户端。类似地，当收集器机制从缓存群集获得记录和其他信息时，收集器机制用作客户端并且缓存群集用作内容提供商。此外，当内容核心群集从收集器机制获得信息时，控制核心群集用作客户端并且收集器机制用作内容提供商。当CDN代表内容提供商将内容传送到客户端时，缓存从与内容提供商相关联的源服务器站点获得该内容。在一些情况下，如上所述，缓存服务器站点可以尝试从另一缓存服务器站点(例如，从对等缓存服务器站点或者从父缓存服务器站点)获得请求的内容。在这些情况下，对等(或父)缓存服务器站点用作内容提供商。分层CDN优选地使用树型分层通信结构来从控制核心和源服务器向边缘提取数据，并且从边缘向专用聚集器和监控器提取数据。这些树型结构优选地是动态的，即，它们可以随时间、要求和环境而改变。这些结构优选地还是定制的，即，不同的通信操作可以使用不同的分层，并且通信操作的不同实例可以使用不同的分层(例如，针对不同的源服务器，不同父服务器)。为了将数据提取到边缘，每一个节点需要知道其父节点。为了将数据提取到根，每一个节点需要知道其子节点。父节点或子节点的列表本身可以是资源。使用域名代替父节点和子节点的IP地址允许利用会合系统。可执行资源、定制挂钩和脚本CDN100中的缓存102能够处理和传送(供应)可执行资源，并且CDN用户(例如，内容提供商、CDN自身)能够经由这些可执行资源提供资源的扩展。可执行资源提供了一般且有用的扩展，该扩展可以替代和/或增强CDN中的多个自组织机制和HTTP扩展。可执行资源允许适当认证的HTTP服务器使用(可能通过诸如“600Exec”等的扩展状态代码或者诸如“应用/x-fp-exec”等的新内容类型标识的)新类型的答复对HTTP请求进行响应。这种答复的内容是要由解释器在缓存的响应路径中执行的脚本，以生成实际的答复。解释器可以进行的操作的示例是：●填充来自备选位置的请求。●填充来自多个位置的请求并且合并结果。●执行认证。●预填充一个或更多个其他资源。●对资源的主体进行操纵(例如，压缩、代码转换、分段等)。如果答复是可缓存的，则它可以由缓存保存并且每当请求资源时被执行。NDC可以使用该特征来聚集记录。系统提供了一种用于区分请求脚本自身与请求执行脚本的结果的方式。正如任何其他资源一样，脚本受到固定、终止、无效和重新生效。可以在处理中的多个挂钩点处添加客户特有的代码。这种客户特有的代码可以用于例如：●解析之后的请求操纵；●计算缓存密钥以用于索引查找；●认证的粗略和详细细节；●内容协商选择、变形和编码；●用于范围处理的策略；●决定联系或迁移至哪一些对等体；●联系哪些主机以进行填充；●填充请求的内容；●填充响应的操纵；●源服务器错误的处理；●缓存策略；●客户端的响应的操纵；●记录效果。各种各样的挂钩点使CDN用户(客户端)能够修改现有的算法；预处理算法或后置处理算法；和/或完全替换算法。在当前优选的实施例中，这些是CCS在各个挂钩点处设置的客户特有的序列。在本实现中，脚本可以用于：●配置●客户特有的事件处理和HTTP重写●网络数据收集操作●新特征的快速原型设计脚本优选地是缓存的对象(与CDN中的其他对象类似)。它们优选地被编译为字节代码并且在沙盒中由虚拟机执行。优选地针对CPU使用对脚本进行测量，并且脚本实际上是可抢占的。在当前优选的实现中，脚本是使用Lua脚本语言来实现的。针对小寄存器虚拟机，Lua编译为字节代码。Lua的原始数据是稳定的(其被实现为散列表格与阵列之间的混合)，但是它还具有其他类型(字符串、数字、布尔数等)。Lua针对系统剩余部分的接口经由各种功能绑定，这些功能绑定是Lua功能调用使系统功能(而不是另一个Lua功能)被调用的方式。特定绑定的细节(包括它对其进行操作的数据以及它向Lua脚本返回的结果)是所考虑的绑定特有的，并且可以涉及表格(例如，散列表格对象)或其他类型的对象。本领域技术人员在阅读该描述之后将认识和理解的是，可以使用不同的脚本语言。然而，应当清楚的是，任何脚本语言应当使用小解释器快速地运行(例如，被解释)，具有相对小的实现(重量轻——具有小内存占用，并且容易被沙盒化以便安全运行)，并且提供足够的控制以允许使用客户导出的脚本。应当注意的是，“脚本”不一定暗指在运行时被解释，而是在更宽泛的意义上用于指代可加载代码。应当清楚的是，基本缓存功能不需要脚本，并且CDN将在没有脚本的情况下操作以供应内容。挂钩允许脚本在缓存的处理路径中的各个点处执行，并且可以用于(如果允许的话)增强和修改内容传送。挂钩可以是：●客户-可见(Customer-visible)。监控、计费、记账。●Ops-可见(Ops-visible)。监控。●开发-可见(Development-visible)。最小限制。在挂钩点处，可以指定：●预录(预定义)的算法名称；或者●表达(例如，内联脚本或脚本语言的表达)；或者●处理程序或一系列处理程序；或者●脚本的名称在一些实现中，在请求处理中使用的脚本可以：●检查请求●修改请求●生成响应(包括替换已经生成的响应)●提供短静态主体●提供用于递增地生成较长响应主体的功能●提供用于对响应主体进行滤波的功能●检查已经生成的响应●修改已经生成的响应●启动任意数量的帮助请求○同步地——等待并且检查响应○异步地——“发后不理”○可缓存的或不可缓存的配置变量类似地支持脚本执行，例如，变量可以具有立即值，是参数参考，或者由内联表达确定。例如，在这里使用不同类型的值来示出变量fill_host。●fill_host＝“origin.customer.com”--立即值●fill_host＝$host1--参数参考●fill_host＝“origin”.domain($request_host)--内联表达●fill_host＝http://origin.customer.com/scripts/pick_origin.lua-脚本的引用应当清楚的是，仅通过对值的类型进行举例说明的方式给出这些值。这些表达优选地将利用脚本语言(例如，Lua)。缓存组织图17是示出了示例性缓存中的主要功能模块(统称为1700)的框图。这些模块包括执行机构1704、清单信道1706、全局策略制定器1708、输出连接管理器1710、填充管理器1712、HTTP解析器1714、1715、HTTP格式化器1716、1717、输入连接管理器1718、重写器1720、索引1722、存储管理器1724、对等管理器1726、IO1728、缓存间传输协议1730和规则库1732。这些模块及其可操作连接是通过举例说明的方式示出的，并且应当清楚的是，缓存可以包括不同和/或额外的模块，并且缓存中的模块可以具有不同的可操作连接。执行机构1704是控制缓存中的所有活动的基本执行机构。执行机构的责任是维护可运行任务的优先级列表，并且以优先级顺序执行这些任务。高优先级“系统”任务重复地检查就绪文件描述符，并且将其等待“用户”任务移动至运行列表上。执行机构还可以支持提取任务或任务组作为称作信道的异步服务，并且可以提供用于传送任务和信道的干净方式。下面讨论的缓存子系统被实现为任务和信道。当在监听程序文件描述符之一上检测到新客户端连接时，输入连接管理器1718指派客户端任务来处理该新客户端连接，并且协调接受连接、完成任何TLS(传输层安全性)握手、以及指派优先级和连接级策略的过程。输入连接管理器1718在其使用期限期间继续监控和管理连接。虽然输入连接管理器1718在这里被描述为单个组件，但是应当清楚的是，这仅是缓存中的功能的一个逻辑描绘。例如，在本实现中，存在这样的监听程序任务，即，在接收到新连接之后，该监听程序任务运行为该特定监听程序配置的处理程序序列。这些处理程序可以应用策略、执行TLS升级(如果适合的话)等。客户端任务调用HTTP解析器1715来从连接读取数据，定位消息边界，并且将HTTP解析为具有方便的内部格式的请求对象。只要消息处于缓存系统(CDN)中，消息就保持该内部格式，即使它们被迁移至另一缓存也是如此。应当清楚的是，缓存至缓存消息可以具有另一格式，例如，在一些情况下，可以以消息的标准文本格式来在缓存之间发送消息。接下来，可以由规则库1732来处理请求对象，以指派客户特有的处理策略并且归一化与请求相关联的URL。策略可以指示例如请求需要通过客户定义的脚本的操纵。在该情况下，请求重写器1720执行脚本。在本实现中，使用表格(GCO)，该表格联合请求的视在(apparent)目标来决定究竟是否值得继续进一步处理(即，请求是否与有效客户相关联)。此时，系统检查是否存在适合于该客户的经编程的处理程序序列。如果否，则系统取回并运行客户配置脚本，该客户配置脚本的功能是对处理程序的序列进行编程。然后，运行处理程序以处理请求。下一个步骤是确定缓存是否具有与请求对象有关的任何信息。向清单信道呈送请求，然后，清单信道检查请求并且使用它内部具有的信息(清单)来确定如何最佳地处理请求，包括通过提供针对缓存对象的引用、请求填充或刷新等。清单信道维护清单数据并且还提供使用清单数据的情报。在缓存索引1722中查找URL，缓存索引1722实质上是列出了已经存在于缓存中的对象的数据库。索引查找的结果为空，或者是列出了在对请求进行响应时可能有关的所有数据、元数据和进行中的活动的清单。此时，请求处理引擎具有请求特有的信息集合，包括解析的请求、用于处理请求的策略集合、以及有关的缓存信息的清单。如上所述，清单信道1706负责确定如何对请求进行响应。通常，决策将取决于请求特有的信息、对象特有的信息、机器的当前状态、CDN的全局状态、以及在缓存中实现的能力集合。针对缓存中每一个参考的清单，可能存在一个运行的策略制定器实例，并且该策略制定器处理参考该清单的所有客户端和活动。在当前实现中，策略制定器是清单信道。清单信道1706在其布置处具有实现服务的多个模块，这些服务包括存储服务、填充服务和对等服务。其他模块可以用于错误消息生成、认证、记录、限制等。策略制定器的作用是精心安排这些服务以构造对请求的答复，并且优选地完全处理请求(这是因为记录是处理的一部分，但不一定是答复的一部分)。清单信道1706包含缓存中大部分情报。针对新的资源类别，可以在清单信道1706中添加新能力并且提供特殊处理。由于该原因，架构被设计为提供机制和策略的完全分离。执行各个服务的机械设备/机制被封装在单独的模块中，并且清单信道1706实质上用作管理者，从而监督响应的构造。最常见的场景被预期是简单的缓存命中，其中，缓存具有请求对象的容易访问的副本。在该情况下，清单信道1706调用存储服务(存储管理器1724)以取回对象，其中，该对象可能在存储器中或者在固态磁盘或硬盘(通常标记为1734)上。在该过程中，清单信道1706还可以向存储服务(存储管理器1724)提供与预期哪种类型的将来访问有关的指导，使得可以将对象最佳地放置在适合类型的存储设备中。另一个常见的场景调用动态生成的响应，例如，针对控制命令的响应、统计报告或错误消息。当接收到请求时，初始处理程序序列被组合以(基于请求的目标和它参与的监听程序)处理请求。处理程序由于请求被导向它而生成响应，通过执行请求或响应操纵而添加某一值，或者由于它们与即将到来的请求无关而使自己从序列实例中取出。处理程序可以是脚本处理程序，并且该脚本可以执行任意数量的功能(如上所述)以生成响应或操纵请求或响应。“清单信道”是由一系列处理程序使用的一个组件，但是它涉及处理可缓存的资源。它通常不涉及确定例如是否需要执行预认证(这可以由cli-req挂钩等中的处理程序处理)。如上所述，架构的重要方面是实质上所有数据项(包括机器配置、客户策略、记录、记账数据和统计数据)仅是web对象，这些web对象在索引中出现并且如客户web资源等一样通过策略制定器被取回。作为关键的资源，它们确实具有参与特定认证服务、持久服务和预填充服务的策略，但是这些服务的机械设备也可以在必要时用于普通资源。Unix文件I/O的特征是对标准文件的读操作和写操作是同步的，并且如果需要从磁盘物理地取回数据或者向磁盘物理地写入数据，则将阻止调用线程。因为当正在访问磁盘时缓存很可能具有大量其他工作要做，因此IO库1728提供了用于使缓存将磁盘I/O切换至可以在不延迟缓存活动的情况下阻止的单独线程的方式。此外，IO库1728向物理磁盘提供了比正常打开/读取/写入/关闭接口更强、更有效的API。如果请求不是缓存命中，则清单信道1706通常将调用对等服务(对等管理器1726)来确定附近的缓存是否具有请求的对象。因为其他服务也可能需要与相邻缓存进行通信，并且打开或操作与多个邻居的多个TCP连接可能是低效的，因此缓存间传输协议模块1730在单个通用链路上复用多种类型的缓存间通信。例如，对等服务可能提供以将客户端连接迁移至具有资源的邻居；策略制定器可以选择使用该选项，在该情况下，它将调用迁移服务，迁移服务将使用缓存间传输协议来传输客户端连接状态。如上所述，应当清楚的是，一个或更多个处理程序执行该功能。如果请求不是命中或者内部服务或迁移，则需要经由网络获取资源并且调用填充服务(填充管理器1712)。填充管理器的作用是平衡和优先处理所有策略制定器之间的输出网络活动，并且针对支持的协议集合处理协议处理程序。具体地，针对HTTP填充，策略制定器将以内部格式创建HTTP填充请求，并且填充服务将使用HTTP格式化器1716来格式化该请求，将其发送到适合的目标主机，并且管理数据传输。出于效率的考虑，由输出连接管理器1710创建和管理连接，输出连接管理器1710维持与频繁访问的主机的连接池、跟踪响应性、执行业务成形等。在当前实现中，清单信道创建填充请求。一些填充操作将是来自其他缓存的对等填充，并且这些填充操作可能构成不使用缓存间传输协议的缓存间通信的主要类别。这些填充可以使用内部消息格式并且绕过不必要的HTTP格式化和解析步骤。来自网络的填充响应被切换回清单信道1706，清单信道1706决定是否缓存对象以及在答复等待客户端之前如何处理对象。应当清楚的是，清单信道1706将不调用“答复重写器”。而是这种重写器(如果有的话)将存在于响应路径(例如，client-resp)上的挂钩点之一处，并且将被使用，而不论清单信道是否涉及生成响应。这种重写器可以检查响应以确定它是否来自缓存，然而，不是由清单信道来决定是否调用该重写器。清单信道通常将不涉及先验已知是不可缓存的请求。另一方面，“答复重写器”可以很好地参与这种请求。当在进入路径上时，清单信道1706调用适合的服务来进行实际的工作，并且支持答复重写器1720在即将最终格式化并输出至客户端之前进行的可选处理。本领域技术人员在阅读该描述之后将认识和理解的是，由一个或更多个处理程序在处理序列的“离开”路径上执行这种类型的处理(最终格式化等)。清单信道1706负责处理单个URL，并且优化客户当前请求与该URL相关联的资源的体验。全局策略制定器1708负责优化整体缓存行为以及CDN的总体行为。全局策略制定器1708包括永久运行的后台任务和服务集合，这些任务和服务集合监控和管理缓存，从而执行操作，例如，丢弃旧对象、预获取延迟敏感对象以及强制限额。与清单信道类似，全局策略制定器优选地被构造为完全分离策略和机制，从而允许将来的增强和调整。全局策略制定器1708通过调整清单信道在做出其决策时查询的多种模式和等级来影响清单信道1706。全局策略制定器进而监控模式和等级改变的影响，并且根据需要对其进行调整以实现期望的全局条件。因此，全局策略制定器是负责缓存中的各个反馈回路的模块。例如，通过调整最大允许对象寿命，全局策略制定器可以控制缓存中的数据量，并且通过调整内存存储设备中允许的对象的最大大小，全局策略制定器可以影响使用中的内存量。在一些实现中，可能不存在全局策略制定器，并且存储系统将管理其自己的资源等。下面更详细地描述各个组件的实现和实施例。本领域技术人员在阅读该描述之后将认识和理解的是，下面提供的细节是示例性的，而并不旨在限制本发明的范围。清单信道1706清单信道1706处理与单个资源有关的问题。其工作是基于诸如以下各项等的各个因素来向每一个客户端传送最优响应：请求细节、策略设置、缓存内容、设备状态、对等缓存、源服务器、网络等。清单信道1706由有效机制的可扩展集合构成，以例如从磁盘进行取回；连接迁移；通过源填充；检查对等体等。控制模块精心安排机制，从而针对常见情形使用固定算法并且提供向这些固定算法引入变化的挂钩。如果必要的话，清单信道1706可以是完全可编写脚本的。清单信道1706可以提供机制与策略的完全分离，并且可以比管道更一般。在本实现中，清单信道1706是序列(类别管道)，但是序列的步骤中的每一个步骤可以是任意智能的(包括是脚本)。在任何时候，针对正在活动访问的每一个清单，存在正在运行的清单信道1706的一个实例。清单信道的作用是协调与清单相关联的所有活动，确保向请求对象的每一个客户端发送满足策略约束的个性化响应，并且尽量有效地完成该操作，而不会违反由全局策略制定器施加的其他约束。清单信道1706优选地包括具有相关联的逻辑以执行以下各项中的一些或全部的机制集合(这实质上是潜在的“处理程序”列表)：全局策略制定器1708全局策略制定器1708是负责监督整个缓存的操作以及缓存与CDN的其他部分的关系的子系统。全局策略制定器优选地一直运行，并且跟踪外部参数，例如，使用的存储量、客户端的数量等。全局策略制定器进而通过调整诸如LRU(最近最少使用)侵略和监听程序轮询以及接受率等的内部参数来控制缓存的操作。无效。全局策略制定器负责获取(优选地大概每秒一次)对来自CDN控制核心的主无效日志的更新，获取主无效日志指示已经改变的任何辅日志的更新，并且无效辅日志指示已经被无效的资源。应当清楚的是，用于客户无效的控制核心可以不是与用于配置数据(和与之相关联的无效)的控制核心相同的控制核心。可以将不同的客户组放到不同的此类控制核心上以进行无效。自动刷新。该机制允许即使当未在外部请求所选资源时也刷新所选资源，使得所选资源始终是最新的。无效日志机制实质上是该机制的特殊情况。负载度量。全局策略制定器负责测量机器上的总负载，并且针对对负载状态的请求进行响应。平台配置和控制。用于对来自控制核心的配置信息起作用的机制。监听程序和IO事件速率控制。控制接受新连接的速率以及针对准备状态轮询文件描述符的速率。与本文所述的其他组件/机制一样，这里所述的功能不一定由单个实体或机制来执行而是由多个任务或序列来执行。然而，本领域技术人员在阅读该描述之后将认识和理解的是，执行这些功能的任务集合可以被认为构成“全局策略制定器”。控制核心数据如上所述，控制核心108维护当前CDN配置和操作CDN所需的信息的权威数据库。数据库包括各种互连表格，这些互连表格用于描述和/或管理CDN。参照图18至图19，数据库包括系统配置对象1802、客户配置对象1804、客户无效日志1806和主日志1808。本领域技术人员在阅读该描述之后将认识和理解的是，可以在数据库中维护不同和/或其他对象。在当前优选的实现中，控制核心108维护并存储以下信息中的一些或全部(作为系统配置对象1802或客户配置对象1804的一部分)，其中一些可以用于会合，并且其中一些由缓存机器使用：全局配置对象(GCO)(1912)结合请求响应处理描述了GCO。客户配置脚本(CCS)结合请求响应处理描述了客户配置脚本。主机表格(HostTable)(1902)HostTable1902是网络中的所有机器的列表。在表格(HostTable)中维护该列表，该表格针对每一个机器包括其网络地址(IP地址)并且优选地包括其带宽容量。HostTable优选地存储带宽容量值(BWcap)。还在群集表格中存储BWCap值，如下所述。根据下面的表格通过这两个值来导出带宽容量值的实际值，其中，在下面的表格中，clusterBW表示对群集设置的带宽容量值，hostBW表示对缓存设置的带宽容量值，并且nhosts表示群集中的机器的数量：虽然仅使用这些表格之一来设置BandwidthCapacity应当是足够的，但是如这里所述，这并不始终是正确的方法。具体地，计算出的BandwidthCapacity变量优选地不由(会合机制的)服务器选择器(SS)机制使用，而是服务器选择器直接使用来自ClusterTable的值以基于群集总带宽来进行分离(shedding)并且使用来自HostTable的值以基于针对每一个主机的带宽来进行分离。在两个表格中均设置BandwidthCapacity，这是因为HostTable条目跟踪从主机到交换机的上行链路，而群集处的BandwidthCapacity是从交换机到网络结构的上行链路。服务器选择器不使用计算出的针对每一个主机的BandwidthCapacity的原因在于，对于控制分离以避免使针对每一个主机的上行链路饱和的目的，它通常是错误的。也即是说，如果仅在ClusterTable中设置BandwidthCapacity，则系统将针对每一个主机的值计算为clusterBW/nhosts(参见上面的表格)。但是，例如，如果存在共享10G上行链路的20个机器，则值为0.5G，该值太小：每一个机器应当能够在引起分离之前(假设总群集上行链路未饱和，即，不是所有机器同时使用1G)单独地突发至1G(或者更高，这取决于从每一个服务器到交换机的连接)。或者，例如，如果存在共享10G上行链路的五个机器，则系统将计算出2G，如果单独的机器仅具有1G链路，则这将太大。因此，通常应当在HostTable和ClusterTable中均设置BWcap值。因为在HostTable中应当存在针对网络中的每一个机器的条目，因此非内容供应机器应当具有设置为0的其BWCap值。位置处的每一种类型的机器应当被分组为一个或多个群集，其在ClusterTable中具有相应的条目(1904)。SMED表格(1908)SMED表格1908是表格(SMEDTable)中的“测量等同”缓存列表。实际上，该列表相当于硬件支架；即，插入到单个路由器中的机器集合。每一个条目包括一个或多个群集。群集表格(1904)群集表格1904描述了每一个群集。回想群集与站点(所有机器插入到给定交换机中，但是这些机器的子集共享相同的VIP集合)不同。因此，针对给定的站点可能存在多个ClusterTable条目。群集表格存储与每一个群集所在的区域有关的信息。每一个群集包含多个HostTable条目(针对每一个物理机器一个HostTable条目)以及一个或多个VIP(其中的每一个由VIPTable中的条目来表示)。应当在ClusterTable中(并且在HostTable中直接)表示网络上的所有机器。为了能够识别哪些是内容供应机器，在ClusterTable中存在特征列。与HostTable一样，非内容供应群集应当具有被设置为0的BWCap。使这些机器在这些表格中被表示允许诸如测量组件等的基础设施组件利用非内容供应机器上的处理。VIP表格1906VIP是本地负载平衡地址，其是作为会合的目标来分发的。如果该VIP用于安全业务，则它包含对SSLTable中的节点的引用，否则，sslKey被设置为空(NULL)(指示HTTP业务)。因此，针对网络中的每一个VIP地址存在一个条目。非内容供应群集不需要具有定义的VIP。SSL表格1910SSLTable中的条目描述了一个“安全”属性；它标识超级名称与证书之间的映射。特征表格1912特征表格1912描述了由具有特定特征(例如，内容供应)的所有机器共享的特性。术语“特征”在本文中用于区分在CDN中执行不同功能(例如，内容供应等)的机器。协同服务器表格1916如本文所使用的，关于特定资源的协同服务器是源服务器——特定资源的权威源。协同服务器表格包含在系统中定义的所有协同服务器(源服务器)和别名节点的描述。该表格保存与向CDN注册的所有客户源服务器有关的信息。该表格用于将输入请求与这些条目相关联，并且描述了取回满足该请求所需的资源的方式和地方。注意，因为CDN对象也由CDN处理，因此一些CDN服务器有时可以用作协同服务器。别名节点与基本协同服务器相关联，并且提供单独地报告和记录与附着到协同服务器的特定别名相关联的业务，而无需将相同的资源缓存多次。协同服务器表格优选地包括以下字段：订户表格1918订户表格1918包括与CDN的订户(例如，CDN的客户)有关的信息。别名别名是使协同服务器为网络所知并且用于在请求处理期间识别该协同服务器的名称。术语别名可以涉及该标识符的格式以及标识符的特定属性。使用术语的方式列表遵循：请求-响应处理图13示出了缓存及其各个组件的逻辑结构。由这些组件中的一些或全部执行的处理可以由排序程序来执行。排序程序使用序列控制对象，序列控制对象是由处理程序的排序列表构成。在当前优选的实现中，排序程序是执行机构任务(优选地，信道)，并且与排序程序(任务)相关联的处理程序是通过事件来执行的。任务必须是执行机构信道，使得它可以使用提交(潜在异步的)模型。请求-响应处理流现在参照图20A至图20C来描述请求-响应处理流。为了该描述的目的，假设正在由CDN中的诸如服务器1102(图11)等的缓存服务器来执行处理。缓存服务器在端口处获得数据(输入连接)并且解析足够的输入数据(2002处)以确定数据与适合类型的请求(例如，HTTP)相对应。输入数据将包括足够的信息以允许缓存确定它是否可以供应请求的资源。例如，在HTTP请求的情况下，输入数据将包括HTTP报头信息，该HTTP报头信息包括用于提出请求的URL(的版本)。为了确定它是否供应请求，缓存服务器需要将与请求相关联的信息与全局配置对象(GCO)中的信息进行比较。因此，缓存服务器需要确定它是否具有有效GCO(2004处)。如果必要的话，由缓存从控制核心取回GCO(2006处)。如果当前GCO有效，则可以使用当前GCO，否则，必须使GCO生效或者获得新GCO。应当清楚的是，如果缓存不能在某一预定次数的尝试之后获得有效GCO，则它不应当供应所请求的内容并且应当失败(并且使自己离开选择循环直到它能够取回有效的GCO为止)。在当前实现中，GCO用作承载有效协议、主机名称和路径前缀的“空白列表”。在一些情况下，对于特定的中间商属性，也可以基于请求参与的VIP来执行客户标识。这种技术也可以用于提供简单的透明代理实现。GCO将协议、主机名称和路径前缀映射到客户标识符(客户ID)。下面的表格示出了示例性GCO(左边一列中的数字被提供用于描述的目的，而不旨在以任何方式进行限制)。字符串客户ID1http://customer1.com/1.12http://customer2.com/2.13http://*.customer3.com/3.14http://*.special.images.customer3.com/3.25http://*.images.customer3.com3.36http://images.customer3.com3.47http://customer4.com/4.18http://customer4.com/topd1/4.29http://customer4.com/topd1/subd/4.310http://customer4.com/topd2/4.311http://customer5.com/5.112https://customer5.com/5.213*://customer6.com/6.114http://customer7.com/7.115http://customer7.com:8080/7.2GCO中的字符串是URL中的一些或全部。通配符可以被使用，但是有限的。回想(为了该描述的目的)URL具有以下形式：<<protocol>>://<<domain>>/<<path>>其中，<<protocol>>可以是例如“http”、“https”、“ftp”等，<<domain>>是域名并且路径指定位置。在T.Berners-Lee等的RFC1738通用资源定位符(URL)中给出了形式URL描述，在T.Berners-Lee等于1998年8月的网络工作组RFC2396“UniformResourceIdentifiers(URI):GenericSyntax”中描述了URI，其中每一个的全部内容完整地并入本文以用于所有目的。可以使用请求参与的监听程序的标记来替换“协议”。原因在于，给定的客户可以具有呈现其服务器证书的专用SSL监听程序，因此缓存将仅希望满足该监听程序上的该特定客户的请求。在该情况下，GCO可以具有例如“https-CUST”(例如，如果CUST是具有客户SSLVIP的客户)作为“协议”。在GCO中，可以用“*”(通配符字符)来替换协议，这是指所有支持的协议映射到相同的客户ID(参见例如，上面的表格的数字13)。通配符字符(例如，“*”)还可以用作主机名称(例如，数字3、4、5)的(仅)第一组成部分。因此，http://a1.customer3.com和“http://a2.customer3.com”都将匹配上面的表格中的条目数字3。为了简化用于解决歧义的规则，在一些实现中，不可以在任何其他地方使用通配符。在完成原始解析(2002处)之后，缓存知道用于提出请求的URL。一旦缓存具有有效的GCO，它就尝试在GCO中找到输入URL的匹配(2008处)。优选地，使用“最佳匹配获胜”策略。首先检查主机名称，并且精确匹配获胜，否则，使用通配符匹配，其中，最大数量的文字匹配获胜。例如，对于customer3.com：字符串“special.images.customer3.com”映射到3.2(比3.3更多的文字匹配)；images.customer3.com映射到3.4(精确匹配)。接下来，查找门户网站和协议，然后最长路径前缀获胜。图20A至图20C中的流程图示出了如果未生成响应则来自GCO例外挂钩的潜在循环。为了防止循环发生，系统只能尝试GCO查找有限次数，例如，多达两次。GCO-例外挂钩的点允许检查/校正请求，使得它可以在GCO中被找到。然而，系统优选地仅得到一次校正机会。每一个客户可以具有要用于处理该客户的请求的相应脚本(序列)。这些客户配置脚本(CCS)与客户id相关联，并且如果请求(URL)(基于GCO中的查找)与有效客户有关(1610处)，则处理继续确定是否存在与该客户相对应的CCS(客户配置脚本)。检查CCS的有效性，并且如果需要的话，(从控制核心)获取新的CCS。如上所述，CCS用于组合序列，这些序列然后可以被缓存和使用直到它们(例如，由于取回新的CCS)变得无效为止。应当清楚的是，脚本和序列不是同一回事，但是如上所述，特定的处理程序可以调用脚本来执行其功能。在当前优选的实现中，CCS是从控制核心取回的Lua脚本。脚本的名称可以基于客户的ID，例如，对于客户ID4.2，可以在以下位置处获得脚本：https://core.fp.net/ccs/ccs-4.2.luac脚本在主处理序列中的多个挂钩点处建立客户特有的子序列。优选地缓存建立的结果，并且CCS不在每一个请求上运行。如果重新加载脚本或者如果条件改变，则重新运行脚本。例如，如果脚本的结果被永久性缓存，则代理修订可以改变。编译的脚本是由缓存消耗的对象，但是脚本本身是通过数据库中的客户配置描述生成的。一旦配置(加载和验证)了CCS，就继续处理挂钩(标记为“cli-req”-客户端请求)以处理任何相应的定制处理。也即是说，“cli-req”是插入客户特有的处理程序(其可以包括脚本)的子序列的挂钩点。举例说明，假设特定的客户需要：■将www.customer1.com设置为公认的主机名称■从所有查询字符串中除去sessionid参数可以在cli-req(客户端请求)挂钩中采取这些动作，其示例性的CCS源将是：hook[″cli-req″].add(″set-host('www.customer1.com')″)hook[″cli-req″].add(″strip-query('sessionid')″)其中，set-host和strip-query是插入到较大序列中的简单的一次性处理程序。举另一个例子，假设客户具有与上述相同的客户端要求，但是还希望将填充目标设置为origin.customer1.com相应的CCS源将是：hook[″cli-req″].add(″set-host('www.customer1.com')″)hook[″cli-req″].add(″strip-query('sessionid')″)hook[″fill-req″].add(″set-target('origin.customer1.com')″)其中，set-host、strip-query和set-target是插入到较大序列中的简单一次性处理程序。该CCS将动作添加到fill-req(填充请求)挂钩。举配置脚本的另一个例子，假设客户需要使用auth.customer1.com的代理认证来进行远端认证。客户的CCS将包括：hook[″cli-req″].add(″proxy-auth('auth.customer1.com')″)proxy-auth处理程序启动其自己的序列来执行实际的认证请求并且等待响应。这是启动帮助请求的阻塞处理程序的示例。基于对认证请求的响应，proxy-auth处理程序可以立即生成401响应或者允许处理继续。另一种使用CCS对其进行处理的方式(如果本地proxy-auth处理程序并非始终可用的话)可以是：该逻辑是CCS构造器而不是配置写入器的一部分。单个全网络CCS可以基于本地环境作出这些决策。CCS可以使用任何复杂的逻辑来组合客户的构造块，包括提出额外请求等。“本地”处理程序还可以是后台的内置脚本，但是优选地，本地处理程序被预期是有效的C代码。应当清楚的是，CCS是针对每一个客户的对象。还应当清楚的是，人工配置写入器不需要处理该细节；它们只需要知道它们想要认证。此外，应当清楚的是，CCS不一定在每一个请求上运行。而是CCS用于将代理配置为通过在各个挂钩点处建立适合的处理程序来处理给定客户的请求。这些处理程序本身可以调用脚本，但是它们不必这样做，并且期望将在主请求处理路径中根本不使用脚本(例如，Lua)来处理典型的客户的请求。CCS是脚本而不是用于在挂钩点处安装的简单处理程序列表的事实意味着它可以灵活地检查其周围环境以针对它在其中运行的环境(软件修订、区域等)来确定适合的处理程序。从图20A至图20C中的流程图可以看出，可以在处理序列中的多个点处使用挂钩。在本实现中，存在尤其可用于以下各项的挂钩：●客户端请求●缓存填充●GCO例外●缓存未命中●填充响应●填充抽取●客户端响应●客户端抽取本领域技术人员在阅读该描述之后将认识和理解的是，不同和/或额外的挂钩可以使用并且用于特定的实现。如上所述，默认处理是可用的，并且如果客户是有效的(例如，在GCO中找到)并且无需客户特有的处理，则缓存将在无需任何客户特有的序列的情况下为请求提供服务。因为CDN的各个元件本身是潜在的客户端(和资源的源)，因此CDN可以提供CDN资源的CCS。从实现的角度来看，CDN可以被视为客户，其在GCO中具有条目并且具有其自己的CCS。示例图21A示出了示例性CDN，该示例性CDN包括(与图1中的缓存102相对应的)形成缓存云的多个缓存以及相关联的组件(统称为116)。在图21A中的附图中通过阴影圆圈描绘了每一个缓存(例如，缓存群集站点)。示出了CDN系统/框架的其他组件，包括核心控制机制(在附图中通过五边形来标记，其共同地与图1中的控制核心108相对应)、收集器机制(在附图中通过三角形来标记并且与图1中的收集器106相对应)以及源服务器/服务器站点(在附图中通过黑色圆圈来标记)。虽然在图21A中通过举例说明的方式示出了覆盖美国和欧洲地图的多个组件，但是本领域技术人员在阅读该描述之后将认识和理解的是，这些覆盖仅是示例性的，并且不旨在限制组件的实际位置或组件的数量。参照图21B(并且再次参照图21A)，(例如与图1中的缓存102相对应的)缓存与CDN100中客户端110可以获得来自其的资源的位置相对应，其中，CDN正在代表内容提供商(例如，内容提供商112)提供(例如，供应)该资源。源服务器/服务器站点与CDN缓存服务器/服务器站点可以获得来自其的内容提供商的内容的位置相对应。源服务器/服务器站点可以是CDN的一部分(例如，如果内容提供商将内容提供商的内容预加载到CDN中的话)，或者它们可以由内容提供商独立于CDN来操作。收集器机制(在附图中通过三角形标记并且与图1中的收集器106相对应)分布在系统中并且代表内容提供商从缓存收集与资源有关的信息(例如，记录和性能数据)。收集器机制可以向内容提供商提供与代表其传送的资源有关的(原始形式或经处理的形式的)收集信息。可以通过单独的管理实体来提供向内容提供商提供的信息，其中，该单独的管理实体收集并维护由收集器机制收集的数据。图21C示出了如图21A和图21B中所示的CDN缓存的一部分的示例性逻辑组织。如图21C中所示，CDN缓存可以被布置在一个或多个层(在附图中标记为“边缘层”、“群集层”、……、“支架层”和“区域层”)中。这些层与图8中的“边缘层”、“父层(层2)”、“层3”等相对应。所谓的“边缘层”中的缓存优选地最接近“客户端”(相距某一网络距离度量)，因此从边缘层中的缓存向客户端供应的资源将可能提供将这些资源向这些客户端进行最有效的传送。特定的CDN可以只具有一个层。从任意层中的缓存的角度来看，下一个内部层中的缓存被认为是其父缓存。因此，例如，在图21C中的示例中，群集层中的缓存是边缘层中的缓存的父缓存。类似地，区域层中的缓存是支架层中的缓存的父缓存。通常，如果存在标记为T1至Tn的n个层(其中，Tn是最外面的层或边缘层)，则层Ti中的缓存是层Ti+1中的缓存的父缓存。相同层中的缓存被称作对等缓存。在图21C中的示例中，层如下：层层名称T0区域层T1支架层Tn-1群集层Tn边缘层将这些缓存组织为层可以与缓存的物理方面相对应，这些方面包括例如：其相对位置、它们与该网络以及其他网络相连的方式、其速度、容量、类型等。缓存也可以被组织为一个或多个区域(在附图中标记为“区域1”、“区域2”等)。图21C中的区域与图9中的组相对应。也可以基于缓存的物理方面(例如，地理位置)来进行区域/组的组织，但是可以由于其他组织原因(例如，为了实现策略)来进行区域/组的组织。虽然在附图中示出了六个示例性且不同的区域/组，但是本领域技术人员在阅读该描述之后将认识和理解的是，可以使用任意数量的区域/组，包括重叠区域。本领域技术人员在阅读该描述之后还将认识和理解的是，区域可以具有不同的大小并且一些区域可以不包括所有层中的缓存。例如，特定国家中的缓存可以被视为处于一个区域中以执行针对该国家的内容传送策略。这些缓存也可以被视为处于一个或多个区域中以代表内容提供商执行内容传送策略。这些区域(国家区域和内容提供商区域)可以重叠。图21D示出了以其各个角色操作的图21A的CDN系统的各个组件。图21D包括会合机制(在附图中使用星号标记)。如上所述，当前优选的会合机制是使用DNS系统实现的，并且优选地用于选择或识别向给定客户端提供服务的“最佳”或“最优”群集。优选地，“最佳”缓存选择在DNS查找时发生。图21D示出了在CDN中发生的三种典型的操作。在附图的左侧(并且如图21E中更详细地所示)，控制核心群集(优选地响应于从缓存区级中分层地提取数据)向各个缓存群集分发控制数据。在附图的右上方(并且如图21F中更详细地所示)，缓存群集正在执行内容传送。在附图的底部(并且如图21G中更详细地所示)，收集器机制正在从缓存群集收集信息。图21H示出了边缘层中的缓存(A00、A02、A03)的分层操作，从而经由CDN分层体系中的缓存从源服务器提取资源并且从控制核心提取控制/业务数据。类似地，收集器经由CDN分层体系(实质上在另一方向上)从边缘缓存提取业务。图10示出了向CDN外部的客户端进行内容传送的一般过程。图22示出了CDN内的相同过程。可以看出并且如上文关于图10所述，在CDN内部和CDN外部，资源请求的处理是相同的。客户端2210(其可以是任何CDN组件，包括：缓存、收集器、控制核心等)想要来自源(其也可以是任何CDN组件，包括：缓存、收集器、控制核心等)的对象。客户端请求被导向CDN中应当具有该资源的位置。该位置也可以是任何CDN组件，包括：缓存、收集器、控制核心等。如果该位置不具有请求的资源，则它从协同服务器(即，从该资源的权威源)得到该资源的副本。虽然客户端2210和协同服务器2212被示出为在用方框标记的CDN100的外部，但是在该示例中，它们位于该方框内(它们被示出在外部以便于描述)。计算至少部分地通过在CDN100的一个或多个计算机上运行的软件来执行如图所示并且如上所述的操作和动作。本领域普通技术人员在阅读该描述之后将容易清楚和理解的是，可以通过例如适当编程的通用计算机、专用计算机和计算设备来执行本文所述的各个过程。一个或多个此类计算机或计算设备可以被称作计算机系统(如上所述，图23示出了典型的计算机)。计算机2302包括经由总线2316连接的一个或多个处理器2306、存储器2308、存储设备(例如，磁存储设备)2310等。计算机2302还可以包括外围设备2314，例如，键盘、显示监控器、打印机等。计算机2302可以经由网络接口2312连接到网络或者其他计算机或设备。如本文所使用的，“处理器”意味着一个或多个微处理器、中央处理单元(CPU)、计算设备、微控制器、数字信号处理器等设备或者其任意组合，而不论其架构如何。执行处理的装置可以包括例如处理器和适合于执行处理的诸如输入设备和输出设备等的设备。本文所述的各个程序通常将作为程序2320驻留在一个或多个计算机的存储器2308中。可以用多种方式使用多种介质(例如，计算机可读介质)来存储和传输执行此类方法的程序(以及其他类型的数据)。硬布线电路或定制硬件可以替代可以执行各个实施例的处理的软件指令中的一些或全部来使用或者与这些软件指令中的一些或全部结合使用。因此，可以使用硬件和软件的各种组合而不仅是使用软件。如本文中所使用的，术语“计算机可读介质”是指参与提供可以由计算机、处理等设备读取的数据(例如，指令、数据结构)的任何介质、多个此类介质、或者不同介质的组合。此类介质可以具有很多形式，包括但不限于：非易失性介质、易失性介质、和传输介质。非易失性介质包括例如光盘或磁盘以及其他永久性存储器。易失性介质包括动态随机存取存储器2308，其通常构成计算机的主存储器。传输介质包括同轴电缆、铜线和光纤，其包括包含耦合到处理器的系统总线的电线。传输介质可以包括或传送声波、广播和电磁发射，例如，在射频(RF)和红外线(IR)数据通信期间生成的那些。常见形式的计算机可读介质包括例如磁盘、磁带、任何其他磁介质、CD-ROM、DVD、任何其他光学介质、具有孔图案的任何其他物理介质、RAM、PROM、EPROM、FLASH-EEPROM、任何其他存储器芯片或带盒、如下所述的载波或者计算机可以对其进行读取的任何其他介质。各种形式的计算机可读介质可以参与向处理器运送数据(例如，指令序列)。例如，数据可以(i)从RAM传送到处理器；(ii)通过无线传输介质来运送；(iii)根据大量格式、标准或协议被格式化和/或传输；和/或(iv)以本领域公知的多种方式中的任意一种方式来加密。计算机可读介质可以(以任何适当的格式)存储适合于执行方法的这些程序元素。本领域普通技术人员在阅读该描述之后将容易清楚和理解的是，装置的实施例可以包括可以操作以执行所述处理中的一些(而不一定全部)的计算机/计算设备。存储程序或数据结构的计算机可读介质的实施例包括存储这种程序的计算机可读介质，当执行该程序时，该程序可以使处理器执行所述处理中的一些(而不一定全部)。在本文描述处理的情况下，本领域技术人员将清楚的是，处理可以在没有任何用户干预的情况下操作。在另一实施例中，处理包括一些人为干预(例如，在人为帮助下或者通过人为帮助执行步骤)。执行机构预期在CDN中，具有10Gb/秒链路针对每一个客户端供应约1Mb/秒的缓存机器应当能够为10,000量级的并发客户端提供服务，其中，针对每一个客户端，约十(10)个活动。这需要100,000量级的并发活动。发明人认识到，为了使缓存机器(因此CDN)有效地操作并且利用新的多核计算机架构，缓存机器将必须执行某一有效形式的并发。更具体地并且基于其对CDN的体验，发明人认识和理解到，网络应用(例如，在CDN中供应和分发内容)通常需要较长的等待时段。因此，发明人认识到，执行很多小工作以便提高效率将是有用的(即，在CDN缓存的情况下，同时进行几十件或者甚至无数件事情将是有利的)。发明人还认识到，同时保持所有处理器(CPU)活动将是有用且有利的。发明人认识到，在这种类型的应用中处理单独的请求通常是由通过相对长的等待时间(长在这里是相对于现代CPU的速度而言的)分离的少量计算构成。因此，虽然请求正处于等待阶段，但是其他请求可以处于计算阶段，从而使CPU保持繁忙。然而，发明人基于其对CDN的体验还认识到，不是所有请求都需要长等待时间，并且在不存在长等待时间的情况下，假设始终存在长等待时间的并发方案将使这些请求处于不利地位。发明人还认识到，在缓存中使用的并发方案可以利用缓存被预期执行以改善性能的这种类型的工作。例如，大多数网络应用具有类似的结构并且大多数网络操作具有毫秒量级。缓存可以执行有用的操作同时等待相对较短的网络操作或磁盘操作完成。(磁盘操作有时花费比毫秒更长的时间。)此外，联网(和诸如互联网等的大型网络中的定时)是固有地且在很大程度上不可预测且不可靠。为了处理这些方面，优选的并发方案应当支持异步性(以处理不可预测的定时)和组织的例外处理(以处理大量潜在的失败模式和网络的不可靠性)。发明人认为诸如一个线程每客户端等的方法对于可操作CDN中的真实缓存的艰巨任务太有限。在线程每客户端模型中，每一个客户端消耗过量的系统资源同时花费其大部分时间等待(网络或磁盘I/O)。线程每客户端方法具有其他缺点。例如，pthread针对每一个线程需要最小16KB的堆栈，这暗指针对预期10,000个并发客户端使用1.6GB。本领域技术人员在阅读该描述之后将认识和理解的是，针对并发性的这些其他方法可以对小缓存或CDN起作用，但是它们扩展得不好。因此，虽然所公开的执行方法是优选的，但是其他方法被设想并且可以被使用。执行机构的当前优选版本假设具有64字节缓存线的64比特的CPU。对基本数据结构均进行缓存线大小规定和对齐。虽然该方法关于取回数据、四处移动数据和存储数据改善了效率，但是该方法可能造成了数据结构中的数据字段的一定过载。本领域技术人员在阅读该描述之后将认识和理解的是，可以使用其他实现。任务、事件和vcore(虚拟CPU核心)执行机构中的基本对象是任务、事件和vcore(虚拟CPU核心)。图24A至图24B示出了执行机构的任务、事件和vcore之间的关系。在一些方面，虚拟CPU核心或vcore可以被认为像具有一些数据的pthread。可能存在任意数量的vcore，但是当针对每一个物理核心存在一个vcore(其中每一个vcore绑定于固定物理核心或者与固定物理核心相关联)时，执行构件预期是最有效的。为了支持同步，向每一个vcore指派vcore标识符(vid)，并且每一个任务具有指定该任务所属的vcore的vid字段。每一个任务具有相应的输入事件列表。例如，如图24A中所示，任务块T具有三个事件(在附图中标记为E1、E2、E3)的列表。每一个vcore具有称作其运行队列的任务优先级列表。例如，图24B示出了第二个vcore，其中，运行队列包括多个任务(标记为T1、T2、T3)，每一个任务具有相应的事件列表(E11针对任务T1、E21和E22针对任务T2，并且E31针对任务T3)。一个任务(T4)当前正在运行，并且多个任务(T5、……、T6)正在等待。图24A中的任务块T被示出为具有VID＝2(即，任务与第二个vcore相关联)。通过函数指针(f)、数据指针(d)和一些其他(例如，任务计费)信息描述执行机构任务。可以通过调用数据的函数(例如，f(d))来运行任务。每一个任务具有任务标识符或称号(tid)。参照图24C中的示例性的任务结构，优选地将任务封装在128字节的结构中，并且通过4字节整数任务称号(“tid”或任务id)来标识任务。信道是特殊类型的执行机构任务。信道任务包含针对“信道信息块”(chib)的指针。每一个chib是信道类型特有的，并且包含用于以下各项的方法：●卸载(异步的)、提交(可以是同步的)、以及返回(传送)事件(其中，正在从另一信道向一个信道返回正在返回的事件)●超时●关闭、消除●迁移●创建入口点●以及各种其他情况。信道具有标志集合以及针对chib的踪迹(wake)/chib点。用户任务不具有标志、用于提醒本质(predicate)的踪迹/chib点(这是前面提到的字段过载的示例)。Prio确定任务被放置在运行队列上的位置。当前支持以下信道类型：●网络○serv被动监听程序○conn活动连接○udp数据报○resolvDNS解析器●异步I/O○aiosaio从○aioaio主●HTTPHTTP○fpnsh_connHTTP解析器和格式化器●例如专用于缓存的应用：○排序程序信道(管理处理程序的运行)○各种Lua有关的信道(处理Lua引擎并且运行Lua引擎)在一些实施例中，异步IO信道可以由IO库来执行。可以不使用aios和aio，并且单独的非执行机构库(libfpio)将处理异步I/O。如本文所使用的，“cid”是指“信道id”，“tid”意味着“任务id”。实际上，“cid”字段可以用作“目的地”地址，并且“tid”字段用作事件的源地址。存在任务间和信道间通信这两种情况，其中，“cid”实际上可以是任务id，反之亦然。优选地，对任务结构进行缓存对齐。在附图中，函数指针被标记为func。任务结构具有额外64个字节用作暂存(scratch)空间。存在48+64个字节供任务自由使用，但是给定任务始终自由地为其自身分配更多的内存并且通过将指针放置在任务结构中来对其进行跟踪。每一个任务包含参考计数器(refs)，并且如果在其参考计数器被设置为0(refs＝＝0)的情况下来派遣任务，则任务消逝。参考(也称作“cid”或信道id，也称作“tid”)是任务的整数id的副本，并且是在创建任务时或者当任务自身调用ns_tid_alloc()时被创建的。当在关闭或丢弃或任务自身调用ns_tid_free()期间返回任务时，参考被消除。参考是不应当被复制或消除并且应当被仔细地跟踪的能力。在事件的tid和cid字段中使用参考。执行机构使用计数参考来防止失效的参考(它们是模拟锁的执行机构)。事件是消息块(优选地，128个字节，包括针对暂存空间的64个字节)并且包含两个任务参考(两个tid)，一个用于发起方任务(tid)，另一个用于目标任务(cid)。64字节的暂存空间可以被划分为内部暂存空间和外部暂存空间。事件可以被链接在一起。在操作中，每一个vcore线程运行无限循环，并且：●从其运行队列中取回(例如，取出)最高优先级任务t；●调用t->f(t)；●调用ns_dispatch(t)，以重新排列、消除或丢弃任务t。下面两个规则应当确保内存一致性：●访问规则：如果另一任务具有与你相同的vid，则你可以安全地访问其数据。●迁移规则：仅vcoren可以将vid值改变为n或者从n改变vid值。在主机上通过为该主机创建适当数量的vocre然后启动第一任务来启动执行机构。例如，为了使用n个vcore启动执行机构，调用：ns_begin(first_task_func,n)；第一任务例如按如下方式创建并且启动更多任务和信道：任务和信道创建事件并且彼此通信：任务、信道和事件根据需要被创建和消逝。ns_task()；ns_chan()；ns_event()；returnns_die()；在优选的实现中，执行机构将在最后一个任务退出时退出。在执行机构中存在两种类型的通信，本别是，保证异步通信和潜在异步通信。保证异步通信将事件放置在目的地任务的输入队列上，并且唤醒目的地任务，即，将其放置在运行队列上。目的地任务(稍后)运行并且事件返回到达源任务的输入队列上。应当清楚的是，源任务可以选择“异步地”发送事件(也即是说，不具有tid)，在该情况下，将不返回响应。另一个选项是使源任务提供某一第三任务的tid，其中，一旦目的地任务随之完成，就将事件传送到该第三任务。这种类型的通信是轻载的且无阻塞的。例如，ns_event_dropoff(e)使用e->cid作为目的地；ns_event_deliver(e)使用e->tid作为目的地。基本上，任务使用ns_event_dropoff以将事件卸载到信道，并且任务使用ns_event_deliver以将事件返回至发送它们的不论哪个任务。例如通过下式调用潜在异步通信：e＝submit(e)。该方法按如下方式工作：S1将事件传递到目的地任务S2暂停当前任务S3取而代之地执行目的地任务S4事件指针作为函数返回值被返回S5恢复当前任务。潜在异步通信可以通过在步骤S4中返回空指针并且稍后传送事件而变得异步。如果例如目的地任务不在相同的vcore上或者在一次运行中存在太多的工作要做或者任务需要等待内部异步操作，则通信恢复异步。目的地不知道/关心它是经由dropoff()(即，作为保证异步的)还是submit()(即，作为潜在异步的)被调用的。事件始终到达输入队列，其中，经由ns_next_event()来访问输入队列。信道使用ns_event_deliver()来返回事件。如果目的地是信道，则它可以知道事件是被卸载还是被提交，这是因为这些是可能过载的分离chib入口点。例如可以使用以下代码来传送事件：该示例说明对参考计数的关注。因为some_cid表示参考并且该参考已经被传输到e->cid，因此some_cid的值被归零。例如，可以按如下方式在函数中回绕该事件传输：事件驱动的程序下面的代码示出了用类“C”语言呈现的执行机构任务函数的基本“循环-切换”提要：下面的示例性代码示出了具有submit()的执行机构任务函数的基本“循环-切换”提要：图25A至图25B将执行机构提交操作的执行机构堆栈与C程序调用的堆栈进行比较。执行机构提交操作(e＝submit(e))与C程序调用类似，重要的区别是当事件被提交时存在变得异步的选项。执行机构的任务块与C堆栈帧类似。执行机构的事件块与C的arg和返回地址区域类似；并且执行机构的tid&标签与C的返回地址类似。然而，在执行机构中，多次调用可能是同时活动的，并且帧可以存在至调用之后。这允许写潜在异步挂钩，例如：e＝submit_op_foo(e,args)；可以使用被称作spec的参数块来创建信道，例如：可以通过返回refs来关闭信道，例如：直到所有refs都已经被返回，才消除信道。全局交换(参见图26)可以用于在vcore之间传送指针所有者。键入的指针被封装到缓存线中，这些缓存线用于经由互斥保护队列有效地传送指针。虽然多种技术用于使全局交换有效，例如，通过使用单个锁定事务传送多个消息来摊销锁定成本、对队列进行无锁检查以查看是否可能存在数据(仅当看到数据时才需要锁)等，但是应当清楚的是，“直接交换”是优选的，并且可以使用无锁技术来创建涉及的队列。下面的示例示出了任务迁移中的同步。在该示例中，任务t想要从vid＝2迁移至vid＝3。●首先t->vid＝2。●tfunc设置t->vid＝1003并且返回Executive_RUN。●ns-dispatch()通知t->vid！＝2并且将(t，RUN,3)放置在全局交换上。●全局交换将三倍传送至vcore3。●Vcore3设置t->vid＝3并且将任务添加至其运行队列。注意，t->vid被设置为1003。执行机构提供多核解决方案，在该多核解决方案中，每一个处理器(CPU)具有可以在该处理器上(在该处理器上的vcore——虚拟核心中)运行的任务队列。处理可以检查其他处理是否正在相同的核心上运行然后确定信息/与这些处理共享信息。在先前的并发/并行处理系统中，当任务或处理完成时，它们被移交并返回。特别在CDN的上下文中，缓存处理的重要方面是一些任务可以立即完成。在这些情况下，没有原因延迟返回。换言之，如果知道任务可能立即完成其处理(即，相对快速地)，则可以使该任务无延迟地提供其结果。使用该技术的一个示例是当Lua脚本被执行时：在很多情况下，脚本可以执行很小的操作使得它实质上可以立即完成，这节省了需要将其作为任务进行调度的开销(除非这变得必要)。该技术的另一个示例是在排序程序信道中：如果一系列处理程序快速地运行，则调用排序程序实质上是函数调用。仅当处理程序需要等待数据或者如果需要完成太多计算时，排序程序才将变为调度任务。可以通过以下方式来完成这一点：该方法(如果可以，则立即执行该方法，否则稍后给我提供答案)提供了针对缓存特有的问题的潜在异步解决方案。此外，以“潜在异步的”方式进行编程意味着如果稍后确定一些特征或方面(其先前是同步的)需要变得异步，则可以在无需重写其他代码的情况下完成这一点。本领域技术人员在阅读该描述之后将认识和理解的是，该方法存在成本损失/风险，例如，如果在给定情形中仅采用同步路径，则异步路径可能未经测试或者如果先前同步操作变为异步，则应用的性能可能下降。然而，例如，可以通过迫使一切变为异步以用于测试的目的来消除这些风险。在一些优选的实施例中，执行机构是使用有时称作Shell或NetShell的系统来实现的。应当清楚的是，本文所述的执行机构和NetShell与任何其他实体的任何产品或工具无关。具体地，如本文所使用的，NetShell不是指Microsoft公司的可编写脚本的命令线工具，执行机构或NetShell也不是指Unixshell等的用户接口。虽然已经结合当前被认为最实际且优选的实施例对本发明进行了描述，但是应当理解的是，本发明不限于所公开的实施例，相反，本发明旨在涵盖所附权利要求的精神和范围内包含的各种修改和等同布置。当前第1页1 2 3