JP2009009592A - Congestion control method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To avoid and lessen faults (congestion) occurring in Web communication repeaters mainly comprising large scale web communication repeaters. <P>SOLUTION: An HTTP module 41 or a caching module 42 included in Web communication repeating software 31 performs method check about whether caching is possible or not and control is not possible (S101) and performs check (1) of a URI (S103) when caching is possible. When caching is possible in the step S103, URI hash retrieval (1) is performed (S107), and processing of one of normal caching (S111), priority caching (S113), and access suppression(S115) is determined. When caching is impossible in the step S101, URI check (2) (S105) and URI has retrieval (2) (S109) are performed, and processing of one of access suppression (S115), and access monitoring/control (S117) is determined. When control is impossible in the step S101, no-control (S119) is determined. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

The present invention relates to a congestion control method, and more particularly to a congestion control method in data communication between a client and a server.

With the rapid spread of the Internet, services such as ticket reservations and banking / securities transactions that were conventionally performed at sales outlets have come to be provided via the Internet. Communication technology has also advanced, and an environment has been established in which services can be enjoyed not only from homes and offices but also from mobile phones.

However, in the conventional method in which each client directly requests a service from the server, client requests are concentrated on the server. As a result, the communication line capacity and the capacity of the server device to process cannot respond to requests from a large number of users, and depending on the time of day and the access destination, no matter how many requests the user makes, a response is not easily returned. The case has come to happen.

In general, this can be improved by installing a Web communication relay device. Requests from clients are processed via a relay processing device called a Web communication relay device.
In the Web communication relay device, by installing a storage unit (caching module) that stores a part of past communication contents (called a cache), a request for the stored communication can be processed without connecting to a server. Proxy devices have been introduced in many communication systems because of their effectiveness.

At present, large-scale Web communication relay devices have been installed in communication systems targeting 10 million users. In such a communication system, requests for a large-scale Web communication relay device are excessively concentrated. When the concentration of requests occurs, the congestion of the communication path and the load on the device increase, so that it becomes difficult for the user to use the service provided by the communication system. In addition, if excessive concentration continues, a failure (congestion) may occur in the large-scale Web communication relay device, and operation may be stopped. When the operation of the large-scale Web communication relay device stops, it does not function as a communication system, and all users who use the communication system cannot use the service.

An object of the present invention is to avoid or reduce a failure that occurs in a Web communication relay apparatus mainly including a large-scale Web communication relay apparatus in view of the above points.

In order to solve the above-described problem, in the present invention, for example, a mechanism is provided for changing the control of request processing for each communication content requested by the Web communication relay device. In order to avoid an increase in the load on the Web communication relay device, the mechanism for determining the control to be executed does not provide a new processing unit, but instead uses a storage unit (caching module) that has existed in the Web communication relay device. Use.

The Web communication relay device verifies the communication contents currently being performed by the device and the state of the device, and determines a processing policy for a newly arrived request. As a result, communication that can be omitted can be detected, and by reducing the amount of communication, the Web communication relay device is prevented from falling into a congestion state.
Further, the communication process causing the congestion is processed by a method different from the normal process. For example, communication that causes congestion is preferentially stored. As a result, the Web communication relay device is prevented from falling into a congestion state.

The Web communication relay device detects a communication approaching a congestion state in the process of determining control for the request. As for communication close to the congestion state, it is announced that the user will refrain from communication without processing until the congestion is improved. This prevents deterioration of the congestion state,
It is avoided that the Web communication relay device becomes unavailable due to a failure.

In the large-scale Web communication relay device of the present invention, a request transmitted by a user is received by the load distribution device. The load distribution apparatus distributes the load to a plurality of Web communication relay apparatuses installed in the large-scale Web communication relay apparatus and transmits the distributed load. In the Web communication relay device, the caching module determines a user request and determines the control to be performed by the Web communication relay device. There are four types of congestion control: request aggregation, priority cache, access suppression, access monitoring, and regulation.

When multiple users make cacheable service requests and the Web communication relay device needs to communicate with the server, the Web communication relay device aggregates multiple requests into one request for the server. Communicate. This reduces the amount of communication between the Web communication relay device and the server. Moreover, since the request | requirement with respect to a server reduces, the load of a server is prevented from rising. In order to avoid congestion and reduce load on the server by the Web communication relay device,
The Web communication relay device can quickly respond to the user.

The Web communication relay device of the present invention provides a method for preferentially caching a specific service. Using this method, the communication system provider can register to preferentially cache a service that causes congestion. Traditional methods take precedence over the data being cached,
Since there is no distinction between non-priority, important data cannot be kept in the Web communication relay device. However, with this method, the Web communication relay device can hold data required by the user. The user can receive more services at high speed.

The Web communication relay device of the present invention provides a method for preventing a user from using a specific service. By using this method, the communication system provider can prevent the user from providing services that should cause the congestion and should not be provided by the communication system. In response to a request related to a service that is not provided, a response that the Web communication relay device cannot be provided to the user is returned, and the request processing is terminated.

Conventionally, since there is no suppression mechanism, the Web communication relay device wastes resources for communication with an unnecessary server. In addition, there is a possibility that the user keeps waiting without being provided with the requested service or tries to communicate many times. By using the method of the present invention, it can be quickly grasped that the service is not provided.

The Web communication relay device of the present invention measures the number of connections for a request that can confirm the number of service connections. If there are many identical requests even though requests cannot be aggregated, a certain number or more of requests can be processed as being inaccessible. At this time, the Web communication relay device notifies the user of the reason for the connection failure as a request result. This reduces the load on the server and avoids congestion of the Web communication relay device. Also, the user can grasp the service provision status without waiting for the requested service not to be provided.

According to a first solving means of the present invention, there is provided a congestion control method in a communication relay device provided between a client terminal and a server device, the request stored when a cache hit occurs according to a request from the client terminal. In the congestion control method for transmitting content to the client terminal and receiving the request content from the server device and transmitting the request content to the client terminal in the case of a cache hit or a request not using the cache, the input client terminal A method check step for determining whether cache is possible or not cacheable based on a request from the client, and if it is determined that cache is possible by the method check step, the URI included in the request from the client terminal is checked and cached Or 1U to judge whether or not And I checking step, according to the judgment by the first 1URI checking step, if cacheable, perform a search of the URI hash, usually a cache, the 1UR to determine any processing priority cache or access suppression is performed
There is provided a congestion control method including an I hash search step and a step of performing any one of a normal cache process, a priority cache process, and an access suppression process according to the determination by the first URI hash search step.

According to a second solving means of the present invention, there is provided a congestion control method in a communication relay device provided between a client terminal and a server device, the request stored when a cache hit is made in accordance with a request from the client terminal. In the congestion control method for transmitting content to the client terminal and receiving the request content from the server device and transmitting the request content to the client terminal in the case of a cache hit or a request not using the cache, the input client terminal A method check step for determining whether or not cache is possible based on a request from the client, and a second UR that checks the URI included in the request from the client terminal when the method check step determines that cache is not possible
I check step and URI hash search, access suppression or access monitoring
A second URI hash search step for determining whether any processing of restriction is performed, and an access suppression process or access monitoring /
A congestion control method including a step of performing any one of the restriction processes.

According to a third solving means of the present invention, there is provided a congestion control method in a communication relay device provided between a client terminal and a server device, the request stored when a cache hit occurs according to a request from the client terminal. In the congestion control method for transmitting content to the client terminal and receiving the request content from the server device and transmitting the request content to the client terminal in the case of a cache hit or a request not using the cache, the input client terminal A method check step for determining whether cache is possible or not cacheable based on a request from the client, and if it is determined that cache is possible by the method check step, the URI included in the request from the client terminal is checked and cached Or 1U to judge whether or not A first URI hash search step for determining whether a normal cache or a priority cache is processed by performing a URI hash search if the cache is possible according to the determination by the I check step and the first URI check step; When the method check step determines that the cache is not possible, the second URI check step for checking the URI included in the request from the client terminal, and the case where the cache is not cacheable by the determination by the first URI check step or the first 2 URI check step is transferred to search URI hash,
A second URI that determines whether access suppression or access monitoring / regulation is performed
A congestion control method comprising: a hash search step; and a step of performing any one of a normal cache process, a priority cache process, an access suppression process, and an access monitoring / restriction process according to the determination by the first or second URI hash search step provide.

By utilizing the present invention, a communication system provider can provide a user with a more reliable communication system than before. In addition, the user can use a communication system that can obtain a response with less waiting time than in the past.

A. Hardware Configuration and Schematic Configuration FIG. 1 shows a configuration diagram of a communication system. The communication system 100 includes, for example, client terminals 1-1 to 1-i, a large-scale Web communication relay device 2, and Web communication devices 3-1 to 3-j. The client terminals 1-1 to 1-i are, for example, user (terminal) devices that perform Web content acquisition (access) requests, data transmission / reception, screen display, and the like. The Web communication apparatuses 3-1 to 3-j, for example, respond to requests from the client terminals 1-1 to 1-i.
b A device that sends out content, and stores content data up to the disc capacity. Although the present embodiment mainly describes a large-scale Web communication apparatus, the present invention is not limited to this, and the present invention can be applied to a communication apparatus of an appropriate scale.

The large-scale Web communication relay device 2 includes, for example, a data relay device 21, an authentication device 22, a system management device 23, a layer 7 load distribution device 24, and Web communication relay devices 25-1 and 25-2.
5-n and an access restriction device 26.

The data relay device 21 is, for example, a device that relays data transmission / reception between devices inside and outside the large-scale Web communication relay device 2, Web communication devices 3-1 to 3-j, and client terminals 1-1 to 1-i. Then, the packet is transferred to the destination device indicated in the header of the transmission / reception data packet. The authentication device 22 includes (regular) client terminals 1-1 to 1-i in which relay services provided by the large-scale web communication relay device 2 are registered in advance and regular web communication devices 3-1 to 3-1.
3-j is an apparatus for authenticating that it is between j, and includes a database in which user information and service information are registered. The system management device 23 is a device for centrally managing each device in the large-scale Web communication relay device 2, for example.

For example, the layer 7 load distribution device 24 distributes Web content acquisition requests from the plurality of client terminals 1-1 to 1-i to the plurality of Web communication relay devices 25-1 to 25-n,
A device that distributes the load of relay processing, interprets the description of the destination, etc. described in the transmission / reception packet header and the Web content request / transmission header, determines the distribution route, and transmits the received data packet to the route . Web communication relay devices 25-1 to 25-n are, for example,
Web content acquisition requests from the client terminals 1-1 to 1-i are accepted, and the requests are relayed to the Web communication apparatuses 3-1 to 3-j, or the client terminals 1-1 to 1-i and the Web communication apparatus 3- It is a device that relays data transmission / reception between 1 to 3-j. For example, when a large amount of Web content acquisition requests are concentrated in a short time, the access control device 26 controls the access amount (acquisition request amount) so as not to exceed the processing limit of the large-scale Web communication relay device 2. Device.

FIG. 2 shows a configuration diagram of the Web communication relay device. The Web communication relay device 25-1 includes, for example, a main storage device 30 and Web communication relay software 31 stored in the main storage device 30.
An input / output device 32, a processor 33, a communication device 34 that transmits / receives data packets to / from the layer 7 load distribution device 24, a secondary storage device 35, and a bus 36 that interconnects these members. Prepare.

The secondary storage device 35 is a device (nonvolatile storage device) such as a magnetic disk, for example, and stores a program and various setting files. The secondary storage device 35 plays the following role.
(1) OS (operating system) data of the Web communication relay device 25-1 is stored, and the data is loaded into the main storage device 30 when the device is activated.
(2) Various application programs (data / setting files) operating on the OS are stored and loaded into the main storage device 30 when the application is started.
(3) Web content data relayed by the Web communication relay device 25-1 is stored as cache data.

In the Web communication relay device of the embodiment, a request from a client is processed in a processing unit called a session (one request corresponds to one session). Reserve a cache entry when a session uses a cache. When a session communicates with a server for caching, it must own a cache entry. This congestion control method is performed in individual session processing.

FIG. 3 is an explanatory diagram for data transmission / reception in the large-scale Web communication relay device.
For convenience of explanation, the same members as those described above are denoted by the same reference numerals, and the configuration and function are the same. Since each of the Web communication relay devices 25-1 to 25-n has the same configuration, only the Web communication relay device 25-1 will be described here.

The Web communication relay software 31 is stored in the Web communication relay device 25-1,
For example, an HTTP module 41, a caching module 42, and a proxy engine 43 are included. Here, data a to d in the figure are: a: request of the client terminals 1-1 to 1-i, b: response of the Web communication relay software 31, and c: Web communication relay software 3.
1 request and d: responses of the Web communication apparatuses 3-1 to 3-j, respectively.

When a cache hit occurs, only data a and b flow through the communication path (see FIG. 4).
In the case of a cache miss hit, data flows through the communication path in the order of data a, c, d, and b (see FIG. 5). Hereinafter, each process will be outlined.

a: Client request First, when a client request is transmitted from the client terminals 1-1 to 1-i, a large-scale W
The eb communication relay device 2 receives it. In the data relay device 21 of the large-scale Web communication relay device 2, the request is transferred to the layer 7 load distribution device 24. The layer 7 load distribution device 24 transmits one of the Web communication relay devices (in this case, the Web relay device 25- Send to 1). In the Web communication relay software 31 in the Web communication relay device 25-1, the HTTP module 41 and the caching module 42 receive the client request via the proxy engine 43.

b: Response of Web communication relay software Next, the Web communication relay device 25-1 that has received the client request analyzes the communication contents. Here, when the Web relay device 25-1 stores a Web page corresponding to the client request in the cache, the content is passed through the layer 7 load distribution device 24 and the data relay device 21, and then the client terminal 1-1. Send to 1.

c: Response of the Web communication relay software On the other hand, when the Web relay device 25-1 does not store the Web page corresponding to the client request in the cache, and / or when the client request is instructed not to use the cache The Web relay device 25-1 transmits information about the client request to the corresponding devices of the Web communication devices 3-1 to 3-j via the layer 7 load distribution device 24 and the data relay device 21.

d: Response of Web Communication Device When receiving the client request, the Web communication devices 3-1 to 3-j respond to the client terminal with a Web page corresponding to the client request via the data relay device 21. Further, the data relay apparatus 21 passes through the layer 7 load distribution apparatus 24 and the Web relay apparatus 25-1.
The communication contents and Web page are transferred. In the Web relay device 25-1, the Web
The page is cached in the caching module 42.

FIG. 4 is an explanatory diagram and a sequence diagram when a cache hit occurs. The sequence here corresponds to a dotted arrow in the configuration diagram. First, the client terminals 1-1 to 1-i
Request signal (data a) from the data relay device 21 in the large-scale Web communication relay device 2,
After passing through the layer 7 load balancer 24, the HTTP module 41 in the Web communication relay software 31 is input to the caching module 42, where it is determined as a cache hit. Next, the Web page again passes through the caching module 42, the HTTP module 41, the layer 7 load distribution device 24, and the data relay device 21 as a response signal (data b) of the Web communication relay software 31, and then the client terminal 1-1. To 1-i.

FIG. 5 is an explanatory diagram and a sequence diagram when a cache miss occurs. The sequence here corresponds to a dotted arrow in the configuration diagram. First, client terminals 1-1 to 1-1
The request signal (data a) from -i is the data relay device 2 in the large-scale Web communication relay device 2
1. Via the layer 7 load balancer 24, via the HTTP module 41 in the Web communication relay software 31, and then input to the caching module 42, where it is determined as a cache miss hit. Next, a request signal (data c) of the Web communication relay software 31
The caching module 42, the HTTP module 41, and the layer 7 load balancer 24
The data is transmitted to the Web communication devices 3-1 to 3-j via the data relay device 21. Further, in response to this, a response signal (data d) including the Web page of the Web communication devices 3-1 to 3-j.
Is input to the caching module 42 via the data relay device 21 and the layer 7 load distribution device 24 in the large-scale Web communication relay device 2, and the HTTP module 41 in the Web communication relay software 31. Next, the Web page again passes through the caching module 42, the HTTP module 41, the layer 7 load distribution device 24, and the data relay device 21 as a response signal (data b) of the Web communication relay software 31, and then the client terminal 1-1. To 1-i.

FIG. 6 is an explanatory diagram and a sequence diagram at the time of congestion. The sequence here corresponds to a dotted arrow in the configuration diagram. First, request signals (data a) from the client terminals 1-1 to 1-i are passed through the data relay device 21 and the layer 7 load balancer 24 in the large-scale Web communication relay device 2 and then in the Web communication relay software 31. Then, the data is input to the caching module 42 via the HTTP module 41.

Here, the Web communication relay software 31 is, for example, the Web communication devices 3-1 to 3-j.
If is congested, regulated content is generated. Here, for example, when requests of a certain level or more are concentrated on one Web page, it is determined as congestion. This restricted content is included in the data b and transmitted to the client terminals 1-1 to 1-i. At that time, the restricted content is sent again as a response signal (data b) of the Web communication relay software 31 via the caching module 42, the HTTP module 41, the layer 7 load balancer 24, and the data relay device 21 to the client terminal 1-1. To 1-i.

FIG. 7 is an explanatory diagram and a sequence diagram when an access suppression target content is requested. The sequence here corresponds to a dotted arrow in the configuration diagram. First, a request signal (data a) containing access-suppressed content from the client terminals 1-1 to 1-i.
) Is the data relay device 21 and the layer 7 load balancer 24 in the large-scale Web communication relay device 2.
Then, the data is input to the caching module 42 via the HTTP module 41 in the Web communication relay software 31. Here, for example, the Web communication relay software 31 requests the access suppression target content from the client terminals 1-1 to 1-i.
Generate deterrence announcements. This inhibition announcement is included in the data b and is transmitted to the client terminals 1-1 to 1-i. At that time, the suppression announcement is sent again as a response signal (data b) of the Web communication relay software 31 via the caching module 42, the HTTP module 41, the layer 7 load distribution device 24, and the data relay device 21, and then to the client terminal 1-1. To 1-i.

FIG. 8 is an explanatory diagram of the internal configuration of the Web communication relay software 31. Web
The communication relay software 31 is stored in the main storage device 30. The Web communication relay software 31 includes, for example, a data area 50 and a session processing process 45. The session processing process 45 includes, for example, an HTTP module 41 and a caching module 42.
A proxy engine 43. The proxy engine 43 realizes the basic functions of the Web communication relay software 31, and performs communication data transmission / reception, session management, and the like. The HTTP module 41 processes an HTTP packet. The caching module 42 is HTT
P caching and congestion control. The data area includes, for example, a proxy engine use area, an HTTP module use area, and a caching module use area. Further, the caching module use area includes, for example, a URI hash, a URI entry, and a U
Includes RI string, access restriction / suppression, message and format, cache entry area, cache data area.

FIG. 9 is an explanatory diagram of URI management using a URI hash and a URI entry.
The URI hash 70 is, for example, a list 70-0 to 70 of URI entries of Key0 to n.
-N is included. A list 70-0 of URI entries of Key0 is, for example, URI entry 7
1 includes a URI 1 (monitoring / regulation) 71-1 and a URI 2 (suppression) 71-2. In addition, the URI entry list 70-2 of the Key2 includes, for example, a URI entry 71 as a URI 3 (monitoring / regulation) 71-3, a URI 4 (normal cache) 71-4, and a URI.
5 (priority cache) 71-5. List of URI entries for Key n 70-n
Includes, for example, URIx (normal cache) 71-x.

Here, URI4 (normal cache) 71-4 and URIx (normal cache) 71-x
Includes normal cache data in the normal cache entry. The URI 5 (priority cache) 71-5 includes the priority cache data in the priority cache entry. here,
The URI management will be described in detail. The URI entry is managed by listing the same hash key based on the hash key calculated by applying the URI to the hash function. In this example, Key0 includes URI1 (monitoring / regulation) 71-1, URI2 (suppression) 71-2, K
In ey2, URI3 (monitoring / regulation) 71-3, URI4 (normal cache) 71-4,...
URI entries are listed. In addition, each URI in the list is subject to monitoring restrictions by request aggregation, deterrence target or priority cache target by operator instruction, normal cache, etc. Yes. Among these, for example, an entry of URI 4 (normal cache) 71-4 that is a normal cache indicates a specific address of the normal cache entry, and similarly, an entry of URI 5 (priority cache) 71-5 that is a priority cache is A specific address of the priority cache entry is shown.

In addition, in the caching module use area in the Web communication relay software on the main storage device 30, for example, a normal cache entry area, a priority cache entry area, and a cache data area are provided, which are prepared by dividing each into predetermined sizes. ing. The content data of the actual URI 4 (normal cache) 71-4 is stored in the normal cache entry area at the address indicated by the cache entry of the URI 4 (normal cache) 71-4. A cache data area is added. Similarly, the content data of the actual URI 5 (priority cache) 71-5 is the URI.
5 (priority cache) 71-5 is stored in the priority cache entry area of the address indicated by the cache entry, and a priority cache data area is added by a necessary amount depending on the size of the content.

Next, a caching module use area stored in the main storage device 30 will be described. The caching module usage area can be provided in an appropriate storage device other than the main storage device 30. FIG. 10 is an explanatory diagram (1) of the data structure in the caching module use area. The caching module use area includes a URI entry 71 and a cache entry 72, for example. Here, as the URI entry 71, for example, URI (example: http://www.abcde.co.jp/index.html), control type (example: normal cache), access counter (example: 3), cache, etc. Contains entry information.

The cache entry 72 is, for example, URI entry information (for example, http://www.abcde.co.
URI entry for jp / index.html), cache entry type (example: normal cache), cache status (example: caching in progress), owner session (example: session No. n), response waiting session list (example: session number) .X, No. y), including cache data information. The priority cache entry and normal cache entry are
Although the cache entry type values are different, the contents are the same. In the caching module 42, the priority cache entry is not deleted unless requested by the operator.
However, the normal cache entry is deleted when resources are insufficient.

FIG. 11 is an explanatory diagram (2) of the data structure in the caching module use area. The caching module use area also includes, for example, cache data 73. The cache data 73 is, for example, cache entry information (eg, http: //www.abcde.c
cache entry for o.jp/index.html), cache data type (example: normal cache), number of sessions referring to the cache data (example: 3), the following cache data information, and cache data. The priority cache data and the normal cache data have the same contents although the cache data type value is different. In the caching module 42, the priority cache data is not deleted unless requested by the operator. However, normal cache data is deleted when resources are insufficient.

B. Detailed Operation Next, caching and congestion control processing will be described. FIG. 12 is a flowchart showing basic processing for caching and congestion control processing. First, the Web communication relay software 31 performs a cache check and a control type determination (S201). The Web communication relay software 31 performs, for example, normal cache control (S2) according to the determination result.
03), priority cache control (S205), access suppression control (S207), access monitoring / regulation control (S209), or no control (S211), or a plurality of controls are performed, and the process ends.

Hereinafter, the cache check and the congestion control process determination will be described in detail. FIG.
These are flowcharts about cache check and congestion control processing determination. First, the caching module 42 included in the Web communication relay software 31 performs a method check as to whether the cache is possible, impossible, or controllable (S101), and if it is cacheable, checks the URI (1) (S103). . Caching module 42
If cache is possible in step S103, URI hash search (1) (S107)
Normal cache (S111), priority cache (S113), access suppression (S
115).

If the cache is not cacheable in the method check in step S101, the caching module 42 performs URI check (2) (S105), and further, the URI.
A hash search (2) (S109) is performed, and a determination is made as to one of access suppression (S115) and access monitoring / regulation (S117). Note that this URI hash search (2) is performed even in the case where caching is not possible in step S103. If the HTTP module 41 or the caching module 42 cannot be controlled by the method check in step S101, it determines that there is no control (S119). Here, each process described above will be described in detail.

(Method check in S101)
In the method check, the following processing is executed.
(A) First, a request method of a client HTTP request is acquired.
(B) Here, if the request method is GET or HEAD, the processing in the case of “cacheable” is performed.
(C) On the other hand, the request method is OPTIONS, POST, DELETE, TRAC
If it is E or CONNECT, the process in the case of “non-cacheable” is performed.
(D) Further, when the request method is an extension method not defined in RFC 2616, processing in the case of “uncontrollable” is performed.

FIG. 14 is an explanatory diagram of a client HTTP request. Client HT
The TP request 80 is, for example, as shown in FIG.
URI (here http://www.abcde.co.jp/). In this example, the above processing (a
), GET ′ is acquired as the request method, and the process proceeds to “cacheable”.

(URI check in steps S103 and S105 (1) (2))
(A) First, it is confirmed that the scheme is HTTP.
(B) Next, the path is checked to see if it contains the character “?”.
(C) Also check the path to see if it contains .cgi, .asp.
(D) Further, the presence / absence of the query is determined, and processing for removing the query is performed. Note that “there is a query” means that “?” Is attached.
(E) If there is a corresponding item in (b) or (c), the character string subjected to the “URI processing” is secured in the shared memory.
(F) If applicable in (b) and (c), perform processing in the case of “non-cacheable”, while if not applicable in (b) and (c), in the case of “cacheable” Proceed with the process.

FIG. 15 is an explanatory diagram of URI processing. For example, the URI is
Among URIs (for example, http: //www.abcde.co.jp/index.html), “http:” is a scheme and “//www.abcde.co.jp/index.html” is a path. The URI processing is, for example,
As shown in the figure, the query attached to the URI (for example, http://www.abcde.co.jp/a.cgi?a1=arg1&a2=arg2) is removed. In this example, the query is? A1 = arg1 & a2 = arg2 ', and except for this, it is assumed that http://www.abcde.co.jp/a.cgi.

Thus, in the URI check, a dynamically generated page such as CGI is checked before the URI hash search. Specifically, the identifier of the file indicated by the URI, and C
A determination is made based on the presence or absence of a parameter (argument) peculiar to the GI, and when it is determined that the page is a dynamically generated page such as CGI, an argument omission process is performed to generate a simplified short URI. As a result, the CGI having various queries is not processed as separate URIs including the queries, but is processed as one URI to realize access monitoring / regulation. In addition, in the URI check (1), whether or not cache is possible is determined together with the above determination.
On the other hand, in the URI check (2), since it is known in advance that the URI is not cacheable, the cache availability determination process is not performed.

(URI hash search in steps S107 and 109 (1) (2))
In the URI hash search (1) in step S107, the following processing is executed. For example, there is a cache area on the memory, the URI communicating with the client terminal is stored on the memory, and the memory table can be a URI hash.
(A) Search the URI hash.
(B) When a URI entry is hit, the control type of the URI entry is referred to, and the control described there is determined.
(C) If no URI entry is hit, the “normal cache” processing is determined.

In the URI hash search (2) in step S109,
(A) If “URI processing” is not performed, the URI in the HTTP request is used to
Search for the RI hash.
(B) When a URI entry is hit, the control described in the URI entry is referred to and the control described there is determined.
(C) If the URI entry is not hit, the “access monitoring / regulation” process is determined.

(Determined as a normal cache in step S111)
FIG. 16 is a flowchart for normal cache processing.
(1) First, a cache hit is determined (S111-1).
(1-1) If there is no hit, the process proceeds to the process of relaying the request to the Web server as the first access request. The caching module 42, for example, (a) creates a normal URI entry, (b) normal cache entry. (C) registration in the URI hash, (d) normal caching pre-processing for setting the owner in the cache entry, etc. (S111-
11). Next, the request is transferred to the Web server (S111-12), the response is received from the Web server (S111-13), and the response is transferred to the client (S111-1).
4). Next, the caching module 42 performs normal caching (step S1).
11-15). Here, in the normal caching in step S111-15, for example, the following processing is performed.
(A) Securing normal cache data.
(B) Copy the response of the Web communication device.
(C) Continue (a) and (b) until there is data.
(D) Check whether there is a registration in the response waiting session list.
(E) If there is a response waiting session in (d), a process start instruction is sent.
(F) Cancel the owner setting.

(1-2) If there is a hit, the process proceeds to request aggregation determination (S111-2). Here, for example, the caching module 42 has a function of consolidating access requests into one content that can be cached in order to reduce the access load to the Web server. When multiple requests for the same content are duplicated before the response is returned from the Web server, this function relays only the first request to the Web server, and temporarily sets the remaining requests to the processing wait state. The process is resumed after the response is returned. Specifically, the aggregation process is performed as follows. Here, in the aggregation determination process in step S111-2, (a) it is determined whether the state of the cache is ready. If it is ready, No is set. Also, (b) the owner of the cache entry determines whether it is a session that is currently performing the determination process. If the other session is the owner, the answer is Yes, otherwise N
Let o.

(2) If the request aggregation determination is Yes, the processing is stopped until the processing of the request relayed to the Web server is completed (S111-3). Here, in the process of waiting until processing is possible in step S111-3, (a) a session is registered in the response waiting session list of the cache entry, and (b) waits until it is called.

(3) Next, after step S111-3, when processing becomes possible, or step S1.
When the aggregation is not performed in 11-2, the process proceeds to the cache expiration date determination (S111-4). Here, in the determination of the cache expiration date in step S111-4, the RFC 26 in the cache is used.
The expiration date is calculated as described in 16, and if it is within the time limit, it is set as Yes, and if it is expired, it is set as No.

If the cache expiration date determination is Yes, data is extracted from the cache (S111).
-5). Here, in the cache fetching in step S111-5, (a) cache data is accessed as much as necessary. Next, the data extracted in step S111-5 is
Data is transferred to the client (S111-6). Normally, in this case, there is a high probability that fresh data has been cached immediately before (because the first request was waiting for data to be fetched from the Web server), so the cache is within the expiration date. There is also a high probability. As a result, the number of access requests to the Web server is reduced, and the access load can be reduced.

(4) On the other hand, if the cache expiration date determination is No, the request is transferred to the Web server (S
111-7), receives a response from the Web server (S111-8), and further transfers the response to the client (S111-9). Next, the caching module 42 performs normal caching (S111-10). Note that the request processed as the first access in (1-1) is checked in the normal caching process (S111-10) to see if there is a request whose process has been canceled. If it exists, an instruction to restart the process is issued.

Note that monitoring / regulation processing as described below may be added before step S111-1. At that time, as described later, first, a pre-monitoring / regulation process (S117-1) is added,
Thereafter, it is determined whether or not the regulation is to be performed (S117-2). If you do not regulate here,
The process proceeds to step S111-1. On the other hand, when the restriction is performed, a process of obtaining a restriction message (S117-3), a process of creating content from the restriction message (S117-4),
And the process (S117-5) which transfers a content to a client is performed. further,
After steps S111-6, S111-10, and S111-15, post-monitoring / regulatory processing (1
17-9) is added, and after the execution, the processing ends.

FIG. 17 is an explanatory diagram of an HTTP response of the Web communication apparatus. HT of this Web communication device
The TP response 85 is included in steps S111-8 and S13, for example.

FIG. 18 is an explanatory diagram for managing Web content data. First, the caching module 42 in the web communication relay software 31 receives the web communication apparatus HTTP response 85. The caching module 42 sends the Web communication device HTTP response 85 to
For example, the cache entry 55-1 including the Web communication device HTTP response Part 1, the cache data 55-2 including the Web communication device response data Part 2, and the cache data 55-n including the Web communication device response data Part n. Partition and store in the caching module usage area.

(Determined as the priority cache in step S113) FIG. 19 is a flowchart of the priority cache processing. In addition, the flowchart here shows step S111 mentioned above.
Compared with the normal cache processing, the processing is the same except for the processing that has been changed because the normal cache has become the priority cache. First, the caching module 42 determines whether or not the cache has hit (S113-1), and if there is a cache hit, determines whether or not to perform aggregation (S113-2). Here, in the aggregation determination process of step S113-2, (
a) The state of the cache is determined to be ready, and if it is ready, No. Also, (b) the owner of the priority cache entry determines whether the session is currently being determined, and if the other session is the owner, it is set to Yes, otherwise it is set to No.

Next, when the aggregation is performed in step S113-2, the caching module 42 waits until processing is possible (S113-3). Here, in the process of waiting until processing is possible in step S113-3, (a) a session is registered in the response waiting session list of the cache entry, and (b) waits until it is called. Next, the caching module 42 determines whether or not the cache is within the expiration date (S113-4). Here, step S11
In the determination of the cache expiration date of 3-4, the expiration date is calculated as described in RFC 2616. If it is within the expiration date, Yes is set, and if it is expired, No is set. If the cache is within the expiration date, the cache is taken out (S113-5). Here, in the cache fetching in step S113-5, (a) the cache data is accessed as much as necessary. Next, the caching module 42 transfers the cache to the client (S113-6).

If the cache is not within the expiration date in step S113-4, the caching module 42 forwards the request to the Web server (S113-7), receives a response from the Web server (S113-8), and further transmits to the client. The response is transferred (S113-9). Next, the caching module 42 performs priority caching (S113-10). Here, in the priority caching in step S113-10, (a) securing the priority cache data, (b) copying the response of the Web communication device, (c) continuing (a) and (b) until there is data ( d) Check whether there is a registration in the response waiting session list, (e) If there is a response waiting session in (d), send a processing start instruction, (f) cancel the owner setting, etc.

Further, if the cache does not hit in step S113-1, the caching module 42 performs normal caching pre-processing (S113-11). Here, step S
As the pre-cache processing of 113-11, for example, (a) creation of a priority URI entry, (b) creation of a priority cache entry, (c) registration in a URI hash, and (d) setting an owner in the priority cache entry. Can be mentioned.

In addition, after step S113-11, the caching module 42 transfers the request to the Web server (S113-12), receives a response from the Web server (S113-13), and
Further, the response is transferred to the client (S113-14). Next, the caching module 42 performs priority caching (S113-15). Step S113-
The preferential caching at 15 is the same as the processing at step S113-10.

In addition, before the step S113-1, monitoring / regulation processing as described below may be added. At that time, as will be described later, first, pre-monitoring / regulation processing (S117-1) is executed, and then it is determined whether or not regulation is to be performed (S117-2). Here, when not regulating, it transfers to step S111-1. On the other hand, when the restriction is performed, a process of obtaining a restriction message (S117-3), a process of creating content from the restriction message (S117-4), and a process of transferring the content to the client (S117-5) are executed. . Further, after the steps S113-6, S113-10, and S113-15, the post-monitoring / regulation processing (11
7-9) is added, and after the execution, the processing ends.

(Determined to inhibit access in step S115)
As a method of creating the access suppression content, for example, an access suppression message and an access suppression content format are prepared and dynamically generated. For example, the access suppression message group and the format of the access suppression content are stored above. The caching module 42 generates an access-suppressed content by taking out a message appropriate for the state and inserting it into the access-suppressed content format. For example, as shown in the following figure, a general message 93 “requested content cannot be used” at the time of suppression is inserted into the access suppression message format and the access suppression content is generated.

FIG. 20 is a flowchart of the access suppression process. First, the caching module 42 acquires a suppression message (S115-1), creates content from the suppression message (S115-2), and transfers the content to the client (S115-3).
).

FIG. 21 is an explanatory diagram of a suppression message and suppression content. The suppression message 91 is
For example, it is displayed in correspondence with “the requested content cannot be used”. Moreover, the suppression content 93 is displayed as shown in the figure, for example.

(Decision of access monitoring / regulation in step S117)
FIG. 22 is a flowchart of access monitoring / restriction processing. First, the caching module 42 performs pre-monitoring / regulation processing (S117-1). Here, step S1
In the pre-monitoring / regulation processing of 17-1, the following processing is performed.
(A) Create a URI entry if not created.
(B) When (a) is executed, it is registered in the URI hash.
(C) Increase the access count in the URI entry by one.

Next, the caching module 42 determines whether or not to perform regulation (S117-2).
). Here, in the restriction determination process in step S117-2, (a) a URI entry access counter, (b) a URI entry restriction execution flag, (c) the number of restriction start connections set in the apparatus, (d) in the apparatus Referring to the set number of restriction end connections, if the restriction execution flag of (b) is not set, Yes is set if (a)> (c), and No is set otherwise.
On the other hand, when the restriction execution flag (b) is set, Yes is set if (a)> (d), and No is set otherwise.

The caching module 42 acquires a restriction message (S117-3) and creates content from the restriction message (S117-) when the restriction is performed in step S117-2.
4) Transfer content to the client (S117-5). On the other hand, step S117.
-2 does not regulate, the caching module 42 transfers the request to the Web server (S117-6), receives the response from the Web server (S117-7), and transfers the response to the client (S117-). 8).

Further, the caching module 42 performs post-monitoring / regulation processing after steps S117-5 and 8 (S117-9). Here, in the monitoring and post-regulation processing in step S117-9,
The following processing is performed.
(A) Decrease the access count in the URI entry by one.
(B) If the access counter is 0, delete it from the URI hash.
(C) When deletion is executed in (b), the URI entry is deleted.

FIG. 23 is an explanatory diagram of restriction messages and restriction contents. The method for creating the access restriction message is the same as the method for creating the access deterrent content described above. The restriction message 95 is displayed in correspondence with, for example, “Currently crowded, please use later”. The restricted content 97 is displayed as shown in the figure, for example.

In the caching module 42, for example, in step S <b> 117-2, the following process may be performed to determine whether or not to restrict.
A. URI entry New parameters are added.
B. The parameter includes an average of response times when the Web communication relay apparatus has transmitted a request for the URI to the server in the past.
C. When the number of accesses is 1 or more, A. In consideration of the parameters added in (1), for example, if there is a certain number of accesses and communication is likely to take more than a set time, the communication is restricted even if the number of connections for restriction start is not reached.

(Determined without control in step S119) FIG. 24 is a flowchart of the process without control. First, the caching module 42 transfers the request to the Web server (S1
19-1) A response is received from the Web server (S119-2), and the response is transferred to the client (S119-3). Here, garbage collection (reuse of resources in the device) will be explained. When there is no space in the cache area, the garbage collection process is performed in order to erase and reuse the area where the data storage is old or the access frequency is low. Do. At the time of the garbage collection process, the priority cache entry is excluded from the target, and the additional determination that the data area used as the priority cache is also excluded from the process is performed with reference to the priority cache flag.

When the communication system does not support a request method that is not defined in RFC 2616, the effect of the invention can be obtained without installing no control (S119, S211). Also,
If the communication system does not process the HEAD method as a cache, step S10
This can be dealt with by processing the HEAD method in 1 with (c) instead of (b). The case where the number of restriction start connections and the number of restriction end connections used for access monitoring / regulation are dynamically changed will be described below.

FIG. 25 is a diagram showing an extended URI entry. By extending the URI entry as shown in FIG. 25, the number of restriction start connections and the number of restriction end connections used for access monitoring / regulation are as follows:
In addition to values set in advance in the apparatus, dynamically changed values can be used. For example, the next restriction start connection number and restriction end connection number are determined by the restriction start time and the restriction end time.

FIG. 26 is an explanatory diagram showing dynamic changes in the number of restriction start connections and the number of restriction end connections. Here, it is an example in which the number of restriction start connections and the number of restriction end connections are dynamically determined.
The change in the number of connections with respect to 2 is shown. Here, both URI1 and URI2 are shown in FIG.
The initial number of connections is set for the number of restriction start connections and the number of restriction end connections, respectively. In FIG. 26, the access restriction control is started for URI1 and URI2 at time t1. In this example, the restriction start time t1 is stored in each URI entry when restriction starts. When regulation ends, t1 and regulation end time t2 and t
3 is used to calculate the regulation implementation time. The regulation time T1 for URI1 is t2-t1, UR
The regulation execution time T2 for I2 is t3-t1. This is compared with the standard regulation execution time T assumed by the communication system, and the next regulation start connection number and regulation termination connection number are determined. In this example,
Since the value of T1 is much smaller than T, the number of restriction start connections and the number of restriction end connections of URI1 are increased by a certain number. Also, T2 is not so different from T, so the value is not changed.

Further, in the URI entry expanded as shown in FIG. 25, access monitoring / regulation can be performed by different methods. The proxy engine usage area inside the Web communication software 31 includes the We
The average response time when the b communication software 31 requests the Web communication devices 3-1 to 3-n is stored. Further, the URI entry stores an average response time for each URI. When there is a certain number of requests for the URI, the average response time of the entire Web communication software 31 is compared with the average response time for each URI, and if the response time of the average response time for each URI is significantly large, the access restriction process Can avoid congestion.

The block diagram of a communication system. The block diagram of a web communication relay apparatus. Explanatory drawing about transmission / reception of the data in a large-scale Web communication relay apparatus. An explanatory view and a sequence diagram at the time of a cache hit. An explanatory view and a sequence diagram at the time of a cache miss hit. An explanatory view and a sequence diagram at the time of congestion. An explanatory diagram and a sequence diagram when an access suppression target content is requested. An explanatory view about an internal configuration of Web communication relay software 31. FIG. Explanatory drawing about URI management by URI hash and URI entry. Explanatory drawing (1) about the data structure in the shared memory 55. FIG. Explanatory drawing (2) about the data structure in the shared memory 55. FIG. The flowchart which shows a basic process about caching and congestion control processing. The flowchart about a cache check and congestion control process determination. Explanatory drawing about the HTTP request | requirement of a client. Explanatory drawing about processing of URI. The flowchart about normal cache processing. Explanatory drawing of the HTTP response of a web communication apparatus. Explanatory drawing about management of Web content data. The flowchart about a priority cache process. The flowchart about an access suppression process. Explanatory drawing of a suppression message and suppression content. The flowchart about an access monitoring and control process. Explanatory drawing of a regulation message and regulation content. The flowchart about a process without control. The figure which shows the extended URI entry. Explanatory drawing which shows the dynamic change of the regulation start connection number and the regulation end connection number.

Explanation of symbols

1-1 to 1-i Client terminal 2 Large-scale Web communication relay device 3-1 to 3-j Web communication device 21 Data relay device 22 Authentication device 23 System management device 24 Layer 7 load distribution device 25-1 to 25-n Web communication relay device 26 Access restriction device 31 Web communication relay software 41 HTTP module 42 Caching module 43 Proxy engine 100 Communication system

Claims (21)

A congestion control method in a communication relay device provided between a client terminal and a server device. When a cache hit occurs according to a request from the client terminal, the stored request content is transmitted to the client terminal, and the cache hit occurs. In the congestion control method for receiving the request content from the server device and transmitting the request content to the client terminal in the case where there is no cache or a request not using the cache,
A method check step for determining whether cacheable or non-cacheable based on the input request from the client terminal;
A first URI check step for determining whether the cache is possible or not by checking the URI included in the request from the client terminal when the method check step determines that the cache is possible;
In accordance with the determination by the first URI check step, if a cache is possible, a URI hash search is performed to determine whether a normal cache, a priority cache, or an access suppression process is performed;
A congestion control method including a step of performing a normal cache process, a priority cache process, or an access deterrence process in accordance with the determination by the first URI hash search step. A congestion control method in a communication relay device provided between a client terminal and a server device. When a cache hit occurs according to a request from the client terminal, the stored request content is transmitted to the client terminal, and the cache hit occurs. In the congestion control method for receiving the request content from the server device and transmitting the request content to the client terminal in the case where there is no cache or a request not using the cache,
A method check step for determining whether cacheable or non-cacheable based on the input request from the client terminal;
A second URI check step for checking a URI included in the request from the client terminal when the method check step determines that caching is impossible;
A second URI hash search step for performing a URI hash search to determine whether access suppression or access monitoring / regulation is performed;
A congestion control method including a step of performing either an access deterrence process or an access monitoring / restriction process in accordance with the determination made by the second URI hash search step. A congestion control method in a communication relay device provided between a client terminal and a server device. When a cache hit occurs according to a request from the client terminal, the stored request content is transmitted to the client terminal, and the cache hit occurs. In the congestion control method for receiving the request content from the server device and transmitting the request content to the client terminal in the case where there is no cache or a request not using the cache,
A method check step for determining whether cacheable or non-cacheable based on the input request from the client terminal;
A first URI check step for determining whether the cache is possible or not by checking the URI included in the request from the client terminal when the method check step determines that the cache is possible;
In accordance with the determination by the first URI check step, if a cache is possible, a URI hash search is performed to determine whether a normal cache process or a priority cache process is performed;
A second URI check step for checking a URI included in the request from the client terminal when the method check step determines that caching is impossible;
When it is determined that the cache cannot be determined by the determination in the first URI check step or the second URI check step is performed, the URI hash is searched to determine whether to perform access suppression or access monitoring / restriction processing. A 2 URI hash search step;
A congestion control method including a step of performing any one of normal cache processing, priority cache processing, access deterrence processing, and access monitoring / regulation processing according to the determination by the first or second URI hash search step. The congestion control method according to claim 1, further comprising a step of performing a process without control when it is determined that the control is impossible by the method check step. The method check step includes
Obtaining a request method included in a request from a client terminal;
4. The congestion control method according to claim 1, further comprising a step of determining whether cacheable, noncacheable, or uncontrollable according to the acquired request method. The first URI check step includes:
Confirming that the scheme included in the request from the client terminal is the first scheme such as HTTP;
Processing the URI by removing the query attached to the URI;
Checking the path included in the request from the client terminal and checking if it contains a predetermined character;
If the predetermined character is included, a step of securing a character string obtained by processing the URI in the memory and shifting to a non-cacheable process;
The congestion control method according to claim 1, further comprising a step of shifting to a cacheable process when the predetermined character is not included. The second URI check step includes:
Confirming that the scheme included in the request from the client terminal is the first scheme such as HTTP;
The congestion control method according to claim 2, further comprising: processing a URI by removing a query attached to the URI. The first or second URI hash search step includes:
Retrieving a URI hash;
If the URI entry is hit, refer to the control type included in the URI entry,
4. The congestion control method according to claim 1, further comprising a step of determining the control described therein and a step of determining a predetermined process when no URI entry is hit. The congestion control method according to claim 8, wherein the URI entry includes a URI, a control type, an access counter, and cache entry information. 10. The congestion control according to claim 9, wherein the cache entry includes URI entry information, a cache entry type indicating various control types, owner session information indicating a session that is mainly used, and cache data information. Method. 11. The congestion control method according to claim 10, wherein the control type or the cache entry type is any one of a normal cache, a priority cache, access suppression, and access monitoring / regulation. The normal cache process or the priority cache process is:
Determining whether a cache hit has occurred;
Determining whether the cache is within an expiration date;
If the cache is within the expiration date, fetching the cache and transferring the cache to the client terminal;
The method includes the steps of: transferring a request from the client terminal to the server device if the cache is not within the expiration date; transferring a response received from the server device to the client terminal; and performing normal caching or priority caching. The congestion control method according to any one of 11. If the cache does not hit, performing a pre-caching process including one or more of normal or priority URI entry creation, normal or priority cache entry creation, URI hash registration, and cache entry owner setting;
13. The congestion control method according to claim 12, further comprising the steps of: transferring a request from the client terminal to the server apparatus; transferring a response received from the server apparatus to the client terminal; and further performing normal caching. If the cache hits,
If multiple requests for the same content are duplicated before the response is returned from the server device,
2. The method further includes an aggregation process in which only the first request is relayed to the server device, the remaining requests are temporarily put into a process waiting state, and the process is resumed after a response to the first request is returned.
3. The congestion control method according to 2. When garbage collection processing for erasing and reusing an area with a low access count when there is no more or less space in the cache area, priority cache entries are excluded, and referring to the priority cache flag, 15. The congestion control method according to claim 1, wherein a data area used as a priority cache is also excluded from processing. The access suppression process is:
Obtaining a suppression message for the requested content;
Creating content from the suppression message;
And transferring the content to the client terminal.
The congestion control method according to any one of 1 to 15. The access monitoring / regulation process
A regulation determination step for determining whether to perform regulation;
When performing regulation, obtaining a regulation message, creating content from the regulation message, and transferring the content to the client terminal;
17. The congestion control method according to claim 1, further comprising a step of transferring a request to the server device and transferring a response received from the server device to the client terminal when the regulation is not performed. Create a URI entry if it has not been created and register it in the URI hash;
18. The congestion control method according to claim 17, further comprising pre-monitoring / regulation preprocessing for executing processing for increasing an access count in a URI entry by one. The regulation determination step includes
(A) URI entry access counter, (b) URI entry restriction execution flag,
(C) With reference to the number of restriction start connections set in the device, (d) the number of restriction end connections set in the device,
When the restriction execution flag of (b) is not set, if (a)> (c), the restriction is performed, otherwise the restriction is not performed, while the restriction execution flag of (b) is set. 18. The congestion control method according to claim 17, wherein if (a)> (d), the restriction is performed, and if not, the restriction is not performed. If the access count in the URI entry is decremented by 1 and the access counter is 0, U
18. The congestion control method according to claim 17, further comprising post-monitoring / restriction processing for deleting from the RI hash and deleting the URI entry. The non-control process is
Forwarding the request to the server device;
Receiving a response from the server device;
And transferring the response to the client terminal.
The congestion control method according to any one of 0.

Images