JP3941763B2 - Congestion control system for client-server service - Google Patents

Description

  The present invention relates to a congestion control system for detecting and controlling a network congestion state in a client server type service using an Internet protocol typified by WEB access.

  With the recent progress of computers and the Internet, for example, client server type services via IP networks such as the Internet have become widespread, such as content distribution services. In such a client-server service, the network is congested when the number of clients accessing the server increases. In this case, for example, since it takes time to receive the content distribution, the user operating the client cannot receive a satisfactory service.

  In order to solve the problem caused by such congestion, various congestion control techniques have been proposed. For example, a technology for preventing network congestion by a congestion control device installed in an IP network such as the Internet estimating processing capacity for each server and restricting access from the client to the server based on the processing capacity Has been proposed (see Patent Document 1). In addition, a provided service control device installed in an IP network such as the Internet detects a congestion state of the network, determines an alternative service that can be provided according to a change in the congestion state, and restricts operations of the server and the client. Thus, a technique for maintaining the continuity and speed of the provided service has also been proposed (see Patent Document 2).

Japanese Patent Laying-Open No. 2003-163698 (paragraph [0015]) JP 2003-101575 A (paragraphs [0011] [0012])

However, the conventional congestion control technology has the following problems.
In the conventional congestion control technology, the server application software or the hardware or software of the IP communication device such as the above-described congestion control device or provided service control device detects the network congestion state, and in the case of the congestion state, the server hardware Exclusive control is performed so that the hardware or software does not accept a new IP packet. For this reason, the server also performs exclusive control on an IP packet transmitted from a specific client desiring to allow communication, and controls the network congestion state so that the IP packet from the specific client can be received. It was difficult.

  Further, when comparing the processing capability of the server with the IP packet transfer processing capability of the network including the IP router device, the transfer processing capability of the network is generally higher. Further, it is common to perform congestion control without being aware of the processing state of the server. For this reason, in order to realize more effective congestion control, it is necessary for the server to reflect its own processing state in the congestion control by a unique measure.

  In addition, when the congestion control is not properly performed, the client seems to take a very long time to process one transaction. For this reason, when an important task such as an order for a business model provided by a service is taken, a business opportunity may be lost.

  Conventionally, congestion tolerance can be improved by distributing communication from clients to a plurality of servers in units of transactions. In this case, it is necessary to design the server equipment in consideration of the maximum congestion state, which is disadvantageous in terms of cost.

  In addition, the IP router device on the network side monitors the access state from the client to the server at the IP packet or session level, and requests the processing to each server at the transaction level, thereby performing network load balancing processing. It was possible. However, this load balancing process is not a control that takes into account the actual load state in each server, but is merely a process according to a static algorithm.

  In addition, when a server is in a congested state, IP packets that attempt to access a network (IP router device and physical link) in the vicinity of the server are concentrated, so that it can be applied to another server or another user network under the network. There was an effect.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to control network congestion without imposing a load on the server and the client in a network that provides a client-server type service. Is to provide a simple congestion control system.

The present invention detects a server congestion state in the following two forms in a network congestion control system in which a server that is accessed from a client via an IP router device provides a client-server service using the Internet protocol. It is characterized by doing.
(1) The server detects its own congestion state, and notifies the neighboring IP router device (neighboring IP router device that houses the server) that is placed in the vicinity of the server and performs IP packet transfer processing.
(2) When the neighboring IP router device holds a congestion threshold set in advance as the number of sessions that can be simultaneously communicated, and the number of sessions during communication between the server and the client exceeds the congestion threshold, the server congestion state Is detected.

  Further, according to the present invention, when the server is in a congested state, the neighboring IP router device allows access from a client that has established communication before the server congested state is detected. It is characterized in that new access from a client trying to establish communication after being detected is rejected. In this case, the neighboring IP router device does not discard the IP packet when permitting access. Also, for example, IP packets can be selectively discarded (packet filtering) by a combination of the incoming / outgoing IP address, the protocol used, the incoming / outgoing port number, or the IP packet (message) for a specific protocol and a specific application can be selectively discarded. To deny access from clients.

  Further, according to the present invention, the neighboring IP router device notifies the congestion state of the server to another IP router device arranged in the upstream network in the client direction. Similar to the apparatus, access to the server is permitted and denied.

Further, the present invention ends the detection of the congestion state and the denial of access to the server by detecting recovery from the congestion state of the server in the following two forms.
(1) The server detects recovery from its own congestion state and notifies the neighboring IP router device of the recovery state.
(2) The restoration state of the server when the neighboring IP router device holds a restoration threshold value that is set in advance as the number of sessions that can be communicated simultaneously, and the number of sessions during communication between the server and the client falls below the restoration threshold value. Is detected.

  In addition, the present invention is characterized in that, when the server recovers from the congestion state, the neighboring IP router device cancels the new access denial from the client to the server and allows the new access to the server.

  Further, according to the present invention, the neighboring IP router device notifies the other IP router devices arranged in the upstream network in the client direction of the server recovery state, and the other IP router device communicates with the neighboring IP router described above. Similar to the apparatus, the denial of new access to the server is canceled and new access to the server is allowed.

  According to the present invention, it is possible to control network congestion without imposing a load on the server and the client. Further, network congestion due to concentration of access from the client to the server can be prevented. As a result, it is possible to provide a client server type service that a user who receives the service can satisfy.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a configuration diagram illustrating a congestion control system according to an embodiment of the present invention. The congestion control system includes clients (users) 11 to 13 that receive a client server type service, a server 41 that provides the service, an access network 21 to which the clients 11 and 12 are connected, and an access network to which the client 13 is connected. 22, an access network 23 to which the server 41 is connected, an edge router 32 that is connected to the access network 21 and accommodates the clients 11 and 12, an edge router 33 that is connected to the access network 22 and accommodates the client 13, and is connected to the access network 23. An edge router 31 that accommodates the server 41 and a core network 24 that connects the access networks 21 to 23 by the edge routers 31 to 33 are provided.

  Typically, the Internet service provider provides the client 11 to 13 with the core network 24 via the core network 24 together with the core network 24, so that the congestion control system is a server based on the network operation. The congestion control of the process 41 is executed. When the server 41 is in a congested state, access restriction information (packet filtering information) for the server 41 is not transmitted / received between the server 41 and a core router (not shown) in the core network 24, but is detailed with the server 41. Data is transmitted to and received from the edge routers 31 to 33 that can be controlled in units of flows. As a protocol between the server 41 and the edge routers 31 to 33, a protocol that is an extension of the existing iBGP (internal Border Gateway Protocol) is used.

  Next, the operation of the congestion control system will be described with reference to FIGS. The sequence diagrams shown in FIG. 2 to FIG. 5 exemplify the case of WEB access using the normal HTTP protocol. First, with reference to FIG. 1, the outline | summary of operation | movement of the congestion control system shown in FIGS. 2-5 is shown. The server 41 notifies the edge router 31 of the congestion state and the congestion recovery state. Alternatively, the server 41 notifies the edge router 31 of threshold information in order for the edge router 31 to monitor the communication state for determining the congestion state of the server 41 and the trigger for the congestion recovery state. The edge router 31 detects that the server 41 is congested or receives a notification from the server 41. Further, when the server 41 is in a congested state, the edge router 31 provides logical information for selectively discarding IP packets related to a session for which access is denied to the upstream edge router 32 in the direction of the clients 11 to 13. , 33 is notified. On the other hand, when the server 41 is in a congestion recovery state, the edge router 31 notifies the upstream edge routers 32 and 33 of logical information for canceling access denial. Further, the edge routers 31 to 33 selectively discard IP packets related to new access when the server 41 is in a congested state. The client 11 is already communicating with the server 41 when the server 41 detects a congestion state and the edge router 31 receives a notification of the congestion state from the server 41 or when the edge router 31 detects the congestion state of the server 41. In the case of, the communication is saved. The client 12 has not established communication with the server 41 when the server 41 detects the congestion state and the edge router 31 receives a notification of the server 41 congestion state, or when the edge router 31 detects the congestion state of the server 41. In this case, the intermediate edge routers 31 and 32 refuse communication. Similarly, when the server 41 detects a congestion state and the edge router 31 receives a notification of the congestion state from the server 41, or when the edge router 31 detects the congestion state of the server 41, the client 13 When communication is not established, the edge routers 31 and 32 on the way reject communication.

  FIG. 2 is a sequence diagram illustrating congestion control when the server 41 detects a congestion state. This sequence diagram realizes congestion control by selectively discarding a TCP SYN message for the server 41 in order to selectively discard an IP packet related to a new access to the server 41 when the server 41 becomes congested. It is an example. First, in order to establish a TCP session between the client 11 and the server 41, the client 11 transmits SYN (TCP) to the server 41, the server 41 transmits SYN / ACK (TCP) to the client 11, and the client 11 11 transmits ACK (TCP) to the server 41 (step S201). This is because the HTTP protocol operates on the TCP protocol of the layer 4 and therefore, it is necessary to establish a TCP connection as a previous process for starting transmission / reception of data by HTTP.

  When the TCP connection is established, communication between the client 11 and the server 41 starts (step S202). When the server 41 receives an access exceeding the processing capability from the client 11 or the like, the server 41 becomes congested and detects the congested state (step S203). The server 41 notifies the edge router 31 of the congestion state (step S204). When receiving the notification of the congestion state, the edge router 31 determines that the server 41 is in the congestion state, and sets rejection of new access to the server 41 (step S205). Therefore, when the client 12 transmits SYN (TCP) to newly access the server 41 (step S206), the edge router 31 selectively discards the message when receiving the SYC (TCP). Thereby, since the TCP session is not established between the client 12 and the server 41, the IP packet can be discarded (step S207).

  Further, the edge router 31 generates an access rejection theory for rejecting new access to the server 41, constructs an upstream network in the direction of the client 12 trying to transmit the IP packet to the server 41, and transfers the IP packet. The edge router 32 is notified of an access refusal to deny access to the server 41 because the server 41 is congested (step S208). In this case, the edge router 31 discriminates the IP address information of the server 41 in the congested state and the IP packet transmitted by the client 12 trying to newly access the server 41 in the congested state together with the notification of the access denial. Information (for example, port number, protocol type) necessary to do this is notified to the edge router 32. Upon receiving the notification of access denial, the edge router 32 determines that the server 41 is in a congestion state, and sets denial of new access to the server 41 (step S209). In this case, the edge router 32 selectively discards an IP packet including an IP address destined for the server 41 using a predetermined logical expression. Therefore, when the client 12 transmits SYN (TCP) to newly access the server 41 (step S210), the edge router 32 selectively discards the message when receiving the SYC (TCP). Thereby, since the TCP session is not established between the client 12 and the server 41, the IP packet can be discarded in the edge router 31 (step S211).

  In this case, the edge routers 31 and 32 set to deny new access to the server 41 receive the IP packet transmitted from the client 11 to the server 41 before the server 41 notifies the edge router 31 of the congestion state. Since the TCP connection between the client 11 and the server 41 is established and communicating, the IP packet is transferred without being discarded.

  When the communication between the client 11 and the server 41 is completed (step S212), the client 11 transmits FIN (TCP) to the server 41 to disconnect the TCP session, and the server 41 transmits ACK (TCP) and FIN ( TCP) is transmitted to the client 11, and the client 11 transmits ACK (TCP) to the server 41 (step S213).

  FIG. 3 is a sequence diagram for explaining the congestion control when the server 41 detects the recovery of the congestion state. As shown in FIG. 2, when the edge routers 31 and 32 recover from the congestion state by discarding new IP packets or the communication between the client 11 and the server 41 is terminated, the server 41 detects the recovery state (step S301). The server 41 notifies the restoration status to the edge router 31 (step S302). When receiving the notification of the recovery state, the edge router 31 determines that the server 41 is in the recovery state, and cancels rejection of new access to the server 41 (step S303).

  Further, the edge router 31 generates an access logic for allowing new access to the server 41, constructs an upstream network in the direction of the client 12 that tries to transmit the IP packet to the server 41, and transfers the IP packet. The router 32 is notified of access permission indicating that access to the server 41 is permitted because the server 41 is in the recovery state (step S304). In this case, the edge router 31 discriminates the IP address information of the server 41 in the recovery state and the IP packet transmitted by the client 12 trying to newly access the server 41 in the recovery state together with the notification of the access permission. Information (for example, port number, protocol type) necessary to do this is notified to the edge router 32. Upon receiving the notification of access permission, the edge router 32 determines that the server 41 is in a recovery state, cancels the rejection of new access to the server 41 (step S305), and stops discarding the new IP packet. . In this case, the edge router 32 does not selectively discard an IP packet including an IP address destined for the server 41 according to a predetermined logical expression. Therefore, when the client 12 transmits SYN (TCP) to newly access the server 41, when receiving the SYN (TCP), the edge router 32 transfers the message to the server 41 without discarding the message. Thereby, a TCP session is established between the client 12 and the server 41 (step S306), and communication is started (step S307).

  FIG. 4 is a sequence diagram illustrating congestion control when the edge router 31 detects a congestion state. This sequence diagram is an example in which the edge router 31 manages the number of TCP sessions actually established in the server 41 by monitoring TCP packets and detects a congestion state. First, the server 41 notifies the edge router 31 of threshold information on the number of sessions necessary for the edge router 31 to detect a congestion state and threshold information on the number of sessions necessary for detecting restoration of the congestion state (Step S41). S401). In this case, a maintenance person of the congestion control system may statically set these threshold values in the edge router 31. Then, the edge router 31 monitors the access state to the server 41 at the IP packet or session level, and compares the number of sessions with a threshold value for detecting the congestion state (step S402). In order to establish a TCP session between the client 11 and the server 41, the client 11 transmits SYN (TCP) to the server 41, the server 41 transmits SYN / ACK (TCP) to the client 11, and the client 11 ACK (TCP) is transmitted to the server 41 (step S403).

  When the TCP connection is established, communication between the client 11 and the server 41 starts (step S404). Then, when the number of sessions exceeds the threshold value, the edge router 31 detects a congestion state (step S405). Then, the edge router 31 determines that the server 41 is in a congested state, and sets a denial of new access to the server 41 (step S406). Therefore, when the client 12 transmits SYN (TCP) to newly access the server 41 (step S407), the edge router 31 selectively discards the message when receiving the SYC (TCP). Thereby, since the TCP session is not established between the client 12 and the server 41, the IP packet can be discarded (step S408).

  Further, the edge router 31 generates an access rejection theory for rejecting new access to the server 41, constructs an upstream network in the direction of the client 12 trying to transmit the IP packet to the server 41, and transfers the IP packet. The edge router 32 is notified of an access refusal to deny access to the server 41 because the server 41 is congested (step S409). In this case, the edge router 31 discriminates the IP address information of the server 41 in the congested state and the IP packet transmitted by the client 12 trying to newly access the server 41 in the congested state together with the notification of the access denial. Information (for example, port number, protocol type) necessary to do this is notified to the edge router 32. Upon receiving the notification of access denial, the edge router 32 determines that the server 41 is in a congestion state, and sets denial of new access to the server 41 (step S410). In this case, the edge router 32 selectively discards an IP packet including an IP address destined for the server 41 using a predetermined logical expression. Therefore, when the client 12 transmits SYN (TCP) to newly access the server 41 (step S411), the edge router 32 discards the message when receiving the SYC (TCP). Thereby, since the TCP session is not established between the client 12 and the server 41, the IP packet can be selectively discarded to the edge router 31 (step S412).

  In this case, the edge routers 31 and 32 set to deny new access to the server 41 receive the IP packet transmitted from the client 11 to the server 41 before the server 41 notifies the edge router 31 of the congestion state. Since the TCP connection between the client 11 and the server 41 is established and communicating, the IP packet is transferred without being discarded.

  When the communication between the client 11 and the server 41 is completed (step S413), the client 11 transmits FIN (TCP) to the server 41 to disconnect the TCP session, and the server 41 transmits ACK (TCP) and FIN ( TCP) is transmitted to the client 11, and the client 11 transmits ACK (TCP) to the server 41 (step S414).

  FIG. 5 is a sequence diagram for explaining the congestion control when the edge router 31 detects the recovery of the congestion state. After detecting the congestion state in step 405 shown in FIG. 4, the edge router 31 monitors the session by comparing the number of sessions with a threshold value for detecting restoration of the congestion state (step S501). As shown in FIG. 2, when the edge routers 31 and 32 discard the new IP packet or the communication between the client 11 and the server 41 is terminated, the number of sessions becomes less than the threshold value. Detects the recovery state (step S502). The edge router 31 determines that the server 41 is in a recovery state, and cancels rejection of new access to the server 41 (step S503).

  Further, the edge router 31 generates an access logic for allowing new access to the server 41, constructs an upstream network in the direction of the client 12 that tries to transmit the IP packet to the server 41, and transfers the IP packet. The router 32 is notified of access permission indicating that access to the server 41 is permitted because the server 41 is in the recovery state (step S504). In this case, the edge router 31 discriminates the IP address information of the server 41 in the recovery state and the IP packet transmitted by the client 12 trying to newly access the server 41 in the recovery state together with the notification of the access permission. Information (for example, port number, protocol type) necessary to do this is notified to the edge router 32. When receiving the notification of access permission, the edge router 32 determines that the server 41 is in the recovery state, cancels the rejection of the new access to the server 41 (step S505), and cancels the discard of the new IP packet. . In this case, the edge router 32 does not selectively discard an IP packet including an IP address destined for the server 41 according to a predetermined logical expression. Therefore, when the client 12 transmits SYN (TCP) to newly access the server 41, when receiving the SYN (TCP), the edge router 32 transfers the message to the server 41 without discarding the message. Thereby, a TCP session is established between the client 12 and the server 41 (step S506), and communication is started (step S507).

  The present invention has been described with reference to the embodiment of the present invention. However, the present invention is not limited to the above embodiment, and various modifications can be made without departing from the spirit of the present invention. . For example, the congestion control system according to the above embodiment includes three clients 11 to 13, one server 41, three edge routers 31 to 33, and three access networks 21 to 21, as shown in FIG. 23 and one core network 24, but is not limited by the number of devices such as clients, the number of networks, and the network hierarchy.

  According to the embodiment of the present invention, the edge routers 31 and 32 transfer the IP packet from the client 11 that has been established before the server 41 is congested to the server 41 without discarding it, In addition, since new IP packets from the client 12 to the server 41 are selectively discarded, it is possible to reduce the load for congestion control in the clients 11 to 13 and the server 41.

  In addition, according to the embodiment of the present invention, the edge routers 31 and 32 are configured to transfer the IP packet from the client 11 that has been established before the server 41 is congested to the server 41 without discarding it. Therefore, even if the server 41 is in a congested state, it is possible to receive the IP packet of the client 11 that wishes to permit communication, and to control the congested state appropriately. Thereby, a client server type service can be provided continuously.

  Also, according to the embodiment of the present invention, the edge routers 31 and 32 selectively discard new IP packets from the client 12 to the server 41, so that network congestion can be prevented. . In particular, since the edge router 32 arranged upstream in the direction of the client 12 and not arranged in the vicinity of the server 41 discards the new IP packet, the IP packet is transferred to the network downstream of the edge router 32. Network congestion can be further prevented. As a result, in the case where the provided service is responsible for an important task such as an order for a business model, a business opportunity is not lost. Further, it does not affect other servers and other networks due to congestion.

It is a block diagram explaining the congestion control system which concerns on embodiment of this invention. It is a sequence diagram explaining congestion control in case a server detects a congestion state. It is a sequence diagram explaining congestion control in case a server detects recovery of a congestion state. It is a sequence diagram explaining congestion control in case an edge router detects a congestion state. It is a sequence diagram explaining congestion control in case an edge router detects recovery of a congestion state.

Explanation of symbols

11-13 Client 21-23 Access network 24 Core network 31-33 Edge router 41 Server

Claims (15)

In a network congestion control system in which a server that is accessed from a client via an IP router device provides a client-server service using the Internet protocol,
A server that detects its own congestion state upon receiving an access exceeding the processing capacity from the client, a neighboring IP router device that accommodates the server, and a relay from the client to the server. With other IP router devices arranged on the upstream side,
The neighboring IP router device receives the notification of the congestion state from the server and notifies the other IP router device, and executes congestion control so that the congestion state of the server is restored ,
The other IP router device receives the notification from the neighboring IP router device and executes congestion control so that the congestion state of the server is restored . In a network congestion control system in which a server that is accessed from a client via an IP router device provides a client-server service using the Internet protocol,
The server and the neighboring IP router device that detects the congestion state of the server that accommodates the server and receives the access exceeding the processing capacity from the client, and relays the access from the client to the server. With other IP router devices arranged on the upstream side,
The neighboring IP router device monitors the access state from the client to the server, compares the number of sessions obtained by monitoring with a preset congestion threshold, and if the number of sessions exceeds the congestion threshold, The congestion state is detected, the congestion state is notified to other IP router devices, and the congestion control is executed so that the congestion state of the server is restored ,
The other IP router device receives the notification from the neighboring IP router device and executes congestion control so that the congestion state of the server is restored .   3. The congestion control system according to claim 2, wherein the congestion threshold is a value set by a maintenance person of the congestion control system or a value notified from the server.   4. The congestion control system according to claim 1, wherein the neighboring IP router device allows access from a client that has established communication before a server congestion state is detected, and A congestion control system characterized by denying access from a client attempting to establish communication after a congestion state is detected. 5. The congestion control system according to claim 1 , wherein the neighboring IP router device transmits the IP address information of the server in a congested state and a client newly trying to access the server. The other IP router device is notified of information necessary for determining the IP packet to be performed, and the other IP router device performs congestion control so that the congestion state of the server is restored upon receiving the notification. Congestion control system characterized by that. The congestion control system according to any one of claims 1 to 5 , wherein the other IP router device receives a notification from a neighboring IP router device and communicates before the server congestion state is detected. A congestion control system that allows access from an established client and rejects access from a client attempting to establish communication after a server congestion state is detected. The congestion control system according to any one of claims 1 to 6 , wherein the server detects a state recovered from a congestion state, notifies the state of recovery to the neighboring IP router device, and the neighboring IP router. A congestion control system, wherein the apparatus performs congestion control upon receiving a recovery status notification from a server. The congestion control system according to any one of claims 1 to 7, wherein the neighboring IP router device monitors an access state from a client to a server, and the number of sessions obtained by the monitoring is set in advance. A congestion control system that compares a recovery threshold and detects the recovery state of the server and executes congestion control when the number of sessions falls below the recovery threshold. 9. The congestion control system according to claim 8 , wherein the recovery threshold is a value set by a maintenance person of the congestion control system or a value notified from the server. 10. The congestion control system according to any one of claims 7 to 9 , wherein the neighboring IP router device allows access from a client attempting to establish communication with a server. . The congestion control system according to any one of claims 7 to 10 , wherein another IP router that relays access from the client to a server and is arranged upstream in the client direction as viewed from the neighboring IP router device. And the neighboring IP router device notifies the other IP router device of a server recovery state, and the other IP router device performs congestion control upon receiving the notification. Control system. 12. The congestion control system according to claim 11 , wherein the neighboring IP router device transmits the IP address information of the server in the recovery state and an IP packet transmitted by a client that newly tries to access the server in the congestion state. The congestion control system is configured to notify the other IP router device of information necessary for determining the information, and the other IP router device performs congestion control in response to the notification. The congestion control system according to claim 11 or 12, wherein the other IP router device, it receives a notification from the neighboring IP router, allowing access from the client attempt to establish a communication to the server Congestion control system characterized by The congestion control system according to claim 10 , wherein the neighboring IP router device cancels the denial of access to the server from the client and allows access from the client trying to establish communication with the server. Congestion control system. In congestion control system of claim 13 or 14, wherein the other IP router device receives the notification from neighboring IP router device, it releases the denial of access to the server from the client, establishes the communication to the server A congestion control system characterized by allowing access from a client to be attempted.

Images