CN1151635C - General dispatching system based on content adaptive for colony network service - Google Patents

Abstract

The invention is a content-based general scheduling system suitable for cluster network services. The core of the whole system is divided into two parts: one is the content-based scheduler CADS installed in the front-end machine; the other is the CANS module installed in the node machine. In the workflow and method of this system, pseudo-server technology, piggyback technology, interception and camouflage three-way handshake technology, and general scheduling technology are used. Compared with the existing scheduling system, this system has the advantages of supporting more concurrent users, improving the memory cache hit rate and improving the utilization rate of cluster storage devices, good versatility, good scalability, and high system throughput rate.

Description

A Content-Based General Scheduling System for Cluster Network Services

technical field

The invention belongs to the technical field of cluster network servers, and is a content-based general scheduling system suitable for cluster network services.

Background technique

With the rapid development of the Internet, the network has become an indispensable and effective tool for people's daily study and work. Whether it is an existing portal or an enterprise electronic trading platform built on the Web Service architecture, it is inseparable. Open powerful web server support. And the web server cluster is more and more favored by people because of its low price, good reliability, high throughput rate, abundant system resources and so on. Therefore, in order to make better use of the advantages of abundant resources and scalability of the cluster, a cluster network service scheduling system that balances request distribution becomes the key to the performance of the cluster system.

The so-called cluster network service scheduling system actually uses multiple physical servers to jointly complete service requests for users: when a client request arrives at the cluster network server, a dispatcher directs the request to a real physical server, This not only provides support for a single system image, but also enhances the scalability of the system.

In the existing cluster network service scheduling system, the dispatcher does not consider the content of the request message when forwarding the message to the back-end node machine. In this way, after a service request arrives at the dispatcher, in addition to load considerations, all The back-end node machines are treated equally, resulting in low utilization of storage devices in the cluster system, insufficient utilization of the main memory resources of the cluster system, unsatisfactory network services that require the support of content scheduling policies, and multiple copies. Aiming at the deficiencies of existing cluster network service scheduling systems, content-based scheduling systems have become a research hotspot. Existing content-based scheduling systems include ArrowPoint's web switch, Apache, Squid, and KTCPVS. The first three are implemented in user space, and the processing overhead is very large. KTCPVS is implemented in the kernel of the operating system, avoiding the overhead of switching between user space and kernel space and memory copying (see 2001 "Computer Engineering and Science" magazine, Volume 23, Issue 3). But it is based on a network address translation (NAT) structure, the schematic diagram of which is shown in Figure 1. The front-end machine forwards the request sent by the client to different node machines according to its content, and then the node machine serves the request and makes a response, and sends the response packet back to the front-end machine, and the front-end machine is responsible for returning the response packet to the client . This structure eliminates some of the weaknesses of the above-mentioned existing scheduling system (for example: the main memory resources of the cluster system are not fully utilized, the storage device utilization rate of the cluster system is not high, some network services that require the support of content scheduling policies cannot be satisfied, multiple copies ). However, in this structure, the front-end machine is not only responsible for scheduling, but also responsible for forwarding the response packet to the client, and the load of the front-end machine is very heavy. With the increasing number of node machines, the load on the front-end machine will become increasingly heavy, which will become the bottleneck of the entire cluster system, reducing the scalability of the system and the number of concurrent clients; in addition, it only supports http services and has no versatility.

Contents of the invention

The purpose of the present invention is to address the deficiencies of the existing scheduling system, and propose a content-based general scheduling system suitable for cluster network services. The system can directly send response packets to customers without going through the front-end machine, greatly reducing The load of the front-end machine has been reduced, and the number of concurrent clients has been increased; at the same time, the system supports multiple services, not just http services, and can easily support more services, which has good versatility.

A content-based general scheduling system suitable for cluster network services provided by the present invention includes a front-end machine and a subnet, and is characterized in that: the front-end machine is configured with a policy customization module, a pseudo-server and a load scheduler, and the subnet It is composed of multiple node machines configured with TCP protocol stack transformation modules and service routines, and a server pool is formed by multiple subnets;

The policy customization module is used for users to customize their policies and transmit the policies to the load scheduler; this module includes a policy definition user interface, a policy verification module, a policy library and a sending kernel module;

The policy definition user interface is used to customize the policies allowed by the cluster system, and the user

The customized strategy is handed over to the strategy verification module for unified verification;

The policy library is used to store policy rules for calling by the policy verification module;

The policy verification module matches the policy transmitted from the policy definition user interface with the policy library,

Determine whether it meets; if not, perform error handling and report the error message to the user,

Otherwise, it will be handled by the sending kernel module;

The sending kernel module passes the policy verified by the policy verification module to the load scheduler for processing through system calls;

The pseudo-server is used to perform a three-way handshake communication with the client that initiates the request, and transmits information to the load scheduler; the pseudo-server includes an initialization module, a listening port service module, a service type library, a module for saving handshake information and handshake information table;

The initialization module is used to initialize the network service linked list and take out the service type and port number to be monitored from the service type library and hand it over to the monitoring port service module to monitor the network packets sent to these ports;

The monitoring port service module receives the service type and port number transmitted from the initialization module, and monitors network packets on these ports; when the three-way handshake signal is completed, enter the save handshake signal module to save the handshake information;

The service type library is used to store the service types supported by the cluster system and the port numbers of the corresponding services, and provide them to the initialization module;

The handshake information saving module is used to save the handshake information to the handshake information table after the three-way handshake is completed;

The handshake information table is used to store the three-way handshake information, which is provided to the message piggybacking module in the load scheduler;

The load scheduler is used to dispatch the request packets sent by the client to different node machines of different subnets according to their contents; and forward the handshake information intercepted in the fake server to the node machines; the load scheduler Including message receiving module, general scheduler, event receiving module, policy library, message piggybacking module, scheduling table and forwarding module;

The message receiving module is used to receive the network packet, and judge whether the IP of the network packet is a virtual IP, if not, then hand it over to the original TCP/IP protocol stack for processing, otherwise, enter the general scheduler;

The event receiving module is used to receive policy information from the sending kernel module and store it in the policy library;

The policy library is used to save policy information for calling by the general scheduler;

The scheduling table is used to save the content of the message request and the information of the scheduled destination node machine, which is called by the general scheduler;

The general scheduler decides to dispatch to a certain node machine according to the message analysis data provided by the message receiving module, the policy library and the information in the scheduling table, and passes the decision to the message piggybacking module;

The message piggyback module takes out the message request content from the scheduling information sent by the general scheduler, and transmits it to the forwarding module together with the handshake information in the piggyback handshake information table;

The forwarding module is used to forward the packet from the message piggybacking module to the TCP protocol stack transformation module of the designated node machine through the internal high-speed network;

The TCP protocol stack modification module is used to intercept the network packet sent by the load scheduler, intercept its handshake information, restore the original message, realize the pseudo connection with the client, and send the response message to the client through the pseudo connection end.

This system comprehensively uses pseudo-server technology, piggyback technology, interception and camouflage three-way handshake technology, and general scheduling technology. It adopts a direct routing structure, that is, the node machine directly sends a response packet to the client without going through the front-end machine, which significantly reduces the front-end machine. load, increasing the number of concurrent clients. At the same time, this system supports multiple services, not just http services, and can easily support more services, which has good versatility. Compared with the existing dispatching system, the present invention has the advantages of supporting more concurrent users, improving memory cache hit rate and utilization rate of cluster storage devices, good versatility, good scalability, high system throughput rate and the like. Specifically, the present invention has the following characteristics.

1) Dynamic scalability

This system uses direct routing to forward the response packet to the client, unlike the network address translation that sends the response packet back to the front-end machine, which reduces the load on the front-end machine, improves the throughput of the entire system, adds more concurrent users, and improves Dynamic scalability of the system.

2) Support dynamic page request and static page request

This system adopts content-based hybrid scheduling to provide support for mixed requests including dynamic page requests and static page requests, and better utilize the main memory Cache of the node machine to obtain greater processing capacity.

3) Support continuous service

The system forwards the message directly to the destination node machine at the IP layer according to the connection record maintained by the machine, which ensures the integrity of the service and supports multiple services for one connection.

4) Support any TCP protocol-based service

The system adopts a general scheduler, supports various types of network services, and can easily add more service resolvers to support more types of services. This system can support any service based on TCP protocol. For different types of services, the system schedules them into different subnets, which is convenient for users to manage and expand the cluster.

Description of drawings

FIG. 1 is a schematic structural diagram of a content scheduling system based on network address translation in the prior art;

FIG. 2 is a schematic structural diagram of a content-based general scheduling system applicable to cluster network services in the present invention;

FIG. 3 is a schematic structural diagram of a strategy customization module;

FIG. 4 is a schematic structural diagram of a pseudo-server;

Fig. 5 is the structural representation of load scheduler (CADS) in the front-end machine;

Fig. 6 is a schematic structural diagram of the general scheduler in Fig. 5;

Fig. 7 is the structural representation of the TCP protocol stack transformation module (CANS) on the node machine;

Fig. 8 is a schematic diagram of the workflow of the system of the present invention.

Detailed ways

The present invention will be described in further detail below in conjunction with the accompanying drawings.

Divided from the working principle, the core of this system is divided into two parts, one is the content-based scheduler CADS installed in the front-end machine; the other is the CANS module installed in the node machine. As shown in Figure 2, the architecture of the content-based general scheduling system (hereinafter referred to as CAVS (Content Aware Virtual Server)) suitable for cluster network services is divided into two layers: the first layer is the front-end machine, which adopts the content-based scheduling system ( Hereinafter referred to as CADS (Content Aware Dispatcher System)) and pseudo-server; the second layer is the server pool, which consists of many subnets, and each subnet provides specific services such as http services, proxy services, etc. The implementation part of the content scheduling system on the node machine (hereinafter referred to as CANS (Content Aware Node server System)) is also in this layer. Each node machine in the cluster is connected through a high-speed network.

CADS is responsible for dispatching the request packets sent by customers to different node machines in different subnets according to their different contents. In this way, requests for the same content are served by the same node machine. When a new request comes, it can be assigned to the corresponding node machine according to its content, and the request content can be read directly from the cache without having to read the hard disk, making the overall system throughput higher, faster response time, and shorter delay .

CADS is also responsible for forwarding the intercepted handshake information to the node machine. The node machine performs three-way handshake camouflage according to the intercepted handshake information through CANS, indicating that the node machine has established a false connection with the client machine. CANS transmits the response information directly to the client through a pseudo-connection, without the need to return the response information through the front-end machine, which reduces the load on the front-end machine, supports more concurrent users, and reduces delays.

Under this architecture, when all server node machines are overloaded, administrators can quickly add new server node machines to process requests without copying Web documents, etc. to the local hard disk of the node machine. Dynamic scalability good.

The functions of each part are introduced as follows:

Policy customization module

This module is used for users to customize their own strategy (of course, the strategy must meet the requirements of the strategy library), and pass the strategy to the load scheduler in the kernel, and the load scheduler works according to the strategy, so as to meet the requirements of the user Effect.

As shown in Figure 3, this module defines the strategy that meets the requirements of the strategy library through the strategy definition user interface 20, and transmits the user-defined strategy to the load scheduler in the kernel by sending the kernel module 23, and hands it over to the event receiving module 4 therein deal with. Its functions and interrelationships are described as follows:

1) Policy definition user interface 20: used to customize the policies allowed by the cluster system, such as the virtual IP of the system, which services the system supports, which node machines are assigned to each service, and so on. It submits the policies customized by users to the policy verification module 21 for unified verification.

2) Policy verification module 21: Match the policy transmitted from the policy definition user interface 20 with the policy library 22, and judge whether it conforms. If not, error processing is performed, and the error information is reported to the user; otherwise, it is handed over to the sending kernel module 23 for processing.

3) Policy library 22: stores policy rules, which is convenient for the policy verification module 21 to perform matching verification on user-defined rules.

4) Sending kernel module 23: transmits the policy verified by the policy verification module 21 to the kernel through system calls, and is processed by the event receiving module 4.

fake server

The fake server is used for three-way handshake communication with the requesting client. The concept of a pseudo-server corresponds to a real network service program (such as Apache Web server).

For a real network service program, it first needs to receive the request from the client on a standard port, after completing the three-way handshake with the client, receive the client service request, and return the corresponding content to the user according to the request of the client, and then pass An improved three-way handshake negotiates with the client to end the connection. The network service program is carefully designed to serve multiple connection requests at the same time to improve service capabilities.

The concept and working principle of the pseudo server are different from the real network service program in two aspects:

(1) The function of the fake server is only to perform three-way handshake interaction with the client. Once the three-way handshake process is completed, the fake server terminates the connection.

(2) The fake server can support multiple network services at the same time. Since the fake server only listens to the port and establishes a connection, there is no need to do more processing on the request. Therefore, the pseudo-server has nothing to do with the specific service content and type, which makes the pseudo-server a general mechanism to provide services to multiple standard service ports at the same time. In this way, when the cluster server needs to provide multiple network services, there is no need to install multiple network service programs on the dispatcher.

According to the analysis of the above two points, it can be seen that the design of the pseudo-server can reduce the load of the dispatcher and the complexity of the implementation on the one hand (no need to install multiple service programs, avoiding the overhead of the service program); on the other hand, it can provide cluster servers Versatility. In this way, as long as a fake server is installed on the dispatcher, it can provide the functions of establishing a three-way handshake and obtaining handshake information for various network services.

The schematic diagram of the fake server structure is shown in Figure 4. Initialization is performed by the initialization module 11 first, and the service type and port data are taken from the service type library and passed to the monitoring port service module for monitoring. After the three-way handshake is completed, it is saved by the save handshake signal module. The handshake information is entered into the handshake information table and passed to the message piggybacking module 6 in the load scheduler. Its functions and interrelationships are described as follows:

1) Initialization module 11: used to initialize the network service linked list, and take out the service type and port number to be monitored from the service type library 13, and hand over the monitoring port service module 12 to monitor the network packets sent to these ports.

2) Listen port service module 12: accept the service type and port number transmitted from the initialization module 11, and monitor network packets at these ports. After the three-way handshake is completed, enter the save handshake signal module 14 to save the handshake information.

3) Service type library 13: used to store the service types supported by the cluster system and the port numbers of the corresponding services.

4) Save the handshake information module 14: for saving the handshake information in the handshake information table 10 after the three-way handshake is completed, so that the message piggybacking module 6 can obtain the handshake information from the handshake information table.

5) Handshake information table 10: for storing three-way handshake information such as source IP address, source port number, destination IP address, destination port number, etc. of the current IP packet.

Load Scheduler (CADS)

CADS is used to dispatch the request packet sent by the client and the intercepted handshake information to different node machines in different subnets according to the content of the request packet. Its structure is shown in FIG. 5 and FIG. 6 . The message receiving module 1 receives network packets, and filters them to obtain the required network packets, and delivers them to the general scheduler 3 . The protocol recognition module 24 in the universal dispatcher carries out protocol recognition to the incoming network packet, and calls different service routines (such as http service routine 25-1, corba service routine 25-2, proxy service routine 25-1, etc.) Routine 25-n etc.), after obtaining corresponding request content, call general scheduling system 26 and carry out unified processing; Simultaneously, event receiving module 4 receives the customized strategy from sending kernel module 23 (seeing Fig. 3) and saves in strategy storehouse 5 middle. Universal scheduler 3 decides to schedule on a certain node machine according to message analysis data, policy storehouse and scheduling table information, and passes message to the message filter module 16 of CANS through message piggyback module 6, forwarding module 9 (seeing Fig. 7 ). Its functions and interrelationships are described as follows:

1) Message receiving module 1: upon receiving a network packet, it judges whether the IP of the network packet is a virtual IP. If not, it will be handled by the original TCP/IP protocol stack; otherwise, it will enter the protocol identification module 24 in the general scheduler 3 .

2) general scheduler 3: it searches the scheduling table 7 information to judge whether the request has been scheduled, and if so, directly takes out the scheduling information from the scheduling table; As a result of the processing, scheduling information, that is, which node machine in which subnet to schedule to, can be obtained and stored in the scheduling table 7 . Send the scheduling information to the message piggybacking module 6 .

The general scheduler is the core module of this system. It handles all types of services uniformly, making the system more convenient to support more types of services. At present, the system supports http service, corba service and proxy service. If other services need to be supported, we only need to add the identification of corresponding services in the protocol identification module 24, such as the http service routine 25-1, Corba service routine 25-2 listed in the figure, until the proxy service routine 25-n . A corresponding service routine is added to process the service, and finally the general scheduling module 26 performs unified scheduling, and one type of service can be supported. Its functions and interrelationships are described as follows:

2.1) protocol recognition module 24: analyze the content of the network packet that message receiving module 1 receives, obtain the service type and the corresponding port number required by the client, judge the service required by the client, call corresponding service routine (such as http service routine 25-1, corba service routine 25-2, proxy service routine 25-n, etc.) to process.

2.2) http service routine 25-1: process http requests. It firstly analyzes the header of the http protocol to obtain the content of the service request, and sends it to the general scheduling module 26 for unified scheduling.

2.3) corba service routine 25-2: process the corba request. It first analyzes the header of the iiop protocol, obtains the content of the service request, and sends it to the general scheduling module 26 for unified scheduling.

2.4) Proxy service routine 25-n: process the proxy request. It firstly analyzes the header of the proxy protocol, obtains the content of the service request, and sends it to the general scheduling module 26 for unified scheduling.

2.5) General scheduling module 26: it processes all types of services in a unified manner, making the system more convenient to support more types of services. It schedules the content processed by the service routine through a hybrid scheduling algorithm, and after obtaining the scheduling information, sends it to the message piggybacking module 6 for processing.

3) Scheduling table 7: save the content of the message request, the information of the scheduled destination node machine such as IP address, port number, timer and other information. The timer is used to maintain whether the scheduling table is invalid.

4) Event receiving module 4: receiving the policy information from the sending kernel module 23 (see FIG. 3 ) and storing it in the policy library 5 .

5) Policy library 5: store policy information such as service type and its available node machine information.

6) Message piggybacking module 6: Take out the message request content from the scheduling information sent by the scheduling module and send it to the forwarding module 9 together with the handshake information in the handshake information table 10 .

7) Forwarding module 9: the packet sent by message piggyback module 6 is forwarded to designated node machine through internal high-speed network, and the message filter module 16 (seeing Fig. 7) of the CANS of node machine is responsible for receiving this bag.

8) Timer 8: This module regularly sends a trigger signal to the scheduling table invalidation module, so as to delete outdated scheduling information.

TCP protocol stack transformation module

This module is used to intercept the network packet sent by the front-end machine, intercept its handshake information, restore the original message (that is, the message without handshake information), realize the pseudo connection with the client, and send the response message to the client. In order to meet these requirements, it is necessary to modify the TCP protocol stack of the node machine.

As shown in Figure 7, this module receives the network packet that forwarding module 9 sends by message filtering module 16 and hand over to intercepting handshake information by message recovery module 17, recovers original message (that is, the message that does not have handshaking information), and then The camouflaged three-way handshake module camouflages according to the handshake information, modifies the original TCP protocol stack to obtain a new modified TCP protocol stack, and then sends the response message of the original message directly to the client by the sending response module 19 . Its functions and interrelationships are described as follows:

1) Message filtering module 16: receiving all network packets. If the protocol field of the packet is not CA_TCP, it indicates that the packet is not the desired packet of the system, and it is handled by the original TCP/IP protocol stack; otherwise, it indicates that the packet sent from the forwarding module 9 is received, and it is restored by the message Module 17 processing.

2) Message recovery module 17: intercept the handshake signal from the network packet, restore the original message (that is, a message without handshake information), and pass the handshake signal and the original message to the fake three-way handshake module 18.

3) camouflage three-way handshake module 18: carry out the camouflage of TCP layer according to the handshake information sent by message recovery module 17, then send the original message to upper layer network service program (such as httpserver, cache server etc.) with the TCP protocol after camouflage. The network service program serves the request and sends the response packet to the module 19 for sending the response packet.

4) Send response packet module 19: send the response packet to the client according to the disguised TCP protocol.

Fig. 8 has described the workflow of the system of the present invention:

① When CADS receives the network packet, it judges whether to visit the virtual IP. If not, it means that it is not a network packet required by the system, and the system does not do any processing and directly submits it to the original TCP/IP protocol stack for processing; otherwise, initialize the pointer of the three-way handshake information entry type.

②Start to find out whether there is handshake information. If not, the fake server intercepts the three-way handshake information and saves it in the handshake information table. If it exists, it means that the handshake information has just been established and enters the protocol identification module.

③ The protocol identification module first identifies the protocol according to the port, and enters into the corresponding protocol processing module. The protocol processing module analyzes the content of the packet to extract relevant information, and calls the general scheduling module for unified processing.

④ The general scheduling module uses a certain algorithm to decide which node machine in which subnet to dispatch to according to the information intercepted in ③. If the scheduling information already exists in the scheduling table, forward the message along with the handshake information to the scheduled node directly according to the scheduling information; otherwise, use a certain algorithm to obtain the scheduling information and save it in the scheduling table , and then forward the message along with the handshake information to the scheduled node machine according to the scheduling information.

⑤ When the node machine receives the message sent by the front-end machine, CANS takes out the handshake information, restores the original appearance of the client request message, and starts to enter the TCP/IP masquerading module to camouflage the three-way handshake signal. It is responsible for completing the function of disguising the three-way handshake to the upper service program.

⑥Finally, the network service program of the node computer completes the service request and returns the result directly to the user.

For subsequent messages of the connection, such as multiple transmissions of a service item, ending the connection with an improved three-way handshake, etc., the network dispatcher will directly forward the message to the destination node at the IP layer according to the connection record maintained by the machine machine so that the service is completed in its entirety.

The following example illustrates the configuration during the implementation of this system.

A content-based general scheduling system suitable for cluster network services is constructed on a cluster system with 16 nodes. Its basic configuration is shown in Table 1.

Table 1 Example of system configuration

CPU Memory hard drive network card operating system network Dual PIII 866 256M 30G 3C905B Linux6.2 100M switch

Among them, one is used as the front-end machine, and the remaining service node machines are divided into several subnets according to services, such as: Web service subnet and proxy service subnet. The specific implementation is as follows: node machine 1 acts as a front-end machine, and loads a pseudo server module and a front-end machine content scheduling system (CADS); node machine 2 to node machine 8 are in the Web service subnet, and node machine 9 to node machine 16 are in the proxy service subnet. In the network, each node machine is loaded with the node machine content service system (CANS) and the corresponding network service program (that is, the node machine 2 to the node machine 8 all load the http server, and the node machine 9 to the node machine 16 all load the cache server).

The configuration of the entire system is described as follows:

1) The service type library (13) has the following fields, as shown in Table 2.

Table 2 Configuration example of service type library Service type The port number HTTP 80 IIOP 1025

Claims (4)

1. A content-based general scheduling system suitable for cluster network services, comprising a front-end machine and a subnet, characterized in that: the front-end machine is configured with a policy customization module, a pseudo-server and a load scheduler, and the subnet is configured by It is composed of multiple node machines with TCP protocol stack transformation modules and service routines, and a server pool is formed by multiple subnets; Described strategy customization module is used for user to customize its strategy, and this strategy is sent to described load scheduler; This module comprises strategy definition user interface (20), strategy verification module (21), strategy storehouse (22) and sending kernel module(23); The policy definition user interface (20) is used for user-defined policies allowed by the cluster system, and the user-defined policies are handed over to the policy verification module (21) for unified verification; The policy library (22) is used to store policy rules for calling by the policy verification module (21); The policy verification module (21) matches the policy transmitted from the policy definition user interface (20) with the policy storehouse (22), and judges whether it is consistent; Hand over to send kernel module (23) to handle; Sending kernel module (23) will be passed to load scheduler to handle by the strategy of strategy verification module (21) verification by system call; The pseudo-server is used to perform a three-way handshake communication with the client that initiates the request, and transmits information to the load scheduler; the pseudo-server includes an initialization module (11), a listening port service module (12), and a service type library (13), save the handshake information module (14) and the handshake information table (10); The initialization module (11) is used to initialize the network service linked list and takes out the service type and the port number to be monitored from the service type storehouse (13) and hands over the network packets sent to these ports by the monitoring port service module (12) to monitor; The monitoring port service module (12) receives the service type and the port number transmitted from the initialization module (11), and monitors network packets at these ports; after the three-way handshake signal is completed, enter the preservation handshake signal module (14) to save the handshake information ; The service type library (13) is used to store the service types supported by the cluster system and the port number of the corresponding service, which is provided to the initialization module (11) for use; Save the handshake information module (14) for saving the handshake information in the handshake information table (10) after the three-way handshake is completed; The handshake information table (10) is used to store the three-way handshake information, which is provided to the report in the load scheduler. Text piggybacking module (6); The load scheduler is used to dispatch the request packets sent by the client to different node machines of different subnets according to their contents; and forward the handshake information intercepted in the fake server to the node machines; the load scheduler Including a message receiving module (1), a general scheduler (3), an event receiving module (4), a policy library (5), a message piggybacking module (6), a scheduling table (7) and a forwarding module (9); The message receiving module (1) is used to receive the network packet, and judges whether the IP of the network packet is a virtual IP, if not, then it is handled by the original TCP/IP protocol stack, otherwise, it enters the general scheduler (3); The event receiving module (4) is used to receive policy information from the sending kernel module (23), and store it in the policy storehouse (5); The strategy library (5) is used to store strategy information for calling by the general scheduler (3); The scheduling table (7) is used to save the message request content and the information of the scheduled destination node machine, which is called by the general scheduler (3); The general scheduler (3) decides to dispatch to a certain node machine according to the message analysis data provided by the message receiving module (1), the policy library (5) and the information in the scheduling table (7), and transmits the decision to the message piggyback module (6); The message piggyback module (6) takes out the message request content from the scheduling information sent by the general scheduler (3), and transmits the forwarding module (9) together with the handshake information in the piggyback handshake information table (10); The forwarding module (9) is used for forwarding the packet from the message piggybacking module (6) to the described TCP protocol stack transformation module of the designated node machine through the internal high-speed network; The TCP protocol stack transformation module is used to intercept the network packet sent by the load scheduler, intercept its handshake information, restore the original message, realize the pseudo connection with the client, and send the response message to the client through the pseudo connection end. 2. The general dispatching system according to claim 1, characterized in that: The general scheduler (3) includes a protocol identification module (24), multiple service routines (25-1, 25-2, ..., 25-n) and a general schedule module (26); The protocol identification module (24) is used to analyze the content of the network packet received by the message receiving module (1), obtain the service type and corresponding port number required by the customer, and judge the service required by the customer, and call the corresponding service Routine (25-1, 25-2, ..., 25-n) for processing; The general scheduling module (26) is used to uniformly process all types of services, making the system more convenient to support more types of services; it schedules the content obtained by the service routine processing through a hybrid scheduling algorithm, and after obtaining the scheduling information, sends Processed by the message piggyback module (6). 3. The general scheduling system according to claim 1, characterized in that: the load scheduler also includes a timer (8), which is used to regularly send a trigger signal to the scheduling table (7) failure module to delete outdated scheduling information. 4. The general dispatching system according to claim 1, 2 or 3, characterized in that: Described TCP protocol stack transformation module comprises message filter module (16), message recovery module (17), camouflage three-way handshake module (18) and send response packet module (19); Message filtering module (16) is used for receiving all network packets that send from forwarding module (9), if the protocol field of packet is not CA_TCP, shows that this packet is not the desired packet of this system, and is handed over to former TCP/IP protocol stack Processing; Otherwise, it shows that the packet sent from the forwarding module (9) is received, and is delivered to the message recovery module (17); The message recovery module (17) intercepts the handshake signal from the network packet, restores the original message, and passes the handshake signal and the original message to the fake three-way handshake module (18); The camouflaged three-way handshake module (18) camouflages the handshake information sent by the message recovery module (17) at the TCP layer, then sends the original message to the upper-layer network service program with the camouflaged TCP layer, and the network service program serves the request and The response packet is passed to the sending response packet module (19); The sending response packet module (19) receives the response packet sent by the fake three-way handshake module (18), and sends it to the client.

Images