Tunnel establishment and data transmission processing method and device, and storage medium

Abstract

Embodiments of the present application provide a tunnel establishment and data transmission processing method and device, and a storage medium. In the embodiments of the present application, on the one hand, the tunnel supporting unreliable transmission is improved, and the number of retransmissions when the client configures the tunnel to transmit non-reliable data packets is allowed, so that in the case that the tunnel fails to transmit non-reliable data packets, the retransmission of the non-reliable data packets that fail to be transmitted in the tunnel can be processed according to the number of retransmissions configured by the client, so as to realize the retransmission of lost packets on the tunnel link and improve the data transmission performance based on the tunnel. On the other hand, a tunnel establishment method based on long and short packet header information is provided, which solves the problem that the tunnel message is discarded or blocked on the tunnel server due to the loss of the control frame for establishing the tunnel or the out-of-order of the data message in the traditional tunnel establishment process. At the same time, the overhead of the tunnel packet header is saved, the resources consumed by data transmission are reduced, and the data transmission efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and particularly relates to a tunnel establishment and data transmission processing method and device and a storage medium. BACKGROUND

[0002] In the field of Internet, the communication protocols mainly used in the transport layer include the connection-oriented transmission control protocol (TCP) and the connectionless user datagram protocol (UDP). Compared with TCP, the transmission efficiency of UDP is higher, but the reliability is not as good as TCP.

[0003] Quick UDP Internet Connection (QUIC) is a UDP-based transmission protocol. QUIC absorbs many properties similar to TCP and also has the security transmission protocol (TLS) encryption, which is placed in the application layer on the UDP transmission. QUIC has the advantages of TCP and UDP, can well solve various requirements faced by the transport layer and the application layer, including processing more connections, security and low delay, etc.

[0004] With the development of QUIC, the QUIC protocol is also integrated with the tunnel technology. A tunnel can be created on the QUIC connection, and the transmission of upper-layer application data is performed through the tunnel, which can improve the transmission efficiency. In the existing tunnel technology, the unreliable transmission technology is usually used. However, in some application scenarios, the transmission reliability requirement is relatively high, and the existing data transmission scheme based on the tunnel cannot meet the transmission performance requirement of these application scenarios. SUMMARY

[0005] The aspects of the present application provide a tunnel establishment and data transmission processing method, device and storage medium, to provide a new tunnel transmission mechanism, allow the upper-layer application to configure the retransmission number of the tunnel transmission of the unreliable data packet, and realize the packet loss retransmission on the tunnel link. The transmission efficiency is guaranteed, and the transmission performance based on the tunnel is improved.

[0006] The embodiment of the present application provides a data transmission processing method, which is applied to a tunnel client, and the method comprises the following steps: in response to a tunnel establishment request of a first client, a first tunnel for carrying data transmission is established between the first client and a first server; configuration information issued by the first client is received, wherein the configuration information comprises a retransmission number for the first tunnel to transmit unreliable data packets; in the case that the first tunnel fails to transmit unreliable data packets, the retransmission number in the configuration information is acquired, and retransmission processing is performed on the unreliable data packets that fail to be transmitted in the first tunnel.

[0007] The embodiment of the present application also provides a data transmission processing method, which is applied to a first client, and the method comprises the following steps: a retransmission number for a first tunnel to transmit unreliable data packets is generated, wherein the first tunnel is a tunnel for carrying data transmission between the first client and a first server; configuration information is sent to a tunnel client, wherein the configuration information comprises the retransmission number, so that the tunnel client acquires the retransmission number in the configuration information, and performs retransmission processing on unreliable data packets that fail to be transmitted in the first tunnel in the case that the first tunnel fails to transmit unreliable data packets.

[0008] The embodiment of the present application also provides a data transmission processing method, which is applied to a tunnel client, and the method comprises the following steps: in response to a tunnel establishment request of a first client, a first tunnel is established on a QUIC connection between the tunnel client and a tunnel server, wherein the first tunnel carries data transmission between the first client and the first server in the form of unreliable data packets; configuration information issued by the first client is received, wherein the configuration information comprises a retransmission number for the first tunnel to transmit unreliable data packets; in the case that the first tunnel fails to transmit unreliable data packets, retransmission processing is performed on the unreliable data packets that fail to be transmitted in the first tunnel according to the retransmission number in the configuration information.

[0009] The embodiment of the present application also provides a tunnel establishment method, which is applied to a tunnel client, and the method comprises the following steps: in response to a tunnel establishment request of a first client, identification information of a first server is acquired, wherein the tunnel establishment request is used for requesting a first tunnel for carrying data transmission between the first client and the first server; tunnel resource initialization is performed at the local end to obtain identification information of the first tunnel; a first unreliable data packet carrying first packet header information is sent to a tunnel server, wherein the first packet header information comprises the identification information of the first server and the identification information of the first tunnel, so that the tunnel server performs establishment of a forwarding mapping relationship between the first tunnel and the first server and forwarding processing of the first unreliable data packet.

[0010] The embodiment of the present application further provides a tunnel establishment method applied to a tunnel server, and the method comprises the following steps: receiving a first non-reliable data packet sent by a tunnel client; analyzing first packet header information from the first non-reliable data packet, wherein the first packet header information comprises identification information of a first server and identification information of a first tunnel, and the first tunnel is a tunnel used for carrying data transmission between a first client and the first server; establishing a forwarding mapping relationship between the first tunnel and the first server according to the first packet header information, and forwarding the first non-reliable data packet to the first server.

[0011] The embodiment of the present application provides a terminal device, comprising a memory and a processor; the memory is used for storing a computer program, and the processor is coupled with the memory and is used for executing the computer program to implement steps in the data transmission processing method executable by a tunnel client, the data transmission processing method executable by a first client or the tunnel establishment method executable by a tunnel client provided by the embodiment of the present application.

[0012] The embodiment of the present application provides a tunnel server, comprising a memory and a processor, wherein the memory is used for storing a computer program, and the processor is coupled with the memory and is used for executing the computer program to implement steps in the tunnel establishment method executable by a tunnel server.

[0013] The embodiment of the present application further provides a computer readable storage medium storing a computer program, when the computer program is executed by a processor, the processor is caused to implement steps in the data transmission processing method or the tunnel establishment method provided by the embodiment of the present application.

[0014] In the embodiment of the present application, a new tunnel transmission mechanism is provided, a tunnel carrying data transmission is established between a client and a server, and the number of retransmissions when the tunnel transmits a non-reliable data packet is configured by the client, so that in the case that the tunnel transmission of the non-reliable data packet fails, the retransmission processing of the non-reliable data packet transmitted in the tunnel and failed can be performed according to the number of retransmissions configured by the client, so as to realize the packet loss retransmission on the tunnel link and improve the data transmission performance based on the tunnel.

[0015] Further, in the embodiments of the present application, a tunnel establishment method based on two kinds of packet header information is provided. For a tunnel used for carrying data transmission between a client and a server, before determining that a tunnel server establishes a forwarding mapping relationship between the tunnel and the server, a first packet header information (i.e., a long packet header information) is used to encapsulate and tunnel a data packet sent by the client to the server in the tunnel. In this way, the tunnel server can establish the forwarding mapping relationship between the tunnel and the server according to the first packet header information, so that the tunnel can carry data transmission between the client and the server, and the establishment of the tunnel is completed. On the other hand, the tunnel server can also complete the forwarding processing of the data packet according to the first packet header information. In this way, even if the forwarding mapping relationship has not been successfully established, the data packet can be successfully forwarded to the server, and the problem that the non-reliable data packet is discarded or blocked on the tunnel server due to the fact that the control frame for establishing the tunnel is lost or out of order with the data packet during the traditional tunnel establishment process, and the forwarding mapping relationship cannot be established in time, is solved.

[0016] Further, after the tunnel server successfully establishes the forwarding mapping relationship between the tunnel and the server, the second packet header information (i.e., a short packet header information) is used to encapsulate and tunnel the data packet, which can save the overhead of the tunnel packet header, reduce the resources consumed by data transmission, and improve the data transmission efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings, which are included to provide a further understanding of the present application and are incorporated in and constitute a part of this application, illustrate embodiments of the present application and serve to explain the present application. In the drawings:

[0018] Figure 1 An application scenario diagram for service access based on a tunnel technology provided by the embodiments of the present application;

[0019] Figure 2a An interaction flow diagram of a tunnel establishment method provided by the embodiments of the present application;

[0020] Figure 2b An interaction flow diagram of a tunnel establishment method based on long and short packet header information provided by the embodiments of the present application;

[0021] Figure 2c A tunnel establishment method based on Figure 1 A diagram for showing the tunnel establishment process in the application scenario;

[0022] Figure 3a A flow diagram of a data retransmission method based on a tunnel provided by the embodiments of the present application;

[0023] Figure 3b A flow diagram of a data retransmission method based onFigure 1 An application scenario for showing a tunnel retransmission configuration process is shown in the figure;

[0024] Figure 4a A flowchart of a data transmission processing method provided by an embodiment of the present application is shown in the figure;

[0025] Figure 4b A flowchart of a data transmission processing method provided by an embodiment of the present application is shown in the figure;

[0026] Figure 4c A flowchart of a tunnel establishment method provided by an embodiment of the present application is shown in the figure;

[0027] Figure 4d A flowchart of another tunnel establishment method provided by an embodiment of the present application is shown in the figure;

[0028] Figure 5a A structural diagram of a data transmission processing apparatus provided by an embodiment of the present application is shown in the figure;

[0029] Figure 5b A structural diagram of a data transmission processing apparatus provided by an embodiment of the present application is shown in the figure;

[0030] Figure 5c A structural diagram of a tunnel establishment apparatus provided by an embodiment of the present application is shown in the figure;

[0031] Figure 5d A structural diagram of another tunnel establishment apparatus provided by an embodiment of the present application is shown in the figure;

[0032] Figure 6a A structural diagram of a terminal device provided by an embodiment of the present application is shown in the figure;

[0033] Figure 6b A structural diagram of a tunnel server provided by an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0034] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described below in detail with reference to the embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0035] The technical solutions provided by the embodiments of the present application will be described in detail below with reference to the drawings.

[0036] Figure 1 An application scenario for service access based on tunnel technology provided by an embodiment of the present application is shown in the figure. As shown in the figure,Figure 1 As shown in the system scenario, the system scenario includes: a terminal device 10, an edge node 20 and a server 30; wherein the terminal device 10 is network interconnected with the edge node 20, and the edge node 20 is network interconnected with the application server 30. Optionally, the application server 30 is located in a central cloud or an Internet Data Center (IDC).

[0037] In this embodiment, the terminal device 10 is installed with a client, which can be various application programs, applets or plug-ins and the like capable of providing local services for users, for example, but not limited to: online shopping App, online reading App, game App, mailbox App, instant messaging App and video App and the like. These clients need to cooperate with the server 30, and the server 30 is mainly used for responding to various requests of the clients for data processing, returning processing results to the clients, providing resources to the clients, storing data of the clients and the like. According to different application requirements, the application functions provided by the server 30 will also be different. For example, the server 30 can be an e-commerce server, a reading server, a game server, a mailbox server, an instant messaging server and a video server and the like.

[0038] Among them, in terms of product implementation form, the terminal device 10 carrying the client can be a smart phone, a tablet computer, a notebook computer, a wearable device, a vehicle-mounted device and a smart home appliance and the like. Correspondingly, the server 30 can be a traditional server, a cloud server, a server array or a cluster and the like. The number of terminal devices 10 can be one or more, and the number of servers 30 can also be one or more, and different servers 30 can provide different application services. In Figure 1 , one terminal device 10 and two servers 30 are taken as an example for illustration, and in Figure 1 , the two servers 30 are divided into a first server and a second server. It should be understood that Figure 1 the number and product form of the terminal device 10 and the server 30 shown in Figure 1 , the terminal device 10 is installed with two clients, which are referred to as a first client and a second client, but are not limited to this, and one or more clients can be installed on each terminal device 10. Different clients can request services from different servers 30, and in Figure 1In the diagram, a first client requests a service from a first server, and a second client requests a service from a second server. Of course, different clients can also request services from the same server 30; accordingly, the same client can request services from one server 30, or from multiple servers 30 for different services. In either case, if a client needs to use the service provided by the server, data transmission is required between the client and the server.

[0039] In this embodiment, an edge node 20 is added between the terminal device 10 and the server 30. The edge node 20 includes a series of edge infrastructure, including but not limited to: distributed data centers (DCs), wireless computer rooms or clusters, operator communication networks, core network equipment, base stations, edge gateways, home gateways, computing devices and / or storage devices, and corresponding network environments. It should be noted that in this embodiment, there can be one or more edge nodes 20. In the case of multiple edge nodes 20, the locations, capabilities, and infrastructure included in different edge nodes 20 can be the same or different.

[0040] Compared to server 30, edge node 20 is relatively close to terminal device 10. The client on terminal device 10 accesses server 30 through edge node 20 instead of through the public network, which helps reduce response latency, cloud pressure, and bandwidth costs. Optionally, edge node 20 can connect to server 30 via a dedicated line (referred to as a dedicated line) to further improve data transmission reliability, security, and transmission rate.

[0041] With the continued growth of end-side applications, in order to improve user experience, the embodiments of the present application provide a new tunnel transmission mechanism. Based on this new tunnel transmission mechanism, the client on the terminal device 10 can be connected to the edge node 20 closer to the user in a tunnel manner through static bandwidth, and then connected to the server 30 from the edge node 20 through a dedicated line. This tunnel access method can, on the one hand, shorten the public network link, reduce dependence on the public network, and provide more reliable transmission quality than public network transmission; on the other hand, it can enable the edge node 20 to quickly perceive and recover from packet loss on the tunnel link, and implement packet retransmission on the tunnel link, while ensuring transmission efficiency and improving the performance of tunnel-based data transmission.

[0042] The tunnel transmission mechanism provided in the embodiment of the present application can be applied to Figure 1 The application scenarios shown are, but not limited to Figure 1 The application scenario shown in the figure can adopt the tunnel transmission mechanism provided by the embodiment of the present application in various scenarios involving data transmission between the client and the server. Figure 1The tunnel transmission mechanism provided by the embodiments of the present application is described by taking the data transmission between the first client and the first server in the illustrated scenario as an example. The first client and the first server in the illustrated scenario can be clients and servers that need to perform data transmission in other application scenarios. Figure 1 The first client and the first server in the illustrated scenario can also be clients and servers that need to perform data transmission in other application scenarios.

[0043] The tunnel transmission mechanism provided by the embodiments of the present application can be implemented by a tunnel client and a tunnel server. The tunnel client is a client program for tunnel management, and the tunnel server is a server program for tunnel management, which can be deployed between the first client and the first server to provide tunnel services for the first client and the first server. Preferably, the tunnel client is deployed close to the first client, and the tunnel server is deployed close to the first server. The tunnel client can be deployed on the device where the first client is located, which is referred to as on-machine deployment, but is not limited thereto. The tunnel client can also be deployed on another device other than the device where the first client is located, and the device where the tunnel client is located is communicatively connected to the device where the first client is located, which is referred to as cross-machine deployment. In the illustrated application scenario, the tunnel client is deployed on the terminal device 10 (i.e., on-machine deployment), and the tunnel server is deployed on the edge node 20. Figure 1 The tunnel client is deployed on the terminal device 10 (i.e., on-machine deployment), and the tunnel server is deployed on the edge node 20 in the illustrated application scenario. In this way, each client on the terminal device 10 can access the edge node 20 through a tunnel, and then access the corresponding server 30 through the edge node 20.

[0044] It is explained that the tunnel client and the tunnel server can provide tunnel services for other clients and servers in addition to providing tunnel services for the first client and the first server. The first client and the first server are only taken as examples for description in the embodiments of the present application.

[0045] In the embodiments, a tunnel connection (TunnelConnection) is established between the tunnel client and the tunnel server. The tunnel connection refers to a transport layer connection between the tunnel client and the tunnel server, and the transport layer connection has tunnel bearing capability. The tunnel transmission mechanism provided by the embodiments of the present application can be implemented based on the tunnel connection between the tunnel client and the tunnel server, that is, a tunnel (Tunnel) for data transmission between the first client and the first server can be established on the tunnel connection. The tunnel can also be understood as a channel responsible for transmitting data between the first client and the first server between the tunnel client and the tunnel server. For ease of description and distinction, the tunnel for data transmission between the first client and the first server is referred to as the first tunnel.

[0046] Optionally, the tunnel connection of the embodiment can be a connection (Connection) oriented connection and can support both reliable transmission mode and unreliable transmission mode, for example, can be but not limited to QUIC connection. Among them, the reliable transmission mode refers to the transmission mode that can perform packet loss retransmission until the transmission is successful when the data packet fails to transmit (referred to as packet loss). The unreliable transmission refers to the transmission mode that does not perform packet loss retransmission when the data packet fails to transmit.

[0047] The tunnel connection of the embodiment can use different data packets to implement reliable transmission and unreliable transmission. In order to distinguish the transmission capabilities of the tunnel connection, reliable data packets and unreliable data packets are provided, the reliable data packets and the unreliable data packets have different data formats, the tunnel connection uses the reliable data packets when implementing the reliable transmission, and the tunnel connection uses the unreliable data packets when implementing the unreliable transmission. Among them, according to the difference in the specific implementation of the tunnel connection, the implementation modes of the reliable data packets and the unreliable data packets will also be different. Taking the QUIC connection as an example, reliable transmission and unreliable transmission can be implemented through different transmission frames. When the QUIC connection implements reliable transmission, a stream (Stream) type transmission frame (referred to as Stream frame) can be used. The Stream frame is used for reliable byte stream transmission, the Stream frame is retransmitted until the transmission is successful when the Stream frame packet is lost, and the Stream frame is ack-eliciting. When the QUIC connection implements unreliable transmission, a non-reliable transmission frame (Datagram) can be used for non-reliable data transmission, that is, the Datagram frame is not retransmitted when the Datagram frame packet is lost, but the Datagram frame is ack-eliciting. The tunnel connection of the embodiment can be implemented as other connections similar to the QUIC connection in addition to the QUIC connection.

[0048] In the embodiment of the application, data transmission needs to be performed between the first client and the first server at the application layer, and the data transmission process can be one-way or two-way, which is not limited. In the embodiment of the application, the transmission protocol used for data transmission between the first client and the first server is also not limited, for example, a connection-oriented transmission protocol such as TCP or QUIC can be used, or a non-connection-oriented transmission protocol such as UDP can be used. In the embodiment of the application, the first client and the first server do not directly perform data transmission, but establish a first tunnel carrying data transmission between the first client and the first server based on the tunnel connection between the tunnel client and the tunnel server, and the first client and the first server perform data transmission through the first tunnel. Tunnel-based data transmission is beneficial to improve data transmission efficiency and security.

[0049] For ease of description, the transmission protocol adopted between the first client and the first server is denoted as a target transmission protocol, for example, a UDP or TCP protocol. On this basis, the general process of data transmission between the first client and the first server through the first tunnel includes: when the first client needs to send application data to the first server, the first client encapsulates the application data to be sent into a first data packet, for example, a UDP packet or a TCP packet, according to the target transmission protocol, and then sends the first data packet to the tunnel client. The tunnel client parses the useful data from the first data packet, and then sends the useful data to the tunnel server through the first tunnel after tunnel encapsulation. The tunnel server obtains the useful data by decapsulating the packet transmitted by the first tunnel, and then forwards the useful data to the first server through the communication link between the tunnel server and the first server after protocol encapsulation according to the target transmission protocol. Similarly, when the first server needs to send an application to the first client, the first server encapsulates the application data to be sent into a first data packet, for example, a UDP packet or a TCP packet, according to the target transmission protocol, and then sends the first data packet to the tunnel server. The tunnel server parses the useful data from the first data packet, and then sends the useful data to the tunnel client through the first tunnel after tunnel encapsulation. The tunnel client obtains the useful data by decapsulating the packet transmitted by the first tunnel, and then forwards the useful data to the first client after protocol encapsulation according to the target transmission protocol.

[0050] Among them, according to the difference of the target transmission protocol, the useful data parsed from the first data packet by the tunnel client or the tunnel server will be different. If it is a TCP protocol, the TCP header and the payload part in the first data packet can be used as useful data, and if it is a UDP or QUIC protocol, the UDP payload part in the first data packet can be used as useful data.

[0051] Among them, according to the difference of the deployment mode of the first client and the tunnel client, the way of data transmission between them will also be different. If the first client and the tunnel client belong to the same machine deployment, the tunnel client can be embedded in the first client as a functional module, an application programming interface (API) or a software development kit (SDK), etc. Then the first client can communicate with the tunnel client through API or function call, etc. to transmit the first data packet to the tunnel client. If the first client and the tunnel client belong to cross-machine deployment, the first client can send the first data packet to the tunnel client through the communication link between the terminal device where the first client is located and the device where the tunnel client is located.

[0052] exist Figure 1 In the example, the QUIC protocol is used between the first client and the first server. QUIC is based on UDP, so the protocol type is UDP. The QUIC connection between the tunnel client and the tunnel server is used as an example. Figure 1 In the example, the first client and the tunnel client are located on the same terminal device 10. The tunnel client provides a tunnel service for the first client and the first client on the terminal device 10 based on the QUIC connection between the tunnel client and the tunnel server. The first client uses the first tunnel (i.e. Figure 1 The first client transmits data to the first server through the tunnel 1 shown in FIG. 1 , and the first client transmits data to the first server through the second tunnel (i.e. Figure 1 2) is connected to the first server; tunnels 1 and 2 are carried on the QUIC connection between the tunnel client and the tunnel server. It should be noted that the tunnel client can provide tunnel services for any client and server that need to transmit data. The process of providing tunnel services for each pair of clients and servers that need to transmit data is the same or similar. In the following embodiments, the first client and the first server are used as an example for description.

[0053] In the following embodiments, combined with relevant drawings, taking QUIC connection as an example, the tunnel transmission mechanism provided in the embodiments of the present application is described in detail from multiple angles such as tunnel establishment, tunnel-based data transmission, tunnel closing, and closing of tunnel connection.

[0054] in, Figure 2a This is a schematic diagram of an interactive process of a tunnel establishment method provided in an embodiment of the present application. Figure 2a As shown, the tunnel establishment method includes:

[0055] 21. When the first client needs to communicate with the first server, the first client sends the identification information of the first server to the tunnel client via an out-of-band message.

[0056] The identification information of the first server includes: the IP address, port number (port) and transmission protocol (protocol) type of the first server. Figure 1 In the example, the first client sends data to the first server. The first server serves as the target end, its IP address is sip1, the port number is sport1, and the protocol type is externally reflected as UDP, specifically QUIC based on UDP.

[0057] The transmission method used by the first client to send the data packet to the tunnel client for transmission through the tunnel is considered an in-band message method. In contrast, the transmission method used by the first client to send the identification information of the first server to the tunnel client is considered an out-of-band message method. In other words, the first client uses different transmission methods to send the data packet and the identification information of the first server to the tunnel client. Optionally, the out-of-band message method can be an API call or a message.

[0058] 22. After receiving the identification information of the first server, the tunnel client determines whether a tunnel connection already exists between it and the tunnel server. In this embodiment, the tunnel connection refers to a QUIC connection. If a QUIC connection does not already exist between the tunnel client and the tunnel server, step 23 is executed. If a QUIC connection already exists between the tunnel client and the tunnel server, step 24 is executed.

[0059] 23. The tunnel client establishes a QUIC connection with the tunnel server, establishes a control flow adapted to the QUIC connection, and then executes step 24.

[0060] When the tunnel connection uses other connections, its establishment process is similar or identical to the QUIC connection establishment process, and supports 1-RTT and 0-RTT establishment processes. Among them, the 1-RTT establishment process refers to the establishment process that requires 1 round-trip time (RTT), and the 0-RTT establishment process refers to the establishment process that requires 0 RTT. When the tunnel connection is established in the form of 0-RTT, both control frames and data packets can be sent in the form of 0-RTT. Among them, the QUIC connection establishment process is as follows:

[0061] 1. The tunnel client sends a connection request to the tunnel server, requesting the key generation algorithm to generate the parameters required for the key. The key generation algorithm can be but is not limited to the DH (Diffie-Hellman) algorithm.

[0062] 2. The tunnel server returns the parameters required for the key generation algorithm and the public key of the tunnel server to the tunnel client.

[0063] 3. After receiving the parameters required by the key generation algorithm and the public key of the tunnel server, the tunnel client generates a key based on the key generation algorithm, the parameters and the public key, and sends the public key of the tunnel client to the tunnel server.

[0064] At this point, the tunnel client can now securely transmit data with the tunnel server using the key. In this embodiment, data transmission between the tunnel client and the tunnel server is performed over a tunnel carried by the tunnel connection, rather than directly over the tunnel connection. Furthermore, if the tunnel connection carries multiple tunnels, different tunnels are responsible for transmitting data between different clients and the server.

[0065] 4. After receiving the public key of the tunnel client, the tunnel server can generate a corresponding key based on the key generation algorithm, the above parameters and the public key of the tunnel client. The key is used to decrypt the encrypted data sent by the tunnel client.

[0066] In the above process, it only takes one RTT for the tunnel client and tunnel server to generate a symmetric key, and data transmission can be securely performed based on the symmetric key.

[0067] Furthermore, the tunnel client can save the parameters required for the key generation algorithm. Based on this, when the tunnel client re-establishes a QUIC connection with the tunnel server, it can directly generate a key based on the saved parameters, use this key to encrypt the data message, and transmit the tunnel client's public key to the tunnel server at the same time as transmitting the encrypted message to the tunnel server. In this way, the tunnel server can also use the tunnel client's public key to generate a key and then decrypt the encrypted data, thus completing the 0-RTT connection process.

[0068] In this embodiment, after the tunnel connection is established, Figure 1 As shown, the tunnel client and the tunnel server will also establish a unidirectional control stream (Control Stream) in each data transmission direction of the tunnel connection, which is used to exchange control information between the two ends of the tunnel connection (i.e., the tunnel client and the tunnel server). These control information can be transmitted in the control stream through control frames (Control Frame). Control frames are data units transmitted on the control stream, and there are multiple types. Different types of control frames are used to exchange different control information between the tunnel client and the tunnel server. In this embodiment, the control frame is mainly used to set the status of the tunnel connection and the status of the tunnel. It should be noted that in this embodiment, the control frame will not participate in the process of tunnel establishment. This is because the tunnel establishment process of this embodiment does not depend on the control frame. For the tunnel establishment process of this embodiment, please refer to the description below and will not be described in detail here. The relationship between the control stream, control frame and tunnel connection is as follows. Figure 1 shown.

[0069] 24. The tunnel client and the tunnel server cooperate with each other to establish a first tunnel on the QUIC connection, where the first tunnel is used to carry data transmission between the first client and the first server.

[0070] In this embodiment, the first tunnel is a channel carried on the QUIC connection between the tunnel client and the tunnel server, and is responsible for transmitting data packets between the first client and the first server. In this embodiment, the first tunnel uses unreliable data packets to carry data packets between the first client and the first server, that is, the first tunnel of this embodiment is a tunnel implemented using unreliable data packets. In this embodiment, the tunnel implemented using unreliable data packets can support unreliable transmission. Among them, the tunnel supporting unreliable transmission refers to a data transmission method in which when the tunnel transmission of an unreliable data packet fails (i.e., packet loss occurs), there is no need to retransmit the unreliable data packet (i.e., packet loss) that failed to be transmitted.

[0071] It is hereby explained that in the embodiments of the present application, the first tunnel implemented using unreliable data packets can support unreliable transmission, but this does not mean that the first tunnel can only support unreliable transmission. In some optional embodiments, it can be assumed that the first tunnel only supports unreliable transmission. In other optional embodiments, the capabilities of the first tunnel can be expanded so that the first tunnel can support partially reliable transmission and / or fully reliable transmission on the basis of supporting unreliable transmission, and allow the first client to decide which transmission mode of the first tunnel specifically implements unreliable transmission, partially reliable transmission and fully reliable transmission through configuration. For details about this implementation method, please refer to the description in the subsequent embodiments and will not be described in detail here. Among them, the tunnel supports partially reliable transmission, which means that when the transmission of an unreliable data packet fails (i.e., packet loss) through the tunnel, the unreliable data packet that failed to be transmitted (i.e., packet loss) needs to be retransmitted according to the number of retransmissions configured by the first client. The tunnel supports fully reliable transmission, which means that when the transmission of an unreliable data packet fails (i.e., packet loss) through the tunnel, the unreliable data packet that failed to be transmitted (i.e., packet loss) needs to be retransmitted, and the number of retransmissions is not limited until the transmission is successful.

[0072] In the embodiment, the tunnel client and the tunnel server cooperate with each other, and the process of establishing the first tunnel on the QUIC connection mainly refers to: the tunnel client obtains the identification information of the first server, performs tunnel resource initialization based on the tunnel connection to obtain the identification information of the first tunnel, provides the identification information of the first tunnel and the identification information of the first server to the tunnel server, and the tunnel server locally establishes and maintains the forwarding mapping relationship between the first tunnel and the first server. The identification information of the first tunnel can be any information capable of uniquely identifying the tunnel, for example, but not limited to: the ID or sequence number of the first tunnel. The forwarding mapping relationship between the first tunnel and the first server is used for the tunnel server to perform data forwarding between the first tunnel and the first server. The process of the tunnel server performing data forwarding between the first tunnel and the first server includes: the tunnel server unpacks the unreliable data packet from the first tunnel to obtain useful data, re-encapsulates the useful data according to the protocol type used by the first server, and forwards the re-encapsulated data packet to the first server according to the identification information of the first server.

[0073] The forwarding mapping relationship between the first tunnel and the first server includes the identification information of the first tunnel and the IP address, port number and protocol type of the first server. When the tunnel server performs data forwarding between each tunnel and each application server (for example, the first server), the tunnel server also needs to have an IP address and a port number. Optionally, the tunnel server has a unique IP address and port number, and the unique IP address and port number can be used to perform data forwarding between each tunnel and each application server. Alternatively, the tunnel server has multiple IP addresses and port numbers, and in this case, the tunnel server can assign the same IP address and port number to different tunnels when performing data forwarding between different tunnels and application servers, or can assign different IP addresses and port numbers to different tunnels. Based on this, in order to record the IP address and port number assigned by the tunnel server to different tunnels, the forwarding mapping relationship between the first tunnel and the first server can also include the IP address and port number assigned by the tunnel server to the first tunnel, regardless of whether the IP address and port number assigned by the tunnel server to different tunnels are the same.

[0074] Further, in the data packet forwarding process, the tunnel server and the first server are equivalent to two ends of the communication, therefore, the IP address and port allocated by the tunnel server for the first tunnel, the IP address and port of the first server, and the protocol type used therebetween (that is, the type of the transmission protocol used between the first client and the first server), can form the five-tuple information required for the communication between the tunnel server and the first server, that is, the forwarding mapping relationship between the first tunnel and the first server can be implemented as: the identification information of the first tunnel and the five-tuple information required for the communication between the tunnel server and the first server. Wherein, the forwarding mapping relationship between different tunnels and application servers can form a forwarding mapping relationship table, including the identification information and five-tuple information of each tunnel, as shown in Figure 1 In Figure 1 which, the identification information of the first tunnel is represented as "#1", the IP address allocated by the tunnel server for the first tunnel is recorded as tnl_ip, the port number is recorded as tnl_port1, and the five-tuple information is: tnl_ip, tnl_port1, sip1, sport1, UDP.

[0075] In the embodiment, in order for the tunnel server to be able to locally establish and maintain the above-mentioned forwarding mapping relationship, the identification information of the first tunnel and the identification information of the first server need to be provided to the tunnel server. In the embodiment of the present application, instead of providing the above-mentioned identification information of the first tunnel and the identification information of the first server to the tunnel server through the control flow between the tunnel client and the tunnel server, a new tunnel establishment method based on long and short packet header information is provided to provide the identification information of the first tunnel and the identification information of the first server to the tunnel server in a manner different from the control flow. In the embodiment, the reason why the tunnel establishment is not performed through the control flow is as follows:

[0076] On the basis that the QUIC connection has been established or the key negotiation has been completed, after obtaining the identification information of the first tunnel, the tunnel client can encrypt and tunnel encapsulate the data packet and transmit it to the tunnel server through the first tunnel in order to improve the data transmission efficiency. In this case, if the tunnel establishment is performed through the control flow (that is, the above-mentioned identification information of the first tunnel and the identification information of the first server are provided to the tunnel server through the control frame), because the control flow and the first tunnel are different transmission channels, the phenomenon of loss of the control frame for tunnel establishment or out-of-order of the control frame and the data packet encapsulated through the tunnel at the tunnel server end may occur in the control flow. If the control frame for tunnel establishment is lost or the data packet arrives at the tunnel server before the control frame, at this time the tunnel server has not established the forwarding mapping relationship between the first tunnel and the first server, which will cause the problem of discarding or blocking of the data packet on the tunnel server.

[0077] The tunnel establishment method based on long and short header information provided in the embodiment of the present application can solve the above problem. The tunnel establishment method is also a detailed implementation process of the above step 24. Specifically, Figure 2b As shown, the method includes the following steps:

[0078] 241. The tunnel client responds to the tunnel establishment request initiated by the first client, obtains identification information of the first server, initializes tunnel resources on its own end, obtains identification information of the first tunnel, and enables long header mode during the initial tunnel establishment phase. The tunnel establishment request is used to request establishment of a first tunnel between the first client and the first server, carrying data transmission, based on the tunnel connection between the tunnel client and the tunnel server.

[0079] The identification information of the first server can be obtained from the out-of-band message. Initializing the tunnel resources on the local end includes: creating resource information required for the first tunnel on the local end, such as the identification information and data structure of the first tunnel, and establishing an association between the first tunnel and the tunnel connection, wherein the data structure stores the identification information of the first tunnel and identification information (Connection ID, CID) of the tunnel connection corresponding to the first tunnel.

[0080] 242. The tunnel client encapsulates the data message sent from the first client to the first server into a first unreliable data packet according to the first packet header information, where the first packet header information includes identification information of the first server and identification information of the first tunnel.

[0081] 243. The tunnel client sends a first unreliable data packet carrying first packet header information to the tunnel server, so that the tunnel server establishes a forwarding mapping relationship between the first tunnel and the first server and forwards the first unreliable data packet according to the first packet header information.

[0082] 244. The tunnel server receives a first unreliable data packet sent by the tunnel client, and parses the first unreliable data packet to obtain first packet header information.

[0083] 245. The tunnel server establishes a forwarding mapping relationship between the first tunnel and the first server according to the first packet header information, and forwards the first unreliable data packet.

[0084] 246. The tunnel server returns a confirmation message corresponding to the first unreliable data packet to the tunnel client.

[0085] The order of step 245 and step 246 is not limited.

[0086] 247. After receiving the confirmation message returned by the tunnel server for the first unreliable data packet, the tunnel client switches to the short header mode, that is, according to the second header information, the data message sent by the first client to the first server is encapsulated into a second unreliable data packet, and the second header information includes the identification information of the first tunnel.

[0087] 248. The tunnel client transmits a second unreliable data packet carrying the second packet header information in the first tunnel, so that the tunnel server forwards the second unreliable data packet according to the second packet header information and the forwarding mapping relationship.

[0088] 249. The tunnel server receives a second unreliable data packet transmitted by the tunnel client through the first tunnel, and forwards the second unreliable data packet according to the second packet header information and the forwarding mapping relationship.

[0089] In this embodiment, during the initial phase of establishing the first tunnel, the tunnel client has not yet confirmed whether the tunnel server has established and maintained the state related to the first tunnel, primarily referring to the forwarding mapping relationship between the first tunnel and the first server. Therefore, the tunnel client uses a long header mode, i.e., tunnel-encapsulating the data packet sent from the first client to the first server into a first unreliable data packet using the first header information and then sending the data packet. The first header information is long and includes information such as identification information of the first tunnel, the IP address of the first server, the port number, and the protocol type.

[0090] Specifically, a data packet sent from a first client to a first server is tunnel-encapsulated using the first header information, resulting in an unreliable data packet carrying the first header information. Specifically, useful data can be parsed from the data packet, and the useful data is first tunnel-encapsulated based on the first header information, followed by sequential encapsulation of UDP header information, IP header information, and the like, resulting in an unreliable data packet carrying the first header information. Accordingly, a data packet sent from a first client to a first server is tunnel-encapsulated using the second header information, resulting in an unreliable data packet carrying the second header information. Specifically, useful data can be parsed from the data packet, and the useful data is first tunnel-encapsulated based on the second header information, followed by sequential encapsulation of UDP header information, IP header information, and the like, resulting in an unreliable data packet carrying the second header information. Regarding the method of parsing useful data: if the TCP protocol is used between the first client and the first server, the TCP header and payload part in the data message are used as useful data; if UDP is used between the first client and the first server, the UDP payload part in the data message is used as useful data; if the QUIC protocol is used between the first client and the first server, the QUIC header and payload part in the data message are used as useful data, such asFigure 1 and Figure 2c For easy distinction, the unreliable data packet carrying the first header information is referred to as a first unreliable data packet, and the unreliable data packet carrying the second header information is referred to as a second unreliable data packet.

[0091] Further, if Figure 2c As shown, before the tunnel client confirms whether the tunnel server has established and maintained the state related to the first tunnel, one or more first unreliable data packets can be sent to the tunnel server. Figure 2c In the example, the sending of three first unreliable data packets is used as an example. Optionally, a format of the first unreliable data packet is as follows: Figure 2c As shown, from the inside to the outside, it includes: payload, application layer protocol header (QUIC), long packet header information (Tunnel (L)), encapsulation information of unreliable data packets (such as Datagram), tunnel connection (QUIC) information, UDP header information and IP header information.

[0092] For the tunnel server, upon successfully receiving the first first unreliable data packet, a forwarding mapping relationship between the first tunnel and the first server can be established based on the first packet header information carried in the first received first unreliable data packet. It should be noted that the first received first unreliable data packet is not necessarily the first first unreliable data packet sent by the tunnel client.

[0093] At the tunnel connection level (such as QUIC connection), the tunnel server will confirm (ACK) any unreliable data packets received, so if Figure 2c As shown, the tunnel server returns a confirmation message to the tunnel client, each confirmation message including the sequence number of the first unreliable data packet. Optionally, an optional format of the confirmation message is as follows: Figure 2c As shown, from the inside to the outside, it includes the sequence number of the confirmation data packet (such as ACK#1, #2-3), the information of the tunnel connection (QUIC), the UDP header information and the IP header information.

[0094] If the tunnel client finds that any of the first unreliable data packets has been acknowledged (ACKed) by the tunnel server, it can be confirmed that the tunnel server has established and maintained the status related to the first tunnel, which means that the first tunnel has been successfully established between the tunnel client and the tunnel server. At this time, the tunnel client switches to short header mode on the first tunnel. Thereafter, when the tunnel client transmits data packets sent by the first client to the first server on the first tunnel, it uniformly uses the second header information for encapsulation. The second header information is short header information, which mainly contains the identification information of the first tunnel and no longer contains the identification information of the first server. This can save the overhead of the tunnel header, reduce the resources consumed by data transmission, and improve data transmission efficiency.

[0095] It should be noted that, during the tunnel establishment process, only the process of the tunnel client sending the first or second unreliable data packet to the tunnel server is described. Accordingly, after the tunnel is established, the tunnel server can also send unreliable data packets to the tunnel client. Since the tunnel has been successfully established at this point, the unreliable data packet sent from the tunnel server to the tunnel client is a second unreliable data packet using short header information. For example, when the first server needs to send a data packet to the first client, it encapsulates the application data to be sent using the transmission protocol used, obtains a data packet (such as a UDP packet or a TCP packet), and sends it to the tunnel server; after receiving the data packet sent by the first server, the tunnel server searches for the forwarding mapping relationship between the tunnel and the application server based on the five-tuple information carried in the data packet, determines the identification information of the first tunnel corresponding to the five-tuple carried in the data packet, parses the useful data from the data packet, and then encapsulates the useful data into a second unreliable data packet based on the identification information of the first tunnel, and sends it to the tunnel client via the first tunnel; after receiving the second unreliable data packet, the tunnel client parses the useful data from it, re-encapsulates the useful data into a data packet according to the transmission protocol used by the first server and the first client, and sends it to the first client. It is explained here that the transmission of unreliable data packets between the tunnel server and the tunnel client through the first tunnel refers to the process of carrying at least the identification information of the first tunnel in the unreliable data packet, and then sending the unreliable data packet carrying the identification information of the first tunnel (such as the first unreliable data packet or the second unreliable data packet) to the other end.

[0096] In this embodiment, the implementation format of the long and short header information is not limited. The following examples are given: the long header (LongTunnel Header) information includes a tunnel identification (Tunnel ID) field, which indicates which tunnel it is; a flag (Flag) field, which is used to indicate the type of IP address; a server IP address (ServerIP) field, which indicates the IP address of the application server, which IP address can be a 32-bit IPv4 address or a 128-bit IPv6 address, depending on whether the lowest bit in the Flag field is 0 or 1; and a server port (ServerPort) field, which indicates the port number of the application server. Among them, the code examples corresponding to the long header information and the short header information (Short Tunnel Header) are as follows, but are not limited to this. The short header (ShortTunnel Header) information includes a tunnel identification (Tunnel ID) field, which indicates which tunnel it is. Compared with the long header information, no other fields are included.

[0097] Long Tunnel Header

[0098] Tunnel ID(i),

[0099] Flag(8),

[0100] ServerIp(..),

[0101] ServerPort(16),

[0102] }

[0103] Short Tunnel Header

[0104] Tunnel ID(i),

[0105] }

[0106] During the tunnel establishment process, upon receiving the first unreliable data packet or the second unreliable data packet, the tunnel server will also forward the first unreliable data packet or the second unreliable data packet. The forwarding of the first unreliable data packet includes: the tunnel server decapsulating the first unreliable data packet to obtain useful data therefrom; then, based on the IP address, port number, and protocol type of the first server in the first packet header information, encapsulating the useful data to obtain a data packet whose source IP address and source port number are the IP address and port number assigned by the tunnel server for the first tunnel, and whose target IP address and destination port number are the IP address and port number of the first server; and then sending the data packet to the first server. The forwarding processing of the second unreliable data packet includes: the tunnel server decapsulates the second unreliable data packet to obtain useful data therefrom; then, based on the identification information of the first tunnel in the second packet header information, searches for the forwarding mapping relationship between each tunnel and the application server, and obtains the IP address, port number and protocol type of the first server corresponding to the first tunnel; based on the IP address, port number and protocol type of the first server, encapsulates the useful data to obtain a data packet whose source IP address and source port number are the IP address and port number assigned by the tunnel server to the first tunnel, and whose target IP address and destination port number are the IP address and port number of the first server, and sends the data packet to the first server.

[0107] Further, if Figure 2a As shown, after the first tunnel is established, the process further includes: step 25, data transmission between the first client and the first server through the first tunnel.

[0108] The detailed process of transmitting the second unreliable data packet during the tunnel establishment process is the same as the process of transmitting data between the first client and the first server through the first tunnel after the first tunnel is established.

[0109] The first client sends a data packet to the tunnel client. Specifically, if the tunnel client and the first client are deployed on the same machine, the first client sends the data packet to the tunnel client through an API call or a function call. If the tunnel client and the first client are deployed across machines, the first client sends the data packet to the tunnel client through the communication link between its terminal device and the device where the tunnel client is located. The data packet is encapsulated using the transmission protocol used by the first client and the first server, which can be a UDP packet or a TCP packet.

[0110] The tunnel client obtains useful data from the data packet and tunnel-encapsulates the useful data using the second header information to obtain a second unreliable data packet. The second unreliable data packet is then sent to the tunnel server via the first tunnel. After receiving the second unreliable data packet, the tunnel server parses the second header information and useful data from it. Then, based on the identification information of the first tunnel carried in the second header information, it searches for the forwarding mapping relationship between each tunnel and the application server, and obtains the IP address, port number, and protocol type of the first server corresponding to the first tunnel, or the five-tuple information corresponding to the first tunnel. Then, based on the IP address, port number, and protocol type (or five-tuple information) of the first server, the useful data is encapsulated in a new data packet and sent to the first server.

[0111] In an embodiment of the present application, whether during the tunnel establishment process or after the tunnel establishment is completed, in the process of transmitting unreliable data packets based on the tunnel, the problem of unreliable data packet transmission failure, that is, the packet loss problem, may occur. In this embodiment, the first tunnel is a tunnel that uses unreliable data packets (such as Datagram), and Datagram provides unreliable transmission capabilities, which means that packet loss occurring on the tunnel connection will not be retransmitted at the tunnel connection level. If an unreliable transmission protocol (such as UDP) is used between the first client and the first server, it means that the application layer does not pay attention to the data packets that are lost on the tunnel connection. If a reliable transmission protocol is used between the first client and the first server, it means that the application layer needs to rely on the packet loss retransmission mechanism to retransmit the data packets that are lost on the tunnel connection. If the packet loss retransmission mechanism at the application layer is simply relied upon to retransmit the data packets that are lost on the tunnel connection, the efficiency of data retransmission is low and the flexibility is insufficient. Therefore, in an embodiment of the present application, the capability of a tunnel supporting unreliable transmission is improved, and a data retransmission mechanism for a tunnel supporting unreliable transmission is provided. This mechanism is mainly applied to a tunnel supporting unreliable transmission, that is, a tunnel implemented using unreliable data packets (such as Datagram), so that the tunnel originally supporting unreliable transmission has data retransmission capability, that is, in the process of transmitting unreliable data packets, in addition to being able to perform unreliable transmission, the tunnel can also perform partial reliable transmission and can also perform fully reliable transmission, solving the problem that the tunnel can only achieve reliable transmission or unreliable transmission, improving the flexibility of data retransmission, and while ensuring data transmission efficiency, it can also improve data transmission performance to meet more application requirements. Furthermore, when proposing a data retransmission mechanism for a tunnel supporting unreliable transmission, the following issues are also comprehensively considered, as follows:

[0112] When a reliable transport protocol is used between the first client and the first server, which can be referred to as the application layer using a reliable transport protocol, if the transmission delay from the first client to the first server is greater than, and significantly greater than, the transmission delay from the tunnel client to the tunnel server, then packet retransmission at the tunnel connection layer can be completed more quickly than at the application layer. In this case, the application layer will not perceive the packet loss issue, which is equivalent to masking the packet loss issue at the application layer and is beneficial to improving transmission performance at the application layer. The above transmission delay can be a one-way transmission delay or a round-trip transmission time, or RTT.

[0113] However, when the transmission delay from the first client to the first server is close to the transmission delay from the tunnel client to the tunnel server, retransmission at the tunnel connection cannot mask packet loss at the application level. The time required to retransmit packet loss at the tunnel connection level is not much different from that required to retransmit packet loss at the application level. In this case, in addition to retransmitting packet loss at the application level, you can also choose to retransmit packet loss at the tunnel level. Retransmitting packet loss at both levels helps improve data retransmission reliability. Alternatively, you can choose not to retransmit packet loss at the tunnel level and only retransmit packet loss at the application level to save retransmission costs.

[0114] In addition, if the transmission delay from the first client to the first server is greater than, and significantly greater than, the transmission delay from the tunnel client to the tunnel server, and if the number of retransmissions for packet loss retransmission at the tunnel connection level is not limited, then if the number of retransmissions exceeds a certain number but still fails, the application level will perceive the packet loss and trigger packet loss retransmission at the application level. In this case, continuing to retransmit packet loss at the tunnel connection level can improve retransmission reliability, but it will also increase retransmission costs. If the number of retransmissions for each data packet can be flexibly limited at the tunnel connection level based on application requirements, the flexibility of the data retransmission mechanism at the tunnel connection level can be further improved.

[0115] Based on the above, the data retransmission mechanism applied to tunnels supporting unreliable transmission proposed in the embodiment of the present application supports flexible configuration functions, allows flexible customization of data retransmission strategies at the tunnel connection level according to application requirements, and realizes fully reliable transmission, partially reliable transmission or completely unreliable transmission on demand on tunnels supporting unreliable transmission, enriching the retransmission mechanism when the tunnel performs data transmission. Compared with tunnels that can only perform fully reliable transmission or completely unreliable transmission, it can better balance the retransmission cost and transmission performance.

[0116] In the following embodiment, the first tunnel is taken as an example. Figure 3a - Figure 3b From data retransmission configuration to data retransmission process, the data retransmission mechanism provided in the embodiment of the present application is explained.

[0117] like Figure 3a As shown, a tunnel-based data retransmission process provided in an embodiment of the present application includes the following steps:

[0118] 31. The first client generates a retransmission count for transmitting an unreliable data packet through the first tunnel. The definition and related introduction of the first tunnel are the same as those in the previous embodiment and are not repeated here.

[0119] 32. The first client sends configuration information to the tunnel client, where the configuration information includes a number of retransmissions for transmitting unreliable data packets through the first tunnel.

[0120] 33. The tunnel client receives the configuration information sent by the first client, and obtains therefrom the number of retransmissions for transmitting unreliable data packets through the first tunnel.

[0121] 34. The tunnel client synchronizes the above retransmission count to the tunnel server through the reliable data packet in the control flow, so that the tunnel server maintains the retransmission count locally.

[0122] 35. During the process of transmitting the unreliable data packet based on the first tunnel, the tunnel client detects whether an unreliable data packet transmission failure occurs.

[0123] 36. If a transmission failure of an unreliable data packet is detected, the tunnel client obtains the number of retransmissions in the configuration information and retransmits the unreliable data packet that has failed to be transmitted in the first tunnel.

[0124] In an embodiment of the present application, the first client can configure the number of times that an unreliable data packet in the first tunnel can be retransmitted according to application requirements, allowing the unreliable data packet that fails to be transmitted in the first tunnel to be retransmitted according to the number of retransmissions, thereby achieving reliable transmission in a tunnel that supports unreliable transmission and meeting the first client's requirements for transmission reliability.

[0125] In an optional embodiment, the reliable transmission implemented in the tunnel supporting unreliable transmission can be partial reliable transmission. Alternatively, in another optional embodiment, the reliable transmission implemented in the tunnel supporting unreliable transmission can be further divided into partial reliable transmission and complete reliable transmission, so that a tunnel supporting partial reliable transmission, complete reliable transmission and unreliable transmission is obtained, and the first client can be flexibly configured according to application requirements to meet various transmission requirements of the first client. Wherein, whether the tunnel implements partial reliable transmission, complete reliable transmission or unreliable transmission can be distinguished by the value of the retransmission number. Based on this, in an optional embodiment, the retransmission processing of the non-reliable data packet that fails to transmit in the first tunnel in step 36 above can be divided into the following three processing modes according to the value of the retransmission number: if the retransmission number in the configuration information is in the preset number interval, step 361 is executed; if the retransmission number in the configuration information is a first reserved value, step 362 is executed; and if the retransmission number in the configuration information is a second reserved value, step 363 is executed.

[0126] 361. In the case where the retransmission number obtained from the configuration information is in the preset number interval, the non-reliable data packet that fails to transmit is retransmitted in the first tunnel, and the retransmission number cannot exceed the retransmission number in the configuration information, to implement partial reliable transmission.

[0127] Specifically, in the case where the retransmission number obtained from the configuration information is in the preset number interval, the non-reliable data packet that fails to transmit can be retransmitted in the first tunnel, and the number of retransmissions of the non-reliable data packet that fails to transmit is recorded; if the non-reliable data packet that fails to transmit is successfully retransmitted before the number of retransmissions of the non-reliable data packet that fails to transmit reaches the retransmission number, the retransmission operation is terminated, if the non-reliable data packet that fails to transmit is not retransmitted successfully, the retransmission of the non-reliable data packet that fails to transmit is continued; if the non-reliable data packet that fails to transmit is not successfully transmitted when the number of retransmissions of the non-reliable data packet that fails to transmit reaches the retransmission number, the retransmission operation of the non-reliable data packet that fails to transmit is terminated.

[0128] 362. When the retransmission number obtained from the configuration information is a first reserved value outside the preset number interval, the retransmission operation of the non-reliable data packet that fails to transmit is prohibited to implement unreliable transmission.

[0129] 363. When the retransmission number obtained from the configuration information is a second reserved value outside the preset number interval, the non-reliable data packet that fails to transmit is retransmitted in the first tunnel until the non-reliable data packet that fails to transmit is successfully transmitted, to implement complete reliable transmission.

[0130] In an embodiment of the present application, the first client can configure the number of times that an unreliable data packet in the first tunnel can be retransmitted according to application requirements, and through the value of the number of retransmissions, limit whether the first tunnel realizes partially reliable transmission, fully reliable transmission or unreliable transmission. In this embodiment, the number of retransmissions configured by the first client for transmitting unreliable data packets through the first tunnel has no necessary relationship with the transmission protocol adopted between the first client and the first server. In the case where an unreliable transmission protocol is adopted between the first client and the first server, the first tunnel can also be configured to realize partially reliable transmission, fully reliable transmission or unreliable transmission. In the case where a reliable transmission protocol is adopted between the first client and the first server, the first tunnel can also be configured to realize partially reliable transmission, fully reliable transmission or unreliable transmission.

[0131] Among them, the tunnel is implemented as fully reliable transmission, which means that when the tunnel transmission of an unreliable data packet fails, the unreliable data packet that failed to be transmitted is retransmitted an unlimited number of times until the retransmission is successful; the tunnel is implemented as unreliable transmission, which means that when the tunnel transmission of an unreliable data packet fails, the unreliable data packet that failed to be transmitted is not retransmitted; the tunnel is implemented as partially reliable transmission, which means that when the tunnel transmission of an unreliable data packet fails, the unreliable data packet that failed to be transmitted is retransmitted, but the number of retransmissions cannot exceed the number of retransmissions pre-configured by the first client for the transmission of unreliable data packets in the first tunnel. When the number of retransmissions reaches the number of retransmissions pre-configured by the first client, the retransmission operation will be terminated even if the retransmission is not successful.

[0132] In this embodiment, a number interval corresponding to partially reliable transmission is pre-set, and a first reserved value and a second reserved value are outside the number interval. When the number of retransmissions configured by the first client for transmitting an unreliable data packet through the first tunnel is within the pre-set number interval, the first tunnel is limited to partially reliable transmission; when the number of retransmissions configured by the first client for transmitting an unreliable data packet through the first tunnel is the second reserved value, the first tunnel is limited to fully reliable transmission; and when the number of retransmissions configured by the first client for transmitting an unreliable data packet through the first tunnel is the first reserved value, the first tunnel is limited to unreliable transmission. In this embodiment of the present application, there are no restrictions on the values ​​of the pre-set number interval, the first reserved value, and the second reserved value. Any value that can serve the aforementioned distinction is applicable to this embodiment of the present application. In an optional embodiment, the first reserved value can be 0 and the second reserved value can be ∞ (infinity), and accordingly, the pre-set number interval can be an open interval from 0 to ∞. Alternatively, in another optional embodiment, the first reserved value can be 10 and the second reserved value can be 100, and accordingly, the pre-set number interval can be a plurality of numerical intervals that do not include 10 and 100. In another optional embodiment, the first reserved value and the second reserved value may also be non-numeric values, for example, the first reserved value may be a, and the second reserved value may be b, where a and b are letters, or for another example, the first reserved value may be "#", and the second reserved value may be "%, where "#" and "%" are special symbols; when the number of retransmissions is set to a or "#", it indicates unreliable transmission; when the number of retransmissions is set to b or "%, it indicates completely reliable transmission. Accordingly, the number interval may be a numerical interval from k1 to k2, and when the number of retransmissions in the configuration information is in the numerical interval from k1 to k2, it indicates partially reliable transmission; or, the number interval may be represented by setting a number threshold K3, and when the number of retransmissions in the configuration information is less than or equal to the number threshold K3, it indicates partially reliable transmission. It is hereby explained that when the first client requires completely reliable transmission at the tunnel level, a tunnel that supports reliable transmission may also be used, and is not limited to the method provided in the embodiment of the present application.

[0133] In an optional embodiment, the first client can consider the transmission protocol adopted between the first client and the first server when generating the number of retransmissions for transmitting the non-reliable data packet via the first tunnel. Specifically, in the case where a reliable transmission protocol is adopted between the first client and the first server and it is considered that the packet loss retransmission should be performed at the tunnel connection level, the number of retransmissions for transmitting the non-reliable data packet via the first tunnel is generated, in which case the number of retransmissions is either within a preset number of times or a second reserved value outside the number of times. That is, in the case where reliable transmission is required at the application level, partial reliable transmission or complete reliable transmission can be configured at the tunnel level to improve the retransmission efficiency and performance by virtue of the advantage that the tunnel level perceives the packet loss speed faster than the application level. The response time interval at which the tunnel level triggers the packet loss retransmission is less than the response time interval at which the application level triggers the packet loss retransmission, and the response time interval herein refers to the time interval for waiting for the feedback acknowledgement message from the opposite end. If the acknowledgement message from the opposite end is not received within the time interval, the packet loss retransmission is triggered.

[0134] Further optionally, in the case where a reliable transmission protocol is adopted between the first client and the first server, the first client can obtain a first transmission delay between the first client and the first server and a second transmission delay between the tunnel client and the tunnel server. If the first transmission delay is greater than the second transmission delay, it is indicated that the packet loss retransmission can be performed at the tunnel connection level, and then the number of retransmissions for transmitting the non-reliable data packet via the first tunnel is generated according to the first transmission delay and the second transmission delay. At this time, the maximum number of times is within a preset number of times, indicating that partial reliable transmission is required for the non-reliable data packet in the first tunnel.

[0135] Optionally, the way of generating the number of retransmissions for transmitting the non-reliable data packet via the first tunnel according to the first transmission delay and the second transmission delay includes but is not limited to calculating the difference between the first transmission delay and the second transmission delay, and when the difference is greater than a set difference threshold value, it is indicated that the first transmission delay is much greater than the second transmission delay, and then the number of retransmissions for transmitting the non-reliable data packet via the first tunnel is generated. Specifically, taking the first transmission delay as the first RTT and the second transmission delay as the second RTT as an example, one way of generating the number of retransmissions for transmitting the non-reliable data packet via the first tunnel can be but is not limited to: retx_num represents the number of retransmissions for transmitting the non-reliable data packet via the first tunnel, represents the floor function, RTT1 represents the RTT between the tunnel client and the tunnel server, RTT2 represents the RTT between the tunnel server and the first server, the second RTT = RTT1, and the first RTT = RTT1 + RTT2.

[0136] Alternatively, optionally, when a reliable transmission protocol is adopted between the first client and the first server, a first transmission delay between the first client and the first server and a second transmission delay between the tunnel client and the tunnel server are obtained; if the first transmission delay is greater than the second transmission delay, and the difference between the first transmission delay and the second transmission delay is greater than a set difference threshold, it means that packet loss retransmission can be performed at the tunnel connection level, and the second reserved value can be directly used as the number of retransmissions for transmitting unreliable data packets through the first tunnel, indicating that the unreliable data packets in the first tunnel need to be transmitted completely reliably.

[0137] Further optionally, when an unreliable transmission protocol (such as UDP) is adopted between the first client and the first server, or when a reliable transmission protocol (such as TCP) is adopted between the first client and the first server, but the difference between the first transmission delay and the second transmission delay is less than or equal to a set difference threshold (indicating that the difference between the two is not large), the first client can use the first reserved value (for example, 0) as the number of retransmissions for transmitting unreliable data packets through the first tunnel, indicating that unreliable transmission of unreliable data packets in the first tunnel is performed.

[0138] It should be noted that, by default, the number of retransmissions used for transmitting unreliable data packets through the first tunnel is set to a first reserved value (such as 0), indicating that unreliable transmission of the unreliable data packets in the first tunnel is performed.

[0139] In either of the above situations, after generating the number of retransmissions for transmitting an unreliable data packet through the first tunnel, the number of retransmissions can be included in configuration information and sent to the tunnel client. This allows the tunnel client to retransmit the unreliable data packet in the first tunnel by obtaining the number of retransmissions in the configuration information if the transmission of the unreliable data packet through the first tunnel fails. Alternatively, the first client can send the configuration information to the tunnel client via an out-of-band message.

[0140] In addition, the tunnel client can connect to the corresponding control flow of the tunnel, for example, by sending the number of retransmissions used for transmitting unreliable data packets through the first tunnel through a control frame for settings (hereinafter referred to as a SETTINGS frame) to the tunnel server, so that the tunnel server can locally configure the number of retransmissions used for transmitting unreliable data packets through the first tunnel, and in the event that the transmission of the unreliable data packets through the first tunnel fails, the unreliable data packets that failed to be transmitted are retransmitted in the first tunnel by obtaining the number of retransmissions in the configuration information. Among them, the control frames in the control flow are reliable data packets, that is, they need to be retransmitted when packet loss occurs at the tunnel connection level.

[0141] In this embodiment, the frame format of the SETTINGS frame is not limited. In combination with the following code, an exemplary frame format includes: a frame type (Type) field, which indicates the type of the control frame. There can be multiple types of control frames in the control stream. Different types of control frames are used to transmit different types of control information. The frame type here indicates that the control frame is a control frame that sets the maximum number of times an unreliable data packet in a tunnel can be retransmitted; a length (Length) field, which indicates the length of the control frame; a tunnel identifier (Tunnel ID) field, which indicates which tunnel it is; and a retransmission count (RetransNum) field, which indicates the maximum number of times an unreliable data packet in the tunnel corresponding to the TunnelID field can be retransmitted.

[0142] SETTINGS Frame

[0143] Type(8),

[0144] Length(i),

[0145] Tunnel ID(i),

[0146] RetransNum(i),

[0147] }

[0148] like Figure 3b As shown, the first RTT (i.e. 80+20=100ms) corresponding to the first application client is much larger than the second RTT (i.e. 20ms), so the number of retransmissions corresponding to the unreliable data packet in tunnel 1 is configured to be 4; the tunnel client maintains the number of retransmissions corresponding to the unreliable data packet in tunnel 1 locally, and on the other hand, notifies the number of retransmissions corresponding to the unreliable data packet in tunnel 1 (i.e. 4) to the tunnel server through the SETTINGS frame. The tunnel server also maintains the number of retransmissions corresponding to tunnel 1 locally, i.e. 4. Figure 3b In the example, the first RTT (ie, 5+20=25ms) corresponding to the second application client is almost the same as the second RTT (ie, 20ms), so the number of retransmissions is not configured for the unreliable data packet in tunnel 2, and the number of retransmissions corresponding to tunnel 2 defaults to 0.

[0149] It should be noted that in the above embodiment, the number of retransmissions used when transmitting unreliable data packets through the first tunnel is generated by the first client, but this is not limited to this. The number of retransmissions used when transmitting unreliable data packets through the first tunnel may also be generated by the tunnel client based on a configuration instruction of the first client. Specifically, the first client may send a configuration instruction to the tunnel client, which is used to instruct the tunnel client to generate the number of retransmissions used when transmitting unreliable data packets through the first tunnel. Based on this, the tunnel client may generate the number of retransmissions used when transmitting unreliable data packets through the first tunnel based on the configuration instruction.

[0150] Optionally, the tunnel client can obtain information such as the transmission protocol used between the first client and the first server, the first transmission delay between the first client and the first server, and the second transmission delay between the tunnel client and the tunnel server based on the configuration instruction; and generate a retransmission count for transmitting unreliable data packets through the first tunnel based on the obtained information. The detailed implementation method for the tunnel client to generate the retransmission count for transmitting unreliable data packets through the first tunnel based on the obtained information is the same or similar to the detailed implementation method for the first client to generate the retransmission count for transmitting unreliable data packets through the first tunnel based on the obtained information, and will not be repeated here.

[0151] Optionally, the first client may include the transmission protocol and first transmission delay used between it and the first server in the configuration indication. Based on this, the tunnel client can parse the configuration indication to determine the transmission protocol and first transmission delay used between the first client and the first server. Alternatively, after receiving the configuration indication, the tunnel client can send an information acquisition request to the first client, and the first client will return the transmission protocol and first transmission delay used between it and the first server based on the information acquisition request.

[0152] Regardless of the method used, after the number of retransmissions for transmitting unreliable data packets in the first tunnel is configured on both the tunnel client and the tunnel server, if packet loss occurs on the first tunnel, whether the packet loss occurs in the direction from the tunnel server to the tunnel client or in the direction from the tunnel client to the tunnel server, the packet loss can be processed by using partially reliable transmission, fully reliable transmission or unreliable transmission according to the number of retransmissions for transmitting unreliable data packets in the first tunnel configured by the first application client.

[0153] Specifically, when packet loss due to transmission failure occurs on the first tunnel, if the number of retransmissions configured by the first client is within a preset number range, it is determined whether the number of retransmissions for the unreliable data packet that failed to be transmitted reaches the number of retransmissions configured by the first client; if the number of retransmissions configured by the first client is not reached, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel; if the number of retransmissions configured by the first client is reached, the retransmission operation of the unreliable data packet that failed to be transmitted is terminated. When the number of retransmissions configured by the first client is the first reserved value, the retransmission operation of the unreliable data packet that failed to be transmitted is directly prohibited. When the number of retransmissions configured by the first client is the second reserved value, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel without limiting the number of retransmissions until the unreliable data packet that failed to be transmitted is successfully transmitted.

[0154] Furthermore, during the transmission of an unreliable data packet through the first tunnel, if the variation of the first transmission delay and / or the second transmission delay is greater than a set variation threshold, the first client may generate a new retransmission count according to the above-described method and send update information to the tunnel client, the update information including the new retransmission count; the tunnel client receives the update information sent by the first client and updates the retransmission count in the configuration information to the new retransmission count included in the update information. The second transmission delay, i.e., the transmission delay of the first tunnel, may be reported by the tunnel client to the first client when the variation of the transmission delay of the first tunnel is greater than a set variation threshold, so that the first client can update the retransmission count based on the transmission delay of the first tunnel; or, the tunnel client may respond to a delay acquisition request from the first client and report the transmission delay of the first tunnel to the first client, so that the first client can update the retransmission count based on the transmission delay of the first tunnel. The first client may determine whether the variation of the transmission delay of the first tunnel is greater than the set variation threshold, and if so, update the retransmission count based on the transmission delay of the first tunnel.

[0155] Furthermore, in an embodiment of the present application, each tunnel carried on the tunnel connection can be closed. Among them, the tunnel can be closed in an active or passive manner. Taking the first tunnel as an example, the situation of actively closing the first tunnel includes but is not limited to: when the first client decides not to use the first tunnel anymore, it can actively request the tunnel client to close the first tunnel; or, when the tunnel server needs to close the first tunnel due to insufficient resources or security considerations, it can actively close the first tunnel; when the tunnel client needs to close the first tunnel due to insufficient resources or security considerations, it can also actively close the first tunnel. When the first tunnel is actively or passively closed, the tunnel client reclaims the identification information occupied by the first tunnel, and the tunnel server deletes the relevant status information of the first tunnel maintained. In addition, the tunnel client will notify the first client that the first tunnel has been closed.

[0156] Among them, the first tunnel can be actively closed by the tunnel client, or by the tunnel server. Regardless of which party actively closes the tunnel, when closing the tunnel, a control frame for closing (CLOSE) the tunnel (referred to as CLOSE frame for short) can be sent through the control flow corresponding to the tunnel connection to notify the other party to close the tunnel. The embodiment of the present application does not limit the frame format for the CLOSE frame. In combination with the following code, a format for the CLOSE frame includes: a frame type (Type) field, indicating the type of the control frame, where the frame type indicates that the control frame is a control frame for closing the tunnel; a length (Length) field, indicating the length of the control frame; a tunnel identifier (Channel ID) field, indicating which tunnel is to be closed; an error code (Error_code) field, indicating the reason information for closing the tunnel.

[0157] CLOSE Frame{

[0158] Type(8),

[0159] Length(i),

[0160] Channel ID(i),

[0161] Error_code(i),

[0162] Reason Phrase(..),

[0163] }

[0164] The passive closure of a tunnel mainly occurs when the tunnel connection (such as a QUIC connection) that carries the tunnel is passively closed. That is, when a tunnel connection is passively closed, all tunnels carried by the tunnel connection will be passively closed.

[0165] No matter the tunnel is closed actively or passively, the tunnel client may notify the application client using the tunnel so that the application client knows that the tunnel has been closed.

[0166] Furthermore, in an embodiment of the present application, the tunnel connection between the tunnel client and the tunnel server may also be closed. The tunnel connection may be actively closed by the tunnel client or the tunnel server, or may be passively closed (such as when the network is interrupted and the tunnel connection times out and is closed). The situations in which the tunnel connection is actively closed include but are not limited to: when the tunnel client believes that the tunnel connection is no longer needed, or when the tunnel client needs to close the tunnel connection due to factors such as insufficient resources or security considerations, or when the tunnel server needs to close the tunnel connection due to factors such as insufficient resources or security considerations, the tunnel connection can be closed through the process of closing the tunnel connection. Before closing the tunnel connection, the tunnel client actively closes all tunnels on the tunnel connection. When the tunnel connection is closed actively or passively, the tunnel client and the tunnel server will reclaim the various resource information occupied by the tunnel connection.

[0167] In the above embodiment, the data transmission processing method and tunnel establishment method provided by the embodiment of the present application are described in detail from the perspective of system interaction. Next, the data transmission processing method and tunnel establishment method provided by the embodiment of the present application are described from the perspectives of the tunnel client, tunnel server, and application client.

[0168] Figure 4a A flow chart of a data transmission processing method provided in an embodiment of the present application. This embodiment is applied to a tunnel client, such as Figure 4a As shown, the method includes:

[0169] 41a. In response to the tunnel establishment request from the first client, establish a first tunnel between the first client and the first server to carry data transmission.

[0170] 42a. Receive configuration information sent by the first client, where the configuration information includes a number of retransmissions for transmitting unreliable data packets through the first tunnel.

[0171] 43a. When the unreliable data packet fails to be transmitted in the first tunnel, retransmit the unreliable data packet that failed to be transmitted in the first tunnel by obtaining the number of retransmissions in the configuration information.

[0172] In an optional embodiment, by obtaining the number of retransmissions in the configuration information, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel, including: when the number of retransmissions obtained from the configuration information is within a preset number range, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel; if the number of retransmissions of the unreliable data packet that failed to be transmitted reaches the number of retransmissions obtained from the configuration information and the transmission is still not successful, then the retransmission operation of the unreliable data packet that failed to be transmitted is terminated.

[0173] Further optionally, when the number of retransmissions obtained from the configuration information is within a preset number range, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel, and the number of retransmissions of the unreliable data packet that failed to be transmitted is recorded; if the number of retransmissions of the unreliable data packet that failed to be transmitted does not reach the number of retransmissions before the retransmission number is successfully retransmitted, the retransmission operation is terminated; if the retransmission is not successful, the unreliable data packet that failed to be transmitted continues to be retransmitted; if the number of retransmissions of the unreliable data packet that failed to be transmitted reaches the number of retransmissions before the transmission number is still not successfully transmitted, the retransmission operation of the unreliable data packet that failed to be transmitted is terminated.

[0174] In an optional embodiment, by obtaining the number of retransmissions in the configuration information, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel, and also includes: when the number of retransmissions obtained from the configuration information is a second reserved value outside the number range, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel until the transmission is successful.

[0175] In an optional embodiment, the method of this embodiment further includes: when the number of retransmissions obtained from the configuration information is a first reserved value outside the number interval, prohibiting retransmission of the unreliable data packet that has failed to be transmitted.

[0176] In an optional embodiment, the method of this embodiment also includes: synchronizing the number of retransmissions in the configuration information to the tunnel server through the reliable data packet in the control flow, so that when the tunnel server fails to transmit the unreliable data packet, the unreliable data packet that failed to be transmitted is retransmitted in the first tunnel according to the number of retransmissions.

[0177] In an optional embodiment, the method of this embodiment also includes: during the process of transmitting unreliable data packets through the first tunnel, receiving update information sent by the first client, the update information including a new number of retransmissions; and updating the number of retransmissions in the configuration information to the new number of retransmissions.

[0178] Further optionally, the method of this embodiment also includes: when the change amplitude of the transmission delay of the first tunnel is greater than the set change amplitude threshold, reporting the transmission delay of the first tunnel to the first client, so that the first client can update the number of retransmissions according to the transmission delay of the first tunnel; or, in response to the delay acquisition request of the first client, reporting the transmission delay of the first tunnel to the first client, so that the first client can update the number of retransmissions according to the transmission delay of the first tunnel.

[0179] In an optional embodiment, the above-mentioned response to the tunnel establishment request of the first client to establish a first tunnel for carrying data transmission between the first client and the first server includes: responding to the tunnel establishment request of the first client, and establishing the first tunnel for carrying data transmission between the first client and the first server based on the tunnel connection between the tunnel client and the tunnel server.

[0180] Further optionally, in response to the tunnel establishment request of the first client, a first tunnel carrying data transmission is established between the first client and the first server based on the tunnel connection between the tunnel client and the tunnel server, including: responding to the tunnel establishment request of the first client, obtaining the identification information of the first server, and initializing the tunnel resources on the local end to obtain the identification information of the first tunnel; sending a first unreliable data packet carrying first packet header information to the tunnel server, the first packet header information including the identification information of the first server and the identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

[0181] Further optionally, transmitting a first unreliable data packet carrying first packet header information in the first tunnel includes: before determining that the tunnel server has successfully established a forwarding mapping relationship between the first tunnel and the first server, encapsulating the data message sent by the first client to the first server into a first unreliable data packet according to the first packet header information, and sending the first unreliable data packet to the tunnel server, so that the tunnel server can establish a forwarding mapping relationship according to the first packet header information and forward the first unreliable data packet.

[0182] Further optionally, the method of this embodiment also includes: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, transmitting a second unreliable data packet carrying second packet header information in the first tunnel; the second packet header information includes identification information of the first tunnel, so that the tunnel server can perform forwarding processing of the second unreliable data according to the forwarding mapping relationship.

[0183] Further optionally, a second unreliable data packet carrying second header information is transmitted in the first tunnel, including: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, encapsulating the data message sent by the first client to the first server into a second unreliable data packet according to the second header information, and transmitting the second unreliable data packet in the first tunnel, so that the tunnel server can forward the second unreliable data packet according to the second header information and the forwarding mapping relationship.

[0184] In an optional embodiment, the tunnel connection between the tunnel client and the tunnel server is a connection-oriented transport layer connection that can support both unreliable and reliable transmission, such as but not limited to: a QUIC connection.

[0185] Figure 4b A flow chart of a data transmission processing method provided in an embodiment of the present application. This embodiment is applied to a first client, such as Figure 4b As shown, the method includes:

[0186] 41b. Generate a retransmission count for transmitting an unreliable data packet through a first tunnel, where the first tunnel is a tunnel for transmitting data between a first client and a first server.

[0187] Among them, the first tunnel is carried on the tunnel connection between the tunnel client and the tunnel server. Optionally, the tunnel connection is a connection-oriented transport layer connection that can support both unreliable and reliable transmission, for example, it can be but not limited to: QUIC connection.

[0188] 42b. Send configuration information to the tunnel client, where the configuration information includes the number of retransmissions, so that when the tunnel client fails to transmit an unreliable data packet through the first tunnel, the tunnel client can retransmit the unreliable data packet that failed to be transmitted in the first tunnel by obtaining the number of retransmissions in the configuration information.

[0189] In an optional embodiment, the above-mentioned number of retransmissions generated for transmitting unreliable data packets through the first tunnel includes: when a reliable transmission protocol is adopted between the first client and the first server, that is, when a reliable transmission protocol is adopted at the application layer, generating the number of retransmissions generated for transmitting unreliable data packets through the first tunnel.

[0190] In an optional embodiment, the above-mentioned method of generating the number of retransmissions for transmitting unreliable data packets through the first tunnel when a reliable transmission protocol is adopted between the first client and the first server includes: generating the number of retransmissions for transmitting unreliable data packets through the first tunnel when a reliable transmission protocol is adopted between the first client and the first server, and the difference between the first transmission delay between the first client and the first server and the second transmission delay between the tunnel client and the tunnel server is greater than a set difference threshold.

[0191] Further optionally, when a reliable transmission protocol is employed between the first client and the first server, and the difference between the first transmission delay and the second transmission delay is greater than a preset difference threshold, a number of retransmissions for use in transmitting an unreliable data packet through the first tunnel is generated based on the first transmission delay and the second transmission delay, and optionally, the number of retransmissions is within a preset number interval. Alternatively, when a reliable transmission protocol is employed between the first client and the first server, and the difference between the first transmission delay and the second transmission delay is greater than a preset difference threshold, the second reserved value is used as the number of retransmissions for use in transmitting an unreliable data packet through the first tunnel.

[0192] In an optional embodiment, generating the number of retransmissions for transmitting unreliable data packets through the first tunnel further includes: when an unreliable transmission protocol is adopted between the first client and the first server, or when a reliable transmission protocol is adopted between the first client and the first server but the difference between the first transmission delay and the second transmission delay is less than or equal to a set difference threshold, using a first reserved value outside the number interval as the number of retransmissions for transmitting unreliable data packets through the first tunnel.

[0193] The above number interval indicates partially reliable transmission of unreliable data packets in the first tunnel, the second reserved value indicates fully reliable transmission of unreliable data packets in the first tunnel, and the first reserved value indicates unreliable transmission of unreliable data packets in the first tunnel.

[0194] Figure 4c A flow chart of a tunnel establishment method provided in an embodiment of the present application. This embodiment is applied to a tunnel client, such as Figure 4c As shown, the method includes:

[0195] 41c. Respond to the tunnel establishment request from the first client and obtain identification information of the first server. The tunnel establishment request is used to request establishment of a first tunnel between the first client and the first server to carry data transmission.

[0196] Among them, the first tunnel is carried on the tunnel connection between the tunnel client and the tunnel server. Optionally, the tunnel connection is a connection-oriented transport layer connection that can support both unreliable and reliable transmission, for example, it can be but not limited to: QUIC connection.

[0197] 42c. Initialize tunnel resources at the local end to obtain identification information of the first tunnel.

[0198] 43c sends a first unreliable data packet carrying first packet header information to the tunnel server, where the first packet header information includes identification information of the first server and identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

[0199] Optionally, sending a first unreliable data packet carrying first header information to the tunnel server includes: encapsulating the data message sent by the first client to the first server into a first unreliable data packet according to the first header information, and sending the first unreliable data packet carrying the first header information to the tunnel server.

[0200] In an optional embodiment, the method of this embodiment also includes: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, transmitting a second unreliable data packet carrying second packet header information in the first tunnel; the second packet header information includes identification information of the first tunnel, so that the tunnel server can forward the second unreliable data according to the forwarding mapping relationship.

[0201] Furthermore, a second unreliable data packet carrying second header information is transmitted in the first tunnel, including: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, according to the second header information, encapsulating the data message sent by the first client to the first server into a second unreliable data packet, and transmitting the second unreliable data packet in the first tunnel, so that the tunnel server can forward the second unreliable data packet according to the second header information and the forwarding mapping relationship.

[0202] Figure 4d A flow chart of another tunnel establishment method provided in an embodiment of the present application. This embodiment is applied to a tunnel server, such as Figure 4d As shown, the method includes:

[0203] 41d. Receive a first unreliable data packet sent by the tunnel client.

[0204] 42d. Parse first packet header information from the first unreliable data packet, where the first packet header information includes identification information of the first server and identification information of the first tunnel. The first tunnel is a tunnel used to carry data transmission between the first client and the first server.

[0205] Among them, the first tunnel is carried on the tunnel connection between the tunnel client and the tunnel server. Optionally, the tunnel connection is a connection-oriented transport layer connection that can support both unreliable and reliable transmission, for example, it can be but not limited to: QUIC connection.

[0206] 43d, according to the first packet header information, establishing a forwarding mapping relationship between the first tunnel and the first server, and forwarding the first non-reliable data packet to the first server.

[0207] Further optionally, further comprising: returning an acknowledgement message corresponding to the first non-reliable data packet to the tunnel client.

[0208] The embodiment of the application also provides a data transmission processing method based on a QUIC connection, which comprises the following steps: in response to a tunnel establishment request of a first client, establishing a first tunnel on a QUIC connection between the tunnel server and the first client, wherein the first tunnel carries data transmission between the first client and a first server in the form of non-reliable data packets; receiving configuration information issued by the first client, wherein the configuration information comprises a retransmission number for the first tunnel to transmit non-reliable data packets; and in the case that the first tunnel fails to transmit non-reliable data packets, performing retransmission processing on the non-reliable data packets that fail to be transmitted according to the retransmission number in the configuration information.

[0209] Further, in response to the tunnel establishment request of the first client, establishing the first tunnel on the QUIC connection between the tunnel server and the first client comprises the following steps: in response to the tunnel establishment request of the first client, obtaining identification information of the first server and initializing tunnel resources at the local end to obtain identification information of the first tunnel; and sending a first non-reliable data packet carrying first packet header information to the tunnel server, wherein the first packet header information comprises the identification information of the first server and the identification information of the first tunnel, so as to enable the tunnel server to establish a forwarding mapping relationship between the first tunnel and the first server and perform forwarding processing on the first non-reliable data packet.

[0210] For the detailed implementation of each step in the above method embodiments, refer to the description of the foregoing embodiments, which will not be repeated here.

[0211] It should be noted that in some of the processes described in the foregoing embodiments and the accompanying drawings, a plurality of operations appear in a specific order, but it should be clearly understood that these operations can be executed in the order they appear in this document or in parallel. The serial numbers of the operations, such as 41a, 42a, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and the operations can be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this document are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence. Also, "first" and "second" are not of different types.

[0212] Figure 5a A structural schematic diagram of a data transmission processing device provided by the embodiment of the application is shown in FIG. 3. Figure 5aAs shown, the apparatus comprises:

[0213] The establishment module 50a is configured to establish a first tunnel for carrying data transmission between the first client and the first server in response to a tunnel establishment request of the first client.

[0214] The receiving module 51a is configured to receive configuration information issued by the first client, the configuration information comprising a retransmission number for retransmitting non-reliable data packets in the first tunnel.

[0215] The retransmission module 52a is configured to, in the case of a failure in transmitting the non-reliable data packets in the first tunnel, perform retransmission processing on the failed non-reliable data packets in the first tunnel by obtaining the retransmission number in the configuration information.

[0216] The first tunnel is carried on a tunnel connection between the tunnel client and the tunnel server, and the tunnel connection is a connection-oriented transport layer connection capable of supporting both unreliable transmission and reliable transmission, such as but not limited to a QUIC connection.

[0217] In an optional embodiment, the retransmission module 52a is specifically configured to, in the case that the retransmission number obtained from the configuration information is within a preset number range, perform retransmission on the failed non-reliable data packets in the first tunnel; and if the retransmission on the failed non-reliable data packets is still unsuccessful after the number of retransmissions reaches the retransmission number obtained from the configuration information, terminate the retransmission operation on the failed non-reliable data packets.

[0218] In an optional embodiment, the retransmission module 52a is further configured to, in the case that the retransmission number obtained from the configuration information is a second reserved value outside the number range, perform retransmission on the failed non-reliable data packets in the first tunnel until the transmission is successful; or, in the case that the retransmission number obtained from the configuration information is a first reserved value outside the number range, prohibit the retransmission operation on the failed non-reliable data packets.

[0219] In an optional embodiment, as shown, Figure 5a The apparatus further comprises a sending module 53a configured to synchronize the retransmission number in the configuration information to the tunnel server through reliable data packets in a control stream, so that the tunnel server performs retransmission processing on the failed non-reliable data packets in the first tunnel according to the retransmission number in the case of a failure in transmitting the non-reliable data packets.

[0220] Further optionally, the receiving module 51a is further configured to, in the process of transmitting the non-reliable data packets in the first tunnel, receive updated information issued by the first client, the updated information comprising a new retransmission number; and update the retransmission number in the configuration information to the new retransmission number.

[0221] Further optionally, the sending module 53a is also used to: when the change amplitude of the transmission delay of the first tunnel is greater than the set change amplitude threshold, report the transmission delay of the first tunnel to the first client, so that the first client can update the number of retransmissions according to the transmission delay of the first tunnel; or, in response to the delay acquisition request of the first client, report the transmission delay of the first tunnel to the first client, so that the first client can update the number of retransmissions according to the transmission delay of the first tunnel.

[0222] Optionally, the number of retransmissions used for transmitting unreliable data packets through the first tunnel is generated based on the first transmission delay and the second transmission delay when a reliable transmission protocol is adopted between the first client and the first server, and the difference between the first transmission delay between the first client and the first server and the second transmission delay between the tunnel client and the tunnel server is greater than a set difference threshold.

[0223] Further optionally, as Figure 5a As shown, the establishment module 50a is specifically used to: respond to the tunnel establishment request of the first client, obtain the identification information of the first server, and initialize the tunnel resources on the local end to obtain the identification information of the first tunnel; send a first unreliable data packet carrying a first packet header information to the tunnel server, the first packet header information includes the identification information of the first server and the identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

[0224] Furthermore, the establishment module 50a is also used to: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, transmit a second unreliable data packet carrying second packet header information in the first tunnel; the second packet header information includes identification information of the first tunnel, so that the tunnel server can perform forwarding processing of the second unreliable data according to the forwarding mapping relationship.

[0225] Further optionally, a second unreliable data packet carrying second header information is transmitted in the first tunnel, including: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, encapsulating the data message sent by the first client to the first server into a second unreliable data packet according to the second header information, and transmitting the second unreliable data packet in the first tunnel, so that the tunnel server can forward the second unreliable data packet according to the second header information and the forwarding mapping relationship.

[0226] Figure 5b This is a structural diagram of a data transmission processing device provided in an embodiment of the present application. Figure 5b As shown, the device includes:

[0227] The generating module 51b is configured to generate the number of retransmissions for transmitting the non-reliable data packet via the first tunnel.

[0228] The first tunnel is carried on a tunnel connection between the tunnel client and the tunnel server. Optionally, the tunnel connection is a connection-oriented transport layer connection that supports both unreliable transmission and reliable transmission, for example, but not limited to, a QUIC connection.

[0229] The sending module 52b is configured to send the configuration information to the tunnel client, where the configuration information includes the number of retransmissions, so that the tunnel client performs retransmission processing on the non-reliable data packet that fails to be transmitted via the first tunnel by obtaining the number of retransmissions in the configuration information.

[0230] In an optional embodiment, when the generating module 51b generates the number of retransmissions for transmitting the non-reliable data packet via the first tunnel, the generating module 51b is specifically configured to generate the number of retransmissions for transmitting the non-reliable data packet via the first tunnel in a case where the reliable transmission protocol is used between the first client and the first server (i.e., the reliable transmission protocol is used at the application layer).

[0231] Further, the generating module 51b is specifically configured to generate the number of retransmissions for transmitting the non-reliable data packet via the first tunnel in a case where the reliable transmission protocol is used between the first client and the first server and the difference between the first transmission delay and the second transmission delay is greater than the set difference threshold value, where the first transmission delay is the transmission delay between the first client and the first server, and the second transmission delay is the transmission delay between the tunnel client and the tunnel server.

[0232] Further, the generating module 51b is specifically configured to generate the number of retransmissions for transmitting the non-reliable data packet via the first tunnel according to the first transmission delay and the second transmission delay in a case where the reliable transmission protocol is used between the first client and the first server and the difference between the first transmission delay and the second transmission delay is greater than the set difference threshold value, where the number of retransmissions is in a preset number of times interval. Alternatively, the generating module 51b is specifically configured to generate the number of retransmissions for transmitting the non-reliable data packet via the first tunnel by taking the second reserved value as the number of retransmissions in a case where the reliable transmission protocol is used between the first client and the first server and the difference between the first transmission delay and the second transmission delay is greater than the set difference threshold value.

[0233] In an optional embodiment, the generation module 51b is also used to: when an unreliable transmission protocol is adopted between the first client and the first server, or when a reliable transmission protocol is adopted between the first client and the first server and the difference between the first round-trip delay and the second round-trip delay is less than or equal to a set difference threshold, use the first reserved value outside the number interval as the number of retransmissions for transmitting unreliable data packets through the first tunnel.

[0234] The above number interval indicates partially reliable transmission of unreliable data packets in the first tunnel, the second reserved value indicates fully reliable transmission of unreliable data packets in the first tunnel, and the first reserved value indicates unreliable transmission of unreliable data packets in the first tunnel.

[0235] Figure 5c This is a schematic diagram of the structure of a tunnel establishment device provided in an embodiment of the present application. Figure 5c As shown, the device includes:

[0236] The acquisition module 51c is configured to respond to a tunnel establishment request from the first client and acquire identification information of the first server, where the tunnel establishment request is used to request establishment of a first tunnel between the first client and the first server for carrying data transmission.

[0237] Among them, the first tunnel is carried on the tunnel connection between the tunnel client and the tunnel server. Optionally, the tunnel connection is a connection-oriented transport layer connection that can support both unreliable transmission and reliable transmission, for example, it can be but not limited to: QUIC connection.

[0238] The initialization module 52c is configured to initialize tunnel resources at the local end to obtain identification information of the first tunnel.

[0239] The transmission module 53c is used to send a first unreliable data packet carrying first packet header information to the tunnel server. The first packet header information includes identification information of the first server and identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

[0240] Furthermore, the transmission module 53 is specifically used to: encapsulate the data message sent by the first client to the first server into a first unreliable data packet according to the first packet header information; and send the first unreliable data packet to the tunnel server so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server according to the first packet header information.

[0241] In an optional embodiment, the transmission module 53 is also used to: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, transmit a second unreliable data packet carrying second packet header information in the first tunnel; the second packet header information includes identification information of the first tunnel, so that the tunnel server can forward the second unreliable data according to the forwarding mapping relationship.

[0242] Furthermore, the transmission module 53 is specifically used to: after receiving a confirmation message returned by the tunnel server for any first unreliable data packet, encapsulate the data packet sent by the first client to the first server into a second unreliable data packet according to the second packet header information, and transmit the second unreliable data packet in the first tunnel, so that the tunnel server can forward the second unreliable data packet according to the second packet header information and the forwarding mapping relationship.

[0243] Figure 5d This is a schematic diagram of the structure of another tunnel establishment device provided in an embodiment of the present application. Figure 5d As shown, the device includes:

[0244] The receiving module 51d is configured to receive a first unreliable data packet sent by the tunnel client.

[0245] The parsing module 52d is configured to parse the first packet header information from the first unreliable data packet, where the first packet header information includes identification information of the first server and identification information of the first tunnel. The first tunnel is a tunnel for carrying data transmission between the first client and the first server.

[0246] Among them, the first tunnel is carried on the tunnel connection between the tunnel client and the tunnel server. Optionally, the tunnel connection is a connection-oriented transport layer connection that can support both unreliable transmission and reliable transmission, for example, it can be but not limited to: QUIC connection.

[0247] The establishing module 53d is configured to establish a forwarding mapping relationship between the first tunnel and the first server according to the first packet header information.

[0248] The transmission module 54d is configured to forward the first unreliable data packet to the first server. Furthermore, the transmission module 54d is further configured to return a confirmation message corresponding to the first unreliable data packet to the tunnel client.

[0249] Figure 5a - Figure 5d The device shown can be executed accordingly Figure 4a - Figure 4d The method of the embodiment shown, its implementation principle and technical effect are not described in detail. Figure 5a - Figure 5d The specific manner in which each module in the device shown performs operations has been described in detail in the embodiment of the method and will not be elaborated here.

[0250] Figure 6a A structure schematic diagram of a terminal device is provided in the embodiments of the present application. As shown in the figure, the terminal device comprises a memory 61a and a processor 62a. The memory 61a is configured to store computer programs and can be configured to store other various data to support operations on the terminal device. Examples of the data include instructions of any application program or method for operating on the terminal device, contact data, phonebook data, messages, pictures, videos, etc. Figure 6a

[0251] The processor 62a is coupled to the memory 61a and is configured to execute the computer programs in the memory 61a to realize corresponding functions. In the embodiments, the computer programs in the memory 61a can be the program codes corresponding to the first client in the above-mentioned embodiments, and the processor 62a executes the program codes to realize various steps or operations performed by the first client in the above-mentioned system and method embodiments. Alternatively, the computer programs in the memory 61a can be the program codes corresponding to the tunnel client in the above-mentioned embodiments, and the processor 62a executes the program codes to realize various steps or operations performed by the tunnel client in the above-mentioned system and method embodiments. Alternatively, the computer programs in the memory 61a can contain the program codes corresponding to the first client and the tunnel client in the above-mentioned embodiments, and the processor 62a executes the program codes to realize various steps or operations performed by the first client and the tunnel client in the above-mentioned system and method embodiments, respectively. For detailed description of the steps or operations, please refer to the foregoing embodiments, which will not be described here.

[0252] Further, as shown in the figure, the terminal device further comprises a communication component 63a, a display 64a, a power supply component 65a, an audio component 66a and other components. Figure 6a Figure 6a Only part of the components are shown in the figure, which does not mean that the terminal device only comprises the components shown in the figure. Figure 6a

[0253] Figure 6b A structure schematic diagram of a tunnel server is provided in the embodiments of the present application. As shown in the figure, the tunnel server comprises a memory 61b and a processor 62b. The memory 61b is configured to store computer programs and can be configured to store other various data to support operations on the tunnel server. Examples of the data include instructions of any application program or method for operating on the tunnel server, messages, pictures, videos, etc. Figure 6b

[0254] ​​​​The processor 62b is coupled to the memory 61b and configured to execute the computer program in the memory 61b to implement corresponding functions. In this embodiment, the computer program in the memory 61b can be the program code corresponding to the tunnel server in the above-described embodiments, and the processor 62b executes the program code to implement various steps or operations performed by the tunnel server in the above-described system and method embodiments. For detailed description of these steps or operations, please refer to the foregoing embodiments, which will not be described here again.

[0255] Further, as shown in Figure 6b the tunnel server further includes a communication component 63b, a power supply component 64b, and other components. Figure 6b Only some components are shown in the tunnel server in the Figure 6b embodiment, and it does not mean that the tunnel server only includes the components shown in the figure.

[0256] Correspondingly, the embodiment of the present application further provides a computer readable storage medium storing a computer program, when the computer program is executed by a processor, the processor can implement each step in each method embodiment described above.

[0257] Correspondingly, the embodiment of the present application further provides a computer program product, including computer program / instruction, when the computer program / instruction is executed by a processor, the processor can implement the steps in each method embodiment described above.

[0258] The memory in the above-described embodiments can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0259] The communication component is configured to facilitate wired or wireless communication between the device on which the communication component is installed and other devices. The device on which the communication component is installed can access a wireless network based on a communication standard, such as WiFi, a 2G, 3G, 4G / LTE, 5G, or the like cellular communication network, or a combination thereof. In an example embodiment, the communication component receives a broadcast signal or a broadcast related information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, BlueTooth (BT) technology, and other technologies.

[0260] The display includes a screen, which can include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense a touch, a slide, and a gesture on the touch panel. The touch sensor can not only sense a boundary of a touching or a sliding action, but also detect a duration and a pressure associated with the touching or the sliding action.

[0261] The power supply component provides power to various components of the device on which the power supply component is installed. The power supply component can include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the device on which the power supply component is installed.

[0262] The audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) that is configured to receive an external audio signal when the device on which the audio component is installed is in a particular mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be further stored in memory or transmitted via the communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0263] Those skilled in the art will appreciate that embodiments of the application can be readily used as a method, a system or a computer program product. Accordingly, the application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the application can take the form of a computer program product on one or more computer readable storage media (including, but not limited to, disk memory, CD-ROMs, optical storage devices, etc.) embodying computer readable program code.

[0264] The application is described in relation to flow diagrams and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It is understood that each flow and / or block in the flow diagrams and / or block diagrams, and combinations of flows and / or blocks in the flow diagrams and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flow diagrams and / or block diagrams block or blocks. Figure 1 one or more flows and / or blocks Figure 1 means for carrying out the function specified by the flow or flows and / or block or blocks.

[0265] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the flow diagrams and / or block diagrams flow or flows and / or block or blocks. Figure 1 one or more flows and / or blocks Figure 1 means for carrying out the function specified by the flow or flows and / or block or blocks.

[0266] The computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flow diagrams and / or block diagrams flow or flows and / or block or blocks. Figure 1 one or more flows and / or blocks Figure 1 means for carrying out the function specified by the flow or flows and / or block or blocks.

[0267] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0268] Memory can include non-persistent memory, Random Access Memory (RAM), and / or non-volatile memory, such as Read-Only Memory (ROM) or flash memory, in computer readable media. Memory is an example of computer readable media.

[0269] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital video disc (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0270] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not include only those elements in the list, but can also include other elements not expressly listed or inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0271] The above merely provides an example of the present application and is not intended to limit the present application. The present application can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A data transmission processing method, applied to a tunnel client, characterized in that: The method comprises: In response to a tunnel establishment request from a first client, establishing a first tunnel for carrying data transmission between the first client and a first server; receiving configuration information sent by the first client, the configuration information including a number of retransmissions for transmitting unreliable data packets through the first tunnel; When the first tunnel fails to transmit an unreliable data packet, retransmitting the unreliable data packet that failed to be transmitted in the first tunnel by obtaining the number of retransmissions in the configuration information; Among them, in response to the tunnel establishment request of the first client, the first tunnel carrying data transmission is established between the first client and the first server, including: responding to the tunnel establishment request of the first client, obtaining the identification information of the first server, and initializing the tunnel resources on the local end to obtain the identification information of the first tunnel; sending a first unreliable data packet carrying first packet header information to the tunnel server, the first packet header information including the identification information of the first server and the identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

2. The method according to claim 1, characterized in that Retransmitting the unreliable data packet that fails to be transmitted in the first tunnel by acquiring the number of retransmissions in the configuration information includes: retransmitting the unreliable data packet that failed to be transmitted in the first tunnel when the number of retransmissions obtained from the configuration information is within a preset number interval; If the number of retransmissions for the unreliable data packet that has failed to be transmitted reaches the number of retransmissions obtained from the configuration information and the data packet is still not successfully transmitted, the retransmission operation for the unreliable data packet that has failed to be transmitted is terminated.

3. The method according to claim 2, characterized in that Also includes: When the number of retransmissions obtained from the configuration information is a second reserved value outside the number interval, the unreliable data packet that has failed to be transmitted is retransmitted in the first tunnel until the transmission is successful.

4. The method according to claim 1, wherein Also includes: The number of retransmissions in the configuration information is synchronized to the tunnel server through the reliable data packet in the control flow.

5. The method according to claim 1, wherein Also includes: During transmission of the unreliable data packet through the first tunnel, receiving update information sent by the first client, the update information including a new number of retransmissions; The number of retransmissions in the configuration information is updated to the new number of retransmissions.

6. The method according to claim 5, characterized in that Also includes: When a change in the transmission delay of the first tunnel is greater than a set change threshold, reporting the transmission delay of the first tunnel to the first client, so that the first client updates the number of retransmissions according to the transmission delay of the first tunnel; or In response to the delay acquisition request of the first client, the transmission delay of the first tunnel is reported to the first client, so that the first client updates the number of retransmissions according to the transmission delay of the first tunnel.

7. The method according to claim 1, characterized in that Also includes: After receiving a confirmation message returned by the tunnel server for any of the first unreliable data packets, transmitting a second unreliable data packet carrying second packet header information in the first tunnel; The second packet header information includes identification information of the first tunnel, so that the tunnel server can perform forwarding processing on the second unreliable data packet according to the forwarding mapping relationship.

8. A data transmission processing method, applied to a first client, characterized in that: The method comprises: generating a retransmission count for transmitting an unreliable data packet through a first tunnel, wherein the first tunnel is a tunnel for carrying data transmission between a first client and a first server; Sending configuration information to the tunnel client, the configuration information including the retransmission count, so that when the transmission of the unreliable data packet fails through the first tunnel, the tunnel client retransmits the unreliable data packet in the first tunnel by obtaining the retransmission count in the configuration information; Among them, the first tunnel is established by the tunnel client according to the tunnel establishment request sent by the first client, and the establishment steps of the first tunnel include: responding to the tunnel establishment request of the first client, obtaining the identification information of the first server, and initializing the tunnel resources on the local end to obtain the identification information of the first tunnel; sending a first unreliable data packet carrying first packet header information to the tunnel server, the first packet header information including the identification information of the first server and the identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

9. The method according to claim 8, characterized in that Generates the number of retransmissions for unreliable data packets transmitted through the first tunnel, including: When a reliable transmission protocol is adopted at the application layer and a difference between the first transmission delay and the second transmission delay is greater than a set difference threshold, generating a number of retransmission times for transmitting an unreliable data packet through the first tunnel; The first transmission delay is the transmission delay between the first client and the first server, and the second transmission delay is the transmission time between the tunnel client and the tunnel server.

10. The method according to claim 9, characterized in that When a reliable transmission protocol is adopted at the application layer and a difference between a first transmission delay and a second transmission delay is greater than a set difference threshold, generating a number of retransmission times for transmitting an unreliable data packet through the first tunnel includes: When a reliable transmission protocol is adopted at the application layer and a difference between a first transmission delay and a second transmission delay is greater than a set difference threshold, generating a number of retransmission times for transmitting an unreliable data packet through the first tunnel based on the first transmission delay and the second transmission delay; or When a reliable transmission protocol is adopted at the application layer and the difference between the first transmission delay and the second transmission delay is greater than a set difference threshold, a second reserved value outside the preset number of times is used as the number of retransmissions when transmitting unreliable data packets through the first tunnel.

11. The method according to claim 10, characterized in that Generating the number of retransmissions for transmitting an unreliable data packet through the first tunnel further includes: When an unreliable transmission protocol is adopted at the application layer, or when a reliable transmission protocol is adopted at the application layer and the difference between the first transmission delay and the second transmission delay is less than or equal to a set difference threshold, the first reserved value outside the preset number of times is used as the number of retransmissions when transmitting unreliable data packets through the first tunnel.

12. A data transmission processing method, applied to a tunnel client, characterized in that: The method comprises: In response to the tunnel establishment request from the first client, establish a first tunnel on the QUIC connection with the tunnel server, where the first tunnel carries data transmission between the first client and the first server in the form of unreliable data packets; receiving configuration information sent by the first client, the configuration information including a number of retransmissions for transmitting unreliable data packets through the first tunnel; In the case where the first tunnel fails to transmit an unreliable data packet, retransmitting the unreliable data packet that failed to be transmitted in the first tunnel according to the number of retransmissions in the configuration information; Among them, responding to the tunnel establishment request of the first client, establishing the first tunnel on the QUIC connection between the tunnel server, includes: responding to the tunnel establishment request of the first client, obtaining the identification information of the first server, and initializing the tunnel resources on the local end to obtain the identification information of the first tunnel; transmitting a first unreliable data packet carrying first packet header information to the tunnel server, the first packet header information including the identification information of the first server and the identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

13. A tunnel establishment method, applied to a tunnel client, characterized in that: The method comprises: Responding to a tunnel establishment request from the first client, obtaining identification information of the first server, wherein the tunnel establishment request is used to request establishment of a first tunnel between the first client and the first server for carrying data transmission; Initializing tunnel resources at the local end to obtain identification information of the first tunnel; A first unreliable data packet carrying first packet header information is sent to a tunnel server, where the first packet header information includes identification information of the first server and identification information of the first tunnel, so that the tunnel server can establish a forwarding mapping relationship between the first tunnel and the first server and forward the first unreliable data packet.

14. The method according to claim 13, characterized in that Also includes: After receiving the confirmation message returned by the tunnel server for any of the first unreliable data packets, a second unreliable data packet carrying second packet header information is transmitted in the first tunnel, and the second packet header information includes identification information of the first tunnel, so that the tunnel server can forward the second unreliable data packet according to the forwarding mapping relationship.

15. A tunnel establishment method, applied to a tunnel server, characterized in that: The method comprises: receiving a first unreliable data packet sent by a tunnel client; Parsing first packet header information from the first unreliable data packet, where the first packet header information includes identification information of the first server and identification information of a first tunnel, where the first tunnel is a tunnel used to carry data transmission between the first client and the first server; A forwarding mapping relationship between the first tunnel and the first server is established according to the first packet header information, and the first unreliable data packet is forwarded to the first server.

16. A terminal device, characterized in that: include: memory and processor; The memory is used to store a computer program, and the processor is coupled to the memory and is used to execute the computer program to implement the steps in the method of any one of claims 1-7, claims 8-11, claim 12, and claims 13-14.

17. A tunnel server, characterized in that: include: memory and processor; The memory is used to store a computer program, and the processor is coupled to the memory and is used to execute the computer program to implement the steps in the method according to claim 15.

18. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the processor is caused to implement the steps of the method according to any one of claims 1 to 7, 8 to 11, 12, 13 to 14, and 15.

Images