A method, system, device and medium for forwarding an HTTP request to an intranet application

Abstract

The application discloses a kind of HTTP request forwarding to intranet application method, system, equipment and medium, it is related to network communication technical field.The method includes: intranet RPC service and the relay RPC cloud service of public network side establish long connection, and report intranet device serial number;Relay service binds this serial number with communication channel.Intranet service maintains connection by heartbeat mechanism, and it is automatically rebuilt and updated when abnormal.Binding.External HTTP request reaches relay service, extracts target serial number and matches channel, generates unique request ID and binds asynchronous response waiting object, then forwards request to intranet.Intranet application microservice processes request, and response data with request ID is returned by original channel.The relay service is matched according to request ID waiting object, obtains response and returns client.The application realizes that external request is safely and accurately accessed to intranet application, has dynamic network self-adapting and high concurrent reliable processing capacity, and simplifies deployment and maintenance.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and specifically to a method, system, device, and medium for forwarding HTTP requests to intranet applications. Background Technology

[0002] In modern application architectures, especially microservice architectures, many core business applications or data processing microservices are typically deployed within an enterprise's internal network (internal network) or a protected private LAN environment. This deployment method effectively isolates public network threats, ensuring the security of core data and the stability of system operation. However, with the increasing demand for mobile office, remote operation and maintenance, IoT device access, and cross-organizational collaboration, external clients located on the public network (such as mobile applications, partner systems, remote monitoring terminals, etc.) often need to securely and reliably access these application services deployed on the internal network, especially through the common HTTP / HTTPS protocol.

[0003] To enable external networks to access internal network applications, the following solutions are commonly used: (1) Port mapping (such as NAT traversal, DMZ zone deployment): Directly mapping a specific port of an internal network service to the public network gateway. This method is equivalent to opening a hole in the internal network firewall, which greatly increases the risk of being attacked. Moreover, the configuration is complex and it is difficult to flexibly adapt to service changes or dynamic IP environments.

[0004] (2) Virtual Private Network (VPN): A VPN establishes an encrypted tunnel for external clients to access the internal network, temporarily making them part of the internal network. Although VPNs offer high security, they are complex to configure and maintain, require clients to install dedicated software, resulting in a poor user experience. Furthermore, there is a delay in establishing and disconnecting VPN tunnels, making them unsuitable for high-frequency, short-connection access scenarios with high real-time requirements. In addition, once a VPN is established, clients will gain extensive network access privileges, posing a security risk of excessive privileges.

[0005] (3) Traditional reverse proxy: Deploy a proxy server on the public network to forward requests to the internal network. This method hides the internal network structure to some extent, but still requires configuring fixed entry rules for the proxy server in the internal network firewall. When the internal network service IP address changes dynamically (such as DHCP allocation, containerized dynamic scheduling) or the network is interrupted, the proxy configuration needs to be updated manually, lacking automatic adaptation capabilities and resulting in a heavy maintenance burden. In addition, when dealing with high concurrency requests, traditional proxies have difficulty accurately maintaining the correspondence between each request and response, which can easily lead to response errors.

[0006] In summary, existing technologies for enabling external HTTP requests to access microservices within the internal network generally suffer from contradictions and shortcomings in terms of security, dynamic adaptability, connection stability, and precise request / response matching. Therefore, there is an urgent need for a novel forwarding mechanism that can balance secure isolation, dynamic addressing, link reliability, and ease of maintenance to support increasingly complex cross-network access needs. Summary of the Invention

[0007] To address the problems in existing technologies, such as the inability of external HTTP requests to securely and reliably access intranet applications, difficulty in adapting to dynamic network changes, and difficulty in accurately matching requests and responses in high-concurrency scenarios, this invention provides a method, system, device, and medium for forwarding HTTP requests to intranet applications, thereby resolving the aforementioned technical deficiencies.

[0008] This invention proposes a method for forwarding HTTP requests to intranet applications, the method comprising the following steps: S1. The intranet RPC service establishes a long connection with the relay RPC cloud service deployed on the public network side and reports the intranet device serial number to the relay RPC cloud service; the relay RPC cloud service binds and stores the intranet device serial number with the communication channel for establishing the long connection; S2. The intranet RPC service maintains long connections through a heartbeat mechanism. When the long connection is interrupted, the intranet RPC service re-establishes the long connection with the relay RPC cloud service and re-reports the intranet device serial number so that the relay RPC cloud service can update the binding relationship between the serial number and the communication channel. S3, the relay RPC cloud service receives HTTP requests from external clients, extracts the serial number of the intranet device to be accessed from the HTTP request, and queries the corresponding communication channel based on the extracted intranet device serial number; S4, the relay RPC cloud service generates a unique request ID for the HTTP request and creates an asynchronous response wait object bound to the request ID; then it forwards the HTTP request to the intranet RPC service through the queried communication channel; S5, the intranet RPC service forwards the received requests to the intranet application microservice for processing; after processing, it generates response data carrying the request ID and returns it to the relay RPC cloud service through the original communication channel; S6, the relay RPC cloud service matches the corresponding asynchronous response waiting object based on the request ID in the response data, retrieves the response data from it, and returns the response data to the external client that initiated the HTTP request.

[0009] Preferably, in step S1, the intranet RPC service establishes a long connection with the relay RPC cloud service deployed on the public network side and reports the intranet device serial number to the relay RPC cloud service; the relay RPC cloud service binds and stores the intranet device serial number with the communication channel for establishing the long connection, including the following sub-steps: S11. When the relay RPC cloud service starts, it registers its network address information with the registration center. S12. When the intranet RPC service starts, it queries and obtains the network address information of the relay RPC cloud service from the registry center. S13. The intranet RPC service initiates a connection request to the relay RPC cloud service based on the obtained network address information to establish a long connection; S14. After the long connection is established, the intranet RPC service immediately sends a reporting message containing the intranet device serial number to the relay RPC cloud service through the long connection. S15. The relay RPC cloud service receives the reported message, parses out the internal network device serial number, and associates the internal network device serial number with the communication channel carrying the reported message, storing it in the local binding relationship; specifically, associating and storing the serial number with the communication channel is done using a thread-safe key-value mapping container, where the key is the internal network device serial number and the value is a reference to the corresponding communication channel object.

[0010] Preferably, in step S2, the heartbeat mechanism maintains the long-lived connection, specifically including the following sub-steps: S21. The intranet RPC service sends heartbeat messages to the relay RPC cloud service via a long connection according to a preset time period. S22. After receiving the heartbeat message, the relay RPC cloud service returns an acknowledgment response to the intranet RPC service. S23. Check if the internal network RPC service monitoring has received an acknowledgment response; if no acknowledgment response is received within the preset time, the current heartbeat cycle detection is deemed to have failed.

[0011] More preferably, in step S2, when the long connection is interrupted, the specific judgment condition is: the internal network RPC service fails to detect for N consecutive heartbeat cycles, and / or the internal network RPC service detects that the IP address of its network environment has changed; where N is an integer greater than 1.

[0012] Preferably, in step S2, rebuilding the long connection includes: the intranet RPC service uses a backoff algorithm to control the waiting time for reconnection attempts, and obtains the current network address information of the relay RPC cloud service from the registry center and establishes a connection during each attempt.

[0013] Preferably, in step S4, an asynchronous response wait object bound to the request ID is created, including the following sub-steps: S41. The relay RPC cloud service generates a globally unique string for each received HTTP request, which serves as the request ID of the HTTP request; S42. The relay RPC cloud service creates a new asynchronous response wait object. The asynchronous response wait object is used to block and wait and eventually obtain response data that matches the request ID. S43. The relay RPC cloud service uses the request ID as the key and the asynchronous response waiting object as the value, storing them in a thread-safe hash mapping structure to complete the binding.

[0014] Preferably, in step S6, matching the corresponding asynchronous response waiting object based on the request ID in the response data includes: using the request ID as the key, querying the corresponding asynchronous response waiting object from the thread-safe hash map storing the binding relationship, and setting the response data into the asynchronous response waiting object to release its waiting state.

[0015] This invention also proposes a system for forwarding HTTP requests to intranet applications, used to implement any of the methods described above, the system comprising: The relay RPC cloud service module is deployed in a public network environment and configured to perform the following operations: Establish a long connection with the intranet RPC service module, receive the intranet device serial number reported by the intranet RPC service module, and bind and store the serial number with the communication channel for establishing the long connection; The system maintains a long-lived connection with the internal network RPC service module through a heartbeat mechanism, and updates the binding relationship based on the re-reported sequence number when the long-lived connection is re-established after an interruption. Receive HTTP requests from external clients, extract the serial number of the intranet device to be accessed from the HTTP request, and query the corresponding communication channel based on the extracted intranet device serial number; Generate a unique request ID for the HTTP request, create an asynchronous response wait object bound to the request ID, and forward the HTTP request through the queried communication channel; Based on the request ID in the response data returned from the internal network, match the corresponding asynchronous response waiting object to obtain the response data, and return the response data to the external client that initiated the HTTP request; The intranet RPC service module, deployed in the intranet environment, is configured to perform the following operations: Establish a long connection with the relay RPC cloud service module and report the internal network device serial number to the relay RPC cloud service module; The long connection is maintained through a heartbeat mechanism, and when the long connection is interrupted, the long connection is re-established with the relay RPC cloud service module and the internal network device serial number is re-reported. The request received through the communication channel is forwarded to the intranet application microservice module, and the response data generated after processing, carrying the request ID, is returned through the original communication channel. The intranet application microservice module is deployed in the intranet environment and communicates with the intranet RPC service module to process received requests and generate response data.

[0016] The present invention also proposes a terminal device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein when the processor executes the computer program, it implements the method steps of forwarding any of the above-described HTTP requests to an intranet application.

[0017] The present invention also proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method steps described above for forwarding an HTTP request to an intranet application.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) This invention utilizes a communication mode where an intranet RPC service deployed on the intranet actively initiates and maintains a long connection with a relay RPC cloud service on the public network. This eliminates the need for the intranet to open any inbound ports or perform firewall mapping. External access requests can only reach the public network relay node and must be authenticated and addressed by carrying a valid and bound intranet device serial number. This architecture, where the intranet actively sends out requests and the public network only relays, effectively avoids the attack surface caused by traditional port mapping or reverse proxy exposing intranet addresses and ports, achieving a higher level of network isolation and security protection.

[0019] (2) Based on the continuous monitoring of the heartbeat mechanism and the active reconnection mechanism, the system can perceive the connection status of long connections in real time. Combined with the service discovery function of the registry center, when the IP address of the intranet device changes due to DHCP, migration or failure, or when the network is temporarily interrupted, the intranet RPC service can automatically and promptly rediscover the service address and rebuild the connection, and synchronously update the binding relationship between the sequence number and the channel. This process does not require manual intervention, effectively solving the problems of cumbersome configuration and difficult maintenance of traditional solutions in dynamic IP environments, and ensuring the continuous availability of service access links.

[0020] (3) By generating a unique request ID for each external HTTP request on the relay RPC cloud server and creating an asynchronous response waiting object bound to it for management, and by forcibly including the same request ID in the response returned from the intranet, a global, thread-safe request-response tracing mechanism is established. This enables the system to accurately match the asynchronously returned response data with the previously suspended request context, even in high-concurrency scenarios where multiplexers share the same communication channel. This effectively solves the problems of response confusion, loss, or misattribution that may occur in traditional proxies, and improves the accuracy and reliability of business processing.

[0021] (4) This invention presents a standard HTTP service to external clients, requiring no specific software (such as a VPN client) to be installed or complex configurations to be made on the client side. On the internal network side, only an internal network RPC service component responsible for connection management and forwarding needs to be run, without modifying existing internal network application microservices or adjusting the network architecture. The overall solution encapsulates complexity in the middle layer, providing a simple and unified access method for both the internal and external networks, significantly reducing the technical threshold and cost of deployment, upgrades, and daily operation and maintenance. Attached Figure Description

[0022] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments, taken with reference to the accompanying drawings: Figure 1 This is a flowchart of a method for forwarding HTTP requests to an intranet application according to an embodiment of the present invention; Figure 2 This is a system architecture block diagram of forwarding HTTP requests to intranet applications according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating the data processing of an external HTTP request being forwarded to an intranet application via a relay service, according to an embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of a computer system suitable for implementing the embodiments of the present invention. Detailed Implementation

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] Figure 1A flowchart illustrating a method for forwarding HTTP requests to an intranet application according to an embodiment of the present invention is shown. Figure 2 This diagram illustrates a system architecture block diagram for forwarding HTTP requests to intranet applications according to an embodiment of the present invention. Figure 3 This diagram illustrates a data processing flow chart of an embodiment of the present invention, showing how external HTTP requests are forwarded to an intranet application via a relay service. For example... Figure 1-3 As shown in the figure, an embodiment of the present invention provides a method for forwarding HTTP requests to an intranet application, comprising the following steps: S1. The internal network RPC service establishes a long connection with the relay RPC cloud service deployed on the public network side and reports the internal network device serial number to the relay RPC cloud service; the relay RPC cloud service binds and stores the internal network device serial number with the communication channel for establishing the long connection.

[0026] This step is fundamental to the system's operation. Its core objective is to establish a stable and identifiable dedicated communication channel between the public and internal networks, and to strongly associate the unique identifiers of internal network devices with this channel. The specific implementation process is as follows: S11. When the relay RPC cloud service starts, it registers its network address information with the registration center.

[0027] First, the system is deployed and initialized. The relay RPC cloud service is deployed on a cloud server or host with a public IP address. In this embodiment, the service is developed using Java and based on the high-performance network framework Netty, implementing an HTTP protocol server. After the service starts, its primary operation is to register the service with a centralized registry (Nacos is used in this embodiment). The registration information includes, but is not limited to, the service name (e.g., transit-rpc-service), its listening public IP address (e.g., 203.0.113.100), and port number (e.g., 8080). This step allows the network location information of the relay RPC cloud service to be dynamically discovered.

[0028] S12. When the intranet RPC service starts, it queries and obtains the network address information of the relay RPC cloud service from the registry center.

[0029] Subsequently, the intranet RPC service deployed in the intranet environment (such as an enterprise LAN or industrial control network) is started. This service is also developed based on the Netty framework and runs as a client. After starting, it immediately sends a query request to the same registry center (Nacos) to obtain the current network address information (203.0.113.100:8080) of the relay RPC cloud service registered in step S11.

[0030] S13. The intranet RPC service initiates a connection request to the relay RPC cloud service based on the obtained network address information to establish a long connection.

[0031] After successfully obtaining the address, the client of the intranet RPC service uses that address to proactively initiate a TCP connection request to the server of the public network relay RPC cloud service. Once the connection is successfully established through a three-way handshake, a long-lived connection is formed from the intranet to the public network. In the Netty framework, this connection is abstracted as a communication channel, which serves as the carrier for all subsequent data exchange.

[0032] S14. After the long connection is established, the intranet RPC service immediately sends a reporting message containing the intranet device serial number to the relay RPC cloud service through the long connection.

[0033] After the long connection is established, the intranet RPC service needs to immediately send a reporting message to the relay RPC cloud service through this newly established communication channel. This message carries a crucial piece of information: the intranet device serial number. In this embodiment, this serial number is a unique factory identifier for the intranet device (such as a specific industrial gateway, server, or IoT terminal), for example, SN-9A8B7C6D5E4F. By reporting this serial number, the intranet service proactively declares its identity.

[0034] S15. The relay RPC cloud service receives the reported message, parses out the internal network device serial number, and associates the internal network device serial number with the communication channel carrying the reported message, storing it in the local binding relationship; specifically, associating and storing the serial number with the communication channel is done using a thread-safe key-value mapping container, where the key is the internal network device serial number and the value is a reference to the corresponding communication channel object.

[0035] Upon receiving the report message, the server of the relay RPC cloud service parses it and extracts the internal network device serial number SN-9A8B7C6D5E4F. Next, the server performs a binding operation: it associates the parsed serial number with the communication channel carrying the report message (i.e., the channel object of the newly established long connection). In this embodiment, this binding relationship is stored in a thread-safe key-value mapping container in the server's local memory. The key is the internal network device serial number SN-9A8B7C6D5E4F, and the value is the corresponding communication channel object reference. Thus, a mapping relationship between a device identifier and a communication channel is successfully established and persistently stored, laying the foundation for accurate request forwarding. This binding storage mechanism ensures that even with a large number of internal network devices connecting simultaneously, the relay service can quickly and accurately locate the correct communication path using the serial number.

[0036] Continue to refer to Figure 1-3 The present invention provides a method for forwarding HTTP requests to an intranet application, which further includes the following steps: S2. The intranet RPC service maintains long connections through a heartbeat mechanism. When a long connection is interrupted, the intranet RPC service re-establishes the long connection with the relay RPC cloud service and re-reports the intranet device serial number so that the relay RPC cloud service can update the binding relationship between the serial number and the communication channel.

[0037] This step is the core mechanism for ensuring the long-term stability and reliability of the communication link. It aims to dynamically monitor the connection's health status and automatically recover in the event of network anomalies, ensuring the continued reachability of external requests. The specific implementation of the heartbeat mechanism is as follows: S21. The intranet RPC service sends heartbeat messages to the relay RPC cloud service via a long connection according to a preset time period.

[0038] To ensure the activity of persistent connections and prevent idle connections from being dropped due to timeouts of intermediate network devices or firewall policies, the internal RPC service incorporates a heartbeat detection module. This module is configured with a preset heartbeat period, such as 30 seconds. At each interval, the heartbeat detection module controls the Netty client to send a specific, minimal-payload heartbeat message (e.g., a protocol packet containing specific instructions) to the Netty server of the relay RPC cloud service through the established communication channel. The sole purpose of this heartbeat message is to declare to the other end that the connection is active and valid.

[0039] S22. After receiving the heartbeat message, the relay RPC cloud service returns an acknowledgment response to the internal network RPC service.

[0040] After receiving a heartbeat message from the channel, the Netty server of the relay RPC cloud service will immediately generate a corresponding acknowledgment response (ACK) and return it to the internal network RPC service through the same channel.

[0041] S23. Check if the internal network RPC service monitoring has received an acknowledgment response; if no acknowledgment response is received within the preset time, the current heartbeat cycle detection is deemed to have failed.

[0042] After sending a heartbeat message, the internal network RPC service starts a timer for that heartbeat and monitors the channel to wait for an acknowledgment response from the peer. The preset waiting time (i.e., timeout) is slightly shorter than the heartbeat cycle, for example, 25 seconds. If an acknowledgment response is successfully received within 25 seconds, the heartbeat detection is considered successful, the relevant counters are reset, and the system waits for the next heartbeat cycle. If no acknowledgment response is received within the preset 25-second timeout period, the heartbeat detection module records and determines that the current heartbeat cycle has failed. This failure may indicate a sudden increase in network latency, a one-way link interruption, or temporary unavailability of the peer service.

[0043] When the heartbeat detection mechanism fails multiple times in a row, or when changes are detected at the underlying network layer, the system will determine that the long connection has been interrupted and trigger the reconstruction process.

[0044] Judgment Criteria: In this embodiment, when the internal network RPC service detects N consecutive (e.g., N=3) failed heartbeat cycles (i.e., no valid heartbeat confirmation received for 90 consecutive seconds), the system has sufficient reason to determine that the current long-lived connection has failed. And / or, the internal network RPC service continuously monitors the network interface status of its operating system. Once it detects a change in the IP address of its network environment (e.g., from 192.168.1.101 to 192.168.1.102), regardless of the current heartbeat status, it will immediately determine that the original connection based on the old IP is unavailable and needs to be rebuilt. Both of these situations will trigger the connection interruption logic.

[0045] Rebuilding the persistent connection: Once a connection is determined to be interrupted, the reconnection module in the internal RPC service immediately takes over the process and begins reconnection. This module uses a backoff algorithm (such as binary exponential backoff) to control the waiting time for reconnection attempts. The first reconnection attempt may begin immediately or after a short delay (such as 1 second); if it fails, the waiting time for the next attempt will increase exponentially (e.g., 2 seconds, 4 seconds, 8 seconds...) until a maximum delay limit is reached to avoid meaningless frequent impacts when the server is temporarily unavailable.

[0046] During each reconnection attempt, the reconnection module does not use the old cached address, but instead retrieves the current network address information of the relay RPC cloud service from the registry center (Nacos). This design is crucial, ensuring that even if the relay service changes its IP or port due to failover or scaling, the internal network service can discover the latest access point. After obtaining the new address, the reconnection module controls the Netty client to initiate a new connection request, the process of which is exactly the same as step S13. Once the connection is successfully established, the internal network RPC service immediately re-reports its internal network device serial number.

[0047] Upon receiving a sequence number reporting message from the same device but via a new channel, the relay RPC cloud service performs an update operation: it uses this new communication channel object reference to overwrite the old, expired channel reference for that sequence number in the thread-safe mapping container, thus updating the binding relationship between the sequence number and the communication channel. At this point, the communication link has completed self-healing without manual intervention, and the system returns to a ready state. During this period, if an external request arrives, the relay service will return an error to the client if a valid channel cannot be found or the request processing times out, preventing request loss.

[0048] Continue to refer to Figure 1-3The present invention provides a method for forwarding HTTP requests to an intranet application, which further includes the following steps: S3, the relay RPC cloud service receives HTTP requests from external clients, extracts the serial number of the intranet device to be accessed from the HTTP request, and queries the corresponding communication channel based on the extracted intranet device serial number.

[0049] This step is the entry point and starting point for external requests entering the forwarding system. Its core function is to parse the external request and accurately locate the pre-established internal network communication channel based on the target identifier in the request. The specific implementation process is as follows: When an external client (such as a mobile app, web front-end, or third-party service running on the public network) needs to access an application microservice on a specific internal network device, it constructs a standard HTTP / HTTPS request. The target address of this request is not the internal network service itself, but rather a public access endpoint (e.g., http: / / cloud-service.com:8080) of a relay RPC cloud service deployed on the public network. The request includes the identifier of the specific internal network device to be accessed, as well as the specific business path and parameters.

[0050] When an HTTP request arrives at the Netty server, which is acting as a relay RPC cloud service, the server immediately initiates the HTTP protocol parsing process. The external client must include a specific field in the HTTP request header to specify the internal network device it wishes to access. In this embodiment, this field is named Device-SN.

[0051] Therefore, after completing the basic HTTP request line and header parsing, the Netty server extracts the value of the Device-SN field from the HTTP request header information. This value is defined as the serial number of the internal network device being accessed. For example, if an HTTP request header contains Device-SN: SN-9A8B7C6D5E4F, then after extraction, the target serial number is SN-9A8B7C6D5E4F. If the request does not contain this field or the field value is empty, the relay service will directly return an error response such as 400 Bad Request and refuse to process the request.

[0052] After successfully extracting the target intranet device serial number, the relay RPC cloud service needs to find a dedicated channel to that device. This process involves querying the corresponding communication channel based on the extracted intranet device serial number.

[0053] Specifically, the server accesses its maintained thread-safe key-value mapping container. It uses the extracted sequence number SN-9A8B7C6D5E4F as the key to attempt to retrieve the corresponding value from the mapping container, which is a valid Netty communication channel object reference bound to that sequence number.

[0054] Query successful: If an entry with the key SN-9A8B7C6D5E4F exists in the container, and its corresponding communication channel object is active, the query is successful, and a valid communication channel pointing to the target intranet device has been obtained. The system then proceeds to step S4.

[0055] Query failed: If the key does not exist in the container, or the corresponding communication channel is closed, it means that there is currently no active long-lived connection from the internal network device (the device may be offline, the network may be interrupted, or the binding relationship may not have been established). In this case, the relay RPC cloud service cannot forward the request and will immediately return an error response to the external client, such as 503 ServiceUnavailable, with an explanation that the target device is unreachable, thereby preventing the request from being suspended invalidly.

[0056] Through the above process, the system completes the identification and mapping from external general HTTP requests to internal specific device channels, preparing for subsequent targeted forwarding. This step ensures the accuracy of forwarding; no request can be sent to an unexpected internal network device, and invalid or unroutable requests are quickly rejected, guaranteeing the robustness of the system.

[0057] Continue to refer to Figure 1-3 The present invention provides a method for forwarding HTTP requests to an intranet application, which further includes the following steps: S4, the relay RPC cloud service generates a unique request ID for the HTTP request and creates an asynchronous response wait object bound to the request ID; then it forwards the HTTP request to the intranet RPC service through the queried communication channel.

[0058] This step is crucial for achieving accurate request-response matching in high-concurrency scenarios. Its core function is to establish a unique tracking identifier for each external request and prepare a synchronous mechanism for receiving asynchronous responses, subsequently completing the inward request forwarding. The specific implementation process is as follows: S41. The relay RPC cloud service generates a globally unique string for each received HTTP request, which serves as the request ID of the HTTP request.

[0059] After successfully retrieving a valid communication channel from step S3, the relay RPC cloud service needs to create a unique identifier for the HTTP request for full lifecycle tracking. For each received, valid HTTP request that needs to be forwarded, the server generates a globally unique string as its request ID. In this embodiment, a standard algorithm is typically used to ensure uniqueness, such as generating a UUID (Universally Unique Identifier), like uuid-1234-5678-90ab-cdef12345678. This request ID is unique throughout the system and is used to accurately associate the forwarding and response of the same request in subsequent steps.

[0060] S42. The relay RPC cloud service creates a new asynchronous response wait object. The asynchronous response wait object is used to block and wait and eventually obtain response data that matches the request ID.

[0061] After generating the request ID, the system needs to create a synchronization mechanism to wait for the potentially delayed intranet response. To this end, the relay RPC cloud service creates a new asynchronous response waiting object. In this embodiment, this object is a programming construct used to implement asynchronous operation result waiting and retrieval (for example, in a Java Netty-based implementation, it can be implemented using concrete components such as Promise or DefaultFuture). This object operates based on the Future pattern. The core function of this object is to block and wait until a result is eventually obtained. After creation, it is in an incomplete state and will be associated with a specific request ID. When the method of this object used to retrieve the result is called, the thread executing the call is suspended (i.e., enters a blocked waiting state) until another thread (e.g., the thread handling the response return in step S6) assigns or passes the response data returned from the intranet to this object, thereby waking up the waiting thread and obtaining the response data.

[0062] S43. The relay RPC cloud service uses the request ID as the key and the asynchronous response waiting object as the value, storing them in a thread-safe hash mapping structure to complete the binding.

[0063] To locate the corresponding waiting object at any time using the request ID (especially when an asynchronous response returns), a mapping relationship between the two needs to be established. The intermediary RPC cloud service maintains a global, thread-safe hash mapping structure, such as a ConcurrentHashMap.<String, Promise> In this step, the server performs a binding operation: it uses the request ID (e.g., uuid-1234-5678-90ab-cdef12345678) as the key and the newly created asynchronous response wait object (Promise) as the value, storing them in this hash map. This binding operation completes the binding, meaning that subsequently, as long as this request ID is held, the corresponding wait object can be retrieved from this map, allowing for setting the response or checking the status.

[0064] The HTTP request is forwarded to the internal RPC service via the queried communication channel. After the request ID is generated and bound to the asynchronous object, the system can execute the forwarding. The relay RPC cloud service encapsulates the original HTTP request (or its necessary components, such as method, path, headers, and request body) along with the generated request ID into a message format defined by the internal RPC protocol. Then, it writes the encapsulated message into the communication channel queried in step S3 (i.e., the Netty communication channel bound to the target device serial number) and sends it out immediately. Since this channel is a long-lived connection between the public network and the internal network, the message will be reliably transmitted to the Netty client of the internal RPC service on the internal network side through this connection.

[0065] At this point, step S4 is complete. The external request has been assigned a unique identifier, its response receiver (asynchronous response wait object) is in place and registered, and the request itself has embarked on its journey to the target intranet service. The entire design ensures that even in the face of massive concurrent requests, the state of each request can be managed independently and in an orderly manner.

[0066] Continue to refer to Figure 1-3 The present invention provides a method for forwarding HTTP requests to an intranet application, which further includes the following steps: S5, the intranet RPC service forwards the received requests to the intranet application microservice for processing; after processing, it generates response data carrying the request ID and returns it to the relay RPC cloud service through the original communication channel.

[0067] This step involves the processing and response generation of business requests on the intranet side. Its core function is to act as a bridge between the intranet and the external network, delivering external requests to specific business services and returning the processing result along with the original request identifier to ensure that the response correctly matches the original request. The specific implementation process is as follows: When the Netty client of the internal RPC service receives a data packet from the relay RPC cloud service via a long connection, it immediately decodes it. The decoding operation is performed according to the internal RPC protocol format agreed upon by both parties, and two core parts are parsed from the data packet: first, the encapsulated original HTTP request information (including request method, path, request header, request body, etc.); second, the unique request ID associated with the request (e.g., uuid-1234-5678-90ab-cdef12345678).

[0068] After parsing, the intranet RPC service determines the access address of the target intranet application microservice (e.g., http: / / 127.0.0.1:8081 / api / deviceStatus locally) based on pre-configured information or information in the request. Then, the intranet RPC service reassembles the parsed HTTP request information (method, path, headers, payload, etc.) into a new, standard HTTP request and initiates a call to the target intranet application microservice. This process realizes the conversion and forwarding of the request from the intermediary protocol to the internal business protocol.

[0069] After receiving this HTTP request, the intranet application microservice begins to execute its specific business logic (such as querying device status, issuing control commands, and processing data reports). Once processing is complete, the microservice generates business-level response data (usually an HTTP response containing a status code, response headers, and a response body, such as a business result in JSON format).

[0070] A crucial step is that after receiving the original business response from the intranet application microservice, the intranet RPC service needs to generate the final message to be sent back to the relay service. It encapsulates the business response data with the request ID parsed in step 1. That is, the final generated response data must explicitly carry the original request ID. This is the fundamental guarantee for correctly matching requests and responses subsequently.

[0071] Finally, the internal RPC service will return the encapsulated response data carrying the request ID to the relay RPC cloud service through the original communication channel. It calls the channel's send function to write the response data into the channel and send it. Since this channel is a pre-established, point-to-point long-lived connection, the response data can be returned efficiently and reliably along the original path without the need for complex routing.

[0072] At this point, step S5 is complete. The request from the public network has been processed in the secure intranet environment, and the processing result, along with a unique request identifier, is sent back to the relay node, preparing for the final response. This step ensures the isolation of business processing, the traceability of the response, and the stability of the communication path.

[0073] Continue to refer to Figure 1-3 The present invention provides a method for forwarding HTTP requests to an intranet application, which further includes the following steps: S6, the relay RPC cloud service matches the corresponding asynchronous response waiting object based on the request ID in the response data, retrieves the response data from it, and returns the response data to the external client that initiated the HTTP request.

[0074] This step is the final step in completing the entire request-response closed loop. Its core function is to receive the business response from the internal network, accurately locate and wake up the corresponding waiting thread through the request identifier, and finally deliver the processing result to the original requester. The specific implementation process is as follows: The Netty server, acting as a relay RPC cloud service, receives data packets from the internal RPC service via a communication channel. The server first decodes the data packet according to the internal RPC protocol. After decoding, two core pieces of information are extracted: first, business response data generated by the internal application microservice (such as HTTP status codes, response headers, and JSON-formatted response bodies); and second, the request ID encapsulated in the data packet (e.g., UUID-1234-5678-90ab-cdef12345678).

[0075] Based on the parsed request ID, the intermediary RPC cloud service executes a matching process, which specifically includes: Query mapping: Using the parsed request ID as the key, initiate a query to the thread-safe hash mapping structure established in step S43 for storing binding relationships.

[0076] Locating the object: If the request ID exists in the mapping, the corresponding asynchronous response waiting object (i.e., the object created in step S42 to wait for the response to this request) is retrieved. If it is not found, it means that the request may have timed out and been cleaned up. The system will log and discard this response.

[0077] After successfully matching an asynchronous response wait object, the system sets the parsed business response data (e.g., a JSON result indicating success: {"status": "ok", "data": {...}}) into that asynchronous response wait object. This operation immediately releases the object from its associated wait state and wakes up threads that may have been blocked waiting after step S4 due to calling the object's result retrieval method (typically worker threads that handled the original external HTTP request).

[0078] The awakened thread then retrieves the pre-configured response data from the asynchronous response wait object. The intermediary RPC cloud service then reassembles this internal response data into a standard HTTP response message (including status code, response headers, and response body). Finally, this HTTP response is returned to the external client that initiated the HTTP request via the same network connection that initially received the external HTTP request.

[0079] After successfully returning the response to the client, the system removes the binding entry between the request ID and the asynchronous response wait object from the thread-safe hash mapping structure mentioned above, releasing related resources and preventing memory leaks.

[0080] At this point, step S6 is complete. A complete HTTP request forwarding and response loop, initiated by an external client, relayed via the public network, processed within the internal network, and then returned along the same path, is finally achieved. Through the unique identifier of the request ID and the synchronization mechanism of the asynchronous response waiting object, even in a multiplexed, high-concurrency network environment, it can be guaranteed that every response is accurately delivered to the client that initiated the corresponding request, ensuring the reliability and accuracy of the system.

[0081] As an implementation of the above method, the present invention also proposes a system for forwarding HTTP requests to intranet applications, the system comprising: The relay RPC cloud service module is deployed in a public network environment and configured to perform the following operations: Establish a long connection with the intranet RPC service module, receive the intranet device serial number reported by the intranet RPC service module, and bind and store the serial number with the communication channel for establishing the long connection; The system maintains a long-lived connection with the internal network RPC service module through a heartbeat mechanism, and updates the binding relationship based on the re-reported sequence number when the long-lived connection is re-established after an interruption. Receive HTTP requests from external clients, extract the serial number of the intranet device to be accessed from the HTTP request, and query the corresponding communication channel based on the extracted intranet device serial number; Generate a unique request ID for the HTTP request, create an asynchronous response wait object bound to the request ID, and forward the HTTP request through the queried communication channel; Based on the request ID in the response data returned from the internal network, match the corresponding asynchronous response waiting object to obtain the response data, and return the response data to the external client that initiated the HTTP request; The intranet RPC service module, deployed in the intranet environment, is configured to perform the following operations: Establish a long connection with the relay RPC cloud service module and report the internal network device serial number to the relay RPC cloud service module; The long connection is maintained through a heartbeat mechanism, and when the long connection is interrupted, the long connection is re-established with the relay RPC cloud service module and the internal network device serial number is re-reported. The request received through the communication channel is forwarded to the intranet application microservice module, and the response data generated after processing, carrying the request ID, is returned through the original communication channel. The intranet application microservice module is deployed in the intranet environment and communicates with the intranet RPC service module to process received requests and generate response data.

[0082] The present invention also proposes a terminal device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein when the processor executes the computer program, it implements the method steps of forwarding any of the above-described HTTP requests to an intranet application.

[0083] The present invention also proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method steps described above for forwarding an HTTP request to an intranet application.

[0084] The following is for reference. Figure 4 It shows a schematic diagram of the structure of a computer system 400 suitable for implementing terminal devices or servers in the embodiments of this application. Figure 4 The terminal device or server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0085] like Figure 4 As shown, the computer system 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 402 or programs loaded from storage section 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the computer system 400. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0086] The following components are connected to I / O interface 405: input section 406 including keyboard, mouse, etc.; output section 407 including liquid crystal display (LCD) and speakers, etc.; storage section 408 including hard disk, etc.; and communication section 409 including network interface card such as LAN card, modem, etc. Communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from them can be installed into storage section 408 as needed.

[0087] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable medium or any combination thereof. The computer-readable medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable medium that can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0088] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0089] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0090] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for forwarding HTTP requests to an intranet application, characterized in that, Includes the following steps: S1. The intranet RPC service establishes a long connection with the relay RPC cloud service deployed on the public network side, and reports the intranet device serial number to the relay RPC cloud service; the relay RPC cloud service binds and stores the intranet device serial number with the communication channel for establishing the long connection; S2. The intranet RPC service maintains the long connection through a heartbeat mechanism; when the long connection is interrupted, the intranet RPC service re-establishes the long connection with the relay RPC cloud service and re-reports the intranet device serial number so that the relay RPC cloud service updates the binding relationship between the serial number and the communication channel. S3. The relay RPC cloud service receives an HTTP request from an external client, extracts the serial number of the intranet device as the access target from the HTTP request, and queries the corresponding communication channel based on the extracted intranet device serial number. S4. The relay RPC cloud service generates a unique request ID for the HTTP request and creates an asynchronous response wait object bound to the request ID; then, the HTTP request is forwarded to the intranet RPC service through the queried communication channel. S5. The intranet RPC service forwards the received request to the intranet application microservice for processing; After processing, response data carrying the request ID is generated and returned to the relay RPC cloud service through the original communication channel; S6. The relay RPC cloud service matches the corresponding asynchronous response waiting object according to the request ID in the response data, obtains the response data from it, and returns the response data to the external client that initiated the HTTP request.

2. The method for forwarding HTTP requests to an intranet application according to claim 1, characterized in that, In step S1, the intranet RPC service establishes a long connection with the relay RPC cloud service deployed on the public network side, and reports the intranet device serial number to the relay RPC cloud service; the relay RPC cloud service binds and stores the intranet device serial number with the communication channel for establishing the long connection, including the following sub-steps: S11. When the relay RPC cloud service starts, it registers its network address information with the registration center; S12. When the intranet RPC service starts, it queries and obtains the network address information of the relay RPC cloud service from the registration center. S13. The intranet RPC service initiates a connection request to the relay RPC cloud service based on the obtained network address information to establish a long connection; S14. After the long connection is established, the intranet RPC service immediately sends a reporting message containing the intranet device serial number to the relay RPC cloud service through the long connection. S15. The relay RPC cloud service receives the reporting message, parses out the intranet device serial number, and associates the intranet device serial number with the communication channel carrying the reporting message, storing it in a local binding relationship; wherein, associating and storing the serial number with the communication channel specifically involves using a thread-safe key-value mapping container, where the key is the intranet device serial number and the value is a reference to the corresponding communication channel object.

3. The method for forwarding HTTP requests to an intranet application according to claim 1, characterized in that, In step S2, the heartbeat mechanism maintains the long connection, specifically including the following sub-steps: S21. The intranet RPC service sends heartbeat messages to the relay RPC cloud service through the long connection according to a preset time period. S22. After receiving the heartbeat message, the relay RPC cloud service returns an acknowledgment response to the intranet RPC service; S23. Whether the intranet RPC service monitoring receives the confirmation response; If no confirmation response is received within the preset time, the current heartbeat cycle detection is deemed to have failed.

4. The method for forwarding HTTP requests to an intranet application according to claim 3, characterized in that, In step S2, when the long connection is interrupted, the specific judgment conditions are: the intranet RPC service fails to detect for N consecutive heartbeat cycles, and / or the intranet RPC service detects that the IP address of its network environment has changed; where N is an integer greater than 1.

5. The method for forwarding HTTP requests to an intranet application according to claim 1 or 4, characterized in that, In step S2, rebuilding the long connection includes: the intranet RPC service uses a backoff algorithm to control the waiting time for reconnection attempts, and obtains the current network address information of the relay RPC cloud service from the registry center and reconnects during each attempt.

6. The method for forwarding HTTP requests to an intranet application according to claim 1, characterized in that, In step S4, an asynchronous response wait object bound to the request ID is created, including the following sub-steps: S41. The relay RPC cloud service generates a globally unique string for each received HTTP request, which serves as the request ID of the HTTP request; S42. The relay RPC cloud service creates a new asynchronous response waiting object, which is used to block and wait and eventually obtain response data that matches the request ID; S43. The relay RPC cloud service uses the request ID as the key and the asynchronous response waiting object as the value, and stores them in a thread-safe hash mapping structure to complete the binding.

7. The method for forwarding HTTP requests to an intranet application according to claim 1, characterized in that, In step S6, the corresponding asynchronous response waiting object is matched according to the request ID in the response data, including: using the request ID as the key, querying the corresponding asynchronous response waiting object from the thread-safe hash mapping that stores the binding relationship, and setting the response data into the asynchronous response waiting object, thereby releasing its waiting state.

8. A system for forwarding HTTP requests to intranet applications, characterized in that, The system for implementing the method of any one of claims 1 to 7 comprises: The relay RPC cloud service module is deployed in a public network environment and configured to perform the following operations: Establish a long connection with the intranet RPC service module, receive the intranet device serial number reported by the intranet RPC service module, and bind and store the serial number with the communication channel for establishing the long connection; The long connection is maintained with the internal network RPC service module through a heartbeat mechanism, and the binding relationship is updated according to the re-reported sequence number when the long connection is re-established after an interruption. Receive an HTTP request from an external client, extract the serial number of the intranet device to be accessed from the HTTP request, and query the corresponding communication channel based on the extracted intranet device serial number; Generate a unique request ID for the HTTP request, create an asynchronous response wait object bound to the request ID, and forward the HTTP request through the queried communication channel; Based on the request ID in the response data returned from the intranet, match the corresponding asynchronous response waiting object to obtain the response data, and return the response data to the external client that initiated the HTTP request; The intranet RPC service module, deployed in the intranet environment, is configured to perform the following operations: Establish a long connection with the relay RPC cloud service module and report the intranet device serial number to the relay RPC cloud service module; The long connection is maintained through a heartbeat mechanism, and when the long connection is interrupted, the long connection is re-established with the relay RPC cloud service module and the serial number of the intranet device is re-reported. The request received through the communication channel is forwarded to the intranet application microservice module, and the response data generated after processing, carrying the request ID, is returned through the original communication channel. The intranet application microservice module is deployed in the intranet environment and communicates with the intranet RPC service module to process received requests and generate response data.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, When the processor executes the computer program, it implements the method steps of forwarding HTTP requests to an intranet application as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method steps of forwarding an HTTP request to an intranet application as described in any one of claims 1 to 7.

Images