A cross-network request synchronous invocation system based on traffic hijacking and reverse proxy
By using a cross-network request synchronous call system based on traffic hijacking and reverse proxy, and leveraging Netty and exchange proxy for cross-network request synchronous calls, the system solves the problem of large-scale data or interface calls in cross-domain scenarios, and achieves seamless access and simplified cross-network interaction.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING INST OF COMP TECH & APPL
- Filing Date
- 2026-03-18
- Publication Date
- 2026-06-02
AI Technical Summary
Existing technologies cannot quickly achieve large-scale cross-network sending and calling of data or interfaces in cross-domain and cross-center scenarios. Each domain registration and publication is required, resulting in a cumbersome cross-network calling process.
A cross-network synchronous request invocation system based on traffic hijacking and reverse proxy is adopted. Netty is used for request interception and parsing, cross-network infrastructure invocation is carried out through exchange proxy, and request-response matching and reassembly are realized by combining asynchronous programming model.
It enables seamless access and simplified, scalable, and reusable data exchange in cross-network scenarios, simplifying the cross-network calling process.
Smart Images
Figure CN122137884A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer software, specifically relating to a cross-network request synchronous invocation system based on traffic hijacking and reverse proxy. Background Technology
[0002] Currently, the market suffers from insufficient data sharing and exchange methods. Most business information systems across various sectors are independently planned and constructed, resulting in numerous silos and information islands. In situations where network construction or strategies differ across domains and data centers, it's impossible to provide existing data to users with urgent needs in a timely and effective manner. Furthermore, it's difficult to collect desired data into one's own business systems through standardized and effective methods. Therefore, data sharing and exchange platforms have emerged. However, a horizontal comparison of similar products and technologies on the market reveals that most operate in scenarios without cross-network connectivity or rely on existing API registration and mapping methods to wrap the original interfaces. This necessitates domain registration and publishing each time data or services are provided, hindering the rapid large-scale cross-network transmission and invocation of data or interfaces. Therefore, the development process requires finding new technical means and solutions to overcome these technical challenges. Summary of the Invention
[0003] (a) Technical problems to be solved The technical problem this invention aims to solve is how to provide a cross-network request synchronous invocation system based on traffic hijacking and reverse proxy, so as to solve the problem in the prior art that requires domain registration and publication every time data or service is provided, making it impossible to quickly realize large-scale cross-network sending and invocation of data or interfaces.
[0004] (II) Technical Solution To address the aforementioned technical issues, this invention proposes a cross-network request synchronous invocation system based on traffic hijacking and reverse proxy. The system includes: an A-end request interceptor, an A-end request parser, an A-end request encapsulator, an exchange proxy A, an A-end response parser, an A-end response restorer, an exchange proxy B, a B-end request dispatcher, a B-end request parser, a B-end request restorer, a B-end response parser, and a B-end response encapsulator. After a request is initiated, the A-side request interceptor intercepts the request traffic by obtaining inbound data from Netty. The A-side request parser parses the request according to the system standard specifications, and the A-side request encapsulator encapsulates the request protocol and standard data packets. The encapsulated data is then passed to the A-side exchange proxy A for path planning and cross-network infrastructure calls. The cross-network data is then transmitted to the B-side exchange proxy B through the cross-network channel, waking up the B-side request dispatcher. The B-side request dispatcher distributes the data packets uniformly to the message queue according to the standard packet type. The corresponding consumers listen for the specified route messages and then hand them over to the B-side request parser. In conjunction with the B-side request restorer, the request is restored according to the data packet model, and an HTTP request call is made to the business system B. After receiving the request, business system B returns response data. The response protocol, metadata, etc. are parsed and standard data packets are packaged through the B-side response parser and B-side response encapsulator. Cross-network infrastructure calls are made through the B-side switching agent B, and the response data packets are transmitted to the A-side switching agent A through the cross-network channel. On side A, the exchange proxy A unlocks and releases the request thread, realizes request-response matching, and hands the data packet to the response parser on side A. Together with the response restorer on side A, the response is restored according to the data packet model. After encapsulating the real response content into the Response stream, the request complete loop is realized.
[0005] (III) Beneficial Effects This invention proposes a cross-network request synchronous invocation system based on traffic hijacking and reverse proxy. Under existing solutions and technical systems, reverse proxy can be implemented using Nginx, allowing the caller to make server calls without needing to know the specific information of the server. However, Nginx cannot achieve reverse proxying and invocation across network domains or logically isolated data centers. Adding cross-network infrastructure enables cross-network data packet transmission. Supported by this, API interface addresses are registered through service directories or OpenAPI platforms. However, this often requires registering each interface separately for cross-network invocation, which is cumbersome in both form and usage, hindering large-scale cross-network use.
[0006] After using the technology of this invention, a request / response interceptor can be assembled using Netty and Socket to perform global traffic hijacking. The request / response parser and encapsulator can unpack and unpack data. Through the asynchronous programming model of cross-network infrastructure calls via the exchange proxy, the original "request-response" matching is completed. Finally, the original request and response are reassembled in cross-network scenarios by relying on the request / response restorer. This achieves seamless access for both the caller and the service provider, and simplifies, scales, and makes reusable cross-network exchange interaction. Attached Figure Description
[0007] Figure 1 This is a diagram of the overall architecture of the present invention; Figure 2 This is a diagram illustrating the replacement of the request address. Detailed Implementation
[0008] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.
[0009] 1. Overall Architecture Figure 1 This is a diagram of the overall architecture of the present invention, as shown below. Figure 1 As shown, it is divided into: A-side request interceptor, A-side request parser, A-side request encapsulator, exchange proxy A (calling services across network infrastructure to realize cross-network transmission capability), A-side response parser, A-side response restorer, exchange proxy B, B-side request dispatcher, B-side request parser, B-side request restorer, B-side response parser, and B-side response encapsulator.
[0010] After a request is initiated, the A-side request interceptor intercepts the request traffic by obtaining inbound data from Netty. The A-side request parser parses the request according to network request standards and specifications, and the A-side request encapsulator encapsulates the request protocol and standard data packets. The encapsulated data is then passed to the A-side exchange proxy A for path planning and cross-network infrastructure calls. The cross-network data is then transmitted to the B-side exchange proxy B through the cross-network channel, waking up the B-side request dispatcher. The B-side request dispatcher distributes the data packets uniformly to the message queue according to the standard packet type. The corresponding consumers listen for the specified route messages and then hand them over to the B-side request parser. In conjunction with the B-side request restorer, the request is restored according to the data packet model, and an HTTP request is made to the business system B.
[0011] After receiving the request, business system B returns response data. The response protocol, metadata, etc. are parsed and standard data packets are packaged through the B-side response parser and B-side response encapsulator. Cross-network infrastructure calls are made through the B-side switching agent B, and the response data packets are transmitted to the A-side switching agent A through the cross-network channel.
[0012] On side A, the exchange proxy A unlocks and releases the request thread, realizes request-response matching, and hands the data packet to the response parser on side A. Together with the response restorer on side A, the response is restored according to the data packet model. After encapsulating the real response content into the Response stream, the request complete loop is realized.
[0013] 2. Detailed Implementation When establishing a Netty server (listening to the port, accepting connections, and acquiring / processing the transport stream) within the A-side request interceptor, a NioEventLoopGroup (thread pool and Selector) is created, selecting NioServerSocketChannel as the service Socket implementation class, indicating a server-side implementation based on NIO. A ChildHandler is set up to define the handler used for "accepted connections," and a new initialization handler is created. Standard and custom handlers are declared internally, and a Pipeline is used for pipelined configuration of handlers, such as request stream parsing handlers, protocol aggregation handlers, and fragmented write stream handlers. Finally, the business handler (custom business logic, such as subsequent request parsing and request encapsulation logic) is declared, using the processing results of the pre-processor. After the client's SocketChannel establishes a connection, all handlers are initialized.
[0014] (1) A-side request interceptor. The Netty Server is dynamically loaded when the system starts. The business processor inherits the Netty inbound processor and is responsible for handling all events "flowing into" the application, such as reading data from the network and changes in connection status. The internal channelRead() and channelRead0() functions are overridden as functions for reading network inbound data (transmission stream). The ChannelHandlerContext (Netty processor context) and transmission stream are obtained through function parameters to intercept request traffic. After distinguishing between WebSocket and HTTP types based on the obtained transmission stream, the A-side request parser is called, passing in the inbound transmission stream, and executing the parsing logic for specific protocol requests.
[0015] (2) A-side request parser. Converts the inbound transmission stream into the corresponding format under the Netty ecosystem. Taking HTTP protocol request processing as an example, the transmission stream is converted into FullHttpRequest format, and the protocol request is parsed.
[0016] To retrieve the HTTP request headers, the original request headers should include a unique identifier (Code) for both the A and B web-side business systems. This identifier allows you to find the access IP and port of the corresponding business system service. For example... Figure 2As shown, the IP address and port of the B-end business system are obtained and concatenated with the interface request path (original request path) and interface request parameters in the request metadata to form a complete request URI, which is the actual request path of the B-end. The ContentType in the request header is read, and the processing logic of the request parameters and request body is specified according to the ContentType, such as "application / json", "application / x-www-form-urlencoded", "multipart / form-data", etc. The request metadata is then parsed and temporarily stored.
[0017] (3) A-side request wrapper. The request protocol and standard data packets are packaged according to the standard model.
[0018] 1) Request Protocol. The original request header, request body, request method (GET, POST, etc.), and B-end request URL are assembled into a data packet.
[0019] 2) Standard data. Carries necessary configuration information for transmission, such as routing information from end A to end B, and a unique identifier for the request (request ID).
[0020] (4) Switching Proxy. Switching proxy A makes a cross-network infrastructure call and transmits the encapsulated data packet to switching proxy B through the cross-network channel. However, the call only returns the result of the cross-network infrastructure call, not the actual response result of the interface request (B-end interface). In order to ensure that the response of B-end can be directly returned as the response of A-end and realize the seamless call of the entire interface request (cross-network), an asynchronous programming model needs to be used when making cross-network infrastructure calls to perform an asynchronous-to-synchronous operation.
[0021] Using Netty's Promise mechanism, an interface for writing asynchronous operation results is provided. This extends the Future interface by adding methods for setting operation results, thereby enabling proactive control over the completion of asynchronous operations and achieving asynchronous-to-synchronous conversion (blocking and waiting for results). Specifically, a new Promise is created, and the unique ID of the request is bound to the current Promise in key-value pairs in an atomic Map. The current thread is locked, and a timeout of 30 seconds is set.
[0022] (5) B-end request dispatcher. After the cross-network engine is called, the data packet from the A end is transmitted to the B end. The B-end request dispatcher is responsible for receiving the request data packet and distributing it to the message queue according to the routing information for the B-end request parser to consume.
[0023] (6) B-end request parser. The B-end request parser listens to and consumes messages in the message queue, and parses the data packets. It obtains all request headers of the original request, gets all request header metadata key-value pairs, and iterates through them; it obtains the parameters carried in the original request, and if the passed parameters contain a file stream, it takes it out, processes it separately, and reassembles the parameter into MultipartFile.
[0024] (7) B-end request restorer. Obtain the actual request address (including IP, port and interface path) that the B-end needs to call, construct the corresponding HTTP request (Get, Post, etc.) according to the request method parameters carried, and send the HTTP request to the B-end business system B (the called service).
[0025] (8) B-side response parser. The response data of the HTTP request returned by business system B is passed to the B-side response parser, which parses and temporarily stores the metadata of the response.
[0026] (9) B-end response encapsulator. Packetize the request protocol and standard data according to the standard model. Assemble the response header, response body and other contents into a data packet, and assemble the cross-network infrastructure call data packet, carrying the necessary configuration information for cross-network transmission (such as routing information from B-end to A-end, request ID (consistent with the request ID when sending) etc.).
[0027] (10) Switching Agent. The B-end response encapsulator delivers the encapsulated data packet to the switching agent B, which then calls the cross-network infrastructure to realize the transmission of the data packet from the switching agent B to the switching agent A.
[0028] (11) Response parser on end A. Exchange proxy A hands over the response data packet to the response parser on end A for parsing. The parser obtains the request id attribute in the data packet and uses it as the key to retrieve the corresponding Promise from the atomic Map. It then performs a thread wake-up operation, returns the basic response data in the data packet to the blocked thread, realizes request-response matching, and converts asynchronous to synchronous response. Then, it parses the response data, including response header data, response status code, response body data, streaming data, etc.
[0029] (12) A-side response restorer. The response is restored using FullHttpRequest (initial request), Netty processor context, and response data. The response body data is converted into a byte array and written to the context. Together with the HTTP version and response status code, it forms the FullHttpResponse within the Netty ecosystem. Common items are added to the request header. The FullHttpResponse is written to the buffer through the context. Finally, the buffer is flushed to send the data out, achieving a seamless response.
[0030] Under existing solutions and technical frameworks, Nginx can be used for reverse proxying, allowing callers to make server-side calls without needing to know the specific server information. However, Nginx cannot handle reverse proxying and calls across domains or logically isolated data centers. Adding cross-network infrastructure enables cross-network data packet transmission. Supported by this, API interface addresses are registered through service directories or OpenAPI platforms. However, this often requires registering each interface individually for cross-network calls, which is cumbersome in both form and usage, hindering large-scale cross-network deployment.
[0031] After using the technology of this invention, a request / response interceptor can be assembled using Netty and Socket to perform global traffic hijacking. The request / response parser and encapsulator can unpack and unpack data. Through the asynchronous programming model of cross-network infrastructure calls via the exchange proxy, the original "request-response" matching is completed. Finally, the original request and response are reassembled in cross-network scenarios by relying on the request / response restorer. This achieves seamless access for both the caller and the service provider, and simplifies, scales, and makes reusable cross-network exchange interaction.
[0032] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A cross-network request synchronous invocation system based on traffic hijacking and reverse proxy, characterized in that, The system includes: A-side request interceptor, A-side request parser, A-side request encapsulator, exchange proxy A, A-side response parser, A-side response restorer, exchange proxy B, B-side request dispatcher, B-side request parser, B-side request restorer, B-side response parser, and B-side response encapsulator. After a request is initiated, the A-side request interceptor intercepts the request traffic by obtaining inbound data from Netty. The A-side request parser parses the request according to network request standards and specifications. The A-side request encapsulator encapsulates the request protocol and standard data packets. The encapsulated data is then passed to the A-side exchange proxy A for path planning and cross-network infrastructure calls. The cross-network data is then transmitted to the B-side exchange proxy B through the cross-network channel, waking up the B-side request dispatcher. The B-side request dispatcher distributes the data packets uniformly to the message queue according to the standard packet type. The corresponding consumers listen for the specified route messages and then hand them over to the B-side request parser. In conjunction with the B-side request restorer, the request is restored according to the data packet model, and an HTTP request is made to the business system B. After receiving the request, business system B returns response data. The response protocol, metadata, etc. are parsed and standard data packets are packaged through the B-side response parser and B-side response encapsulator. Cross-network infrastructure calls are made through the B-side switching agent B, and the response data packets are transmitted to the A-side switching agent A through the cross-network channel. On side A, the exchange proxy A unlocks and releases the request thread, realizes request-response matching, and hands the data packet to the response parser on side A. Together with the response restorer on side A, the response is restored according to the data packet model. After encapsulating the real response content into the Response stream, the request complete loop is realized.
2. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 1, characterized in that, When establishing a Netty server within the request interceptor on side A, a NioEventLoopGroup (thread pool and Selector) is created, and NioServerSocketChannel is selected as the service Socket implementation class, indicating a server-side implementation based on NIO. A ChildHandler is set up to define the handler used for "connection accepted," and a new initialization handler is created. Standard and custom handlers are declared internally, and a Pipeline is used for pipelined configuration of the handlers. Finally, the business handler is declared, using the processing results of the previous handler. After the client SocketChannel establishes a connection, all handlers are initialized.
3. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 2, characterized in that, The implementation of the A-side request interceptor includes: dynamically loading the Netty Server when the system starts; the business processor inherits from the Netty inbound processor, which is responsible for handling data reading from the network and connection status change events; overriding the internal channelRead() and channelRead0() functions as functions for reading inbound network data; obtaining the ChannelHandlerContext and transport stream through function parameters; and intercepting request traffic; after distinguishing between WebSocket and HTTP types based on the obtained transport stream, calling the A-side request parser, passing in the inbound transport stream, and executing the parsing logic for specific protocol requests.
4. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 3, characterized in that, The implementation of the A-side request parser includes: converting the inbound transport stream to the corresponding format under the Netty ecosystem; for HTTP protocol request processing, converting the transport stream to FullHttpRequest format and parsing the protocol request; obtaining the HTTP request header, which needs to carry the unique identifier code (Code) of the A and B-side business systems in the request header, and finding the access IP and port of the corresponding business system service through the identifier code; obtaining the IP and port of the B-side business system, and concatenating it with the interface request path and interface request parameters in the request metadata to form a complete request URI, i.e., the actual request path of the B-side; reading the ContentType in the request header, specifying the processing logic of the request parameters and request body through the ContentType, and parsing and temporarily storing the request metadata.
5. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 4, characterized in that, The A-side request wrapper encapsulates the request protocol and standard data packets according to the standard model. 1) Request Protocol: Assemble the original request headers, request body, request method, and B-end request URL into a data packet; 2) Standard data: Carries necessary configuration information for transmission, including routing information from end A to end B, and requests a unique identifier.
6. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 5, characterized in that, Exchange agent A makes cross-network infrastructure calls, transmitting the encapsulated data packets to exchange agent B through the cross-network channel. Using Netty's Promise mechanism, an interface for writing asynchronous operation results is provided. The Future interface is extended to add methods for setting operation results, thereby enabling proactive control over the completion of asynchronous operations and achieving asynchronous-to-synchronous conversion. A new Promise is created, and the unique ID of the request is bound to the current Promise in key-value pairs in an atomic Map. The current thread is locked, and a timeout of 30 seconds is set.
7. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 6, characterized in that, After the cross-network engine is called, the data packet from end A is transmitted to end B. The request dispatcher on end B is responsible for receiving the request data packet and distributing it to the message queue according to the routing information for consumption by the request parser on end B. The B-side request parser listens to and consumes messages in the message queue, parses the data packets, obtains all request headers of the original request, gets all request header metadata key-value pairs, and iterates through them; it also obtains the parameters carried in the original request, and if the parameters passed contain a file stream, it extracts it, processes it separately, and reassembles the parameter into a MultipartFile.
8. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 7, characterized in that, The B-end request restorer obtains the actual request address that the B-end needs to call, constructs the corresponding HTTP request based on the request method parameters carried, and sends the HTTP request to the B-end business system B.
9. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 8, characterized in that, The response data of the HTTP request returned by business system B is passed to the response parser on the B side, and the metadata of the response is parsed and temporarily stored. The B-end response wrapper encapsulates request protocols and standard data packets according to the standard model. The response header and response body are assembled into a data packet, and a cross-network infrastructure call data packet is assembled, carrying the necessary configuration information for cross-network transmission; The B-end response encapsulator delivers the encapsulated data packet to the switching agent B, which then invokes the cross-network infrastructure to transmit the data packet from the switching agent B to the switching agent A.
10. The cross-network request synchronous invocation system based on traffic hijacking and reverse proxy as described in claim 9, characterized in that, Exchange agent A hands over the response data packet to the response parser on side A for parsing. The parser obtains the request id attribute in the data packet and uses it as the key to retrieve the corresponding Promise from the atomic Map. It then performs a thread wake-up operation and returns the basic response data in the data packet to the blocked thread, thus achieving request-response matching and converting asynchronous to synchronous response. Then the response data is parsed, including the response header data, response status code, response body data, and streaming data; The A-side response restorer restores the response using FullHttpRequest, the Netty processor context, and the response data. It converts the response body data into a byte array and writes it into the context, which, together with the HTTP version and response status code, forms the FullHttpResponse within the Netty ecosystem. It also adds common items to the request headers, writes the FullHttpResponse into the buffer through the context, and finally flushes the buffer to send the data out, achieving a seamless response.