CN118251880A - Controller for performing load balancing in the non-application layer using non-application protocols - Google Patents

Abstract

A controller (202, 304, 404) is provided for performing load balancing in a non-application layer using a non-application protocol. The load balancing includes determining to which backend server in a pool of servers (206A-206N, 306A and 306B, 406) the data packets should be sent. The controller (202, 304, 404) is configured to receive a data packet. The data packet includes one or more fields and a data payload. The data payload is encrypted and at least one of the one or more fields is unencrypted. The controller (202, 304, 404) is configured to determine an operation and/or weight of the data packet based on the unencrypted field. The controller (202, 304, 404) is configured to determine a server to which to send the data packet based on the operation and/or the weight of the data packet.

Description

Controller for performing load balancing in the non-application layer using non-application protocols

Technical Field

The present invention relates to a controller for performing load balancing in a non-application layer using a non-application protocol, and more particularly, to the controller for transmitting data packets. In addition, the present invention also relates to a method used in a controller for performing load balancing in a non-application layer using a non-application protocol.

Background technique

Modern high-traffic websites handle hundreds of thousands of client requests per second, tens of millions of concurrent requests from different clients, and return the requested text, images, videos, or application data in a fast and reliable manner. Modern computing systems often require adding more servers to achieve the above requirements. In order to scale cost-effectively while meeting these requirements, modern computing best practices often require adding more servers. Load balancers, which act as "traffic police", are placed in front of web servers and route these requests in a way that maximizes speed and capacity utilization across all servers that can satisfy client requests, and ensure that no server is overworked, which may degrade performance. If a single server fails, the load balancer redirects traffic to the remaining online servers. When a new server is added to the server group, the load balancer automatically starts sending requests to it.

In computer networks, the known communication system model includes partitions called abstraction layers. Abstraction layers, Layer 4 to Layer 7 (L4 to L7) are defined based on their functions. L4 refers to the transport layer, L5 refers to the session layer, L6 refers to the presentation layer, and L7 refers to the application layer. The transport layer is used to transfer data between points on the network. The session layer manages the connections between applications. The presentation layer provides mapping and communication for applications. The application layer interacts and communicates with end users. Load balancer refers to a load balancing technology used to distribute new connections to servers.

The load balancer uses load balancing techniques to distribute new connections to servers. The load balancer applies different types of load balancing techniques as needed. When a group of servers need to distribute requests, round-robin load balancing techniques are applied. Least connection load balancing techniques are used when new requests are sent to the server with the least number of client connections. The server with the least connections is determined by considering the relative computing power of each server. Least time load balancing techniques are used when a parameter is used to send requests to the selected server. The parameter is calculated by combining the fastest response time and the lowest active connection. Least time load balancing techniques are used exclusively with Internal Load Balancing (NGINX) plus load balancers. Hash load balancing techniques are used when requests are distributed based on a key. The key is defined using the client Internet Protocol (IP) address or the request uniform resource locator (URL). Optionally, Internal Load Balancing (NGINX) plus load balancers use hash load balancing techniques to minimize load redistribution when a group of data upstream servers changes. IP hash load balancing techniques are used when the client's IP address is used to determine which server receives a request. The random double selection load balancing technique is used by sending a request to a server randomly selected from two servers and then applying the least connection load balancing technique on the selected server. For internal load balancing (NGINX) plus load balancer, the least time load balancing technique is used.

FIG. 1A is an exemplary diagram 100A of performing load balancing at the transport layer provided by the prior art. The exemplary diagram 100A includes a client device 102, a load balancer 104, and backend servers 106A to 106N. The load balancer 104 at the transport layer performs load balancing on the source IP address and the destination IP address and port recorded in the data packet header. The IP address of the load balancer is broadcast to the client device 102 for the website or service. Therefore, the client device 102 registers the IP address of the load balancer as the destination IP address in its request. When the load balancer 104 at the transport layer receives the request and makes a load balancing decision, it performs network address translation (NAT) on the request packet to change the recorded destination IP address from the "server IP address" to the specially selected machine for this connection. Similarly, before forwarding the backend server 106A to 106N response to the client device 102, the load balancer 104 can change the source address recorded in the data packet header from the server's IP address to its own IP address. The destination and source TCP port numbers recorded in the data packet are sometimes changed in a similar manner. The load balancer 104 at the transport layer can be a hardware device running proprietary load balancing software, or a dedicated chip instead of software if NAT operation is present. The load balancer 104 effectively balances for simple packet-level load balancing. The load balancer 104 at the transport layer manages network traffic based on network information such as application ports and protocols, without considering the actual content of the data message. In addition, the content of the data message is neither inspected nor decrypted for fast, efficient and secure forwarding. Therefore, the load balancer 104 cannot route traffic based on media type, localization rules or other criteria. The load balancer 104 at the transport layer requires less computation. But the performance of the load balancer 104 at the transport layer has become negligible or irrelevant.

FIG. 1B is an exemplary diagram 100B of performing load balancing at the application layer provided by the prior art. The exemplary diagram 100B includes a client device 108, a load balancer 110, and back-end servers 112A to 112N. The load balancer 110 in the application layer performs load balancing using technologies such as the hypertext transfer protocol (HTTP) and the simple mail transfer protocol (SMTP) to provide decisions based on the actual content of each message. The load balancer 110 at the application layer terminates network traffic, performs message decryption as needed, inspects the message, makes content-based routing decisions, initiates a new transmission control protocol (TCP) connection to the appropriate upstream server, and writes the request to the server. Although the need for encryption causes performance loss to application layer processing, the performance loss can be greatly reduced by using the secure socket layer (SSL) offload function. The load balancer 110 at the application layer determines smarter load balancing decisions and content optimization. The load balancer 110 identifies unique client sessions to provide server persistence or "sticky sessions" by watching or actively injecting cookies to send all client requests to the same server for increased efficiency. Packet-level visibility allows for the use of content caching to keep frequently accessed items in memory for easy retrieval. The load balancer 110 at the application layer provides the intelligence to handle protocols that multiplex requests onto a single connection to optimize traffic and reduce overhead. The load balancer 110 at the application layer is more expensive and has the added complexity of being a termination point and establishing connections to the backend servers 112A to 112N.

Therefore, there is a need to address the above technical deficiencies in known techniques or technologies in load balancing in non-application layers.

Summary of the invention

An object of the present invention is to provide a controller for performing load balancing in a non-application layer using a non-application protocol, the controller being used to transmit data packets, and a method for use in the controller, the controller being used to perform load balancing in a non-application layer using a non-application protocol, while avoiding one or more disadvantages of the prior art methods.

The above objects are achieved by the features of the independent claims. Further implementations are apparent from the dependent claims, the description and the drawings.

The present invention provides a controller for performing load balancing in a non-application layer using a non-application protocol, the controller is used to transmit data packets, and a method used in the controller, the controller is used to perform load balancing in a non-application layer using a non-application protocol.

According to a first aspect, a controller is provided for performing load balancing in a non-application layer using a non-application protocol. The load balancing includes determining to which backend server in a pool of servers a data packet should be sent. The controller is used to receive a data packet. The data packet includes one or more fields and a data payload. The data payload is encrypted, and at least one of the one or more fields is unencrypted. The controller is used to determine an operation and/or a weight of the data packet based on the at least one unencrypted field. The controller is used to determine a server to which the data packet is to be sent based on the operation and/or weight of the data packet.

The controller reduces the cost of the load balancer and uses an L4 load balancer with high-level load balancing decoding capabilities. The controller reduces latency because no termination points need to be generated at the load balancer. The controller reduces the number of connections to a pool of servers because no proxy connections need to be terminated at the load balancer. The controller provides intelligent load balancing decisions and content optimization. The controller requires less computation. The performance of the controller at the transport layer is very efficient when the controller routes traffic based on media type, localization rules, or other criteria that know the content of the data message.

Optionally, the controller is used to determine the server to which the data packet is sent based on a current load of the server.

Optionally, the at least one field is an optional header field. Optionally, the at least one field may be a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator. The at least one field is a timestamp field.

Optionally, the controller is further used to determine the operation according to the operation indicator carried in the at least one field.

Optionally, the controller is further configured to determine the weight according to a weight indicator carried in the at least one field.

Optionally, the at least one field is a field allocated for a destination port (DST) but used to carry a weight indicator. Optionally, the weight indicator comprises a traffic indicator.

Optionally, the controller is further configured to determine the weight of the operation of the data packet according to the operation indicator in combination with the service indicator.

Optionally, the controller is further configured to determine the weight of the operation of the data packet based on a table lookup.

Optionally, the controller further comprises determining a server to which the data packet is to be sent, so that data packets of similar services are sent to the same group of servers that process such services.

Optionally, the non-application layer is a transport layer, and the protocol is a transport protocol for transmitting data.

Optionally, the non-application layer is a network layer, and the protocol is a transmission protocol for transmitting data.

Optionally, the controller is further configured to perform application layer load balancing in the non-application layer.

According to a second aspect, a controller is provided for transmitting a data packet. The data packet includes one or more fields and a data payload. The data payload is encrypted, and at least one of the one or more fields is unencrypted. The controller is configured to include an operation indicator and/or a weight indicator of the data packet in at least one unencrypted field of the data packet.

The controller provides intelligent load balancing decisions and content optimization. The controller requires less computation. The controller is very efficient at the transport layer when it routes traffic based on media type, localization rules, or other criteria that know the content of the data message.

Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator.

Optionally, the at least one field is a field allocated to indicate a port (DST PORT) but used to carry a weight indicator. Optionally, the weight indicator is a service indicator.

According to a third aspect, a device is provided, including a controller.

According to a fourth aspect, a method for use in a controller is provided for performing load balancing in a non-application layer using a non-application protocol. The load balancing includes determining to which backend server in a pool of servers a data packet should be sent. The method includes receiving a data packet. The data packet includes one or more fields and a data payload. The data payload is encrypted, and at least one of the one or more fields is unencrypted. The method includes determining an operation and/or a weight of the data packet based on the at least one unencrypted field. The method includes determining a server to which the data packet is to be sent based on the operation and/or weight of the data packet.

The method used in the controller reduces the cost of the load balancer and uses an L4 load balancer with high-level load balancing decoding capabilities. The method used in the controller reduces latency because no termination point needs to be generated on the load balancer. The method used in the controller reduces the number of connections to a pool of servers because no proxy connection needs to be terminated at the load balancer. The method used in the controller establishes different connections to backend servers. The method provides intelligent load balancing decisions and content optimization. The method used in the controller requires less computation.

Optionally, the method further comprises determining a server to which to send the data packet based on a current load of the server.

Optionally, the at least one field is an optional header field.

Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator. Optionally, the at least one field is a timestamp field.

Optionally, the method further comprises determining the operation according to the operation indicator carried in the at least one field.

Optionally, the method further comprises determining the weight according to a weight indicator carried in at least one field.

Optionally, the at least one field is a field allocated for a destination port (DST) but used to carry the weight indicator.

Optionally, the weight indicator includes a service indicator.

Optionally, the method further comprises determining a weight of the operation of the data packet according to the operation indicator in combination with the service indicator.

Optionally, the method further comprises determining the weight of the operation of the data packet based on a table lookup.

Optionally, the method further comprises determining a server to which the data packet is to be sent, so that data packets of similar services are sent to the same group of servers that handle such services.

Optionally, the non-application layer is a transport layer, and the protocol is a transport protocol for transmitting data.

Optionally, the non-application layer is a network layer, and the protocol is a transmission protocol for transmitting data.

Optionally, the method further comprises performing application layer load balancing in the non-application layer.

According to a fifth aspect, a method is provided for use in a controller for transmitting a data packet. The data packet comprises one or more fields and a data payload. The data payload is encrypted, and at least one of the one or more fields is unencrypted. The controller is configured to include an operation indicator and/or a weight indicator of the data packet in at least one unencrypted field of the data packet.

Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation of the indicator.

Optionally, the at least one field is a field allocated to indicate a port (DST PORT) but used to carry the weight indicator. The weight indicator may be a service indicator.

According to a sixth aspect, there is provided an apparatus comprising a controller, which can perform the above method when loading instructions and executing those instructions.

Therefore, unlike the prior art, the present invention provides a controller for performing load balancing in a non-application layer using a non-application protocol. The controller is used to transmit a data packet, the data packet including one or more fields and a data payload. The controller reduces the cost of the load balancer and uses an L4 load balancer with high-level load balancing decoding capabilities. The controller reduces latency because there is no need to generate a termination point on the load balancer. The controller reduces the number of connections to a pool of servers because there is no need to terminate the proxy connection at the load balancer. The controller establishes different connections with back-end servers. The controller provides intelligent load balancing decisions and content optimization. The controller requires less calculation. When the controller routes traffic based on media type, localization rules, or other criteria that know the content of the data message, the performance of the controller at the transport layer is very efficient. A network sniffer checks whether similar requests obtain the same value on the one or more fields of the data packet. The network sniffer checks whether different requests on the one or more fields of the data packet are the same.

These and other aspects of the invention will be apparent from one or more implementations described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

The various implementations of the present invention are now described by way of example only with reference to the accompanying drawings, wherein:

1A and 1B are exemplary diagrams of performing load balancing at the transport layer and the application layer provided by the prior art;

2 is a block diagram of a controller for performing load balancing in a non-application layer using a non-application protocol provided by an implementation of the present invention;

3 is an exemplary block diagram of a controller for performing load balancing to determine a server to which a data packet is to be sent according to an operation indicator and/or a weight indicator of a data packet, provided in an implementation of the present invention;

FIG4 is an exemplary block diagram of a controller for allocating a timestamp field to determine a server to which a data packet is to be sent, provided by an implementation of the present invention;

5 is a flow chart of a method for a controller to perform load balancing in a non-application layer using a non-application protocol provided by an implementation of the present invention;

6 is a diagram of a computing device (eg, a controller) used in an implementation of the present invention.

Detailed ways

An implementation of the present invention provides a controller for performing load balancing in a non-application layer using a non-application protocol, the controller being used to transmit data packets, and a method used in the controller, the controller being used to perform load balancing in a non-application layer using a non-application protocol.

In order to make it easier for those skilled in the art to understand the solutions of the present invention, the following implementations of the present invention are described in conjunction with the accompanying drawings.

The terms "first", "second", "third" and "fourth" (if any) in the specification, claims and above-mentioned drawings of the present invention are used to distinguish similar objects, and are not necessarily used to describe a specific sequence or order. It should be understood that the terms used in this way are interchangeable where appropriate, such as enabling the implementation of the present invention described herein to be implemented in a sequence other than the sequence shown or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to the steps or units explicitly listed, but may include other steps or units that are not explicitly listed or inherent to such processes, methods, products or devices.

FIG. 2 is a block diagram 200 of a controller 202 for performing load balancing in a non-application layer using a non-application protocol provided by an implementation of the present invention. The block diagram 200 includes a controller 202 and a pool of servers 204A to 204N. Load balancing includes determining which backend server in the pool of servers 204A to 204N a data packet should be sent to. The controller 202 is used to receive a data packet. The data packet includes one or more fields and a data payload. The data payload is encrypted, and at least one of the one or more fields is unencrypted. The controller 202 is used to determine an operation and/or weight of the data packet based on the at least one unencrypted field. The controller 202 is used to determine a server to which the data packet is sent based on the operation and/or weight of the data packet.

Controller 202 reduces the cost of the load balancer and uses an L4 load balancer with high-level load balancing decoding capabilities. Controller 202 reduces latency because there is no need to generate a termination point on load balancer d. Controller 202 reduces the number of connections to the pool of servers 204A to 204N because there is no need to terminate the proxy connection at the load balancer. Controller 202 establishes different connections with the backend servers. Controller 202 provides intelligent load balancing decisions and content optimization. When controller 202 routes traffic based on media type, localization rules, or other criteria that know the content of the data message, the performance of controller 202 at the transport layer is very efficient.

Optionally, the controller 202 is configured to determine a server to which to send the data packet according to a current load of the server.

Optionally, the at least one field is an optional header field. Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator. Optionally, the at least one field is a timestamp field.

Optionally, the controller 202 is further configured to determine the operation according to an operation indicator carried in the at least one field.

Optionally, the controller 202 is further configured to determine the weight according to a weight indicator carried in at least one field. Optionally, the weight indicator includes a service indicator.

Optionally, the controller 202 is further configured to determine a weight of an operation of the data packet according to the operation indicator in combination with the service indicator.

Optionally, the controller 202 is further configured to determine the weight of the operation of the data packet according to a table lookup.

Optionally, the non-application layer is a transport layer, and the protocol is a transport protocol for transmitting data.

Optionally, the non-application layer is a network layer, and the protocol is a transmission protocol for transmitting data.

Optionally, the controller 202 is further configured to perform application layer load balancing in a non-application layer.

FIG3 is an exemplary diagram 300 of a controller 304 for performing load balancing to determine a server to which a data packet is to be sent based on an operation indicator and/or a weight indicator of a data packet, provided by an implementation of the present invention. The exemplary diagram 300 includes a client device 302, a controller 304, and a pool of servers 306A, 306B. The client device 302 transmits a data packet. The controller 304 is used to receive a data packet from the client device 302. The controller 304 is used to transmit a data packet to a server. The data packet includes one or more fields and a data payload. The data payload is encrypted, and at least one of the one or more fields is unencrypted. The controller 304 is used to include an operation indicator and/or a weight indicator of the data packet in at least one unencrypted field of the data packet.

Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator. Optionally, the at least one field is a field allocated to indicate a port (DST PORT) but used to carry a weight indicator. Optionally, the weight indicator is a service indicator.

As shown in Figure 3, the Internet Protocol address (DST IP) of the client device 302 can be 44.1.1.1, the IP address of the controller 304 can be 44.2.2.2 and 44.2.2.3, and the DST IP addresses of the pool of servers 306A and 306B can be 44.3.3.3, 44.4.4.4, 44.5.5.5 and 44.6.6.6. As shown in Figure 3, a lookup table 308 including the IPs of the controller 304 that performs load balancing in the non-application layer, content type (e.g., information flow, shopping), service type (e.g., comments, images, add/delete items, checkout) and DSP ports corresponds to each DST server IP. Each DST server IP has a weight indicator and a current load, for example, DST server IP 44.3.3.3 has a weight indicator 1 and a current load A, DST server IP 44.4.4.4 has a weight indicator 3 and a current load B, DST server IP 44.5.5.5 has a weight indicator 1 and a current load C, and DST server IP 44.6.6.6 has a weight indicator 5 and a current load D.

For example, if the client device 302 sends a data packet, the controller 304 looks at the IP and DST port and knows what the operation and weight are. Since the controller 304 knows the weight of the operation, the controller 304 can direct the data packet from the operation server pool to the backend server with the least load. For example, if the client device 302 sends a data packet, the controller 304 looks at the IP and DST port corresponding to the DST server IP 44.3.3.3 and knows what the operation and weight of the DST server IP 44.3.3.3 are. Since the controller 304 knows the weight of the operation of the DST server IP 44.3.3.3, the controller 304 can direct the data packet to the server including the DST server IP 44.3.3.3.

As shown in Figure 3, controller 304 is used to receive feedback about their current state from the pool of servers 306A, 306B. Optionally, controller 304 is used to receive all calculations of the back-end server load using timestamps and capabilities. The current state can be the current load state and/or any configuration changes of the pool of servers 306A, 306B. If the current load of any server is high, controller 304 can change the server or increase another server to which the data packet is sent.

FIG. 4 is an exemplary diagram 400 of a controller 404 for allocating a timestamp field to determine a server to which a data packet is to be sent provided by an implementation of the present invention. The exemplary diagram 400 includes a pool of client devices 402, controllers 404, and servers 406. The client device 402 transmits a data packet to the controller 404. The data packet includes one or more fields and a data payload 408. Optionally, the at least one field is an optional header field. Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP), but used to carry an operation indicator. Optionally, at least one field of the data packet includes a timestamp field.

Optionally, the Internet Protocol (IP) address of the client device 402 may be 44.1.1.1, the DST IP address of the controller 404 may be 44.2.2.2, and the DST IP addresses of the pool of the server 406 may be 44.3.3.3 and 44.4.4.4.

The timestamp field and the optional header field characterize the data payload 408. As shown in FIG. 4, the characteristics of the data payload 408 may include a media access control (MAC) header, an IP header, a transport layer protocol (TCP) header, TCP option 8, a type, a length, a timestamp value, and a timestamp echo reply. The optional header field may be used to carry the information in the field. The information may be a weight indicator. Optionally, DST IP and DST jointly define a weight indicator.

The timestamp field may be used to carry other information. As shown in table lookup 410, the DST port may include a service on an application of client device 402. Each application may have one or more DST ports. Optionally, controller 404 is further used to determine the weight of the operation of the data packet according to table lookup 410.

As shown in table lookup 410, the service can be, for example, an image, a comment, etc. Optionally, the data payload is encrypted and at least one of the one or more fields is unencrypted. Optionally, information of the weight indicator is encoded into the unencrypted field of the data payload. Optionally, the application of the client device 402 inserts an encoding identifier and a content identifier of the data payload into the unencrypted field of the data payload. The controller 404 is used to decode the unencrypted field of the data payload and determine which backend server to direct the data packet to. Optionally, the controller 404 is used to add a request routing decision based on the characteristics of the data payload.

FIG5 is a flowchart 500 of a method for a controller to perform load balancing in a non-application layer using a non-application protocol provided by an implementation of the present invention. Load balancing includes determining which backend server in a pool of servers a data packet should be sent to. In step 502, a data packet is received on the controller side. The data packet includes one or more fields and a data payload. The data payload is encrypted, and at least one of the one or more fields is unencrypted. In step 504, an operation and/or weight of the data packet is determined based on at least one unencrypted field. In step 506, a server to which the data packet is sent is determined based on the operation and/or weight of the data packet.

The method used in the controller reduces the cost of the load balancer and uses an L4 load balancer with high-level load balancing decoding capabilities. The method used in the controller reduces latency because there is no need to generate termination points on the load balancer. The method used in the controller reduces the number of connections to the pool of servers because there is no need to terminate the proxy connection at the load balancer. The method used in the controller establishes different connections with the backend servers. The method provides intelligent load balancing decisions and content optimization. The method used in the controller requires less computation. When the method used in the controller routes traffic based on media type, localization rules, or other criteria that know the content of the data message, the controller is very efficient at the transport layer.

Optionally, the method further comprises determining a server to which to send the data packet based on a current load of the server.

Optionally, the at least one field is an optional header field.

Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator. Optionally, the at least one field is a timestamp field.

Optionally, the method further comprises determining the operation according to an operation indicator carried in the at least one field.

Optionally, the method further comprises determining the weight according to a weight indicator carried in at least one field.

Optionally, the at least one field is a field allocated for a destination port (DST) but used to carry a weight indicator.

Optionally, the weight indicator comprises a traffic indicator.

Optionally, the method further comprises determining a weight of the operation of the data packet according to the operation indicator in combination with the service indicator.

Optionally, the method further comprises determining a weight of an operation of the data packet based on a table lookup.

Optionally, the method further comprises determining a server to which the data packet is to be sent, so that data packets of similar services are sent to the same group of servers that handle such services.

Optionally, the non-application layer is a transport layer, and the protocol is a transport protocol for transmitting data.

Optionally, the non-application layer is a network layer, and the protocol is a transmission protocol for transmitting data.

Optionally, the method further includes performing application layer load balancing in a non-application layer.

In one implementation, a method is provided for use in a controller for transmitting a data packet. The data packet includes one or more fields and a data payload, wherein the data payload is encrypted and at least one of the one or more fields is unencrypted. The controller is configured to include an operation indicator and/or a weight indicator of the data packet in at least one unencrypted field of the data packet.

Optionally, the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator.

Optionally, the at least one field is a field allocated to indicate a port (DST PORT) but used to carry a weight indicator. The weight indicator may be a service indicator.

In one implementation, a device is provided, including a controller, which can perform the above method when loading instructions and executing those instructions.

FIG6 is a diagram of an exemplary computing device 600 (e.g., a controller) in which various architectures and functions of various previous implementations can be implemented. As shown, computing device 600 includes at least one processor 604 connected to bus 602, wherein computing device 600 can be implemented using any suitable protocol, such as the peripheral component interconnect (PCI) standard, PCI-Express, Accelerated Graphics Port (AGP), HyperTransport, or any other bus or point-to-point communication protocol. Computing device 600 also includes memory 606.

Control logic (software) and data are stored in memory 606, which may take the form of random access memory (RAM). In the present description, a single semiconductor platform may refer to a unique integrated circuit or chip based on a single semiconductor. It should be noted that the term single semiconductor platform may also refer to a multi-chip module with increased connectivity, which simulates an on-chip module with increased connectivity, which simulates on-chip operations and makes substantial improvements over traditional central processing units (CPUs) and bus implementations. Of course, the various modules may also be placed separately or in various combinations of semiconductor platforms, depending on the user's wishes.

The computing device 600 may also include an auxiliary memory 610. For example, the auxiliary memory 610 includes a hard disk drive and a removable storage drive, representing a floppy disk drive, a tape drive, a compact disk drive, a digital versatile disk (DVD) drive, a recording device, a universal serial bus (USB) flash memory. The removable storage drive reads from and/or writes to a removable storage unit in a well-known manner.

Computer programs or computer control logic algorithms may be stored in memory 606 and/or secondary storage 610. When these computer programs are executed, they enable computing device 600 to perform various functions as described above. Memory 606, secondary storage 610, and any other storage are possible examples of computer-readable media.

In one implementation, the architecture and functionality described in the various previous figures may be implemented in a processor 604, a graphics processor coupled to a communication interface 612, an integrated circuit (not shown) capable of having at least a portion of the capabilities of both the processor 604 and the graphics processor, a chipset (i.e., a group of integrated circuits designed to operate and be sold as a unit that performs related functions, etc.).

In addition, the architecture and functions described in the various previous figures can be implemented in the context of a general-purpose computer system, a circuit board system, a game console system dedicated to entertainment purposes, a dedicated system. For example, the computing device 600 can take the form of a desktop computer, a laptop computer, a server, a workstation, a game console, an embedded system.

Furthermore, the computing device 600 may take the form of various other devices, including, but not limited to, a personal digital assistant (PDA) device, a mobile telephone device, a smart phone, a television, etc. Furthermore, although not shown, the computing device 600 may be coupled to a network (e.g., a telecommunications network, a local area network (LAN), a wireless network, a wide area network (WAN), such as the Internet, a peer-to-peer network, a cable network, etc.) for communication purposes through the I/O interface 608.

It should be understood that the arrangement of components shown in the described figures is exemplary, and other arrangements may be made. It should also be understood that the various system components (and modules) defined by the claims described below and shown in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and modules) may be implemented in whole or in part by at least some of the components shown in the arrangements shown in the described figures.

Furthermore, while at least one of these components is at least partially implemented as an electronic hardware component and thus constitutes a machine, other components may be implemented in software which, when included in an execution environment, constitutes a machine, hardware, or a combination of software and hardware.

Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (40)

1. A controller (202, 304, 404), characterized in that it is used to perform load balancing in a non-application layer using a non-application protocol, wherein the load balancing includes determining to which backend server in a pool of servers (206A to 206N, 306A and 306B, 406) a data packet should be sent, and the controller (202, 304, 404) is used to: a. receiving a data packet, wherein the data packet includes one or more fields and a data payload, the data payload is encrypted and at least one of the one or more fields is unencrypted; b. Determining the operation and/or weight of the data packet based on the at least one unencrypted field; c. Determine the server to which the data packet is sent according to the operation and/or the weight of the data packet. 2. The controller (202, 304, 404) according to claim 1 is characterized in that the controller (202, 304, 404) is used to: determine the server to which the data packet is sent based on the current load of the server. 3. The controller (202, 304, 404) according to claim 1 or 2, characterized in that the at least one field is an optional header field. 4. The controller (202, 304, 404) according to claim 3, characterized in that the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator. 5. The controller (202, 304, 404) according to claim 4, characterized in that the at least one field is a timestamp field. 6. The controller (202, 304, 404) according to any one of the above claims, characterized in that the controller (202, 304, 404) is also used to determine the operation according to the operation indicator carried in the at least one field. 7. A controller (202, 304, 404) according to any one of the above claims, characterized in that the controller (202, 304, 404) is also used to determine the weight based on a weight indicator carried in the at least one field. 8. The controller (202, 304, 404) according to claim 7, characterized in that the at least one field is a field allocated for indicating a destination port (DST) but used to carry the weight indicator. 9. The controller (202, 304, 404) according to claim 7 or 8, characterized in that the weight indicator comprises a traffic indicator. 10. The controller (202, 304, 404) according to claim 9, characterized in that the controller (202, 304, 404) is also used to determine the weight of the operation of the data packet according to the operation indicator in combination with the service indicator. 11. The controller (202, 304, 404) according to any one of the above claims, characterized in that the controller (202, 304, 404) is also used to determine the weight of the operation of the data packet based on a table lookup. 12. The controller (202, 304, 404) according to claim 9, 10 or 11 is characterized in that the controller (202, 304, 404) is also used to determine the server to which the data packet is sent, so that data packets of similar services are sent to the same group of servers that handle such services. 13. The controller (202, 304, 404) according to any one of the preceding claims, characterized in that the non-application layer is a transport layer, and the protocol is a transport protocol for transmitting data. 14. The controller (202, 304, 404) according to any one of the preceding claims, characterized in that the non-application layer is a network layer, and the protocol is a transmission protocol for transmitting data. 15. The controller (202, 304, 404) according to any one of the above claims, characterized in that the controller (202, 304, 404) is also used to perform application layer load balancing in the non-application layer. 16. A controller (202, 304, 404), characterized in that it is used to transmit a data packet, the data packet includes one or more fields and a data payload, the data payload is encrypted, and at least one of the one or more fields is unencrypted, and the controller (202, 304, 404) is used to include an operation indicator and/or a weight indicator of the data packet in at least one unencrypted field of the data packet. 17. The controller (202, 304, 404) according to claim 16, characterized in that the at least one field is a field allocated for indicating an Internet Protocol address (DST IP) but for carrying an operation indicator. 18. The controller (202, 304, 404) according to claim 16 or 17, characterized in that the at least one field is a field allocated for indicating a port (DST PORT) but used to carry the weight indicator. 19. The controller (202, 304, 404) according to claim 18, characterized in that the weight indicator is a service indicator. 20. A device, characterized by comprising a controller (202, 304, 404) according to any one of claims 16 to 19. 21. A method for use in a controller (202, 304, 404), characterized in that it is used to perform load balancing in a non-application layer using a non-application protocol, wherein the load balancing includes determining to which backend server in a pool of servers (206A to 206N, 306A and 306B, 406) a data packet should be sent, the method comprising: a. receiving a data packet, wherein the data packet includes one or more fields and a data payload, the data payload is encrypted and at least one of the one or more fields is unencrypted; b. Determining the operation and/or weight of the data packet based on the at least one unencrypted field; c. Determine the server to which the data packet is sent according to the operation and/or the weight of the data packet. 22. The method according to claim 21 is characterized in that the method also includes determining the server to which the data packet is sent based on the current load of the server. 23. The method according to claim 21 or 22, characterized in that the at least one field is an optional header field. 24. The method according to claim 23, characterized in that the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry an operation indicator. 25. The method according to claim 24, characterized in that the at least one field is a timestamp field. 26. The method according to any one of the preceding claims, further comprising determining the operation according to the operation indicator carried in the at least one field. 27. The method according to any of the preceding claims, further comprising determining the weight based on a weight indicator carried in at least one field. 28. The method according to claim 27, characterized in that the at least one field is a field allocated for indicating a destination port (DST) but used to carry the weight indicator. 29. The method according to claim 27 or 28, characterized in that the weight indicator comprises a service indicator. 30. The method according to claim 29, characterized in that the method further comprises determining the weight of the operation of the data packet based on the operation indicator in combination with the service indicator. 31. The method according to any one of the above claims is characterized in that the method also includes determining the weight of the operation of the data packet based on a table lookup. 32. The method according to any one of claims 29, 30 or 31, characterized in that the method also includes determining the server to which the data packet is to be sent, so that data packets of similar services are sent to the same group of servers that handle such services. 33. The method according to any one of the preceding claims, characterized in that the non-application layer is a transport layer, and the protocol is a transport protocol for transmitting data. 34. The method according to any one of the preceding claims, characterized in that the non-application layer is a network layer and the protocol is a transport protocol for transmitting data. 35. The method according to any of the above claims, characterized in that the method also includes performing application layer load balancing in the non-application layer. 36. A method used in a controller (202, 304, 404), characterized in that it is used to transmit a data packet, the data packet includes one or more fields and a data payload, the data payload is encrypted, and at least one of the one or more fields is unencrypted, and the controller (202, 304, 404) is used to include an operation indicator and/or a weight indicator of the data packet in at least one unencrypted field of the data packet. 37. The method according to claim 36, characterized in that the at least one field is a field allocated to indicate an Internet Protocol address (DST IP) but used to carry the operation indicator. 38. The method according to claim 36 or 37, characterized in that the at least one field is a field allocated to indicate a port (DST PORT) but used to carry the weight indicator. 39. The method according to claim 38, characterized in that the weight indicator is a service indicator. 40. A device, characterized by comprising a controller (202, 304, 404), which, when loading instructions and executing these instructions, performs the method according to any one of claims 21 to 39.