CN115134553A

CN115134553A - Data transmission method and device, electronic equipment and storage medium

Info

Publication number: CN115134553A
Application number: CN202110277682.0A
Authority: CN
Inventors: 余一
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-03-15
Filing date: 2021-03-15
Publication date: 2022-09-30

Abstract

The application provides a data transmission method, a data transmission device, electronic equipment and a storage medium; relating to the technical field of cloud technology and communication, the method comprises the following steps: establishing a first data connection for data transmission between the terminal and the terminal, wherein a connection identifier of the first data connection is kept unchanged when an internet protocol address or a port of the terminal is changed; receiving a data packet transmitted by the terminal based on the first data connection; analyzing the data packet to determine a data type corresponding to the data packet; when the data type of the data packet is determined to be an unreliable data type, controlling not to return a receiving response message corresponding to the data packet to the terminal; by the method and the device, unnecessary occupation of network resources can be reduced, and the utilization rate of the network resources is improved.

Description

Data transmission method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of cloud technologies and communication technologies, and in particular, to a data transmission method and apparatus, an electronic device, and a storage medium.

Background

In the related art, unreliable data which does not need to be reliably transmitted, such as audio and video data, frequently-moving coordinate data and the like, are often transmitted by multiplexing the unreliable data and the reliable data which need to be reliably transmitted through the same channel, namely, the unreliable data and the reliable data are transmitted in a reliable transmission mode. When the network is poor, the retransmission strategy of the reliable transmission mode can bring great pressure to the network and can influence the normal transmission of reliable data such as signaling.

Disclosure of Invention

Embodiments of the present application provide a data transmission method, an apparatus, an electronic device, and a storage medium, which can reduce unnecessary occupation of network resources and improve utilization rate of the network resources.

The technical scheme of the embodiment of the application is realized as follows:

an embodiment of the present application provides a data transmission method, including:

establishing a first data connection for data transmission between a terminal and the terminal, wherein a connection identifier of the first data connection is kept unchanged when an internet protocol address or a port of the terminal is changed;

receiving a data packet transmitted by the terminal based on the first data connection;

analyzing the data packet to determine the data type corresponding to the data packet;

and when the data type of the data packet is determined to be an unreliable data type, controlling not to return a receiving response message corresponding to the data packet to the terminal.

establishing a first data connection for data transmission between the server and the server, wherein the connection identifier of the first data connection is kept unchanged when the internet protocol address or the port of the server is changed;

sending a data packet to the server based on the first data connection;

the data type of the data packet comprises an unreliable data type, and the unreliable data type is used for controlling not to return a receiving response message corresponding to the data packet when the server determines that the data type of the data packet is the unreliable data type.

An embodiment of the present application further provides a data transmission device, including:

the system comprises a creating module, a sending module and a receiving module, wherein the creating module is used for creating a first data connection for data transmission between a terminal and the terminal, and a connection identifier of the first data connection is kept unchanged when an internet protocol address or a port of the terminal is changed;

a receiving module, configured to receive a data packet transmitted by the terminal based on the first data connection;

the analysis module is used for analyzing the data packet to determine the data type corresponding to the data packet;

and the control module is used for controlling not to return a receiving response message corresponding to the data packet to the terminal when the data type of the data packet is determined to be an unreliable data type.

In the above scheme, the apparatus further comprises:

the connection state control module is used for acquiring a heartbeat packet sending period and sending a heartbeat packet to the terminal through the first data connection according to the heartbeat packet sending period;

and when receiving heartbeat response information aiming at the heartbeat packet, controlling the connection state corresponding to the first data connection to be an active state.

In the above scheme, when the first data connection is established for the first time, the establishing module is further configured to receive a first query packet that requests to establish a data connection and is sent by the terminal;

based on the first inquiry data packet, sending a corresponding response data packet to the terminal;

and when receiving a second inquiry data packet sent by the terminal, establishing a first data connection for data transmission with the terminal.

In the above scheme, when the first data connection is not established for the first time, the establishing module is further configured to receive an inquiry data packet that is sent by the terminal and requests to establish a data connection;

based on the query packet, a first data connection for data transmission with the terminal is created.

In the above scheme, the parsing module is further configured to extract a header portion of the data packet;

analyzing the packet head part to obtain a message field for indicating the data type;

and determining the data type indicated by the message field as the data type corresponding to the data packet.

In the above scheme, the apparatus further comprises:

the first migration module is used for establishing a second data connection with the terminal through a first socket interface of the terminal when the internet protocol address of the terminal changes so as to migrate the data connection with the terminal from the first data connection to the second data connection;

wherein the connection identifier of the second data connection is consistent with the connection identifier of the first data connection.

In the foregoing solution, the first migration module is further configured to send, based on the connection identifier, a probe packet including first verification information to the terminal through the second data connection;

receiving a response data packet returned by the terminal aiming at the detection data packet, wherein the response data packet comprises second verification information;

and verifying the first verification information based on the second verification information, and when a verification result representing that the verification is passed is obtained, performing data transmission with the terminal based on the second data connection.

In the foregoing solution, the first migration module is further configured to receive a probe packet that is transmitted by the terminal through the second data connection based on the connection identifier and includes third verification information;

sending a response data packet for the probe data packet to the terminal, wherein the response data packet comprises fourth verification information;

and the fourth verification information is used for verifying the fourth verification information by the terminal based on the third verification information, and when a verification result that the representation verification passes is obtained, data transmission is carried out based on the second data connection.

In the above scheme, the apparatus further comprises:

the second migration module is used for monitoring whether a target Internet protocol address changes or not to obtain a monitoring result, wherein the target Internet protocol address belongs to a server which establishes the first data connection with the terminal;

when the monitoring result represents that the target Internet protocol address is changed, a second socket interface is established for the changed target Internet protocol address, and

establishing a third data connection with the terminal based on the second socket interface to migrate the data connection with the terminal from the first data connection to the third data connection;

wherein the connection identifier of the third data connection is consistent with the connection identifier of the first data connection.

In the foregoing solution, the second migration module is further configured to monitor at least one of a data transmission failure event of an original socket interface corresponding to the target internet protocol address and a change notification message of the target internet protocol address;

and when at least one of a data transmission failure event of an original socket interface corresponding to the target internet protocol address and a change notification message of the target internet protocol address is monitored, obtaining a monitoring result representing that the target internet protocol address is changed.

In the foregoing solution, the second migration module is further configured to verify data reachability of the third data connection based on the connection identifier, so as to obtain a verification result;

and when the verification result represents that the data of the third data connection is reachable, performing data transmission with the terminal based on the third data connection.

the connection establishing module is used for establishing a first data connection for data transmission between the server and the server, and the connection identifier of the first data connection is kept unchanged when the internet protocol address or the port of the server is changed;

a sending module, configured to send a data packet to the server based on the first data connection;

An embodiment of the present application further provides an electronic device, including:

a memory for storing executable instructions;

and the processor is used for realizing the data transmission method provided by the embodiment of the application when the processor executes the executable instructions stored in the memory.

The embodiment of the present application further provides a computer-readable storage medium, which stores executable instructions, and when the executable instructions are executed by a processor, the data transmission method provided by the embodiment of the present application is implemented.

The embodiment of the application has the following beneficial effects:

establishing a first data connection for data transmission between the terminal and the terminal, wherein the connection identifier of the first data connection is kept unchanged when the internet protocol address or the port of the terminal is changed; when a data packet transmitted by the terminal based on the first data connection is received, analyzing the data packet to determine a data type corresponding to the data packet; and when the data type of the data packet is determined to be an unreliable data type, controlling not to return a receiving response message of the corresponding data packet to the terminal. Therefore, by analyzing the data type of the data packet, the corresponding receiving response message is not returned for the data packet of the unreliable data type, so that the condition that the terminal retransmits the data packet of the unreliable data type is avoided, unnecessary occupation of network resources is reduced, and the utilization rate of the network resources is improved.

Drawings

Fig. 1 is a schematic architecture diagram of a data transmission system 100 according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of an electronic device 500 of a data transmission method according to an embodiment of the present application;

fig. 3A is a schematic flowchart of a data transmission method according to an embodiment of the present application;

fig. 3B is a schematic flowchart of a data transmission method according to an embodiment of the present application;

fig. 4 is a schematic flowchart of a data transmission method according to an embodiment of the present application;

fig. 5 is a flowchart illustrating a method for creating a long connection for data transmission according to an embodiment of the present application;

fig. 6 is an application schematic diagram of a client provided in an embodiment of the present application;

fig. 7 is a schematic diagram illustrating a flow of establishing a TCP connection according to an embodiment of the present application;

fig. 8 is a schematic diagram illustrating an establishment procedure of a TLS connection according to an embodiment of the present application;

fig. 9 is a schematic representation of a client when an internet protocol address is changed according to an embodiment of the present application;

FIG. 10 is a flow chart illustrating the establishment of a QUIC connection according to an embodiment of the present application;

fig. 11 is a flowchart illustrating a method for creating a long connection for data transmission according to an embodiment of the present application;

FIG. 12 is a schematic flow chart illustrating connection migration of a data connection according to an embodiment of the present application;

FIG. 13 is a schematic flow chart diagram illustrating connection migration provided by an embodiment of the present application;

FIG. 14 is a flow chart illustrating path verification provided by an embodiment of the present application;

FIG. 15 is a schematic diagram of reliable and unreliable frame formats provided by embodiments of the present application;

fig. 16 is a schematic flow chart of data transmission applied to remote control according to an embodiment of the present application;

FIG. 17A is a schematic diagram of a picture-in-picture mode provided by an embodiment of the present application;

FIG. 17B is a schematic diagram of a sound magnitude display provided by an embodiment of the present application;

FIG. 18 is a schematic diagram illustrating optimization of a client index provided by an embodiment of the present application;

fig. 19 is a schematic structural diagram of a data transmission device 555 according to an embodiment of the present application;

fig. 20 is a schematic structural diagram of a data transmission device 2000 according to an embodiment of the present application.

Detailed Description

In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the accompanying drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without making creative efforts fall within the protection scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the following description, references to the terms "first \ second \ third" are only to distinguish similar objects and do not denote a particular order or importance, but rather "first \ second \ third" may, where permissible, be interchanged in a particular order or sequence so that embodiments of the present application described herein can be practiced in other than the order shown or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.

1) The terminal comprises a client and an application program running in the terminal and used for providing various services, such as an instant messaging client and a video playing client.

2) In response to the condition or state on which the performed operation depends, one or more of the performed operations may be in real-time or may have a set delay when the dependent condition or state is satisfied; there is no restriction on the order of execution of the operations performed unless otherwise specified.

3) Transmission Control Protocol (TCP), which is a connection-oriented, reliable transport layer communication Protocol based on byte stream, is defined by RFC 793 of IETF (Internet engineering task force).

4) TLS, Transport Layer Security, is a Security protocol, and aims to provide Security and data integrity guarantee for Internet communication

5) Quick UDP Internet Connection is a UDP-based reliable Internet transport layer protocol established by Google, standardization is started by IETF (Internet engineering task force) in 2016 (11 months), and RFC is expected to be released from basic draft in 2021.

6) Cellular, a wireless communication technology, also commonly referred to as GPRS/3G/4G/5G networks.

7) The long connection is a long-time effective and reliable data transmission channel established and maintained between the client and the background.

8) XMPP: XMPP is a protocol based on a subset XML of standard generic markup speech that inherits the flexible developability in an XML environment. The XML data stream can be used for service-class real-time communication, representation and demand response service. Therefore, XMPP-based applications have superior scalability, as defined by IETF (internet engineering task force) RFC 3920.

9) RTT: Round-Trip Time, Round-Trip delay. It is an important performance indicator in computer networks, which indicates the total delay experienced from the time the sender sends data to the time the sender receives an acknowledgment from the receiver (the receiver sends an acknowledgment immediately after receiving the data).

Based on the above explanations of terms and terms involved in the embodiments of the present application, the data transmission system provided by the embodiments of the present application is explained below. Referring to fig. 1, fig. 1 is a schematic diagram of an architecture of a data transmission system 100 provided in an embodiment of the present application, in order to support an exemplary application, a terminal (an exemplary terminal 400-1 is shown) is connected to a server 200 through a network 300, where the network 300 may be a wide area network or a local area network, or a combination of the two, and data transmission is implemented using a wireless or wired link.

A terminal (e.g., terminal 400-1) for creating a first data connection for data transmission with the server 200; sending a data packet to the server 200 based on the first data connection;

a server 200 for creating a first data connection for data transmission with a terminal; receiving a data packet transmitted by the terminal based on the first data connection; analyzing the data packet to determine the data type corresponding to the data packet; and when the data type of the data packet is determined to be an unreliable data type, controlling not to return a receiving response message of the corresponding data packet to the terminal.

The embodiments of the present application may be implemented by means of Cloud Technology (Cloud Technology), which refers to a hosting Technology for unifying series resources such as hardware, software, and network in a wide area network or a local area network to implement data calculation, storage, processing, and sharing.

The cloud technology is a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied based on a cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources.

In practical application, the server 200 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, a middleware service, a domain name service, a security service, a CDN, a big data and artificial intelligence platform, and the like. The terminal (e.g., the terminal 400-1) may be, but is not limited to, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart television, a smart watch, and the like. The terminal (e.g., terminal 400-1) and the server 200 may be directly or indirectly connected through wired or wireless communication, and the application is not limited thereto.

Referring to fig. 2, fig. 2 is a schematic structural diagram of an electronic device 500 of a data transmission method provided in the embodiment of the present application. In practical applications, the electronic device 500 may be a server or a terminal shown in fig. 1, and the electronic device 500 is taken as the terminal shown in fig. 1 as an example to explain an electronic device implementing the data transmission method according to the embodiment of the present application, where the electronic device 500 provided in the embodiment of the present application includes: at least one processor 510, memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together by a bus system 540. It is understood that the bus system 540 is used to enable communications among the components of the connection. The bus system 540 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 540 in fig. 2.

The Processor 510 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc., wherein the general purpose Processor may be a microprocessor or any conventional Processor, etc.

The user interface 530 includes one or more output devices 531 enabling presentation of media content, including one or more speakers and/or one or more visual display screens. The user interface 530 also includes one or more input devices 532, including user interface components to facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 550 optionally includes one or more storage devices physically located remote from processor 510.

The memory 550 may comprise volatile memory or nonvolatile memory, and may also comprise both volatile and nonvolatile memory. The nonvolatile memory may be a Read Only Memory (ROM), and the volatile memory may be a Random Access Memory (RAM). The memory 550 described in embodiments herein is intended to comprise any suitable type of memory.

In some embodiments, memory 550 can store data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 551 including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

a network communication module 552 for communicating to other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

a presentation module 553 for enabling presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 (e.g., a display screen, speakers, etc.) associated with the user interface 530;

an input processing module 554 for detecting one or more user inputs or interactions from one of the one or more input devices 532 and translating the detected inputs or interactions.

In some embodiments, the data transmission apparatus provided in the embodiments of the present application may be implemented in software, and fig. 2 shows a data transmission apparatus 555 stored in a memory 550, which may be software in the form of programs and plug-ins, and includes the following software modules: a creation module 5551, a reception module 5552, a parsing module 5553 and a control module 5554, which are logical and thus can be arbitrarily combined or further split according to the implemented functions, the functions of the respective modules will be explained below.

In other embodiments, the data transmission Device provided in the embodiments of the present Application may be implemented by a combination of hardware and software, and for example, the data transmission Device provided in the embodiments of the present Application may be a processor in the form of a hardware decoding processor, which is programmed to execute the data transmission method provided in the embodiments of the present Application, for example, the processor in the form of the hardware decoding processor may be one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), Field Programmable Gate Arrays (FPGAs), or other electronic components.

Based on the above description of the data transmission system and the electronic device provided in the embodiments of the present application, the data transmission method provided in the embodiments of the present application is described below. In some embodiments, the data transmission method provided in the embodiments of the present application may be implemented by a server or a terminal alone, or implemented by a server and a terminal in a cooperation manner, and the data transmission method provided in the embodiments of the present application is described below by taking the server as an example. Referring to fig. 3A, fig. 3A is a schematic flowchart of a data transmission method provided in an embodiment of the present application, where the data transmission method provided in the embodiment of the present application includes:

step 101: the server creates a first data connection for data transmission with the terminal.

Wherein the connection identifier of the first data connection remains unchanged when the internet protocol address or port of the terminal changes.

Here, the server may create a first data connection for data transmission between the server and the terminal in advance before performing data communication with the terminal. After the first data connection is established, the server and the terminal transmit and receive data packets through the first data connection. In practical applications, the terminal may be provided with an application client, such as a conference client, a learning client, and the like, and the server may be a background server of the corresponding application client.

In this embodiment, the connection identifier of the first data connection remains unchanged when the internet protocol address (i.e., IP address) or port of either one of the terminal and the server is changed, that is, when the IP address or port of either one of the terminal and the server is changed, the data channel between the terminal and the server is not disconnected, and both of them can transmit data packets based on the connection identifier of the first data connection. In this way, when the IP address of the terminal or the server is changed, data transmission between the two is not affected, and the change of the IP address is imperceptible for the user, and the situations of network disconnection, need of reconnection and the like do not occur.

In practical application, the first data connection is established based on a QUIC protocol, the connection identifier of the QUIC connection is a 64-bit connection ID, when a user switches between Wi-Fi and a cellular network (namely cellular), no matter an IP address or a Port (Port) changes, the connection ID in the QUIC connection keeps unchanged, and the terminal and the server can still transmit data packets based on the connection identifier of the QUIC connection, so that connection is not required to be established through processes such as protocol handshaking and the like again, and the technical effect of network type switching which is not perceived by the user can be achieved through QUIC connection migration.

In some embodiments, when the first data connection is first established, the server may establish the first data connection for data transmission with the terminal by: receiving a first inquiry data packet which is sent by a terminal and requests to establish data connection; based on the first inquiry data packet, sending a corresponding response data packet to the terminal; when a second query packet sent by the terminal is received, a first data connection for data transmission with the terminal is created.

In practical applications, the first data connection may be implemented based on the QUIC protocol. Specifically, when the first data connection is established for the first time, the first data connection may be established between the server and the terminal in the following manner: when a terminal needs to establish data connection with a server, sending a first inquiry data packet requesting to establish the data connection to the server; after receiving the first query data packet, the server sends a corresponding response data packet to the terminal based on the first query data packet, wherein the response data packet may include public key information, algorithm information, certificate information, protocol available version information and the like of a key exchange algorithm; the terminal receives a response data packet sent by the server and stores information contained in the response data packet, and then sends a second inquiry data packet to the server, wherein the second inquiry data packet can carry encryption information of the terminal, such as public key information of a client operated by the terminal; and after receiving the second inquiry data packet, the server establishes a first data connection with the terminal if accepting to establish the data connection, and returns response information refusing to establish if not accepting. Here, the encryption information corresponding to the terminal and the server is used for encrypting the data transmitted in the first data connection, so as to ensure the security of data transmission.

In practical implementation, when the terminal sends the second query data packet, the encryption information of the terminal and the application data can be sent together; when receiving the second query data packet, the server establishes a first data connection with the terminal based on the second query data packet, so that a corresponding response can be made to the application data in the second query data packet. Therefore, the first data connection can complete the operations of protocol handshaking and data encryption within one RTT, so that the time consumed by the handshaking of the data connection is reduced, the data encryption transmission is also completed, and the data security is ensured.

In some embodiments, when the first data connection is not established for the first time, the server may establish the first data connection for data transmission with the terminal by: receiving an inquiry data packet which is sent by a terminal and requests to establish data connection; based on the query packet, a first data connection for data transmission to the terminal is created.

In practical applications, the first data connection may be implemented based on the QUIC protocol. Specifically, when the first data connection is not established for the first time, the first data connection may be established between the server and the terminal in the following manner: since the data connection between the terminal and the server is not established for the first time, the terminal side stores the related information of the server, that is, the public key information, algorithm information, certificate information, protocol available version information, and the like of the key exchange algorithm in the second query packet stored when the data connection is established for the first time. At this time, when the terminal needs to establish data connection with the server again, the terminal only needs to send a query data packet requesting to establish data connection to the server, and the query data packet can directly carry encrypted application data; after receiving the query data packet, if the connection establishment is accepted, the server directly establishes the first data connection with the terminal, so that corresponding response can be performed on application data in the query data packet. Therefore, the first data connection can be established within 0 RTT, so that the time consumed by handshaking of the data connection is reduced, data encryption transmission is completed, and the data security is ensured.

In some embodiments, after creating the first data connection for data transmission with the terminal, the server may maintain the connection state of the first data connection as an active state by: acquiring a heartbeat packet sending period, and sending a heartbeat packet to a terminal through a first data connection according to the heartbeat packet sending period; and when heartbeat response information aiming at the heartbeat packet is received, controlling the connection state corresponding to the first data connection to be an active state.

Here, after the server establishes the first data connection with the terminal, the server needs to maintain the connection state of the first data connection as an active state. The method comprises the steps of setting a heartbeat mechanism, judging whether heartbeat response information of a heartbeat packet is received within a preset time length threshold value or not by sending the heartbeat packet to a terminal so as to determine whether the connection state of the first data connection needs to be maintained as an active state or not, and accordingly maintaining the first data connection between a server and the terminal as a long connection. Specifically, the sending period and the duration threshold of the heartbeat packet may be preset; then according to the heartbeat packet sending period, sending a heartbeat packet to the terminal through the first data connection; judging whether heartbeat response information returned by the terminal aiming at the heartbeat packet is received within a preset time length threshold value or not; when determining that the heartbeat response information returned by the terminal aiming at the heartbeat packet is received within the preset time length threshold value, controlling the connection state corresponding to the first data connection to be an active state, and when determining that the heartbeat response information returned by the terminal aiming at the heartbeat packet is not received within the preset time length threshold value, controlling the connection state corresponding to the first data connection to be a disconnection state, namely disconnecting the first data connection with the terminal, thereby reducing the waste of network resources.

Step 102: and receiving a data packet transmitted by the terminal based on the first data connection.

Here, after establishing a first data connection for data transmission with the terminal, the server transmits a packet through the first data connection. In an embodiment of the present application, the first data connection may support both reliable and unreliable data transmission. When reliable data (such as data in a handshake period, signaling data after handshake success, and the like) needs to be sent, the data can be encapsulated into a data packet of a reliable data type; when unreliable data (such as audio and video data, frequently moving coordinate data, and the like) needs to be sent, the data can be packaged into a data packet of an unreliable data type. Specifically, the data packet of the reliable data type and the data packet of the unreliable data type adopt different packet formats, and the data packet carries a message field for indicating the data type, where the message field is used to store a data identifier for indicating the data type, that is, the data identifiers of the data packets of different data types are different.

Here, the reliable data type data packet is non-discardable data (such as data in a handshake period, signaling data after successful handshake, etc.) strictly required in the transmission process, specifically data that needs to be transmitted in a reliable transmission manner; the data packet of the unreliable data category is data (such as audio/video data, frequently moving coordinate data, and the like) that may be partially discarded in the transmission process, and specifically data that needs to be transmitted in an unreliable transmission manner. Here, if the receiving end does not receive the data due to network jitter or congestion, the sending end needs to retransmit the data, where whether the data is received is determined according to whether the receiving end replies a response message such as an ACK; the unreliable transmission mode is a transmission mode corresponding to the reliable transmission mode, and a sender of the unreliable transmission mode only manages sending whether a receiver receives data or not.

Step 103: and analyzing the data packet to determine the data type corresponding to the data packet.

Here, after receiving the data packet sent by the terminal based on the first data connection, the server parses the data packet to determine the data type corresponding to the data packet. Therefore, different data processing modes are adopted to process data packets of different data types.

In some embodiments, the server may determine the data type corresponding to the data packet by: extracting a header part of a data packet; analyzing the packet header part to obtain a message field for indicating the data type; and determining the data type indicated by the message field as the data type corresponding to the data packet.

In practical application, the data packets of the reliable data types and the data packets of the unreliable data types adopt different packet formats, and the data packets carry message fields for indicating the data types, and the message fields are used for storing data identifiers for indicating the data types, that is, the data identifiers of the data packets of different data types are different. When the server receives a data packet sent by the terminal, the packet head part of the data packet is extracted, and then the packet head part is analyzed to obtain a message field for indicating the data type, wherein a data identifier for indicating the data type is stored in the message field. At this time, the data type indicated by the data identifier in the message field is determined as the data type corresponding to the received data packet.

Step 104: and when the data type of the data packet is determined to be an unreliable data type, controlling not to return a receiving response message of the corresponding data packet to the terminal.

Based on the above embodiment, when it is determined that the data type of the received data packet is the unreliable data type, the server controls not to return the reception response message of the corresponding data packet to the terminal. Accordingly, the terminal may transmit data packets for unreliable data types.

And when the data type of the received data packet is determined to be the reliable data type, the server returns a receiving response message corresponding to the data packet to the terminal so as to inform the terminal that the data packet is received. Correspondingly, if the terminal does not receive the receiving response message aiming at the data packet, the data packet is retransmitted to the server.

In some embodiments, when the internet protocol address of the terminal is changed, a second data connection with the terminal is established through the first socket interface of the terminal so as to transfer the data connection with the terminal from the first data connection to the second data connection; wherein the connection identifier of the second data connection is consistent with the connection identifier of the first data connection.

Here, when the IP address of the terminal is changed, for example, when the network type of the terminal is changed from Wi-Fi to a cellular network, since the socket interface (i.e., socket) bound to the original IP address is not used, at this time, it is necessary to re-create the corresponding first socket interface for the changed IP address, and bind the re-created first socket interface with the changed IP address, so as to transmit the data packet through the re-created first socket interface.

Based on the data transmission method, the terminal can perform data transmission with the server through the recreated first socket interface based on the connection identifier of the first data connection to establish a second data connection; likewise, the server also performs data transmission with the terminal based on the second data connection. In this way, the data connection between the terminal and the server is migrated from the first data connection to the second data connection.

Here, the connection identifier of the second data connection is consistent with the connection identifier of the first data connection, so that data transmission can still be performed between the terminal and the server through the connection identifier when the IP address is changed, and the situation that the data connection is disconnected due to the change of the IP address is avoided. The second data connection and the first data connection are actually a plurality of network paths corresponding to the data connection established between the terminal and the server, the data connection between the terminal and the server is migrated from the first data connection to the second data connection, and the data connection between the terminal and the server is migrated from the original network path to a new network path through the connection identifier, so that the normal transmission of data in the migration process of the data connection is ensured, and the non-perception switching of the IP address is realized.

Here, the terminal may determine whether the IP address of the terminal is changed by: monitoring at least one of a data transmission failure event of an original socket interface corresponding to an IP address of a terminal and a change notification message of the IP address; when at least one of a data transmission failure event of an original socket interface corresponding to the IP address and a change notification message of the IP address is monitored, the IP address of the terminal is determined to be changed.

In practical application, under each operating system (including Windows/Mac/Android/iOS system), monitoring of the change notification message of the IP address can be respectively realized according to the code logic of each operating system. Therefore, when the terminal monitors the change notification message of the IP address, the IP address of the terminal is determined to be changed.

In practical application, a general IP address change monitoring mode may be set for each operating system, that is, a data transmission failure event of an original socket interface corresponding to an IP address is monitored. And when a data transmission failure event of the original socket interface corresponding to the IP address is monitored, determining that the IP address of the terminal is changed. Therefore, monitoring of the change notification message of the corresponding IP address does not need to be realized for different operating systems, complexity of logic realization is reduced, and efficiency is improved.

In some embodiments, after establishing the second data connection with the terminal, the server may perform path verification on the established second data connection by: sending a detection data packet including first verification information to the terminal through a second data connection based on the connection identifier; receiving a response data packet returned by the terminal aiming at the detection data packet, wherein the response data packet comprises second verification information; and verifying the first verification information based on the second verification information, and when a verification result that the representation verification passes is obtained, performing data transmission with the terminal based on the second data connection.

In practical applications, after the data connection between the terminal and the server is migrated, that is, after the data connection is migrated from the first data connection to the second data connection, the second data connection needs to be subjected to path verification, that is, data reachability of the second data connection is verified. Here, the data reachability is to verify whether the second data connection can support data transmission between the terminal and the server, that is, whether the terminal or the server can receive data transmitted by the transmitting side when the terminal or the server respectively serves as the receiving side.

Specifically, the server may send a probe packet including first authentication information to the terminal through the second data connection based on a connection identifier of the data connection between the terminal and the server, where the first authentication information is an unpredictable random value in actual implementation; and after receiving the detection data packet containing the first verification information, the terminal acquires the first verification information contained in the detection data packet, and takes the first verification information as second verification information to be carried in a response data packet aiming at the detection data packet and returns the response data packet to the server. The server receives the response data packet, acquires second verification information contained in the data packet, and then verifies the second verification information through the first verification information, namely, judges whether the second verification information is consistent with the first verification information; and when the second verification information is consistent with the first verification information, obtaining a verification result that the representation verification passes, and at the moment, considering that the data of the second data connection is reachable. And in the subsequent data transmission process, performing data transmission with the terminal based on the second data connection.

In some embodiments, after establishing the second data connection with the terminal, the terminal may perform path verification on the established second data connection by: receiving a detection data packet which is transmitted by the terminal through a second data connection and comprises third verification information based on the connection identifier; sending a response data packet to the terminal, wherein the response data packet comprises fourth verification information; and the fourth verification information is used for the terminal to verify the fourth verification information based on the third verification information, and when a verification result that the representation verification passes is obtained, data transmission is carried out based on the second data connection.

In practical applications, not only the server needs to verify the data reachability of the second data connection, but also the terminal needs to verify the data reachability of the second data connection after the IP address is changed. Specifically, the terminal sends a probe data packet containing third verification information to the server through a second data connection based on a connection identifier of the data connection between the terminal and the server, wherein the third verification information is an unpredictable random value in actual implementation; and after receiving the detection data packet containing the third verification information, the server acquires the third verification information contained in the detection data packet, and takes the third verification information as fourth verification information to be carried in a response data packet aiming at the detection data packet and returns the response data packet to the terminal. The terminal receives the response data packet, acquires fourth verification information contained in the data packet, and then verifies the fourth verification information through the third verification information, namely, judges whether the fourth verification information is consistent with the third verification information; and when the fourth verification information is consistent with the third verification information, obtaining a verification result that the representation verification passes, and at the moment, considering that the data of the second data connection is reachable. And in the subsequent data transmission process, performing data transmission with the terminal based on the second data connection.

In some embodiments, the server further monitors whether a target internet protocol address changes to obtain a monitoring result, wherein the target internet protocol address belongs to a server establishing a first data connection with the terminal; when the monitoring result represents that the target internet protocol address is changed, a second socket interface is created for the changed target internet protocol address, and a third data connection with the terminal is established based on the second socket interface so as to transfer the data connection with the terminal from the first data connection to the third data connection; wherein the connection identifier of the third data connection is consistent with the connection identifier of the first data connection.

Here, the server may also monitor whether its own IP address, i.e., the target internet protocol address, is changed, and obtain a monitoring result. When the target IP address of the server is changed, since the socket interface (i.e., socket) bound to the original IP address is not used, at this time, a second socket interface corresponding to the changed IP address needs to be created again, and the created second socket interface is bound to the changed target IP address, so that the data packet is transmitted through the created second socket interface.

Based on the data transmission method, the server can perform data transmission with the terminal through the second socket interface created again based on the connection identifier of the first data connection so as to establish a third data connection; likewise, the terminal also performs data transmission with the server based on the third data connection. In this way, the data connection between the terminal and the server is migrated from the first data connection to the third data connection.

Here, the connection identifier of the third data connection is consistent with the connection identifier of the first data connection, so that data transmission can still be performed between the terminal and the server through the connection identifier when the IP address is changed, and the situation that the data connection is disconnected due to the change of the IP address is avoided. The third data connection and the first data connection are multiple network paths corresponding to the data connection established between the terminal and the server, the data connection between the terminal and the server is migrated from the first data connection to the third data connection, the data connection between the terminal and the server is migrated from the original network path to a new network path through the connection identifier, and normal transmission of data in the data connection migration process is guaranteed, so that the non-perception switching of the IP address is realized.

In some embodiments, the server may monitor whether the target internet protocol address is changed, and obtain a monitoring result, as follows: monitoring at least one of a data transmission failure event of an original socket interface corresponding to a target internet protocol address and a change notification message of the target internet protocol address; when at least one of a data transmission failure event of an original socket interface corresponding to the target internet protocol address and a change notification message of the target internet protocol address is monitored, a monitoring result representing that the target internet protocol address is changed is obtained.

In some embodiments, after the server establishes the third data connection with the terminal, the data reachability of the third data connection may be verified as follows: verifying the data accessibility of the third data connection based on the connection identifier to obtain a verification result; and when the verification result indicates that the data of the third data connection is reachable, performing data transmission with the terminal based on the third data connection.

In practical applications, after the data connection between the terminal and the server is migrated, that is, after the data connection is migrated from the first data connection to the third data connection, the third data connection needs to be subjected to path verification, that is, data reachability of the third data connection is verified. Here, the data reachability is to verify whether the third data connection can support data transmission between the terminal and the server, that is, whether the terminal or the server can receive data transmitted by the transmitting side when the terminal or the server respectively serves as the receiving side. Specifically, the path verification manner of the third data connection may also adopt the path verification manner of the second data connection, which will not be described in detail in this embodiment.

By applying the embodiment of the application, a first data connection used for data transmission between the terminal and the terminal is established, and the connection identifier of the first data connection is kept unchanged when the internet protocol address or the port of the terminal is changed; when a data packet transmitted by the terminal based on the first data connection is received, analyzing the data packet to determine a data type corresponding to the data packet; and when the data type of the data packet is determined to be an unreliable data type, controlling not to return a receiving response message of the corresponding data packet to the terminal. Therefore, by analyzing the data type of the data packet, the corresponding receiving response message is not returned for the data packet of the unreliable data type, thereby avoiding the situation that the terminal retransmits the data packet of the unreliable data type, reducing the unnecessary occupation of network resources and improving the utilization rate of the network resources.

The following continues to describe the data transmission method provided by the embodiment of the present application. In some embodiments, the data transmission method provided in the embodiments of the present application may be implemented by a server or a terminal alone, or implemented by a server and a terminal in a cooperation manner, and the data transmission method provided in the embodiments of the present application is described below by taking the terminal as an example. Referring to fig. 3B, fig. 3B is a schematic flowchart of a data transmission method provided in the embodiment of the present application, where the data transmission method provided in the embodiment of the present application includes:

step 201: the terminal establishes a first data connection for data transmission with the server.

Wherein the connection identifier of the first data connection remains unchanged when the internet protocol address or port of the server changes.

Here, the terminal may create a first data connection for data transmission between the server and the terminal in advance before performing data communication with the server. After the first data connection is established, the server and the terminal transmit and receive data packets through the first data connection. In practical applications, the terminal may be provided with an application client, such as a conference client, a learning client, and the like, and the server may be a background server of the corresponding application client.

In practical application, the first data connection is established based on a QUIC protocol, the connection identifier of the QUIC connection is a 64-bit connection ID, when a user switches between Wi-Fi and a cellular network (i.e., cellular), no matter an IP address or a Port (Port) is changed, the connection ID in the QUIC connection is kept unchanged, both the terminal and the server can still transmit data packets based on the connection identifier of the QUIC connection, so that connection is not required to be established again through processes such as protocol handshaking, and the QUIC connection migration can achieve the technical effect of network type switching which is not perceived by the user.

Step 202: and sending the data packet to the server based on the first data connection.

The data type of the data packet comprises an unreliable data type, and the unreliable data type is used for controlling not to return a receiving response message of the corresponding data packet when the server determines that the data type of the data packet is the unreliable data type.

After the first data connection between the terminal and the server is established, the terminal sends a data packet to the server through the first data connection. In an embodiment of the present application, the first data connection may support both reliable and unreliable data transmission. When reliable data (such as data in a handshake period, signaling data after successful handshake, etc.) needs to be sent, the data can be encapsulated into a data packet of a reliable data type; when unreliable data (such as audio and video data, frequently moving coordinate data, and the like) needs to be sent, the data can be packaged into a data packet of an unreliable data type. Specifically, the data packet of the reliable data type and the data packet of the unreliable data type adopt different packet formats, and the data packet carries a message field for indicating the data type, where the message field is used to store a data identifier for indicating the data type, that is, the data identifiers of the data packets of different data types are different.

Here, the reliable data type data packet is non-discardable data strictly required in the transmission process (such as data in a handshake period and signaling data after handshake is successful), specifically data that needs to be transmitted in a reliable transmission manner; the unreliable data type data packet is data (such as audio/video data, frequently moving coordinate data, and the like) that may be partially discarded in the transmission process, and specifically, data that needs to be transmitted in an unreliable transmission manner. Here, if the receiving end does not receive the data due to network jitter or congestion, the sending end needs to retransmit the data, where whether the data is received is determined according to whether the receiving end replies a response message such as ACK; the unreliable transmission mode is a transmission mode corresponding to the reliable transmission mode, and a sender of the unreliable transmission mode only manages sending whether a receiver receives data or not.

After receiving a data packet sent by the terminal based on the first data connection, the server analyzes the data packet to determine a data type corresponding to the data packet. Therefore, different data processing modes are adopted to process the data packets with different data types. And when the data type of the received data packet is determined to be an unreliable data type, the server controls not to return a receiving response message of the corresponding data packet to the terminal. Accordingly, the terminal may transmit data packets for unreliable data types.

And when the data type of the received data packet is determined to be the reliable data type, the server returns a receiving response message of the corresponding data packet to the terminal so as to inform the terminal that the data packet is received. Correspondingly, if the terminal does not receive the receiving response message aiming at the data packet, the data packet is retransmitted to the server.

By applying the embodiment of the application, a first data connection used for data transmission between the terminal and the terminal is established, and the connection identifier of the first data connection is kept unchanged when the internet protocol address or the port of the terminal is changed; when a data packet transmitted by the terminal based on the first data connection is received, analyzing the data packet to determine a data type corresponding to the data packet; and when the data type of the data packet is determined to be an unreliable data type, controlling not to return a receiving response message of the corresponding data packet to the terminal. Therefore, by analyzing the data type of the data packet, the corresponding receiving response message is not returned for the data packet of the unreliable data type, so that the condition that the terminal retransmits the data packet of the unreliable data type is avoided, unnecessary occupation of network resources is reduced, and the utilization rate of the network resources is improved.

Next, a description is continued on the data transmission method provided in the embodiment of the present application, and the data transmission method provided in the embodiment of the present application may be cooperatively implemented by a terminal and a server. Referring to fig. 4, fig. 4 is a schematic flowchart of a data transmission method provided in an embodiment of the present application, where the data transmission method provided in the embodiment of the present application includes:

step 301: the terminal establishes a first data connection for data transmission with the server.

Step 302: the terminal sends the data packet to the server based on the first data connection.

Step 303: and the server receives a data packet transmitted by the terminal based on the first data connection, analyzes the data packet and determines the data type corresponding to the data packet.

Step 304: judging whether the data type corresponding to the data packet is an unreliable data type, if not, executing a step 305; if yes, go to step 306.

Step 305: and returning a receiving response message of the corresponding data packet to the terminal.

Step 306: and controlling not to return a receiving response message of the corresponding data packet to the terminal.

Step 307: the terminal receives a reception response message corresponding to the data packet.

An exemplary application of the embodiments of the present application in a practical application scenario will be described below.

Before explaining a data transmission method provided by the embodiment of the present application, a method for creating a long connection for data transmission provided by the embodiment of the present application is first explained. As shown in fig. 5, fig. 5 is a flowchart illustrating a method for creating a long connection for data transmission according to an embodiment of the present application, where the method includes:

step 401: the client sends a SYN handshake signal to the server.

Step 402: the server returns an acknowledgement signal SYN + ACK to the client to indicate receipt of the SYN handshake signal.

Step 403: the client sends an ACK response signal to the server so as to establish a TCP connection with the server.

Here, in an actual application, the client may be a conference client, and a user may install and operate the client through a terminal to implement a corresponding client function. As an example, referring to fig. 6, fig. 6 is an application schematic diagram of a client provided in an embodiment of the present application, where the client is a conference client, and includes functional scenarios of reserving a conference, joining the conference, opening a camera and a microphone in the conference, and in each scenario, a long connection needs to be established between the client and a server for data interaction and transmission. Therefore, the client needs to establish a long connection with the server, and in this embodiment of the application, the long connection can be established by TCP + TLS + XMPP, where the above-mentioned step 401 and 403 are handshake flows of the TCP protocol, and after the step 401 and 403, the TCP connection is established between the client and the server.

Specifically, referring to fig. 7, fig. 7 is a schematic diagram of an establishment flow of a TCP connection provided in the embodiment of the present application, including:

step 501: the client sends a SYN handshake signal to the server; step 502: the server returns a response signal SYN + ACK to the client to indicate that a SYN handshake signal is received; step 503: the client sends an ACK response signal to the server to establish TCP connection with the server; step 504: the client sends Application Data (Application Data) to the server; step 505: the server returns the Application Data (Application Data) to the client. Thus, data transmission based on the TCP connection is realized.

Step 404: the client sends a query packet (XMPP Stream Start) to the server to request the Stream characteristics field of the server.

Here, after the TCP connection is established between the client and the server, the XMPP handshake flow is started.

Step 405: the server returns a response packet ACK carrying the session ID.

Here, the session ID is an identifier allocated by the server for the session of the client.

Step 406: the Server issues a Feature field Server Feature (TLS) to the client.

Step 407: the client sends a handshake request (TLS start) of the TLS handshake to the server.

Step 408: the server sends response information ACK for the handshake request of the TLS handshake to the client.

Step 409: the Client sends a Client inquiry data packet Client Hello to the server.

Here, the Client Hello packet carries information such as a random number random, a cipher suite ciphers, and an available protocol version number version of the Client.

Step 410: the Server returns a Server inquiry data packet Server Hello to the client.

Here, the Server Hello packet carries information such as the random number random, cipher suites cipers, and certificate cert of the Server.

Step 411: the Client sends a Client inquiry ending data packet Client Hello Finish to the server.

Step 412: the Server returns a Server inquiry ending data packet Server Hello Finish to the client.

Here, a standard TLS handshake is performed between the client and the server, and after completion of the handshake, a TLS connection is established to enable TLS encryption of the channel.

Specifically, referring to fig. 8, fig. 8 is a schematic diagram of a TLS connection establishment process provided in the embodiment of the present application, including: step 601: the Client sends a Client inquiry data packet Client Hello to the server; step 602: the Server returns a Server inquiry data packet Server Hello to the client; step 603: the Client sends a Client inquiry ending data packet Client Hello Finish to the server; step 604: the Server returns a Server inquiry ending data packet Server Hello Finish to the client; step 605: the client sends the application data to the server; step 606: the server returns the application data to the client. Therefore, data encryption transmission based on TLS connection is realized, and data security is ensured.

Step 413: the client sends a query data packet Stream Request to the server to Request the server to issue a Stream characteristic field and perform SASL authentication.

Step 414: the server sends a response packet ACK containing the flow flag to the client.

Step 415: the Server sends a stream Feature field (SASL) to the client and carries the supported SASL encryption mode.

Step 416: the client selects an encryption mode and sends an SASL challenge start packet (SASL challenge start) carrying user information to the server.

Here, in practical applications, the client selects a PLAIN encryption scheme from among the supported SASL encryption schemes.

Step 417: the server sends a SASL verification end packet (SA SL challenge end) for the received packet to the client.

Here, the authentication of the server for the SASL is successful.

Step 418: the client sends the initial Stream Request to the server.

Step 419: the server sends the client flow flag as a response packet ACK.

Step 420: the Server responds and returns a supported stream Feature field, Server Feature, to indicate that the client needs to start binding resource flow.

Step 421: the client sends a Bind resource Request to the server.

Step 422: and the server judges and returns a resource binding result Bind resource Response to the client.

Step 423: the client sends Application Data to the server.

Step 424: the server returns Application Data to the client.

Thus, the long connection for data transmission described above is based on the TCP + TLS protocol and long connection communication technology. The TCP protocol provides a reliable transmission channel, and the TLS encryption protocol provides security guarantee for the channel. However, with respect to the method for creating a long connection for data transmission provided in the embodiment of the present application, the applicant further analyzes and finds that, as can be seen from fig. 7 and fig. 8, before data communication is formally started, TCP requires 1.5 RTTs for establishing a connection, TLS encryption for completing a channel requires 2 RTTs, and a total of 11 RTTs are required for establishing a long connection for data transmission (i.e., a long connection between a client and a server) based on the above procedure.

The statistical data shows that, under the condition of a normal network, only 69.9% of users can complete the handshake process within 1s, and start other conference functions of the client to use, and the whole handshake process, considering the user experience, the timeout time of connection establishment is 30s, and among all users who fail to login, 41.53% of users are login failures caused by connection establishment timeout, because under the condition of a weak network, the RTT is larger, if the flow of connection establishment is complex, the time consumption for completing the handshake is inevitably larger, and the probability of timeout is higher, therefore, the handshake link is simplified, the time consumption for login is reduced, and the problems of login success rate and weak network resistance are urgently to be solved.

Also, currently the long connection between the client and the server is based on the TCP protocol, which uses a quadruplet (source IP address, destination IP address, source port and destination port) to identify a long connection. When a user equipment network is switched between wifi and cellular, a source IP address changes, so that TCP protocol connection cannot support seamless switching between wifi and cellular, which results in that once a user switches the network, the entire long connection must be disconnected and reconnected, otherwise, data cannot be continuously transmitted, which is represented by a case where a client side is disconnected and reconnected, such as "network is unstable and is connected", and fig. 9 is a representation diagram of the client when an internet protocol address changes, which is provided in the embodiment of the present application. During the reconnection of long connection and disconnection, all instruction data cannot be sent and received, and due to the fact that in the daily use process, the signals of going in and out of an elevator and the like or even wifi signals are not good, the scenes that wifi and cellular are frequently switched mutually are very common, and if reconnection needs to be disconnected every time, the user experience can be greatly influenced.

Based on the above, the embodiments of the present application also provide a method for creating a long connection for data transmission, where the method for creating a long connection for data transmission is established based on a QUIC protocol. Next, firstly, a flow for establishing a QUIC connection provided in the present application is explained, as shown in fig. 10, fig. 10 is a schematic diagram of a flow for establishing a QUIC connection provided in an embodiment of the present application, and includes:

step 701: the Client sends an initial query packet Inchoate Client Hello to the server.

Step 702: the server returns a response packet reject to the Client for the initial query packet Inchoate Client Hello.

Step 703: the Client sends the Complete query packet Complete Client Hello to the server.

Here, the Complete Client Hello may carry encryption information of the Client and send to the server together with encrypted Application Data encrypt Data, i.e., an operation indicating that the QUIC handshake and Data encryption are completed within one RTT.

Step 704: the server returns encrypted application Data Encript A application Data based on Complete Client Hello.

As shown in fig. 10, it can be seen that when the QUIC connection is established, only 1 RTT is needed, and after receiving the query packet Rejection sent by the server, the client carries the encryption information of the client when sending the next packet, and sends the packet to the server together with the application data, so as to complete the operation of QUI C handshake and data encryption within one RTT, which saves 2.5 RTTs compared to TCP + TLS.

As such, the long connection between the conference client and the server may be implemented based on the QUIC protocol, and referring to fig. 11, fig. 11 is a flowchart of a method for creating a long connection for data transmission according to an embodiment of the present application, including:

step 801: the Client sends an initial query packet Inchoate Client Hello to the server.

Step 802: the server returns a response data packet Rejection to the Client for the Inchoate Client Hello.

Step 803: the client sends a query data packet to the server to request the stream characteristic field of the server; and simultaneously sending a Complete query packet Complete Client Hello to the server.

Step 804: the server returns an ACK carrying the session ID; and simultaneously returning encrypted Application Data encryption Data based on the complete Client Hello.

Step 805: the client sends a query packet Stream Request to the server to Request the Stream characteristic field of the server.

Step 806: the server sends the stream flag as a response packet ACK to the client.

Step 807: the Server sends a stream Feature field (SASL) to the client and carries the supported SASL encryption mode.

Step 808: the client selects an encryption mode and sends an SASL authentication start packet (SASL challenge start) carrying user information to the server.

Step 809: the server sends a SASL authentication end packet (SA SL challenge end) for the received packet to the client.

Here, the server's authentication for the SASL is successful.

Step 810: the client sends the initial Stream Request to the server.

Step 811: the server sends the client flow flag as a response packet ACK.

Step 812: the Server responds and returns a supported stream Feature field, Server Feature, to indicate that the client needs to start binding resource flow.

Step 813: the client sends a Bind resource Request to the server.

Step 814: and the server judges and returns a resource binding result Bind resource Response to the client.

Step 815: the client sends Application Data to the server.

Step 816: the server returns Application Data to the client.

It can be seen that the process of long connection establishment introduced in the QUIC protocol has been reduced to 7 RTTs, which is a reduction of 4 RTTs compared to the above-described process of long connection establishment shown in fig. 5, while theoretically the long connection establishment can be reduced by 36%.

Meanwhile, since the QUIC protocol uniquely identifies a connection using a connection identification (ConnectionID), when a source IP address of a client changes (for example, a network switches between wifi and cellular), the connection identification of a long connection based on the QUIC protocol is unchanged, so that a data channel between the client and a server is kept continuous. Specifically, referring to fig. 12, fig. 12 is a schematic flowchart of connection migration of a data connection provided in an embodiment of the present application, including:

step 901: the client establishes a first socket for the IP1 and binds the first socket with the IP 1.

Step 902: the client sends an Application Data Request to the server.

Step 903: the server returns an Application Data Response for the Application Data request to the client.

Step 904: the client monitors that the network state change notification is changed from IP1 to IP 2.

Step 905: the client establishes a second socket interface socket for IP2 and binds the second socket interface socket with IP 2.

Here, when the network of the client is switched between wifi and cellular, the client receives a notification of changing the network state of the system, at this time, the IP1 is changed to IP2, and the first socket key bound to the original IP1 cannot continue communication. Therefore, a new socket needs to be bound with the changed IP2 to continue to receive and send network packets, and meanwhile, a data packet that is sent in the first socket buffer fails is retransmitted, so that the migration of a network channel of data connection between the client and the server is completed. In practical application, under each operating system (including Windows/Mac/Android/iOS system), monitoring of the network state change notification of the IP address can be respectively realized according to the code logic of each operating system. Therefore, when the client monitors the network state change notification of the IP address, the IP address of the client is determined to be changed, and a new socket is created in time to complete the migration of the data connection.

Step 906: and realizing connection migration connection n migration of the data connection based on the second socket interface socket.

Step 907: and the client retransmits the data packet which is sent in the first socket buffer and fails to be sent.

Step 908: the server returns an application data response to the client.

Further, referring to fig. 13, fig. 13 is a schematic flowchart of connection migration provided in the embodiment of the present application, including:

step 1001: the client establishes a first socket for the IP1 and binds the first socket with the IP 1.

Step 1002: the client sends an Application Data Request to the server.

Step 1003: the server returns an Application data Response Dat a Response to the Application data request to the client.

Step 1004: the client sends an application data request to the server.

At this time, the network of the client is switched between wifi and cellular, and is changed from IP1 to IP 2.

Step 1005: the server returns an application data response and fails to send, and the client monitors a socket reading failure event.

Step 1006: the client establishes a second socket interface socket for IP2 and binds the second socket interface socket with IP 2.

Step 1007: and realizing connection migration of the data connection based on the second socket interface socket.

Step 1008: and the client retransmits the data packet which is sent in the first socket buffer and fails to be sent.

Step 1009: the server returns an application data response to the client.

Here, the client no longer monitors the notification of the change of the network state of the physical network of the operating system, but monitors the event of the failed reading and writing of the socket, so as to determine whether the socket needs to be rebuilt to bind a new ip for network data transmission. Therefore, physical network changes of 4 platforms (Windows/Mac/Android/iOS) do not need to be monitored respectively, socket read-write failure caused by network switching can be successfully monitored, and a new transmission channel is established in time to complete connection migration.

Continuously, after the connection between the client and the server is migrated, data reachability verification needs to be performed on the migrated network path. Referring to fig. 14, fig. 14 is a schematic flowchart of path verification provided in the embodiment of the present application, including:

step 1101: before connection migration, the client communicates data with the server using Non-probing packets (Non-probing packets) through IP 1.

Here, the Non-sounding Packet (Non-sounding Packet) is a Packet related to the transmitted application data.

Step 1102: the IP of the client becomes IP2, and the client sends a probe Packet (probingpacket) containing a PATH verification frame PATH _ CH ALLENGE frame to the server, the PATH _ CHALLENGE frame containing an unpredictable random value.

Here, after the IP address of the client is changed and the connection migration is completed, the client starts path verification on the new network path after the migration, and verifies data reachability (i.e., reachability) of the new network path.

Step 1103: the server receives a detection Packet which is sent by the client and contains a PATH _ CHALLENGE frame, returns a RESPONSE detection Packet (probingpacket) to the client, and carries a random value received through the PATH _ CHALLENGE frame in a PATH RESPONSE frame PATH _ RESPONSE frame contained in the RESPONSE detection Packet.

Here, the client receives the RESPONSE probe packet of the PATH _ RESPONSE included in the PATH _ RESPONSE, verifies whether the random value in the payload of the RESPONSE probe packet is consistent with the random value of the PATH _ CHALLENGE frame, and if so, the data representing the PATH is reachable.

Step 1104: the server sends a probe packet (probingpa packet) containing a PATH _ CHALLENGE frame to the client, the PATH _ CHALLENGE frame containing an unpredictable random value.

Here, the server also needs to send a PATH _ CHALLENGE frame to perform PATH verification for the client.

Step 1105: the client receives a detection Packet containing a PATH _ CHALLENGE frame sent by the client, returns a RESPONSE detection Packet (probingpacket) to the server, and carries a random value received through the PATH _ CHALLENGE frame contained in the RESPONSE detection Packet.

Here, the server receives the RESPONSE probe packet of the PATH _ RESPONSE included in the PATH _ RESPONSE, verifies whether the random value in the payload of the RESPONSE probe packet is consistent with the random value of the PATH _ CHALLENGE frame, and if so, the data representing the PATH is reachable.

Step 1106: after the connection migration, the client communicates data with the server through IP2 using a Non-probing Packet (Non-probing Packet).

Therefore, the long connection based on the QUIC protocol can realize connection migration when the IP address is changed, namely seamless switching between wifi and cellular of the network is realized without reestablishing the connection. In practical application, if a network switching scene occurs in the process of using the conference client by a user, network operations such as audio and video data, switching on and off a microphone/camera and the like can be directly continued, the user is completely unaware, and the user experience is improved.

After the description of the method for creating a long connection for data transmission provided in the embodiment of the present application is finished, the data transmission method provided in the embodiment of the present application is described next. In the embodiment of the application, the data transmission method is realized based on a long connection of a QUIC protocol.

In the related technology, data which can not be discarded, such as signaling, is transmitted by adopting a reliable transmission mode; for other less strict requirements, unreliable data (such as volume display data, frequently-moving coordinate data and the like) which can be partially discarded can also be reliably transmitted by multiplexing the same channel with reliable data; then, when the network is poor, the retransmission strategy of the reliable transmission channel will put a great strain on the network, and will affect the normal transmission of reliable data such as signaling. If another unreliable channel is specially established for the unreliable data, such as a UDP channel, the client and the server need to maintain the states of the two channels at the same time, which results in adding handshake delay of the new channel, and the implementation logic is complex and the maintenance cost is high.

Based on this, the embodiments of the present application provide a data transmission method, which establishes a data connection between a terminal and a server (i.e., a client and a server) based on a QUIC protocol, and performs reliable transmission and unreliable transmission simultaneously by using the same data connection channel. Specifically, in the embodiment of the present application, the data connection between the client and the server may support reliable data transmission or unreliable data transmission. When reliable data (such as data in a handshaking period and signaling data after successful handshaking, including switching operation instructions of a camera and a microphone in a conference process) needs to be sent, the data can be packaged into a data packet of a reliable data type; when unreliable data (such as volume-sized display data, frequently moving coordinate data, etc.) needs to be sent, the data may be encapsulated into packets of the unreliable data type. Specifically, the data packets of the reliable data type and the data packets of the unreliable data type adopt different packet formats, and the data packets carry identifiers for indicating the data types (including the reliable data type and the unreliable data type), that is, the identifier of the data packet of the reliable data type is different from the identifier of the data packet of the unreliable data type. Fig. 15 is a schematic diagram of a reliable frame format and an unreliable frame format according to an embodiment of the present application, where a in fig. 15 is a reliable frame format, and B in fig. 15 is an unreliable frame format.

Here, the reliable data type data packet is non-discardable data (such as data in a handshake period, signaling data after successful handshake, etc.) strictly required in the transmission process, specifically data that needs to be transmitted in a reliable transmission manner; the unreliable data type data packet is data that may be partially discarded during transmission (e.g., volume display data, frequently moving coordinate data, etc.), and specifically data that needs to be transmitted in an unreliable transmission manner. Here, if the receiving end does not receive the data due to network jitter or congestion, the sending end needs to retransmit the data, where whether the data is received is determined according to whether the receiving end replies a response message such as ACK; the unreliable transmission mode is a transmission mode corresponding to the reliable transmission mode, and a sender of the unreliable transmission mode only manages sending whether a receiver receives data or not.

Specifically, when the server determines that the data type of the received data packet is an unreliable data type, the server does not return a reception response message of the corresponding data packet to the terminal. Accordingly, the terminal may transmit data packets for unreliable data types. And when the server determines that the data type of the received data packet is the reliable data type, the server returns a receiving response message corresponding to the data packet to the terminal so as to inform the terminal that the data packet is received. Correspondingly, if the terminal does not receive the receiving response message aiming at the data packet, the data packet is retransmitted to the server.

Taking remote control as an example, referring to fig. 16, fig. 16 is a schematic flow chart of data transmission applied to remote control according to an embodiment of the present application, including:

step 1201: the first client and the second client are connected with the server in a QUIC long mode.

Here, the first client corresponds to user a, the second client corresponds to user B, and the QUIC long connection can be established based on both the QUIC protocol and the XMPP protocol.

Step 1202: the first client sends a Remote Control Request to the server.

Here, the first client sends a remote control request signaling using a QUIC long connection, which carries identification information of the destination user B, requests to start a remote control service, and remotely controls the second client of the user B.

Step 1203: and the server returns the ACK receiving response information to the first client.

Step 1204: and the server sends the Remote Control request of the first client to the second client through Remote Control Push information Remote Control Push.

Step 1205: and the second client returns a first remote control response to the server, wherein the first remote control response carries a notification message of refusing to accept the remote control.

Step 1206: and the server sends a remote control response message to the first client so as to inform the first client of the failure of the remote control connection.

Step 1207: and the second client returns a second remote control response to the server, wherein the second remote control response carries a notification message of agreeing to accept the remote control.

Step 1208: and the server sends a remote control response message to the first client so as to inform the first client that the remote control connection is successful.

Here, the remote control response message carries an authentication token for authenticating the subsequent specific instruction control data.

Step 1209: the first client sends a remote control start request to the server to request the start of remote control.

Step 1210: the server sends a remote control start request to the second client.

Step 1211: and returning a remote control starting response message which is successfully issued by the instruction to the first client.

Here, the server receives the remote control start signaling of the first client, sends a push instruction for starting remote control to the destination user B through the long connection channel, and then sends a packet return instruction to the user a to issue a successful notification message.

Step 1212: and after receiving the remote control starting response message which is successfully issued by the instruction, the first client intercepts mouse and keyboard operations.

Step 1213: and the second client receives the remote control starting request and intercepts mouse and keyboard operations.

Step 1214: the first client encapsulates the control instruction data into an unreliable data packet, sends the unreliable data packet to the server through the QUIC long connecting channel, and simultaneously carries the authentication token and the target user information.

Step 1215: and the server forwards the control instruction data to the second client through the QUIC long connecting channel.

Here, the control instruction data may include mouse coordinates, mouse operation instructions, keyboard operation instructions, and the like. However, it is not necessary to ensure that the data is reliable to a hundred percent, for example, in the process of moving the mouse, even if the current network state is poor, some coordinate information is lost, and as long as the coordinates of which the movement is stopped are successfully transmitted or are transmitted again through another operation, the remote control can also be successful. The control command data in the remote control can thus be encapsulated into unreliable packets and transmitted over the established QUIC long connection that supports both reliable and unreliable transmission.

Here, the data of the unreliable data type further includes data related to a picture-in-picture mode of the conference client (i.e., screen sharing is started while a camera is started, a picture of the camera can be placed in a window, as shown in fig. 17A, fig. 17A is a schematic diagram of the picture-in-picture mode provided in this embodiment of the present application), for example, anywhere specified by a user, that is, data of coordinates and dimensions of the picture, which can be transmitted by an unreliable transmission manner, may be adjusted by the user. In addition, the conference client has volume data, that is, display data indicating the sound size of the user (as shown in fig. 17B, fig. 17B is a schematic diagram of sound size display provided in the embodiment of the present application), the data volumes are all large, and when the network is poor, some data is discarded without much influence, and the data can also be transmitted in an unreliable transmission mode.

By applying the embodiment of the application, the QUIC protocol is introduced into the process of establishing the long connection between the client and the server, and the characteristics of quick handshake of the QUIC and channel encryption and connection migration are utilized, so that a larger optimization effect is obtained. As shown in fig. 18, fig. 18 is a schematic diagram illustrating optimization of client indexes provided in the embodiment of the present application, where the establishment of the long connection based on TCP + TLS + XMPP successfully reduces the login time as shown in a diagram in fig. 18, as compared with the establishment of the long connection based on QUIC + XMPP, according to on-line data statistics, the average login time is reduced from 1224ms to 555ms, and the optimization effect reaches 54.6%; as shown in a graph B in fig. 18, since the timeout problem caused by high login time consumption is also optimized, the login success rate is increased from 99.89% to 99.98%, which is increased by 0.09%; as shown in a diagram C in fig. 18, the success rate of switching on and off the microphone in the conference client is increased from 98.59% to 99.84%, and the optimization effect reaches 1.26%.

Continuing with the description of the data transmission device 555 provided in the embodiments of the present application, in some embodiments, the data transmission device may be implemented by a software module. Referring to fig. 19, fig. 19 is a schematic structural diagram of a data transmission device 555 according to an embodiment of the present application, where the data transmission device 555 according to the embodiment of the present application includes:

a creating module 5551, configured to create a first data connection for data transmission with a terminal, where a connection identifier of the first data connection remains unchanged when an internet protocol address or a port of the terminal changes;

a receiving module 5552, configured to receive a data packet transmitted by the terminal based on the first data connection;

the parsing module 5553 is configured to parse the data packet to determine a data type corresponding to the data packet;

a control module 5554, configured to control not to return a reception response message corresponding to the data packet to the terminal when it is determined that the data type of the data packet is an unreliable data type.

In some embodiments, the apparatus further comprises:

and when heartbeat response information aiming at the heartbeat packet is received, controlling the connection state corresponding to the first data connection to be an active state.

In some embodiments, when the first data connection is established for the first time, the establishing module 5551 is further configured to receive a first query packet sent by the terminal and requesting to establish a data connection;

In some embodiments, when the first data connection is not established for the first time, the establishing module 5551 is further configured to receive a query packet sent by the terminal and requesting to establish a data connection;

In some embodiments, the parsing module 5553 is further configured to extract a header portion of the data packet;

In some embodiments, the apparatus further comprises:

In some embodiments, the first migration module is further configured to send, based on the connection identifier, a probe packet including first verification information to the terminal through the second data connection;

In some embodiments, the first migration module is further configured to receive a probe packet including third authentication information, which is transmitted by the terminal through the second data connection based on the connection identifier;

sending a response packet to the terminal, wherein the response packet comprises fourth verification information;

In some embodiments, the apparatus further comprises:

In some embodiments, the second migration module is further configured to monitor at least one of a data transmission failure event of an original socket interface corresponding to the target internet protocol address and a change notification message of the target internet protocol address;

In some embodiments, the second migration module is further configured to verify data reachability of the third data connection based on the connection identifier, so as to obtain a verification result;

Continuing with the description of the data transmission device 2000 provided in the embodiment of the present application, referring to fig. 20, fig. 20 is a schematic structural diagram of the data transmission device 2000 provided in the embodiment of the present application, where the data transmission device 2000 provided in the embodiment of the present application includes:

a connection creating module 2010, configured to create a first data connection for data transmission with a server, where a connection identifier of the first data connection remains unchanged when an internet protocol address or a port of the server changes;

a sending module 2020, configured to send a data packet to the server based on the first data connection;

An embodiment of the present application further provides an electronic device, where the electronic device includes:

a memory for storing executable instructions;

Embodiments of the present application also provide a computer program product or a computer program comprising computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the data transmission method provided by the embodiment of the application.

In some embodiments, the computer-readable storage medium may be memory such as FRAM, ROM, PROM, EP ROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some embodiments, the executable instructions may be in the form of a program, software module, script, or code written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

The above description is only an example of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A method of data transmission, the method comprising:

analyzing the data packet to determine a data type corresponding to the data packet;

2. The method of claim 1, wherein after the creating of the first data connection for data transmission with the terminal, the method further comprises:

acquiring a heartbeat packet sending period, and sending a heartbeat packet to the terminal through the first data connection according to the heartbeat packet sending period;

3. The method of claim 1, wherein when the first data connection is first established, the establishing a first data connection for data transmission with the terminal comprises:

receiving a first inquiry data packet which is sent by the terminal and requests to establish data connection;

sending a corresponding response data packet to the terminal based on the first query data packet;

4. The method of claim 1, wherein creating the first data connection for data transmission with the terminal when the first data connection is not first established comprises:

receiving an inquiry data packet which is sent by the terminal and requests to establish data connection;

5. The method of claim 1, wherein parsing the packet to determine the data type corresponding to the packet comprises:

extracting a header part of the data packet;

analyzing the packet header part to obtain a message field for indicating the data type;

6. The method of claim 1, wherein the method further comprises:

when the internet protocol address of the terminal is changed, establishing a second data connection with the terminal through a first socket interface of the terminal so as to transfer the data connection with the terminal from the first data connection to the second data connection;

7. The method of claim 6, wherein after the establishing the second data connection with the terminal, the method further comprises:

sending a detection data packet comprising first verification information to the terminal through the second data connection based on the connection identifier;

8. The method of claim 6, wherein after the establishing the second data connection with the terminal, the method further comprises:

receiving a detection data packet which is transmitted by the terminal through the second data connection and comprises third verification information based on the connection identification;

9. The method of claim 1, wherein the method further comprises:

monitoring whether a target Internet protocol address changes or not to obtain a monitoring result, wherein the target Internet protocol address belongs to a server establishing the first data connection with the terminal;

when the monitoring result represents that the target internet protocol address is changed, a second socket interface is created for the changed target internet protocol address, and

10. The method as claimed in claim 9, wherein said monitoring whether the target ip address is changed to obtain a monitoring result comprises:

monitoring at least one of a data transmission failure event of an original socket interface corresponding to the target internet protocol address and a change notification message of the target internet protocol address;

11. The method of claim 9, wherein after establishing the third data connection with the terminal, the method further comprises:

verifying the data accessibility of the third data connection based on the connection identifier to obtain a verification result;

and when the verification result indicates that the data of the third data connection is reachable, performing data transmission with the terminal based on the third data connection.

12. A method of data transmission, the method comprising:

sending a data packet to the server based on the first data connection;

13. A data transmission apparatus, characterized in that the apparatus comprises:

14. An electronic device, characterized in that the electronic device comprises:

a memory for storing executable instructions;

a processor, configured to execute the executable instructions stored in the memory, to implement the data transmission method according to any one of claims 1 to 12.

15. A computer-readable storage medium having stored thereon executable instructions for, when executed, implementing a data transmission method as claimed in any one of claims 1 to 12.