Methods and electronic equipment for constructing safe tunnels
The secure tunnel implementation scheme using QUIC+UDP leverages QUIC connections to support multiple data streams and binds data stream management, solving the problems of TCP head-of-line blocking and session identifier management in existing technologies, and improving the real-time performance and transmission efficiency of the secure tunnel.
Patent Information
- Application Number
- CN202310004916.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-01-03
- Publication Date
- 2025-12-02
- Estimated Expiration
- 2043-01-03
AI Technical Summary
Existing secure tunnel implementations based on TLS+TCP secure tunnel session functionality result in TCP head-of-line blocking issues and low packet transmission efficiency, failing to meet the real-time and efficiency requirements of multiple application layer connections.
A secure tunnel implementation scheme using QUIC+UDP is adopted. By establishing multiple application layer connections, QUIC connections support multiple data streams, and QUIC's own data stream management mechanism binds the data streams to achieve a secure tunnel, avoiding additional session identifier management and improving the secure tunnel implementation scheme. By establishing QUIC connections and binding data streams, the TCP head-of-line blocking problem is solved, and data transmission efficiency is improved.
It improves the real-time performance and transmission efficiency of secure tunnels, avoids TCP head-of-line blocking and additional session identifier management, and supports the real-time performance and efficiency requirements of multiple application layer connections.
Smart Images

Figure CN116015954B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of the Internet of Things, and more specifically, to methods and electronic devices for establishing secure tunnels. Background Technology
[0002] Secure tunneling is a network traversal technology and one of the common capabilities required by Internet of Things (IoT) devices. It is mainly used to solve the problem of traversing the internal network to access IoT devices.
[0003] Most current secure tunnel implementations are based on WebSocket + Transport Layer Security (TLS) + Transmission Control Protocol (TCP). A single secure tunnel can only serve one TCP connection, but real-world applications typically require multiple connections. Therefore, the above implementations add secure tunnel session functionality to allow multiple application-layer connections to run on a single secure tunnel. However, this leads to TCP head-of-line blocking, causing multiple application-layer data to interfere with each other, affecting data real-time performance. Furthermore, the need to add a secure tunnel session identifier to messages for session management results in low packet transmission efficiency. Therefore, a new secure tunnel implementation mechanism is urgently needed to avoid these problems. Summary of the Invention
[0004] This application provides a method and electronic equipment for establishing a secure tunnel, with the aim of improving the real-time performance and transmission efficiency of data transmission.
[0005] In a first aspect, this application provides a method for constructing a safe tunnel, comprising:
[0006] A first QUIC connection is established with the first device, and a first data stream is established based on a first data stream creation request sent by the first device, wherein the first data stream creation request includes a first tunnel identifier;
[0007] A second QUIC connection is established with the second device, and a second data stream is established based on a second data stream creation request sent by the second device, wherein the second data stream creation request includes a second tunnel identifier;
[0008] If the first tunnel identifier is the same as the second tunnel identifier, then the first QUIC connection is bound to the second QUIC connection, and a successful secure tunnel creation response is returned to the first device through the first data stream, and a successful secure tunnel creation response is returned to the second device through the second data stream.
[0009] Optionally, establishing the first data stream based on the first data stream creation request sent by the first device includes:
[0010] Receive the first data stream creation request sent by the first device;
[0011] After successfully authenticating the first device, a first data stream creation success response is returned to the first device, and the first tunnel identifier is saved;
[0012] The establishment of the second data stream based on the second data stream creation request sent by the second device includes:
[0013] Receive the second data stream creation request sent by the second device;
[0014] After successfully authenticating the first device, a second data stream creation success response is returned to the first device, and the second tunnel identifier is saved.
[0015] Optional, also includes:
[0016] Receive the first heartbeat information sent by the first device through the first data stream;
[0017] Return a first heartbeat response to the first device;
[0018] Receive the second heartbeat information sent by the second device through the second data stream;
[0019] Return a second heartbeat response to the second device.
[0020] Optional, also includes:
[0021] Receive a first shutdown message sent by the first device, the first shutdown message being used to shut down the first data stream and / or to shut down the first QUIC connection;
[0022] A second shutdown message is sent to the second device, the second shutdown message being used to close the second data stream and the second QUIC connection.
[0023] Optional, also includes:
[0024] The device receives a third data stream creation request sent by the first device. The third data stream creation request includes session information, and the third data stream is used to transmit session data.
[0025] Send a fourth data stream creation request to the second device, the fourth data stream creation request including the session information, the fourth data stream being used to transmit session data;
[0026] Receive the fourth data stream creation success response returned by the second device, and bind the third data stream and the fourth data stream;
[0027] A successful creation response for the third data stream is returned to the first device.
[0028] Optional, also includes:
[0029] Receive session data sent by the first device through the third data stream;
[0030] Based on the binding relationship between the third data stream and the fourth data stream, the session data is sent to the second device through the fourth data stream.
[0031] Optional, also includes:
[0032] Receive a third shutdown message sent by the first device, the third shutdown message being used to shut down the third data stream;
[0033] Based on the binding relationship between the third data stream and the fourth data stream, the fourth data stream is closed.
[0034] Secondly, embodiments of this application provide a method for establishing a secure tunnel, comprising:
[0035] Establish a first QUIC connection with the server and send a first data stream creation request to the server, wherein the first data stream creation request includes a first tunnel identifier;
[0036] Receive the first data stream creation success response returned by the server;
[0037] The first data stream receives a secure tunnel creation success response returned by the server. The secure tunnel creation success response indicates that a secure tunnel has been successfully created with the second device. The second tunnel identifier of the second device is the same as the first tunnel identifier.
[0038] Optional, also includes:
[0039] The first heartbeat information is sent to the server through the first data stream;
[0040] Receive the first heartbeat response returned by the server.
[0041] Optional, also includes:
[0042] Send a first close message to the server, the first close message being used to close the first data stream and / or to close the first QUIC connection.
[0043] Optional, also includes:
[0044] A third data stream creation request is sent to the server, so that the server sends a fourth data stream creation request to the second device based on the third data stream creation request. The third data stream creation request and the fourth data stream creation request include session information. The third data stream and the fourth data stream are used to transmit session data.
[0045] Receive a successful creation response from the server for the third data stream.
[0046] Optional, also includes:
[0047] Session data is sent to the server via the third data stream, so that the server, based on the binding relationship between the third data stream and the fourth data stream, sends the session data to the second device via the fourth data stream.
[0048] Thirdly, this application provides an electronic device, including: a memory and a processor;
[0049] The memory is used to store computer programs;
[0050] The processor is configured to execute a computer program stored in the memory, wherein the computer program, when executed, causes the processor to perform the method described in the first aspect or the second aspect.
[0051] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the method described in the first or second aspect.
[0052] The secure tunnel establishment method and electronic device provided in this application implement a secure tunnel mechanism based on QUIC+UDP. Since QUIC connections support multiple data streams, and these streams do not interfere with each other (i.e., the sessions corresponding to the data streams do not affect each other), real-time data transmission is guaranteed. Furthermore, session management can be achieved using QUIC's own data stream management mechanism, eliminating the need for additional identifier management and improving data transmission efficiency. Attached Figure Description
[0053] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0054] Figure 1 This is a schematic diagram of an access scenario for an IoT device.
[0055] Figure 2 These are schematic diagrams illustrating the principles of two implementation schemes for safe tunnels;
[0056] Figure 3 This is a schematic diagram of the secure tunnel session function;
[0057] Figure 4 This is a diagram illustrating TCP transmission.
[0058] Figure 5 This is a schematic diagram of the TCP message structure;
[0059] Figure 6 This is a schematic diagram illustrating the principle of the QUIC+UDP-based scheme provided in the embodiments of this application;
[0060] Figure 7 This is an architecture diagram of the secure tunnel solution provided in the embodiments of this application;
[0061] Figure 8 This is a flowchart illustrating the method for establishing a secure tunnel provided in an embodiment of this application;
[0062] Figure 9 This is another schematic flowchart of the method for establishing a secure tunnel provided in the embodiments of this application;
[0063] Figure 10 This is a flowchart illustrating the session establishment and data transmission method provided in the embodiments of this application;
[0064] Figure 11 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation
[0065] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0066] First, the terminology used in the embodiments of this application will be introduced.
[0067] Secure tunnel: Provides a secure access channel for devices at both ends to solve the problem of network disconnection between devices at both ends. In IoT scenarios, it is mainly used for operation and maintenance. For example, the two ends are the access end for operation and maintenance personnel and the IoT device end, respectively.
[0068] Secure tunnel session: A communication unit based on a secure tunnel, which treats the secure tunnel as a real tunnel (road), and the secure tunnel session is the lane on the tunnel.
[0069] WebSocket: A protocol for full-duplex communication over a single TCP connection.
[0070] Quick User Datagram Protocol Internet Connection (QUIC) is a low-latency Internet transport layer protocol based on UDP.
[0071] Figure 1 This is a diagram illustrating an access scenario for an IoT device. For example... Figure 1 As shown, the IoT device (device side) is on the intranet, while the maintenance personnel's PC is on the internet. The internet-connected maintenance computer (access terminal) cannot directly access the IoT device, thus preventing maintenance. On-site maintenance would be prohibitively expensive due to manpower costs. Therefore, intranet penetration technology is essential in IoT scenarios.
[0072] There are currently two main solutions for implementing safe tunnels, such as... Figure 2 As shown, the first approach is to implement the secure tunnel function using the Internet Protocol Security (IPSec) security protocol at the IP layer. This approach requires modification of the IP layer and specific equipment, such as a dedicated Virtual Private Network (VPN) gateway. Since the network environment of IoT devices is not fixed and the cost of modifying the IP layer is high, this approach is rarely used.
[0073] The second approach involves adding TSL (Transport Security Layer) at the transport layer and implementing the secure tunnel functionality based on the TSL+TCP secure transport protocol. This approach does not require network modifications and can be used by any device, making it a mainstream secure tunnel implementation. However, because the secure tunnel implementation relies on an adaptive security layer, a single secure tunnel can only serve one TCP connection. Since real-world applications typically require multiple connections, this approach also includes secure tunnel session functionality, such as... Figure 3 As shown, multiple application layers can be connected through a secure tunnel, and there are no restrictions on the type of application layer protocol, such as common HTTP, SSH, FTP, etc.
[0074] However, the second approach still has two problems. The first is the TCP head-of-line blocking problem: because TCP is a reliable transmission method, packets arrive in order and are then received by the upper layer, such as... Figure 4As shown, if one frame is lost, subsequent data cannot be read until the retransmission of that frame arrives. In a secure tunnel scenario, if some data in a previous session is lost, it will affect the data of subsequent sessions; that is, data from multiple sessions will interfere with each other, impacting data real-time performance. The second problem is that because secure tunnel sessions are added, all messages on the secure tunnel need to have a session identifier added for session management. This results in less effectively transmitted data, such as... Figure 5 In the TCP packet shown, only the user data portion is valid, resulting in low packet transmission efficiency.
[0075] Therefore, it is currently necessary to address the issues of data real-time performance and message transmission efficiency introduced by secure tunnel session management. However, the underlying implementation using TLS+TCP cannot solve these problems, thus requiring the exploration of other solutions. In this application, a secure tunnel implementation scheme based on QUIC+UDP is proposed. QUIC effectively addresses various requirements faced by the transport and application layers, including handling more connections, security, and low latency. Figure 6 The diagram illustrates the difference between the TLS+TCP and QUIC+UDP schemes.
[0076] First, let's introduce the features of QUIC. QUIC features multistreaming, key negotiation, and reliable transmission. Specifically, QUIC natively supports multiple independent data streams on a single connection, meaning it supports multiple data streams. Because it's implemented based on UDP, the data streams do not interfere with each other. QUIC uses reliable key negotiation in TLS 1.3 to ensure secure transmission. Furthermore, QUIC has implemented packet loss retransmission and flow control, ensuring that the data read from the data stream is ordered and reliable.
[0077] In secure tunnel session scenarios, sessions are stateful and continuous. When using QUIC in secure tunnel scenarios, it is necessary to manage the correspondence between tunnels and streams to ensure that data is not transferred incorrectly. Figure 7The diagram illustrates the architecture of an embodiment of this application. Taking the two devices as the access end and the device end as an example, the access end and the device end respectively establish a QUIC connection with the IoT server and a data stream based on the QUIC connection. The server matches and binds the QUIC connections of the two ends to form a secure tunnel. Subsequently, when a session is created at either end, a data stream based on a QUIC connection is established with the server. The server then creates a corresponding data stream on the other end and binds the two data streams. Afterwards, either end sends data to the server through the data stream, and the server then finds the corresponding data stream based on the binding relationship and completes the data forwarding. Figure 7 As illustrated, data in session 1 between the client and device is forwarded by the server via stream1 and streamB, while data in session 2 is forwarded by the server via stream2 and streamC, and other sessions follow a similar pattern. Since data streams within a QUIC connection do not interfere with each other, sessions will not affect each other. Data loss in one session will not affect data reading in other sessions, thus ensuring data real-time performance. Furthermore, one session corresponds to one data stream, and session management can naturally utilize QUIC's data stream management mechanism without the need for additional identifier management. All user data can be transmitted on the data stream, improving data transmission efficiency.
[0078] The method for establishing a secure tunnel provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be noted that in the embodiments of this application, the methods performed by the first device and the second device are interchangeable. For example, the first device can be a device end, and the second device can be an access end, or the first device can be an access end, and the second device can be a device end.
[0079] Figure 8 This is a flowchart illustrating the method for establishing a secure tunnel provided in an embodiment of this application. Figure 8 As shown, the method includes:
[0080] S801. Establish a first QUIC connection with the first device and establish a first data stream based on the first data stream creation request sent by the first device. The first data stream creation request includes a first tunnel identifier.
[0081] During the process of establishing a first QUIC connection between the first device and the server, the first device verifies the server's certificate to ensure the security of the server's identity. The process of establishing a QUIC connection in this embodiment can be found in the implementation of related technologies. After establishing the first QUIC connection between the server and the first device, a data stream can be established based on this connection. The first device sends a first data stream creation request to the server to establish a first data stream between the first device and the server. The first data stream creation request may carry device identity information. The first tunnel identifier carried in the first data stream creation request can be a secure tunnel identifier obtained in advance from the server. Optionally, the first data stream creation request may carry information such as a token or device signature for authentication. Device identity information, such as the tunnel identifier and token, can be sent to the first device through the server's MQTT channel. Optionally, the server receives the first data stream creation request sent by the first device; after successfully authenticating the first device, it returns a first data stream creation success response to the first device and saves the first tunnel identifier.
[0082] S802. Establish a second QUIC connection with the second device, and establish a second data stream based on the second data stream creation request sent by the second device. The second data stream creation request includes a second tunnel identifier.
[0083] During the establishment of the second QUIC connection between the second device and the server, the second device verifies the server's certificate to ensure the security of the server's identity. After the second QUIC connection is established between the server and the second device, a data stream can be established based on the second QUIC connection. The second device sends a second data stream creation request to the server to establish the second data stream between the second device and the server. The second data stream creation request may carry device identity information. The second tunnel identifier carried in the second data stream creation request can be a secure tunnel identifier obtained in advance from the server. Optionally, the second data stream creation request may carry tokens or device signatures for authentication. Device identity information, such as the tunnel identifier and token, can be sent to the second device through the server's Message Queuing Telemetry Transport (MQTT) channel. Optionally, the server receives the second data stream creation request sent by the second device; after successfully authenticating the second device, it returns a second data stream creation success response to the second device and saves the second tunnel identifier.
[0084] It should be noted that the execution order of S801 and S802 is not limited in this embodiment, that is, the order in which the first device and the second device establish a connection with the server is not limited.
[0085] S803. If the first tunnel identifier is the same as the second tunnel identifier, then bind the first QUIC connection to the second QUIC connection, and return a successful secure tunnel creation response to the first device through the first data stream, and return a successful secure tunnel creation response to the second device through the second data stream.
[0086] After establishing a QUIC connection with each device and obtaining the corresponding tunnel identifier from the data stream, the server checks if a matching tunnel identifier exists. If the first tunnel identifier of the first device and the second tunnel identifier of the second device are the same, the server binds the first QUIC connection to the second QUIC connection, indicating that the secure tunnel is established. Simultaneously, the server returns a successful secure tunnel creation response to the corresponding device via the first and second data streams, indicating that the secure tunnel between the first and second devices has been successfully created. Thus, the secure tunnel is in a connected state, and the first and second devices can subsequently initiate session creation based on this secure tunnel. Each session corresponds to a data stream for data transmission within that session.
[0087] The method described in this application implements a secure tunnel mechanism based on QUIC+UDP. Since QUIC connections support multiple data streams, and these streams do not interfere with each other (i.e., the sessions corresponding to the data streams do not affect each other), real-time data transmission is guaranteed. Furthermore, session management can be achieved using QUIC's own data stream management mechanism, eliminating the need for additional identifier management and improving data transmission efficiency.
[0088] In this embodiment, after the first device and the second device establish a QUIC connection, their respective first data streams (i.e., the first data stream and the second data stream) are used to send heartbeat packets. The server uses these heartbeat packets to determine whether the first device and the second device are still connected. The server receives the first heartbeat information sent by the first device through the first data stream and returns a first heartbeat response to the first device. The server receives the second heartbeat information sent by the second device through the second data stream and returns a second heartbeat response to the second device. If the first device (or the second device) does not send a heartbeat packet for a long time or fails to send a heartbeat packet multiple times consecutively, the server determines that the connection of the first device (or the second device) has been broken. It then executes an exception handling process, disconnecting the QUIC connection of the first device (or the second device) and marking the associated secure tunnel as not open. Subsequently, if the first device (or the second device) re-establishes a QUIC connection and the corresponding first data stream (or second data stream) with the server, the server can re-match the tunnel identifier to open the secure channel.
[0089] With the secure tunnel established, either the first or second device can proactively initiate session creation, that is, proactively create a data stream for transmitting session data. After the server establishes a data stream corresponding to a session with the first or second device, it will establish a corresponding data stream on the other device and bind the two data streams together. In this way, the data of that session between the first and second devices can be transmitted through these two bound data streams in the secure tunnel.
[0090] Optionally, the server receives a third data stream creation request from the first device, which includes session information and is used to transmit session data; it also sends a fourth data stream creation request to the second device, which includes session information and is used to transmit session data; it receives a successful fourth data stream creation response from the second device and binds the third and fourth data streams; and it returns a successful third data stream creation response to the first device. The session information may include the session type, IP address, or port number.
[0091] Optionally, the server receives a fifth data stream creation request sent by the second device, the fifth data stream creation request including session information, and the fifth data stream is used to transmit session data; sends a sixth data stream creation request to the first device, the sixth data stream creation request including session information, and the sixth data stream is used to transmit session data; receives a sixth data stream creation success response returned by the first device, and binds the fifth data stream and the sixth data stream; and returns a fifth data stream creation success response to the second device.
[0092] After the two data streams used for transmitting session data are bound together, either the first device or the second device can actively transmit data based on the data streams. Once the session data from either end is sent to the server via the data stream, the server will find the corresponding data stream based on the binding relationship of the data streams and forward the session data to the other end.
[0093] Optionally, the server receives session data sent by the first device through the third data stream; based on the binding relationship between the third data stream and the fourth data stream, it sends session data to the second device through the fourth data stream.
[0094] Optionally, the server receives session data sent by the second device through the fourth data stream; based on the binding relationship between the third and fourth data streams, it sends session data to the first device through the third data stream.
[0095] After a QUIC connection and data stream are established, either the first device or the second device can actively close the QUIC connection and data stream. Either device can initiate the closure to the server. If the first device initiates the closure to the server, the server will then initiate the closure to the second device after receiving the closure information. Conversely, if the second device initiates the closure to the server, the server will then initiate the closure to the first device after receiving the closure information.
[0096] Optionally, the server receives a first close message from the first device, which is used to close the first data stream and / or close the first QUIC connection; and sends a second close message to the second device, which is used to close the second data stream and the second QUIC connection. Optionally, the server receives a fifth close message from the second device, which is used to close the first data stream and / or close the first QUIC connection; and sends a sixth close message to the first device, which is used to close the first data stream and the first QUIC connection. That is, if one device actively closes the QUIC connection or the data stream used to send heartbeats, the server will close both the data stream and the QUIC connection of the other device.
[0097] Optionally, the server receives a third close message from the first device, which is used to close the third data stream; based on the binding relationship between the third and fourth data streams, it closes the fourth data stream. Optionally, the server receives a fourth close message from the second device, which is used to close the fourth data stream; based on the binding relationship between the third and fourth data streams, it closes the third data stream. That is, if one device actively closes the data stream used to send session data, the server closes the corresponding data stream used by the other device to send that session data. At this time, the QUIC connection is still maintained, and the first and second devices can still create data streams based on the QUIC connection later.
[0098] The following combination Figure 9 and Figure 10 Examples of the creation of secure tunnels, session creation, and session data transmission in the embodiments of this application are provided. Figure 9 and Figure 10 The example uses the first device as the access end and the second device as the device end.
[0099] Reference Figure 9 It explains the creation and closure of safe tunnels and the maintenance of heartbeats.
[0100] S901. The device and the server establish a QUIC connection. During this stage, the device verifies the server's certificate to ensure the security of the server's identity.
[0101] S902. The device establishes the first data stream (stream1) connection with the server. When establishing the stream1 connection, device identity information is attached: tunnel identifier and token or device signature.
[0102] S903. The server verifies the device's identity information and returns a success response to the device, while saving the tunnel identifier for subsequent matching.
[0103] S904-S906, the process of establishing a QUIC connection and the first data stream (streamA) at the access end, is similar to S901-S903. It should be noted that S904-S906 can be executed before or simultaneously with S901-S903.
[0104] S907. The server determines that the tunnel identifiers of the device and the access end are the same, and binds the tunnel connection between the two ends, thus completing the secure tunnel connection.
[0105] S908, the server returns a secure tunnel connection message via stream1, indicating that the secure tunnel has been successfully created, and sends a response to the device.
[0106] S909. The server returns a secure tunnel connection message via sreamA, indicating that the secure tunnel has been successfully created, and sends a response to the client.
[0107] It should be noted that S909 can be executed before or simultaneously with S908.
[0108] S910: The device sends a heartbeat to the server via stream1.
[0109] S911, the server returns a heartbeat response to the device via stream1.
[0110] S912, the client sends a heartbeat to the server via streamA.
[0111] S913, The server returns a heartbeat response to the client via streamA.
[0112] It should be noted that S912-S913 can be executed before or simultaneously with S910-S911.
[0113] S914, The access end closes the streamA and QUIC connections with the server.
[0114] S915, The server closes the stream1 and QUIC connections with the device and marks the secure tunnel between the device and the access point as not open.
[0115] Understandably, in S914-S915, the example can also be that the device initiates the shutdown first.
[0116] Reference Figure 10 This section explains the creation and transmission of data streams.
[0117] S1001. The access end creates a new session, that is, creates a data stream based on QUIC. Taking streamB as an example, the session information of streamB is carried during creation. The session information includes, but is not limited to, type, IP and port.
[0118] S1002. When the server receives the creation request for streamB, it will create a data stream stream2 between the server and the device, and the creation request will carry the session information of streamB.
[0119] S1003, The device returned a message that stream2 was created successfully.
[0120] S1004, the server will bind stream2 to streamB.
[0121] S1005, The server returns a message to the client indicating that streamB was successfully created.
[0122] Understandably, in S1001-S1005, the example can also be that the device initiates the session creation first.
[0123] S1006. The access end sends session data through streamB.
[0124] S1007. The server receives the session data and looks up the data stream stream2 corresponding to streamB.
[0125] S1008, The server forwards session data to the device via stream2.
[0126] Device initiates session:
[0127] The processing flow for S1009-S1011 is similar to that for S1006-S1008. It should be noted that S1009-S1011 can be executed before or simultaneously with S1006-S1008.
[0128] S1012, The accessing end actively disconnects streamB.
[0129] S1013. The server searches for the data stream stream2 corresponding to streamB.
[0130] S1014, The server disconnects stream2.
[0131] Understandably, in S1012-S1014, the example could be that the device initiates the disconnection first.
[0132] The secure channel scheme in this application is implemented based on UDP, without involving any modifications to the IP layer, and has a wide range of applications. Furthermore, it avoids the head-of-line blocking problem of TCP, ensuring complete isolation between sessions and preventing the loss of data in session 2 due to packet loss in session 1, thus improving data transmission real-time performance. Simultaneously, one session corresponds to one data stream, and session management can naturally utilize QUIC's existing data stream management mechanism. All user data can be transmitted on the data stream, improving data transmission efficiency. Moreover, both the access end and the device end can actively initiate sessions to complete data transmission, expanding the application scenarios of sessions. For example, in addition to the access end actively maintaining the device end, the device end can also actively report data to the access end, broadening its application scope.
[0133] Figure 11 This is a schematic block diagram of the electronic device provided in an embodiment of this application. Figure 11 As shown, the electronic device 1100 may include at least one processor 1101 for implementing the inspection method provided in the embodiments of this application. The electronic device 1100 may be a server, a first device, or a second device.
[0134] Optionally, the electronic device 1100 further includes at least one memory 1102 for storing program instructions and / or data. The memory 1102 is coupled to the processor 1101. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1101 may operate in conjunction with the memory 1102. The processor 1101 may execute program instructions stored in the memory 1102. At least one of the at least one memory may be included in the processor.
[0135] Optionally, the electronic device 1100 further includes a communication interface 1103 for communicating with other devices via a transmission medium, thereby enabling the electronic device 1100 to communicate with other devices. The communication interface 1103 may be, for example, a transceiver, interface, bus, circuit, or a device capable of transmitting and receiving functions. The processor 1101 can utilize the communication interface 1103 to transmit and receive data and / or information, and to implement the methods provided in the embodiments of this application. For details, please refer to the detailed descriptions in the preceding embodiments; further elaboration is not required here.
[0136] This application embodiment does not limit the specific connection medium between the processor 1101, memory 1102, and communication interface 1103. This application embodiment... Figure 11 The processor 1101, memory 1102, and communication interface 1103 are connected via bus 1104. Bus 1104 is... Figure 11 The connections between other components are shown in thick lines only and are not intended to be limiting. This bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 11 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0137] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.
[0138] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0139] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the methods as described in any of the foregoing embodiments.
[0140] The terms “unit”, “module”, etc., used in this specification may be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.
[0141] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0142] The unit described as a separate component may or may not be physically separate. The component shown as a unit may or may not be a physical unit; that is, it may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0143] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0144] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. This computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).
[0145] If this function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0146] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for constructing a safe tunnel, characterized in that, include: A first QUIC connection is established with the first device, and a first data stream is established based on a first data stream creation request sent by the first device, wherein the first data stream creation request includes a first tunnel identifier; the first data stream is used to transmit secure tunnel status information. A second QUIC connection is established with the second device, and a second data stream is established based on a second data stream creation request sent by the second device, wherein the second data stream creation request includes a second tunnel identifier; the second data stream is used to transmit secure tunnel status information. If the first tunnel identifier is the same as the second tunnel identifier, then the first QUIC connection is bound to the second QUIC connection, and a successful secure tunnel creation response is returned to the first device through the first data stream, and a successful secure tunnel creation response is returned to the second device through the second data stream.
2. The method according to claim 1, characterized in that, The establishment of the first data stream based on the first data stream creation request sent by the first device includes: Receive the first data stream creation request sent by the first device; After successfully authenticating the first device, a first data stream creation success response is returned to the first device, and the first tunnel identifier is saved; The establishment of the second data stream based on the second data stream creation request sent by the second device includes: Receive the second data stream creation request sent by the second device; After successfully authenticating the first device, a second data stream creation success response is returned to the first device, and the second tunnel identifier is saved.
3. The method according to claim 1, characterized in that, Also includes: Receive the first heartbeat information sent by the first device through the first data stream; Return a first heartbeat response to the first device; Receive the second heartbeat information sent by the second device through the second data stream; Return a second heartbeat response to the second device.
4. The method according to claim 1, characterized in that, Also includes: Receive a first shutdown message sent by the first device, the first shutdown message being used to shut down the first data stream and / or to shut down the first QUIC connection; A second shutdown message is sent to the second device, the second shutdown message being used to close the second data stream and the second QUIC connection.
5. The method according to any one of claims 1-4, characterized in that, Also includes: The device receives a third data stream creation request sent by the first device. The third data stream creation request includes session information, and the third data stream is used to transmit session data. Send a fourth data stream creation request to the second device, the fourth data stream creation request including the session information, the fourth data stream being used to transmit session data; Receive the fourth data stream creation success response returned by the second device, and bind the third data stream and the fourth data stream; A successful creation response for the third data stream is returned to the first device.
6. The method according to claim 5, characterized in that, Also includes: Receive session data sent by the first device through the third data stream; Based on the binding relationship between the third data stream and the fourth data stream, the session data is sent to the second device through the fourth data stream.
7. The method according to claim 5, characterized in that, Also includes: Receive a third shutdown message sent by the first device, the third shutdown message being used to shut down the third data stream; Based on the binding relationship between the third data stream and the fourth data stream, the fourth data stream is closed.
8. A method for constructing a safe tunnel, characterized in that, include: Establish a first QUIC connection with the server and send a first data stream creation request to the server, wherein the first data stream creation request includes a first tunnel identifier; Receive the first data stream creation success response returned by the server; The first data stream receives a secure tunnel creation success response returned by the server. The secure tunnel creation success response is used to indicate that a secure tunnel between the second device and the second device has been successfully created. The second tunnel identifier of the second device is the same as the first tunnel identifier. The first data stream is used to transmit secure tunnel status information.
9. The method according to claim 8, characterized in that, Also includes: The first heartbeat information is sent to the server through the first data stream; Receive the first heartbeat response returned by the server.
10. The method according to claim 8, characterized in that, Also includes: Send a first close message to the server, the first close message being used to close the first data stream and / or to close the first QUIC connection.
11. The method according to any one of claims 8-10, characterized in that, Also includes: A third data stream creation request is sent to the server, so that the server sends a fourth data stream creation request to the second device based on the third data stream creation request. The third data stream creation request and the fourth data stream creation request include session information. The third data stream and the fourth data stream are used to transmit session data. Receive a successful creation response from the server for the third data stream.
12. The method according to claim 11, characterized in that, Also includes: Session data is sent to the server via the third data stream, so that the server, based on the binding relationship between the third data stream and the fourth data stream, sends the session data to the second device via the fourth data stream.
13. An electronic device, characterized in that, include: Memory and processor; The memory is used to store computer programs; The processor is configured to execute a computer program stored in the memory, wherein when the computer program is executed, the processor performs the method described in any one of claims 1-12.
14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method as described in any one of claims 1-12.
Citation Information
Patent Citations
Method for establishing traffic engineering-over-label switch path tunnel and equipment
CN107306222A
Session establishment method and device, computer equipment, terminal and storage medium
CN115460266A
Multilayer tunneling of protocols over quic
US20210409447A1
System and method for creating a secure hybrid overlay network
WO2019246331A1