Dynamic request proxy method and system based on nginx

Abstract

The invention discloses a dynamic request proxy method and system based on nginx. The invention belongs to the technical field. The network monitoring module is started, and a request from a client is waited and received; when a request arrives, analyzing request header information, and extracting an address, a port and a protocol of a request target; verifying the address, the port and the protocol of the extracted request target information; and if the request target is the domain name, executing a domain name resolution process, and converting the domain name into a network address. Checking whether a local cache has an analysis result of the domain name or not; as the proxy service does not need to store and maintain the routing information, the storage demand and the maintenance workload of the server are greatly reduced. An administrator does not need to periodically update a routing table and does not need to worry about problems caused by expiration or errors of routing information. And the proxy service can directly extract the target service information from the request and quickly establish the connection with the target service. The delay of request processing is reduced, and the performance of request forwarding is improved.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, in particular to a dynamic request proxy technology, and in particular to an nginx-based dynamic request proxy method and system. Background Art

[0002] Nginx (engine x) is a high-performance HTTP and reverse proxy web server. Its core function, dynamic request proxying, intelligently distributes client requests to multiple backend servers, achieving the dual goals of load balancing and high system availability. Traditionally, implementations of this type of dynamic request proxying have relied on specialized software or hardware. However, these solutions have gradually exposed performance bottlenecks and insufficient flexibility in practice, limiting their potential for application in complex and changing network environments.

[0003] To address these challenges, existing research and technological innovation are dedicated to exploring more efficient and flexible solutions. For example, Chinese patent CN116389570A discloses a dynamic reverse proxy method, proxy server, and system based on the HTTP / HTTPS protocol. This method pre-configures dynamic routing information containing multiple built-in servers and implements a dynamic update mechanism for routing information in conjunction with Lua scripts. It receives and parses HTTP / HTTPS user requests, which contain request information for a target server corresponding to a preset built-in server. The system then accurately forwards the request to the target server based on the dynamic routing information corresponding to the request, which has been updated by the Lua script.

[0004] Despite this, this solution requires that all request target services and their corresponding routing information be preconfigured on the server, which not only increases the workload of routing maintenance but also directly leads to increased maintenance costs. Furthermore, routing information is stored in external services such as Redis. While this improves flexibility, it also introduces additional resource consumption, resulting in an unnecessary waste of resource costs. Furthermore, the system lacks effective management of connections between request targets, which leads to reduced forwarding performance and unnecessary loss of computing and network resources.

[0005] To this end, the present invention proposes a dynamic request proxy method and system based on nginx. Summary of the Invention

[0006] In view of this, the present invention hopes to provide a dynamic request proxy method and system based on nginx to solve or alleviate the technical problems existing in the prior art, namely how to directly obtain the request target service information, manage the connection with the request target service, and complete the forwarding of business requests, thereby achieving the following effects:

[0007] (1) Because routing information is no longer stored, the maintenance cost of the service itself is greatly reduced;

[0008] (2) Since routing information is no longer stored, no storage is required, thus eliminating the waste of storage resource costs.

[0009] (3) Manage the connection with the requested target service. By default, the connection with the requested target service is placed in the connection pool for management, which improves the connection performance during the forwarding process and reduces resource waste.

[0010] The technical solution of the present invention is achieved as follows:

[0011] First, the dynamic request proxy method based on nginx:

[0012] (1) Overview:

[0013] The present invention aims to build a dynamic request proxy service with high efficiency and low maintenance costs. By abandoning the traditional routing storage method, the solution directly extracts the target service information, including the address, port, and protocol, from the client request, thereby avoiding the storage and maintenance of routing information and greatly reducing the maintenance cost and resource consumption of the service. At the same time, the solution introduces a connection pool management mechanism to effectively manage and reuse connections to the target service. When a request arrives, the system first checks whether there is a connection to the target service in the connection pool. If so, it is used directly. If not, a new connection is established and added to the connection pool. This mechanism improves resource utilization and reduces the overhead of establishing a new connection for each request, thereby improving the performance of request forwarding.

[0014] (2) Technical solution:

[0015] To achieve the above technical objectives, upon receiving a user input dynamic request proxy activation instruction, the following steps are executed:

[0016] 2.1 Step S1, initialization:

[0017] Initializes the configuration and resources of the dynamic request proxy service and loads system parameters and connection pool configuration.

[0018] 2.1.1 Step S100, initializing the configuration of the dynamic request proxy service:

[0019] Create or update the proxy service configuration file (in XML, YAML, or Properties format) containing the necessary service settings.

[0020] Load configuration items, including:

[0021] 1) Basic service information: service name, version number and log level;

[0022] 2) Network communication configuration: listening port, protocol type (HTTP / HTTPS) and timeout settings;

[0023] 3) Security configuration: TLS / SSL certificate path and encryption key (if applicable);

[0024] 4) Performance tuning parameters: thread pool size, connection pool size, and caching strategy.

[0025] 2.1.2 Step S101, load system parameters:

[0026] Read system parameters in the configuration file programmatically (Properties class in Java or @Value annotation in Spring); check and load configuration items covered in system environment variables, and verify the loaded system parameters.

[0027] 2.1.3 Step S102: Load the connection pool configuration:

[0028] Based on the selected HikariCP connection pool, Apache DBCP connection pool, or C3P0 connection pool in the technology stack, configure the following parameters:

[0029] 1) Maximum number of connections: the maximum number of connections allowed in the connection pool;

[0030] 2) Minimum number of idle connections: the minimum number of idle connections maintained in the connection pool;

[0031] 3) Connection timeout: the maximum time to wait for a connection from the connection pool;

[0032] 4) Idle connection survival time: The maximum time a connection remains idle in the connection pool. If it exceeds this time, it will be closed;

[0033] 5) Advanced configuration: connection test statement and connection property settings.

[0034] Finally, the connection pool instance is initialized according to the configuration parameters and is ready to connect to the target service.

[0035] 2.2 Step S2, monitoring and receiving requests:

[0036] Start the network listening module and wait for and receive requests from the client. When a request arrives, parse the request header information and extract the address, port, and protocol of the request target.

[0037] 2.2.1 Step S200, waiting for the request to arrive:

[0038] Wait for requests in blocking or non-blocking mode; in blocking mode, the service will wait until a request arrives; in non-blocking mode, the service will periodically check for new requests and process other tasks at the same time.

[0039] 2.2.2 Step S201: Receive a request:

[0040] When a request arrives, the request data is read based on I / O operations, including the request header, request body, and attachments.

[0041] 2.2.3 Step S202: Parse the request header information:

[0042] Extract the address from the Host field of the request header;

[0043] If not explicitly specified in the request header, extract the default port (e.g. HTTP defaults to 80, HTTPS defaults to 443);

[0044] Extract the protocol (HTTP / 1.1 or HTTP / 2, etc.) from the request line or request header.

[0045] 2.3 Step S3, request target information analysis:

[0046] Verify the address, port, and protocol of the extracted request target information; if the request target is a domain name, execute the domain name resolution process to convert the domain name into a network address.

[0047] Check whether the local cache has the resolution result for the domain name:

[0048] If there is no cached result, a query request is sent to the domain name resolution server and the resolution result is received.

[0049] 2.3.1 Step S300: Verify the requested target information:

[0050] Check whether the address format is correct (such as IPv4, IPv6 or domain name format);

[0051] Verify that the port number is within the allowed range (e.g. 1-65535);

[0052] Confirm whether the protocol is supported (such as HTTP, HTTPS, etc.);

[0053] Use regular expressions or string matching to check whether the request target contains domain name characteristics (such as "." and does not conform to the IP address format).

[0054] Use a hash table, dictionary, or database to store locally cached domain name resolution results; search the cache for the corresponding resolution result based on the domain name;

[0055] 2.3.2 Step S301, execute domain name resolution process:

[0056] S3010: Construct a DNS query request including the domain name to be resolved.

[0057] S3011, send a query request to the configured domain name resolution server (local DNS server or public DNS service, etc.).

[0058] S3012, receive and parse the response from the domain name resolution server, and extract the network address (IPv4 or IPv6 address) corresponding to the domain name.

[0059] S3013, update the local cache: store the domain name and its corresponding network address, and the timestamp information of the resolution result in the local cache so that subsequent requests can directly use the cached results; at the same time, set the data timeout time, using the minimum survival time in the returned record. If the minimum survival time is not specified or is unreasonable, the default setting is 60 seconds.

[0060] 2.3.3 Step S302, return the analysis result:

[0061] Encapsulate the resolved network address into a data structure or object and return it for subsequent request processing (such as routing, forwarding, etc.).

[0062] 2.4 Step S4, connection management and establishment:

[0063] According to the parsed request target address and port, check whether there is a connection to the target in the connection pool and establish a connection;

[0064] 2.4.1 Step S400, check the connection pool:

[0065] Use the API provided by the connection pool manager (HikariCP, Apache DBCP, or C3P0) to query the connections in the connection pool. Retrieve connections from the connection pool using the address and port as the key.

[0066] 2.4.2 Step S401: Determine whether the connection is available:

[0067] Check the status of the connection (whether it is active, idle, or has an error);

[0068] If the connection is unavailable (closed, timed out, or has an error), it is removed from the connection pool;

[0069] 2.4.3 Step S402: Obtaining Available Connections:

[0070] If there is an available connection in the connection pool, use the connection pool manager's API to connect and update the connection status to "in use".

[0071] If there is no connection to the target service in the connection pool, a network programming interface (such as the Socket class in Java) or a framework (such as Netty) is used to establish a new persistent connection to the target service.

[0072] Then, configure the connection parameters, including the timeout period and read / write buffer size, and add the newly established connection to the connection pool.

[0073] 2.4.4 Step S403: Update the connection pool:

[0074] Update the newly established or acquired connection to the connection pool so that it can be reused by subsequent requests; where:

[0075] If an existing connection is obtained, its last used time or status is updated.

[0076] If a new connection is established, it is added to the list of idle connections in the connection pool.

[0077] 2.4.5 Step S404, return connection:

[0078] Encapsulate the connection into an appropriate data structure or object for subsequent request processing (sending request data, receiving responses, etc.).

[0079] 2.5 Step S5, request forwarding:

[0080] Use the connection obtained from the connection pool to forward the client's request to the request target service.

[0081] 2.5.1 Step S500, obtain connection:

[0082] Use the connection pool manager's API to obtain a connection; ensure that the obtained connection is active and can be used to send requests.

[0083] 2.5.2 Step S501: Construct request data:

[0084] Read the client's request header, request body, and attachments; construct standardized request data based on the protocol and interface requirements of the target service.

[0085] 2.5.3 Step S502, send request:

[0086] Use the obtained connection to send the constructed request data to the target service.

[0087] That is, use the network programming interface (such as the OutputStream class in Java) or framework (such as Netty, etc.) to send request data.

[0088] 2.5.4 Step S503, Processing Response:

[0089] Receive the response from the target service and perform corresponding processing based on the response status code, header information and response body, including parsing, caching and / or forwarding.

[0090] You can use network programming interfaces (such as the InputStream class in Java) or frameworks (such as Netty) to receive response data.

[0091] 2.5.5 Step S504: Forward the response to the client:

[0092] Forwards the target service's response to the client.

[0093] Among them, response data can be constructed according to the client's request and protocol requirements, and then the response data can be sent to the client using the connection established with the client.

[0094] 2.5.6 Step S505: Release the connection:

[0095] After the request forwarding is completed, use the connection pool manager's API to mark the connection as idle or release it back to the connection pool, and update the connection status and last usage time so that other requests can reuse it.

[0096] 2.6 Step S6, receiving response and return:

[0097] Wait for and receive response data from the requested target service; parse and process the response data; and return the processed response data to the client.

[0098] (3) Mechanisms for resolving technical issues:

[0099] 3.1 Directly obtain the requested target service information:

[0100] When the proxy service receives a request from the client, it no longer relies on the pre-stored routing information table, but directly extracts the address, port and protocol of the target service from the request header information.

[0101] By parsing the Host field or other protocol-specific header information in HTTP requests, the proxy service can dynamically obtain information about the request target, thus avoiding the storage and maintenance of routing information.

[0102] 3.2 Do not store routing information:

[0103] Because the proxy service extracts the destination information directly from the request, there is no need to store any routing information.

[0104] This design eliminates the need for proxy services to maintain large routing tables, significantly reducing service maintenance costs and saving storage resources. Furthermore, since routing information is not stored, it also avoids request forwarding failures caused by untimely or erroneous routing information updates.

[0105] 3.3 Manage the connection with the request target service:

[0106] The proxy service introduces a connection pool management mechanism, which puts the connection with the requested target service into the connection pool for unified management.

[0107] The connection pool mechanism reuses established connections, avoiding the overhead of reestablishing a new connection for each request. It also effectively monitors and manages connections, ensuring stability and availability. When a request arrives, the proxy service first checks the connection pool for a connection to the target service. If so, it uses the connection directly; otherwise, a new connection is established and added to the pool.

[0108] 3.4 Improving forwarding performance and reducing resource waste:

[0109] By managing the connection pool and directly obtaining request target information, the proxy service can significantly improve the performance of request forwarding and reduce resource waste.

[0110] The connection pool mechanism reduces the overhead of establishing and destroying connections, improving connection utilization. Furthermore, directly obtaining request target information avoids the storage and maintenance of routing information, saving storage resources. These optimization measures work together to improve the proxy service's overall request processing flow, enabling it to forward business requests more efficiently and cost-effectively.

[0111] The second aspect is the dynamic request proxy system based on nginx:

[0112] like Figure 2 As shown, the system is used to implement the above-mentioned nginx-based dynamic request proxy method, which includes:

[0113] (1) The client layer for initiating requests: contains target service information (such as address, port, protocol, etc.). The request is sent to the Nginx (engine x) proxy server.

[0114] (2) The proxy server layer that performs dynamic request proxying, including:

[0115] (2.1) The network monitoring module is responsible for monitoring the network port and receiving requests from the client.

[0116] (2.2) Request parsing module responsible for parsing request header information and extracting target service information (address, port, protocol, etc.).

[0117] (2.3) Connection management module that manages the connection with the target service: including connection establishment, reuse, and release. Its submodules include:

[0118] A connection pool module responsible for storing and providing connections to target services.

[0119] Use the connection obtained from the connection pool to forward the request to the request forwarding module of the target service.

[0120] A response processing module that receives the response from the target service, processes it, and returns it to the client.

[0121] (3) The target service layer is responsible for processing requests and returning response data: interacting with the proxy server layer, receiving requests, and returning responses.

[0122] Compared with the prior art, the present invention has the following beneficial effects:

[0123] 1. Reduced maintenance costs and optimized server resource utilization: Since the proxy service no longer needs to store and maintain routing information, server storage requirements and maintenance workload are significantly reduced. Administrators no longer need to regularly update routing tables or worry about issues caused by outdated or incorrect routing information, thus reducing maintenance costs. By introducing a connection pool management mechanism, connections to target services are effectively managed and reused. This avoids the overhead of establishing a new connection for each request, improving connection utilization and optimizing server resource utilization.

[0124] 2. Improved request forwarding performance: The proxy service can directly extract target service information from the request and quickly establish a connection to the target service (if an available connection is already in the connection pool, it will be used directly). This reduces request processing latency and improves request forwarding performance. Furthermore, it does not rely on a specific route storage method, making it easier to adapt to different network environments and business needs. When adding a new target service, simply configure the proxy service to recognize the new request header information without modifying the existing routing table.

[0125] 3. Reduced storage resource waste: Since routing information no longer needs to be stored, the present invention saves valuable storage resources. For resource-constrained environments (such as cloud services and edge computing), limited resources can be more effectively utilized to provide higher-quality services.

[0126] Fourth, improve service stability and reliability: Through connection pool management and dynamic request processing, the present invention reduces service interruptions and request failures caused by connection problems. At the same time, because it no longer relies on routing information, it also avoids service unavailability caused by incorrect or expired routing information. BRIEF DESCRIPTION OF THE DRAWINGS

[0127] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0128] Figure 1 Schematic diagram of the method flow of the present invention;

[0129] Figure 2 It is a schematic diagram of the system composition of the present invention;

[0130] Figure 3 This is a schematic diagram of the overall dynamic proxy process of the present invention;

[0131] Figure 4 Schematic diagram of the process of step S4 of the present invention. DETAILED DESCRIPTION

[0132] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. Many specific details are set forth in the following description to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0133] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. The devices disclosed in the embodiments are described briefly because they correspond to the methods disclosed in the embodiments. For relevant details, refer to the method description.

[0134] Explanation of relevant terms:

[0135] (1) Configuration and resources of proxy service: refers to the setting options and available resources required for the normal operation of proxy service, such as server address, port number, authentication information, etc.

[0136] (2) System parameters: These are the basic settings required for the proxy service to run, including but not limited to cache size, timeout period, and concurrent connection limit.

[0137] (3) Connection pool: A mechanism for managing database or network connections, used to store and reuse established connections, reducing the overhead of connection establishment and destruction.

[0138] (4) Connection pool configuration: refers to the setting parameters of the connection pool, such as the maximum number of connections, connection idle time, connection timeout, etc., which are used to optimize the performance of the connection pool.

[0139] (5) Request header information: The metadata that the client attaches when sending a request, including information such as request type, target address, protocol version, etc.

[0140] (6) Target address, port, and protocol: Specifies the network location (address), communication port, and communication protocol used by the server to be accessed.

[0141] (7) Resolution results: The network information such as the IP address obtained during the domain name resolution process is the basis for accessing the target service.

[0142] (8) Domain Name Resolution Server: A server responsible for converting domain names into IP addresses, such as DNS (Domain Name System).

[0143] (9) Minimum Time to Live (TTL): The cache time specified in the DNS record, which indicates the maximum time the resolution result can be stored before being replaced.

[0144] (10) Long connection: In network communication, a continuous connection is maintained between the client and the server, allowing multiple requests and responses to be made on the same connection, thereby improving communication efficiency.

[0145] (11) Target service: The service that the client ultimately requests to access, such as a Web server, database service, etc.

[0146] (12) Response data: The data returned by the server after processing the client request, including the request result, status code, message body, etc.

[0147] Example 1: Figure 1 、 3 As shown in Figure 4, this embodiment will provide an execution method of the nginx-based dynamic request proxy method in the online car-hailing management service platform.

[0148] In online ride-hailing management service platforms, users initiate ride-hailing requests through mobile apps or websites. These requests need to be dynamically proxied to different service providers (such as taxi companies or private car service providers) to obtain the best match and price. To this end, this embodiment aims to implement a dynamic request proxy service that can intelligently manage and establish connections based on the target service information requested, and complete the forwarding of service requests.

[0149] In this embodiment, regarding step S1: initialization:

[0150] S100: Create or update the configuration file of the proxy service, such as proxy-config.yaml, which contains the service name (such as "RideHailingProxy"), version number (such as "1.0.0"), log level (such as "INFO"), listening port (such as 8080), protocol type (HTTP / HTTPS), TLS / SSL certificate path (if applicable), thread pool size (such as 100), connection pool size (such as 50), and cache strategy (such as LRU).

[0151] S101: Load system parameters through Java's Properties class or Spring's @Value annotation, such as System.getProperty("proxy.port") or @Value("${proxy.port}"), and verify their validity.

[0152] S102: Configure the HikariCP connection pool, set the maximum number of connections to 50, the minimum number of idle connections to 5, the connection timeout to 30 seconds, and the idle connection lifetime to 60 seconds. Add a connection test statement and property settings. Initialize the connection pool instance and prepare for connection to the target service.

[0153] In this embodiment, regarding step S2: monitoring and receiving requests:

[0154] S200: Start the network monitoring module and use Spring Boot's @RestController and @RequestMapping annotations to listen for HTTP requests on port 8080.

[0155] S201: When a request arrives, the request data is read through Spring's HttpServletRequest object.

[0156] S202: Extract the address (such as api.taxicompany.com) from the Host field of the request header. If the port is not specified, it defaults to 80 (HTTP) or 443 (HTTPS). Extract the protocol (such as HTTP / 1.1) from the request line.

[0157] It is understandable that by parsing the request header information, the address, port, and protocol of the request target can be directly extracted, thereby accurately determining the target service. This helps to reduce the delay of request forwarding and improve the accuracy of the proxy service.

[0158] In this embodiment, regarding step S3: requesting target information analysis:

[0159] S300: Use regular expressions to validate the address format, ensure the port number is within the valid range, and confirm protocol support. If the address is a domain name, check the local cache.

[0160] S301: If the local cache does not have the resolution result of the domain name, a DNS query request is constructed, a query is sent to the configured domain name resolution server (such as 8.8.8.8), and a resolution result (such as IPv4 address 192.168.1.1) is received.

[0161] S302: Encapsulate the resolved network address (such as 192.168.1.1:80) into an object and return it.

[0162] In this embodiment, regarding step S4: connection management and establishment:

[0163] S400: Use the API of the HikariCP connection pool manager to query the connections in the connection pool, and search based on the address and port as keywords.

[0164] S401: Check the status of the connection and remove it from the connection pool if the connection is unavailable.

[0165] S402: If there is an available connection in the connection pool, use it; otherwise, use the Java Socket class or the Netty framework to establish a new persistent connection with the target service, configure the connection parameters, and add it to the connection pool.

[0166] S403: Update the status of the connection pool so that subsequent requests can reuse the connection.

[0167] S404: Encapsulate the connection into an object and return it for subsequent request processing.

[0168] As you can see, using a connection pool manager allows for efficient management and reuse of connections to target services. This helps reduce connection establishment overhead and improves proxy service performance. Furthermore, the connection pool's configuration parameters can be adjusted based on actual needs to further optimize performance.

[0169] In this embodiment, regarding step S5: request forwarding:

[0170] S500: Use the API of the HikariCP connection pool manager to obtain a connection and ensure that it is active.

[0171] S501: Constructing standardized request data (such as a request body in JSON format) according to the protocol and interface requirements of the target service.

[0172] S502: Use Java's OutputStream class or the Netty framework to send the request data to the target service.

[0173] S503: Use the Java InputStream class or the Netty framework to receive the response of the target service, and perform corresponding processing according to the status code, header information and response body of the response.

[0174] S504: Forward the response of the target service to the client, ensuring that the response data matches the client's request and protocol requirements.

[0175] S505: Use the API of the HikariCP connection pool manager to mark the connection as idle or release it back to the connection pool so that other requests can reuse it.

[0176] After acquiring an available connection, the client's request data is forwarded to the target service and the target service's response is received and processed. This ensures that the request is correctly proxied to the target service and the response is returned to the client in a timely manner. This process implements the core functionality of dynamic request proxying.

[0177] In summary, connection pool management and reuse mechanisms reduce connection establishment latency and overhead, improving the proxy service's responsiveness and throughput. Furthermore, regular maintenance and error handling mechanisms maintain the stability and reliability of the proxy service. The proxy service supports multiple protocols and interface requirements, adapting to diverse target services and business needs. Furthermore, the loading of configuration files and system parameters facilitates the adjustment and optimization of the proxy service's performance and behavior.

[0178] Example 2: This example further provides a Python execution program for the solution provided in Example 1:

[0179]

[0180]

[0181]

[0182]

[0183] In the above program:

[0184] Initialization (step S1): The initialize function is responsible for creating or updating the configuration file and loading system parameters for verification, relying on aiohttp.ClientSession to manage the connection.

[0185] Listening and receiving requests (step S2): Use the aiohttp library's web.Application and web.TCPSite to start an HTTP server and listen on the specified port. The handle_request function processes the received request and reads the request data and header information.

[0186] Request target information resolution (step S3): DNS is directly replaced with a predefined IP address.

[0187] Connection management and establishment (step S4): aiohttp.ClientSession is used to manage connections, which implements a connection pool mechanism internally. When forwarding a request, a connection is obtained from the connection pool or a new connection is used.

[0188] Request forwarding (step S5): Use the post method of aiohttp.ClientSession to forward the request to the target service. Receive the response from the target service and forward it to the client. After the request is completed, the connection is automatically returned to the connection pool (managed by aiohttp.ClientSession).

[0189] All of the above embodiments merely represent implementation methods of the present invention in practical applications. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the appended claims.

[0190] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0191] At the same time, those skilled in the art will understand that all or part of the processes in all the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. The dynamic request proxy method based on nginx is characterized in that: When receiving a dynamic proxy activation request from the user, perform the following steps: S1, initialize the configuration and resources of the dynamic request proxy service, and load the system parameters and connection pool configuration; S2, waits for and receives requests from the client; when a request arrives, parses the request header information and extracts the address, port and / or protocol of the request target; S3, verifying the address, port and / or protocol of the extracted request target information; If the request target is a domain name, the domain name resolution process is executed to convert the domain name into a network address; If there is no cached result, send a query request to the domain name resolution server and receive the resolution result; S4, based on the parsed request target address and / or port, checks whether there is a connection to the target in the connection pool and establishes a connection; S5, uses the connection obtained from the connection pool to forward the client's request to the request target service; S6, waiting for and receiving response data from the requested target service; Parse and process the response data; Return the processed response data to the client.

2. The dynamic request proxy method according to claim 1, wherein: In S1, the method for initializing the configuration of the dynamic request proxy service includes: Create or update the configuration file of the proxy service; Load configuration items, including: Basic service information: service name, version number and log level; Network communication configuration: listening port, protocol type and timeout settings; Security configuration: TLS / SSL certificate path and encryption keys; Performance tuning parameters: thread pool size, connection pool size, and caching strategy.

3. The dynamic request proxy method according to claim 1, wherein: In S1, according to the HikariCP connection pool, Apache DBCP connection pool or C3P0 connection pool selected by the technology stack, configure the maximum number of connections, the minimum number of idle connections, the connection timeout and the idle connection survival time; Initializes the connection pool instance according to the configuration parameters and prepares the connection to the target service.

4. The dynamic request proxy method according to claim 1, wherein: In S2, when a request arrives, the request data, including the request header, request body, and attachments, is read based on an I / O operation; Extract the address from the Host field of the request header; If not explicitly specified in the request header, the default port is extracted; Extract the protocol from the request line or request header.

5. The dynamic request proxy method according to claim 1, wherein: The implementation process of S3 includes: S300, checks whether the address format is correct, verifies whether the port number is within the allowed range, confirms whether the protocol is supported, and checks whether the request target contains domain name characteristics through regular expressions or string matching; S301, perform domain name resolution: S3010: Construct a DNS query request including the domain name to be resolved. S3011, to the configured domain name resolution server; S3012, receiving and parsing the response from the domain name resolution server, and extracting the network address corresponding to the domain name; S3013, update the local cache: store the domain name and its corresponding network address, and the timestamp information of the resolution result in the local cache; set the timeout of the data and use the minimum survival time in the returned record.

6. The dynamic request proxy method according to any one of claims 1 to 5, characterized in that: The execution process of S4 includes: S400, using the API provided by the connection pool manager to query the connections in the connection pool; S401, check the status of the connection, and remove it from the connection pool if the connection is unavailable; S402: If there is an available connection in the connection pool, use the connection pool manager API to connect; otherwise, use the network programming interface to establish a new persistent connection with the target service; S403, updating the newly established connection or the acquired connection to the connection pool; S404: Encapsulate the connection into an appropriate data structure or object.

7. The dynamic request proxy method according to claim 6, wherein: In S403, if the connection acquired is an existing connection, its last usage time or status is updated; if a new connection is established, it is added to the idle connection list of the connection pool.

8. The dynamic request proxy method according to claim 6, wherein: In S5, a response from the target service is received, and parsed, cached, and / or forwarded according to the status code, header information, and response body of the response.

9. A system for implementing the dynamic request proxy method according to any one of claims 1 to 8, characterized in that: The system comprises: The client layer for making requests; A proxy server layer that performs dynamic request proxying; The target service layer is responsible for processing requests and returning response data.

10. The system according to claim 9, characterized in that: The proxy server layer includes: A network monitoring module responsible for monitoring network ports and receiving requests from clients; Request parsing module responsible for parsing request header information and extracting target service information; A connection management module that manages connections to target services.

Images