Method, system and storage medium for communication connection based on multiplexing tunnels

Abstract

Embodiments of the present application disclose a communication connection method and system based on multiplexing tunnels, an electronic device and a storage medium. The method comprises: a WebSocket proxy service module responding to a WebSocket connection request initiated by a client, calling an external contract interface for dynamic addressing, and sending a dynamic addressing result to a stub module; the stub module creating a new user flow on an existing public network multiplexing tunnel with a proxy module based on the dynamic addressing result, and sending a signal containing the new user flow to the proxy module; and the proxy module initiating a local TCP connection request to a service module after receiving the signal containing the new user flow, using a local loop network segment multi-IP address polling binding technology, so that the service module establishes a local TCP connection with the proxy module based on the local TCP connection request. Through the above method, the service service can adapt to WebSocket access without modifying the original service code.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a communication connection method, system, electronic device, and storage medium based on multiplexing tunnels. Background Technology

[0002] With the rapid popularization of real-time communication services, the WebSocket protocol has become a core communication carrier for scenarios such as instant messaging, market data push, collaborative office work, and IoT data reporting. These services are generally characterized by large connection volume, a high proportion of long-lived connections, and dynamic scaling of service nodes. In actual implementation, traditional WebSocket proxy architectures have gradually revealed many pain points that are difficult to adapt to. Summary of the Invention

[0003] In view of the above problems, embodiments of this application propose a communication connection method, system, electronic device, and storage medium based on multiplexing tunnels to improve the above problems.

[0004] In a first aspect, embodiments of this application provide a communication connection method based on a multiplexed tunnel, applied to a communication connection system. The communication connection system includes a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module. The method includes: the WebSocket proxy service module responding to a WebSocket connection request initiated by a client calls an external contract interface to perform dynamic addressing and sends the dynamic addressing result to the stub program module; the stub program module, based on the dynamic addressing result, opens a new user stream on an existing public network multiplexed tunnel with the proxy program module and sends a signal containing the new user stream to the proxy program module; after receiving the signal containing the new user stream, the proxy program module initiates a local TCP connection request to the business service module using a local loopback network segment multi-IP address round-robin binding technology, so that the business service module establishes a local TCP connection with the proxy program module based on the local TCP connection request.

[0005] Secondly, embodiments of this application provide a communication connection system based on a multiplexed tunnel. The communication connection system includes a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module. The WebSocket proxy service module is used to respond to a WebSocket connection request initiated by a client, call an external contract interface for dynamic addressing, and send the dynamic addressing result to the stub program module. The stub program module is used to, based on the dynamic addressing result, open a new user stream on the existing public network multiplexed tunnel with the proxy program module, and send a signal containing the new user stream to the proxy program module. Upon receiving the signal containing the new user stream, the proxy program module is used to initiate a local TCP connection request to the business service module using a local loopback network segment multi-IP address round-robin binding technology, so that the business service module establishes a local TCP connection with the proxy program module based on the local TCP connection request.

[0006] Thirdly, embodiments of this application provide an electronic device, including one or more processors and a memory; one or more programs are stored in the memory and configured to be executed by the one or more processors to implement the above-described method.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, wherein the above-described method is executed when the program code is run by a processor.

[0008] Fifthly, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described method.

[0009] This application provides a communication connection method, system, electronic device, and storage medium based on a multiplexed tunnel. The WebSocket proxy service module responds to a WebSocket connection request initiated by a client, calls an external contract interface for dynamic addressing, and sends the dynamic addressing result to the stub program module. Based on the dynamic addressing result, the stub program module opens a new user stream on the existing public network multiplexed tunnel with the proxy program module and sends a signal containing the new user stream to the proxy program module. After receiving the signal containing the new user stream, the proxy program module uses local loopback network segment multi-IP address round-robin binding technology to initiate a local TCP connection request to the business service module, so that the business service module establishes a local TCP connection with the proxy program module based on the local TCP connection request. Using the above methods, dynamic addressing is achieved by calling external contract interfaces, which can flexibly adapt to the scaling up and down of backend business services and node migration scenarios without modifying the proxy layer configuration, greatly improving the flexibility of service deployment and the scalability of the architecture. New user streams are opened on existing public network multiplexing tunnels, eliminating the need to establish a separate public network connection for each user, greatly reducing public network connection handshake overhead, reducing server resource consumption, and improving cross-network transmission efficiency. The use of local loopback network segment multi-IP address round-robin binding technology to initiate connections can break through the local port number limit, greatly increasing the number of local TCP connections that a single proxy node can handle concurrently, while achieving traffic load balancing and avoiding single IP connection limit issues. The proxy program uses local loopback multi-IP round-robin binding to initiate TCP connections, allowing business services to perceive it as a standard local client request, and adapting to WebSocket access without modifying the original business code. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This illustration shows an application scenario diagram of a communication connection method based on multiplexing tunnels proposed in an embodiment of this application; Figure 2 A flowchart of a communication connection method based on a multiplexed tunnel according to an embodiment of this application is shown; Figure 3 A schematic diagram of the process described in S110-S130 in one embodiment of this application is shown; Figure 4 A flowchart of a communication connection method based on multiplexing tunnels according to another embodiment of this application is shown; Figure 5 A schematic diagram of the process described in S240-S260 in another embodiment of this application is shown; Figure 6 A flowchart of a communication connection method based on multiplexing tunnels according to another embodiment of this application is shown; Figure 7 This illustration shows a schematic diagram of the process described in S340-S360 in yet another embodiment of this application; Figure 8 A flowchart of a communication connection method based on multiplexing tunnels according to another embodiment of this application is shown; Figure 9 This paper shows a structural block diagram of a communication connection system based on a multiplexed tunnel according to an embodiment of this application; Figure 10 shows a structural block diagram of an electronic device for performing a communication connection method based on multiplexing tunnels according to an embodiment of the present application. Figure 11 This application shows a storage unit for storing or carrying program code that implements a communication connection method based on multiplexing tunnels according to embodiments of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0013] With the rapid popularization of real-time communication services, the WebSocket protocol has become a core communication carrier for scenarios such as instant messaging, market data push, collaborative office work, and IoT data reporting. These services are generally characterized by large connection volume, a high proportion of long-lived connections, and dynamic scaling of service nodes. In actual implementation, traditional WebSocket proxy architectures have gradually revealed many pain points that are difficult to adapt to.

[0014] Most current mainstream WebSocket proxy solutions adopt a fixed address configuration mode. The static IP and port information of the backend business service are pre-written before the proxy service starts, which can only connect to backend nodes with completely fixed deployment locations. When the business needs to dynamically scale according to traffic load, or when service nodes drift in containerized deployment scenarios, the statically configured proxy service cannot automatically detect the backend address change. The configuration must be manually modified and the service restarted. This not only interrupts the running long-lived connection, but also brings a lot of maintenance costs. It is completely unsuitable for the needs of elastic service scheduling in cloud-native environments.

[0015] Meanwhile, traditional proxy architectures establish a separate public TCP channel for each client WebSocket connection. In high-concurrency scenarios, a large number of independent public network connections quickly consume server port resources and connection limits, and also incur overhead from repeated TCP handshakes and TLS negotiations, resulting in low public network transmission efficiency and severely limiting the carrying capacity of a single proxy node. Some solutions that attempt to introduce multiplexing mechanisms mostly adopt the mode of building new independent tunnels, which cannot quickly open up user traffic on existing stable public network tunnels, resulting in extremely low tunnel resource reuse rates.

[0016] In addition, when a regular proxy service initiates a TCP connection to a local business service, it binds to only a single local loopback address by default. Due to the limitations of the operating system's port range, a single process can only establish a maximum of about 60,000 TCP connections. In business scenarios with tens of thousands or even hundreds of thousands of WebSocket long connections, the number of connections of a single proxy node can easily reach its limit. It is necessary to deploy a large number of proxy instances to support the business, which significantly increases the cost of server resource investment.

[0017] Therefore, the inventors have proposed a method, system, electronic device, and storage medium for communication connections based on multiplexed tunnels in this application. The WebSocket proxy service module responds to a WebSocket connection request initiated by a client, calls an external contract interface for dynamic addressing, and sends the dynamic addressing result to the stub program module. Based on the dynamic addressing result, the stub program module opens a new user stream on the existing public network multiplexed tunnel with the proxy program module and sends a signal containing the new user stream to the proxy program module. After receiving the signal containing the new user stream, the proxy program module uses local loopback network segment multi-IP address round-robin binding technology to initiate a local TCP connection request to the business service module, so that the business service module establishes a local TCP connection with the proxy program module based on the local TCP connection request. Through the above method, the proxy program initiates a TCP connection using local loopback multi-IP round-robin binding, allowing the business service to perceive it as a standard local client request, thus adapting to WebSocket access without modifying the original business code.

[0018] The communication connection method based on multiplexing tunnels provided in this application can be applied to, for example... Figure 1 The communication connection system 100 shown may include a boundary connection layer 110, a WebSocket proxy service module 120, a stub program module 130, a distributed coordination center module (Etcd) 140, an agent program module (including a firewall synchronization protection module) 150, and a business service module 160.

[0019] The boundary connection layer 110 includes a reverse proxy server, which is used to receive WebSocket long connection requests initiated by public network clients and perform TLS encryption, decryption and offloading on the long connection requests.

[0020] The WebSocket proxy service module 120 has a built-in application layer flow control component, which is used to receive and manage WebSocket connections forwarded by the boundary connection layer 110, and to initiate addressing requests to external services through a standard HTTP RESTful interface to obtain dynamic routing information during the connection establishment phase. The Stub program module 130 and the WebSocket proxy service module 120 are deployed in the same local area network, and the two exchange raw binary data streams on an equal basis through a local inter-process communication mechanism.

[0021] The distributed coordination center module 140 is used to centrally store the static whitelist of source IPs of legally authorized Stub program modules 130, and provides key-value dynamic registration, lease maintenance and change notification services.

[0022] Agent program module 150 is deployed on the server where the remote business service is located. It is connected to the Stub program module 130 through a public QUIC tunnel and is used to receive and parse multiplexed stream data in the QUIC tunnel.

[0023] Business service module 160, as the actual binary business service process in the backend, has its socket listening address forcibly limited to the local loopback address 127.0.0.1.

[0024] The server hosting the Agent program module has a resident firewall synchronization guardian module that monitors changes in the Stub registration status of the distributed coordination center module in real time and dynamically modifies the server's kernel-mode packet filtering firewall rules based on these changes.

[0025] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0026] Please see Figure 2This application provides a communication connection method based on a multiplexed tunnel, applied to a communication connection system. The communication connection system includes a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module. The method includes: S110: The WebSocket proxy service module responds to the WebSocket connection request initiated by the client by calling the external contract interface to perform dynamic addressing and sending the dynamic addressing result to the stub module.

[0027] In this embodiment, the WebSocket connection request is an HTTP handshake request initiated by the client with an Upgrade: websocket header. The external contract interface is a predefined set of independent HTTP RESTful interfaces provided by the scheduling / addressing service. The WebSocket proxy service module receives the routing decision result by passing the client context parameters in the agreed format, thus decoupling the access layer from the routing layer. Dynamic addressing is the process by which the scheduling service calculates the optimal forwarding target (i.e., determines the target stub module) in real time based on rules such as client identity, business type, and backend agent load after the WebSocket proxy service module calls the external contract interface, replacing the static routing configuration of traditional fixed proxies. The dynamic addressing result is structured data returned by the external contract interface, containing core information such as the target agent's (i.e., the target stub module's) identifier, public access address, and a dedicated dynamic token (used for subsequent authentication and preventing unauthorized access). This serves as the legal basis for the subsequent stub module to open a QUIC user flow.

[0028] Specifically, when a client initiates a WebSocket connection request, the WebSocket proxy service module, acting as the entry gateway, first intercepts the request. At this point, the connection is not yet fully established (it is in the handshake phase), so the WebSocket proxy service module suspends the standard protocol upgrade process and instead enters the addressing decision phase.

[0029] When the WebSocket proxy service module receives a WebSocket connection request from a client, it does not directly decide which backend to forward the traffic to. Instead, it calls an external HTTPRESTful contract interface to perform dynamic addressing and obtain the result. Once the WebSocket proxy service module obtains the dynamic addressing result, it does not directly establish a data channel with the target stub module. Instead, it sends the dynamic addressing result to the stub module, enabling the stub module to establish a data channel based on this result.

[0030] S120: Based on the dynamic addressing result, the stub program module opens a new user flow on the existing public network multiplexing tunnel with the agent program module, and sends a signal containing the new user flow to the agent program module.

[0031] In this embodiment, the existing public network multiplexing tunnel refers to the underlying public network multiplexing tunnel (such as a QUIC connection) already established by the stub program module and the proxy program module. In this embodiment, a public network QUIC connection has been pre-established between the stub program module and the proxy program module; this is a persistent, multiplexing-supporting underlying tunnel. The newly created user stream refers to a dedicated QUIC Stream opened on the existing public network multiplexing tunnel. It is a dedicated data carrier for a single WebSocket connection, carrying all business data packets for that user. The traffic of different WebSocket users is naturally isolated through different Stream IDs, eliminating the need to establish a separate public network connection for each user, significantly reducing handshake latency and public network resource consumption.

[0032] After receiving the dynamic addressing result, the stub module can check whether a low-level public network multiplexing tunnel has been established between the local machine and the stub module based on the dynamic addressing result. If the tunnel exists, the stub module uses the returned dynamic addressing result to open a new QUIC Stream on that tunnel. Then, the stub module sends a "channel ready" signal to the WebSocket proxy service module, or directly maps the newly established Stream handle to the current WebSocket session ID.

[0033] Once the stub module confirms that the underlying data channel (QUIC Stream) is ready, the WebSocket proxy service module returns 101 Switching Protocols to the client, formally establishing the WebSocket connection. Afterward, data sent by the client via WebSocket is transparently forwarded by the WebSocket proxy service module to the stub, and then transmitted to the target Agent via the established QUIC Stream.

[0034] Optionally, once the QUIC Stream is successfully established and the WS connection handshake is complete, the Stub program module and the Agent program module perform Layer 4 stateless blind transmission when transmitting data through the public network QUIC tunnel. The Stub program module and the Agent program module only read the length field in the header of the raw binary data packet to perform streaming packet splitting and forwarding, without deserializing or parsing the specific application layer protocol packet body. The meaning of Layer 4 blind transmission is as follows: Stateless: The Stub and Agent modules do not maintain application-layer session state (such as HTTP Header, JSON fields, etc.); they only care about the movement of data packets.

[0035] No business protocol parsing: Regardless of whether the upper layer runs WebSocket, gRPC, or a custom binary protocol, neither the Stub program module nor the Agent program module performs parsing. This significantly reduces the computational overhead of the proxy module and improves throughput.

[0036] Forwarding based on the Length field: This is the key to streaming forwarding. Since business semantics are not parsed, the Stub program module and the Agent program module rely on the length field (Length Prefix) inherent in the data packet to define message boundaries.

[0037] For example: read the first 4 bytes to get the length N, then read the exact N bytes of data and push them unchanged to the QUIC Stream or WS connection on the other end.

[0038] This mechanism ensures data integrity and order, while also achieving protocol independence.

[0039] S130: After receiving the signal containing the newly created user flow, the proxy module initiates a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology, so that the service module establishes a local TCP connection with the proxy module based on the local TCP connection request.

[0040] In this embodiment, when the proxy module initiates a connection to the service module, it employs a local loopback network segment multi-IP address round-robin binding technology. The specific steps include: constructing a local virtual loopback source IP address pool consisting of addresses from 127.0.0.1 to 127.0.0.254 within the proxy module; whenever a new user stream signal is received from the QUIC tunnel, selecting a local virtual source IP address from the address pool using a round-robin or weighted random algorithm; before initiating a connection to the local TCP port of the service module by calling the system connect interface, explicitly calling the system bind interface to lock the selected local virtual source IP address. By dynamically changing the source IP variable in the TCP quadruple, the number of concurrent local TCP connections on a single machine can break through the physical constraint of 65535 temporary ports per IP address. For example, in order to enable a single business server to handle far more than 65535 concurrent TCP long connections, in this embodiment, when the Agent program module receives a new user session instruction (carrying a specific targetServicePort) sent by the Stub program module through the public network QUIC tunnel, the Agent program module executes the following socket control sequence in user space: 1. The program initializes a local loopback virtual IP array: local_ips = ["127.0.0.1", "127.0.0.2", ..., "127.0.0.254"].

[0041] 2. Read the global mutex auto-incrementing counter index value: current_index.

[0042] 3. Select the source IP for this local TCP connection based on the index: selected_src_ip = local_ips[current_index].

[0043] 4. Call the system's native interface to create a standard TCP socket file descriptor: client_fd = socket(AF_INET, SOCK_STREAM, 0).

[0044] 5. Explicitly call the system's bind interface to lock its source IP address and set the port parameter to 0: bind(client_fd, &selected_src_ip, 0). Setting the port to 0 here instructs the operating system kernel to automatically allocate an available temporary port (typically in the range of 32768~60999) under the currently selected 127.0.0.x local virtual IP.

[0045] 6. Call the system connect interface to initiate a standard TCP connection to the actual binary business service: connect(client_fd, "127.0.0.1", targetServicePort).

[0046] 7. Release the mutex and update the global auto-incrementing index: current_index = (current_index + 1) %254.

[0047] Since a TCP connection is uniquely determined by the four-tuple of "source IP, source port, destination IP, and destination port", this invention increases the maximum concurrent connection capacity to the same local business service port by 254 times by dynamically changing the source IP variable in the four-tuple, thus eliminating the physical constraint of 60,000 long connections on a single machine.

[0048] For example, the process described in S110-S130 can be as follows: Figure 3 As shown.

[0049] This embodiment provides a communication connection method based on multiplexed tunnels. The proxy program initiates a TCP connection by using local loopback multi-IP polling binding, so that the business service perceives it as a standard local client request, and can adapt to WebSocket access without modifying the original business code.

[0050] Please see Figure 4 This application provides a communication connection method based on a multiplexed tunnel, applied to a communication connection system. The communication connection system includes a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module. The method includes: S210: The WebSocket proxy service module responds to the WebSocket connection request initiated by the client by calling the external contract interface to perform dynamic addressing and sending the dynamic addressing result to the stub module.

[0051] S220: Based on the dynamic addressing result, the stub program module opens a new user flow on the existing public network multiplexing tunnel with the agent program module, and sends a signal containing the new user flow to the agent program module.

[0052] S230: After receiving the signal containing the newly created user flow, the proxy module initiates a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology, so that the service module establishes a local TCP connection with the proxy module based on the local TCP connection request.

[0053] S240: When the client is in a disconnected state, the WebSocket proxy service module sends a socket close event to the stub module.

[0054] In this embodiment, the client being in a disconnected state can be understood as a brief network outage or disconnection. A socket close event refers to a TCP disconnection or WS closure.

[0055] When a client is detected to be disconnected, the WebSocket proxy service module captures the socket close event and notifies the stub module via inter-process communication.

[0056] S250: The stub module sends a RESET_STREAM status frame to the agent module based on the socket close event.

[0057] In this embodiment, the RESET_STREAM status frame is a control instruction in the QUIC protocol used to force the immediate termination of a specified data stream.

[0058] After the stub module detects the socket close event, it calls the QUIC underlying API to send a RESET_STREAM status frame to the proxy module.

[0059] S260: Based on the RESET_STREAM state frame, the agent module parses the mapping table to close the local file descriptor corresponding to the RESET_STREAM state frame, and drives the service module to release user memory after reading the EOF signal.

[0060] In this embodiment, the mapping table refers to a key data structure maintained in the memory of the agent program module, which records the one-to-one correspondence between QUIC Stream IDs and local TCP file descriptors (FDs). It serves as a bridge connecting the "upper-layer QUIC tunnel stream" and the "lower-layer local service connection," ensuring that the agent program module can accurately locate the specific service connection that needs to be closed.

[0061] A local file descriptor is a unique integer identifier assigned by the operating system kernel to each TCP connection established between the agent module and the local business service module.

[0062] The EOF signal indicates a "0-byte" status returned by the kernel when a service module attempts to read data from a closed TCP socket. It is the standard way for a service module to detect a connection failure and trigger subsequent memory cleanup logic.

[0063] Specifically, when an external client experiences a brief network outage, it causes the underlying socket of the WebSocket proxy service module to report an error or receive a FIN / RST packet. The WebSocket proxy service module captures this shutdown event and immediately notifies the stub module via efficient inter-process communication.

[0064] Then the stub module calls the QUIC underlying API to send a RESET_STREAM status frame to the agent module.

[0065] After receiving the RESET_STREAM status frame, the agent module extracts the Stream ID, queries the mapping table to find the corresponding file descriptor for the local TCP connection, and then executes the close() system call on that file descriptor.

[0066] When the business service module polls or blocks to read the socket, if it finds that the connection has been closed and the read operation returns 0 bytes, it receives an EOF signal. Based on the EOF, the business service module determines that the session has ended and immediately releases the heap memory, context object, database handle, and other resources allocated to that user.

[0067] For example, the process described in S240-S260 can be as follows: Figure 5 As shown. When the front-end user's network experiences a brief interruption, the boundary access layer (Nginx) detects the abnormal closure of the WebSocket and triggers a disconnection signal from the reverse proxy. The WebSocket proxy service module captures the socket closure event and immediately sends a release notification, carrying the user's WS_Session_ID, to the Stub program module in the same data center via Unix Domain Socket inter-process communication. The Stub program module retrieves its internal state mapping table, calls the QUIC underlying API, and sends a RESET_STREAM status frame to the dedicated QUIC Stream corresponding to the user session. Upon receiving this frame, the network driver of the remote Agent program module interrupts the user space blocking. Based on its internally maintained QUIC_Stream_ID ⟷ Local_TCP_Socket_FD mapping table, the Agent immediately calls the system call close(Local_TCP_Socket_FD) for the corresponding local file descriptor. Due to this call, the local business service module immediately reads the EOF zero-byte signal on its corresponding TCP connection, thereby triggering its internal player offline and memory cleanup logic. The entire zombie connection is cleanly destroyed within milliseconds.

[0068] This embodiment provides a communication connection method based on multiplexed tunnels, which realizes full-link automatic recycling from front-end disconnection to back-end memory release, preventing server-side memory leaks or connection accumulation caused by abnormal client disconnection.

[0069] Please see Figure 6 This application provides a communication connection method based on a multiplexed tunnel, applied to a communication connection system. The communication connection system includes a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module. The method includes: S310: The WebSocket proxy service module responds to the WebSocket connection request initiated by the client by calling the external contract interface to perform dynamic addressing and sending the dynamic addressing result to the stub module.

[0070] S320: Based on the dynamic addressing result, the stub program module opens a new user flow on the existing public network multiplexing tunnel with the agent program module, and sends a signal containing the new user flow to the agent program module.

[0071] S330: After receiving the signal containing the newly created user flow, the proxy module initiates a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology, so that the service module establishes a local TCP connection with the proxy module based on the local TCP connection request.

[0072] S340: When the business service module triggers the local TCP connection to disconnect, the proxy program module reads the EOF signal on the local TCP connection, releases the corresponding local source IP address and port, and sends a new user flow closing signal to the stub program module.

[0073] In this embodiment, the business service module process unexpectedly exits or crashes. In this case, the operating system kernel automatically closes all file descriptors held by that process.

[0074] As a TCP client, the proxy module detects that the peer (business service) has been closed when listening to or reading the corresponding local TCP connection, and thus reads the EOF (End Of File) signal (i.e., read returns 0).

[0075] After the agent module detects the EOF signal, it immediately executes close() to close the local socket.

[0076] As we know, due to the previous use of the "local loopback multi-IP address round-robin binding" technology, the proxy module must explicitly release the virtual source IP and port combination occupied by the connection. This step is crucial; it returns the four-tuple to the address pool, ensuring that subsequent new requests can reuse these limited local network resources and preventing resource leaks due to crashes.

[0077] While releasing local resources, the proxy module sends a new user stream close signal (usually a STOP_SENDING or RESET_STREAM frame in the QUIC protocol, or a custom close command at the application layer) to the stub module on the other end through the existing public QUIC multiplexed connection.

[0078] S350: After the stub module captures the closed signal of the newly created user stream, it notifies the WebSocket proxy service module.

[0079] In this embodiment, after the stub module captures the new user stream closing signal from the proxy module, it immediately notifies the WebSocket proxy service module through an efficient inter-process communication mechanism.

[0080] In this step, the stub module is responsible for data plane state synchronization, while the WebSocket proxy service module handles control plane signaling. This decoupling ensures that control signaling can be transmitted quickly even when the data plane is busy.

[0081] S360: The WebSocket proxy service module sends a WebSocket close frame with a business-defined status code to the client and disconnects the connection.

[0082] In this embodiment of the application, after receiving the notification, the WebSocket proxy service module constructs a standard WebSocket Close frame and sends it to the client.

[0083] The WebSocket close frame carries a specific status code defined by the business logic (e.g., 4001: BackendService Crashed). This differs from a normal network error; it clearly informs the client that the disconnection is due to a "backend service error," rather than network fluctuations or proxy failure.

[0084] After sending the WebSocket Close frame, the WebSocket proxy service module officially closes the WebSocket connection with the client, completing the cleanup of the entire chain.

[0085] For example, the process described in S340-S360 can be as follows: Figure 7As shown. When the backend binary service process unexpectedly exits or crashes, its listening local socket closes. The Agent program module instantly reads the EOF signal on the local TCP connection, immediately releases the corresponding local 127.0.0.x virtual port, and sends a stream close signal (FIN frame) to the corresponding public network QUIC Stream. The Stub program module captures this signal on the public network side and notifies the WebSocket proxy service module via local IPC through UDS (Unix DomainSocket). The WebSocket proxy service module immediately assembles a WebSocket Close frame with a business-defined specific status code and pushes it to the client, then actively disconnects from the reverse proxy server, completing the back-to-foreign cascading self-healing process.

[0086] This embodiment provides a communication connection method based on multiplexed tunnels. By "customizing specific status codes," the system transforms the underlying "process crash" into an application-layer-understandable "business error." The client can execute specific retry strategies (such as delayed retry, server switching, or prompting the user) based on the status code, instead of blindly reconnecting.

[0087] Please see Figure 8 This application provides a communication connection method based on multiplexed tunnels, applied to a communication connection system. The communication connection system includes a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module. The communication connection system also includes a distributed coordination center. The method includes: S410: The stub program module sends a registration request to the distributed coordination center.

[0088] In this embodiment of the application, the registration request is a request sent by the stub module to the distributed coordination center for legal verification.

[0089] In one approach, the stub module sends a registration request to the distributed coordination center, including: dynamically generating a temporary public key and a temporary private key when the stub module starts, using a preset management terminal registration public key, performing asymmetric encryption on the registration request containing the temporary public key and device identity credentials, and sending the encrypted registration request to the distributed coordination center.

[0090] Among them, the device identity credential is a unique identifier and a pre-shared secret (such as a Secret Key or certificate) of the stub module, used to prove "who I am".

[0091] First, the operations and maintenance team configures a whitelist of legitimate authorized source IPs in the distributed coordination center in advance, and the management team registers public / private keys.

[0092] Before each registration attempt, the stub module dynamically generates a temporary public and private key pair in memory. Then, using the pre-installed management registration public key in the code or configuration, the stub module performs asymmetric encryption on the registration request, resulting in an encrypted registration request that is then sent to the distributed coordination center.

[0093] S420: When the distributed coordination center receives the registration request, it executes a two-way identity access process based on an asymmetric encryption algorithm to determine whether the stub program module has been successfully registered.

[0094] In one approach, upon receiving the registration request, the distributed coordination center executes a two-way identity access process based on an asymmetric encryption algorithm to determine whether the stub module has successfully registered. This process includes: the distributed coordination center decrypting the encrypted registration request and extracting the temporary public key and the device identity credential; the distributed coordination center verifying the stub module's identity based on the device identity credential and generating a response plaintext containing a timed tunnel token; the response plaintext undergoing secondary asymmetric encryption based on the temporary public key and then being sent back to the stub module; the stub module decrypting the received response ciphertext based on the temporary private key and extracting the timed tunnel token; activating the construction and communication permissions of the multiplexed tunnel based on the timed tunnel token; and confirming that the stub module has successfully registered.

[0095] In this embodiment, upon receiving an encrypted registration request, the distributed coordination center decrypts the request using its locally held management terminal registration private key, extracting the device identity credential and temporary public key. The extracted device identity credential is then compared with a pre-configured whitelist of legitimate authorized source IPs to determine if the stub module's source IP is within this whitelist. If so, the verification passes, and a response plaintext containing a dynamic time-limited tunnel token is generated. Furthermore, the distributed coordination center can perform secondary asymmetric encryption on this response plaintext based on the extracted temporary public key before sending it back to the stub module.

[0096] After receiving the ciphertext of the response, the stub program module decrypts the received ciphertext using the temporary private key in memory, extracts the dynamic time-limited tunnel token, and activates the construction and communication permissions of the multiplexed tunnel accordingly, thus completing the entire registration process.

[0097] Alternatively, the proxy module includes a firewall synchronization guardian module. When the distributed coordination center receives the registration request, it executes a two-way identity access process based on an asymmetric encryption algorithm. After determining whether the stub module has successfully registered, the process further includes: the firewall synchronization guardian module monitoring event changes in the distributed coordination center via a long connection; when the firewall synchronization guardian module captures a successful registration event of the stub module, it resolves the real physical IP address of the stub module in user space and dynamically adds an allow rule for the real physical IP address to the kernel-level firewall; when the firewall synchronization guardian module captures a deregistration or lease expiration event of the stub module, it dynamically deletes the allow rule corresponding to the stub module, causing the kernel-level firewall to revert to its default discarding and blocking policy, directly discarding all network probe packets from non-whitelisted IPs in kernel space.

[0098] In this embodiment, the firewall synchronization guardian module subscribes to specific topics (such as stub_lifecycle_events) from the distributed coordination center. The distributed coordination center pushes JSON-formatted event messages in real time when the stub module successfully registers, deregisters, or its lease expires, including event_type, stub_id, and physical_ip.

[0099] Specifically, the firewall synchronization guardian module subscribes to changes in the registration key value of the stub program module in the distributed coordination center module through a long-connection Watch interface: when a valid stub program module registration success event is captured, the real physical IP address of the stub program module is dynamically resolved in user space, and an ACCEPT rule for the UDP port listening by the proxy program module pointed to by the physical IP address is dynamically added to the kernel-space packet filtering firewall; when a cancellation or lease expiration event is captured, the corresponding rule is dynamically deleted, so that the kernel-space packet filtering firewall restores the default DROP interception policy, and all network probe packets from non-whitelisted IPs are directly dropped in kernel space.

[0100] For example, the process described in S410-S420 can be: 1. The system administrator pre-configures a static whitelist of authorized source IPs in the distributed coordination center (Etcd) named Authorized_IP_List = ["10.0.1.5", "10.0.1.6"], and distributes the root registration public key from the management end to the front-end deployment nodes.

[0101] 2. When a legitimate Stub program module located in 10.0.1.5 starts, a temporary key pair Stub_Private_Key and Stub_Public_Key is dynamically generated in memory.

[0102] 3. The Stub program module uses the embedded registration public key to perform RSA asymmetric encryption on the plaintext request containing its own device UUID, the current UTC timestamp, and Stub_Public_Key, and then sends a registration request to the distributed coordination center (Etcd).

[0103] 4. After receiving the encrypted ciphertext, the distributed coordination center (Etcd) decrypts it using its unique local root registration private key, extracts the physical IP of the Stub, and matches it in the Authorized_IP_List. Subsequently, the system generates a response plaintext containing a dynamic time-limited tunnel token, extracts the Stub_Public_Key carried in the request, performs secondary asymmetric encryption on the response, and sends it back.

[0104] 5. The Stub program module successfully decrypts the ciphertext of the response using the Stub_Private_Key in memory, obtains the Token, officially activates it, and writes it to the temporary lease node / nodes / stubs / 10.0.1.5.

[0105] 6. The firewall synchronization daemon residing in the user space of the remote business server captures the PUT event in real time through the Watch(" / nodes / stubs / ") interface, immediately calls the system's underlying control handle, and adds a rule to the Linux kernel-level packet filtering firewall: iptables -I QUIC_AGENT_SECURITY -s 10.0.1.5 -p udp --dport 443 -j ACCEPT.

[0106] 7. If an unauthorized stub is maliciously copied, started on 192.168.1.20, and attempts to register, the coordination center will directly reject it because its IP is not in the static whitelist. At this time, the business server's kernel firewall maintains the default blocking policy: `iptables -A QUIC_AGENT_SECURITY -p udp --dport 443 -j DROP`. Any UDP probe packets from this illegal IP will be dropped directly in kernel space, making them completely invisible at the network layer.

[0107] S430: If the stub program module is successfully registered, the WebSocket proxy service module responds to the WebSocket connection request initiated by the client, calls the external contract interface to perform dynamic addressing, and sends the dynamic addressing result to the stub program module.

[0108] S440: Based on the dynamic addressing result, the stub program module opens a new user flow on the existing public network multiplexing tunnel with the agent program module, and sends a signal containing the new user flow to the agent program module.

[0109] S450: After receiving the signal containing the newly created user flow, the proxy module initiates a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology, so that the service module establishes a local TCP connection with the proxy module based on the local TCP connection request.

[0110] In this embodiment of the application, the communication connection system further includes a time-series database; the method further includes: the WebSocket proxy service module reporting the number of currently active external WebSocket connections to the time-series database in real time; the stub program module reporting the number of newly created cross-public network user flows activated in the current network to the time-series database in real time; the proxy program module reporting the number of local TCP connections initiated to the backend to the time-series database in real time; and displaying the external WebSocket connection count, the number of newly created user flows, and the local TCP connection count using linked curves on the same coordinate axis.

[0111] In this embodiment, the external WebSocket connection count refers to the total number of active WebSocket handshake connections between the WebSocket proxy service module and the external client at the current moment. It directly reflects the system's front-end user concurrency scale. Each WebSocket connection typically corresponds to an online user session or device terminal. This metric is used to monitor the pressure on the front-end traffic ingress and is a core basis for evaluating the overall user capacity of the system.

[0112] The "New User Stream Count" metric refers to the total number of logical streams actively transmitting data within the public QUIC multiplexed connection established between the stub module and the agent module at the current moment. It reflects the effective concurrent traffic within the tunnel. Because QUIC supports multiplexing, data from multiple WebSocket connections may be multiplexed across a few QUIC connections, but each WebSocket session typically corresponds to an independent QUIC stream. This metric is used to monitor the resource usage of the public network tunnel and to determine if there are any stream-level blockages or anomalies.

[0113] The local TCP connection count metric refers to the total number of active TCP connections initiated by the proxy module through the local loopback network segment (127.0.0.x) to the backend service module at the current moment. It reflects the actual load pressure on the backend service. Due to the adoption of "local multi-IP address round-robin binding" technology, this metric overcomes the single IP port limitation, truly reflecting the concurrent request volume forwarded by the proxy module to the backend. This metric is used to monitor the carrying capacity of the backend service and prevent service unavailability due to backend connection exhaustion.

[0114] A visual dashboard aligns the three connection count metrics (levels 3, 4, and 5) onto a single coordinate axis, allowing for the precise location of connection leaks in a distributed multi-layered proxy system within seconds of observing misalignment fluctuations without needing to analyze specific business protocols. Ideally, the three metrics should be roughly consistent (1:1:1 mapping). If the external WebSocket connection count exceeds the new user stream count, it indicates that some front-end connections have been lost but tunnel streams have not been cleared in time, or there may be signaling delays. If the new user stream count exceeds the local TCP connection count, it indicates that some tunnel streams have been established but back-end connections have not yet been completed, or the back-end connection pool is full, causing queuing.

[0115] This embodiment provides a communication connection method based on multiplexed tunnels. By using a visualization dashboard to display the above three levels of connection count indicators in a linked curve aligned with the same coordinate axis, the connection leakage fault point in the distributed multi-layer agent system can be located in seconds by observing the misalignment fluctuations of the quantity axis without parsing the specific business protocol.

[0116] Please see Figure 9 This application provides a communication connection system 500 based on multiplexing tunnels. The connection system 500 includes a WebSocket proxy service module 510, a stub program module 520, a proxy program module 530, and a business service module 540.

[0117] The WebSocket proxy service module 510 is used to respond to the WebSocket connection request initiated by the client, call the external contract interface to perform dynamic addressing, and send the dynamic addressing result to the stub module 520.

[0118] The stub module 520 is used to open a new user flow on the existing public network multiplexing tunnel with the agent module 530 based on the dynamic addressing result, and send a signal containing the new user flow to the agent module 530.

[0119] The proxy module 530 is used to initiate a local TCP connection request to the service module 540 using local loopback network segment multi-IP address round-robin binding technology after receiving the signal containing the new user flow, so that the service module 540 establishes a local TCP connection with the proxy module 540 based on the local TCP connection request.

[0120] It should be noted that the system embodiments in this application correspond to the aforementioned method embodiments. The specific principles in the system embodiments can be found in the content of the aforementioned method embodiments, and will not be repeated here.

[0121] The following will combine Figure 10 This application describes an electronic device.

[0122] Please see Figure 10 Based on the aforementioned communication connection method and system based on multiplexing tunnels, this application embodiment also provides another electronic device 100 capable of executing the aforementioned communication connection method based on multiplexing tunnels. The electronic device 100 includes one or more (only one shown in the figure) processors 102, a memory 104, and a network module 106 coupled together. The memory 104 stores programs capable of executing the contents of the aforementioned embodiments, and the processors 102 can execute the programs stored in the memory 104.

[0123] The processor 102 may include one or more processing cores. The processor 102 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling data stored in the memory 104. Optionally, the processor 102 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 102 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 102 and may be implemented separately using a communication chip.

[0124] The memory 104 may include random access memory (RAM) or read-only memory (ROM). The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the electronic device 100 during use (such as phonebook data, audio and video data, chat log data, etc.).

[0125] The network module 106 is used to receive and transmit electromagnetic waves, realizing the mutual conversion between electromagnetic waves and electrical signals, thereby communicating with communication networks or other devices, such as audio playback devices. The network module 106 may include various existing circuit elements for performing these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, SIM cards, memory, etc. The network module 106 can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices via wireless networks. The aforementioned wireless networks may include cellular telephone networks, wireless local area networks, or metropolitan area networks. For example, the network module 106 can interact with base stations.

[0126] Please refer to Figure 11 This diagram illustrates a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. The computer-readable medium 800 stores program code that can be called by a processor to execute the methods described in the above method embodiments.

[0127] The computer-readable storage medium 800 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 800 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 800 has storage space for program code 810 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code 810 may, for example, be compressed in a suitable form.

[0128] This embodiment provides a communication connection method, system, electronic device, and storage medium based on a multiplexed tunnel. The WebSocket proxy service module responds to a WebSocket connection request initiated by a client, calls an external contract interface for dynamic addressing, and sends the dynamic addressing result to the stub program module. Based on the dynamic addressing result, the stub program module opens a new user stream on the existing public network multiplexed tunnel with the proxy program module and sends a signal containing the new user stream to the proxy program module. After receiving the signal containing the new user stream, the proxy program module uses local loopback network segment multi-IP address round-robin binding technology to initiate a local TCP connection request to the business service module, enabling the business service module to establish a local TCP connection with the proxy program module based on the local TCP connection request. Through this method, the proxy program initiates a TCP connection using local loopback multi-IP round-robin binding, allowing the business service to perceive it as a standard local client request, thus adapting to WebSocket access without modifying the original business code.

[0129] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A communication connection method based on multiplexed tunnels, characterized in that, Applied to a communication connection system, the communication connection system including a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module, the method includes: The WebSocket proxy service module responds to the WebSocket connection request initiated by the client by calling the external contract interface to perform dynamic addressing and sending the dynamic addressing result to the stub program module; Based on the dynamic addressing result, the stub program module opens a new user flow on the existing public network multiplexing tunnel with the agent program module, and sends a signal containing the new user flow to the agent program module; After receiving the signal containing the newly created user flow, the proxy module initiates a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology, so that the service module can establish a local TCP connection with the proxy module based on the local TCP connection request.

2. The method according to claim 1, characterized in that, After receiving the signal containing the newly created user flow, the proxy module initiates a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology. This process, after the service module establishes a local TCP connection with the proxy module based on the local TCP connection request, further includes: When the client is disconnected, the WebSocket proxy service module sends a socket close event to the stub module; The stub module sends a RESET_STREAM status frame to the agent module based on the socket close event; The agent module, based on the RESET_STREAM state frame, parses the mapping table to close the local file descriptor corresponding to the RESET_STREAM state frame, and drives the service module to release user memory after reading the EOF signal.

3. The method according to claim 1, characterized in that, After receiving the signal containing the newly created user flow, the proxy module initiates a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology. This process, after the service module establishes a local TCP connection with the proxy module based on the local TCP connection request, further includes: When the business service module triggers the local TCP connection to disconnect, the proxy program module reads the EOF signal on the local TCP connection, releases the corresponding local source IP address and port, and sends a new user flow closing signal to the stub program module. After the stub module captures the closed signal of the newly created user stream, it notifies the WebSocket proxy service module. The WebSocket proxy service module sends a WebSocket close frame with a business-defined status code to the client and disconnects the connection.

4. The method according to claim 1, characterized in that, The communication connection system also includes a distributed coordination center. The WebSocket proxy service module, in response to a WebSocket connection request initiated by a client, calls an external contract interface for dynamic addressing and sends the dynamic addressing result to the stub module, including: The stub program module sends a registration request to the distributed coordination center; When the distributed coordination center receives the registration request, it executes a two-way identity access process based on an asymmetric encryption algorithm to determine whether the stub program module has been successfully registered. If the stub module is successfully registered, the WebSocket proxy service module responds to the WebSocket connection request initiated by the client by calling the external contract interface to perform dynamic addressing and sending the dynamic addressing result to the stub module.

5. The method according to claim 4, characterized in that, The stub module sends a registration request to the distributed coordination center, including: When the stub program module starts, it dynamically generates a temporary public key and a temporary private key. Using a pre-set management terminal registration public key, it performs asymmetric encryption on the registration request containing the temporary public key and the device identity credential, and sends the encrypted registration request to the distributed coordination center. When the distributed coordination center receives the registration request, it executes a two-way identity access process based on an asymmetric encryption algorithm to determine whether the stub program module has successfully registered, including: The distributed coordination center decrypts the encrypted registration request and extracts the temporary public key and the device identity credential. After the distributed coordination center successfully verifies the stub program module based on the device identity credentials, it generates a response plaintext containing a timed tunnel token. Based on the temporary public key, the response plaintext is then subjected to secondary asymmetric encryption and sent back to the stub program module. The stub module decrypts the received ciphertext of the response based on the temporary private key to extract the time-limited tunnel token, activates the construction and communication permissions of the multiplexed tunnel based on the time-limited tunnel token, and confirms that the stub module has been successfully registered.

6. The method according to claim 4, characterized in that, The proxy module includes a firewall synchronization protection module; when the distributed coordination center receives the registration request, it executes a two-way identity access process based on an asymmetric encryption algorithm, and after determining whether the stub module has successfully registered, it further includes: The firewall synchronization protection module monitors event changes in the distributed coordination center via a long connection. When the firewall synchronization guardian module captures the successful registration event of the stub program module, it resolves the real physical IP address of the stub program module in user space and dynamically adds an allow rule for the real physical IP address to the kernel-space firewall. When the firewall synchronization guardian module detects the deregistration or lease expiration event of the stub program module, it dynamically deletes the allow rule corresponding to the stub program module, so that the kernel-mode firewall restores the default drop and interception policy, and directly drops all network probe packets from non-whitelisted IPs in kernel mode.

7. The method according to any one of claims 1-6, characterized in that, The communication connection system further includes a time-series database; the method further includes: The WebSocket proxy service module reports the number of currently active external WebSocket connections to the time-series database in real time. The stub program module reports the number of newly created cross-public network user flows currently active in the network to the time-series database in real time. The proxy module reports the current number of local TCP connections initiated to the backend to the time-series database in real time. The external WebSocket connection count, the number of new user streams, and the local TCP connection count are displayed as linked curves on the same coordinate axis.

8. A communication connection system based on multiplexed tunnels, characterized in that, The communication connection system includes a WebSocket proxy service module, a stub program module, a proxy program module, and a business service module. The WebSocket proxy service module is used to respond to the WebSocket connection request initiated by the client, call the external contract interface to perform dynamic addressing, and send the dynamic addressing result to the stub program module; The stub module is used to open a new user flow on the existing public network multiplexing tunnel with the agent module based on the dynamic addressing result, and send a signal containing the new user flow to the agent module. The proxy module is used to initiate a local TCP connection request to the service module using local loopback network segment multi-IP address round-robin binding technology after receiving the signal containing the new user flow, so that the service module can establish a local TCP connection with the proxy module based on the local TCP connection request.

9. An electronic device, characterized in that, It includes one or more processors and memory; one or more programs are stored in the memory and configured to be executed by the one or more processors according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code, wherein the program code, when executed by a processor, performs the method according to any one of claims 1-7.

Images