Data transmission method, device, equipment, medium and program product

Abstract

The embodiment of the invention provides a data transmission method and device, equipment, a medium and a program product, and relates to a data scheduling technology in a network, and the method comprises the steps that a compression end obtains compression configuration information, receives a service frame sent by an application layer, carries out the QUIC layer processing of the service frame, and obtains two same data packets; according to the compression configuration information, target packet headers of the two data packets are compressed to obtain compressed data packets corresponding to the two data packets, and the target packet headers comprise at least one of the following packet headers: a service IP packet header, a service UDP packet header and a QUIC packet header; and sending the compressed data packets corresponding to the two data packets to a decompression end at the same time through the connections in the two different networks. The compression end compresses the packet header of the QUIC data packet, so that the overhead of the packet header of the data packet is reduced, and the flow consumption for sending the QUIC data packet is reduced.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of communication, and in particular, to a data transmission method, device, equipment, medium and program product. BACKGROUND

[0002] At present, applications (APPs) generally run on a single network, such as a 5th Generation Mobile Communication Technology (5G) network or a Wireless Fidelity (WiFi) network. However, due to problems such as signal fluctuation of a wireless network and terminal mobility switching, the instability of a single wireless network has a great impact on some time delay sensitive services. For example, as the time delay increases or fluctuates, the user experience will obviously decrease.

[0003] In order to solve this problem, an accelerator APP application is born. The accelerator APP generally introduces a 5G+WiFi dual launch function. The dual launch function can be implemented through a multi-path QUIC (MP-QUIC) protocol, where QUIC is the abbreviation of Quick UDP Internet Connection. The basic principle of the dual launch function based on MP-QUIC is as follows: in the uplink direction, the accelerator APP on the terminal will copy the service data packet and send it to the acceleration gateway (also known as a dual-channel acceleration gateway) through the 5G link and the WiFi link at the same time. The acceleration gateway performs deduplication processing and sends the correctly received data packet to the service server. In the downlink direction, the process is similar.

[0004] However, it is found in actual testing that when the dual launch technology using the MP-QUIC protocol is used to accelerate services, the actual service code stream is not increased by 2 times, but nearly 3 times, resulting in too high network traffic cost of the user and the cloud service. SUMMARY

[0005] Embodiments of the present application provide a data transmission method, device, equipment, medium and program product. The compression end compresses the packet header of a QUIC data packet, reduces the overhead of the data packet header, and thus reduces the traffic consumption of sending the QUIC data packet.

[0006] In a first aspect, an embodiment of the present application provides a data transmission method applied to a compression end, the method comprising: obtaining compression configuration information; receiving a service frame sent by an application layer, performing QUIC layer processing on the service frame to obtain two identical data packets; performing compression processing on target packet headers of the two data packets respectively according to the compression configuration information to obtain compressed data packets corresponding to the two data packets, the target packet headers including at least one of the following packet headers: a service IP packet header, a service UDP packet header and a QUIC packet header; and sending the compressed data packets corresponding to the two data packets to the decompression end through a first network connection and a second network connection respectively at the same time, wherein the first network connection and the second network connection are connections in two different networks established through a multi-channel QUIC protocol.

[0007] In some example embodiments, the compression configuration information includes at least one of the following information: context reference information, first indication information, length information of a compressed flow identification ID and length information of a compressed data packet sequence number, wherein the context reference information includes associated information of at least one existing session, and the associated information of the session includes a connection ID, a flow ID, a source IP address of a service, a target IP address, a source port number and a target port number, and the first indication information is used to indicate deletion of at least one of the following fields in a QUIC packet header: a timestamp field and a slice offset field.

[0008] In some example embodiments, when the context reference information is included in the compression configuration information, performing compression processing on the target packet headers of the two data packets according to the compression configuration information to obtain the compressed data packets corresponding to the two data packets includes: for each data packet, setting a frame type field in the QUIC packet header to a first value, the first value being used to indicate that the data packet is a compressed data packet; determining whether associated information of a session corresponding to the data packet exists in the context reference information according to a packet header of the data packet; and when the associated information of the session corresponding to the data packet exists in the context reference information, deleting a source IP address in a service IP packet header of the data packet, a target IP address, and deleting a source port number and a target port number in a service UDP packet header of the data packet.

[0009] In some example embodiments, when the first indication information is further included in the compression configuration information, performing compression processing on the target packet headers of the two data packets according to the compression configuration information further includes: deleting at least one of the following fields in the QUIC packet header of the data packet according to the first indication information: a timestamp field and a slice offset field.

[0010] In some example embodiments, when the compressed configuration information further comprises length information of the compressed flow ID and length information of the compressed data packet sequence number, the compressing the target packet header of each of the two data packets according to the compressed configuration information further comprises: setting the length of the flow ID in the QUIC packet header of the data packet as the length information of the compressed flow ID; and setting the data packet sequence number in the QUIC packet header of the data packet as the length information of the compressed data packet sequence number.

[0011] In some example embodiments, when the compression end is a terminal, the decompression end is an acceleration gateway; or when the compression end is the acceleration gateway, the decompression end is the terminal.

[0012] In some example embodiments, when the compression end is a terminal and the decompression end is an acceleration gateway, the obtaining the compressed configuration information comprises: sending a request message to the acceleration gateway, the request message being used to request to start the packet header compression function; receiving a response message of the request message returned by the acceleration gateway, the response message being used to indicate to start the packet header compression function, the response message comprising the first indication information, the length information of the flow ID, and the length information of the data packet sequence number; and obtaining the association information of the current session by sending a first normal data packet to the acceleration gateway, the normal data packet being a data packet that has not been compressed by the packet header.

[0013] In some example embodiments, after the obtaining the association information of the current session by sending the first normal data packet to the acceleration gateway, the method further comprises: periodically sending normal data packets to the acceleration gateway according to a configured sending period, so as to update the association information of the current session.

[0014] In some example embodiments, the obtaining the association information of the current session by sending the first normal data packet to the acceleration gateway comprises: sending two first normal data packets to the acceleration gateway through the first network connection and the second network connection at the same time; recording the association information of the current session according to the target packet header of the first normal data packet; receiving an acknowledgement message of the first normal data packet sent by the acceleration gateway, the acknowledgement message comprising the association information of the current session recorded by the acceleration gateway; comparing whether the locally recorded association information of the current session is the same as the association information of the current session recorded by the acceleration gateway; and determining that the association information of the current session stored by the terminal and the acceleration gateway is the same when the locally recorded association information of the current session is the same as the association information of the current session recorded by the acceleration gateway.

[0015] In some example embodiments, before the obtaining the association information of the current session by sending the first normal data packet to the acceleration gateway, the method further comprises: sending a first acknowledgement message to the acceleration gateway in response to the response message, the first acknowledgement message being used to confirm starting the packet header compression function.

[0016] In some example embodiments, when the compression end is an acceleration gateway and the decompression end is a terminal, the obtaining the compression configuration information comprises: receiving a request message sent by the terminal, the request message being used to request starting the packet header compression function; determining to start the packet header compression function according to the capability information and / or the load information; sending a response message of the request message to the terminal, the response message comprising at least one of the following information: the first indication information, the length information of the compressed flow ID and the length information of the compressed data packet sequence number; receiving a first normal data packet sent by the terminal; recording the association information of the current session according to the packet header of the first normal data packet; sending an acknowledgement message of the first normal data packet to the terminal, the acknowledgement message comprising the association information of the current session recorded by the acceleration gateway.

[0017] In some example embodiments, the method further comprises: receiving a normal data packet of the current session; updating the association information of the current session according to a target packet header of the normal data packet.

[0018] In a second aspect, the embodiments of the present application provide a data transmission method applied to a decompression end, the method comprising: obtaining compression configuration information; receiving two data packets sent by a compression end through a first network connection and a second network connection respectively, wherein the first network connection and the second network connection are connections in two different networks established through a multi-channel QUIC protocol; determining that the two data packets are compressed data packets, and performing decompression processing on target packet headers of the two data packets according to the compression configuration information to obtain decompressed data packets corresponding to the two data packets, wherein the target packet headers comprise at least one of the following packet headers: a service IP packet header, a service UDP packet header and a QUIC packet header; performing deduplication processing on the decompressed data packets corresponding to the two data packets to obtain target data packets.

[0019] In some example embodiments, the compression configuration information comprises at least one of the following: context reference information, first indication information, length information of compressed stream ID, and length information of compressed data packet sequence number, wherein the context reference information comprises associated information of at least one existing session, and the associated information of the session comprises connection ID, stream ID, source IP address, target IP address, source port number, and target port number, and the first indication information is used to indicate deletion of at least one of the following fields in the QUIC packet header: timestamp field and slice offset field.

[0020] In some example embodiments, when the context reference information is included in the compression configuration information, the decompression processing of the target packet header of the two data packets according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets comprises: for each data packet, querying whether the associated information of the session corresponding to the data packet exists in the context reference information according to the connection ID and the stream ID in the QUIC packet header of the data packet; and when the associated information of the session corresponding to the data packet exists in the context reference information, adding the source IP address and the target IP address in the service IP packet header of the data packet and adding the source port number and the target port number in the service UDP packet header of the data packet according to the associated information of the session corresponding to the data packet.

[0021] In some example embodiments, when the first indication information is further included in the compression configuration information, the decompression processing of the target packet header of the two data packets according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets further comprises: adding at least one of the following fields deleted by the compression end in the QUIC packet header according to the first indication information: timestamp field and slice offset field.

[0022] In some example embodiments, when the length information of the compressed stream ID and the length information of the compressed data packet sequence number are further included in the compression configuration information, the decompression processing of the target packet header of the two data packets according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets comprises: completing the stream ID in the QUIC packet header of the data packet to a standard length; and completing the data packet sequence number in the QUIC packet header of the data packet to a standard length.

[0023] In some exemplary embodiments, the step of deduplicating the decompressed data packets corresponding to the two data packets to obtain the target data packet includes: when the flow ID, message sequence number, and data packet sequence number of the decompressed data packets corresponding to the two data packets are all the same, determining that the decompressed data packets corresponding to the two data packets are the same data packets; deleting one of the decompressed data packets corresponding to the two data packets, and using the remaining data packet as the target data packet.

[0024] Thirdly, embodiments of this application provide a data transmission apparatus, comprising: an acquisition module, a processing module, a compression module, and a sending module. The acquisition module is used to acquire compression configuration information; the processing module is used to receive service frames sent by the application layer, perform QUIC layer processing on the service frames, and obtain two identical data packets; the compression module is used to compress the target headers of the two data packets according to the compression configuration information, obtaining compressed data packets corresponding to the two data packets, wherein the target header includes at least one of the following headers: a service IP header, a service UDP header, and a QUIC header; the sending module is used to simultaneously send the compressed data packets corresponding to the two data packets to a decompression end through a first network connection and a second network connection, wherein the first network connection and the second network connection are connections established through a multi-channel QUIC protocol located in two different networks.

[0025] Fourthly, embodiments of this application provide a data transmission apparatus, comprising: an acquisition module, a receiving module, a decompression module, and a deduplication module. The acquisition module is used to acquire compression configuration information; the receiving module is used to receive two data packets sent by a compression end through a first network connection and a second network connection, wherein the first network connection and the second network connection are connections established through a multi-channel QUIC protocol located in two different networks; the decompression module is used to determine that the two data packets are compressed data packets, and to decompress the target headers of the two data packets according to the compression configuration information to obtain decompressed data packets corresponding to the two data packets, wherein the target headers include at least one of the following headers: a service IP header, a service UDP header, and a QUIC header; the deduplication module is used to deduplicatize the decompressed data packets corresponding to the two data packets to obtain target data packets.

[0026] Fifthly, embodiments of this application provide a communication device, comprising: a processor and a memory, wherein the memory stores a computer program, and the processor invokes and runs the computer program stored in the memory to perform the method described in the first or second aspect above. The communication device may be a terminal or an acceleration gateway.

[0027] In a sixth aspect, embodiments of this application provide a computer-readable storage medium for storing a computer program that causes a computer to perform the method described in the first or second aspect above.

[0028] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in the first or second aspect above.

[0029] The technical solution provided in this application embodiment involves a compression end acquiring compression configuration information, receiving service frames sent by the application layer, performing QUIC layer processing on the service frames to obtain two identical data packets. Based on the compression configuration information, the target headers of the two data packets are compressed respectively to obtain compressed data packets corresponding to the two data packets. The target header includes at least one of the following headers: a service IP header, a service UDP header, and a QUIC header. Simultaneously, the compressed data packets corresponding to the two data packets are sent to the decompression end through connections located in two different networks. By compressing the header of the QUIC data packets, the compression end reduces the overhead of the data packet header, thereby reducing the traffic consumption of sending QUIC data packets. Attached Figure Description

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

[0031] Figure 1 This is a diagram illustrating the position of the QUCI layer within the traditional HTTPS protocol stack.

[0032] Figure 2 This is a schematic diagram of the structure of a data packet transmitted using QUIC in traditional technology;

[0033] Figure 3 This is a schematic diagram of the QUIC header structure;

[0034] Figure 4 This is a schematic diagram of the network system architecture applicable to the embodiments of this application;

[0035] Figure 5 A schematic diagram of the functional modules of the dual-channel acceleration SDK and the dual-channel acceleration gateway;

[0036] Figure 6 A flowchart of the data transmission method provided in Embodiment 1 of this application;

[0037] Figure 7 A flowchart of the data transmission method provided in Embodiment 2 of this application;

[0038] Figure 8 A flowchart of the data transmission method provided in Embodiment 3 of this application;

[0039] Figure 9 This is a schematic diagram of the data transmission device provided in Embodiment 4 of this application;

[0040] Figure 10 This is a schematic diagram of the data transmission device provided in Embodiment 5 of this application;

[0041] Figure 11 This is a schematic diagram of a communication device provided in Embodiment Six of this application. Detailed Implementation

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

[0043] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0044] QUIC: Quick UDP Internet Connection. QUIC was primarily designed to address some of the problems encountered by the Transmission Control Protocol (TCP) in practical applications, such as header blocking, low congestion control efficiency, connection drops due to Internet Protocol (IP) / port changes, three-way handshake overhead, and relatively low out-of-band control efficiency. QUIC can be seen as a transport protocol that can replace TCP.

[0045] Figure 1 This is a diagram illustrating the position of the QUCI layer in the traditional HTTPS protocol stack. (Refer to...) Figure 1 As shown, the QUIC layer is located between the application layer and the User Datagram Protocol (UDP) layer. The QUIC layer replaces the TCP layer and the Transport Layer Security (TLS) layer of the traditional Hypertext Transfer Protocol Secure (HTTPS).

[0046] The QUIC layer is built on top of the UDP layer and typically runs in user space. The QUIC layer provides functions such as error retransmission, congestion control, and flow control. The advantages of QUIC include, but are not limited to: fast connection establishment (connections can be established with 1 round-trip time (RTT) or 0 RTT); flexible congestion control mechanisms with customizable congestion control algorithms; multiplexing to alleviate head-of-line congestion; and support for connection migration.

[0047] MP-QUIC: Multi-channel QUIC protocol. MP-QUIC is an extension of QUIC. MP-QUIC was designed with the following considerations: (1) Reuse the original QUIC as much as possible, such as reusing QUIC's path validation and connection migration mechanisms; (2) Use the same packet header as QUIC; (3) Congestion control, RTT measurement, and Path Maximum Transmission Unit (PMTU) detection are implemented per physical link; (4) The path is uniquely identified by an IP quadtuple.

[0048] For some latency-sensitive services, such as real-time games, using a single network to transmit service data obviously cannot meet the latency and reliability requirements. To solve this technical problem, existing technologies have introduced the 5G+WiFi dual-transmission function. The dual-transmission function refers to transmitting application data through two different networks (5G and WiFi). The basic principle of the dual-transmission function is as follows: In the uplink direction, the accelerator APP on the terminal (or service terminal) copies the service data packet and sends it to the acceleration gateway simultaneously through the 5G link and the WiFi link. The acceleration gateway performs deduplication and sends the correctly received data packet to the service server. The downlink direction is similar.

[0049] Dual transmission reduces network latency and jitter by sending data packets simultaneously on two network links. Successful reception is achieved as long as either data packet is transmitted correctly. In other words, it consumes more network resources to ensure data transmission latency performance and reliability.

[0050] The dual-transmission function of the service can be based on the MP-QUIC protocol mentioned above. There are two connections (or paths or links) between the accelerator APP and the service gateway. One connection is based on the 5G network (referred to as the 5G connection), and the other connection is based on the WiFi network (referred to as the WiFi connection). Service data packets are transmitted simultaneously through the two connections.

[0051] Actual testing shows that when dual-transmission of services is implemented based on MP-QUIC, the actual service bitrate does not increase by 2 times (due to dual-transmission), but by nearly 3 times. This significantly increases network traffic costs for both users and cloud services. The reason for this is that in addition to the traditional IP and UDP headers, a QUIC header is added. The QUIC header consists of two parts: the QUIC Common Header and the Datagram Flow Frame header. The overhead of these two parts can reach up to 36 bytes. In some scenarios, service data consists of small packets; for example, typical game data packets are small packets with payloads ranging from tens to hundreds of bytes. Therefore, in such small packet scenarios, the overhead of the QUIC header is very high, exceeding 30%.

[0052] Figure 2 This is a schematic diagram of the structure of a data packet transmitted using QUIC in traditional technology, such as... Figure 2 As shown, the data packet, from the outermost layer to the innermost layer (i.e., from left to right), includes the following six parts: QUIC layer IP header (i.e., the outermost IP header), QUIC layer UDP header (i.e., the outermost UDP header), QUIC header, service IP header (i.e., the innermost IP header), service UDP header (i.e., the innermost UDP header), and payload. The QUIC layer IP header, QUIC layer UDP header, and QUIC header are added after adopting MP-QUIC transmission, while the service IP header and service UDP header are the header overhead of the original service before adopting MP-QUIC transmission.

[0053] The QUIC layer IP header and QUIC layer UDP header are used for terminal routing to the acceleration gateway. The QUIC layer IP header includes the source IP address and the acceleration gateway's IP address, while the QUIC layer UDP header includes the source port number and the acceleration gateway's port number. The service IP header and service UDP header are used for routing to the service server. The service IP header includes the source IP address and the service server's IP address (destination IP address), while the service UDP header includes the source port number and the service server's port number (destination port number). Here, the source IP address refers to the service application's IP address, and the source port number refers to the service application's port number.

[0054] refer to Figure 2 As shown, before using MP-QUIC, the overhead of the service header was 28 bytes (the sum of the service IP header and the service UDP header). After using MP-QUIC, the header size became 92 bytes, an increase of 64 bytes (the sum of the QUIC layer IP header, the QUIC layer UDP header, and the QUIC header), and the total overhead of the data packet header increased by 3.2 times.

[0055] To address the issue of excessive packet header overhead caused by using MP-QUIC, this application provides a data transmission method for compressing one or more of the QUIC header, service IP header, and service UDP header to reduce packet header overhead.

[0056] Figure 3 This is a schematic diagram of the QUIC header structure, as shown below. Figure 3 As shown, the QUIC header consists of two parts: the QUIC general header and the datagram stream frame header. The QUIC general header includes the following fields: Flag, Connection ID (CID), PathID, and Packet Number. The length of the QUIC general header is 11, 12, 14, or 16 bytes because the length of Packet Number is a variable length of 8, 16, 32, or 48 bits.

[0057] The Flag field consists of 8 bits, and the meaning of each bit is as follows:

[0058] Bit0 is a version negotiation related identifier, and its meaning differs depending on whether it is sent by the client or the server.

[0059] Bit1 is used to identify the public reset message.

[0060] Bit2 and Bit3 represent the length of the CID in the message.

[0061] Bit4 and Bit5 represent the number of bytes containing the sequence number of the data packets in each data packet.

[0062] Bit6: Reserved for multipathing, used to indicate whether a data packet is multipathed or singlepathed.

[0063] CID: An unsigned integer with a maximum length of 64 bits, randomly selected by the client; the length is variable.

[0064] PathID: Identifies multi-path paths.

[0065] PacketNumber: Packet sequence number (or packet number). It is assumed that the sequence number of the first packet sent by the sender is 1, and the sequence numbers of the subsequent packets are all greater than the sequence number of the previous packet.

[0066] A Datagram Flow Frame includes the following fields:

[0067] Type (Frame Type): Distinguishes whether it is a DatagramFlow frame. Type has multiple values, including 0x30 indicating the end of the connection, 0x31 indicating normal data, and 0x33 indicating fragmented data.

[0068] Length: Data length of Datagram, including the length of fixed fields such as FlowID, SeqNum, Timestamp, and FragOffset.

[0069] FlowID (Flow Identifier): Used to identify a DatagramFlow and distinguish business connections.

[0070] SeqNum (Message Sequence Number): Used to identify the sequence number or number of the sent message. It uniquely identifies the message within the same DatagramFlow and is used by the receiving end to determine whether data packets are duplicated, thus removing duplicates.

[0071] Timestamp: Used to identify the time when a message was sent. It is used by the receiving end to determine whether the data has expired and to discard expired messages.

[0072] FragOffset (fragment offset, or simply fragment offset): Reassembles packets based on fragment offsets. Where Type is 0x31 and FragOffset is 0, it indicates a non-fragmented packet; Type is 0x33 and FragOffset is 0, it indicates the first packet of a fragment; and Type is 0x31 and FragOffset is not 0, it indicates the last packet of a fragment.

[0073] Figure 4 This is a schematic diagram of the network system architecture applicable to the embodiments of this application, such as...Figure 4 As shown, the network system includes: a terminal, a dual-channel acceleration gateway (hereinafter referred to as the acceleration gateway), and a service server.

[0074] The terminal runs a business APP and a dual-channel acceleration software development kit (SDK). The dual-channel acceleration SDK can be called by the accelerator APP on the terminal to achieve dual-channel acceleration for the business APP. In this embodiment, the dual-channel acceleration SDK is used to achieve dual-channel acceleration through MP-QUIC. The dual-channel acceleration SDK establishes two QUIC connections with the dual-channel acceleration gateway in the cloud: a 5G connection and a WiFi connection. The 5G connection enables communication between the terminal and the dual-channel acceleration gateway through the 5G network, and the WiFi connection enables communication between the terminal and the dual-channel acceleration gateway through the WiFi network.

[0075] In traditional technology, in the uplink direction, the terminal's accelerator app copies the service data packets, for example... Figure 4 As shown, the accelerator APP copies data packet 1 and data packet 2 into two data packets, and sends them to the dual-channel acceleration gateway simultaneously via 5G and WiFi connections. The dual-channel acceleration gateway performs deduplication on the received service data packets and sends the correctly received service data packets to the service server. For example, for data packet 1, the dual-channel acceleration gateway will receive two data packets through two connections, and the two data packets need to be deduplicated.

[0076] In traditional technology, the process is similar in the downlink direction. The service server sends the service data packets to the dual-channel acceleration gateway. The dual-channel acceleration gateway copies the service data packets and sends them to the accelerator APP simultaneously via 5G and WiFi connections. The accelerator APP deduplicatizes the received service data packets and sends the correctly received service data packets to the service APP.

[0077] In this embodiment, the functionality of the dual-channel acceleration SDK and the dual-channel acceleration gateway has been extended, enabling them to compress and decompress the headers of service data packets.

[0078] Figure 5 A schematic diagram of the functional modules of the dual-channel acceleration SDK and dual-channel acceleration gateway, as shown below. Figure 5As shown, both the QUIC dual-channel acceleration SDK and the dual-channel acceleration gateway include a QUIC dual-channel acceleration module, a packet header compression / decompression module (also known as an MP-QUIC compression / decompression module), and compression configuration information. The QUIC dual-channel acceleration module is an existing functional module in both the dual-channel acceleration SDK and the dual-channel acceleration gateway, used to achieve dual-channel acceleration via MP-QUIC, including but not limited to connection establishment, packet encapsulation, and path management.

[0079] The header compression / decompression module and compression configuration information are new additions. The compression configuration information is a general term for the relevant information used for header compression obtained from the interaction between the dual-channel acceleration SDK and the dual-channel acceleration gateway. The header compression / decompression module compresses the service data packets based on the compression configuration information and decompresses the compressed service data packets based on the compression configuration information.

[0080] Taking uplink transmission as an example, the data processing flow of the dual-channel acceleration SDK and the dual-channel acceleration gateway is described as follows: After receiving the service message sent by the service APP, the dual-channel acceleration SDK first encapsulates and copies the service message through the QUIC dual-channel acceleration module, obtaining two service data packets. Then, the header compression / decompression module compresses the headers of the two service data packets according to the compression configuration information, and sends the two compressed service data packets to the dual-channel acceleration gateway through the 5G connection and WiFi connection, respectively. After receiving the compressed service data packets through the two connections, the dual-channel acceleration gateway's header compression / decompression module decompresses the two compressed service data packets according to the compression configuration information, obtaining two decompressed service data packets. Then, the QUIC dual-channel acceleration module performs deduplication and other processing on the two decompressed service data packets and sends the normal service data packets to the service server. Downlink transmission is similar and will not be repeated here.

[0081] As can be seen from the uplink and downlink data processing flow, the packet header compression and decompression functions added in this application embodiment are compression operations and corresponding decompression operations added outside the original processing flow.

[0082] In this embodiment of the application, the terminal can be a smartphone, tablet computer, laptop computer, desktop computer, dedicated gaming device, etc., but is not limited to these.

[0083] A business server is used to provide services to business apps on the terminal. This business server can be an application server, a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0084] In one embodiment of this application, the method is applied in a game scenario, particularly suitable for real-time games with small data packets. Accordingly, the business app on the terminal is a game app, the business server can be a game server, and the dual-channel acceleration gateway can be called an acceleration gateway.

[0085] After introducing some concepts involved in the embodiments of this application, the data transmission method provided by the embodiments of this application will be specifically described below with reference to the accompanying drawings.

[0086] Figure 6 This is a flowchart of the data transmission method provided in Embodiment 1 of this application. The method in this embodiment is executed by the compression end, such as... Figure 6 As shown, the method provided in this embodiment includes the following steps:

[0087] S101. Obtain compression configuration information.

[0088] During uplink transmission, the compression end is the terminal, and the decompression end is the acceleration gateway. During downlink transmission, the compression end is the acceleration gateway, and the decompression end is the terminal. The terminal and acceleration gateway interact before transmitting data packets, each obtaining the same compression configuration information, and then perform compression and decompression processing based on this shared configuration information. It can be understood that the terminal and acceleration gateway may need to negotiate through multiple messages to obtain this compression configuration information.

[0089] The compression configuration information includes at least one of the following: context reference information, first indication information, length information of the compressed flow ID (FlowID), and length information of the compressed packet number (PacketNumber).

[0090] The context reference information includes association information for at least one existing session. The association information for a session includes: Connection ID (CID), FlowID, source IP address of the data packet, destination IP address, source port number, and destination port number. The CID, FlowID, source IP address of the data packet, destination IP address, source port number, and destination port number are the same for the same session.

[0091] The first instruction information is used to instruct the removal of at least one of the following fields from the QUIC header: the Timestamp field and the FragOffset field.

[0092] S102. Receive the service message sent by the application layer, process the service message using the QUIC layer, and obtain two identical data packets.

[0093] A packet is a complete, processable unit in the QUIC protocol. It can be encapsulated in a UDP datagram, and multiple packets (or QUIC packets) can be encapsulated in a single UDP datagram.

[0094] A frame is the payload of a QUIC data packet and is the smallest unit of data in QUIC. A frame contains control information or application data, and a QUIC data packet can carry one or more frames.

[0095] In this embodiment, MP-QUIC is used for dual data transmission between the terminal and the acceleration gateway. Therefore, the compression end needs to process the service frames sent by the application layer through the QUIC layer to obtain two identical data packets, which are then sent to the decompression end through two connections. For uplink data, the compression end is the terminal, and the terminal's accelerator APP receives service frames sent by the service APP (e.g., a game APP) and processes them through the QUIC layer to obtain two identical data packets. For downlink data, the compression end is the acceleration gateway, which receives service frames sent by the service server and processes them through the QUIC layer to obtain two identical data packets.

[0096] This embodiment will not elaborate on the processing of the QUIC layer; the data packet structure after processing by the QUIC layer is referred to [reference needed]. Figure 2 As shown, the data packet includes: a QUIC layer IP header, a QUIC layer UDP header, a QUIC header, a service IP header, a service UDP header, and a payload (i.e., a service frame). The QUIC layer IP header and QUIC layer UDP header are used for routing to the acceleration gateway.

[0097] S103. Based on the compression configuration information, compress the target headers of the two data packets respectively to obtain compressed data packets corresponding to the two data packets. The target header includes at least one of the following headers: service IP header, service UDP header, and QUIC header.

[0098] Reference Figure 2As shown, since the QUIC layer IP header and QUIC layer UDP header are used for routing to the acceleration gateway, the QUIC layer IP header and QUIC layer UDP header cannot be compressed. Only one or more of the QUIC header, service IP header, and service UDP header can be compressed.

[0099] For each of the two data packets, the compression end first sets the frame type field in the QUIC header to a first value. This first value is used to indicate that the data packet is a compressed data packet. This first value can be different from the existing frame type field value. For example, the first value is 0x35. By setting the frame type to 0x35, the compression end enables the decompression end to determine that the header of the received data packet has been compressed based on 0x35.

[0100] In this embodiment, the compression end mainly performs at least one of the following three types of compression operations on the packet header:

[0101] The first compression operation: When the compression configuration information includes context reference information, the service IP header and service UDP header of the data packet need to be compressed. For example, the compression end determines whether the context reference information contains association information for the session corresponding to the data packet based on the packet header. If the context reference information contains association information for the session corresponding to the data packet, then the source IP address and destination IP address in the service IP header of the data packet, as well as the source port number and destination port number in the service UDP header of the data packet, are deleted.

[0102] The packet header includes CID, FlowID, source IP address of the service, destination IP address, source port number, and destination port number. The context information stores association information for one or more sessions, and the association information for each session includes: CID, FlowID, source IP address of the service, destination IP address, source port number, and destination port number.

[0103] For example, the compression end obtains the associated information of the session corresponding to the data packet from the packet header: CID, FlowID, source IP address of the service, destination IP address, source port number and destination port number. It then matches the associated information of the session corresponding to the data packet with the context reference information. If the associated information of the destination session in the context reference information is the same as the associated information of the session corresponding to the data packet, it is determined that the associated information of the session corresponding to the data packet exists in the context reference information. Accordingly, the compression end deletes the source IP address and destination IP address from the service IP packet header of the data packet, and deletes the source port number and destination port number from the service UDP packet header of the data packet.

[0104] By removing the source IP address, destination IP address, source port number, and destination port number from the packet header, the amount of data in the packet header is reduced, thereby reducing the network traffic consumed in sending the packet. Since the context reference information contains the associated session information for this packet, the decompression end can recover the source IP address, destination IP address, source port number, and destination port number of the packet based on this context reference information.

[0105] The second compression operation: When the compression configuration information includes the first indication information, the QUIC header of the data packet needs to be compressed. Specifically, the compression end performs the following compression operation: Based on the first indication information, at least one of the following fields is deleted from the QUIC header of the data packet: the Timestamp field and the Fragoffset field. In some applications, Timestamp and Fragoffset are not needed; for example, in game applications, Timestamp and Fragoffset are not required, therefore, the Timestamp and Fragoffset fields can be deleted.

[0106] By removing the Timestamp and Fragoffset fields from the QUIC header of this data packet, the amount of data in the packet header is reduced, thus lowering the overhead of the packet header and reducing the network resources used to send the data packet.

[0107] The third compression operation: When the compression configuration information includes the length information of the compressed flow ID and / or the length information of the compressed data packet sequence number, the compression end performs the following compression operation: sets the length of the flow ID in the QUIC header of the data packet to the length information of the compressed flow ID; and / or sets the data packet sequence number in the QUIC header of the data packet to the length information of the compressed data packet sequence number.

[0108] Without compressing the lengths of flowID and PacketNumber, both use standard lengths. For example, the standard length of flowID is 24 bits, and the length of PacketNumber is 48 bits or 32 bits. The compressed length of flowID is less than the standard length, and the compressed length of PacketNumber is also less than the standard length. For example, the compressed length of flowID is 8 bits, and the compressed length of PacketNumber is 8 bits.

[0109] By compressing the length of the flowID and PacketNumber in the packet header, the amount of data in the packet header is reduced, thereby reducing the network traffic used to send the packet.

[0110] In this embodiment, the compression end can perform one or more of the above three compression operations on the data packet. When the compression end performs the above three compression operations on the packet header, and in the second compression operation, both the Timestamp field and the Fragoffset field are deleted, and in the third compression operation, the lengths of flowID and PacketNumber are compressed to 8 bits, then after the above header compression operations, the size of the compressed header is 67 bytes, which is 25 bytes less than the previous 92 bytes, a reduction of 27%.

[0111] The compression scheme provided in this embodiment does not require reference to any information from preceding packets. The compression of each data packet is performed independently, and the compression of each data packet is only related to its own information. Therefore, the error propagation problem in traditional compression schemes does not exist, thus ensuring the latency performance of services. Traditional compression schemes usually refer to information from preceding packets, such as PacketNumber and SuqNum. Because they require reference to information from preceding packets, if the preceding packet is lost or delayed, it will affect the compression of subsequent packets, which may lead to error propagation or increased latency.

[0112] S104. At the same time, the compressed data packets corresponding to the two data packets are sent to the decompression end through the first network connection and the second network connection respectively. The first network connection and the second network connection are connections located in two different networks established by the multi-channel QUIC protocol.

[0113] For example, the first network connection is a 5G connection, and the second network connection is a WiFi connection. The compression end establishes two network connections with the decompression end via the QUIC protocol. For two data packets, a compressed data packet is obtained by compressing the packet header. The two compressed data packets are identical. At the same time, the compression end sends one compressed data packet to the decompression end via the first network connection and the other compressed data packet to the decompression end via the second network connection.

[0114] In this embodiment, the compression end obtains compression configuration information, receives service frames sent by the application layer, performs QUIC layer processing on the service frames, and obtains two identical data packets. According to the compression configuration information, the target headers of the two data packets are compressed respectively to obtain compressed data packets corresponding to the two data packets. The target header includes at least one of the following headers: a service IP header, a service UDP header, and a QUIC header. Simultaneously, the compressed data packets corresponding to the two data packets are sent to the decompression end through connections located in two different networks. By compressing the header of the QUIC data packets, the compression end reduces the overhead of the data packet header, thereby reducing the traffic consumption of sending QUIC data packets.

[0115] Figure 7 This is a flowchart of the data transmission method provided in Embodiment 2 of this application. The method in this embodiment is executed by the decompression end, such as... Figure 7 As shown, the method provided in this embodiment includes the following steps:

[0116] S201. Obtain compression configuration information.

[0117] During uplink transmission, the compression end is the terminal, and the decompression end is the acceleration gateway. During downlink transmission, the compression end is the acceleration gateway, and the decompression end is the terminal. The terminal and acceleration gateway interact before transmitting data packets, each obtaining the same compression configuration information, and then perform compression and decompression processing based on this shared configuration information. It can be understood that the terminal and acceleration gateway may need to exchange multiple messages to obtain this compression configuration information.

[0118] The compression configuration information includes at least one of the following: context reference information, first indication information, length information of the compressed FlowID, and length information of the compressed PacketNumber. The context reference information includes association information for at least one existing session, which includes: CID, FlowID, source IP address of the packet, destination IP address, source port number, and destination port number. The first indication information is used to instruct the removal of at least one of the following fields from the QUIC header: the Timestamp field and the FragOffset field.

[0119] S202. Receive two data packets sent by the compression end through the first network connection and the second network connection respectively, wherein the first network connection and the second network connection are connections located in two different networks established by the multi-channel QUIC protocol.

[0120] In this embodiment, the compression and decompression ends communicate via the MP-QUIC protocol. The compression and decompression ends each establish a connection in two different networks. For example, the first network connection is a 5G connection and the second network connection is a WiFi connection.

[0121] S203. Determine that the two data packets are compressed data packets. Decompress the target headers of the two data packets according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets. The target headers include at least one of the following headers: service IP header, service UDP header, and QUIC header.

[0122] In the absence of packet loss, the decompression end will receive one packet on each of the two network connections, and the two packets received will be identical. The decompression end needs to perform deduplication processing on the packets received on the two connections.

[0123] In this embodiment, both compressed data packets and normal data packets are transmitted over the two network connections. Normal data packets refer to data packets that have not undergone packet header compression.

[0124] After receiving two data packets, the decompression end reads the value of the Type field from the DatagramFlow Frame header of the QUIC packet header of the two data packets. Based on the value of the Type field, it determines whether the data packet is a normal data packet or a compressed data packet. For example, when the value of the Type field is 0x31, it indicates that the data packet is a normal data packet, and when the value of the Type field is 0x35, it indicates that the data packet is a compressed data packet.

[0125] When it is determined that the two data packets are normal data packets, the decompression end executes step S204 to perform deduplication on the two data packets to obtain the target data packet.

[0126] When two data packets are determined to be compressed, the decompression end decompresses the target headers of the two data packets according to the compression configuration information. Deduplication is only performed after decompression. The decompression operation on the decompression end corresponds one-to-one with the compression operation on the compression end; that is, the decompression end knows in advance which compression operations have been performed on the compression end, and accordingly, it executes the decompression operation corresponding to the compression operation on the compression end.

[0127] In Example 1, the compression end performed one or more of the three compression operations. Correspondingly, the decompression end mainly performed the following three types of decompression operations on the packet header:

[0128] The first decompression operation: Corresponding to the first compression operation, when the compression configuration information includes context reference information, the compression end compresses the service IP header and service UDP header of the data packet. Correspondingly, the decompression end needs to decompress the service IP header and service UDP header of the data packet. For example, for each data packet, the decompression end queries the context reference information to see if there is association information for the session corresponding to that data packet, based on the CID and flowID in the QUIC header of the data packet. If the association information for the session corresponding to that data packet exists in the context reference information, then, based on the association information for the session corresponding to that data packet, the source IP address and destination IP address are added to the service IP header of the data packet, and the source port number and destination port number are added to the service UDP header of the data packet.

[0129] The context reference information includes the CID, flowID, source IP address, destination IP address, source port number, and destination port number for each session. The decompression end can obtain the CID and flowID of the corresponding session from the packet header. Based on the CID and flowID of the corresponding session, it can query the source IP address, destination IP address, source port number, and destination port number of the session from the context information. According to the format of the packet header, it completes the missing source IP address, destination IP address, source port number, and destination port number in the packet header.

[0130] The second decompression operation: Corresponding to the second compression operation, when the compression configuration information includes the first indication information, the compression end compresses the QUIC header of the data packet, and correspondingly, the decompression end decompresses the QUIC header of the data packet according to the first indication information. In one implementation, the decompression end adds at least one of the following fields that the decompression end has deleted to the QUIC header according to the first indication information: the Timestamp field and the FragOffset field.

[0131] For example, the decompression end can set the values ​​of the Timestamp field and / or the FragOffset field to fixed values. For instance, when the Timestamp field is 32 bits and the FragOffset field is 16 bits, the 32 bits of the Timestamp field are all set to 0 and the 16 bits of the FragOffset field are all set to 0. Alternatively, the 32 bits of the FragOffset field are all set to 1 and the 16 bits of the FragOffset field are all set to 1.

[0132] The third decompression operation: Corresponding to the third compression operation, when the compression configuration information includes the length information of the compressed FlowID and the length information of the compressed PacketNumber, the compression end compresses the FlowID and PacketNumber in the QUIC header of the data packet. Correspondingly, the decompression end decompresses the header of the data packet according to the length information of the compressed FlowID and the length information of the compressed PacketNumber.

[0133] For example, the decompression end pads the FlowID in the QUIC header of the data packet to the standard length, and also pads the PacketNumber in the QUIC header of the data packet to the standard length. When the length of the compressed FlowID and the length of the compressed PacketNumber are both 8 bits, the standard length of FlowID is 24 bits, and the standard length of PacketNumber is 48 bits, the decompression end can set the high 16 bits of FlowID to a fixed value (e.g., all 0s), while keeping the low 8 bits of FlowID unchanged (i.e., the value after compression), and set the high 40 bits of PacketNumber to a fixed value (e.g., all 0s), while keeping the low 8 bits of PacketNumber unchanged (i.e., the value after compression).

[0134] In this embodiment, the decompression end performs the above three decompression operations on the data packet, so that the header length and format of the decompressed data packet are the same as those of the normal data packet. When the decompression end or the subsequent upper-layer application processes the data packet, it does not need to distinguish whether the data packet is a normal data packet or a decompressed data packet, and the processing of the two is consistent.

[0135] Optionally, when the compression configuration information includes the first indication information, in some implementations, the decompression end may not use the second decompression method described above. If the decompression end learns from the first indication information that the compression end has deleted the Timestamp and / or FragOffset, it will not add Timestamp and FragOffset, thereby making the header length and format of the decompressed data packet different from that of the normal data packet.

[0136] Similarly, when the compression configuration information includes the length of the compressed FlowID and the length of the compressed PacketNumber, in some implementations, the decompression end may not use the third decompression method mentioned above. The decompression end can know that the compression end has compressed the length of FlowID and PacketNumber based on the length of the compressed FlowID and the length of the compressed PacketNumber, and then use the compressed length to obtain FlowID and PacketNumber from the packet header, so that the header length and format of the decompressed data packet are different from those of the normal data packet.

[0137] When the header length and format of a decompressed data packet differ from those of a normal data packet, the decompression end or upper-layer application needs to process the packet header. It is necessary to distinguish between normal data packets and decompressed data packets, and use the corresponding header format for each type of data packet to obtain the correct header and payload information.

[0138] S204. Perform deduplication on the decompressed data packets corresponding to the two data packets to obtain the target data packet.

[0139] In the MP-QUIC protocol, if the data packets received on two connections are the same, they need to be deduplicated before being sent to the upper-layer application, and only one data packet is kept as the target data packet.

[0140] In this embodiment, deduplication can be performed as follows: compare the FlowID, SeqNum, and PacketNumber of two decompressed data packets. When the FlowID, SeqNum, and PacketNumber of the decompressed data packets corresponding to the two data packets are all the same, it is determined that the decompressed data packets corresponding to the two data packets are the same data packets; delete one of the decompressed data packets corresponding to the two data packets, and the remaining data packet is used as the target data packet.

[0141] If any one of the FlowID, SeqNum, and PacketNumber of two decompressed data packets is different, it is determined that the two decompressed data packets are not the same data packets. The difference between the two decompressed data packets may be caused by data packet loss or other reasons. The decompression end can further identify the difference and notify the compression end to retransmit or perform other processing based on the identification.

[0142] In existing technologies, deduplication is typically performed only based on the FlowID and SeqNum of two data packets. If both the FlowID and SeqNum are identical, the two data packets are considered the same. In this embodiment, after compressing the length of the FlowID and / or PacketNumber, deduplication is performed based on the FlowID, SeqNum, and PacketNumber of the two decompressed data packets, ensuring the accuracy of deduplication.

[0143] In this embodiment, the decompression end obtains compression configuration information and receives two data packets sent by the compression end through connections located in two different networks. It determines that the two data packets are compressed data packets and decompresses the target headers of the two data packets according to the compression configuration information to obtain decompressed data packets corresponding to the two data packets. The target header includes at least one of the following headers: a service IP header, a service UDP header, and a QUIC header. The decompressed data packets corresponding to the two data packets are then deduplicated to obtain the target data packets. By compressing the packet headers of the data packets and decompressing the compressed data packets, the compression end reduces the amount of data in the packet headers, thereby reducing the network traffic consumed in sending the data packets.

[0144] Figure 8 This is a flowchart of the data transmission method provided in Embodiment 3 of this application. Based on Embodiments 1 and 2, this embodiment mainly describes in detail an implementation method for the interaction between the compression end and the decompression end to obtain compression configuration information, such as... Figure 8 As shown, the method provided in this embodiment includes the following steps.

[0145] S301. The terminal sends a request message to the acceleration gateway, which is used to request the packet header compression function to be enabled.

[0146] When dual-channel transmission is enabled, the terminal determines to enable the header compression function and sends a request message to the acceleration gateway to request that the header compression function be enabled.

[0147] S302. The acceleration gateway determines whether to enable the packet header compression function based on the capability information and / or load information.

[0148] After receiving the request message, the acceleration gateway can make a decision based on its own capability information and / or load information to determine whether to enable the header compression function. The acceleration gateway's capability information includes indications of whether the acceleration gateway supports the header compression function. If the acceleration gateway's capability information determines that it supports the header compression function, it can further determine whether to enable the header compression function based on the acceleration gateway's load information.

[0149] Enabling packet header compression and decompression on the acceleration gateway requires significant computing and storage resources. If the acceleration gateway is currently under heavy load, enabling packet header compression is not advisable, as it could overload the gateway. However, if the acceleration gateway's current load is moderate, then enabling packet header compression is recommended.

[0150] S303, The acceleration gateway sends a response message to the terminal for the request message, the response message including at least one of the following information: first indication information, length information of compressed FlowID and length information of compressed PacketNumber.

[0151] The acceleration gateway determines whether to enable packet header compression based on capability information and / or load information, and determines the first indication information, the length of the compressed FlowID, and the length of the compressed PacketNumber based on service conditions and configuration. It then sends a response message to the terminal that requests the message. The response message includes at least one of the following information: the first indication information, the length of the compressed FlowID, and the length of the compressed PacketNumber.

[0152] Optionally, the response message includes compression permission information, through which the acceleration gateway explicitly instructs the terminal to allow the packet header compression function to be enabled. For example, the compression permission information is a 1-bit instruction.

[0153] Of course, the response message may not include compression permission information. The acceleration gateway implicitly instructs the terminal to enable header compression by including the first permission information, the length of the compressed FlowID, and the length of the compressed PacketNumber in the response message. After receiving the response message, if the terminal receives at least one of the following information: the first permission information, the length of the compressed FlowID, and the length of the compressed PacketNumber, it considers that the acceleration gateway has enabled header compression.

[0154] If the acceleration gateway determines that header compression is not enabled, it will instruct the terminal not to enable header compression by responding with a message.

[0155] S304. The terminal sends the first confirmation message to the acceleration gateway.

[0156] After receiving the response message, the terminal determines to enable the header compression function based on the response message, and then sends a first confirmation message to the acceleration gateway. This first confirmation message is used to confirm that the header compression function is enabled.

[0157] S305, The terminal sends the first normal data packet to the acceleration gateway.

[0158] The terminal and the acceleration gateway confirm that the packet header compression function is enabled through three message exchanges. Then the terminal can start sending data packets. The terminal sends the first normal data packet to the acceleration gateway to obtain the association information of the current session. The normal data packet is a data packet that has not undergone packet header compression.

[0159] S306. The acceleration gateway records the association information of the current session based on the header of the first normal data packet.

[0160] The acceleration gateway receives the first normal data packet, parses the header of the first normal data packet, and obtains the association information of the current session. The association information of the current session includes the CID, FlowID, source IP address, destination IP address, source port number, and destination port number of the current session.

[0161] S307. The acceleration gateway sends an acknowledgment message for the first normal data packet to the terminal. The acknowledgment message includes the association information of the current session recorded by the acceleration gateway.

[0162] The acceleration gateway sends its recorded association information for the current session to the terminal so that the terminal can confirm whether the information of both parties is consistent.

[0163] S308. The terminal confirms that the association information of the current session stored by both parties is the same.

[0164] When a terminal sends its first normal data packet to the acceleration gateway, it records the association information of the current session based on the header of the first normal data packet.

[0165] The terminal receives an acknowledgment message for the first normal data packet sent by the acceleration gateway, obtains the association information of the first normal data packet recorded by the acceleration gateway from the acknowledgment message, and compares the association information of the current session recorded locally with the association information of the current session recorded by the acceleration gateway. If the association information of the current session recorded locally by the terminal is the same as the association information of the current session recorded by the acceleration gateway, the terminal determines that the association information of the current session stored by both terminals is the same.

[0166] After the terminal confirms that the current session association information stored by both parties is the same, it stores the current session association information obtained in step S308 into the context information, and uses the first indication information obtained in S203, the length information of the compressed FlowID and the length information of the compressed PacketNumber together with the context information as compression configuration information for subsequent compression and decompression processing.

[0167] Optionally, after confirming that the association information of the current session stored by both parties is the same, the terminal also sends a confirmation message to the acceleration gateway. This confirmation message is used to confirm that the association information of the current session stored by both parties is the same. Accordingly, after receiving the confirmation message, the acceleration gateway stores the association information of the current session obtained in S307 into the context information, and uses the first indication information carried in S203, the length information of the compressed FlowID, the length information of the compressed PacketNumber, and the context information together as compression configuration information for subsequent compression and decompression processing.

[0168] S309. The terminal uses compression configuration information to compress data packets.

[0169] The terminal obtains the compression configuration information through steps S301-S308, and then uses the compression configuration information to compress the data packet. The specific compression operation is described in the relevant description of Embodiment 1, and will not be repeated here.

[0170] S310, the terminal sends the compressed data packet to the acceleration gateway.

[0171] The terminal sends the two compressed data packets obtained from the compression to the acceleration gateway through the first network connection and the second network connection.

[0172] S311, The acceleration gateway decompresses the data according to the compression configuration information.

[0173] The acceleration gateway receives two data packets from two connections and determines whether the data packets are normal or compressed based on the Type field in the DatagramFlowFrame header of the two data packets. When it is determined that the two received data packets are compressed, decompression processing is performed according to the compression configuration information. The specific decompression operation is described in the relevant description of Embodiment 2, and will not be repeated here.

[0174] The acceleration gateway performs deduplication on the two decompressed data packets to obtain the target data packet. Then, it performs normal reception, demodulation, and forwarding processing on the target data packet and forwards it to the business server for processing.

[0175] S312. The terminal periodically sends normal data packets to the acceleration gateway according to the configured sending cycle.

[0176] S313, The acceleration gateway updates the association information of the current session based on normal data packets.

[0177] S314. The acceleration gateway sends a confirmation message for normal data packets to the terminal.

[0178] Optionally, the terminal periodically sends normal data packets to the acceleration gateway according to the configured sending period. For example, the terminal sends a normal data packet after sending N compressed data packets, and updates the association information of the current session by sending normal data packets.

[0179] After sending a normal data packet, the terminal records the association information of the current session corresponding to the normal data packet. Upon receiving the normal data packet, the acceleration gateway retrieves the association information of the current session from the normal data packet and updates the association information of the current session in the uplink information. Then, it sends an acknowledgment message for the normal data packet to the terminal. Optionally, this acknowledgment message includes the updated association information of the current session. Upon receiving this acknowledgment message, the terminal confirms that the association information of the current session recorded by both parties is the same, and then updates the association information of the current session in the context information.

[0180] In this embodiment, uplink data is used as an example for explanation; downlink data is similar. The service server sends a service frame to the acceleration gateway. The acceleration gateway performs QUIC layer processing on the service frame, obtaining two identical data packets. Based on the compression configuration information, the target headers of the two data packets are compressed to obtain compressed data packets corresponding to the two data packets. These compressed data packets are then sent to the terminal via the first and second network connections. After receiving the two compressed data packets, the terminal's accelerator app decompresses them according to the compression configuration information, obtaining two decompressed data packets. These deduplication processes are then performed on the two decompressed data packets to obtain the target data packet, which is then sent to the service application, such as a game app.

[0181] In this embodiment, the terminal and acceleration gateway compress the header of the QUIC data packet, reducing the amount of data in the header, thus reducing the overhead of the data packet header and the traffic resources occupied by sending the QUIC data packet, thereby reducing the traffic cost of the terminal and acceleration gateway sending the QUIC data packet.

[0182] Figure 9 This is a schematic diagram of the data transmission device provided in Embodiment 4 of this application. In this embodiment, the device 100 is applied at the compression end, such as... Figure 9As shown, the device 100 includes: an acquisition module 11, a processing module 12, a compression module 13, and a sending module 14. The acquisition module 11 is used to acquire compression configuration information; the processing module 12 is used to receive service frames sent by the application layer, perform QUIC layer processing on the service frames, and obtain two identical data packets; the compression module 13 is used to compress the target headers of the two data packets according to the compression configuration information, obtaining compressed data packets corresponding to the two data packets, wherein the target header includes at least one of the following headers: a service IP header, a service UDP header, and a QUIC header; the sending module 14 is used to simultaneously send the compressed data packets corresponding to the two data packets to the decompression end through a first network connection and a second network connection, wherein the first network connection and the second network connection are connections established through a multi-channel QUIC protocol located in two different networks.

[0183] In some implementations, the compression configuration information includes at least one of the following: context reference information, first indication information, length information of the compressed flow identifier ID, and length information of the compressed packet sequence number. The context reference information includes association information of at least one existing session, and the association information of the session includes: connection ID, flow ID, source IP address of the service, destination IP address, source port number, and destination port number. The first indication information is used to indicate the deletion of at least one of the following fields in the QUIC header: timestamp field and fragment offset field.

[0184] In some implementations, when the compression configuration information includes the context reference information, the compression module 13 is specifically used to: for each data packet, set the frame type field in the QUIC header to a first value, the first value being used to indicate that the data packet is a compressed data packet; determine, based on the header of the data packet, whether there is association information of the session corresponding to the data packet in the context reference information; when there is association information of the session corresponding to the data packet in the context reference information, delete the source IP address and destination IP address in the service IP header of the data packet, and delete the source port number and destination port number in the service UDP header of the data packet.

[0185] In some implementations, when the compression configuration information also includes the first indication information, the compression module 13 is further configured to: delete at least one of the following fields in the QUIC header of the data packet according to the first indication information: timestamp field and fragment offset field.

[0186] In some implementations, when the compression configuration information also includes the length information of the compressed stream ID and the length information of the compressed data packet sequence number, the compression module 13 is further configured to: set the length of the stream ID in the QUIC header of the data packet to the length information of the compressed stream ID; and set the data packet sequence number in the QUIC header of the data packet to the length information of the compressed data packet sequence number.

[0187] In some implementations, when the compression end is a terminal, the decompression end is an acceleration gateway; or, when the compression end is the acceleration gateway, the decompression end is the terminal.

[0188] In some implementations, when the compression end is a terminal and the decompression end is an acceleration gateway, the acquisition module 11 is specifically used to: send a request message to the acceleration gateway, the request message being used to request the enabling of header compression function; receive a response message returned by the acceleration gateway to the request message, the response message being used to indicate the enabling of header compression function, the response message including the first indication information, the length information of the flow ID and the length information of the data packet sequence number; and obtain the association information of the current session by sending the first normal data packet to the acceleration gateway, the normal data packet being a data packet that has not undergone header compression.

[0189] In some implementations, the acquisition module 11 is further configured to periodically send normal data packets to the acceleration gateway according to a configured sending period in order to update the association information of the current session.

[0190] In some implementations, the acquisition module 11 is specifically used to: simultaneously send two first normal data packets to the acceleration gateway through the first network connection and the second network connection respectively; record the association information of the current session according to the target header of the first normal data packet; receive an acknowledgment message of the first normal data packet sent by the acceleration gateway, the acknowledgment message including the association information of the current session recorded by the acceleration gateway; compare whether the association information of the current session recorded locally by the terminal is the same as the association information of the current session recorded by the acceleration gateway; when the association information of the current session recorded locally by the terminal is the same as the association information of the current session recorded by the acceleration gateway, determine that the association information of the current session stored by both terminals is the same.

[0191] In some implementations, the acquisition module 11 is further configured to: send a first confirmation message to the acceleration gateway in response to the response message, wherein the first confirmation message is used to confirm that the packet header compression function is enabled.

[0192] In some implementations, when the compression end is the acceleration gateway and the decompression end is the terminal, the acquisition module 11 is specifically used to: receive a request message sent by the terminal, the request message being used to request the enabling of the header compression function; determine to enable the header compression function based on capability information and / or load information; send a response message to the terminal regarding the request message, the response message including at least one of the following information: the first indication information, the length information of the compressed stream ID, and the length information of the compressed data packet sequence number; receive the first normal data packet sent by the terminal; record the association information of the current session based on the header of the first normal data packet; and send an acknowledgment message to the terminal regarding the first normal data packet, the acknowledgment message including the association information of the current session recorded by the acceleration gateway.

[0193] In some implementations, the acquisition module 11 is further configured to: receive normal data packets of the current session; and update the association information of the current session according to the target header of the normal data packets.

[0194] The apparatus of this embodiment can be used to execute the method steps performed at the compression end in the above method embodiments. It should be understood that the apparatus embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details are omitted here.

[0195] Figure 10 This is a schematic diagram of the data transmission device provided in Embodiment 5 of this application. The device 200 in this embodiment can be applied to the decompression end, such as... Figure 10 As shown, the device 200 includes: an acquisition module 21, a receiving module 22, a decompression module 23, and a deduplication module 24. The acquisition module 21 is used to acquire compression configuration information; the receiving module 22 is used to receive two data packets sent by the compression end through a first network connection and a second network connection, respectively, wherein the first network connection and the second network connection are connections established through the multi-channel QUIC protocol in two different networks; the decompression module 23 is used to determine that the two data packets are compressed data packets, and to decompress the target headers of the two data packets according to the compression configuration information to obtain decompressed data packets corresponding to the two data packets, wherein the target headers include at least one of the following headers: a service IP header, a service UDP header, and a QUIC header; the deduplication module 24 is used to deduplicatize the decompressed data packets corresponding to the two data packets to obtain target data packets.

[0196] In some implementations, the compression configuration information includes at least one of the following: context reference information, first indication information, length information of the compressed flow identifier ID, and length information of the compressed packet sequence number. The context reference information includes association information of at least one existing session, and the association information of the session includes: connection ID, flow ID, source IP address of the service, destination IP address, source port number, and destination port number. The first indication information is used to indicate the deletion of at least one of the following fields in the QUIC header: timestamp field and fragment offset field.

[0197] In some implementations, when the compression configuration information includes the context reference information, the decompression module 23 is specifically used to: for each data packet, query whether there is association information of the session corresponding to the data packet in the context reference information based on the connection ID and flow ID in the QUIC header of the data packet; when there is association information of the session corresponding to the data packet in the context reference information, add the source IP address and destination IP address to the service IP header of the data packet, and add the source port number and destination port number to the service UDP header of the data packet based on the association information of the session corresponding to the data packet.

[0198] In some implementations, when the compression configuration information also includes the first indication information, the decompression module 23 is further configured to: add at least one of the following fields deleted by the compression end to the QUIC packet header according to the first indication information: timestamp field and slice offset field.

[0199] In some implementations, when the compression configuration information also includes the length information of the compressed stream ID and the length information of the compressed data packet sequence number, the decompression module 23 is further configured to: pad the stream ID in the QUIC header of the data packet to the standard length; and pad the data packet sequence number in the QUIC header of the data packet to the standard length.

[0200] In some implementations, the deduplication module 24 is specifically used to: determine that the decompressed data packets corresponding to the two data packets are the same when the flow ID, message sequence number, and data packet sequence number of the decompressed data packets corresponding to the two data packets are all the same; delete one of the decompressed data packets corresponding to the two data packets, and use the remaining data packet as the target data packet.

[0201] The apparatus of this embodiment can be used to execute the method steps performed at the decompression end in the above method embodiments. It should be understood that the apparatus embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details are omitted here.

[0202] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details will not be provided here.

[0203] The apparatus 100 and apparatus 200 of this application embodiment have been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application embodiment can be completed by integrated logic circuits in the processor hardware and / or by software instructions. The steps of the method disclosed in the embodiments of this application can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0204] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0205] This application also provides a communication device. Figure 11 This is a schematic diagram of a communication device provided in Embodiment Six of this application. The communication device can be a terminal or an acceleration gateway, such as... Figure 11 As shown, the communication device 300 may include:

[0206] The system includes a memory 31 and a processor 32. The memory 31 stores computer programs and transfers the program code to the processor 32. In other words, the processor 32 can retrieve and run the computer program from the memory 31 to implement the method described below:

[0207] When the communication device 300 is a compression end, the following method is implemented: obtaining compression configuration information; receiving service frames sent by the application layer, performing QUIC layer processing on the service frames to obtain two identical data packets; compressing the target headers of the two data packets according to the compression configuration information to obtain compressed data packets corresponding to the two data packets, wherein the target header includes at least one of the following headers: service IP header, service UDP header, and QUIC header; simultaneously sending the compressed data packets corresponding to the two data packets to the decompression end through a first network connection and a second network connection, wherein the first network connection and the second network connection are connections established through a multi-channel QUIC protocol located in two different networks.

[0208] When the communication device 300 is a decompression end, the following method is implemented: obtaining compression configuration information; receiving two data packets sent by the compression end through a first network connection and a second network connection, wherein the first network connection and the second network connection are connections located in two different networks established through the multi-channel QUIC protocol; determining that the two data packets are compressed data packets; decompressing the target headers of the two data packets according to the compression configuration information to obtain decompressed data packets corresponding to the two data packets, wherein the target headers include at least one of the following headers: a service IP header, a service UDP header, and a QUIC header; and deduplicating the decompressed data packets corresponding to the two data packets to obtain target data packets.

[0209] In some embodiments of this application, the processor 32 may include, but is not limited to: a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0210] In some embodiments of this application, the memory 31 includes, but is not limited to, volatile memory and / or non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0211] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 31 and executed by the processor 32 to complete the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the communication device 300.

[0212] like Figure 11 As shown, the communication device 300 may further include a transceiver 33, which can be connected to the processor 32 or the memory 31.

[0213] The processor 42 can control the transceiver 33 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 43 may include a transmitter and a receiver. The transceiver 33 may further include antennas, and the number of antennas may be one or more.

[0214] In some embodiments of this application, the communication device 300 may further include a basic input / output (I / O) system that helps transmit information between various devices within a computer device, and a mass storage device for storing the operating system, applications, and other program modules.

[0215] In some embodiments, the basic input / output system includes a display for displaying information and an input device such as a mouse or keyboard for user input. Both the display and the input device are connected to the processor 32 via an input / output controller connected to a system bus. The basic input / output system may also include an input / output controller for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller also provides output to a display screen, printer, or other types of output devices.

[0216] Understandable, although Figure 11 As not shown in the diagram, the communication device 300 may also include more components, such as a Bluetooth module, a power module, an audio module, etc., which will not be described in detail here.

[0217] It should be understood that the various components in the communication device 300 are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0218] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, embodiments of this application also provide a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0219] This application also provides a computer program product comprising a computer program stored in a computer-readable storage medium. The processor of an electronic device reads the computer program from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the corresponding processes in the above method embodiments; for brevity, these will not be elaborated further here.

[0220] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0221] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0222] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data transmission method, characterized by, The method applied to a compression end comprises: obtaining compression configuration information; receiving a service frame sent by an application layer, performing fast UDP Internet connection layer processing on the service frame to obtain two same data packets; performing compression processing on target packet headers of the two data packets respectively according to the compression configuration information to obtain compression data packets corresponding to the two data packets, wherein the target packet headers comprise at least one of the following packet headers: a service Internet protocol (IP) packet header, a service user data protocol (UDP) packet header and a fast UDP Internet connection packet header; sending the compression data packets corresponding to the two data packets respectively to a decompression end through a first network connection and a second network connection at the same time, wherein the first network connection and the second network connection are connections in two different networks established through a multi-channel fast UDP Internet connection protocol.

2. The method of claim 1, wherein, The compression configuration information comprises at least one of the following information: context reference information, first indication information, length information of a compressed flow identification (ID) and length information of a compressed data packet sequence number, wherein the context reference information comprises associated information of at least one existing session, and the associated information of the session comprises a connection ID, a flow ID, a source IP address, a target IP address, a source port number and a target port number of the service, and the first indication information is used to indicate deletion of at least one of the following fields in the fast UDP Internet connection packet header: a time stamp field and a slice offset field.

3. The method of claim 2, wherein, When the context reference information is included in the compression configuration information, performing compression processing on the target packet headers of the two data packets respectively according to the compression configuration information to obtain the compression data packets corresponding to the two data packets comprises: setting a frame type field in the fast UDP Internet connection packet header to a first value for each data packet, wherein the first value is used to indicate that the data packet is a compression data packet; judging whether associated information of a session corresponding to the data packet exists in the context reference information according to a packet header of the data packet; when the associated information of the session corresponding to the data packet exists in the context reference information, deleting a source IP address and a target IP address in a service IP packet header of the data packet and deleting a source port number and a target port number in a service UDP packet header of the data packet.

4. The method of claim 3, wherein, When the first indication information is further included in the compression configuration information, performing compression processing on the target packet headers of the two data packets respectively according to the compression configuration information further comprises: deleting at least one of the following fields in the fast UDP Internet connection packet header of the data packet according to the first indication information: a time stamp field and a slice offset field.

5. The method of claim 4, wherein, When the length information of the compressed flow ID and the length information of the compressed data packet sequence number are further included in the compression configuration information, performing compression processing on the target packet headers of the two data packets respectively according to the compression configuration information further comprises: setting a length of a flow ID in the fast UDP Internet connection packet header of the data packet to the length information of the compressed flow ID. set a packet sequence number in a quick UDP internet connection header of the data packet as length information of the compressed packet sequence number.

6. The method according to any one of claims 2-5, characterized in that, When the compression end is a terminal and the decompression end is an acceleration gateway, the obtaining of the compression configuration information comprises: sending a request message to the acceleration gateway, the request message being used to request to start a header compression function; receiving a response message of the request message returned by the acceleration gateway, the response message being used to instruct to start the header compression function, and the response message comprising the first indication information, length information of the flow ID, and length information of the packet sequence number; sending a first normal data packet to the acceleration gateway to obtain associated information of a current session, the normal data packet being a data packet that has not undergone header compression.

7. The method of claim 6, wherein, After the sending of the first normal data packet to the acceleration gateway to obtain the associated information of the current session, the method further comprises: periodically sending normal data packets to the acceleration gateway according to a configured sending period to update the associated information of the current session.

8. The method of claim 7, wherein, The sending of the first normal data packet to the acceleration gateway to obtain the associated information of the current session comprises: sending the two first normal data packets to the acceleration gateway through the first network connection and the second network connection respectively at the same time; recording the associated information of the current session according to a target header of the first normal data packet; receiving an acknowledgement message of the first normal data packet sent by the acceleration gateway, the acknowledgement message comprising the associated information of the current session recorded by the acceleration gateway; comparing the associated information of the current session recorded locally with the associated information of the current session recorded by the acceleration gateway; determining that the associated information of the current session recorded by the compression end and the decompression end is the same when the associated information of the current session recorded locally is the same as the associated information of the current session recorded by the acceleration gateway.

9. The method according to any one of claims 2-5, characterized in that, When the compression end is an acceleration gateway and the decompression end is a terminal, the obtaining of the compression configuration information comprises: receiving a request message sent by the terminal, the request message being used to request to start a header compression function; determining to start the header compression function according to capability information and / or load information; sending a response message of the request message to the terminal, the response message comprising at least one of the following information: the first indication information, length information of a compressed flow ID, and length information of a compressed packet sequence number; receiving a first normal data packet sent by the terminal; recording associated information of a current session according to a header of the first normal data packet; sending an acknowledgement message of the first normal data packet to the terminal, the acknowledgement message comprising the associated information of the current session recorded by the acceleration gateway.

10. The method of claim 9, wherein, The method further comprises: receiving normal data packets of the current session; updating the associated information of the current session according to a target header of the normal data packet.

11. A data transmission method, characterized by, The method is applied to a decompression end and comprises: obtaining compression configuration information; The receiving compression end sends two data packets through a first network connection and a second network connection, wherein the first network connection and the second network connection are connections in two different networks established through a multi-channel fast UDP Internet connection protocol; It is determined that the two data packets are compressed data packets, and the target packet header of the two data packets is decompressed according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets, wherein the target packet header includes at least one of the following packet headers: service Internet protocol (IP) packet header, service user data protocol (UDP) packet header, and fast UDP Internet connection packet header; The decompressed data packets corresponding to the two data packets are processed to obtain target data packets.

12. The method of claim 11, wherein, The compression configuration information includes at least one of the following information: context reference information, first indication information, length information of compressed flow identification (ID), and length information of compressed data packet sequence number, wherein the context reference information includes association information of at least one existing session, and the association information of the session includes connection ID, flow ID, source IP address, target IP address, source port number, and target port number, and the first indication information is used to indicate deletion of at least one of the following fields in the fast UDP Internet connection packet header: timestamp field and slice offset field.

13. The method of claim 12, wherein, When the context reference information is included in the compression configuration information, the decompression processing of the target packet header of the two data packets according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets includes: For each data packet, the association information of the session corresponding to the data packet in the context reference information is queried according to the connection ID and the flow ID in the fast UDP Internet connection packet header of the data packet; When the association information of the session corresponding to the data packet exists in the context reference information, the source IP address and the target IP address are added in the service IP packet header of the data packet according to the association information of the session corresponding to the data packet, and the source port number and the target port number are added in the service UDP packet header of the data packet.

14. The method of claim 12, wherein, When the first indication information is further included in the compression configuration information, the decompression processing of the target packet header of the two data packets according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets further includes: According to the first indication information, at least one of the following fields deleted by the compression end in the fast UDP Internet connection packet header is added: timestamp field and slice offset field.

15. The method of claim 12, wherein, When the length information of the compressed flow ID and the length information of the compressed data packet sequence number are further included in the compression configuration information, the decompression processing of the target packet header of the two data packets according to the compression configuration information to obtain the decompressed data packets corresponding to the two data packets includes: The flow ID in the fast UDP Internet connection packet header of the data packet is completed to a standard length; The data packet sequence number in the fast UDP Internet connection packet header of the data packet is completed to a standard length.

16. A data transmission apparatus, characterized by comprising: ​ The acquisition module is configured to acquire compression configuration information. The processing module is configured to receive a service frame sent by an application layer, perform fast UDP Internet connection layer processing on the service frame, and obtain two identical data packets. The compression module is configured to perform compression processing on target packet headers of the two data packets respectively according to the compression configuration information, to obtain compressed data packets corresponding to the two data packets, wherein the target packet headers include at least one of the following packet headers: a service Internet Protocol (IP) packet header, a service User Datagram Protocol (UDP) packet header, and a fast UDP Internet connection packet header. The sending module is configured to send the compressed data packets corresponding to the two data packets to a decompression end through a first network connection and a second network connection respectively at the same time, wherein the first network connection and the second network connection are connections in two different networks established through a multi-channel fast UDP Internet connection protocol.

17. A data transmission apparatus, comprising: The acquisition module is configured to acquire compression configuration information. The receiving module is configured to receive two data packets sent by a compression end through a first network connection and a second network connection respectively, wherein the first network connection and the second network connection are connections in two different networks established through a multi-channel fast UDP Internet connection protocol. The decompression module is configured to determine that the two data packets are compressed data packets, perform decompression processing on target packet headers of the two data packets according to the compression configuration information, and obtain decompressed data packets corresponding to the two data packets, wherein the target packet headers include at least one of the following packet headers: a service Internet Protocol (IP) packet header, a service User Datagram Protocol (UDP) packet header, and a fast UDP Internet connection packet header. The deduplication module is configured to perform deduplication processing on the decompressed data packets corresponding to the two data packets, to obtain target data packets.

18. A communication device, characterized by The apparatus comprises: A processor and a memory, wherein the memory is configured to store a computer program, and the processor is configured to invoke and run the computer program stored in the memory, so as to execute the method in any one of claims 1 to 10 or the method in any one of claims 11 to 15.

19. A computer-readable storage medium, characterized in that, The computer program is configured to enable a computer to execute the method in any one of claims 1 to 10 or the method in any one of claims 11 to 15.

20. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method in any one of claims 1 to 10 or the method in any one of claims 11 to 15.

Images