CN102684988A - 负荷控制装置及其方法 - Google Patents

Abstract

限制已向服务器(4)发送完毕但是未从服务器(4)返回应答的应答等待请求的数目。为进行该限制，如果应答等待请求数达到了阈值，则在缓冲器中临时存储接收到的请求，在应答等待请求数降低到低于阈值前使来自缓冲器的请求的发送等待。另外，监视服务器(4)的执行状况，在对于服务器(4)的请求的应答时间在允许范围内时使所述阈值增大，在该应答时间超过允许范围的场合，使所述阈值减小。进而，集约负荷控制装置(3)和客户机(1-1、...、1-n)之间的TCP连接，以使服务器(4)和负荷控制装置(3)之间的连接的同时连接数成为应答等待请求数的阈值以下。

Description

负荷控制装置及其方法

本申请为2007年4月25日递交的、申请号为2007800127797、发明名称为“负荷控制装置及其方法”的专利申请的分案申请。

技术领域

本发明用于一种装置，该装置，被配置在客户机和服务器之间，从客户机接收请求向服务器传送，向客户机传送对于该请求从服务器返回的应答。特别是，涉及请求的调度。另外，在本说明书中，将着眼于Web服务器进行说明，但是不一定限制本发明的对于其他服务器的应用。

背景技术

伴随因特网的普及，已经能够通过网络利用各种服务。邮件、主页的阅览、检索、在线交易、IP电话、点播视频等，是这些服务的例子。这些网络服务能够以各种形态提供，但是近年来，作为与客户机的接口，Web服务器的利用成为主流。

使用Web服务器的服务(Web服务)的基本的结构如下。首先，客户机对于Web服务器发送赋予了识别希望取得的内容的URL(统一资源定位器)的请求。当Web服务器接收到请求时，把与请求中的URL对应的内容作为应答向客户机回送。通过该请求-应答的重复，提供Web服务。

作为传送请求-应答的通信协议，使用HTTP(超文本传输协议)。在本说明书中，把进行Web服务的服务器系统全体称为Web服务器，把在Web服务器上处理HTTP协议的功能称为HTTP服务器，把生成与请求对应的内容的功能称为Web应用。

另外，作为通过Web服务提供的内容现在广泛使用视频和声音的流。流的基本的结构如下。

首先，客户机的Web浏览器从Web服务器取得流内容的元文件。在元文件中，记述流内容的URL。同时，Web浏览器起动与元文件的扩展符关联的播放器(流再生用程序)。然后，根据在从Web服务器取得的元文件中表示的URL，播放器对于流服务器请求流内容的发送。最后，流服务器对于播放器发送流数据。

在流中服务器一般在流内容的再生控制中使用RTSP(实时流协议)协议。RTSP协议是以HTTP协议为基础的协议，在客户机和服务器之间，通过收发请求和对于请求的应答，再生控制流内容。

作为RTSP的请求能够使用的主要的方法，有初始设定(SETUP)、再生(PLAY)、停止(TEARDOWN)等。在RTSP中，因为同时控制多个流，所以有对话的概念。亦即在RTSP中，把从播放器发送SETUP请求到发送TEARDOWN请求、流结束视作为一次对话。

于是，当流服务器从播放器接收SETUP请求时，发行唯一的对话ID。把对话ID赋予应答，通知客户机。通过把通知播放器的对话ID赋予后续的请求，能够识别在流服务器中成为控制对象的对话。

随着Web服务的普及，为舒适地利用服务的课题也日益变得明确起来。作为该课题之一，可以举出服务利用集中时的对过剩通信的应对。

作为服务利用集中的例子，有由于人气高的名牌的股票或者票据的买卖而引起的请求集中、或者灾害发生时的慰问电话等。另外，也有由有恶意的客户机大量发送F5攻击等的无意义的请求的场合。由于这些原因，当向服务器过剩地发送请求时，服务器的请求处理性能会降低。

请求过剩时服务器的请求处理性能降低的原因如下。亦即，第一，伴随服务器处理不完的请求的接收的，诸如中断、TCP/IP处理这样的输入输出开销增加。第二，处理请求的线程或者进程数增大，作为线程或者进程的切换处理所需要的开销的上下文切换开销表面化。第三，因为向客户机返回应答的应答时间增加，所以等待不来应答的客户机会中途撤消请求。这些结果，就会产生服务器越是拥挤，服务器的处理性能越是降低这样的问题。

图1是表示由于请求过剩引起的Web服务器的处理性能降低的实验结果。横轴表示输入请求率，纵轴表示通过量。在图1中，对于某Web服务器，变化输入请求率即每单位时间的请求数(rps)来发送请求。然后，测量通过量，即Web服务器每单位时间能够完成的请求数(rps)。如图1所示，如果输入请求率在一定范围内，则通过量对于输入率成比例(图1直线(a))。但是，当达到Web服务器的最大通过量时，通过量转而降低(图1直线(c))。所以，即使在接收超过Web服务器的最大性能的请求的场合，可以说也需要能够沿图1虚线(b)、维持Web服务器的最大性能的技术。为参考起见，图2表示出理想的通过量的举动。

为防止由于过剩的通信量引起服务器性能降低，提出了预先限制向服务器发送的请求量的方法。作为限制请求量的指标，使用(a)TCP连接数、(b)服务器负荷状态、(c)带宽、(d)并列度等。

(a)在使用TCP连接数的场合，通过决定可同时连接的TCP连接数的上限，试图避免服务器的过负荷。在Apache等的通用的HTTP服务器、负荷分散系统等中使用。但是，由于请求的种类、客户机的线路速度等，对于每一TCP连接其负荷有很大的不同。因此，会出现在达到TCP连接数的上限前，服务器已经成为过负荷，或者反之服务器资源即使有余，由于TCP连接数已经达到上限，所以不能建立新的TCP连接这样的问题。

(b)在使用服务器的负荷状态的场合，从CPU占有率、存储器使用量、应答时间等推测服务器的负荷状态，判定是否过负荷，在判定为过负荷的场合，进行新的请求的传送、拒绝等用于使减轻服务器的负荷的通信量控制。但是，因为在判定是过负荷后才开始进行通信量控制，所以不能避免服务器暂时性的降低性能。

(c)在使用带宽的场合，使用整形器等的带宽控制功能，限制到达服务器的通信量。但是，带宽不是正确测量服务器的负荷的指标。例如，图像文件的下载，占用大的带宽，但是施加给服务器上的负荷较小。因此，通过带宽限制，不容易充分灵活使用服务器的资源，同时不容易确实避免过负荷。

(d)在使用并列度的场合，限制服务器同时执行的线程或者进程数。由此能够削减伴随处理请求的线程或者进程数的增大的上下文切换开销。

作为控制并列度的具体例，有扩展HTTP服务器使在页单位上限制并列度的文献(松沼正浩、日比野秀章、佐藤芳树、光来健一、千叶滋著“改善过负荷时的web应用的性能恶化的Session-Level Queue Scheduling”，第二届可靠软件研讨班(DSW’05)，pp.105-114，2005年1月)。但是，即使在服务器上控制并列度，也不能避免作为请求处理性能降低的第一原因的、伴随服务器处理不完的请求的接收的中断、TCP/IP处理等的开销。其结果，和其他的方法同样，会发生过剩通信时的服务器的处理性能降低。另外，因为需要HTTP服务器或者Web应用的变更，所以有向已经在运用中的服务的导入障碍高的问题。

作为控制并列度的再一例，有流服务器的对话数限制。亦即，一般在流服务器中给能够同时保持的对话数设定上限。由此，避免伴随对话数的增大而产生的服务器的过负荷。

但是，对话数的限制，并不是限制通过RTSP进行的控制请求的接收。因此，当RTSP请求向流服务器集中时，会产生对于请求的处理开销表面化，而流服务器的处理性能降低这样的问题。

服务器的性能降低，如图3(a)所示，由于通过新请求的接收使中断、输入输出、上下文切换开销等增加而产生。为了消除这样的开销，最大限度地发挥服务器的性能，如图3(b)，在服务器中的处理结束的瞬间下一请求到达是理想的。在该场合，没有由服务器处理不完的请求的接收而引起的开销。另外，在服务器中不产生从处理结束到下一请求到达的空闲的时间。

发明内容

本发明是在这样的背景下做出的，其目的在于，提供一种负荷控制装置及其方法，其能够避免在接收过剩请求时的服务器的性能降低。

本发明的负荷控制装置，被配置在客户机和服务器之间，居中调停两者的请求·应答的收发。亦即，向服务器发送从客户机接收到的请求，进而向客户机发送从服务器返回的应答。此时，本发明限制向服务器发送完毕的、但是还未从服务器返回应答的请求、亦即等待应答请求的数。为进行该限制，如果应答等待请求数达到了阈值，则对已接收的请求进行缓冲，在应答等待请求数降到阈值以下前，使请求的发送等待。

本发明，为了模拟图3(b)的理想的请求的到达，限制服务器的请求发送。为简化说明，首先，图4(a)表示把应答等待请求数的阈值设为“1”的场合。为模拟图3(b)，首先，需要知道服务器中的线程的执行结束。在本发明中，从服务器通过应答的接收识别服务器中的线程的执行结束。然后，返回对于先前发送的请求的应答后才向服务器发送下一请求。根据本发明，不向服务器发送服务器未处理完的请求。因此，可以削减伴随请求的接收处理而产生的服务器的开销。

图4(a)中，在从服务器返回应答到负荷控制装置发送下一请求之间，在服务器中产生空闲。为避免该问题，在本发明中，作为应答等待请求数的阈值，可以设定比“1”大的值。图4(b)表示把应答等待请求数的阈值设为“2”的场合的执行例。通过把应答等待请求数取为多个，增加服务器上处于可执行状态的线程数。因为当某线程的执行结束时，能够立即开始下一线程的执行，所以在服务器的请求中就不容易产生空闲。进而，根据本发明，能够不参照服务器的内部信息而从服务器的外部控制服务器的负荷。因此，能够在不对已经运行中的服务器追加或者变更附加的功能的情况下，导入本发明。

另外，根据本发明，能够自动调整应答等待请求数的阈值。最佳应答等待请求数的阈值，根据服务器的系统结构(服务器台数、CPU数等)、应用的执行时间而不同。因此，在静态地设定应答等待请求数的阈值的场合，需要事前的性能评价等、加给负荷控制装置的管理者的负担大。

例如，CPU数是2的服务器能够同时处理的请求数比CPU数是1的服务器多。因此，为使服务器的通过量最大化，CPU数是2的场合的应答等待请求数的阈值需要比CPU数是1的场合设定得大。

另外，当着眼于应用时，其执行时间越短，负荷控制装置和服务器之间的发送延迟相对变得越大。因此，执行时间越短的应用，需要把应答等待请求数的阈值设定得越大，使能够隐蔽通过发送延迟时间引起的空闲时间。

另外，当应答等待请求数的阈值变大时，服务器上多重处理的请求数也增加。因此，当阈值变得过大时，服务器中的上下文切换开销增加，引起通过量降低。进而，会产生从负荷控制装置向服务器发送请求到应答返回来的应答时间恶化这样的问题。

因此，在本发明中，测量服务器的应答时间或者通过量，根据该测量结果自动调整应答等待请求数的阈值。由此不依赖服务器的系统结构或者应用，能够得到希望的应答时间以及通过量。其结果，能够减轻应答等待请求数的阈值的设定中所需要的管理者的负担。

如现有技术a)中所示，一般在Web服务器中，给TCP连接的同时连接数设置有上限。但是，当给TCP连接的同时连接数设置限制时，有时根据应答等待请求数的负荷控制会不起作用。为解决该问题，在本发明中，把基于应答等待请求数的负荷控制，和现有技术的一种连接集约组合起来使用。所谓连接集约是使用HTTP1.1的Keep-Alive功能、由多个客户机共享在负荷控制装置和服务器之间建立的TCP连接的技术。

在不使用连接集约的场合，超过现在连接中的客户机数的TCP连接，在负荷控制装置和服务器之间连接。因此，在请求的发送频度低的客户机尝试连接多个的场合等，在超过应答等待请求数前有服务器的TCP连接数达到上限的可能性。其结果，不能为充分利用服务器的计算资源向服务器供给足够量的请求。对此，在使用连接集约的场合，能够在负荷控制装置侧进行调整，以使TCP连接数不超过应答等待请求数。亦即，只要服务器的TCP连接的同时连接数的上限比应答等待请求数的阈值大，就能使TCP连接的同时连接数的限制无效。

亦即，本发明是一种负荷控制装置，其被配置在客户机和服务器之间，向所述服务器发送从所述客户机接收到的请求，向所述客户机发送对于该请求从所述服务器返回的应答。

这里，本发明的特征在于，具有对已向所述服务器发送完毕但是未从所述服务器返回应答的应答等待请求数进行限制的单元，该进行限制的单元具有：如果应答等待请求数达到阈值，则临时存储接收到的请求的缓冲器；以及在应答等待请求数下降到低于阈值前使来自所述缓冲器的请求的发送等待的单元，。例如，所述阈值取比“1”大的值。

另外，希望具有以下单元：监视所述服务器的执行状况的单元；和根据所述进行监视的单元的监视结果在对于所述服务器的请求的应答时间在允许范围内时增大所述应答等待请求数的阈值，而在该应答时间超过允许范围时减小所述应答等待请求数的阈值的单元。

或者希望具有以下单元：监视所述服务器的执行状况的单元；根据该进行监视的单元的监视结果对于应答等待请求数的每一阈值测定在每单位时间服务器已处理的请求数的通过量的单元；和在对于现在的阈值的通过量高于对于比现在的阈值小的阈值的通过量的场合，增大阈值，而在对于现在的阈值的通过量低于比现在的阈值小的阈值的通过量的场合，减少阈值的单元。

另外，此时，通过具有判定应答等待请求数是否达到其阈值的单元；和在达到阈值的场合判定是否增大或者减小阈值的单元，能够消除在对于服务器不施加大量负荷的状态下，应答等待请求数的阈值无限制增大的问题。

另外，希望具有这样的单元，亦即，为了使所述服务器和自己之间的TCP连接的同时连接数成为所述应答等待请求数的阈值以下，集约自己和所述客户机之间的TCP连接的单元。

另外，所述缓冲器可以具有根据发送源客户机的识别信息优先控制请求的单元。

或者，所述缓冲器可以具有根据是否在请求中的特定的位置或者范围内包含特定的模式来优先控制请求的单元。

或者，所述缓冲器可以具有根据请求中的特定的变量是否比预先设定的阈值大来优先控制请求的单元。

或者，所述缓冲器可以具有根据请求是否被加密来优先控制请求的单元。

或者，所述缓冲器可以具有对于在规定时间以上存储的请求通知忙消息的单元。

或者，所述服务器是Web服务器，所述缓冲器可以具有根据请求的页显示的显示优先度来优先控制请求的单元。

或者，所述请求通过TCP连接从客户机向负荷控制装置发送，所述缓冲器可以具有根据在客户机和负荷控制装置之间连接的其他的TCP连接的有无或者TCP连接的数以及该请求是否是TCP连接的最初的请求来优先控制请求的单元。

或者，具有在对应答指示了浏览器应该自动取得的页构成要素的URL的场合，临时存储应答发送目的地的识别信息和该URL的组的单元，所述缓冲器，可以具有根据请求的发送源的识别信息和URL的组与临时存储的应答发送目的地的识别信息和URL的组是否一致来优先控制请求的单元。

或者可以具有根据所述请求属于的对话的进行状况来优先控制请求的单元。

或者可以具有在一定期间超高速缓冲存储在所述服务器中处理的请求属于的对话的对话识别信息的单元；和根据是否具有超高速缓冲存储的对话识别信息来优先控制请求的单元。

或者，所述缓冲器可以具有根据从客户机发送的通信的不正当访问的可疑度来优先控制请求的单元。

本发明也可以看作是程序。亦即，本发明是通过在通用的信息处理装置中安装而使该通用的信息处理装置实现与本发明的负荷控制装置的功能相应的功能的程序。

另外，本发明也可以看作是记录介质。亦即本发明是记录本发明的程序的记录介质。本发明的程序，通过被记录在本发明的记录介质中，所述通用的信息处理装置能够使用该记录介质安装本发明的程序。或者，也能够从保存本发明的程序的服务器通过网络将本发明的程序直接安装在所述通用的信息处理装置中。

由此，用通用的信息处理装置，就能够实现本发明的负荷控制装置。

另外，可以把本发明看作是本发明的负荷控制装置执行的负荷控制方法的发明。亦即，本发明是一种负荷控制方法，其特征在于，具有限制已向所述服务器发送完毕但是未从所述服务器返回应答的应答等待请求数的步骤，该进行限制的步骤具有以下步骤：如果应答等待请求数达到了阈值，则将接收到的请求临时存储在缓冲器中的步骤；和在应答等待请求数下降到低于阈值前使来自所述缓冲器的请求的发送等待的步骤。例如所述阈值取比“1”大的值。

另外，希望具有以下步骤：监视所述服务器的执行状况的步骤；和根据所述进行监视的步骤的监视结果在对于所述服务器的请求的应答时间在允许范围内时增大所述应答等待请求数的阈值，而在该应答时间超过允许范围的场合减小所述应答等待请求数的阈值的步骤。

或者希望具有以下步骤：监视所述服务器的执行状况的步骤；根据该进行监视的步骤的监视结果对于应答等待请求数的每一阈值测定在每单位时间服务器已处理的请求数的通过量的步骤；和在对于现在的阈值的通过量高于对于比现在的阈值小的阈值的通过量的场合，增大阈值，而在对于现在的阈值的通过量低于对于比现在的阈值小的阈值的通过量的场合，增小阈值的步骤。

另外，此时，希望具有判定应答等待请求数是否达到其阈值的步骤；和在达到阈值的场合判定是否增大或者减小阈值的步骤。

另外，希望具有这样的步骤，亦即为了使所述服务器和自己之间的TCP连接的同时连接数成为所述应答等待请求数的阈值以下，集约自己和所述客户机之间的TCP连接的步骤。

根据本发明，能够避免接收过剩请求时服务器的性能降低。此时，因为也能使用于适当控制的阈值的设定自动化，所以能够减轻装置管理者的负担。

附图说明

图1是用于说明通过过剩请求引起的服务器的处理性能降低的图。

图2是表示理想的通过量的举动的图。

图3是表示过剩请求时的服务器的动作以及请求到达服务器的理想的状态的图。

图4是表示通过本发明请求到达服务器的状态的图。

图5是表示第一实施形态的全体结构图。

图6是表示第一实施形态的负荷控制装置的处理过程的流程图。

图7是表示第一实施形态的请求接收处理的执行过程的流程图。

图8是表示第一实施形态的应答接收处理的执行过程的流程图。

图9是表示基于RTSP请求的方法名的类分类的一例的图。

图10是第二实施形态的负荷控制装置的方框结构图。

图11是表示第二实施形态的请求接收部的处理过程的流程图。

图12是表示请求表的图。

图13是表示第二实施形态的请求发送部的处理过程的流程图。

图14是表示服务器侧套接字表的图。

图15是表示第二实施形态的应答接收部的处理过程的流程图。

图16是表示第二实施形态的应答发送部的处理过程的流程图。

图17是表示第二实施形态的调度部的处理过程的流程图。

图18是表示证实本发明的效果的实验的结构的图。

图19是表示用于实验的服务器以及负荷控制装置的结构表的图。

图20是表示本发明的效果的图。

图21是表示用于证实自动调整本发明的应答等待请求数的效果的实验的服务器以及负荷控制装置的结构表的图。

图22是表示对于应答等待请求数的阈值的设定值的通过量的变化的图。

图23是表示自动调整本发明的应答等待请求数的阈值的效果的图。

图24是表示进行本发明的请求的优先控制的效果的图。

具体实施方式

(第一实施形态)

参照附图说明本发明的第一实施形态。

图5是表示本发明的第一实施形态的框图。本发明由发行请求的客户机1-1～1-n；返回与请求对应的应答的服务器4；以及居中调停请求以及应答的负荷控制装置3组成。另外，服务器4可以是Apache等的软件模块，也可以是CPU和存储器等物理资源与负荷控制装置3独立的硬件模块。另外，也可以把本负荷控制装置3连接在两个以上的服务器4上，用一个负荷控制装置3对于多个服务器4进行负荷控制。进而，负荷控制装置3，也可以扩展安装反向Proxy、Web加速器、Firewall、负荷分散系统等的现有技术。在负荷控制装置3中，监视已向服务器发送完毕但是尚未返回应答的请求数即应答等待请求数。在应答等待请求数超过规定的阈值的场合，缓冲存储接收到的请求。然后，在应答等待请求数降低到低于阈值前，暂缓请求的发送。

图6表示负荷控制装置3的处理过程。当开始执行时，负荷控制装置3首先等待到接收消息(S1)。这里，假定负荷控制装置接收的消息仅有请求或者应答两种。当接收到消息时(S2)，在该消息是请求的场合起动请求接收处理(S3)，在是应答的场合，起动应答接收处理(S4)。

图7表示请求接收处理的执行过程。在接收请求的场合，负荷控制装置3在缓冲器中存储该请求(S10)。接着，判定应答等待请求数是否不到阈值(S11)。另外，在本实施形态中，假定应答等待请求数的阈值，是静态地给予了任意的值。在阈值以上的场合(S11)，暂缓向服务器4的请求的发送，结束本处理。在不到阈值的场合(S11)，从缓冲器选择一个请求取出(S12)。接着，在给应答等待请求数加1后(S13)，向服务器发送请求(S14)。

接着，图8表示应答接收处理的执行过程。首先，把已接收到的应答向发送该应答的请求的客户机返回(S20)。接着，把应答等待请求数减1(S21)。然后，判定缓冲器中是否存在等待发送请求(S22)。在请求不存在的场合(S22)，结束该处理。在请求存在的场合(S22)，和请求接收处理同样，尝试请求的发送。亦即，判定应答等待请求数是否不到阈值(S23)。在阈值以上的场合(S23)，暂缓向服务器4发送请求，结束本处理。在不到阈值的场合(S23)，从缓冲器中选择一个请求取出(S24)。接着，在给应答等待请求数加1后(S25)，向服务器4发送请求(S26)。

这样，在应答等待请求数超过阈值的场合，通过暂缓请求的发送，不向服务器4发送过剩的请求。另外，在超过阈值的场合，通过在缓冲器中存储请求，能够吸收瞬时的请求量的增减。其结果，能够对于服务器4稳定地供给请求。

作为调度缓冲器中的请求的执行顺序的算法，可以使用单一的队列根据FIFO(先进先出)处理请求。另外也可以使用多个队列根据请求的重要性或者要求质量实施优先控制。在该场合，根据一定的规则把请求分类，根据分类结果设定优先控制的参数(例如优先级、重要性、超时时间)等。这里，把根据一定的规则分类的结果产生的请求的集合定义为类。然后按类别在队列中存储请求，根据优先控制参数调度各队列间的请求取出顺序。作为该调度算法，例如可以使用从属于优先级最高的类的请求进行处理的Priority Queuing、根据每类的重要性进行速率控制的Waighted Fair Queuing、Waighted Round Robin等已有的优先调度算法。另外，代替队列，可以使用按照到超时的时间长度为升序那样来排列请求的EDF(Earliest Deadline First)。通过进行请求的优先控制，能够优先在服务器4中处理重要的或者时间制约严格的请求。

另外，在缓冲器中存储请求时，缓冲器中的请求数有时达到可能存储的最大数。在该种场合，选择缓冲器中的任何一个请求，执行以下的任何一种。

·废弃：废弃请求。

·拒绝：停止向服务器4发送请求。然后，从负荷控制装置3向客户机1-1～1-n发送忙消息。和请求的废弃不同，可以向客户机1-1～1-n明示请求失败的原因是请求集中。

·转发：向过负荷时用的待机服务器转发请求。由此，代替负荷集中的服务器4，待机服务器可以处理该请求。

另外，也可以给缓冲器中的各请求设定超时。在检测到达到超时的请求的场合，也可以和缓冲器中的请求数达到可存储的最大数的场合实施同样的处理。

在实施请求的优先控制的场合，根据一定的规则把请求分成类，根据给每一类设定的优先级、重要性、超时时间等的参数进行调度。为高效率提供Web服务，只要根据以下表示的规则分类请求属于的类即可。另外，可以使用这些实施例的仅只任何一个，也可以组合多个实施例对类进行分类。

·基于客户机识别信息的类分类

·基于请求的内容的类分类

·基于有无加密的类分类

·基于页处理的进行状况的类分类

·基于对话处理的进行状况的类分类

·基于不正当的可疑度的类分类

(基于客户机识别信息的类分类)

根据请求的发送源客户机对类进行分类。以下表示实施例。

·基于发送源IP地址的类分类：在作为发送的协议使用TCP/IP的场合，能够从发送源IP地址识别客户机。所以，通过基于发送源IP地址选择队列，能够优先化或者非优先化来自特定的客户机的请求。

例如，在负荷控制装置中预先登记管理者的主机的IP地址。接着，当负荷控制装置接收请求时，如果是来自已登记的主机的请求，则在高优先的类中存储。由此，能够保护由管理者对于服务器的访问。

·基于User-Agent字段的类分类：在服务器是Web服务器的场合，客户机可以根据HTTP协议在请求的头标中包含User-Agent字段。

在User-Agent字段中，存储发行请求的客户机应用的信息。因此，在负荷控制装置中，通过根据接收到的请求的User-Agent的种类分成类，可以使来自使用该Web服务专用的浏览器的客户机的请求优先化，或者另外可以非优先化通过检索机器人等以机械方式发行的请求。

·基于用户ID的类分类：Web服务器，为识别客户机，根据客户机发行用户ID，可以指示在HTTP请求中包含给客户机发行的用户ID。该用户ID，可以使Cookie字段、URL的查询、请求的体内包含用户ID。因此，在负荷控制装置中，预先登记希望优先化(或者非优先化)的客户机的用户ID。接着，根据在HTTP请求中包含的用户ID和登记的用户ID是否一致选择类。由此，可以优先化来自支付了追加费用的客户机的请求，反之，或者非优先化来自在黑名单上记载的客户机的请求。

(基于请求的内容的类分类)

根据在请求中的头标或者内容的任意的位置(在是HTTP请求的场合，例如请求行、各字段等)是否和任意的模式一致、请求中的任意的变量是否超过阈值，来选择存储请求的类。以下列举使用HTTP协议的场合的实施例。另外，在以下的实施例中将模式以正规表现记述在“”中。

·基于方法的类分类：在HTTP中，根据对于资源的操作内容，准备多种方法。例如，为取得资源使用GET方法，为向服务器发送数据，使用POST方法。在在线购物或者个人信息的更新等的重要的处理中，因为必须向服务器发送用户输入的信息，所以不用GET方法而使用POST方法。这里，在HTTP中，方法名用请求中的请求行指定。因此，通过把请求行的方法名和模式“POST”一致的请求分类到高优先的类中，能够优先处理重要度高的请求。

·基于文件的种类的类分类：有时希望非优先化对于动态内容那样负荷高的处理的请求。从被请求的文件名能够识别是动态内容还是静态内容。例如，在作为动态内容使用CGI的场合，其请求的文件名的后缀是.cgi。因此，在非优先化CGI的场合，把对于请求的URL和模式“.cgi”一致的文件的请求分在低优先级的类中。

·基于文件长度的类分类：在希望非优先化试图上载非常大的长度的文件那样的请求的场合，给表示HTTP头标的请求长度的Content-Length字段的值设定阈值，把超过阈值的请求分在低优先级的类中。

(基于有无加密的类分类)

根据请求是否被加密选择请求的类。一般，被加密后发送的请求比不加密发送的请求包含重要的信息。因此，通过把被加密的请求分类到高优先的类中，能够保护重要的请求。例如，在Web服务中，作为请求的发送方法，可以选择不加密的HTTP通信、加密的HTTPS通信的任何一种。

此时，通过TCP连接的连接目的地端口号码识别是HTTP通信还是HTTPS通信。因此，在优先化被加密的请求的场合，只要把从在HTTPS通信用的端口上连接的TCP连接发送的请求分类到高优先的类中即可。

(基于页处理的进行状况的类分类)

在Web服务中，有时客户机的浏览器需要多个请求显示1页。在本说明书中把为显示1页的请求的重复称为页处理。页处理的基本的进行步骤如下。首先，客户对于浏览器输入成为希望取得的页的路径的资源(以下称页路径资源)的URL。接着，浏览器根据输入的URL，对于Web服务器发送请求，取得页路径资源。

此时，在页路径资源中指示为页显示所需要的其他的资源的URL。接着，浏览器对于指示的URL自动发行请求。递归重复上述过程直到取得为页显示所需要的全部资源。下面表示基于页处理的进行的类分类的实施例。

·基于URL的类分类：通过优先处理对于页的显示不可缺的资源的请求，在服务器拥挤时用最小必要限度的页结构能够向更多的客户机提供服务。例如，在Web服务器中，在Web服务器的不同的目录中保存页显示不可缺的资源和不是这样的资源。于是，在负荷控制装置中，只要使用上述“基于请求的内容的类分类”，把对于保存页显示不可缺的资源的目录属下的资源的请求分类到优先级高的类中即可。

·基于是否是对于页路径资源的请求的类分类：通过把对于页路径资源的请求分类到低优先级的类中，优先处理已经继续中的页处理。由此，能够消除服务器拥挤时页处理中的请求中途失败、在客户机的浏览器上显示不完全的页这样的问题。特别，在作为调度缓冲器中的请求的算法使用上述PriorityQueuing的场合，只要页处理中的请求在缓冲器中，就不处理对于页路径资源的请求。因此，服务器拥挤时能够有效地封锁开始新的页处理。

用于低优先化对于页路径资源的请求的方法如下。

·是否是TCP连接的最初的请求：在HTTP1.1中，能够用一个TCP连接收发多个请求·应答。因此，为了页显示在浏览器自动发送请求的场合，通常，再利用在对于页路径资源的取得中使用的TCP连接。

因此，通过在连接TCP连接后把第二个以后的请求分类到高优先的类中，能够保护正继续的页处理。另外，浏览器也能够对于同一服务器连接多个连接，用多个连接并列接收页显示所需要的资源。因此，即使是连接TCP连接后最初的资源，如果存在从同一客户机已经连接在服务器(或者负荷控制装置)上的TCP连接，则也可以把其请求例外地分类到高优先的类中。

负荷控制装置中的具体的执行过程如下。

1)当从服务器接收应答时，在表(客户机识别信息表)中追加成为返回目的地的客户机的识别信息。在表中已经存在该客户机的识别信息的场合，可以省略该步骤。

2)当接收请求时，参照客户机识别信息表。

3)在表中有作为该请求的发送源的客户机的识别信息的场合，把该请求分类到高优先的类中。另一方面，在表中没有的场合，把该请求分类到低优先级的类中。

4)当从同一客户机连接的TCP连接全部被切断时，从客户机识别信息表中删除该客户机的识别信息。

·页路径资源的URL的登记：在负荷控制装置中预先登记页路径资源的URL的一览表。然后，使用上述的“基于请求的内容的类分类”对类进行分类。亦即，负荷控制装置，当接收请求时，首先比较请求的URL和表中的URL。然后，如果该请求的URL和页路径资源的URL一致，则把该请求分类到低优先的类中。

·URL的超高速缓冲存储：在从服务器返回的应答中指示浏览器应该自动取得的资源的URL的场合，把该URL超高速缓冲存储一定时间，优先化对于该URL的请求。在HTTP协议中，通过HTML文件的Src标签等，指示浏览器应该自动取得的资源的URL。因此，负荷控制装置中的执行过程如下。

1)在应答的文件类型是HTML文件的场合，在内容中检索和模式“Src＝”一致的字符串。

2)在和模式“Src＝”一致的字符串存在的场合，接着抽出继模式“Src＝”之后的URL。

3)把抽出的URL和应答发送目的地的客户机识别信息的组超高速缓冲存储一定期间。

4)并用上述的“基于发送源客户机识别信息的类分类”和“基于请求的内容的类分类”，在从被超高速缓冲存储的客户机接收对于被超高速缓冲存储的URL的请求的场合，把该请求分类到高优先的类中。

(基于对话处理的进行状况的类分类)

在Web服务器中，有通过跨多个页进行阅览或者信息输入才结束一个服务的情况。例如，在在线购物中，进行要购买的商品的选择或者客户信息的输入，最后通过购买内容的确认，才结束购买手续。在本说明书中，在到结束需要多个页的服务中，把客户机取得开始页到取得最后的页结束称为对话。

对话，在进行金钱和物品或者交易、或者个人信息的更新等重要的处理的场合使用。但是，当服务器拥挤时，有对话大部分不结束这样的问题。这是因为当在服务器上并列处理的对话数增加时，在对话间竞争服务器资源，中途失败的对话增加的缘故。因此，在负荷控制装置中，即使服务器拥挤时，也根据请求属于的对话的进行状况对类进行分类，以使其能够维持高的对话通过量。

在进行对话处理的场合，Web服务器需要识别接收到的请求属于哪个对话。因此，在对话处理中，使用对话ID等的对话识别信息。例如，Web服务器，当接收到对于对话的开始页的请求时，对于每一对话发行唯一的对话ID，连同应答一起向客户机返回。在典型的Web服务器中，在HTTP应答的Set-Cookie字段中存储对话ID。接着，客户机把从服务器通知的对话ID包含在请求中来向服务器发送。此时，在通过应答的Set-Cookie字段通知对话ID的场合，在请求的Cookie字段中存储对话ID。Web服务器通过请求中的对话ID可识别该请求属于的对话。

另外，如上述，在流服务器中使用的RTSP，在标准中具有对话的概念。亦即，当通过SETUP请求开始对话时，发行对话ID，赋予以后的请求·应答。在RTSP中，在RTSP头标的Session字段中存储对话ID。

在本实施例的负荷控制装置中，首先，把请求中的对话ID作为关键字，评价该请求属于的对话的进行状况。例如，在一律优先化属于已经开始后的对话的请求的场合，如果是HTTP协议则检查请求中的Cookie字段等的有无，如果是RTSP协议则检查请求中的Session字段的有无，判定对话ID是否被包含在请求中。然后，把包含对话ID的请求分类到高优先的类中。由此，能够优先地用服务器处理开始后的对话。特别在作为调度缓冲器中的请求的算法使用上述的Priority Queuing的场合，只要在缓冲器中存在属于继续中的开始后的对话，则不处理要求新的对话开始的请求。因此，能够在服务器拥挤时有效地封锁新的对话处理的开始。

进而，因为避免了有恶意的客户机的不正当地使用对话ID，所以也能够验证对话ID的有效性。下面，表示负荷控制装置中的执行过程。

1)检查来自服务器的应答，如果是HTTP协议，则检查Set-Cookie字段等，如果是RTSP协议，则检查Session字段，判定是否新发行了对话ID。

2)在新发行了对话ID的场合，把该对话ID超高速缓冲存储一定期间。

3)验证在负荷控制装置中接收到的请求中是否包含有对话ID。

4)在请求中包含对话ID的场合，验证是否和超高速缓冲存储的对话ID的某一个一致。

5)在和任何一个对话ID都不一致的场合，该请求的对话ID无效，不需要把该请求分类到高优先的类中。

另外，作为对于对话ID从超高速缓冲存储器遗漏的对策，在请求具有的对话ID在超高速缓冲存储器中不存在的场合，也可以在服务器中处理该请求的时刻，在超高速缓冲存储器中再登记该请求具有的对话ID。

作为被超高速缓冲存储的对话识别信息，也可以使用请求的发送源IP地址、用户ID等的客户机识别信息。例如，代替对话ID，通过超高速缓冲存储在服务器中已处理请求的客户机的IP地址，以发送源IP地址单位优先化已开始的对话，以下表示本方法的实施例。

1)把负荷控制装置从服务器接收的应答的发送目的地客户机的IP地址超高速缓冲存储一定时期。

2)验证负荷控制装置接收到的请求的发送源IP地址是否与超高速缓冲存储的某个对话ID一致。在一致的场合，认为是来自服务器中的处理开始被认可的客户机的请求，把该请求分类到高优先的类中。

和使用对话ID的场合比较，本方法有连不需要优先化的对话也进行优先化的可能性这样的缺点。例如，在多个客户机通过同一Proxy访问负荷控制装置的场合，负荷控制装置接收的请求的发送源IP地址，全部成为Proxy的IP地址。

因此，在访问同一Proxy的客户机的任何一个中开始处理的场合，来自其他客户机的请求也被分类到高优先的类中。另一方面，作为使用发送源IP地址的优点，可以举出计算费用小，设定容易等。

也可以把对话识别信息的超高速缓冲存储器应用于上述基于页处理的进行状况的类分类中的“基于是否是对于页路径资源的请求的类分类”。亦即，页处理，可认为是以1页结束的特殊的对话处理。所以，把超高速缓冲存储对话识别信息的期间限制在一个页处理结束所需要的时间(典型的是数秒)。由此，在客户机访问新的页前，超高速缓冲存储器中的对话识别信息被删去。其结果，对于新页的页路径资源的请求，因为在超高速缓冲存储器中不存在对话识别信息，所以分类到低优先的类中。然后，在服务器中处理对于该页路径资源的请求的时刻，通过在超高速缓冲存储器中再登记对话识别信息，可以把对于页显示所需要的剩余的资源的请求分类到高优先的类中。

也可以不根据对话ID而根据请求的URL评价对话的进行状况。例如，在Web服务器中，将构成对话的各页的资源预先保存到对于每一页不同的目录中。由此，通过在资源的URL中表示的目录，能够识别请求所要求的资源属于的页。因此，在负荷控制装置中，通过使用上述的“基于请求的内容的类分类”，能够对于所要求的资源属于的每一页把请求分类到类中。此时，把离对话开始越近的页，将其优先级设定得越低。

在服务器是基于RTSP的流服务器的场合，也可以根据请求的方法评价对话的进行状况。如上述，在RTSP中，根据流的控制内容，准备了SETUP、PLAY、TEARDOWN等的方法。这些方法，可以分类为在对话确立以前使用、和在对话确立以后使用。

因此，通过把在对话确立以后使用的方法的请求分类到优先级高的类中，能够优先化确立结束的对话。图9表示在RTSP中使用的方法及其分类目的地类的设定例。

(基于不正当的可疑度的类分类)

有时通过恶意客户的不正当的访问占有服务器的计算资源。为避免该问题，在本实施例的负荷控制装置中，也可以并用检测怀疑不正当访问的通信的侵入检测功能，把判定为不正当访问的可能性高的请求分类到低优先的类中。进而，也能够与“基于客户机识别信息的类分类”联合，把判定为发送不正当访问的可能性高的通信的请求在一定期间非优先化。亦即，

1)在负荷控制装置中，评价接收中的通信是不正当访问的可能性。

2)在一定期间记录判定为不正当访问的可能性高的通信的发送源识别信息。

3)当接收请求时，判定该客户机的识别信息与记录的识别信息是否一致。

4)在一致的场合，分类到低优先的类中。

另外，侵入检测功能，也可以通过连接负荷控制装置和已有的侵入检测装置(IDS：Intrusion Diction System)等，作为负荷控制装置的外部装置来实现。在该场合，从侵入检测装置向负荷控制装置作为警报发送关于不正当访问的信息，亦即不正当访问的种类或者成为发送源的客户机识别信息。在负荷控制装置中根据警报实施请求的优先控制。

这样，通过把怀疑不正当访问的请求分类到低优先类中，在服务器拥挤时，能够从正常的可能性高的请求优先地进行处理。作为限制同样的不正当访问的装置有侵入防御系统。在侵入防御系统中，立即废弃被判定为不正当访问的通信。因此，由于把正常的请求误判定为不正当，有误限制正常请求的误限制的问题。但是，在本发明中，因为只要服务器不拥挤，怀疑不正当的请求也在服务器上处理，所以能够缓和侵入防御系统中的误限制的问题。

在第一实施例中，静态给予应答等待请求数的阈值。但是，如上所述，通过人工的应答等待请求数的阈值设定，会给负荷管理装置3的管理者施加大的负担。因此，扩展第一实施例，使a)能够最大限度地引出服务器4的处理性能，而且b)为把应答时间纳入允许范围，可以动态设定应答等待请求数的阈值。

列举用于自动调整应答等待请求数的阈值的实施例。

(自动调整的实施例1)

定期测定缓冲器中等待的(平均)请求数N以及从负荷控制装置3向服务器4发送请求到收到应答的(平均)应答时间T。另外，作为对于N、T的阈值，定为LN、LT。此时如果N＜LN，则因为请求量少，视之为应答等待请求数未达到其阈值。另外，如果T＜LT，则视之为返回了良好的应答。所以，

·如果T≥LT，则使减小应答等待请求数的阈值。

·T＜LT

如果-N≥LN，则使应答等待请求数的阈值增加。

如果-N＜LN，则使应答等待请求数的阈值不变。

(自动调整的实施例2)

定期测定缓冲器中等待的(平均)请求数N以及从负荷控制装置3向服务器4返回请求到收到应答的应答时间T。另外，作为对于N、T的阈值，定为LN、LT。进而，假定把成为T＞LT的请求的比例作为r。此时使用常数k(0≤k≤1)，

·如果r≥k，则使应答等待请求数的阈值减小。

·r＜k

如果-N≥LN，则使应答等待请求数的阈值增加。

如果-N＜LN，则使应答等待请求数的阈值不变。

(自动调整的实施例3)

定期测定缓冲器中等待的(平均)请求数N以及服务器4的使用率U。另外，作为对于N、U的阈值，定为LN、LU。

·如果U≥LU，则使应答等待请求数的阈值减小。

·U＜LU

如果-N≥LN，则使应答等待请求数的阈值增加。

如果-N＜LN，则使应答等待请求数的阈值不变。

不仅CPU使用率，也可以监视存储器使用率、带宽、并列度，把其最大值作为U。

(自动调整的实施例4)

定期测定缓冲器中等待的(平均)请求数N以及作为服务器4每单位时间能够处理的请求数的通过量T。另外，设现在的应答等待请求数的阈值为R。另外，做成对于每一个应答等待请求数的阈值R能够记录通过量。

这里，把对于应答等待请求数的阈值R的通过量记为T[R]。另外，作为对于缓冲器中的请求数N的阈值，定为LN。此时，根据测定的N以及T，实施以下处理。

1)如果N＜LN，则意味着应答等待请求数未达到阈值，所以不更新应答等待请求数的阈值而结束。如果N≥LN，则实施2)。

2)用T更新对于现在的应答等待请求数的阈值的通过量T[R]，接着实施3)。

3)比较对于现在的应答等待请求数的阈值R的通过量T[R]、和阈值更小的场合的通过量T[R’](R’＜R)。

A)在T[R]≥k1×T[R’]的场合：意味着通过增加应答等待请求数的阈值，能够提高通过量。所以会进一步使应答等待请求数的阈值增加。这里，k1是常数，k1≥1.0。

B)在T[R]≤k2×T[R’]的场合：意味着通过增加应答等待请求数的阈值，减少了通过量。所以，使应答等待请求数的阈值减小。这里，k2是常数，k1≤1.0。

C)在上述以外的场合，使应答等待请求数的阈值不变。

在本发明中，根据缓冲器中的等待请求数，判定应答等待请求数是否达到其阈值。然后，在判定应答等待请求数达到其阈值的场合，判定是否应该使应答等待请求数的阈值增加。

由此，在给服务器4没有施加足够的负荷的状态下，消除了应答等待请求数的阈值无限制增加的问题。另外，在上述实施例中，在N＜LN即应答等待请求数未达到其阈值的场合，保持应答等待请求数的阈值不变。但是，在N＜LN的场合，也可以使应答等待请求数的阈值减小。

在上述的实施例中，决定好应答等待请求数的阈值的最大值和最小值，在修正后的应答等待请求数的阈值成为其范围外的场合，也可以不进行其修正。

(第二实施形态)

下面，作为第二实施形态，表示作为收发请求以及应答的协议，使用在因特网中广泛使用的TCP/IP(传输控制协议/因特网协议)的场合。图10是表示本发明的第二实施形态的框图。本实施形态，由发行请求的客户机1-1～1-n、返回与请求对应的应答的服务器4、以及居中调停请求·应答的负荷控制装置3组成。负荷控制装置3也可以扩展安装反向Proxy、Web加速器、Firewall、负荷分散系统等的现有技术。

本实施形态的负荷控制系统由下面的5个功能块构成。

·请求接收部30

·请求发送部32

·应答接收部34

·应答发送部33

·调度部31

请求接收部30，向调度部31发送从客户机1-1～1-n接收到的请求。图11表示请求接收部30的处理过程。首先，当新确立来自客户机1-1～1-n的TCP连接时(S30)，在客户机1-1～1-n和负荷控制装置3之间生成用于收发应答的套接字(S31)。此时，在生成的套接字中，分配唯一识别套接字的ID(套接字ID)。

接着，选择一个客户机侧套接字(S32)。检查该客户机侧套接字(S33)。检查的结果，在套接字中包含新的请求的场合(S34)，进行从各套接字读出请求的请求接收处理(S35)。每次读出请求时，给各请求分配唯一识别请求的请求ID。

接着，为维持请求和客户机侧的套接字的对应关系，在图12表示的请求表中，登记请求ID以及套接字ID的组(S36)。最后，把接收到的请求向调度部31发送(S37)。

另外，检查客户机侧套接字的结果(S33)，在该套接字中不包含新的请求的场合(S34)，选择下一个客户机侧套接字(S32)，重复处理(S33～S37)(S38)。

进而，与请求的读出并行，检查是否由于超时等的原因TCP连接被切断(S39)。在连接被切断的场合，废弃该套接字(S40)。

请求发送部32，进行用于从负荷控制装置3向服务器4发送请求的套接字的管理、以及请求的发送处理。图13表示请求发送部32的处理过程。请求发送部32，当从调度部31接收到新的发送请求时(S50)，参照图14表示的服务器侧套接字表，检查在和发送目的地的服务器4之间是否存在空闲状态的套接字(S51)。这里，所谓空闲状态的套接字，指在负荷控制装置3和发送目的地的服务器4之间已确立TCP连接、而且迄今与对于服务器4发送的请求对应的应答已经全部接收了的套接字。

在检测到空闲状态的套接字的场合(S52)，把该套接字作为请求发送用套接字选择。在空闲状态的套接字不存在的场合(S52)，新确立和发送目的地的服务器4的TCP连接，生成请求发送用套接字(S53)。此时，给套接字分配唯一的ID。然后，在服务器侧套接字表中登记生成的套接字的ID(S54)，将其状态设为空闲状态。当选择空闲状态的套接字时，接着，在服务器侧套接字表中登记该请求ID(S56)。此时，把套接字的状态从空闲变更为忙(S55)。最后，对于服务器4发送请求(S57)。

另外，请求发送部32，经常监视并检测有无由于超时等被切断的TCP连接(S58)。在检测到被切断的TCP连接的场合(S59)，废弃对应的套接字(S60)。从服务器侧套接字表中删除(S61)。

像本实施形态这样，本发明，在请求发送时，不拘泥于其发送源客户机，将再使用空闲状态的套接字(连接集约)。通过连接集约，在负荷控制装置3侧，能够进行调整以使在服务器4和负荷控制装置3之间的TCP连接数不超过客户机数。因此，服务器侧套接字数不会超过应答等待请求数的阈值。所以，如果应答等待请求数的阈值比TCP连接数的限制小，则请求发送不会由于TCP连接数的限制而被封锁

在图13的实施例中，把一个套接字能够同时向服务器4发送的请求数取为1。但是，也可以不等待应答的返回，用一个套接字连续发送多个请求。通过从一个套接字连续向服务器4发送多个请求，能够减轻套接字的生成或者废弃的开销。

图15表示应答接收部34的处理过程。应答接收部34接收从服务器4返回的应答(S70)。接着，参照服务器侧套接字表，选择接收到应答的服务器侧套接字(S71)。接着，读入应答(S72)，从服务器侧套接字表的ID取得对应的请求ID(S73)。然后，作为接收到的应答ID，分配和对应的请求相同的ID。接着，向调度部31、应答发送部33发送应答(S74)。最后，为了能够从该套接字发送下一请求，把套接字的状态从忙变更为空闲(S75)。

图16表示应答发送部33的处理过程。在应答发送部33中，当接收到应答时(S80)，根据该应答ID(和请求ID一致)参照请求表，取得和应该发送应答的客户机连接的客户机侧套接字ID(S81)，选择客户机侧套接字。接着，通过在套接字中写入应答向客户机返回应答(S82)。

在调度部31中，和第一实施形态相同，在缓冲器中缓冲存储接收到的请求。然后，在应答等待请求数降低到低于阈值的场合，选择在缓冲器中存储的请求，向服务器4发送。

图17表示调度部31的处理过程。在接收到请求的场合，首先在缓冲器中存储请求(S90)。接着，判定在缓冲器中是否存在发送等待请求(S91)。在存在发送等待请求的场合，判定现在的应答等待请求数是否超过其阈值(S92)。在阈值以上的场合结束该处理。在发送中请求数不到阈值的场合，使应答等待请求数增加1(S93)。接着，从缓冲器中取出一个请求，对于请求发送部32发送(S94)。

另一方面，在接收到应答的场合，把应答等待请求数减1(S95)，使能够发送下一请求，其后的处理，和请求接收时相同，执行图17的步骤S91“缓冲器中存在请求？”及以下步骤。

在上述的实施例中，把服务器台数设为1台，但是也可以使用多个服务器。在使用多个服务器的场合，按照服务器台数复制调度部31、应答发送部33、应答接收部34。然后，在请求接收部30中，只要遵照送达地向各服务器用的各处理部分配请求即可。

为了表示本发明的效果，在PC(个人计算机)上安装本发明的负荷控制装置3，进行实验性评价。评价，是通过在有本发明的负荷控制装置3的场合和没有的场合比较使从客户机1-1～1-n向服务器4输入的请求率(每秒请求数：rps)变化了的场合的Web服务器的通过量(rps)。

图18表示实验的结构。如图18所示，客户机1-1～1-n和服务器4，通过L2开关5以及负荷控制装置3进行通信。在服务器4和负荷控制装置3之间以及负荷控制装置3和L2开关5之间的网络(省略图示)的带宽为1Gbps。另一方面，在客户机1-1～1-n和L2开关5之间的网络(省略图示)的带宽为100Mbps。这里，图19表示服务器4以及负荷控制装置3的结构。在本实验中，把负荷控制装置3的应答等待请求数的阈值固定为“10”。

为和现有的负荷控制方法比较，设定可同时连接服务器4的TCP连接数的上限为150。另外，把客户机1-1～1-n从发送到接收请求的超时时间设定为10秒。当达到超时时，客户机1-1～1-n切断TCP连接，撤消该请求。

图20表示实验结果。图20横轴为输入请求率，纵轴为通过量。图20表示对于来自客户机1-1～1-n的输入请求率(rps)的服务器4的通过量(rps)的变化。图20中的“本发明”表示有负荷控制装置3的场合的结果。“现有方法”表示不通过负荷控制装置3连接服务器4和客户机1-1～1-n的场合的结果。

从图20可知，如果输入请求率在100rps以下，则与负荷控制装置3的有无无关，服务器4的通过量与输入请求率成比例增加。但是，当输入请求率超过100rps时，在没有负荷控制装置3的场合，通过量显著降低。例如，输入率为200rps时的通过量为尖峰时的约60％。

另一方面，当使用本发明的负荷控制装置3时，即使输入请求率从100rps增加，其通过量也能够维持尖峰时的90％以上。以上的结果可以说证明了本发明的负荷控制装置3的有效性。

下面表示通过自动调整应答等待请求数的阈值而产生的效果。在本评价中使用和图18同样的结构。另外，图21表示本评价中的服务器4以及负荷控制装置3的细节。在本评价中，作为Web应用，设想在线购物，使用基准软件SPEC WEB2005Ecommerce(例如参照Http://www.spec.org)。在该Web应用中，到结束购物需要大约13页。另外，在客户PC上执行模拟现实的客户的动作的程序。

在客户机程序中，自动访问Web服务器，尝试对话的执行。此时，客户机程序的动作，和现实的客户相同，要考虑从取得一个页到移动到下一页的思考时间、读入页的超时。在超时的场合，尝试再次取得该页。另外，以一定的概率向前面的页返回，或者对话中途中断。在本评价中，首先向负荷控制装置3发送高于服务器4的最大处理性能的量的请求。接着，在静态设定应答等待请求数的阈值的场合、和根据本发明进行自动调整的场合，测定比较服务器4中作为单位时间处理的请求数的通过量。

首先，评价静态设定应答等待请求数的阈值的场合。图22表示其评价结果。图22的图表，表示对于应答等待请求数的阈值的设定值的通过量的变化。亦即图22的横轴是应答等待请求数的阈值的设定值，纵轴是服务器4的通过量(rps)。从图22的图表可知，服务器4的通过量在应答等待请求数的阈值是“2”的场合，是671rps为最大，伴随应答等待请求数的增加慢慢降低。从该结果可知，假定要希望把通过量维持在最大值的97％以上，就需要把应答等待请求数的阈值设定在“2”～“6”的范围内。

下面，表示使用上述的(自动调整的实施例4)，基于本发明自动调整了应答等待请求数的阈值的结果。另外，为表示基于本发明的阈值的自动调整法的有效性，一并表示将在非专利文献1中表示的页单位的并列度自动调整法应用到了在应答等待请求数的阈值的控制中的场合的结果。另外，非专利文献1中表示的页单位的并列度自动调整法如下。首先，定期测定通过量，决定是增加还是减小并列度。这里，把第i次的测定中的通过量设为Ti。另外，把第i次的测定时的并列度设为Ci。此时，

·如果Ci＞Ci-1而且Ti≥Ti-1，则使并列度增加。

·如果Ci＞Ci-1而且Ti＜Ti-1，则使并列度减小。

·如果Ci＜Ci-1而且Ti≥Ti-1，则使并列度减小。

·如果Ci＜Ci-1而且Ti＜Ti-1，则使并列度增加。

亦即，和前次的测定结果比较，如果通过量提高，则进行和前次相同的操作(并列度的增加或者减小)。反之，如果通过量减小，则施行和前次相反的操作。

图23的图表表示应答等待请求数的阈值的时间的变化。图23的横轴是时间(秒)，纵轴是应答等待请求数的阈值。在图23中，在基于本发明的自动调整法中，应答等待请求数的阈值固定到了阈值为“2”～“6”之间的时间，达到了观察时间的96.9％。此外，基于本发明自动调整的场合的平均通过量为660rps，这达到了静态设定的场合的最大通过量的98％。另一方面，从图23可知，在根据非专利文献1的方法中，应答等待请求数的阈值异常增加。在通过非专利文献1的方法中产生这种异常增加的原因如下。

(1)在基于非专利文献1的方法中，没有判定现在的应答等待请求数是否达到其阈值的单元。所以，当向服务器的输入请求率慢慢增加时，在达到应答等待请求数的阈值前有其阈值无限制增加这样的问题。与此相对，在本发明中，只要队列中的请求数未达到足够的数，就不使应答等待请求数的阈值增加，这样就避免了该问题。

(2)在基于非专利文献1的方法中，应答等待请求数的阈值的增减，从上次和此次的通过量的测量结果的比较这样的局部的通过量的变化来决定。因此，在通过量暂时大幅降低后慢慢恢复的场合等，会产生尽管通过量长期不能增大而应答等待请求数的阈值却无限制增加(或者减小)这样的问题。与此相对，在本发明的自动调整的实施例4中，通过对于每一个应答等待请求数的阈值记录比较通过量，就设计成了只要通过量不增加就不使阈值增加。另外，在自动调整的实施例1～3中，通过给应答时间设定阈值，就避免了应答等待请求数的阈值无限制增加的问题。

接着，作为基于本发明的请求的优先控制的效果的一例，表示基于对话的进行状况的类分类的评价结果。亦即，根据是否包含有效的对话ID，把请求分类。然后，使用Priority Queuing，优先在服务器中处理包含有效的对话ID的请求。本评价中使用和图18同样的结构。另外，本评价中的服务器4以及负荷控制装置3的细节和图21相同。但是，负荷控制装置的应答等待请求数的阈值静态地设定为10。以以上的条件为基础，在有负荷控制装置的场合和没有的场合下比较使对于Web服务器上试验对话处理的客户机数变化时的、Web服务器在单位时间能够结束的对话数(以下称对话通过量)。

图24表示实验结果。图24的纵轴是对话通过量，横轴表示客户机数。如图24所示，在到达400客户机之前，与负荷控制装置的有无无关，对于客户机数，服务器的对话通过量成比例地增加。但是，当超过400客户机时，服务器变得过负荷，在客户机之间就要竞争服务器资源。其结果，在没有负荷控制装置的场合，在各客户机中相等地发生超时或者中途中断，对话通过量转而降低。然后，在800客户机处，对话就变得完全不结束。与此相对，在本实施例的负荷控制装置中，更优先地处理正进行的对话。其结果，即使在Web服务器成为过负荷的状态下也一直最大地维持对话通过量。以上的结果，证明了根据本实施例的负荷控制装置的优先控制的效果。

可以说以上的结果表示本发明的有效性。

本实施例，通过在通用的信息处理装置中安装，能够在该信息处理装置中作为使实现与在本实施例中说明的负荷控制装置3相应的功能的程序来实施。该程序，被记录在记录介质上，并被安装在通用的信息处理装置中，或者通过通信线路被安装在通用的信息处理装置中，由此，就能够把该通用的信息处理装置作为与在本实施例中说明的负荷控制装置3相应的装置。

另外，本实施例的程序，不仅包含通过通用的信息处理装置可直接执行的程序，而且也包含通过安装在硬盘等上可执行的程序。另外，还包含压缩或者加密过的程序。

根据本发明，能够避免接收过剩请求时服务器的性能降低，另外，因为还能够自动化设定为适当控制的阈值，所以对于装置(网络)管理者以及网络·用户的双方来说，都能提高便利性。

Claims (23)

1.一种负荷控制装置(3)，其被配置在客户机(1-1、...、1-n)和服务器(4)之间，向所述服务器(4)发送从所述客户机(1-1、...、1-n)接收到的请求，向所述客户机(1-1、...、1-n)发送对于该请求从所述服务器(4)返回的应答，其特征在于，

具有限制已向所述服务器(4)发送完毕但是未从所述服务器(4)返回应答的应答等待请求的数的单元，

该进行限制的单元具有：

若应答等待请求数达到了阈值，则临时存储接收到的请求的缓冲器；

在应答等待请求数下降到低于阈值前，使来自所述缓冲器的请求的发送等待的单元；

在应答等待请求数不足阈值时，从所述缓冲器中选择取出一个请求，在把应答等待请求数加1后，将该请求发送给所述服务器(4)的单元；以及

把从所述服务器(4)接收到的应答返回给发送了该应答的请求的客户机，并使应答等待请求数减1的单元。

2.根据权利要求1所述的负荷控制装置(3)，其中，

所述阈值是比1大的值。

3.根据权利要求1所述的负荷控制装置(3)，

具有以下单元：

监视所述服务器(4)的执行状况的单元；和

根据该进行监视的单元的监视结果在对于所述服务器(4)的请求的应答时间在允许范围内时增大所述应答等待请求数的阈值、而在该应答时间超过允许范围的场合减小所述应答等待请求数的阈值的单元。

4.根据权利要求1所述的负荷控制装置(3)，

具有以下单元：

监视所述服务器(4)的执行状况的单元；

根据该进行监视的单元的监视结果对于应答等待请求数的每一阈值测定在每单位时间服务器(4)已处理的请求数即吞吐量的单元；和

在对于现在的阈值的通过量高于对于比现在的阈值小的阈值的通过量的场合增大阈值，而在对于现在的阈值的通过量低于对于比现在的阈值小的阈值的通过量的场合减小阈值的单元。

5.根据权利要求3或4所述的负荷控制装置(3)，

具有以下单元：

判定应答等待请求数是否达到了其阈值的单元；和

在达到了阈值的场合判定是否增大或者减小阈值的单元。

6.根据权利要求1所述的负荷控制装置(3)，

具有下述的单元，亦即，为了使所述服务器(4)和自己(3)之间的TCP连接的同时连接数成为所述应答等待请求数的阈值以下，集约自己(3)和所述客户机(1-1、...、1-n)之间的TCP连接的单元。

7.根据权利要求1所述的负荷控制装置(3)，其中，

所述缓冲器具有根据发送源客户机(1-1、...、1-n)的识别信息优先控制请求的单元。

8.根据权利要求1所述的负荷控制装置(3)，其中，

所述缓冲器具有根据是否在请求中的特定的位置或者范围内包含特定的模式来优先控制请求的单元。

9.根据权利要求1所述的负荷控制装置(3)，其中，

所述缓冲器具有根据请求中的特定的变量是否比预先设定的阈值大来优先控制请求的单元。

10.根据权利要求1所述的负荷控制装置(3)，其中，

所述缓冲器具有根据请求是否已被加密来优先控制请求的单元。

11.根据权利要求1所述的负荷控制装置(3)，其中，

所述缓冲器具有对于存储了规定时间以上的请求通知忙消息的单元。

12.根据权利要求1所述的负荷控制装置(3)，其中，

所述服务器(4)是Web服务器，

所述缓冲器具有根据请求的页显示的显示优先级来优先控制请求的单元。

13.根据权利要求1所述的负荷控制装置(3)，其中，

所述请求通过TCP连接从客户机(1-1、...、1-n)向负荷控制装置(3)发送，

所述缓冲器具有下述的单元，亦即，根据在客户机和负荷控制装置之间连接的其他的TCP连接的有无或者TCP连接的数以及该请求是否是TCP连接的最初的请求来优先控制请求的单元。

14.根据权利要求1所述的负荷控制装置(3)，其中，

具有在对应答指示了浏览器应该自动取得的页构成要素的URL的场合临时存储应答发送目的地的识别信息和该URL的组的单元，

所述缓冲器具有根据请求的发送源的识别信息和URL的组与临时存储的应答发送目的地的识别信息和URL的组是否一致来优先控制请求的单元。

15.根据权利要求1所述的负荷控制装置(3)，其中，

具有根据所述请求属于的对话的进行状况来优先控制请求的单元。

16.根据权利要求1所述的负荷控制装置(3)，其中，

具有以下单元：

在一定期间超高速缓冲存储在所述服务器(4)中处理的请求属于的对话的对话识别信息的单元；和

根据是否具有超高速缓冲存储的对话识别信息来优先控制请求的单元。

17.根据权利要求1所述的负荷控制装置(3)，其中，

所述缓冲器具有根据从客户机(1-1、...、1-n)发送的通信的非法访问的可疑度来优先控制请求的单元。

18.一种负荷控制方法，其由负荷控制装置(3)执行，所述负荷控制装置(3)被配置在客户机(1-1、...、1-n)和服务器(4)之间，向所述服务器(4)发送从所述客户机(1-1、...、1-n)接收到的请求，向所述客户机(1-1、...、1-n)发送对于该请求从所述服务器(4)返回的应答，其特征在于，

具有限制已向所述服务器发送完毕但是未从所述服务器返回应答的应答等待请求的数的步骤(S10-S14，S20-S26)，

该进行限制的步骤具有以下步骤：

若应答等待请求数达到了阈值，则在缓冲器中临时存储接收到的请求的步骤(S10，S11)；

在应答等待请求数下降到低于阈值前使来自所述缓冲器的请求的发送等待的步骤(S11-S14，S23-S26)；

在应答等待请求数不足阈值时，从所述缓冲器中选择取出一个请求，在使应答等待请求数加1后，将该请求发送给所述服务器(4)的步骤(S12-S14)；以及

把从所述服务器(4)接收到的应答返回给发送了该应答的请求的客户机，并使应答等待请求数减1的步骤(S20、S21)。

19.根据权利要求18所述的负荷控制方法，其中，

所述阈值是比1大的值。

20.根据权利要求18所述的负荷控制方法，其中，

具有以下步骤：

监视所述服务器(4)的执行状况的步骤；和

根据所述进行监视的步骤的监视结果在对于所述服务器的请求的应答时间在允许范围内时增大所述应答等待请求数的阈值，而在该应答时间超过允许范围的场合减小所述应答等待请求数的阈值的步骤。

21.根据权利要求18所述的负荷控制方法，其中，

具有以下步骤：

监视所述服务器(4)的执行状况的步骤；

根据该进行监视的步骤的监视结果对于应答等待请求数的每一阈值测定在每单位时间服务器已处理的请求数的通过量的步骤；和

在对于现在的阈值的通过量高于对于比现在的阈值小的阈值的通过量的场合增大阈值，而在对于现在的阈值的通过量低于对于比现在的阈值小的阈值的通过量的场合减小阈值的步骤。

22.根据权利要求20或者21所述的负荷控制方法，其中，

具有以下步骤：

判定应答等待请求数是否达到了其阈值的步骤；和

在达到了阈值的场合判定是否增大或者减小阈值的步骤。

23.根据权利要求18所述的负荷控制方法，其中，

具有下述的步骤，亦即，为了使所述服务器(4)和自己(3)之间的TCP连接的同时连接数成为所述应答等待请求数的阈值以下，集约自己(3)和所述客户机(1-1、...、1-n)之间的TCP连接的步骤。

Images