专利名称：服务器负载平衡系统、装置以及内容管理装置的制作方法
技术领域：
本发明涉及服务器负载平衡，特别是一种用于服务器负载平衡的系统和装置，以及一种内容管理装置和—种用于选择最优服务器的内容服务器，关于一个来自客户端用来获得传送内容的请求，例如WWW(万维网)内容或者流送内容，并且发送上述请求到达所选择的服务器。
背景技术：
最近，在通过Internet传送WWW内容以及流送内容的过程中，已经提出了各种方法，通过将相同的内容分配到若干服务器，用来分配服务器负载以及缩短客户端的响应感知时间。
当在一个网络中分配内容的境况下，存在一个服务器负载平衡装置是必要的，其中该服务器负载平衡装置用来确定哪个服务器发送用于获得内容的客户端请求。
常用的技术中，一种通过模拟和分配每一条用户端请求以便于防止服务器上的额外负载及过载现象来为每一项服务预测一个服务器负载的装置已经在日本出版物平开专利No.2001-101134中公开。在上述出版物所公开的装置中，仅需要考虑服务器负载就能选择目的服务器，并且可为每一项服务选择一个目的服务器。
此外，一种在客户端中选择目的服务器的方法也在日本出版物平开No.Heisei09-198346中公开。在上述出版物所公开的服务器选择方法就是通过将一个选择策略存入到目录服务器的一条查询消息中来处理由各个客户端所发出的不同服务器选择请求。收到所述查询后，该目录服务器根据存储在消息中的选择策略选择最优服务器，并且响应客户端。该方法是在客户端一侧的选择方法，因此，该客户端必须引入该方法。若服务器负载平衡装置能够支持不同的选择标准如在上述方法中所述的，则可以使用过滤方式实现相同的服务而不需要改变客户端—侧的方法。
然而，在上述常见技术中存在下述问题。
首先，在一个内容服务器中，并不需要根据各个特性对内容进行分组，即使已经被分组了，也仅仅是根据其静态特性来进行分组的。
通常，通过对内容服务器中的内容进行安排可以很容易的通过内容管理器对内容服务器进行控制，并且并不是从每个内容的特性角度来对其进行分组。例如在一条有关新闻的目录“news”下，通常，不同的内容例如文章、图片，以及新闻图像会以固定的方式来对其进行安排，它们在文件大小和媒体类型方面具有不同特性。而并不需要考虑动态特性(参数)例如对每条内容的存取频率。这时，在客户端一侧的服务器负载平衡装置中，若选择相同的内容服务器作为“/news/”内容的目的地，则从内容延迟得到方面来看该选中的服务器很有可能并不是最优的服务器。因此，目的服务器的选择应当由各个内容组来进行，其中各个内容组从内容大小及存取频率方面来看具有相同的特性。
其次，在服务器负载平衡装置中，不可能依据每条内容的特性来改变目的服务器的选择标准，因此不会出现有效的负载平衡。
在常见技术中，目的服务器的选择标准是固定的并且不能根据每一条内容的特性加以改变。例如，若考虑到包括小内容以及大内容的两种内容时，对于小内容情况来说，客户端的响应时间很大程度上取决于传输路径中的延迟，而对于大内容情况来说则是很大程度上取决于传输路径中的可用带宽。这种情况下，已有技术不能对两种或者更多种类的内容使用不同的选择标准。
第三点，当位于用户端的各个服务器负载平衡装置分别选择了一个目的服务器时，负载集中在同一个服务器上，因此传送质量也会受到影响。
尤其是，在传送连续介质内容例如流或是声音的情况下，当存取集中在同一服务器上时，就不能获得所期望的传送质量并且必需重新选择一个目的服务器。而且，当所有线路在传送期间被立刻转换时都会出现摆动现象，如由于转换后存取会集中在一个新的传送服务器上而再次导致传送质量的恶化并在另一个传送服务器上重复执行转换操作。
第四点，由于诸如通过内容或者内容组来选择目的服务器的服务器负载平衡装置必须在查看到来自客户端的请求内容后确定一个目的服务器，因此必须使用7层转换。
如果使用7层转换，则可以将来自客户端的每—请求分配到为每一内容设置的目的服务器中，但是其性能比较差，并且与使用较低层例如3层转换和4层转换的装置相比较其成本较高。因此，最好就是能够通过使用较低层转换的装置来实现相同的功能，而不需查看请求内容。
发明内容
为了解决上述常见技术中存在的问题，本发明的第一个目的是提供一种服务器负载平衡系统，一种内容管理装置，以及一种在内容服务器中能够以动态及静态的方式根据它们的特性自动进行分组的内容管理程序。
为了解决上述常见技术中存在的问题，本发明的第二个目的是提供—种服务器负载平衡系统，一种服务器负载平衡装置，以及一种能够根据每一内容特性改变目的服务器选择标准的服务器负载平衡程序。
为了解决上述常见技术中存在的问题，本发明的第三个目的是提供一种服务器负载平衡系统，一种服务器负载平衡装置，一种内容服务器，以及一种能够适当进行分配处理以便于防止在连续介质内容传送过程中负载集中在某一指定的服务器上的内容传送管理程序。
为了解决上述常见技术中存在的问题，本发明的第四个目的是提供一种服务器负载平衡系统，一种服务器负载平衡装置，以及一种能够通过内容组来选择目的服务器而不需要7层转换功能的服务器负载平衡程序。
根据本发明的第一方面，—种用于向多个内容服务器中的一个客户端分配内容发送的服务器负载平衡系统，包括用于确定内容服务器的装置，通过至少使用关于该内容服务器的内容和资源信息特性而将来自客户端的内容传送请求目的地传输给该内容服务器。
在优选结构中，根据资源信息的改变再次确定向其传送来自客户端的内容传送请求的内容服务器。
在另一优选结构中，所述来自客户端的内容传送请求被发送到该内容传送请求将被发送到的内容服务器，该内容服务器为该内容而设置。
在另一优选结构中，基于来自客户端的信息包的目的IP地址以及目的端口号，该由客户端请求的内容被确认并且将该信息包发送到为所述内容设置的内容服务器中。
在另一优选结构中，内容服务器传送的内容根据其特性被分成若干组，并且分成上述组的内容被收集在一块并分到每一组中。
根据本发明的第二方面，用于从若干内容服务器中选择一个向客户端传送内容的内容服务器的服务器负载平衡装置包括用于确定内容服务器的装置，通过至少使用所述内容的特性和关于所述内容服务器的资源信息而将来自客户端的内容传送请求传输给所述内容服务器。
在优选结构中，所述资源信息至少包括一个或多个资源参数，通过使用第一资源参数来预测或提取与第一资源参数不同的第二资源参数，并且该资源信息也包括预测或提取出的第二资源参数。
在另一优选结构中，所述目的服务器确定装置通过使用客户端所请求内容的URL或部分URL来获得用于所述请求目的地的候选内容服务器，并且从候选内容服务器中确定向其传送内容的内容服务器。
在另一优选结构中，所述部分URL是URL的词头即URL的报头部分或者URL中文件的扩展名再或者是两者的结合。
在另一优选结构中，通过对存在于网络或用于管理内容服务器中的内容的内容管理装置中的内容服务器进行查询，该目的服务器确定装置获得用来传送客户端请求内容的候选内容服务器。
在另一优选结构中，通过对存在于网络或用于管理内容服务器中的内容的内容管理装置中的内容服务器进行查询，所述目的服务器确定装置获取所述客户端的特性。
在另一优选结构中，所述目的服务器确定装置通过使用将由请求获得内容的URL或者URL的一部分生成FQDN，获得一个用于该FQDN的IP地址列表，其中FQDN作为密钥，并且将相应于列表中每一IP地址的内容服务器规定为候选服务器，用于传送由客户端请求的内容。
在另一优选结构中，从DNS服务器获得所述用于FQDN的IP地址列表。
在另一优选结构中，在将所述信息包的目的IP地址改变为内容服务器的IP地址之后，其中的内容服务器被确定作为向客户端传送内容的内容服务器，一个由客户端发送的、用来请求内容传送的信息包被传输到所述内容服务器。
在另一优选结构中，在解析了相应于所述内容服务器IP地址的MAC地址之后，其中的内容服务器被确定作为向客户端传送内容并将所述信息包的MAC地址改变为解析后的MAC地址的内容服务器，一个由客户端发送的、用来请求内容传送的信息包被传输到所述内容服务器。
在另一优选结构中，根据资源信息的变化，重新确定向其传送由客户端接收的内容发送请求的内容服务器。
在另一优选结构中，通过至少使用所述内容的特性以及资源信息，优先级别被设置在向其传送由客户端接收的内容发送请求的各个内容服务器中。
在另一优选结构中，根据所述资源信息的变化重新设置优先级别。
在另一优选结构中，考虑到当前的优先级别，在根据各个内容服务器的资源信息重新设置优先级别之前，来自当前优先级别的波动被限制为一个常数级别，并接下来重新对优先级别进行设置。
在另一优选结构中，重新设置优先级别的时间被延迟了一段随着概率变化的时间，并在该延迟时间重新设置优先级别。
在另一优选结构中，在所述延迟时间，重新判断是否重新设置优先级别，并且当确定重新设置优先级别时，重新对优先级别进行设置。
在另一优选结构中，所述服务器负载平衡装置包括用来确定向客户端发送内容的内容服务器的装置，这是基于从客户端接收到的、用来请求内容传送的信息包的目的IP地址以及目的端口号，并且将接受到的用来请求内容发送的信息包传输到确定的内容服务器，其中FQDN唯一指示目的IP地址以及目的端口号，是通过使用接收到的信息包的目的IP地址以及目的端口号的信息来重新生成，候选内容服务器用来将内容发送到客户端，该服务器是接收到的信息包的传递目的地并通过对使用重新生成的FQDN作为密钥的DNS服务器进行查询来获得，以及从候选内容服务器中确定用来向客户端发送内容的内容服务器。
在另一优选结构中，通过对使用目的IP地址作为密钥的DNS服务器进行查询来解析FQDN，通过使用解析后FQDN以及目的端口号的信息来重新生成唯一指示目的端口号以及解析后FQDN的FQDN，通过对使用重新生成的FQDN作为密钥的DNS服务器进行查询来获得一个IP地址列表，并将该列表定义为用来向客户端发送内容的候选内容服务器，以及从候选内容服务器中确定用来向客户端发送内容的内容服务器。
在另一优选结构中，通过对使用目的IP地址作为密钥的DNS服务器进行查询来解析FQDN，通过对使用解析后的FQDN作为密钥的DNS服务器进行查询来获得一个IP地址列表，并将该列表定义为用来向客户端发送内容的候选内容服务器，以及从候选内容服务器中确定用来向客户端发送内容的内容服务器。
在另一优选结构中，所述服务器负载平衡装置进一步包括用来接收来自客户端的请求内容发送的信息包的信息包接收装置，以及信息包传输装置，该装置将信息包接收装置接收到的信息包的目的IP地址重新写入到用于将被请求内容发送到客户端并传输到内容服务器中的内容服务器的IP地址中。
在另一优选结构中，所述信息包传输装置对相应于用于向客户端发送请求内容的内容服务器的IP地址的MAC地址进行解析，并且在将由信息包接收装置接收到的请求内容传送的信息包的目的MAC重新写入到解析后的MAC地址中之后，将该信息包传输给该内容服务器。
根据本发明的第三方面，一个用来传送内容的内容服务器，包括向一个节点通知将一个计算后的实际资源值的校准值作为资源信息的装置，用来基于关于各个服务器的资源信息选择内容的发送目的地。
根据本发明的另一方面，一个用来对由内容服务器传送的内容进行管理的内容管理装置，包含用来根据内容的特性将由内容服务器传送的内容分成多个组的内容分类装置，以及用来在各个组中将分类到各组中的内容集中到一块儿的内容分组装置。
在另一优选结构中，所述内容分类装置根据特性对所述内容进行分类。
在另一优选结构中，所述内容分类装置根据所述内容特性的分类逐步变细粒度的分级结构逐步对内容进行分类。
在另一优选结构中，所述内容分组装置将同一目录下的已分类内容一块儿集中到相同的组中。
根据本发明的另一方面，一个用来通过控制一台计算机，分配内容发送到多个内容服务器中的客户端的服务器负载平衡程序，包括一个涉及具有内容特性与有关内容服务器的资源信息之间对应关系的内容服务器的选择标准的功能，以及一个根据所述请求内容的特性以及资源信息、基于选择标准确定用来发送客户端请求内容的内容服务器的功能。
根据本发明的另一方面，一个用来通过控制一台计算机，管理传送内容的内容服务器的内容传送的内容传送管理程序，包括一个向一个节点通知将一个计算后实际资源值的校准值作为在这一点的可用资源信息的功能，并用来根据服务器的资源选择内容的传送目的地。
根据本发明的另一方面，一个用来通过控制一台计算机，对内容服务器传送的内容进行管理的内容管理程序，包含一个用来根据所述内容的特性将内容服务器传送的内容分成多个组的内容分类功能，以及一个用来在各个组中将分到各组中内容集中一块儿的内容分组功能。
本发明的其它目的、特征和优点将在随着下面的详细描述而变得更加清楚。
本发明将随着下面给出的详细描述以及本发明的优选实施例的附图而被理解得更充分，然而这却不造成对本发明的限制，而只是作为一种解释和理解。
附图中图1为本发明第一实施例的结构方框图；图2给出了依据本发明第一实施例，由一个分类策略设置单元设置的分类策略的一个例子；图3给出了依据本发明第一实施例，由一个内容分组单元执行的URL重写入处理的例子；图4为依据本发明第一实施例内容管理装置的操作过程流程图；图5给出了实现本发明第一实施例的内容管理装置作为内容服务器一部分的功能的一个例子；图6给出了多个内容服务器与本发明第一实施例的内容管理装置相连接的例子；图7为本发明第二实施例的结构方框图；图8为依据本发明的第二实施，用来确定由目的服务器确定策略设置单元设置的目的服务器的策略的一个例子；图9为依据本发明第二实施例，一个注册在请求路径表格中的项目的例子；
图10为依据本发明第二实施例，一个从服务器负载平衡装置中的客户端接收一个请求的操作过程流程图；图11为依据本发明第二实施例，一个在所述服务器负载平衡装置的目的服务器确定单元中确定目的服务器的操作过程流程图；图12为依据本发明第二实施例，一个对注册在所述服务器负载平衡装置的请求路径表格中的项目进行管理的操作过程流程图；图13为本发明第三实施例的结构方框图；图14给出了依据本发明第三实施例，一个资源响应策略设置单元设置的资源响应策略的一个例子；图15为依据本发明第三实施例，在一个内容服务器中接收用于从服务器负载平衡装置获取资源的请求的操作过程流程图；图16为本发明第四实施例的结构方框图；图17为依据本发明第四实施例一个在请求路径表中注册的项目的例子；图18为依据本发明第四实施例，一个服务器负载平衡装置的操作过程流程图；图19为依据本发明第四实施例，另一个服务器负载平衡装置的操作过程流程图；图20为本发明第五实施例的结构方框图；图21为依据本发明第五实施例一个在信息包路径表中注册的项目的例子；图22给出了依据本发明第五实施例，一个在地址/FQDN解析表格中注册的项目的例子；图23为依据本发明第五实施例，一个当客户端发送一个获得内容请求时的操作过程流程图，；图24为依据本发明第五实施例，一个在所述服务器负载平衡装置中接收一个来自客户端信息包的操作过程流程图，；图25为依据本发明第五实施例，在信息包路径表格中生成一个项目的操作过程流程图，；图26给出了依据本发明第二实施例的网络结构；图27给出了依据本发明第三实施例的网络结构；
图28给出了依据本发明第三实施例的请求路径表格的一个例子；以及图29给出了依据所给出的本发明第四实施例，在请求路径表格中生成目的服务器项目的例子。
具体实施例方式
本发明的优选实施例将随后参照附图进行较详细描述。在下面的描述中，阐明了许多细节以便于对本发明有更好的理解。然而，对本领域普通技术人员来说显而易见的是，没有这些特定的细节本发明也是可以实现的。其他情况，为了使本发明避免不必要的描述没有对公知结构进行详细介绍。
根据图1，本发明的第一实施例通过一个内容服务器A1和一个内容管理装置B1实现。能够存取内容服务器A1上的内容的客户端D1通过中枢网络1与内容管理装置B1相连接。
所述内容服务器A1包括存储单元A11以及动态参数存储单元A16。所述内容存储单元A11存储传送内容本身例如WWW内容和流送内容，附有内容的程序，程序执行所需的数据库等等。每条内容都根据客户端一侧的标识符来识别，例如在HTTP(超文本传输协议)中，各个内容都由URL(统一资源定位)识别。所述动态参数存储单元A16存储所述动态参数(资源信息)作为动态特性例如存取频率以及用于各个传送内容的CPU负载，所述参数由内容管理装置b1指出。通过内容服务器A1不断更新所述动态参数内容。在下文中，所述资源值并不是必须为显示存取频率或者CPU负载的具体数字值，也可以是显示上述程度的信息。
所述内容管理装置B1包括一个分类策略设置单元B11，一个内容分类单元B12，以及一个内容分组单元B13。该分类策略设置单元B11根据其特性(静态特性例如内容的类型及大小以及动态特性例如存取频率)设置一个用来对包含在内容存储单元A11中的内容进行分组的分类策略。
这里，一个分类策略包含将不同内容大致分类的信息，例如任一媒体类型中的文件、流以及CGI(公共网关接口)。更进一步，其还可以包含对已分类信息进行更详细分类的分类信息。它可以是一个分类策略例如，文件根据其大小分为大、中和小，以及根据其传输率将流分为高、中和低。另一情况，其可以为根据动态特性将存取频率分类为高、中和低的一种策略。
图2为分类策略表格101的一个例子，给出了所述分类策略设置单元B11中设置的分类策略。例如，分类成文件的内容依据其大小被分成三组大、中和小，被分为大尺寸的组又进一步根据其存取频率而被分为两组高和低。更进一步，所述表格给出了各个URL，其中根据所设置策略分类的各个内容组被一块分组。
所述内容分类单元B12根据分类策略设置单元B11设置的分类策略对内容存储单元A11中的内容进行分类。在这次分类中，静态参数例如类型及大小能够由内容本身获得，动态参数例如存储在动态参数存储单元A16中的存取频率也被涉及。例如，内容被分为各种媒体类型，例如文件、流以及CGI。当为了各个媒体类型设置更详细的分类策略时，根据该策略将内容被分成多个依据例如文件大小及存取频率的内容组。
所述内容分组单元B13根据由内容分类单元B12自动对内容进行分类的结果对各个内容组中的内容进行分组，以采用URL的情况作例，通过使用内容存储单元A11中该内容所位于的目录来表示该URL。然而，由内容分类单元B12生成的内容组中的内容并不总是被一起分组到同一的目录下，但是对于客户端D1来说要识别该内容属于哪一内容组是比较困难的。因此，要执行重新写入URL的处理以便于在相同目录下的同一内容组中对内容进行安排。
在如图2所示分类策略表格101的一个例子中，示出了其中每个分类后的内容组应被一起分组的每个URL，并且例如所有被分类到CGI中的内容以及CPU的高负载被移动到“/cgi/high-load/”目录。
图3用于详细描述所述URL的重写入处理。例如，假设初始目录路径为“/pub/z.exe”的内容在根据所设置策略进行分类之后应当一起被分组到“/cgi/high-load/”目录下。生成具有目录路径“/cgi/high-load/z.exe”的内容作为指向“/pub/z.exe”的符号链接。更进一步，所有涉及“/pub/z.exe”的网页中的参考链接在分组后被重写入到所述目录路径中。
接下来，参照图4详细描述根据该实施例中内容管理装置B1中内容的特性进行自动分组的操作。
在所述内容管理装置B1中，内容分类单元B12将在分类策略设置单元B11中设置的内容分类策略(图4中步骤S101)读出，并且根据读出的分类策略将内容存储单元A11中的内容分成多个媒体类型(步骤S102)。
当将内容分成多个媒体类型之后，所述内容分类单元B12进一步将已经被分为多个媒体类型的内容分成多个内容组(步骤S103)。该步骤根据详细的特性例如大小以及存取频率对内容进行分类，涉及动态参数例如存储于动态参数存储单元A16中的存取频率。
当将内容分为媒体类型并且将各个媒体类型中的内容分为内容组之后，所述内容分组单元B13将内容分到各个内容组中(步骤S104)。
该实施例中，虽然将所述内容管理装置B1描述为一个在独立节点中实现的单元，但是其还能实现如图5示例的内容服务器A1的功能。更进一步，它还可以在包括第二实施例中描述的服务器负载平衡装置C1的某个节点上实现，并且它还可以具有网关功能。
更进一步，虽然上述叙述中已经描述了一个内容服务器A1与内容管理装置B1相连接的情况，可是多个内容服务器A1可以同时与内容管理装置B1相连接，如图6中示例，并且所述内容管理装置B1可以对各个内容服务器A1中的内容进行分类，并以此来管理内容。
下面将对该实施例的效果进行描述。该实施例中，所述内容管理装置B1依据其特性自动对内容服务器中的内容进行分类。该实施例的一个特点就是可以依据其动态特性进行分类。
更进一步，作为分类结果而生成的内容组被自动分组。内容服务器中的内容最初不是被分组到同一目录下的各个特性。例如，从文件大小以及媒体类型角度来看具有不同特性的内容例如文章、图以及新闻图片，通常都以一种混合的方式位于有关新闻的目录“/news/”下。
该实施例能够在同一目录下重新建立具有相同特性的内容组，并且当将在随后描述的位于客户端一侧的服务器负载平衡装置在各个目录下选择最优服务器时，对于内容特性最合适的请求路径能够通过最小数目的项目实现。
接下来，本发明的第二实施例随后将结合附图进行详细描述。参照图7，本发明第二实施例由内容服务器A2，服务器负载平衡装置C1以及客户端D1实现。
所述内容服务器A2包括用于存储多种传送内容的内容存储单元A11，请求接收/内容响应单元A12，以及资源响应单元A13。
请求接收/内容响应单元A12接收来自客户端D1的请求并且识别相应内容作为应答。接着，它发送上述内容到客户端。
资源响应单元A13应答来自服务器负载平衡装置C1的用于获取资源信息的请求，并且依据所请求内容返回资源参数例如服务器负载、连接数以及链接使用率。当服务器负载平衡装置C1没有请求所述内容服务器A2获得资源信息时，该资源响应单元A13就可以被忽略。
所述服务器负载平衡装置C1包括一个资源获得单元C11，一个目的服务器确定策略设置单元C12，一个目的服务器确定单元C13，一个请求路径表格C14，一个请求接收单元C15，一个请求传送单元C16，以及一个内容接收/传送单元C17。所述服务器负载平衡装置C1可以具有例如代理服务器的功能，其中代理服务器集中管理来自客户端的多个请求。
当没有任何关于内容服务器的资源信息在请求路径表格C14中注册时，例如目的服务器以及其他候选服务器，所述资源获得单元C11获取用于注册一个目的服务器的必要资源信息，或者获取有关在请求路径表格C14中注册的目的服务器及其它候选服务器的资源信息。所述资源信息包括例如，网络中的资源参数，例如网页服务器的RTT(往返时间)及传输处理量，以及有关服务器本身的资源参数，例如网页服务器的负载及连接数。这里大致有两种获取资源信息的方法。
一种方法就是请求信息例如CPU负载及来自内容服务器A2自身节点的剩余带宽以便于能够获得信息(主动类型)，另一种方法就是从所述内容接收/传送单元C17获取用于传送接收到的内容的延迟以及获取的传输处理量(被动类型)。通过使用该被动类型方法可以间接预测出服务器的CPU负载以及对话数量。
更进一步，还可以从已获取的资源参数中预测或者提取出另一资源参数。例如可以考虑下列方法；(1)考虑获取小内容的测量时间，例如RTT，以及(2)考虑程序运行时用于获得具有大负载的CGI内容的时间，例如服务器负载。
所述目的服务器确定策略设置单元C12设置一个目的服务器确定策略表格103，该表格给出了依据各个内容的特性选择目的服务器的各个策略。
图8给出了目的服务器确定策略表格103的一个例子，该表格示出了目的服务器确定策略设置单元C12中设置的策略。在目的服务器确定策略表格103中，对于具有文件特性的内容组，使用了获取内容时的传输处理量，并且以具有最大传输处理量的服务器作为参考，并且选择一个具有上述最大值60％或者更高的服务器作为目的服务器。对于具有CGI特性的内容组，采用了通过服务器RTT与CPU负载相乘而获取的数值，在该值的增加序列中选择了3个服务器。
目的服务器确定单元C13通过使用在目的服务器确定策略设置单元C12中设置的资源参数，从由资源获取单元C11获取的资源参数中确定一个目的服务器。
所述请求路径表格C14指出了由哪一个服务器来传输请求接收单元C15接收的请求。由目的服务器确定单元C13对表格的项目进行写入。
图9是指出所述请求路径表格C14的一个例子的表格104。在表格104中，相应于将要被请求的各个内容的URL的目的服务器的IP地址被写入。
例如，所述URL“//http//www.aaa.net/cgi/high/*”的项目是所述URL的词头表达式，表示所有具有“//http//www.aaa.net/cgi/high/”报头的URL。对应于该项目的请求被传输到其IP地址为“10.2.5.2”的内容服务器。URL“http//www.ccc.com/file/small/*.jpg”的项目表示“http//www.ccc.com/file/small”下所有的内容中具有jpg文件扩展名的内容。一个对应于所述项目的请求被传输到其IP地址为“10.4.2.1”或“10.2.5.2”的内容服务器。
当这样指定了多个目的服务器IP地址时，可以以循环的方法(round robinmethod)为每个请求选择一个服务器，或者通过使用加权循环(weighted roundrobin)或加权无用功能，根据为各个服务器指定的权数即所述优先级别比率来进行选择。
所述请求接收单元C15接收来自客户端D1的请求并且解析其中的内容。通过解析所述请求的内容，它能识别出客户端D1所请求内容的URL。更进一步，通过参照请求路径表格C14确定一个目的服务器来传输所述请求，并且把其交给请求传送单元C16。
在收到所述传输请求的内容以及来自请求接收单元C15的传输服务器信息时，该请求传送单元C16传输请求到内容服务器A2。
所述内容接收/传送单元C17从内容服务器A2接收相应于请求传送单元C16发送的请求的答复内容并且传输上述内容到客户端D1。
该客户端D1发出用于获取内容服务器A2中的内容的请求。该请求被发送给由服务器负载平衡装置指定的内容服务器A2。这里，所述客户端D1不只是包括一个客户端而是多个客户端。
在根据该实施例中服务器负载平衡装置C1的内容特性改变选择策略时，下面将参照图10至图12对选择目的服务器的操作进行详细描述。
首先，参照图10对服务器负载平衡装置C1从客户端D1接收一个用于获得内容的请求时的操作进行详细描述。
当请求接收单元C15接收一个来自服务器负载平衡装置中的客户端D1的请求时，它分析该请求并且对该请求内容的URL进行识别(图10中步骤S201)。
由所述请求接收单元C15检查在请求路径表格104中是否存在对应于所述请求内容的项目(步骤S202)。
在步骤202中，当存在一个对应于上述内容的项目时，所述请求接收单元C15读出传输请求目的地的内容服务器A2，涉及所述项目(步骤S203)。所述请求传输单元C16从所述请求接收单元C15中接收将要被传输的请求以及将要被传输的内容服务器A2的信息，并且将该请求传输给内容服务器A2(步骤S204)。
在步骤202中，当不存在对应于上述内容的项目时，所述请求接收单元C15传输该请求到一个默认服务器(步骤S205)，为含有该请求内容的内容组确定一个目的服务器，并且将目的服务器的项目写入到请求路径表格中(步骤S206)。这里，该默认服务器表示一个对应于所述包括该用作数据的请求的IP信息包的目的IP地址的服务器，以及一个对应于通过使用DNS服务器解析的IP地址的服务器，出自该请求中URL的FQDN(正式域名)部分。
图11为用于对上述步骤S206中的操作进行描述的流程图。
由目的服务器确定单元C13识别该被请求的内容属于哪个内容组并获得相应于该内容组的候选服务器列表(图11中的步骤S301)。作为该步骤中的识别/获得方法，还有一种通过对使用请求中全部或部分URL作为密钥的内容管理装置B1进行查询的方法以及一种直接查询内容服务器A2的方法。这里，候选服务器表示保存内容组的所有内容服务器A2或者是从保存内容组的所有内容服务器A2中提取出来的一个服务器组。
进一步，还有一种用来识别相应于URL的内容组以及通过使用DNS服务器来获得候选服务器列表的方法。在这种情况下，用于各个内容组的唯一FQDN被需要并且将相应于各个使用FQDN作为密钥的IP地址的内容服务器视为候选服务器。以生成用于各个内容组的唯一FQDN的方法为例，当相当于被请求内容的URL为“http//www.aaa.net/cgi/high/prog.cgi”时，该“high.cgi.www.aaa.net”被定义为相当于包括该内容的内容组的FQDN，并且使用FQDN作为候选服务器IP地址的密钥。
由该目的服务器确定单元C13识别该内容组遵循目的服务器确定策略设置单元C12中的哪一条策略并读取相应的目的服务器确定策略(步骤S302)。作为其相应的识别方法，以下面的两种方法为例。
(1)在步骤S301的查询内容管理装置B1过程中，一块儿获得该内容组的内容特征信息。
(2)在服务器负载平衡装置C1中准备有一个表格，该表格中示出了相应于各个URL的内容特征与同其进行映射的目的端口号之间的对应关系(例如，在其CGI中包括cgi-bin的内容组的内容特征为CGI并且具有目的端口号554的内容组的内容特征为流)。
根据在步骤S302中读出来的目的服务器确定策略，为了确定相应于内容组的目的服务器，该目的服务器确定单元C13通过直接从候选服务器中获得内容来获得资源，也就是检查该无源类型资源测量是否是必须的(步骤S303)。
以该无源类型资源测量是必须的情况为例，可以出现为了确定目的服务器而使用资源参数例如传送延迟及传送内容处理量的情况。相反，若该无源类型资源测量不是必须的，则会出现通过查询来获得资源参数例如服务器负载和链接带宽以及通过使用该结果来执行用于目的服务器确定的有效类型资源测量。换句话说，目的服务器可以以固定的方式通过无源类型资源测量和有效类型资源测量来确定。
在步骤S303，如果需要通过无源类型资源测量来检测目的服务器，则该目的服务器确定单元C13就会将该候选服务器写入到请求路径表格C14中(步骤S304)。
若在步骤S304中将候选服务器写入到请求路径表格C14中，该请求路径表格C14从候选服务器中选出一个内容服务器作为请求属于内容组内容的目的地。
这里，可以设置为通过循环的方法(round robin method)选择目的地而将请求传送给所有的候选服务器。通过将请求发送给各个候选服务器，该内容接收/传送单元C17可以从各个候选服务器处接收内容并且资源获得单元C11可以知道资源参数例如传送延迟以及此时的传送处理量(通过计算每小时接收到的内容数量)(步骤S305)。
检测是否需要有效类型资源测量(步骤S306)。也就是，如果只有步骤S305中的无源类型资源测量无法获得足够的资源参数，则有效类型资源测量就是必须的并在步骤S307中执行。
若不需要通过步骤S303中的无源类型资源测量来检测目的服务器，同时在步骤S306中判断出有效资源检测类型是必须的，则该目的服务器确定单元C13通过使用资源获得单元C11来测量并获得必须的资源参数(步骤S307)。
若在步骤S305或S307中获得了确定目的服务器所必须的资源参数，则由目的服务器确定单元C13通过使用上述的资源参数以及在步骤S301中读出的目的服务器确定策略来确定目的服务器(步骤S308)。这时，多个内容服务器可被确定为目的服务器。
被确定的目的服务器的项目被写入到请求路径表格C14中作为相当于内容组的请求目的地(步骤S309)。若写入了多个项目，则同时写入向各个内容服务器传送请求的比率以及权数。
若在步骤S309中向请求路径表格C14中写入了目的服务器，则该步骤就转移至保持被写入项目的状态(步骤S310)。
图12为用于对上述步骤S310中的操作进行详细描述的流程图。
请求路径表格C14定期的检查是否接收到了相应于将要在预定的时间内保持的目的服务器项目的请求(图12中的步骤S401)。如果在预定的时间或更多的时间内没有接收到任何请求，则相应的项目将被删掉(步骤S404)。
若在预定的时间内接收到了一个用于项目的请求，则通过使用资源获得单元C11来检查对于相当于项目的候选服务器来说在确定目的的同时该资源值是否被改变为比预定的阈值还大(步骤S402)。这一检查是为了确定在步骤S307中确定的目的服务器是否仍旧合适。若没有变化超过了阈值，则再一次返回至步骤S401。
在步骤S402中，若变化超出了阈值，则返回至步骤S301，在这里重新执行确定目的服务器的操作(步骤S403)。
下面将对该实施例的有益效果进行描述。
在该实施例中，服务器负载平衡装置根据对于各个内容组来说都不相同的策略来确定目的服务器，并将其注册到请求路径表格中。至今，由于根据相同的基准为每个内容组都选择了一个目的服务器，因此仅根据各个内容组无法选择出最优服务器。可是在该实施例中，由于目的服务器的选择标准是根据各个内容组的特征而变化的，因此来自客户端的请求会一直被传送给最优服务器。尤其是，通过将该实施例和根据内容特征自动生成内容组的第一实施例组合在一块，可以更有效的选择出一个服务器。
下面将参照附图对本发明的第三实施例进行详细的描述。
参照图13，本发明第三实施例由内容服务器A3和服务器负载平衡装置C1构成。
内容服务器A3包括资源响应策略设置单元A14，还包括第二实施例内容服务器A2的结构，并且用资源响应单元A15代替了资源响应单元A13。其它的部件同图7中所示的第二实施例中的部件都相同。
为了响应用于获得从服务器负载平衡装置C1接收到的资源信息的请求而使用资源响应策略设置单元A14来设置策略。这里，该策略并没有被用来对自身内容服务器集中进行过多的存取。例如，若内容服务器A3所处的状态为自身节点的CPU负载低于10％，则可以假设它从多个服务器负载平衡装置中接收请求资源信息的请求。同时，当它将CPU负载10％的值返回给所有的服务器负载平衡装置时，由各个服务器负载平衡装置根据这个接收到的值判断出该内容服务器A3的CPU负载足够低并且它们可以选择该内容服务器A3作为目的服务器来传送各个请求。结果，就可以通过集中存取来快速的增加内容服务器A3的CPU负载，但是这无法提供作为服务器的充分性能。在最坏的情况下，可能出现递归重复进行相同操作的摆动现象，以至于所有的已经选择的内容服务器A3作为目的服务器的服务器负载平衡装置都对服务器性能的退化进行监测，并再次选择另一个内容服务器作为目的服务器，这样做的结果就是，由于集中存取而使得该最新被选中的内容服务器的性能再一次退化。
这里设置了一个策略，用来防止上述的对于一个指定内容服务器的集中存取以及摆动现象。最为该策略的一个实例，可以考虑存在一个在预定的时间内不返回一个预定阈值以及其上资源的策略，或者是一个在预定的阈值内约束服务器负载平衡装置号码的策略，其中该装置可以同时返回给上述资源一个给定的值。
图14为一个资源响应策略表格105的例子，该表格中显示出了资源响应策略设置单元A14中的每个策略设置。根据各种资源类型的响应策略都被显示在资源响应策略表格105中。例如，对于CPU负载来说，若当前的CPU负载为0％至30％，则将实际CPU负载两倍的值按照30％的概率被返回(实际值按照70％的概率返回)，若为30％至60％，则将实际CPU负载1.5倍的值按照50％的概率返回，并且若为60％至100％，则返回实际值。
该资源响应单元A15为了回答获得来自服务器负载平衡装置C1的资源信息的请求而返回资源参数，这种方式与第一实施例中的资源响应单元A13一样。但是，在返回资源时，资源响应单元A15参照此时在资源响应策略设置单元A14中设置的策略，并根据该策略计算将要被返回的资源值。
参照图15，对内容服务器A3中接收请求的操作进行详细的描述，其中该请求用来获得来自服务器负载平衡装置C1的资源。
在接收到用于从服务器负载平衡装置C1处获得资源信息的请求时，内容服务器A3中的资源响应单元A15获得了相当于自身节点中的被请求资源参数的资源值(图15中的步骤S501)。
该资源响应单元A15获得了相当于来自资源响应策略设置单元A14的资源参数的资源响应策略(步骤S502)。
步骤S502之后，由资源响应单元A15检查它是否能够以其本身来响应在步骤S501中获得的资源参数(步骤S503)。
若在步骤S503中判断出该资源参数能够以其本身返回，则该资源响应单元A15将该资源参数返回给已发出获得资源信息请求的服务器负载平衡装置C1(S505)。
若在步骤S503中判断出该资源参数无法以其本身返回，则该资源响应单元A15根据相当于资源参数的资源响应策略来计算用于返回的资源值(步骤S504)。与资源参数相同，该计算后的响应值被返回给已发出获得资源信息请求的服务器负载平衡装置C1(步骤S505)。
下面将对该实施例的有益效果进行描述。在该实施例中，内容服务器并不是一直返回和它本身一样的实际资源信息，而是根据设置资源响应策略将校准后的资源值返回给各个获得资源信息的请求，其中该信息来自位于一个网络中的多个服务器负载平衡装置。
由于每个服务器负载平衡装置都分别确定一个目的服务器，如果象现有技术那样返回实际上的资源信息，则由于有多个服务器负载平衡装置同时选择该内容服务器作为目的服务器而有可能出现请求快速集中的情况。通过返回校准后的资源值就能够抑制出现上述的请求迅速集中的情况，例如该实施例。
下面将参照附图对本发明的第四实施例进行详细的描述。
参照图16，本发明第四实施例由内容服务器A2和服务器负载平衡装置C2构成。
服务器负载平衡装置C2包括权数设置单元C19，还包括第二实施例服务器负载平衡装置C1的结构。进一步，还用请求路径表格C18代替了请求路径表格C14。
请求路径表格C18具有同第二实施例中所述的请求路径表格C14相同的功能，但它们之间的不同之处就在于传送权数值被附加在各个项目的每个目的服务器IP地址之后。通过使用循环等待或加权散列功能，参照指定给各个服务器的权数值的比率选择出一个将要用于响应请求接收单元C15的服务器。
虽然该没有传送请求的服务器并没有被注册在请求路径表格C14中，但是用于内容组的所有候选服务器都被注册在该请求路径表格C18中。这时，并不传送请求的服务器用权数0％进行注册。图17以请求路径表格C18为例示出了表格106。
该权数设置单元C19具有在请求路径表格C18中设置/改变传送权数值的功能。在图17的请求路径表格106中，“rtsp//stream.bbb.org/live/*”的各个传送服务器IP地址“10.5.1.1”、“10.7.1.1”、“10.4.2.1”以及“10.2.5.2”都具有各自的权数值20％、20％、10％以及50％，并且该权数设置单元C19执行将上述值分别改为例如30％、30％、20％以及20％的操作。
参照附图18，下面将对防止服务器负载平衡装置C2中的一个特定服务器负载集中的操作进行详细的描述。
该目的服务器确定单元C13通过使用资源获得单元C11为每个位于请求路径表格C18中的项目获得相当于各个已注册过目的服务器的资源(图18中的步骤S601)。已获得资源的类型被设置在目的服务器确定策略设置单元C12中并且对于每个项目都不相同。
若获得了相当于各个目的服务器的资源，侧该目的服务器确定单元C13对各个服务器获得的资源进行比较并检查各个服务器资源值之间的差值是否超出了一个预定的阈值(步骤S602)。该检查的基准包括，例如“对于每个服务器来说，获得资源的最大值比最小值的两倍还大，或者更大”以及“对于每个服务器来说，获得传送处理量的最大值和最小值之间的差别为1Mbps或者更多”。
若在步骤S602中各个服务器资源值之间的不同没有超出一个预定的阈值，则在请求路径表格C18中设置的加权数值并不发生变化，而当其超出上述的阈值时，该权数设置单元C19会根据获得的资源值来重新设置加权数值(步骤S603)。
例如，假设有三个目的服务器；服务器A、服务器B以及服务器C都已经注册过并加权数值分别为30％、50％以及20％。假设三个服务器获得的传送处理量分别为6Mbps、3Mbps以及1Mbps。同时，根据传送处理量的比率将加权数值改为60％、30％以及10％。
可是从防止摆动的观点来看，根据资源值比率突发性的改变加权数值并不可取。在上述例子的情况下，在改变权数之后，虽然对于服务器A的请求比率从30％增加至60％，可是如果在另一个服务器负载平衡装置中对于服务器A的请求比率也类似的增加，则对服务器A的请求次数也会迅速增加并可能大大的增加服务器A传送处理量的退化。接着，就需要再次改变加权数值并可能出现该加权改变操作不收敛相反却发生摆动的情况。为了防止发生摆动的情况，提供了一种通过使用移动粒度(move_granularity)来限制加权改变比率的方法，这不需要根据资源值比率突发性的改变加权数值。该移动粒度为用于限制加权数值第一变化的参数并取值为1.0或更小。在上述的例子中，根据资源值比率将服务器A的加权数值从30％改变至60％，相当于“移动粒度＝1.0”。例如，在上述例子中，若“移动粒度＝0.3”，则服务器A的加权数值变为(60％-30％)×0.3＝9％，并且改变后的加权数值变成39％。类似的，服务器B和服务器C的加权数值也分别变为44％和17％。
通过使用上面所提到的移动粒度逐渐的改变加权数值，可以限制一个特定服务器接收到的请求数量的快速增加/减小并防止摆动。这里，很重要的就是不要将移动粒度的值设置为能够导致摆动的数值。例如，可以考虑有一种采用反馈控制来自动调整移动粒度为一个值并不会发生摆动的方法。例如，可以考虑一种方法，通过使用反馈控制，自动调节移动粒度到一个不发生摆动的值。
该目的服务器确定单元周期性的在请求路径单元C18中的各个项目执行从S601至S603的步骤。
已经在图18中被描述过的操作必须使用移动粒度并调整其值使其不会导致摆动。这时，将对限制内容服务器中请求数量迅速增加的方法中的操作进行详细描述，而不是一定要调整移动粒度(也就是“移动粒度＝1.0”)。
参照图19，至步骤S602之前的操作同图18中所描述的相同。若在步骤S602中资源值的差别为该阈值或更大，则由确定加权数值变化时间(图19中的步骤S604)来代替步骤S603中的立即改变加权数值。根据概率来确定改变加权数值的时间，并且例如，可以用相等的概率来确定0分钟至10分钟之间的时间。
在步骤S604中确定时间时，在步骤S605中再次由该资源获得单元C11为注册在请求路径表格C18中每个项目中的目的服务器获得资源。若在步骤S605中再次为每个目的服务器获得了资源，则再次执行同步骤S602中相同的操作并检查各个服务器之间的资源值差距是否超出了预定的阈值(步骤S606)。
步骤S606中若服务器之间资源值的差距并没有超出预定阈值，这就可以结束该处理过程而不需要改变设置在请求路径表格C18中的加权数值，同时若其超出了该阈值，则由权数设置单元C19根据在步骤S605中再次获得的资源值重新设置该加权数值(步骤S607)。
在该操作过程中，可以通过随概率分散时间延迟重新设置加权数值的时间来对内容服务器请求次数的迅速变化进行限制，而不需要调整移动粒度。需要在被延迟的时间内判断出是否要对加权数值进行重新设置，并且如果不需要重新设置，则不执行重新设置操作，并因此限制了为改变加权数值并有效地防止摆动而进行不必要的操作。
下面将对该实施例的有益效果进行描述。
在该实施例中，分别根据获得的资源值对服务器负载平衡装置各个项目中目的服务器的加权数值进行改变。可以通过使用移动粒度来逐步的改变加权数值，并据此来限制对内容服务器请求次数的迅速变化。进一步，还可以通过随概率分散时间延迟重新设置加权数值的时间来获得相同的效果，而不需要调整移动粒度。虽然在第三实施例中对内容服务器一侧的请求次数的迅速变化进行了限制，可是在该实施例中，也可以在位于服务器负载平衡装置的一侧实现相同的功能，而不需要对该内容服务器一侧进行改变。
下面将参照附图对本发明的第五实施例进行详细的描述。
参照图20，本发明第五实施例由内容服务器A4、服务器负载平衡装置C3、客户端D2以及DNS服务器E1构成。
该内容服务器A4包括内容存储单元A11以及请求接收/内容响应单元A12。其各自的功能和操作都与第二实施例中的相同。
该服务器负载平衡装置C3包括信息包接收单元C25、信息包传送单元C20、信息包路径表格C21、目的服务器确定单元C22以及FQDN(正式域名)解析单元C23以及地址解析单元C24。
该信息包接收单元C25接收来自客户端D2的信息包并检测该信息包的目的端口号。若检测到目的端口号包括在一个预定值中间，则根据相同数据包的目的IP地址，参照注册在信息包路径表格C21中的项目，检测将要向其传送信息包的内容服务器A4的IP地址。
信息包传送单元C20将由信息包接收单元C25接收到的信息包的目的IP地址重新写入到传输目的地内容服务器A4的IP地址中并将该信息包传送给内容服务器A4。
换句话说，该信息包可以只需在第2层重新写入报头就能被传送，而不需要重新写入IP地址。作为第2层协议，若考虑到使用以太网(R)的情况，可以通过使用来自目的地内容限务器A4的IP地址的APR来解析内容服务器A4的MAC地址，并且该信息包随着被视为目的MAC地址的解析后MAC地址被传送出去，而不需要重新写入信息包的目的IP地址。为了进行简要的描述，在下文中只对传送具有重写IP地址的信息包的情况进行描述。
在信息包路径表格C21中，根据由信息包接收单元C23接收到的各个信息包的目的IP地址/目的端口号分别对该传送信息包的内容服务器的IP地址进行注册。
图21示出了信息包路径表格C21的一个例子的表格107。根据表格107，例如，目的IP地址“10.1.1.1”以及目的端口号为“7070”的信息包被传送给目的IP地址为“20.2.2.2”或者目的IP地址为“30.3.3.3”的内容服务器。
这时，该方法通过源IP地址/源端口号的相同组合中的散列功能来进行乘法，并根据该散列值来选择目的服务器，为了与相同的内容服务器建立相同的连接还不需要为每个信息包交替选择两个内容服务器而采用了该方法。进一步，还有一种能够在接收到的信息包的TCP报头SYN标识接收之后用来传送信息包的记录方法，其中该信息包具有同相同服务器终端的信息包一样的IP地址/端口号。
对于具有多个目的IP地址/目的端口号的信息包来说，由目的服务器确定单元C22来确定一个目的服务器(内容服务器A4)。也可以采用同第二实施例目的服务器确定单元C13中所描述的相同的方法来确定目的服务器。该被确定的目的服务器被写入到信息包路径表格C21的项目中。
若目的服务器确定单元C22确定了就是具有多个目的IP地址/目的端口号的信息包的目的地的内容服务器A4，则由FQDN解析单元C23查询关于DNS服务器E1目的IP地址的FQDN。
若目的服务器确定单元C22确定了就是具有多个目的IP地址的信息包的目的地的服务器，则在FQDN解析单元C23解析完关于目的IP地址的FQDN之后，由地址解析单元C24通过使用解析过的FQDN以及信息包的目的端口号重新生成FQDN，并且对重新刚生成的FQDN的IP地址进行解析。这里，新近重新生成的FQDN对于各个目的IP地址以及各个信息包的目的端口号来说必须是唯一的，若解析后的FQDN为“aaa.com”并且信息包的目的端口号为“7070”，则它对于FQDN“port7070.aaa.com”的IP地址进行解析。这里，可以对多个IP地址进行解析并可以通过使用FQDN解析单元C23和地址解析单元C24来获得信息包目的地候选服务器的IP地址列表。
客户端D2包括请求发送单元D11以及地址解析单元D12。
该请求发送单元D11发出一个用来获得作为IP信息包的内容的请求。同时，从作为被请求内容标识符的URL中，通过使用地址解析单元D12对相当于URL的FQDN的IP地址进行解析，并且将该解析出来的IP地址确定作为将要发送IP信息包的目的IP地址。由URL指定的端口号也被确定为目的端口号。例如，当发出为了获得其URL为“http//aaa.com/pict.jpg7070”的内容的请求，假设“aaa.com”的IP地址为“10.1.1.1”，则该请求发送单元D11就会发送目的IP地址为“10.1.1.1”以及目的端口号为“7070”的信息包。
地址解析单元D12对使用预期内容URL中的FQDN部分作为密钥的DNS服务器E1的IP地址进行查询。来自DNS服务器E1的响应可以包括多个IP地址。在这种情况下，可以使用多个项目中的一个作为相应于FQDN的IP地址。
该DNS服务器E1包括地址/FQDN解析表格E11，地址响应单元E12以及FQDN响应单元13。
该地址/FQND解析表格E11涉及到何时地址响应单元E12及FQDN响应单元E13对正接收的地址解析请求及FQDN解析请求进行响应，并且它包括两部分地址解析表格108，这是“FQDN→IP地址”的转换表格以及FQDN解析表格109，这是“IP地址→FQDN”的转换表格。
图22为地址/FQDN解析表格E11的一个例子。该地址/FQDN解析表格E11包括两个表格地址解析表格108以及FQDN解析表格109。该地址/FQDN解析表格E11的一个特征就是对于地址解析表格108中的各个FQDN来说都存在多个解析的IP地址而FQDN解析表格109中对于一个IP地址来说只能解析一个FQDN。
这时，可以使用FQDN作为内容组的标识符能够使得服务器负载平衡装置C3通过解析来自目的IP地址的FQDN以及从客户端D2接收到的信息包的目的端口号来识别被请求的内容组。进一步，可以通过解析来自FQDN的IP地址来获得关于FQDN的候选服务器列表。也就是，只有通过对IP报头以及传输层(UDP/TCP)报头进行分析才能对被请求的内容组进行识别，并且也不需要进一步对上层的信息进行分析。
为了回答来自另一个节点的地址解析请求，地址响应单元E12以包括在请求消息中的FQDN作为密钥来对地址/FQDN解析表格进行查询并返回解析后的IP。
为了回答来自另一个节点的FQDN解析请求，FQDN响应单元E13以包括在请求消息中的IP地址作为密钥来对地址/FQDN解析表格进行查询并返回解析后的FQDN。
在该实施例中，参照图23对客户端D2发送获得内容请求的操作进行详细描述。
请求发送单元D11从所期望内容的URL中提取FQDN部分(图23中的步骤S701)。例如，假设URL为“http//aaa.com/pict.jpg7070”，则相应的FQDN部分就是“aaa.com”。
接下来，通过地址解析单元D12对相当于被提取出来的FQDN的IP地址进行解析(步骤S702)。这里，地址解析单元D12向以FQDN作为密钥的DNS服务器E1发出一个地址解析请求。
最后，由请求发送单元D11发送相当于内容的请求信息包，该信息包具有被确定为目的IP地址的解析后IP地址(步骤S703)。
在该实施例中，参照图24对服务器负载平衡装置C3接收来自客户端D2的信息包的操作进行详细描述。
由信息包接收单元C25对接收到的信息包的目的端口号进行分析并检查分析后的目的端口号是否同预定的值相同(图24中的步骤S801)。
作为步骤S801的结果，若与预定值不同，则信息包接收单元C25将该接收到的信息包作为一般的信息包来进行处理(步骤S803)。也就是说，作为服务器负载平衡装置的操作就不会进行。
作为步骤S801的结果，若与预定值相同，则信息包接收单元C25检测在信息包路径表格C21中是否存在一个与接收到的信息包的目的IP地址/目的端口号相对应的项目(步骤S802)。
作为步骤S802的结果，若存在该项目，则信息包接收单元C25在信息包路径表格C21的项目中查询目的服务器IP地址(步骤S804)。
这时，由该信息包路径表格C21返回相应于接收到信息包目的IP地址/端口号的目的服务器的IP地址。这里，若注册了多个目的服务器IP地址，则信息包路径表格C21通过使用如上所述的散列功能、采用同相同内容服务器建立相同连接返回目的服务器的IP地址。
在接收到来自信息包路径表格C21的目的服务器IP地址时，由信息包接收单元C25将接收到的信息包的目的地址重新写入到目的服务器IP地址中并向其发送该接收到的信息包(步骤S805)。
作为步骤S802的结果，若不存在该项目，由信息包接收单元C25将该接收到的信息包本身传送至最开始的目的IP地址，而不需要改变接收到的信息包的目的IP地址(步骤S806)。进一步，还为具有相同目的IP地址/目的端口号的信息包确定最优目的服务器并将该项目重新写入到信息包路径表格C21中(步骤S807)。在步骤S806之后，直到在步骤S807中将目的服务器写入到表格C21中，即使接收到了具有相同目的IP地址/目的端口号的信息包，该信息包接收单元C25也会将信息包本身传送给最开始的IP地址。
图25为详细说明步骤S807中操作的流程图。
该目的服务器确定单元C22通过FQDN解析单元C23对用于接收到的信息包的目的IP地址的FQDN进行解析(图25中的步骤S901)。这时，由FQDN解析单元C23向以上述IP地址作为密钥的DNS服务器E1发出一个FQDN解析请求并接收回应。
在步骤S901中解析FQDN时，由目的服务器确定单元C22通过使用在步骤S901中解析的FQDN以及信息包的目的端口号重新生成一个FQDN，并解析IP地址用于最近重新生成的FQDN(步骤S902)。这里，该最近重新生成的FQDN必须对于信息包目的IP地址以及目的端口号的组合来说是唯一的。例如，若解析的FQDN为“aaa.com”并且信息包的目的端口号为“7070”，则目的服务器确定单元C22对相当于FQDN“port7070.aaa.com”的IP地址进行解析。
在步骤S902中，虽然在步骤S901中解析的FQDN以及信息包的目的端口号被用来生成一个新的FQDN并且该重新生成的FQDN被用作解析DNS服务器中IP地址的密钥，可是还存在一种使用在步骤S901中解析的FQDN作为密钥的方法。在这种情况下，在步骤S901中解析的FQDN本身对于被请求的内容组来说必须是唯一的。因此，需要确定一个对于由服务器负载平衡装置C3接收到的信息包目的IP地址中的每个内容组都是唯一的数值。进一步，在这种情况下，在信息包路径表格中21中，只能根据目的IP地址对目的服务器的IP地址进行注册，而不是根据目的IP地址/目的端口号的组合。
该目的服务器确定单元C22从相应于步骤S902解析的IP地址的服务器中确定一个目的服务器(步骤S903)。用于确定目的服务器的详细操作同第二实施例中的相同，并在这里省略掉对它的描述。
若确定了目的服务器，则由目的服务器确定单元C22将确定服务器的IP地址写入到信息包路径表格中(步骤S904)。
下面将对该实施例的有益效果进行描述。
在该实施例中，服务负载平衡装置通过使用DNS服务器，根据信息包的目的IP地址/目的端口号对被请求内容所属的内容组进行识别，并且将该信息包传送给内容组中的最优内容服务器。常用的服务器负载平衡装置必须对来自客户端的信息包内容进行分析并识别哪些内容是被请求的。换句话说，常用的服务器负载平衡装置必须使用7层转换。可是本实施例中的服务器负载平衡装置只需检查信息包的目的IP地址和目的端口号就能识别出别请求的内容。因此，这只需要使用4层转换就能实现。一般的，7层转换的处理量例如每秒钟的连接数目较低而且其成本会更贵。如果使用该实施例的4层转换来实现相同的功能，则从增强处理量和降低成本的角度来说是很有效的。
不需要指出的是该第五实施例能够同上面提到的第一实施例中的内容管理装置组合在一块。在这种情况下，代替URL组的是，将端口号设置在如图2所示的分类策略表格中。图3中分组后的目录路径可以用增加端口号的路径来代替，“/cgi/high-load/z.exe7070”。
在下文中，将参照附图对本发明的具体例子进行描述。
参照附图对本发明的第一个具体实例进行描述。该例子对应于第二实施例。
参照图7，该例子由一个网络实现，该网络包括内容服务器A2、服务器负载平衡装置C1以及客户端D1。
在图8的目的服务器确定策略表格103中指出来的各种策略被设置在服务器负载平衡装置C1的目的服务器确定策略设置单元C12中。在初始的状态下，没有项目注册在请求路径表格C14中。
客户端D1将用于获得被识别为URL“http//www.aaa.com/file/small/pict.gif”内容的请求发送给一个服务器。
服务器负载平衡装置C1接收请求并对请求的URL进行分析。参照请求路径表格C14，将该请求传送给默认内容服务器，这是由于没有对应于上述URL的项目。由DNS服务器从URL“www.aaa.com”的FQDN部分解析出来的IP地址被视为默认内容服务器。
在传送完该请求之后，服务器负载平衡装置C1尽量在请求路径表格C14中生成一个相应于URL所属内容组的目的报务器项目。
该目的服务确定单元C13对用于管理内容服务器A2的内容管理装置进行查询以便于获得一个内容组和对于URL的候选服务器列表。
在接收到给查询时，该内容管理装置回答对应于URL的内容组具有文件特征，它被URL前缀识别为“http//www.aaa.com/file/small/*”，并且该候选服务器列表包括三部分“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”。
作为获得对应于URL的候选服务器列表的另一种方法，该FQDN例如“small.file.www，aaa.com”可以从URL中生成，并且可以在DNS服务器中查询以FQDN作为密钥的相应IP地址列表。在该例中，该DNS服务器回应对应于上述FQDN的IP地址包括三部分“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”。
该目的服务器确定单元C13参照目的服务器确定策略设置单元C12检测对应于内容组的目的服务器确定策略，并且获得一个策略，该策略在对具有文件特性的内容组进行内容获取时使用该传送处理量，并以具有上述处理量最大值的服务器作为参照，选择具有60％或更高参照值的服务器作为目的服务器。
为了根据获得的策略测量来自各个候选服务器的传送处理量，该目的服务器确定单元C13在请求路径表格C14中注册三个IP地址“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”作为具有URL前缀“http//www.aaa.com/file/small/*”请求的目的服务器。在注册之后，相应于上述来自客户端URL前缀的各个请求将被以循环的方式(round robin method)传送给三个服务器。
为了回应以循环的方式传送给三个服务器的各个请求，由内容接收/传送单元C17接收来自内容服务器的响应内容。该资源获得单元C11通过内容接收/发送单元C17获得该响应内容的传送处理量，并将获得的信息传输给目的服务器确定单元C13。这里，假设对应于“10.1.1.1”、“10.2.2.2”以及“10.3.3.3”的各个传送处理量分别为1Mbps、7Mbps以及10Mbps。由于该策略就是以具有最大值的服务器作为参照，选择具有60％或更多参照值的服务器来作为目的服务器，目的服务器确定单元C13确定相应于“10.2.2.2”及“10.3.3.3”的两个服务器作为目的服务器。进一步，将请求路径表格C14中相应于具有URL前缀“http//www.aaa.com/file/small/*”请求的目的服务器重新写入到上述的两个“10.2.2.2”及“10.3.3.3”中。接着，相应于上述URL前缀的各个请求被以循环的方式传输给两个服务器。
下面将参照附图对本发明的第二个具体实例进行描述。该例子对应于第三实施例。
参照图26，该实例包括内容服务器201以及服务器负载平衡装置301至306。该内容服务器具有同第三实施例中的内容服务器A3相同的结构，并且服务器负载平衡装置301至306分别具有同服务器负载平衡装置C1相同的结构。
图14的资源响应策略表格105中所示的资源响应策略被设置在内容服务器201中。这里，假设当前的CPU负载为内容服务器201的25％。
为了确定服务器负载平衡装置301至306中的目的服务器，假设各个服务器负载平衡装置都立刻向内容服务器201发出了获得CPU负载资源的请求。
由于当前CPU负载位于0％至30％的范围之内，因此对于来自第一服务器负载平衡装置301至304的用于获得资源的请求来说，该内容服务器201有70％的可能返回实际CPU负载并有30％的可能返回实际CPU负载的两倍。这里假设向服务器负载平衡装置301至304返回实际CPU负载的25％并向服务器负载平衡装置305至306返回实际CPU负载两倍的50％。
若内容服务器201向服务器负载平衡装置301至306返回实际CPU负载的25％，由于判断出内容服务器201的CPU负载足够低并且可能出现随着快速增长的请求而出现的负载迅速增长的情况，因此所有的服务器负载平衡装置都可以确定内容服务器201作为目的服务器。但是在该例子中，服务器负载平衡装置305和306判断出内容服务器201的CPU负载并不够低，因此确定除了内容服务器201以外的另一个内容服务器作为目的服务器。因此，可以限制内容服务器201中负载的快速增长。
下面将参照附图对本发明的第三个具体实例进行描述。该例子对应于第四实施例。
参照图27，该实例包括内容服务器202及203以及服务器负载平衡装置307。该内容服务器202及203分别具有同第四实施例中的内容服务器A2相同的结构，并服务器负载平衡装置307具有同服务器负载平衡装置C2相同的结构。
在如图28的表格110所示的服务器负载平衡装置307中的请求路径表格中，假设有两个对应于“ftp//ftp.ccc.edu/pub/*”的目的服务器IP地址“10.5.1.1”(对应于内容服务器202)以及“10.6.1.1”(对应于内容服务器203)，并且加权数值分别为90％和10％。
根据来自各个服务器的传送处理量比率对权数进行重置，直到具有最大处理量服务器的传送处理量小于具有最小处理量服务器的传送处理量的两倍。这里，假设内容服务器202及203的处理量分别为1Mbps及9Mbps。假设“移动粒度＝1.0”，各个服务器的加权数值被重置为90％→10％以及10％→90％。在对权数进行重置之后，对各个服务器的请求传送比率被改变了并且在下次测量传送处理量时假设各个处理量为9Mbps及1Mbps。接着，该权数又被重置为初始值例如10％→90％以及90％→10％。该权数改变操作以及摆动的递归循环表示移动粒度y太大了。
因此，在该例子中考虑“移动粒度＝0.5”的情况。假设内容服务器202及203的处理量分别为1Mbps及9Mbps，各个服务器加权数值的波动数量为移动粒度＝1.0时的一半，并且权数被重置为90％→50％以及10％→50％。在对权数进行重置之后，对于各个服务器传送请求的比率发生了变化并在下次测量传送处理量时假设各个处理量为7Mbps及3Mbps。类似的，各个权数值被重置为50％→60％以及50％→40％。在对权数进行重置之后，各个服务器的传送处理量分别变为6Mbps及4Mbps，由于具有最大传送处理量服务器的传送处理量小于具有最小处理量服务器的传送处理量的两倍，因此结束权数改变操作。这样，为了不在改变权数的操作中发生摆动现象，为移动粒度确定一个合适的数值是很重要的。
下面将参照附图对本发明的第四个具体实例进行描述。该例子对应于第五实施例。
参照图20，该例子由一个网络实现，该网络包括内容服务器A4、服务器负载平衡装置C3、客户端D2以及DNS服务器E1。
图22中所示的地址解析表格108以及FQDN解析表格109都被注册在DNS服务器E1中。
在初始阶段，服务器负载平衡装置C3的信息包路径表格C21中并没有注册任何项目。
由客户端D2向一个服务器发出用于获得被识别为URL“http//www.aaa/pict.jpg7070”内容的请求。这里，地址解析请求被发送给以URL“aaa.com”的FQDN部分作为密钥的DNS服务器E1。DNS服务器E1返回相应的IP地址“10.1.1.1”。客户端D2将解析后的地址“10.1.1.1”作为目的IP地址并以具有URL中指出的目的端口号7070的信息包的形式发出请求。
该服务器负载平衡装置C3接收来自客户端D2的信息包，并参照信息包路径表格C21将具有预定目的端口号的信息包传送给一个目的服务器IP地址。在这种情况下，“7070”为预定目的端口号，并且对该信息包路径表格C21进行检查其结果就是其中没有发现已注册的项目，并因此将该信息包传送给初始目的IP地址。
在传送信息包之后，服务器负载平衡装置C3在信息包路径表格中生成一个相应信息包内容组中的目的服务器项目。即使接收到的信息包具有同上述信息包相同的目的IP地址/目的端口号，也会将该信息包传输给初始目的IP地址，直到生成一个目的服务器项目。
下面参照图29对在信息包路径表格C21中为相应于信息包的内容组生成一个目的服务器项目的例子进行说明。客户端D2以信息包的形式发出请求，该信息包中包括如上面的URL所指定的目的IP地址“10.1.1.1”和目的端口号“7070”。
服务器负载平衡装置C3的目的服务器确定单元C22请求FQDN解析单元C23对以信息包的目的IP地址“10.1.1.1”为密钥的DNS服务器E1进行FQDN解析。
在接收到该请求时，DNS服务器E1的FQDN响应单元E13对“10.1.1.1”的回答为FQDN“aaa.com”。
目的服务器确定单元C22请求地址解析单元C24对以FQDN“port7070.aaa.com”为密钥的DNS服务器E1进行地址解析。上述FQDN由目的端口号“7070”信息加上从DNS服务器E1返回的FQDN“aaa.com”构成。最近刚生成的FQDN必须对于信息包的目的IP地址和目的端口号来说都是唯一的，并在另一个例子中也可以使用“7070.port.aaa.com”。相应于要生成的FQDN的项目必须被注册在DNS服务器E1中。
在接收到请求时，DNS服务器E1的地址响应单元E12回答相应于“port.7070.aaa.com”的三个地址“10.1.1.1”、“20.2.2.2”以及“30.3.3.3”。
因此，目的服务器确定单元C22就知道了目的IP地址/目的端口号“10.1.1.1/7070”的信息包具有三个候选服务器目的IP地址“10.1.1.1”、“20.2.2.2”以及“30.3.3.3”。
由目的服务器确定单元C22从候选服务器中确定一个注册在信息包路径表格中的目的服务器。这里，假设将在CPU负载的增序中选择两个服务器的策略设置为目的服务器的确定策略，并且作为查询各个服务器的结果，相应于“10.1.1.1”、“20.2.2.2”以及“30.3.3.3”的服务器CPU负载分别为80％、30％以及50％。
结果，对于目的IP地址/目的端口号为“10.1.1.1/7070”的信息包来说，目的服务器确定单元C22确定对应于“20.2.2.2”以及“30.3.3.3”的服务器为目的服务器，并将上述部分都注册到信息包路径表格C21中(参照图21中的信息包路径表格107)。
在将项目注册到信息包路径表格C21中之后，重新将具有目的IP地址/目的端口号“10.1.1.1/7070”的信息包传输给IP地址为“20.2.2.2”或“30.3.3.3”的服务器。
在上述各个实施例的服务器负载平衡系统中，不需要说明的是服务器负载平衡装置C1至C3中目的服务器确定策略设置单元C12、目的服务器确定单元C13及C22、FQDN解析单元C23以及地址解析单元C24的功能、内容管理装置B1中内容分类单元B12以及内容分组单元B13的功能、内容服务器A1至A4中资源响应单元A13及A15以及资源响应策略设置单元A14的功能以及其它功能都可以由硬件来实现，并且内容发送管理程序A39、内容管理程序B19、服务器负载平衡程序C29、C49以及具有各种功能的D59都可以被载入到一台计算机的存储器中，并因此实现上述的系统。该内容发送管理程序A39、内容管理程序B19、以及服务器负载平衡程序C29、C49及D59都被存储在存储介质中例如磁盘和半导体存储器。它们被从存储介质中载入到计算机中来控制计算机的操作并因此实现上述的功能。
如上文所述，参照优选实施例和例子对本发明进行了描述，可是本发明并不仅限于上述的实施例和例子，在本发明的范畴和精神之内可以进行各种修改。
如上所述，根据本发明可以实现以下有益效果。
第一，并不需要人工将内容服务器中的内容分类及分组为多个有相同特征的内容。
这是由于在内容管理装置中设置了将内容分类/分组为相同内容的策略，并因此能够根据内容服务器中内容的静态/动态特征自动对其进行自动分组。
第二，在服务器负载平衡装置中，根据内容特征的最优化请求路径可以通过最小项目号码来实现。
这是由于该内容管理装置能够根据其中的静态/动态特征自动对内容服务器中的内容进行分组以及分类。
第三，经过服务器负载平衡装置，来自客户端的请求可以根据被请求内容的特征而被传送给最优服务器。
这是由于服务器负载平衡装置根据取决于各个特征的选择标准来为各个内容组确定一个目的服务器，将确定的目的服务器注册到请求路径表格中并识别哪个内容组中包括来自客户端的请求内容，因此将该请求传送给相应内容组的目的服务器。
第四，可以限制客户端向内容服务器发送请求的快速增长并防止目的服务器确定操作中出现摆动的情况，而不需要集中在服务器负载平衡装置的请求路径表格中。
这是首先由于在响应来自多个服务器负载平衡装置的用于获得资源信息的请求时(其中这些装置位于内容服务器的一个网络中)，并不总是返回实际资源信息而是返回根据设置资源响应策略校正过的资源值，因此，可以限制服多个服务器负载平衡装置同时选择相同的内容服务器作为目的服务器。
其次由于在服务器负载平衡装置中，根据获得的资源数值对各个项目目的服务器的加权数值进行改变，并利用移动粒度使得加权数值平缓的变化，因此能够限制服多个服务器负载平衡装置同时选择相同的内容服务器作为目的服务器。
再次由于在服务器负载平衡装置中，并不是根据获得的资源数值立即对用于各个项目目的服务器的加权数值进行重置，而是由随概率分布的时间延迟重置加权数值的时间，并且如果需要的话，可以在延迟的时间对加权数值进行重置，因此，可以限制服多个服务器负载平衡装置同时选择相同的内容服务器作为目的服务器。
第五，服务器负载平衡装置能够使用4层转换来从客户端向最优内容服务器引导请求而不需要使用7层转换，因此能够改进服务器负载平衡装置的性能以及降低成本。
这是由于在服务器负载平衡装置中，通过使用DNS服务器，从来自客户端信息包的目的IP地址/目的端口号中识别出含有被请求内容的内容组，并将该信息包传送给相应内容组的最优内容服务器，因此能够越过对从来自客户端信息包的内容(URL等等)的分析。
虽然参照典型的实施例对本发明进行了说明，但是对于本领域内的技术人员来说可以理解的是，在不脱离本发明的精神和范畴的情况下，上述的以及多种其它的变化、删节以及增补都是可以进行的。因此，本发明不应被理解为仅限于上述的特定实施例而是应该包括在含有及等同于附加的权利要求列出的特征范围内能实现的所有可能的实施例。
权利要求
1.一个用来对由内容服务器传送的内容进行管理的内容管理装置，包括用来根据内容的特性将由所述内容服务器传送的内容分成多个组的内容分类装置，以及用来在各个组中将分类到各组中的内容集中到一块儿的内容分组装置。
2.如权利要求1所给出的内容管理装置，其特征在于所述内容分类装置根据特性对所述内容进行分类。
3.如权利要求1所给出的内容管理装置，其特征在于所述内容分类装置根据所述内容特性的分类逐步变细粒度的分级结构逐步对内容进行分类。
4.如权利要求1所给出的内容管理装置，其特征在于所述内容分组装置将同一目录下的已分类内容一块儿集中到相同的组中。
全文摘要
一种用于向多个内容服务器中的一个客户端分配内容发送的服务器负载平衡系统，包括一个目的服务器确定策略设置单元，用来为了确定用于对各个内容特性传送内容的内容服务器而设置选择标准，以及一个目的服务器确定单元，用来根据所请求内容的特性所对应的选择标准确定传送来自客户端的请求内容的内容服务器。
文档编号G06F15/00GK1750543SQ20051011630
公开日2006年3月22日 申请日期2003年3月5日 优先权日2002年3月5日
发明者藤田范人, 岩田淳 申请人:日本电气株式会社