KR20000000010A - Load balancer and method of content-based policy routing thereby - Google Patents

Abstract

PURPOSE: A load balancer is provided to perform content-based load balancing in connection between client and web server. CONSTITUTION: The load balancer has a client table and a web server table. Clients are registered in the client table by client information comprising internet protocol address of client, port number of client, and web server pointer, Web servers are registered in the web server table by web server information comprising internet protocol address of web server, port number of web server, and web server pointer. The load balancer determinate a client and a web server to be connected according to the client table and web server table.

Description

Load Balancer and Content-based Policy Routing Method by Load Balancer

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to the Internet in a computer network, and more particularly, to a load balancer for carrying out relaying in consideration of traffic between an arbitrary client and a specific web server in a website and its load. A method of controlling the operation of a spreader is provided.

There are numerous clients and various web servers on the Internet, and in order for them to smoothly request and provide web services, relaying considering the performance of each web server is required.

United States Patent, invented by Brendel and three others (Kring, Liu, Marino), filed on August 5, 1996, and filed on June 5, 1996, with the United States Patent Office by Resonate, Inc. No. 5,774,660 describes a world-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node. network) technology. According to US Pat. No. 5,774,660, 'resource-based load balancing' using a virtual connection means that a user's web service request is analyzed and transmitted to an appropriate web server.

On the other hand, according to the known TCP (Transport Control Protocol) connection sequence, the first SYN is a message asking whether the client is ready to establish a connection to the web server. SYN / ACK is a message asking if the web server is currently ready to make a connection and is ready to send it to the client. The ACK is a message indicating that the client is ready to send a message. PUSH is a query message containing the actual content that the client wants to receive the web service.

In order to find out the content of the web service request that the user wants in the load balancer, it has to go through several preprocessing steps as shown in the above TCP connection sequence. That is, only after going through SYN, SYN / ACK, and ACK steps, can the user actually know the desired web service request (PUSH). And resource-based load balancing requires knowing the user's service requirements to determine which web server to actually serve. Therefore, you can't go through any preprocessing steps with any web server until you decide on it. To solve this problem, a load balancer receives a connection request from a client and establishes a virtual connection. After that, when the web service request actually arrives, the web server analyzes the content and decides which web server to actually serve. )

The technique disclosed in US Pat. No. 5,774,660 is a technique in which the load balancer delays the connection with the actual web server until the user web service request is determined using the virtual connection. However, this technology supports Hypertext Transfer Protocol (HTTP) 1.0, which has technical limitations in not supporting smooth web services. In other words, almost all web servers cannot support the persistent connections currently supported to improve web service performance.

Here, persistent connection is a technology supported by HTTP 1.1 used on the worldwide web. When a user sends several web service requests to a specific web server, the connection is established and disconnected for each request. A persistent connection processes a single web service request and sets a timer for a certain amount of time. It is a method of transmitting a web service request packet by using the connection maintained until then when another request of the user arrives before the time out by continuing to maintain the connection with the user until time out. This persistent connection saves time by reducing unnecessary connection setup and termination, resulting in faster web services.

However, according to US Patent No. 5,774,660, if a web server to provide a real service is determined, a new connection is made with the web server every time. Therefore, the processing steps that formally violate the continuous connection.

However, there are many technical problems in providing resource-based load balancing in a persistent connection state. Above all, persistent connection is the key to improving overall performance by sending multiple web service requests from one user to the web server of the initially established connection.

The function is to analyze the object contained in the URL of each web service request packet, and select and send a new appropriate web server. Therefore, the existing load balancers could not properly adopt two technologies with the opposite principle of operation.

For example, in order to support resource-based load balancing in a persistent connection state, a web service request packet is unconditionally transmitted to a web server that is already connected according to the principle of the persistent connection state. If the object does not exist on the web server, there is a way to have the web server actively retrieve the object from the local network. However, this method is not true that the load balancer supports resource-based load balancing in a continuous connection, and has a serious problem of increasing the load on the local network.

Accordingly, an object of the present invention is to provide a load balancer capable of performing a resource-based load balancing function while maintaining a continuous connection between a client and a web server in a website.

Another object of the present invention is content-based policy routing (hereinafter referred to as CPR) for controlling a load balancer to perform a resource-based load balancing function while maintaining a persistent connection between a client and a web server in a website. ) To provide a method.

The present invention for achieving the above object is a load balancer for relaying traffic between a plurality of clients and a plurality of web servers in a web site, the client Internet protocol address, client port number and web server A client table for registering the clients using client information including a pointer, and the like, for registering the web servers using web server information including a web server internet protocol address, a web server port number, and a client pointer. It is provided with a web server table, it characterized in that it is determined whether the connection to any client or any web server by referring to the client information or the web server information.

The present invention for achieving the above object is a web site, the load balancer having a client table and a server table is a resource-based load balancing function between a plurality of clients and web servers continuous connection of the client and the web server In the content-based policy routing method for supporting and maintaining, a session initiation process in which an initial connection is made between any one client and the load balancer, and a virtual connection in which a virtual connection is made between the client and the load balancer after the session is started. Process, and when a predetermined web service request packet is first received from the client in the virtual connection state, the load balancer analyzes the uniform resource locator of the packet to provide the web service requested by the client according to a policy set by an operator. By deciding which web server to do After the initial transmission process of connecting with the web server and transmitting the received packet, if the predetermined web service request packet is received from the client a plurality of times in the virtual connection state, the load balancer analyzes the uniform resource locator of the packet. The policy set by the operator determines the web server to provide the web service requested by the client, and searches the web server table of the client to determine the web server that the determined web server has already serviced before and after that service until now. Checking whether the web server maintains the web server; and, if the web server maintains the current connection to the web server, reusing the connection to transmit the packet immediately, and if the web server is in service or connected for the first time. If not maintained, make a new connection and send a packet. Characterized by a made of an.

1 is a view showing a relationship between a plurality of clients and a plurality of web servers that can be connected to each other around a load balancer according to an embodiment of the present invention

2 is a diagram illustrating an example of a client table and a web server table provided in the load balancer of FIG.

3A to 3D are diagrams showing examples of load balancing according to a load balancing method.

4A to 4C are flowcharts illustrating a process of performing a CPR function by a load balancer in a continuous connection state according to an embodiment of the present invention.

5A to 5C are flowcharts illustrating an operation procedure of a load balancer according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same reference numerals have the same reference numerals as much as possible even if displayed on different drawings. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

Network Address Translation (NAT) algorithm refers to a technique for arbitrarily manipulating a source / destination address defined in the IP standard. The load balancer uses this NAT algorithm to intercept web service request packets sent by end users to the virtual IP address in the middle, and uses a distributed algorithm to translate the destination address to a specific IP address of one of the web servers actually installed. do. In other words, by applying the NAT algorithm to the load balancer, users who want web services can be provided with the desired web service without knowing the IP addresses of several real web servers.

Content-based Policy Routing (hereinafter referred to as CPR) refers to a packet that selects a specific object by analyzing a URL packet containing the contents of a web service requested by users based on a policy set by the load balancer operator. It is a technology to transmit to a specific web server.

The load balancer according to the embodiment of the present invention solves the inefficiency problem of the hard disk by using the CPR technology. Hard disk inefficiency here means that each web server must store the same service objects, which means that if you want to run multiple web servers, you need to know which web servers your packets will be sent to. It originates from what could not be.

In the persistent connection state of the load balancer according to the embodiment of the present invention, if the web server is operating to support the persistent connection function, the content-based policy routing uses the connection that maintains this packet when the user requests the web service. send. At this time, rather than sending unconditionally, it analyzes the URL contents of the web service request packet by applying CPR technology and if it needs to be sent to another web server by CPR, it keeps the existing connection to the new web server. Establish a connection and maintain a persistent connection with the new web server. After that, if the URL contents of the newly received web service request packet should be transmitted to the first web server, the packet is transmitted using the connection with the first web server that was maintained. In this way, by analyzing the URL content for each web service request packet of the user to determine the web server to provide the web service, it is possible to fully support the CPR function and maintain the connection for each web server determined by the CPR. Can be.

1 illustrates a relationship between a plurality of clients and a plurality of web servers that can be connected to each other around a load balancer according to an exemplary embodiment of the present invention. This embodiment shows a state composed of one load balancer, m clients, and n web servers. The load balancer includes a client table, a web server table, and a NAT table. M clients are registered in the client table, and as shown in the figure, n web servers are registered in the web server table because the total number of web servers to which the m clients make a connection is. The client table and the web server table are matched with each other using a pointer. Therefore, a single web server registered in the web server table can be designated by multiple clients registered in the client table.

The client information stored in the client table includes at least a client IP address, a client port number and a web server pointer. Similarly, the web server information stored in the web server table includes at least a web server IP address, a web server port number and a client pointer.

FIG. 2 illustrates an example of a client table and a web server table provided in the load balancer of FIG. 1. In the present embodiment, it is assumed that client 1 transmits packets (pkt1 to pkt3) three times, first packet 1 (pkt1) to web server 1, next packet 2 (pkt) to web server 2, and finally packet 3 (pkt3) is assumed to be transmitted to Web server 1 again. As will be described later, when the packet is first transmitted to the web server 1 and the web server 2, the connection is actually performed. However, when the packet 3 (pkt3) is transmitted to the web server 1, the connection is not required. This is because the connection made when first sending packet 1 (pkt1) to Web server 1 is maintained until then. This role is played by the content-based policy routing method according to an embodiment of the present invention.

3A to 3D are diagrams showing examples of load balancing according to a load balancing method. The illustrated text server and image server correspond to web server 1 and web server 2 of FIG. 2, respectively. 3A shows an initial setting state. 3B illustrates a case where a client requests a web service from a text server through a load balancer. At this time, the load balancer establishes a persistent connection with the text server. 3C illustrates a case where the client requests a web service from the image server through the load balancer in the state of FIG. 3B. In this case, the load balancer establishes a continuous connection with the image server while maintaining a continuous connection with the text server. FIG. 3D illustrates a case where the client requests a web service from the text server again through the load balancer in the state of FIG. 3C. In this case, the load balancer establishes a continuous connection with the image server since the load balancer may reuse the persistent connection maintained up to that time.

4A to 4C are flowcharts illustrating a process of performing a CPR function in a load balancer in a continuous connection state according to an embodiment of the present invention. As shown in FIGS. 2 and 3A to 3D, a user (client) is shown. Figure 3 illustrates the order in which three web service request packets are sent.

According to the flowchart, there are nine major processes. First, a session initiation process in which an initial connection is made between a client and a load balancer is performed. Next, a virtual access process is performed in which a virtual connection is made between the client and the load balancer. From then on, a persistent connection is maintained between the client and the load balancer. Next, a process of accessing the web server 1 through the load balancer is performed. Next, a response is transmitted from the web server 1 to the client through the load balancer, and a first session completion process is performed in which the first session is completed. Next, a process of accessing the web server 2 through the load balancer is performed. Next, a response is transmitted from the web server 2 to the client through the load balancer, and a second session completion process of completing the second session is performed. Next, when the client requests a service from the web server 1 through the load balancer again, the response is transferred from the web server 1 to the client through the load balancer without performing an access process, thereby completing the third session. 3 Session completion is performed. As shown in the figure, a process of exchanging SYN '(2), SYN' (2) / ACK '(2), and ACK' (2) between the load balancer and the web server before performing the third session completion process is performed. none.

This is because the connection is maintained between the load balancer and the web server 1 until then. Next, the load balancer receiving the finish message (hereinafter referred to as a FIN) from the web server 1 performs a process of disconnecting the continuous connection with the web server 1. At this time, the load balancer does not transmit the FIN to the client, thereby maintaining the continuous connection with the client. This is a case where timeout information is not included in the FIN. As shown, the web server drives the timer at time T6, and transmits the timeout information in the FIN after a predetermined time (for example, time T15). However, if another packet is received from the same client before the predetermined time elapses, the timer is reset at that time.

On the other hand, when the timeout information is included in the FIN delivered from the web server, the received FIN is transmitted to the client through the persistent connection that the load balancer has maintained with the client until then, and the session termination process is performed to disconnect all persistent connections. .

5A to 5C are flowcharts illustrating an operation procedure of a load balancer according to an embodiment of the present invention.

FIG. 5A illustrates a process in which the load balancer receives and analyzes the packet when the packet is sent from the outside to the load balancer.

Step 1: When sending a packet to the load balancer from outside, the load balancer checks whether the destination address of the incoming packet is a virtual IP or the source address is one of the web servers registered with the load balancer. The packet to be processed by the load balancer is a packet from one of a client and a web server registered with the load balancer. All packets coming from the client must go through a series of processing steps and the destination address must be a virtual IP and the source address of the packets coming from the web server must have one of the web servers registered in the load balancer. Therefore, if the condition is satisfied, the process proceeds to step 3, and if not, the process proceeds to step 2.

Step 2: Ignore the packets that came into the load balancer because they did not contain the proper packets.

Step 3: Verify that the source address of the incoming packet is one of the web servers registered with the load balancer. If the source address of the incoming packet is one of the web servers registered in the load balancer, the flow proceeds to step 7; otherwise, the flow proceeds to step 4 since the incoming address is from the client.

Step 4: Set the first variable FromServer to '0' to indicate that the packet is from a client.

Step 5: Verify that the client that sent the current web service request packet is registered in the load balancer's client table. If so, go to step 8; otherwise, go to step 6.

Step 6: Set the client status to '1', meaning that it received the first packet from the client, and register the client in the load balancer's client table.

Step 7: Since the web server that sent the packet is registered in the web server table of the load balancer, the first variable FromServer is set to '1' and the process proceeds to step 8.

Step 8: Check whether the value of the first variable FromServer is 1 or not. In this case, if the value of the first variable FromServer is '1', it means that the current packet comes from the web server, and so the process proceeds to step 10. Otherwise, the packet is from the client.

Step 9: Compare the client status values for that client. If the client status value is '1', the process proceeds to step 33; if '2' proceeds to step 40; if '3', then proceeds to step 43;

FIG. 5B illustrates the processing when the packet received in the load balancer is transmitted from the web server as a result of the analysis in FIG. 5A.

Step 10: Check the client status with the packet coming from the web server. If the web server sends a packet, the value must be greater than '2'. If '1', '2' proceeds to step 11. Otherwise, if the client state is '3', the process proceeds to step 12; if '4', the process proceeds to step 19.

Step 11: Since the packet is received from the web server with the client status '1' or '2', the packet is ignored.

Step 12: Check whether the content of the packet sent by the current web server is 'SYN / ACK'. If yes, go to Step 13; otherwise, go to Step 17.

Step 13: Set the current client state to '4'.

Step 14: Look up the NAT table in the load balancer for packets coming from the web server to find the IP address of the client that sent the original web service request packet.

Step 15: Create a new packet for sending an ACK to the web server, and set the IP address of the client found in step 14 to the source address to send the packet to the web server.

Step 16: Send the client's original web service request packet (PUSH) to the web server.

Step 17: The content of the packet received from the web server is not 'SYN / ACK'. In this case, because it is abnormal, the connection with the web servers connected with the client and the connection with the client are reset.

Step 18: Delete the reset client from the client table in the load balancer, and within the bounds of other connected web servers that do not affect other clients (because other clients may be connecting to that web server). Delete web servers from the web server table.

Step 19: The load balancer has received a packet from the web server and the current client state is '4'. In this step, check whether the contents of the packet currently received are 'FIN'. If it is not 'FIN', the process proceeds to step 20; otherwise, the process proceeds to step 28.

Step 20: Check whether the content of the packet received from the web server is 'ACK'. If yes, go to Step 23; otherwise, go to Step 21.

Step 21: Since the packet sent by the web server is a packet containing the response to the web service request sent by the client, the source address of the web service request packet stored in step 47 is set as the virtual IP address, and the contents of the original response packet are set. Copy to a new packet and proceed to step 22.

Step 22: Send the newly created response packet to the client that sent the web service request packet.

Step 23: The content of the packet received from the web server is 'ACK'. When the web server sends an 'ACK', the web server's connection times out and the web server sends a 'FIN', and the 'ACK / FIN' is sent to the web server after the load balancer sends it to the web server. Will send 'ACK' for 'ACK / FIN'. In this case, the load balancer checks to see if the web server that sent the 'ACK' is the last web server to maintain a connection with the client. If it was the last web server, go to step 25; otherwise, go to step 24.

Step 24: Since the web server currently sending the 'ACK' is not the last web server maintaining the connection with the client, the connection between the load balancer and the client should remain intact. Therefore, the load balancer deletes the web server from the web server table in the load balancer unless it affects other clients.

Step 25: Set the source address of the packet to the virtual IP address by referring to the NAT table in the load balancer to send the 'ACK' sent by the web server to the client.

Step 26: Send an 'ACK' received from the web server to the client.

Step 27: Since the last web server maintaining the connection with the client requested the termination of the connection, the client is deleted from the client table in the load balancer and the web server sending the 'ACK' is not affected if the other client is not affected. Delete from the table.

Step 28: Clean up all information related to the client.

Step 29: Receive 'FIN' from web server. Check that the web server that sent the 'FIN' is the last web server to keep the client connected. If it was the last web server, go to step 30; otherwise, go to step 32.

Step 30: In order to transmit the 'FIN' received from the web server to the client, set the source address of the packet to the virtual IP address by referring to the NAT table of the load balancer.

Step 31: Send 'FIN' received from the web server to the client.

Step 32 ':' FIN 'received from a web server comes from a web server other than the final web server. In this case, the source address is set as a virtual IP address to send 'ACK / FIN' to the web server.

Step 32: Send 'ACK / FIN' to the web server that sent 'FIN'.

FIG. 5C shows the processing when the packet received in the load balancer is transmitted from the client as a result of the analysis in FIG. 5A.

Step 33: The client first sends a packet to establish a connection with a load balancer. At this time, the content of the packet is 'SYN'. If 'SYN' has been entered correctly proceed to step 34, otherwise proceed to step 38.

Step 34: Since the 'ACK' is properly received from the client, a session is established for the client. At this point, the load balancer starts managing information for the client.

Step 35: Set the client status to '2'.

Step 36: Create a new packet to respond to the 'SYN' received from the client, register the information about the current client in the NAT table in the load balancer, and set the virtual IP at the source address.

Step 37: Set the contents of the new packet passed through NAT as 'SYN / ACK' in response to the 'ACK', and transmit the packet to the client. As you can see, it is the load balancer, not the actual web server, that connects with the client. This is called a virtual connection. In step 37, the virtual connection is not completed but a virtual connection is attempted.

Step 38: Since the content of the first packet received from the client is not 'ACK', an invalid packet was received. Thus, the connection with the client is reset.

Step 39: Delete information about the reset client from the client table in the load balancer.

Step 40: When the client sends an 'ACK' in response to the 'SYN / ACK' sent to the client in step 37. If the client sent 'ACK' exactly, step 41 proceeds; otherwise, step 38 goes.

Step 41: Since the client receives an 'ACK' in response to the 'SYN / ACK' sent in step 37, the virtual connection of the load balancing period is established with the client.

Step 42: Set the client state to '3' in the sense that the virtual connection is completed.

Step 43: After the client sends an 'ACK' as shown in step 38, it checks to see if it actually sent the actual web service request packet (PUSH). The client thinks that the connection is made after sending an 'ACK' and sends the desired web service request (PUSH). If the sent content matches the web service request (PUSH), the process proceeds to step 44; otherwise, the process proceeds to step 38.

Step 44: Analyzes the contents of the URL containing the web service request sent by the client and sets the rules set by the load balancer operator (e.g., referring to FIG. 3A). The image file is transmitted to the image server and the other files are transmitted to the text server. To apply the contents of the packet.

Step 45: Compare the contents of the URL analyzed in Step 44 with the rules set by the load balancer operator to determine the web server to serve the contents requested by the client.

Step 46: Check if the web server determined in step 45 is registered in the corresponding client information of the client table in the load balancer, that is, the web server information making a connection with the client. This information is registered when the web server determined by CPR is a new web server when a web service request comes from a client. If the determined web server is registered in the web server information among the client information, it means that there is already a connection between the load balancer and the determined web server. In this case, no new connection is made. If the determined web server is not in the web server information, a new connection is made. If the currently determined web server is registered, the process proceeds to step 50; otherwise, the process proceeds to step 47.

Step 47: Since the web server determined by the CPR is not in the client's web server information, register the current web server in the web server information.

Step 48: Create a new packet to establish a connection between the distributor and the new web server, set 'ACK' to its content with the source address as the client IP address and send the packet to the web server.

Step 49: Store the web service request packet sent by the client in the load balancer.

Step 50: The web server determined by the CPR is already registered in the client's web server information. This means that the connection is already established between the load balancer and the web server, so that the packet can be transmitted using the existing connection without going through the step of making a separate connection. Therefore, the destination address of the current packet is set to the determined IP address of the web server.

Step 51: Send a web service request packet (PUSH) received from the client to the determined web server.

Step 52: Set the client state to '4' indicating that the web service request packet is sent to the web server.

Step 53: Check whether the content of the information sent from the client is 'ACK / FIN'. Since the current client status is '4', the web service request packet has been sent to the web server or the client has received a response. Therefore, if the content is 'ACK / FIN', it sends 'FIN' to the client, meaning that the client does not send any more web service requests and the connection timer of the web server times out and wants to terminate. Will send 'ACK / FIN'. In this case, step 54 is reached. However, if the message sent by the client is not 'ACK / FIN', it will be a new web service request packet. In this case, step 56 is reached.

Step 54: Since the client has also agreed to the connection termination request sent by the web server, set the destination address of the packet to the IP address of the actual web server in order to send 'ACK / FIN' to the web server.

Step 55: Transmit 'ACK / FIN' received from the client to the web server.

Step 56: The client sends a new web service request packet because the content sent by the client is not 'ACK / FIN' with the client status '4'. Therefore, since only the virtual connection with the client is made, the client state is set to '3' and the process proceeds to step 43.

Incidentally, the above-described processes of FIGS. 4A to 4C are performed in the following order based on FIGS. 5A to 5C described above.

Session start process: 1 → 3 → 4 → 5 → 6 → 8 → 9 → 33 → 34 → 35.

Virtual connection process: 36 → 37 → 1 → 3 → 4 → 5 → 8 → 9 → 40 → 41 → 42.

Client and web server 1 connection process: 1 → 3 → 4 → 5 → 8 → 9 → 43 → 44 → 45 → 46 → 47 → 48 → 49 → 1 → 3 → 7 → 8 → 10 → 12 → 13 → 14 → 15 → 16.

Session 1 is completed: 1 → 3 → 7 → 8 → 10 → 19 → 20 → 21 → 22.

Client and Web Server 2 connection process: 1 → 3 → 4 → 5 → 8 → 9 → 53 → 56 → 43 → 44 → 45

→ 46 → 47 → 48 → 49 → 1 → 3 → 7 → 8 → 10 → 12 → 13 → 14 → 15 → 16.

Session 2 completed: 1 → 3 → 7 → 8 → 10 → 19 → 20 → 21 → 22.

Session 3 completed: 1 → 3 → 4 → 5 → 8 → 9 → 53 → 56 → 43 → 44 → 45 → 46 → 50 → 51 → 52 → 1 → 3 → 7 → 8 → 10 → 19 → 20 → 21 → 22.

The process by which the load balancer disconnects the persistent connection with Web Server 1: 1 → 3 → 7 → 8 → 10 → 19 → 29 → 32 → 1 → 3 → 7 → 8 → 10 → 19 → 20 → 23 → 24.

Session termination process where the load balancer receiving the end message (FIN) sent from the web server disconnects the persistent connection with the client that has been maintained until then: 1 → 3 → 7 → 8 → 10 → 19 → 29 → 30 → 31 → 1 → 3 → 4 → 5 → 8 → 9 → 53 → 54 → 55 → 1 → 3 → 7 → 8 → 10 → 19 → 20 → 23 → 25 → 26 → 27 → 28.

On the other hand, the operator can arbitrarily designate specific objects to be used for CPR and a web server to process packets containing the specific objects. In addition, you can select both the extension and directory by extending the scope of a specific object as much as possible. You can select specific objects that cannot be set in the extension or directory by setting exceptions for special cases. An AND / OR logic function may be provided for the policy to further expand the selection of the selection condition.

On the other hand, in the detailed description of the present invention has been described with respect to specific embodiments, various modifications are possible without departing from the scope of the invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, using the content-based policy routing method in the continuous connection state of the load balancer allows the operator, which is an effect that can be obtained by providing a faster web service and providing a CPR function, which is an effect obtained by supporting the persistent connection state. It is possible to establish smooth server operating rules and to simultaneously solve the problem of resource inefficiency caused by storing the same service content on multiple servers. In addition, by distributing the problem of additional expensive server due to overload of network server by spreading technology redirecting to several low-cost servers, high-quality network service like when using high-performance network server There is an effect that can provide. Another ripple technology, fault-tolerance, provides the ability to provide continuous service 24 hours a day, 365 days a year.

Claims (4)

In a load balancer that performs traffic relaying between multiple clients and multiple web servers in a website, A client table for registering the clients using client information including a client internet protocol address, a client port number and a web server pointer; A web server table for registering the web servers using web server information including a web server internet protocol address, a web server port number, a client pointer, and the like, And determining whether to connect with any client or any web server by referring to the client information or the web server information. In a web site, a load balancer with client tables and server tables is a content-based policy routing method for supporting resource-based load balancing between multiple clients and web servers while maintaining a continuous connection between the client and the web server. In While the virtual connection is established between the client and the load balancer, it analyzes the uniform resource locator of the web service request packet to find out the web server set by the operator, connects with the web server, transmits the received packet, and continues the current connection. An initial transmission process of storing the connection information in the server table in order to maintain When the predetermined web service request packet is received from the client a plurality of times in the virtual connection state, the uniform resource locator of the packet is analyzed to find a web server set by an operator, and the server table of the client is searched to find the web server. Check whether the web server has already been serviced before and remains connected to the server after the service; If the web server is a web server that maintains the connection state until now, the process of reusing the connection to send a packet immediately, If the web server is the first service or the connection state is not maintained, the method comprising the step of performing a new connection and then transmitting a packet. The method of claim 2, A session initiation process in which an initial connection is made between any one client and the load balancer, And a virtual connection process in which a virtual connection is made between the client and the load balancer after starting the session. The method of claim 2, Receiving a termination message from a web server, checking whether timeout information is included; If the timeout information is not included, responding to the server without transmitting the termination message to the client to maintain a continuous connection with the client; If the timeout information is included, transmitting the termination message to the corresponding client, and then disconnecting the continuous connection with the client.