Http / 2 based load balancing apparatus and method

Abstract

The application relates to an HTTP / 2-based load balancing device and method. A configuration module of the application is responsible for processing configuration data; an authentication module is responsible for receiving an HTTP / 2 request message sent by a user, then analyzing the HTTP / 2 request message, performing identity authentication, IP white list verification and permission verification in sequence to perform authentication, and forwarding the HTTP / 2 request message to a load module if the authentication result is pass, or directly constructing an HTTP / 2 response message of authentication failure to forward to the user; the load module is responsible for forwarding the HTTP / 2 request message to an upstream according to a load strategy, and forwarding an HTTP / 2 response message of the upstream to the user. The application improves the efficiency, reliability and availability of the load balancer, effectively solves the problems that the open-source load balancer cannot support HTTP / 2 message level load in the upstream and cannot automatically discover the upstream and dynamically configure the load strategy.

Description

Technical Field

[0001] This invention relates to a load balancing device and method based on HTTP / 2. Background Technology

[0002] The technical background of this invention mainly revolves around the limitations of open-source load balancers. Currently, while open-source load balancers such as Nginx support dynamic configuration updates, they do not support automatic upstream discovery. This requires operations and maintenance personnel to manually modify and reload the configuration, increasing workload and increasing the possibility of errors. Furthermore, existing open-source load balancers also have limitations in supporting upstream HTTP / 2, making packet-level load balancing impossible. Additionally, existing load balancer strategies only support proportional horizontal load balancing, not vertical load balancing across devices. Summary of the Invention

[0003] In view of the problems existing in the prior art, the purpose of this invention is to provide a technical solution for a load balancing device and method based on HTTP / 2, aiming to build a technical solution that can automatically discover HTTP / 2 upstreams and perform load balancing, so as to realize HTTP / 2 load balancing and provide authentication capabilities to the outside world.

[0004] The HTTP / 2-based load balancing device is characterized by comprising:

[0005] Configuration module: Responsible for processing configuration data;

[0006] The authentication module is responsible for receiving HTTP / 2 request messages sent by users, parsing the HTTP / 2 request messages, and performing authentication, IP whitelist verification, and permission verification in sequence. If the authentication result is successful, the HTTP / 2 request message is forwarded to the load balancer module; otherwise, an HTTP / 2 response message indicating authentication failure is directly constructed and forwarded to the user.

[0007] Load Module: Responsible for forwarding the HTTP / 2 request messages to the upstream according to the load balancing policy, and forwarding the upstream HTTP / 2 response messages to the user.

[0008] The HTTP / 2-based load balancing method is characterized by the following steps:

[0009] Step S101: The configuration module processes the configuration data;

[0010] Step S102: The authentication module receives an HTTP / 2 request message sent by the user;

[0011] Step S103: The authentication module parses the HTTP / 2 request message and performs authentication in sequence, including identity authentication, IP whitelist verification, and permission verification.

[0012] In step S104, the load balancing module forwards the HTTP / 2 request message to the upstream according to the load balancing policy, and forwards the upstream HTTP / 2 response message to the user.

[0013] The HTTP / 2-based load balancing method is characterized in that the configuration data processing in step S101 is implemented in the configuration module, which periodically obtains the configuration in the configuration file and discovers upstream services from the registry center in near real-time and obtains the upstream information of all upstream services in real time. After processing, the authentication policy, routing policy, load policy, and HTTP / 2 connection pool are generated and stored in the memory of this device.

[0014] The HTTP / 2-based load balancing method is characterized in that the authentication policy is responsible for configuring the authentication policy when a user accesses the service, and the user's authentication is associated with the upstream service and obtained according to the configuration file; the routing policy is responsible for configuring the routing information, and supports using regular expressions to match the URI to specify a specific upstream service, which is obtained according to the configuration file.

[0015] The load policy is responsible for configuring the load policy, which is obtained by processing all upstream information obtained from the registry center;

[0016] The HTTP / 2 connection pool is responsible for the management of the HTTP / 2 connection pool, and is created after obtaining all upstream information from the registration center;

[0017] The term "upstream service" refers to the code name of multiple upstream sets with the same function. Upstreams with the same upstream service name perform the same function, and sending to any of them can result in the same processing.

[0018] The HTTP / 2-based load balancing method is characterized by the following implementation process for step S101:

[0019] Step S1011, configuration file parsing;

[0020] Configuration file parsing retrieves the configuration from the configuration file every 5 seconds, and generates cost configuration, authentication policy and routing policy after parsing. The configuration file is in YAML format.

[0021] Step S1012: The authentication policy and routing policy are saved to memory;

[0022] The authentication strategy is obtained by processing authentications.users in the configuration file and stored in memory as a HashMap, where the key of the HashMap is appkey and the value is a structure.

[0023] The routing strategy is obtained by processing the routes in the configuration file and stored in memory as a List. The value is a structure, and the order of the List is consistent with the order of the Routes in the routes in the configuration file.

[0024] Step S1013: The upstream registers with the registration center;

[0025] Upstream companies need to register their relevant information with the registration center;

[0026] Step S1014: Upon initial startup, obtain upstream information for all upstream services and subscribe to all upstream services;

[0027] Upstream information is the metadata that the upstream registers with the registry center, including the upstream service name, upstream IP, upstream port, upstream status, load level, and load weight.

[0028] Step S1015: Start the scheduled task to subscribe to all upstream services from the registry center every 5 seconds;

[0029] Upstream services in the registration center need to actively register and query. The list of all upstream services cannot be obtained through subscription. However, upstream information of upstream services can be obtained by subscribing to upstream services. When the upstream information of an upstream service changes, the registration center will notify this device.

[0030] Step S1016: Create an HTTP / 2 connection based on the upstream information;

[0031] All upstream information obtained in step S1015 needs to be traversed. If the status of the upstream information is 0, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is not 0, no connection is created.

[0032] If the upstream information obtained after step S1018 is newly added, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is 0, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is not 0, no connection is created. If the upstream information is deleted, no connection is created.

[0033] An HTTP / 2 connection object refers to the object in the code representing an HTTP / 2 session created using an IP address and port.

[0034] Step S1017: The load balancing strategy and the HTTP / 2 connection pool are saved to memory;

[0035] The load balancing strategy is obtained by processing all upstream information and stored in memory as a HashMap. The key of the HashMap is serviceName, and the value is a List. The value of the List is a random allocation class obtained by processing all currently available upstream information with the same serviceName and the same level. The order of the List is sorted in ascending order of level under the same serviceName.

[0036] The HTTP / 2 connection pool is obtained by processing all HTTP / 2 connection objects obtained in step S1016. It is stored in memory as a HashMap, where the key of the HashMap is a string concatenated with the IP address of the HTTP / 2 connection object plus a colon and the port number of the HTTP / 2 connection object, and the value is the HTTP / 2 connection object.

[0037] If the upstream information obtained after step S1018 is to delete upstream information or update upstream information and the status of the upstream information is non-zero, then the data in the HTTP / 2 connection pool's in-memory HashMap that uses the string concatenated with the upstream IP address plus a colon plus the upstream port address as the key needs to be deleted.

[0038] Step S1018: When the upstream service changes, the registration center pushes the upstream information to this device;

[0039] After steps S1014 and S1015, the registration center will notify this device when the upstream information of the subscribed upstream service changes.

[0040] Upstream information changes in upstream services refer to the addition, deletion, or updating of upstream services.

[0041] The HTTP / 2-based load balancing method is characterized in that, in step S103, the authentication module parses the HTTP / 2 request message, performs identity authentication, IP whitelist verification, and permission verification in sequence for authentication. If the execution result is successful, the HTTP / 2 request message is forwarded to the load module, and the subsequent HTTP / 2 response message from the load module is forwarded to the user. Otherwise, an HTTP / 2 response message indicating authentication failure is directly constructed and forwarded to the user.

[0042] The HTTP / 2-based load balancing method is characterized by the following implementation process for step S103:

[0043] Step S1031: Parse the HTTP / 2 request message received from the user authentication module;

[0044] Step S1032: Determine whether the current device has enabled authentication. If not, proceed to step S10312; otherwise, proceed to step S1033.

[0045] Step S1033: Perform identity authentication, i.e., request identity authentication;

[0046] The authentication supports HTTP Basic authentication. Once authentication is successful, access is granted. HTTP Basic authentication first decrypts the value of the Authorization header field of the HTTP request message using the HTTP Basic authentication decryption method to obtain the username and password. The username is the appkey in the authentication policy, and the password is the appsecret in the authentication policy. Then, the corresponding structure is retrieved from the HashMap in memory based on the appkey. If the appsecret in the structure matches the decrypted password, the authentication is considered successful; otherwise, it fails. An HTTP / 2 response message is constructed with an HTTP / 2 status code of 401 and forwarded to the user.

[0047] Step S1034: Determine whether the identity authentication request is successful. If not, proceed to step S10311; if yes, proceed to step S1035.

[0048] Step S1035: Perform whitelist verification, i.e., IP whitelist verification;

[0049] The IP whitelist verification obtains the IP address from the HOST header field in the HTTP request message, retrieves the structure of the appkey corresponding to the authentication policy based on the identity authentication, and obtains the IP whitelist ipWhitelists from the structure. Considering efficiency issues, the IP whitelist only supports the full IP address and does not support placeholders. The IP address obtained from the HOST header field is compared with ipWhitelists by string comparison. If the IP address obtained from the HOST header field is in ipWhitelists, the request is allowed; otherwise, it is blocked. An HTTP / 2 response message is constructed with an HTTP / 2 response status code of 401 and forwarded to the user. Step S1036: Check if the whitelist verification passes. If not, proceed to step S10311; if yes, proceed to step S1037.

[0050] Step S1037: Obtain the route based on the URI;

[0051] The process of obtaining the route based on the URI involves retrieving the URI from the HTTP request message, traversing the List of routing policies in memory, retrieving the URI matching regular expression uriExpression from the structure, and using the URI matching regular expression to match the URI obtained from the HTTP request message. If a match is found, the matching ends and the route is obtained, allowing the request to proceed. If no match is found, the matching continues in a loop. If no match is found, the request is considered not to have matched and no route has been obtained, and the request is blocked. An HTTP / 2 response message with an HTTP / 2 status code of 404 is constructed and forwarded to the user.

[0052] Step S1038: Obtain the route. If not, proceed to step S10311; if yes, proceed to step S1039. Step S1039: Obtain the upstream service in the route.

[0053] Obtain the upstream service name serviceName from the route structure obtained in step S1037. Obtain the structure of the appkey corresponding to the authentication policy according to the identity authentication in step S1033. Obtain the upstream service name array serviceNames from the structure and traverse it to obtain the authorized upstream service name. If it is consistent with the upstream service name obtained by traversing the List of route policies in memory, the traversal ends and the process is allowed. If there is no inconsistency, the traversal continues. If they are all inconsistent, the process is intercepted, an HTTP / 2 response message is constructed with an HTTP / 2 response status code of 403, and forwarded to the user.

[0054] Step S10310: Is the upstream service in the authentication application's upstream service list? If not, proceed to step S10311; if yes, proceed to step S10312.

[0055] Step S10311: After interception, directly forward the HTTP / 2 response message that failed to construct authentication to the user;

[0056] Step S10312: After allowing access, forward the HTTP / 2 request message to the load balancing module;

[0057] Step S10313: Forward the HTTP / 2 response message from the load balancer module to the user.

[0058] The HTTP / 2-based load balancing method is characterized by the following implementation process for step S104:

[0059] Step S1041: Receive the HTTP / 2 request message from the authentication module;

[0060] Step S1042: Obtain the upstream service name;

[0061] Based on the URI obtained from the HTTP / 2 request message in step S1041, the List of routing policies in memory is traversed, and the URI matching regular expression in the structure is retrieved. The URI matching regular expression is used to match the URI obtained from the HTTP request message. If a match is found, the matching ends and the upstream service name in the routing structure is obtained. If no match is found, the matching continues in a loop. If no match is found, it is considered that the upstream service name has not been obtained, an HTTP / 2 response message is constructed with an HTTP / 2 response status code of 404, and forwarded to the authentication module.

[0062] Step S1043: Has the upstream service been obtained? If not, proceed to step S1048; if yes, proceed to step S1044.

[0063] Step S1044: Obtain the random allocation class;

[0064] Based on the upstream service name obtained in step S1042, the random allocation class with index 0 is obtained from the HashMap List of the load balancing strategy in memory;

[0065] Step S1045: Randomly obtain the upstream source;

[0066] Based on the random allocation class obtained in step S1044, the random method is called to obtain the structure, which is the upstream information;

[0067] Step S1046: Obtain the HTTP / 2 connection object from the upstream source;

[0068] Based on the upstream information obtained in step S1045, the upstream IP address and port are obtained, and the HTTP / 2 connection object is retrieved from the HashMap in memory from the HTTP / 2 connection pool.

[0069] Step S1047: Forward the HTTP / 2 request message to the corresponding upstream;

[0070] According to step S1046, obtain the HTTP / 2 connection object and forward the HTTP / 2 request message;

[0071] Step S1048: Receive the HTTP / 2 response message from the upstream and forward it to the authentication module.

[0072] The HTTP / 2-based load balancing method is characterized in that all currently available upstream information refers to upstream information with a status of 0. A batch of objects and their weights are initialized by random allocation class input. The random method of random allocation class is called to output objects randomly selected according to their selection probability. The selection probability of each object is calculated by dividing the object's weight by the sum of the weights of all objects. An object is a structure in the load balancing strategy.

[0073] The HTTP / 2-based load balancing method is characterized by using an HTTP Basic authentication decryption method that decrypts Basic authentication. The value of the Authorization header field in the HTTP request message begins with "Basic". The username and password are separated by colons and then Base64 encoded. The specific format is Authorization: Basic{Base64 encoded username and password}. Therefore, the decoding method involves Base64 decoding the Base64 encoded username and password, and then separating the strings according to the colons. The first group is the username, and the second group is the password.

[0074] This invention achieves automatic upstream discovery and configuration by connecting to a registry center, significantly improving operational efficiency and reliability. Whenever the registry center detects changes upstream, this invention can immediately detect and update its policies. Furthermore, this invention natively supports HTTP / 2 upstream performance and supports load balancing at the HTTP / 2 packet level, avoiding issues such as uneven load distribution that can occur with connection-level load balancing. Finally, this invention also supports vertical device policies, allowing lower-performance backup servers to take over when a high-performance server completely fails, thereby ensuring a higher degree of service availability.

[0075] In summary, this invention addresses the limitations of open-source load balancers by innovating in areas such as integration with registry centers, support for HTTP / 2 message-level load balancing, and vertical device policies. This improves the efficiency, reliability, and availability of load balancers, effectively resolving the issues of open-source load balancers not supporting HTTP / 2 message-level load balancing upstream and the inability to automatically discover upstream components and dynamically configure load policies. This significantly enhances the quality and efficiency of network services. Attached Figure Description

[0076] Figure 1 This is a diagram of the device architecture of the present invention;

[0077] Figure 2 This is a diagram illustrating the load patterns.

[0078] Figure 3 Here is a flowchart of the HTTP / 2 load balancing method;

[0079] Figure 4 Flowchart for configuring the module;

[0080] Figure 5 Authentication flowchart;

[0081] Figure 6 For the load flow diagram;

[0082] Figure 7 This diagram illustrates the differences between the present invention and open-source load balancers. Detailed Implementation

[0083] The present invention will be further described below with reference to the accompanying drawings:

[0084] The present invention provides a load balancing device and method based on HTTP / 2, which mainly aims to solve the problems of existing load balancers not supporting HTTP / 2 upstreams, or supporting HTTP / 2 upstreams but not supporting HTTP / 2 packet-level load balancing, and the inability to automatically discover upstreams and dynamically configure load strategies.

[0085] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0086] Example 1

[0087] Figure 3 The diagram shown is a flowchart of an HTTP / 2 load balancing method provided in Embodiment 1 of the present invention.

[0088] Step S101, independent of the HTTP / 2 request load balancing process, mainly functions to convert the configuration file and upstream information into the data required for the execution of steps S102, S103, and S104.

[0089] The HTTP / 2 request load balancing process refers to the following steps: S102: The authentication module receives the HTTP / 2 request message sent by the user; S103: The authentication module parses the HTTP / 2 request message and performs authentication in sequence by performing identity authentication, IP whitelist verification, and permission verification; S104: The load balancing module forwards the HTTP / 2 request message to the upstream according to the load balancing policy and forwards the upstream HTTP / 2 response message to the user.

[0090] The HTTP / 2 request load balancing process differs from traditional open-source load balancers that handle connection-level load balancing. In this approach, the user creates a connection to an upstream server through the load balancer. While simple and straightforward, this can lead to uneven upstream connections. For example, if there are three upstream servers but only one user, creating a connection only for the user means only one upstream server will receive the message, failing to distribute the user's requests evenly across all three. This embodiment uses message-level load balancing. The user establishes a connection with the device, the device establishes a connection with an upstream server, and after receiving the user's HTTP / 2 request message, the device randomly selects an upstream server for forwarding. Figure 7 .

[0091] Step S101: The configuration module processes the configuration data.

[0092] In this embodiment, the configuration data processing is implemented by the configuration module, which periodically obtains the configuration in the configuration file and discovers upstream services from the registry center in near real-time and obtains the upstream information of all upstream services in real time. After processing, it generates authentication policies, routing policies, load balancing policies, and HTTP / 2 connection pools, and then stores them in the memory of this device.

[0093] The authentication strategy, routing strategy, load balancing strategy, and HTTP / 2 connection pool data are derived from configuration files and upstream information, respectively. The specific relationships are shown in Table 1.

[0094] data source Authentication strategy configuration file Routing policy configuration file Load balancing strategy Registration Center HTTP / 2 connection pool Created based on upstream information obtained from the registry center

[0095] Table 1. Relationship between data and sources

[0096] The authentication policy is responsible for configuring the authentication policy when a user accesses the service. The user's authentication is associated with the upstream service and is obtained according to the configuration file.

[0097] The routing policy is responsible for configuring routing information, and supports using regular expressions to match URIs to specify specific upstream services, which are obtained by processing the configuration file.

[0098] The load balancing strategy is responsible for configuring the load balancing strategy, which is obtained by processing all upstream information obtained from the registry center.

[0099] The HTTP / 2 connection pool is responsible for the management of the HTTP / 2 connection pool, and is created after obtaining all upstream information from the registration center;

[0100] An upstream service refers to the code name of a set of multiple upstream services with the same function. Upstream services with the same name perform the same function, and sending to any of them can result in the same processing.

[0101] The specific implementation process of step S101 is as follows: Figure 4 Steps S1011, S1012, S1013 and S1014 are four processes that can be performed simultaneously, and there is no order between them.

[0102] Step S1011: Configuration file parsing;

[0103] The configuration file parsing process retrieves the configuration from the configuration file every 5 seconds, and then generates cost configuration, authentication policy, and routing policy. The configuration file is in YAML format.

[0104] The configuration file example is as follows:

[0105]

[0106] The definitions of each field in the configuration file are shown in Table 1.

[0107]

[0108]

[0109] Table 2 Configuration File Fields Table

[0110]

[0111] Table 3 Authentication Strategy Fields

[0112] Fields type illustrate serviceName string Upstream service name uriExpression string Uri matches regular expressions

[0113] Table 4 Routing Policy Fields Table

[0114] Step S1012: Save the authentication policy and routing policy to memory;

[0115] The authentication strategy is obtained by processing the `authentications.users` file in the configuration file; relevant fields are shown in Table 3. It is stored in memory as a HashMap, where the key is `appkey` and the value is a structure; the structure field definitions are shown in Table 3. An example of the JSON format is as follows:

[0116]

[0117]

[0118] The routing strategy is obtained by processing the routes in the configuration file; relevant fields are shown in Table 4. It is stored in memory as a List, with each value being a struct. The order of the List matches the order of the Routes in the configuration file; struct field definitions are shown in Table 4. An example of the JSON format is shown below:

[0119]

[0120] Step S1013: Register upstream with the registration center;

[0121] The upstream needs to register its own relevant information with the registration center. This step is not directly related to the device of the present invention, and the upstream needs to implement the current method of the present invention.

[0122] Step S1014: Upon initial startup, obtain upstream information for all upstream services and subscribe to all upstream services;

[0123] Upstream information is the metadata that the upstream registers with the registry center, including the upstream service name, upstream IP, upstream port, upstream status, load level, and load weight, as detailed in Table 5.

[0124]

[0125]

[0126] Table 5. Metadata Structure Table Carried During Upstream Registration

[0127] Step S1015 starts a scheduled task, which subscribes to all upstream services from the registry center every 5 seconds;

[0128] Upstream services in the registry center need to actively register and query; a complete list of upstream services cannot be obtained through subscription. However, upstream information of upstream services can be obtained by subscribing to upstream services, and the registry center will notify this device when the upstream information of an upstream service changes.

[0129] Step S1016: Create an HTTP / 2 connection based on the upstream information.

[0130] All upstream information obtained in step S1015 needs to be traversed. If the status of the upstream information is 0, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is not 0, no connection is created.

[0131] If the upstream information obtained after step S1018 is newly added, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is 0, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is non-zero, no connection is created. If the upstream information is deleted, no connection is created.

[0132] An HTTP / 2 connection object refers to the object in the code that represents an HTTP / 2 session created using an IP address and port.

[0133] Step S1017: Save the load balancing strategy and HTTP / 2 connection pool to memory;

[0134] The load balancing strategy is obtained by processing all upstream information. It is stored in memory as a HashMap, where the key is `serviceName` and the values ​​are a List. Each List contains a randomized allocation of all currently available upstream services with the same `serviceName` and level. The List is sorted in ascending order of level for the same `serviceName`.

[0135] All currently available upstream information refers to upstream information with a status of 0.

[0136] The random allocation class takes a batch of objects as input and initializes their weights. It then calls the random method of this class to output objects randomly selected based on their selection probabilities. The selection probability of each object is calculated by dividing the object's weight by the sum of the weights of all objects.

[0137] The object in the load balancing strategy is a structure, and the structure field definitions are shown in Table 5.

[0138] The HTTP / 2 connection pool is obtained by processing all HTTP / 2 connection objects as described in step S1016. It is stored in memory as a HashMap, where the key is a string concatenated with the IP address, colon, and port number of the HTTP / 2 connection object, and the value is the HTTP / 2 connection object itself.

[0139] If the upstream information obtained after step S1018 is either to delete upstream information or to update upstream information and the status of the upstream information is non-zero, then the data in the HTTP / 2 connection pool's in-memory HashMap that uses the string concatenated with the upstream IP address plus a colon plus the upstream port address as the key needs to be deleted.

[0140] When the upstream service changes in step S1018, the registration center pushes the upstream information to this device.

[0141] After steps S1014 and S1015, the registration center will notify this device when there are changes in the upstream information of the subscribed upstream services.

[0142] Upstream information changes in upstream services refer to the addition, deletion, or updating of upstream services.

[0143] In step S102, the authentication module receives the HTTP / 2 request message sent by the user.

[0144] In step S103, the authentication module parses the HTTP / 2 request message and performs authentication in sequence, including identity authentication, IP whitelist verification, and permission verification.

[0145] The authentication module parses the HTTP / 2 request message and performs authentication in sequence: identity authentication, IP whitelist verification, and permission verification. If the result is successful, the HTTP / 2 request message is forwarded to the load balancer module, and the subsequent HTTP / 2 response message from the load balancer module is forwarded to the user. Otherwise, an HTTP / 2 response message indicating authentication failure is constructed and forwarded to the user.

[0146] Step S103, the authentication module performs identity authentication, IP whitelist verification, and permission verification. The specific implementation process is as follows: Figure 5For identity authentication, refer to steps S1033 to S1034; for IP whitelist verification, refer to steps S1035 to S1036; and for permission verification, refer to steps S1037 to S10310.

[0147] Step S1031: Parse the HTTP / 2 request message received from the user authentication module.

[0148] Step S1032: Determine whether the current device has enabled authentication. If not, proceed to step S10312; otherwise, proceed to step S1033.

[0149] Step S10312: After allowing access, forward the HTTP / 2 request message to the load balancing module.

[0150] Step S10313: Forward the HTTP / 2 response message from the load balancer module to the user.

[0151] Step S1033: Perform identity authentication, i.e., request identity authentication.

[0152] The authentication supports HTTP Basic authentication. Once authentication is successful, access is granted. HTTP Basic authentication first decrypts the value of the Authorization header field in the HTTP request message using the HTTP Basic authentication decryption method to obtain the username and password. The username is the appkey in the authentication policy, and the password is the appsecret in the authentication policy. Then, the corresponding structure is looked up from the HashMap in memory based on the appkey. If the appsecret in the structure matches the decrypted password, the authentication is considered successful; otherwise, it fails, an HTTP / 2 response message is constructed with an HTTP / 2 status code of 401, and forwarded to the user.

[0153] HTTP Basic authentication decryption is a method of decrypting Basic authentication. In the HTTP request message, the value of the Authorization header field begins with "Basic". The username and password are separated by colons and then Base64 encoded. The specific format is Authorization: Basic{Base64 encoded username and password}. Therefore, the decoding method involves Base64 decoding the Base64 encoded username and password, and then separating the strings according to the colons. The first string is the username, and the second string is the password.

[0154] Step S1034: Determine whether the identity authentication request is successful. If not, proceed to step S10311; if yes, proceed to step S1035.

[0155] Step S10311: After interception, the HTTP / 2 response message that failed to construct authentication is directly forwarded to the user.

[0156] Step S1035: Perform whitelist verification, specifically IP whitelist verification.

[0157] The IP whitelist verification retrieves the IP address from the HOST header field of the HTTP request message. Based on the authentication, it obtains the structure corresponding to the appkey of the authentication policy, and then retrieves the IP whitelist `ipWhitelists` from this structure. For efficiency reasons, the IP whitelist only supports the full IP address and does not support placeholders. The IP address obtained from the HOST header field is compared with `ipWhitelists`. If the IP address obtained from the HOST header field is in `ipWhitelists`, the request is allowed; otherwise, it is blocked. An HTTP / 2 response message with an HTTP / 2 status code of 401 is constructed and forwarded to the user.

[0158] Step S1036: Check if the whitelist verification is successful. If not, proceed to step S10311; if yes, proceed to step S1037.

[0159] Step S1037: Obtain the route based on the URI.

[0160] The process of obtaining a route based on the URI involves retrieving the URI from the HTTP request message, traversing the List of routing policies in memory, retrieving the URI matching regular expression uriExpression from the structure, and using the URI matching regular expression to match the URI obtained from the HTTP request message. If a match is found, the matching ends and the route is obtained, allowing the request to proceed. If no match is found, the matching continues in a loop. If no match is found, it is considered that no match has been found and no route has been obtained, so the request is blocked, an HTTP / 2 response message is constructed with an HTTP / 2 response status code of 404, and the message is forwarded to the user.

[0161] Step S1038: Obtain the route? If not, proceed to step S10311; if yes, proceed to step S1039.

[0162] Step S1039: Obtain the upstream services in the route.

[0163] Obtain the upstream service name serviceName from the routing structure obtained in step S1037. Obtain the structure of the appkey corresponding to the authentication policy according to the identity authentication in step S1033. Obtain the upstream service name array serviceNames from the structure and iterate to obtain the authorized upstream service name. If it is consistent with the upstream service name obtained by iterating through the List of routing policies in memory, the iteration ends and the process is allowed. If there is no inconsistency, the iteration continues. If they are all inconsistent, the process is intercepted, an HTTP / 2 response message is constructed with an HTTP / 2 response status code of 403, and forwarded to the user.

[0164] Step S10310: Is the upstream service in the authentication application's upstream service list? If not, proceed to step S10311; if yes, proceed to step S10312.

[0165] In step S104, the load balancing module forwards the HTTP / 2 request message to the upstream according to the load balancing strategy and load balancing mode, and forwards the upstream HTTP / 2 response message to the user.

[0166] The load mode is the core function of this invention to achieve load balancing. In order to achieve multi-level disaster recovery load, a mode that supports both device and random load is designed, which supports horizontal proportional load, vertical multi-level devices, and expansion and contraction without interrupting service provision.

[0167] The implementation of scaling up and down depends on the data configuration without interrupting service provision.

[0168] Horizontal proportional load balancing and vertical multi-level device allocation are achieved through levels and weights. Levels define the hierarchy of upstream devices with the same upstream name; lower levels have higher priority. Only when all high-priority upstreams are unreachable will the next highest priority upstream be accessed. Weights define the weight of an upstream accessed within the same level and with the same upstream name; higher weights increase the probability of being accessed. The probability of an upstream being accessed is calculated by dividing the upstream's weight by the sum of the weights of all upstream devices with the same name and level. (See diagram below.) Figure 2 .

[0169] In this invention, the load strategy is a specific manifestation of the load mode. For the specific implementation method, please refer to the relevant description of the load strategy in step S101.

[0170] The specific implementation process of step S104 is as follows: Figure 6 :

[0171] Step S1041: Receive the HTTP / 2 request message from the authentication module.

[0172] Step S1042: Obtain the upstream service name.

[0173] Based on the URI obtained from the HTTP / 2 request message in step S1041, the List of routing policies in memory is traversed, and the URI matching regular expression in the structure is retrieved. The URI matching regular expression is used to match the URI obtained from the HTTP request message. If a match is found, the matching ends and the upstream service name in the routing structure is obtained. If no match is found, the matching continues in a loop. If no match is found, it is considered that the upstream service name has not been obtained, an HTTP / 2 response message is constructed with an HTTP / 2 response status code of 404, and forwarded to the authentication module.

[0174] Step S1043: Has the upstream service been obtained? If not, proceed to step S1048; if yes, proceed to step S1044.

[0175] Step S1044: Obtain the random allocation class.

[0176] Based on the upstream service name obtained in step S1042, the random allocation class with index 0 is obtained from the List of HashMap in memory for the load balancing strategy.

[0177] Step S1045: Randomly obtain the upstream source.

[0178] Based on the randomly assigned class obtained in step S1044, the random method is called to obtain the structure, which is the upstream information.

[0179] Step S1046: Obtain the HTTP / 2 connection object from the upstream.

[0180] Based on the upstream IP and port obtained in step S1045, the HTTP / 2 connection object is retrieved from the HashMap in memory from the HTTP / 2 connection pool.

[0181] Step S1047: Forward the HTTP / 2 request message to the corresponding upstream.

[0182] Obtain the HTTP / 2 connection object according to step S1046, and forward the HTTP / 2 request message.

[0183] Step S1048: Receive the HTTP / 2 response message from the upstream and forward it to the authentication module.

[0184] Example 2

[0185] According to embodiments of the present invention, an HTTP / 2 load balancing apparatus is provided, such as... Figure 1 As shown, the HTTP / 2 load balancing device includes a configuration module, an authentication module, and a load balancing module.

[0186] Configuration module: Responsible for processing configuration data;

[0187] The authentication module is responsible for receiving HTTP / 2 request messages sent by users, parsing the HTTP / 2 request messages, and performing authentication, IP whitelist verification, and permission verification in sequence. If the authentication result is successful, the HTTP / 2 request message is forwarded to the load balancer module; otherwise, an HTTP / 2 response message indicating authentication failure is directly constructed and forwarded to the user.

[0188] Load Module: Responsible for forwarding the HTTP / 2 request messages to the upstream according to the load balancing policy, and forwarding the upstream HTTP / 2 response messages to the authentication module.

[0189] Key points and points to be protected in this invention

[0190] The key points and areas to be protected in the method of this invention are as follows:

[0191] 1. The upstream is automatically discovered by the access registration center and the load balancing policy is automatically and dynamically updated. See steps S1013 to S1018.

[0192] 2. Supports upstream HTTP / 2 load balancing and HTTP / 2 message-level load balancing. Refer to the description of the HTTP / 2 request load balancing process in Embodiment 1, and refer to steps S1016 to S1018.

[0193] 3. Simultaneously supports horizontal proportional load and vertical multi-level device load models, see step S104.

[0194] Advantages of this invention:

[0195] 1) This invention aims to protect point 1. Open-source load balancers such as Nginx, although they support dynamic configuration updates, do not support automatic upstream discovery. When an upstream is added or deleted, the configuration needs to be manually modified and then reloaded, which increases the workload of operation and maintenance and is also prone to errors. This invention uses the method of connecting to the registry center to realize automatic upstream discovery and automatic configuration, which can be more efficient and reliable. As long as the registry center detects changes in the upstream, this invention can immediately detect the changes and update the strategy.

[0196] 2) This invention aims to protect point 2. Most open-source load balancers support HTTP / 2 load balancing, but none of them support HTTP / 2 packet-level load balancing. For example, Nginx can support upstream HTTP / 2 by compiling a plugin, but it uses TCP load balancing for upstream, which is connection-level load balancing. This may lead to uneven load when the upstream is closed and reopened multiple times. This invention provides native support for upstream HTTP / 2 and supports HTTP / 2 packet-level load balancing.

[0197] 3) This invention aims to protect point 3: open-source load balancers such as Nginx only support proportional horizontal load balancing, not vertical load balancing. For example, consider two groups of servers: a high-performance new server cluster and a lower-performance old server cluster. The lower-performance old servers are slower in disk I / O. We need to provide an HTTP download cluster. In production, we expect all traffic to be evenly distributed across the high-performance new server cluster, with the lower-performance old server cluster as a backup. If the high-performance new server cluster fails completely, the lower-performance old server cluster can temporarily take over. This invention supports such a strategy to ensure service availability to a higher degree.

[0198] Note:

[0199] YAML (YAML Ain't Markup Language) is a human-readable data serialization format. HashMap is a data structure that stores key-value pairs, enabling fast data lookup by mapping keys to values.

[0200] JSON is a lightweight data interchange format, short for JavaScript Object Notation.

[0201] A URI (Uniform Resource Identifier) ​​is an important component of an HTTP request, used to identify and locate resources.

[0202] A list is a linear data structure used to store an ordered set of elements.

[0203] Java is an object-oriented programming language that was introduced by Sun Microsystems (now Oracle Corporation) in 1995.

[0204] HTTP (Hypertext Transfer Protocol) is an application layer protocol used for transmitting hypertext.

[0205] HTTP / 2 (Hypertext Transfer Protocol version 2) is the second major version of the HTTP protocol.

[0206] Base64 is an encoding method used to convert binary data into printable ASCII characters. IP (Internet Protocol) is a network protocol used on the Internet for transmitting data packets. The IP protocol defines the communication rules and address allocation methods between network devices.

Claims

1. A load balancing method based on HTTP / 2, characterized in that... Includes the following steps: Step S101: The configuration module processes the configuration data; Step S102: The authentication module receives the HTTP / 2 request message sent by the user; Step S103: The authentication module parses the HTTP / 2 request message and performs authentication in sequence, including identity authentication, IP whitelist verification, and permission verification. Step S104: The load balancing module forwards the HTTP / 2 request message to the upstream according to the load balancing policy, and forwards the upstream HTTP / 2 response message to the user. The implementation process of step S101 is as follows: Step S1011, configuration file parsing; Configuration file parsing retrieves the configuration from the configuration file every 5 seconds, and generates cost configuration, authentication policy and routing policy after parsing. The configuration file is in YAML format. Step S1012: The authentication policy and routing policy are saved to memory; The authentication strategy is obtained by processing authentications.users in the configuration file and stored in memory as a HashMap, where the key of the HashMap is appkey and the value is a structure. The routing strategy is obtained by processing the routes in the configuration file and stored in memory as a List. The value is a structure, and the order of the List is consistent with the order of the Routes in the configuration file. Step S1013: The upstream registers with the registration center; Upstream companies need to register their relevant information with the registration center; Step S1014: Upon initial startup, obtain upstream information for all upstream services and subscribe to all upstream services; Upstream information is the metadata that the upstream registers with the registry center, including the upstream service name, upstream IP, upstream port, upstream status, load level, and load weight. Step S1015: Start the scheduled task to subscribe to all upstream services from the registry center every 5 seconds; Upstream services in the registration center need to actively register and query. The list of all upstream services cannot be obtained through subscription. However, upstream information of upstream services can be obtained by subscribing to upstream services. When the upstream information of an upstream service changes, the registration center will notify this device. Step S1016: Create an HTTP / 2 connection based on the upstream information; All upstream information obtained in step S1015 needs to be traversed. If the status of the upstream information is 0, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is not 0, no connection is created. If the upstream information obtained after step S1018 is newly added, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is 0, an HTTP / 2 connection is created and an HTTP / 2 connection object is obtained. If the upstream information is updated and the status of the upstream information is not 0, no connection is created. If the upstream information is deleted, no connection is created. An HTTP / 2 connection object refers to the object in the code representing an HTTP / 2 session created using an IP address and port. Step S1017: The load balancing strategy and the HTTP / 2 connection pool are saved to memory; The load balancing strategy is obtained by processing all upstream information and stored in memory as a HashMap. The key of the HashMap is serviceName, and the value is a List. The value of the List is a random allocation class obtained by processing all currently available upstream information with the same serviceName and the same level. The order of the List is sorted in ascending order of level under the same serviceName. The HTTP / 2 connection pool is obtained by processing all HTTP / 2 connection objects obtained in step S1016. It is stored in memory as a HashMap, where the key of the HashMap is a string concatenated with the IP address of the HTTP / 2 connection object plus a colon and the port number of the HTTP / 2 connection object, and the value is the HTTP / 2 connection object. If the upstream information obtained after step S1018 is to delete upstream information or update upstream information and the status of the upstream information is non-zero, then the data in the HTTP / 2 connection pool's in-memory HashMap that uses the string concatenated with the upstream IP address plus a colon plus the upstream port address as the key needs to be deleted. Step S1018: When the upstream service changes, the registration center pushes the upstream information to this device; After steps S1014 and S1015, the registration center will notify this device when the upstream information of the subscribed upstream service changes. Upstream information changes in upstream services refer to the addition, deletion, or updating of upstream services.

2. The load balancing method based on HTTP / 2 according to claim 1, characterized in that... The configuration data processing described in step S101 is implemented in the configuration module, which periodically obtains the configuration in the configuration file and discovers upstream services from the registry center in near real time and obtains the upstream information of all upstream services in real time. After processing, it generates authentication policies, routing policies, load balancing policies, and HTTP / 2 connection pools, and then stores them in the memory of this device.

3. The load balancing method based on HTTP / 2 according to claim 2, characterized in that... The authentication policy is responsible for configuring the authentication policy when a user accesses the service. The user's authentication is associated with the upstream service and is obtained by processing according to the configuration file. The routing policy is responsible for configuring routing information and supports using regular expressions to match URIs to specify specific upstream services, which are obtained by processing the configuration file. The load policy is responsible for configuring the load policy, which is obtained by processing all upstream information obtained from the registry center; The HTTP / 2 connection pool is responsible for the management of the HTTP / 2 connection pool, and is created after obtaining all upstream information from the registration center; The term "upstream service" refers to the code name of multiple upstream sets with the same function. Upstreams with the same upstream service name perform the same function, and sending to any of them can result in the same processing.

4. The load balancing method based on HTTP / 2 according to claim 1, characterized in that... The authentication module described in step S103 parses the HTTP / 2 request message and performs authentication in sequence, including identity authentication, IP whitelist verification, and permission verification. If the execution result is successful, the HTTP / 2 request message is forwarded to the load balancer module, and the subsequent HTTP / 2 response message from the load balancer module is forwarded to the user. Otherwise, an HTTP / 2 response message indicating authentication failure is directly constructed and forwarded to the user.

5. A load balancing method based on HTTP / 2 according to claim 1, characterized in that... The implementation process of step S103 is as follows: Step S1031: Parse the HTTP / 2 request message received from the user authentication module; Step S1032: Determine whether the current device has enabled authentication. If not, proceed to step S10312; otherwise, proceed to step S1033. Step S1033: Perform identity authentication, i.e., request identity authentication; Identity authentication supports HTTP Basic authentication; once authentication is successful, access is granted. HTTP Basic authentication first decrypts the value of the Authorization header field in the HTTP request message using the HTTP Basic authentication decryption method to obtain the username and password. The username is the appkey in the authentication policy, and the password is the appsecret in the authentication policy. Then, the corresponding structure is retrieved from the HashMap in memory based on the appkey. If the appsecret in the structure matches the decrypted password, the authentication is considered successful; otherwise, it fails. An HTTP / 2 response message is constructed with an HTTP / 2 status code of 401 and forwarded to the user. Step S1034: Determine whether the identity authentication request is successful. If not, proceed to step S10311; if yes, proceed to step S1035. Step S1035: Perform whitelist verification, i.e., IP whitelist verification; The IP whitelist verification obtains the IP address from the HOST header field in the HTTP request message, retrieves the structure of the appkey corresponding to the authentication policy based on the identity authentication, and obtains the IP whitelist ipWhitelists from the structure. Considering efficiency issues, the IP whitelist only supports the full IP address and does not support placeholders. The IP address obtained from the HOST header field is compared with ipWhitelists by string comparison. If the IP address obtained from the HOST header field is in ipWhitelists, the request is allowed; otherwise, it is blocked. An HTTP / 2 response message is constructed with an HTTP / 2 response status code of 401 and forwarded to the user. Step S1036: Check if the whitelist verification is successful. If not, proceed to step S10311; if yes, proceed to step S1037. Step S1037: Obtain the route based on the URI; The process of obtaining the route based on the URI involves retrieving the URI from the HTTP request message, traversing the List of routing policies in memory, retrieving the URI matching regular expression uriExpression from the structure, and using the URI matching regular expression to match the URI obtained from the HTTP request message. If a match is found, the matching ends and the route is obtained, allowing the request to proceed. If no match is found, the matching continues in a loop. If no match is found, the request is considered not to have matched and no route has been obtained, and the request is blocked. An HTTP / 2 response message with an HTTP / 2 status code of 404 is constructed and forwarded to the user. Step S1038: Obtain a route? If not, proceed to step S10311; if yes, proceed to step S1039. Step S1039: Obtain the upstream services in the route; Obtain the upstream service name serviceName from the route structure obtained in step S1037. Obtain the structure of the appkey corresponding to the authentication policy according to the identity authentication in step S1033. Obtain the upstream service name array serviceNames from the structure and traverse it to obtain the authorized upstream service name. If it is consistent with the upstream service name obtained by traversing the List of route policies in memory, the traversal ends and the process is allowed. If there is no inconsistency, the traversal continues. If they are all inconsistent, the process is intercepted, an HTTP / 2 response message is constructed with an HTTP / 2 response status code of 403, and forwarded to the user. Step S10310: Is the upstream service in the authentication application's upstream service list? If not, proceed to step S10311; if yes, proceed to step S10312. Step S10311: After interception, directly forward the HTTP / 2 response message that failed to construct authentication to the user; Step S10312: After allowing access, forward the HTTP / 2 request message to the load balancing module; Step S10313: Forward the HTTP / 2 response message from the load balancer module to the user.

6. A load balancing method based on HTTP / 2 according to claim 1, characterized in that... The implementation process of step S104 is as follows: Step S1041: Receive the HTTP / 2 request message from the authentication module; Step S1042: Obtain the upstream service name; Based on the URI obtained from the HTTP / 2 request message in step S1041, the List of routing policies in memory is traversed, and the URI matching regular expression in the structure is retrieved. The URI matching regular expression is used to match the URI obtained from the HTTP request message. If a match is found, the matching ends and the upstream service name in the routing structure is obtained. If no match is found, the matching continues in a loop. If no match is found, it is considered that the upstream service name has not been obtained, an HTTP / 2 response message is constructed with an HTTP / 2 response status code of 404, and forwarded to the authentication module. Step S1043: Has the upstream service been obtained? If not, proceed to step S1048; if yes, proceed to step S1044. Step S1044: Obtain the random allocation class; Based on the upstream service name obtained in step S1042, the random allocation class with index 0 is obtained from the HashMap List of the load balancing strategy in memory; Step S1045: Randomly obtain the upstream source; Based on the randomly assigned class obtained in step S1044, the random method is called to obtain the structure, which is the upstream information; Step S1046: Obtain the HTTP / 2 connection object from the upstream source; Based on the upstream information obtained in step S1045, obtain the upstream IP address and port, and retrieve the HTTP / 2 connection object from the HashMap in memory from the HTTP / 2 connection pool. Step S1047: Forward the HTTP / 2 request message to the corresponding upstream; According to step S1046, obtain the HTTP / 2 connection object and forward the HTTP / 2 request message; Step S1048: Receive the HTTP / 2 response message from the upstream and forward it to the authentication module.

7. A load balancing method based on HTTP / 2 according to claim 1, characterized in that... The currently available upstream information refers to the upstream information with a status of 0. It is obtained by randomly assigning a batch of objects and initializing the weights of the objects. The random method of the random assignment class is called to output the objects randomly selected according to the object selection probability. The selection probability of each object is calculated by dividing the object's weight by the sum of the weights of all objects. The object is a structure in the load strategy.

8. A load balancing method based on HTTP / 2 according to claim 5, characterized in that... The HTTPBasic authentication decryption method is a way to decrypt Basic authentication. It begins with "Basic" in the value field of the Authorization header of the HTTP request message. The username and password are separated by colons and then Base64 encoded. The specific format is: Authorization: Basic {Base64 encoded username and password}. Therefore, the decoding method involves Base64 decoding the Base64 encoded username and password, and then separating the strings according to the colons. The first group is the username, and the second group is the password.

9. A load balancing device for use in the load balancing method of claim 1, characterized in that... include: Configuration module: Responsible for processing configuration data; The authentication module is responsible for receiving HTTP / 2 request messages sent by users, parsing the HTTP / 2 request messages, and performing authentication, IP whitelist verification, and permission verification in sequence. If the authentication result is successful, the HTTP / 2 request message is forwarded to the load balancer module; otherwise, an HTTP / 2 response message indicating authentication failure is directly constructed and forwarded to the user. Load loader module: Responsible for forwarding the HTTP / 2 request messages to the upstream according to the load loader policy, and forwarding the upstream HTTP / 2 response messages to the user.

Images