Data transmission method, system and device, electronic equipment and computer program product

Abstract

The invention discloses a data transmission method, system and device, electronic equipment and a computer program product. The method comprises the steps that hypertext transfer protocol messages transmitted through hypertext transfer protocol tunnels are acquired, and at least one hypertext transfer protocol message transmitted through the same hypertext transfer protocol tunnel belongs to the same hypertext transfer protocol session; the hypertext transfer protocol message at least carries a target address of the message receiving end; according to a hypertext transfer protocol session to which the hypertext transfer protocol message belongs, determining a matched target stream, the target stream being a data channel based on a fast user datagram network connection protocol; converting the hypertext transfer protocol message into a target message based on a fast user datagram network connection protocol; and transmitting the target message to the target address through the target flow. According to the method and the device, the technical problem of lack of session-level mapping and transparent protocol conversion between the HTTP tunnel request and the QUIC flow in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a data transmission method, system, apparatus, electronic device, and computer program product. Background Technology

[0002] Currently, internet application layer protocols primarily rely on HTTP / 1.1 and HTTP / 2, both built on top of the TCP transport layer. HTTP / 1.1 employs a serial request processing mechanism, resulting in high connection establishment overhead and low concurrency efficiency. While HTTP / 2 introduces binary framing and multiplexing technologies to improve concurrency within a single connection, all data streams share the same TCP connection. If a data packet is lost, it triggers head-of-line blocking, forcing other independent streams to wait for retransmission, severely reducing transmission efficiency. Furthermore, both HTTP / 1.1 and HTTP / 2 require a TCP three-way handshake and TLS 1.3 negotiation during connection establishment, accumulating a delay of 1-3 RTTs. This connection establishment time significantly impacts user experience, especially in mobile weak network or frequent handover scenarios. TCP connections are also restricted by the four-tuple binding (source IP, source port, destination IP, destination port). When a terminal switches networks (e.g., between WiFi and 5G), the connection is inevitably interrupted, requiring a re-handshake and reconstruction, causing service interruption and data retransmission.

[0003] To improve transmission performance, the IETF officially released the QUIC protocol (RFC 9000) in 2021. Based on UDP, it implements multiplexing, integrates TLS 1.3 encryption, and supports 0-RTT fast connection recovery and migration. It has been adopted by HTTP / 3 (RFC 9114) as a standard transport layer protocol. Major vendors have already deployed QUIC in production environments, and real-world testing shows it can reduce page load latency by 10% to 30%. However, the widespread application of QUIC faces two major bottlenecks: First, terminal clients or servers need to explicitly integrate the QUIC protocol stack and modify network code, resulting in high deployment costs and making it impossible to directly upgrade a large number of existing applications; Second, although existing proxy systems (such as Squid and Nginx) support the HTTP CONNECT method (RFC 2817) to establish TCP tunnels for transparent forwarding, they only act as byte stream relays and cannot recognize the QUIC message structure, let alone be aware of application layer sessions. Therefore, they cannot achieve semantic-level mapping between HTTP requests and QUIC streams, nor can they reuse QUIC connections, support 0-RTT recovery, or perform stream-level scheduling.

[0004] Furthermore, existing solutions are generally limited to single-path transmission. Although terminals commonly have dual network cards for both WiFi and cellular networks (such as 5G), both standard QUIC and traditional TCP can only select a single path to transmit data, failing to aggregate bandwidth. While MPTCP supports multi-path concurrency, it requires operating system kernel support and is limited by operator policies and device compatibility, making large-scale deployment on mobile devices difficult. Simultaneously, existing proxy systems lack the ability to perceive service flows and cannot implement differentiated QoS scheduling based on request type (such as AI inference, short video uploads, and log reporting). This results in high-priority, low-latency services being squeezed out by high-throughput background traffic, impacting user experience. Moreover, if each HTTP request establishes a separate QUIC connection, handshakes and key negotiations will be repeated, leading to inefficient connection management. Without connection pools and stream multiplexing mechanisms, system concurrency is limited, resulting in low resource utilization.

[0005] In summary, existing technologies face systemic defects in the process of upgrading the HTTP protocol to QUIC, such as "high transformation cost, no session mapping, single path bottleneck, lack of QoS, and inefficient connection reuse".

[0006] There is currently no effective solution to the problem of the lack of session-level mapping and transparent protocol conversion between HTTP tunnel requests and QUIC streams in the existing technologies mentioned above. Summary of the Invention

[0007] This application provides a data transmission method, system, apparatus, electronic device, and computer program product to at least solve the technical problem of lack of session-level mapping and transparent protocol conversion between HTTP tunnel requests and QUIC streams in the prior art.

[0008] According to one aspect of the embodiments of this application, a data transmission method is provided, comprising: acquiring Hypertext Transfer Protocol (HTTP) messages transmitted through a Hypertext Transfer Protocol tunnel, wherein at least one HTTP message transmitted through the same HTTP tunnel belongs to the same HTTP session, and the HTTP message carries at least a target address of a message receiving end; determining a matching target stream based on the HTTP session to which the HTTP message belongs, wherein the target stream is a data channel based on Fast User Datagram Networking Protocol (HUDP); converting the HTTP message into a target message based on HUDP; and transmitting the target message to the target address through the target stream.

[0009] Optionally, determining the matching target flow based on the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs includes: determining the session identifier of the HTTP session to which the HTTP message belongs; querying the target flow identifier corresponding to the session identifier from multiple flow identifiers recorded in a preset mapping table, wherein the preset mapping table is used to record the mapping relationship between the flow identifier and the session identifier, and each flow identifier corresponds to a unique preset flow; selecting the target flow corresponding to the target flow identifier from multiple preset flows recorded in a connection pool, wherein the connection pool is at least used to represent the correspondence between each pre-established preset flow and the flow identifier; and determining the preset flow corresponding to the target flow identifier as the target flow.

[0010] Optionally, the method further includes: if there is no target flow channel identifier corresponding to the session identifier among the multiple flow identifiers recorded in the preset mapping table, creating a transport flow based on the Fast User Datagram Network Connection Protocol for the session identifier; recording the transport flow through the connection pool; creating a unique transport flow identifier for the transport flow; and recording the correspondence between the transport flow identifier and the session identifier through the preset mapping table.

[0011] Optionally, determining the session identifier of the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs includes: identifying the message type of the HTTP message, wherein the message type includes: an HTTP request message and an HTTP response message, the HTTP response message being the response data returned by the message receiver after receiving the HTTP request message; if the message type is an HTTP request message, in response to the HTTP request message, creating the HTTP tunnel, and based on the HTTP request message... The Hypertext Transfer Protocol (HTTP) session to which the HTTP request message belongs assigns the session identifier to the HTTP request message; when the message type is an HTTP response message, the HTTP tunnel for transmitting the HTTP response message is determined, and the session identifier is assigned to the HTTP response message according to the HTTP session to which the HTTP tunnel belongs, wherein the HTTP response message is transmitted through the HTTP tunnel created in response to the HTTP request message.

[0012] Optionally, transmitting the target message to the target address via the target flow includes: splitting the target message into multiple data packets; allocating a corresponding target link for each data packet in the multiple transmission links of the target flow; and transmitting the data packet corresponding to each target link to the target address via the multiple target links respectively.

[0013] Optionally, in the multiple transmission links of the target flow, allocating a corresponding target link for each data packet includes: performing service quality detection on each data packet to obtain the data quality type of each data packet, wherein the data quality type includes at least: a first data packet with low latency priority and a second data packet with high throughput priority; detecting the transmission characteristics of each transmission link in the target flow to obtain the link type of each transmission link, wherein the link type includes: a first link with low latency and a second link with high bandwidth; allocating the first link to the first data packet and the second link to the second data packet.

[0014] Optionally, in the multiple transmission links of the target flow, allocating a corresponding target link for each data packet includes: identifying the data packet type of each data packet, wherein the data packet type includes: a third data packet carrying key information and a fourth data packet with a data volume greater than a preset data volume threshold; copying the third data packet into multiple copies and allocating different transmission links to the multiple copied third data packets; slicing the fourth data packet to obtain multiple data sub-packets of the fourth data packet, and allocating different transmission links to each fourth data sub-packet.

[0015] According to another aspect of the embodiments of this application, a data transmission method is also provided, comprising: acquiring a target packet based on Fast User Datagram Networking Protocol (HUDP) transmitted through a target stream, wherein the target stream is a HUDP data channel, and the target packet carries at least a target address of a packet receiving end; determining a Hypertext Transfer Protocol (HTP) session matching the target stream, wherein the same HTP session uses the same HTP tunnel to transmit at least one HTP packet; converting the target packet into the HTP packet; and transmitting the HTP packet to the target address through the HTP tunnel used by the HTP session.

[0016] According to another aspect of the embodiments of this application, a data transmission system is also provided, comprising: a first proxy server, configured to acquire Hypertext Transfer Protocol (HTTP) messages transmitted to a target address via an HTTP tunnel; determine a target flow matching the HTTP messages based on a first HTTP session to which the HTTP messages belong, and convert the HTTP messages into target messages based on Fast User Datagram Networking Protocol (HUDP); transmit the target messages to a second proxy server via the target flow; the second proxy server, configured to receive the target messages transmitted via the target flow; determine a second HTTP session matching the target flow, and convert the target messages into HTTP messages; transmit the HTTP messages to the target address via the HTTP tunnel used by the second HTTP session; wherein, the same HTTP session uses the same HTTP tunnel to transmit at least one HTTP message, and the target flow is a HUDP data channel.

[0017] According to another aspect of the embodiments of this application, a data transmission apparatus is also provided, comprising: a first acquisition module, configured to acquire Hypertext Transfer Protocol (HTTP) messages transmitted through a Hypertext Transfer Protocol tunnel, wherein at least one HTTP message transmitted through the same HTTP tunnel belongs to the same HTTP session, and the HTTP message carries at least a target address of the message receiving end; a first determination module, configured to determine a matching target stream based on the HTTP session to which the HTTP message belongs, wherein the target stream is a data channel based on Fast User Datagram Networking Protocol (HUDP); a first conversion module, configured to convert the HTTP message into a target message based on HUDP; and a first transmission module, configured to transmit the target message to the target address through the target stream.

[0018] According to another aspect of the embodiments of this application, a data transmission apparatus is also provided, comprising: a second acquisition module, configured to acquire a target packet based on Fast User Datagram Networking Protocol (HUDP) transmitted through a target stream, wherein the target stream is a HUDP data channel, and the target packet carries at least a target address of a packet receiving end; a second determination module, configured to determine a Hypertext Transfer Protocol (HTP) session matching the target stream, wherein the same HTP session uses the same HTP tunnel to transmit at least one HTP packet; a second conversion module, configured to convert the target packet into the HTP packet; and a second transmission module, configured to transmit the HTP packet to the target address through the HTP tunnel used by the HTP session.

[0019] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes the above-described data transmission method when it runs.

[0020] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the above-described data transmission method.

[0021] The embodiments described above in this application acquire Hypertext Transfer Protocol (HTTP) messages transmitted via a Hypertext Transfer Protocol tunnel and establish a session-level mapping relationship between the HTTP message and the Fast User Datagram Network Connectivity (HUDP) target stream based on the HTTP message's session. This enables unified stream channel allocation for multiple messages within the same HTTP session. Furthermore, the original HTTP messages are transparently converted into target messages conforming to the QUIC protocol format and transmitted to the target address via the corresponding target stream. This process fully preserves the continuity and contextual relevance of the session during protocol conversion, effectively avoiding the defects in existing technologies such as connection reuse failure, session interruption, and state loss caused by the lack of session-level mapping between HTTP tunnel requests and QUIC streams. It achieves efficient, stable, and orderly forwarding of HTTP tunnel traffic in the QUIC network, improving the reliability and transmission performance of protocol interoperability, and thus solving the problem of the lack of session-level mapping and transparent protocol conversion between HTTP tunnel requests and QUIC streams in existing technologies. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a data transmission method is shown.

[0024] Figure 2 This is a flowchart of a data transmission method according to an embodiment of this application. Figure 1 ;

[0025] Figure 3 This is a flowchart of a data transmission method according to an embodiment of this application. Figure 2 ;

[0026] Figure 4 This is a schematic diagram of a multi-level collaborative processing system according to an embodiment of this application;

[0027] Figure 5 This is a schematic diagram of a session bridging process according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of a request forwarding process according to an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of a multi-path scheduling process according to an embodiment of this application;

[0030] Figure 8 This is a schematic diagram of a data transmission system according to an embodiment of this application;

[0031] Figure 9 This is a schematic diagram of a data transmission apparatus according to an embodiment of this application. Figure 1 ;

[0032] Figure 10 This is a schematic diagram of a data transmission apparatus according to an embodiment of this application. Figure 2 . Detailed Implementation

[0033] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application 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 this application 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 apparatus 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 apparatus.

[0035] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0036] QUIC: Quick UDP Internet Connections, a UDP-based multiplexed secure transport protocol. QUIC provides applications with flow-controlled multiplexing, low-latency connection establishment, and network path migration capabilities. It integrates TLS 1.3 into the transport layer, achieving faster handshakes and better mobility support than traditional TCP+TLS.

[0037] HTTP Tunnel: Specifically refers to an end-to-end TCP tunnel established using the HTTP CONNECT method. This method is often used to penetrate firewalls or proxy servers, transparently forwarding the underlying TCP stream.

[0038] Session Bridge: A session management mechanism used to establish a bidirectional mapping between HTTP tunnel requests and QUIC protocol streams. This mechanism enables data conversion and session association between the two protocols without modifying the application layer protocol.

[0039] Multipath transmission: The terminal simultaneously utilizes multiple network interfaces such as WiFi and 5G for parallel data transmission to aggregate bandwidth and improve transmission reliability. Similar to the MPTCP protocol, the system can automatically allocate traffic among multiple paths to improve bandwidth utilization and connection redundancy.

[0040] 0-RTT: A fast connection establishment mechanism supported by the QUIC protocol. After completing a full handshake, the client can carry data in the initial handshake message during the next connection attempt, achieving "zero-round latency" data transmission and thus significantly reducing connection establishment latency.

[0041] TCP (Transmission Control Protocol): A connection-oriented, reliable transmission protocol widely used for Internet data transmission to ensure orderly and lossless data delivery, but it is susceptible to head-of-line congestion and connection migration issues.

[0042] UDP (User Datagram Protocol): The foundation of QUIC, it is a connectionless and unreliable transmission protocol, but it supports custom congestion control.

[0043] HTTP / 1.1: Hypertext Transfer Protocol version 1.1, an Internet application layer standard protocol based on TCP, supporting persistent connections and pipelining, but with low efficiency in processing serial requests.

[0044] HTTP / 2: Hypertext Transfer Protocol version 2, introduces features such as binary framing, multiplexing, and header compression, which improves the concurrent performance of HTTP / 1.1, but still relies on a single TCP connection and is susceptible to network fluctuations.

[0045] Head-of-Line Blocking (HoL): In multiplexing protocols, due to the shared transmission channel, when a data packet is lost, all subsequent data packets (even those belonging to different streams) must wait for retransmission, resulting in an increase in overall latency.

[0046] RTT (Round-Trip Time): Round-trip time refers to the time required for a data packet to travel from the sender to the receiver and back, usually measured in milliseconds, and is used to assess network latency.

[0047] IETF (Internet Engineering Task Force): An international standards organization responsible for developing internet protocol standards, such as TCP / IP and QUIC.

[0048] RFC (Request for Comments): A series of Internet protocol standard documents published by the IETF to define protocol specifications, such as RFC 9000 which defines the QUIC protocol.

[0049] TLS 1.3 (Transport Layer Security version 1.3): This is a version 1.3 of the transport layer security protocol. It provides encryption and authentication, supports a faster handshake process, and is often integrated with QUIC to achieve secure end-to-end transport.

[0050] MPTCP (Multipath TCP): Multipath TCP is a TCP extension protocol that supports parallel data transmission across multiple network paths, improving bandwidth utilization and fault tolerance, but deployment requires kernel support.

[0051] QoS (Quality of Service): Service quality refers to the priority management and resource allocation mechanism implemented in the network for different types of traffic to ensure that critical services (such as low-latency applications) are given priority.

[0052] Connection ID: A connection identifier in the QUIC protocol, an encrypted and unique ID used to identify a QUIC connection, supporting connection migration without relying on the IP / port quadruple.

[0053] Stream ID: A stream identifier in the QUIC protocol, used to distinguish independent data streams within the same QUIC connection, supporting multiplexed transmission.

[0054] This application addresses the prominent problems of high protocol upgrade costs, low transmission efficiency, and insufficient resource utilization in existing technologies under mobile network environments. It proposes a transparent HTTP-QUIC conversion and multi-path aggregation acceleration method based on session bridging, aiming to achieve zero-modification, fully transparent, and high-performance network transmission optimization through local gateways or terminal proxies, and comprehensively improve the support capability for latency- and bandwidth-sensitive applications.

[0055] To address the problems existing in related technologies, embodiments of this application provide a data transmission method, which can be run in... Figure 1 The computer terminal shown is explained below.

[0056] The method embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a data transmission method is shown. Figure 1 As shown, the computer terminal 10 (or mobile device 10) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0057] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0058] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the data transmission method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned data transmission method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0059] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0060] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0061] It should be noted here that, in some optional embodiments, the above... Figure 1The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0062] In the above operating environment, this application provides a data transmission method embodiment. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0063] Figure 2 This is a flowchart of a data transmission method according to an embodiment of this application. Figure 1 ,like Figure 2 As shown, the method includes the following steps:

[0064] Step S202: Obtain Hypertext Transfer Protocol (HTTP) messages transmitted through the HTTP tunnel, wherein at least one HTTP message transmitted through the same HTTP tunnel belongs to the same HTTP session, and the HTTP message carries at least the destination address of the message receiver.

[0065] Step S204: Determine the matching target flow based on the Hypertext Transfer Protocol session to which the Hypertext Transfer Protocol message belongs, wherein the target flow is a data channel based on the Fast User Datagram Network Connection Protocol.

[0066] Step S206: Convert the Hypertext Transfer Protocol message into a target message based on the Fast User Datagram Network Connection Protocol;

[0067] Step S208: Transmit the target packet to the target address through the target stream.

[0068] The embodiments described above in this application acquire Hypertext Transfer Protocol (HTTP) messages transmitted via a Hypertext Transfer Protocol tunnel and establish a session-level mapping relationship between the HTTP message and the Fast User Datagram Network Connectivity (HUDP) target stream based on the HTTP message's session. This enables unified stream channel allocation for multiple messages within the same HTTP session. Furthermore, the original HTTP messages are transparently converted into target messages conforming to the QUIC protocol format and transmitted to the target address via the corresponding target stream. This process fully preserves the continuity and contextual relevance of the session during protocol conversion, effectively avoiding the defects in existing technologies such as connection reuse failure, session interruption, and state loss caused by the lack of session-level mapping between HTTP tunnel requests and QUIC streams. It achieves efficient, stable, and orderly forwarding of HTTP tunnel traffic in the QUIC network, improving the reliability and transmission performance of protocol interoperability, and thus solving the problem of the lack of session-level mapping and transparent protocol conversion between HTTP tunnel requests and QUIC streams in existing technologies.

[0069] In step S202 above, the Hypertext Transfer Protocol message (i.e., HTTP message) includes: a Hypertext Transfer Protocol request message (i.e., HTTP request) and a Hypertext Transfer Protocol response message (i.e., HTTP response); wherein, the Hypertext Transfer Protocol request message (i.e., HTTP request) can instruct the creation of a Hypertext Transfer Protocol tunnel (i.e., HTTP tunnel) and continue to transmit message content in the Hypertext Transfer Protocol tunnel; the Hypertext Transfer Protocol response message (i.e., HTTP response) can be a response to the Hypertext Transfer Protocol request message (i.e., HTTP request) and is transmitted through the Hypertext Transfer Protocol tunnel (i.e., HTTP tunnel) established by the Hypertext Transfer Protocol request message (i.e., HTTP request) in response.

[0070] In step S202 above, the Hypertext Transfer Protocol tunnel (i.e., the HTTP tunnel) serves as the underlying transmission channel to carry the upper-layer Hypertext Transfer Protocol communication content; multiple Hypertext Transfer Protocol messages are organized into logically related Hypertext Transfer Protocol sessions (i.e., HTTP sessions) within the tunnel, wherein each Hypertext Transfer Protocol session (i.e., HTTP session) consists of a set of context-related requests or responses, and its boundaries are defined by session identifiers or interaction continuity.

[0071] In step S202 above, the Hypertext Transfer Protocol message carries at least the target address of the message receiver, indicating that each message contains address information used to determine the final delivery of data. This address is a necessary basis for the system to identify the forwarding target, establish a mapping relationship, or perform routing decisions.

[0072] In step S204 above, the target stream (i.e., QUIC stream) is a data channel based on the Fast User Datagram Network Connection Protocol (i.e., QUIC). The mapping relationship between the target stream and the Hypertext Transfer Protocol session (i.e., HTTP session) can be implemented through a session bridge. Using this mapping relationship, the Hypertext Transfer Protocol session (i.e., HTTP session) to which the Hypertext Transfer Protocol message (i.e., HTTP message) belongs can be identified, and the target stream (i.e., QUIC stream) mapped by the Hypertext Transfer Protocol session (i.e., HTTP session) can be further determined. Then, based on this mapping relationship, the identified Hypertext Transfer Protocol message (i.e., HTTP message) can be converted into a target message (i.e., QUIC message) and then transmitted to the target address through the mapped target stream (i.e., QUIC stream).

[0073] In step S206 above, the Hypertext Transfer Protocol (HTTP) message (i.e., an HTTP message) is taken as input. Through protocol parsing and format reconstruction, its content is completely converted into a message structure that conforms to the Fast User Datagram Networking Protocol (HUDP) specification, resulting in the target message (i.e., a QUIC message). This process does not change the semantic content of the original message; it only encapsulates the header and payload of the HTTP message according to the HUDP frame format specification to adapt it to the transport layer structure based on the HUDP, thereby achieving protocol-level message format conversion.

[0074] In the embodiments described above, obtaining Hypertext Transfer Protocol (HTTP) messages transmitted through a HTTP tunnel refers to capturing the original HTTP request and response messages from the HTTP tunnel established between the client and the server. These messages carry session identifiers (such as cookies, session IDs, or connection IDs) to identify that they belong to the same HTTP session, thereby providing a contextual basis for subsequent protocol conversion. Determining the matching target stream based on the session refers to dynamically binding a unique QUIC stream to each HTTP session in the QUIC protocol stack, realizing a one-to-one mapping between HTTP sessions and QUIC streams, and avoiding out-of-order or confusion caused by multiple sessions using the same data channel. Converting HTTP messages into QUIC-based target messages refers to reorganizing the HTTP semantic structure in the traditional TCP / IP stack into a frame format supported by QUIC, such as encapsulating the HTTP / 1.1 request header and body into a STREAM frame, while preserving semantic integrity to ensure that the protocol conversion can still be correctly parsed by the QUIC endpoint.

[0075] As an optional embodiment, determining the matching target flow based on the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs includes: determining the session identifier of the HTTP session to which the HTTP message belongs; querying the target flow identifier corresponding to the session identifier from multiple flow identifiers recorded in a preset mapping table, wherein the preset mapping table is used to record the mapping relationship between flow identifiers and session identifiers, and each flow identifier corresponds to a unique preset flow; selecting the target flow corresponding to the target flow identifier from multiple preset flows recorded in the connection pool, wherein the connection pool is used at least to represent the correspondence between each pre-established preset flow and flow identifier; and determining the preset flow corresponding to the target flow identifier as the target flow.

[0076] The embodiments described above in this application acquire HTTP messages transmitted through an HTTP tunnel and identify the HTTP session to which they belong, thereby determining the unique session identifier of the HTTP session. This aims to normalize the identity of continuous requests from the same client session, avoiding fragmentation of streaming resources caused by multiple independent requests being misjudged as different sessions. Subsequently, a target stream identifier matching the session identifier (such as SessionID) of the session is queried in a preset mapping table. Then, a preset QUIC stream corresponding to the target stream identifier is found through the connection pool. Finally, the found preset stream is determined as the target stream, thus completing the precise binding and reuse from the application layer session to the transport layer stream. This process achieves transparent alignment between the HTTP session lifecycle and the QUIC stream lifecycle, thereby significantly reducing the frequency of QUIC stream establishment and destruction without disrupting the original HTTP tunnel structure. This significantly reduces network overhead such as TLS handshake and connection initialization, improves the throughput and resource utilization of concurrent requests, and solves the problem of the lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in the prior art.

[0077] Optionally, the preset mapping table is a key-value pair structure pre-maintained by the system to persistently record the mapping relationship between "HTTP session - QUIC stream". For example, when a client initiates a request for the first time with SessionID=abc123, the system assigns it a QUIC stream ID=0x01 and registers it in the mapping table. Subsequent requests with the same SessionID reuse this mapping relationship without the need to renegotiate the stream channel.

[0078] Optionally, the connection pool serves as a pool of established QUIC stream resources that are either active or idle. Its function is to cache and reuse candidate streams, avoiding the high-overhead handshake process of creating a new QUIC connection for each HTTP request. For example, when a new message carries SessionID=abc123, the system directly reuses the existing stream ID=0x01 from the connection pool instead of creating a new stream ID=0x02.

[0079] It should be noted that each QUIC flow has an independent flow ID (i.e., flow identifier), encryption context, and congestion control parameters, just like a data pipeline dedicated to forwarding multiple packets for the corresponding session.

[0080] Optionally, each flow identifier is a globally unique and non-repeatable number (e.g., QUIC flow ID=0x0A3F) to ensure that it can be accurately located and distinguished at the network layer.

[0081] As an optional embodiment, the method further includes: when there is no target flow channel identifier corresponding to the session identifier among the multiple flow identifiers recorded in the preset mapping table, creating a transport flow based on the Fast User Datagram Network Connection Protocol for the session identifier; recording the transport flow through a connection pool; creating a unique transport flow identifier for the transport flow; and recording the correspondence between the transport flow identifier and the session identifier through the preset mapping table.

[0082] In the embodiments described above, after session identification of an HTTP message, it is found that the corresponding QUIC transport stream mapping relationship has not yet been established for the HTTP session to which it belongs. At this time, an independent QUIC stream (i.e., transport stream) is dynamically created. This newly created stream is included in the system's resource management pool (such as a connection pool) to facilitate subsequent reuse, monitoring, and lifecycle management, prevent resource leakage, and establish a persistent mapping through a preset mapping table. This allows subsequent messages belonging to the same HTTP session (such as POST and PUT requests under the same Cookie session) to quickly reuse the QUIC stream, avoiding the overhead of repeated connection establishment. This constructs a dynamic channel establishment mechanism from scratch, enabling the protocol conversion system, which originally could only rely on pre-stored mappings, to have the ability to seamlessly, transparently, and with low latency incubate QUIC channels for new HTTP sessions. It realizes end-to-end full lifecycle session-level mapping and protocol adaptation between HTTP tunnel requests and QUIC streams, solving the problem of the lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in the prior art.

[0083] As an optional embodiment, determining the session identifier of the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs includes: identifying the message type of the HTTP message, wherein the message type includes: HTTP request message and HTTP response message, and the HTTP response message is the response data returned by the message receiver after receiving the HTTP request message; when the message type is an HTTP request message, in response to the HTTP request message, an HTTP tunnel is created, and a session identifier is assigned to the HTTP request message according to the HTTP session to which the HTTP tunnel belongs; when the message type is an HTTP response message, an HTTP tunnel for transmitting the HTTP response message is determined, and a session identifier is assigned to the HTTP response message according to the HTTP session to which the HTTP tunnel belongs, wherein the HTTP response message is transmitted through the HTTP tunnel created by the HTTP request message.

[0084] The embodiments described above in this application, by identifying the message type of Hypertext Transfer Protocol (HTTP) messages and distinguishing between request and response messages, ensure that the system can adopt differentiated processing logic for different communication directions: When the message is a request message, the system dynamically creates a corresponding HTTP tunnel as the communication carrier for that session and assigns a unique session identifier to the HTTP session to which the tunnel belongs, thereby establishing an initial anchor point for subsequent QUIC stream mapping; when the message is a response message, the system does not need to create a new tunnel, but instead, by parsing the source address, destination address, and associated request context of the response message, it traces back to its corresponding established HTTP tunnel, and then continues... By using the session identifier of the HTTP session to which the tunnel belongs, the response message and the request message use completely consistent session identifiers, achieving session consistency in bidirectional communication. This mechanism enables the QUIC layer to accurately match the established target QUIC stream based on the session identifier when it receives any protocol message, thereby achieving session-level transparent mapping between the HTTP tunnel and the QUIC stream. This overcomes the technical defects of response messages not being correctly routed due to the lack of session association, resulting in connection errors or data loss. It also solves the problem of the lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in the existing technology.

[0085] For example, a GET request sent by the client is transmitted through tunnel A and assigned session ID=0x123. The 200 OK response returned by the server, although it is downlink traffic, is still transmitted back through tunnel A and reuses ID=0x123 instead of generating a new identifier.

[0086] As an optional embodiment, transmitting a target message to a target address via a target flow includes: splitting the target message into multiple data packets; allocating a corresponding target link for each data packet in multiple transmission links of the target flow; and transmitting the data packet corresponding to each target link to the target address via the multiple target links respectively.

[0087] The embodiments described above in this application, by converting HTTP tunnel-based transmission messages into target messages in QUIC protocol format and further splitting them into multiple data packets, overcome the bandwidth bottleneck of a single transmission path. This allows the HTTP message, originally a whole, to be decomposed into independently schedulable transmission units, adapting to the multi-path concurrent transmission capabilities supported by the QUIC protocol. Assigning a corresponding target link to each data packet across multiple transmission links in the target flow means that the system intelligently and dynamically distributes data packets to different physical or logical network paths based on the real-time bandwidth, latency, and congestion status of each link. Transmitting their respective data packets to the target address through multiple target links achieves true parallel data delivery. Each data packet is independently routed and acknowledged, without waiting for preceding packets to complete, significantly improving transmission throughput and fault tolerance. This allows HTTP-over-TLS tunnel traffic, originally limited by single-link bandwidth, to achieve bandwidth aggregation and transmission acceleration through the multi-path characteristics of the QUIC protocol. Thus, while maintaining session-level semantic consistency, it greatly improves data transmission efficiency and user experience smoothness across network environments, solving the problem of the lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in existing technologies.

[0088] Optionally, the multiple transmission links include at least: a Wi-Fi link, a 4G link, and a wired Ethernet link. By transmitting the data packets corresponding to each target link to the target address separately through multiple target links, a large file request can be split into 10 data packets, which are then sent in parallel through the three links of Wi-Fi, 4G, and wired Ethernet, avoiding overall transmission blockage due to congestion on one link.

[0089] It should be noted that splitting the target message into multiple data packets can dynamically segment large messages based on QUIC's MTU limit and congestion window, forming independently schedulable transmission units, thus providing a basic granularity for multi-link parallel transmission.

[0090] As an optional embodiment, allocating a corresponding target link for each data packet in multiple transmission links of the target flow includes: performing service quality detection on each data packet to obtain the data quality type of each data packet, wherein the data quality type includes at least: a first data packet with low latency priority and a second data packet with high throughput priority; detecting the transmission characteristics of each transmission link in the target flow to obtain the link type of each transmission link, wherein the link type includes: a first link with low latency and a second link with high bandwidth; allocating a first link for the first data packet and an second link for the second data packet.

[0091] The embodiments described above in this application automatically classify data packets into "low latency priority" (such as real-time video frames, WebSocket heartbeat packets) or "high throughput priority" (such as large file chunking, image download) by analyzing the source, content characteristics, or application layer semantics of the data packets. The determination criteria may include the Content-Type in the message header and the request method (such as GET vs. GET). POST) or application layer markers; detect the transmission nature of each transmission link in the target stream to obtain its link type, and perform real-time detection on multiple network paths (such as Wi-Fi, 4G, 5G, wired broadband) multiplexed by the QUIC connection to evaluate the latency fluctuation and bandwidth capacity of each path, and clearly distinguish between "low-latency links" (such as LAN or fiber optic leased lines, with low packet loss rate and stable RTT) and "high-bandwidth links" (such as 5G high-bandwidth channels, with high speed but intermittent jitter); then, according to the intelligent scheduling rule of "low-latency data packets go through low-latency links and high-throughput data packets go through high-bandwidth links", for example, the voice frames in the video conference are forcibly routed to the sub-path with the lowest RTT in 5G, while the high-definition video slices are allocated to the Wi-Fi link with the largest bandwidth to avoid voice stuttering or video buffering. The process of transmitting data packets corresponding to each link to a target address via multiple target links refers to the sequential reassembly of data packets from different paths at the receiving end. This ensures that the final restored message order is correct and there is no packet loss or retransmission, thereby achieving transparent acceleration of multi-path transmission without changing the upper-layer application logic. By dynamically sensing the service characteristics of data packets and the capabilities of the underlying links, and establishing an intelligent distribution mechanism based on attribute matching, it overcomes the degradation of critical service experience caused by "blind load balancing" in traditional QUIC multi-path transmission. It significantly improves the response speed of low-latency services and the transmission efficiency of high-throughput services, achieving accurate adaptation and consistency guarantee of end-to-end service quality. It also solves the problem of the lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in existing technologies.

[0092] As an optional embodiment, in the multiple transmission links of the target stream, allocating a corresponding target link for each data packet includes: identifying the data packet type of each data packet, wherein the data packet type includes: a third data packet carrying key information and a fourth data packet with a data volume greater than a preset data volume threshold; copying the third data packet into multiple copies and allocating different transmission links to the multiple copied third data packets; slicing the fourth data packet to obtain multiple data sub-packets of the fourth data packet, and allocating different transmission links to each fourth data sub-packet.

[0093] In the embodiments described above, identifying the data packet type of each data packet refers to dynamic classification based on message content and transmission characteristics. A "third data packet carrying critical information" refers to metadata packets crucial to connection stability, such as session control instructions, authentication tokens, or retransmission requests, like HTTP / 2 HEADERS frames or TLS handshake messages. A "fourth data packet with a data size exceeding a preset data size threshold" refers to a large payload packet whose single data packet size exceeds the system's fragmentation threshold (e.g., 1KB), such as image or video fragments or file upload blocks. By copying the third data packet into multiple copies and distributing them to different transmission links, redundancy and fault tolerance of critical information are achieved. Even if a link experiences packet loss due to network jitter or congestion, the receiving end can still obtain the complete information through other links, significantly improving the reliability of control signaling. Meanwhile, the fourth data packet is sliced ​​and distributed in parallel, which breaks down a single large packet into multiple smaller data sub-packets and maps them to multiple independent QUIC stream transmission paths. This breaks through the single-stream congestion window limitation and makes full use of the parallel bandwidth of multiple links. For example, a 5MB response body is cut into five 1MB sub-packets and transmitted concurrently through five links, reducing the overall transmission time by nearly 80%. This mechanism retains the original session-level mapping from the HTTP tunnel to the QUIC stream and realizes intelligent scheduling based on semantic importance and data size. This prevents critical control information from failing at a single point and maximizes the parallel efficiency of large-scale loads. It significantly enhances the transmission robustness and resource utilization of the system in complex network environments and solves the problem of the lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in existing technologies.

[0094] Figure 3 This is a flowchart of a data transmission method according to an embodiment of this application. Figure 2 ,like Figure 3 As shown, the method includes the following steps:

[0095] Step S302: Obtain the target message based on Fast User Datagram Networking Protocol (HUDP) transmitted through the target stream, wherein the target stream is a data channel based on HUDP, and the target message carries at least the target address of the message receiver.

[0096] Step S304: Determine the Hypertext Transfer Protocol session that matches the target stream, wherein the same Hypertext Transfer Protocol session uses the same Hypertext Transfer Protocol tunnel to transmit at least one Hypertext Transfer Protocol message.

[0097] Step S306: Convert the target message into a Hypertext Transfer Protocol message;

[0098] Step S308: Transmit a Hypertext Transfer Protocol (HTTP) message to the target address through the HTTP tunnel used by the HTTP session.

[0099] The embodiments described above in this application achieve precise alignment between the response data transmitted via the QUIC protocol and the HTTP session initiated by the client at the protocol stack level by receiving the target message transmitted by the target stream based on the QUIC protocol, identifying the target address carried by the message, and restoring it to the original HTTP message based on the mapping relationship between the QUIC stream to which the message belongs and the previously established HTTP session. The response data is then returned to the requester via the corresponding HTTP tunnel. This allows the QUIC response returned by the backend server to be transparently returned via the original HTTP tunnel without modifying the existing HTTP implementations of the client and server, ensuring bidirectional consistency of the protocol conversion process and improving the integrity and reliability of cross-protocol communication. It is particularly suitable for scenarios where a local proxy intercepts and converts QUIC communication, effectively supporting bidirectional data mapping and session continuation between the HTTP tunnel and the QUIC stream, and solving the problem of lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in the prior art.

[0100] Figure 4 This is a schematic diagram of a multi-level collaborative processing system according to an embodiment of this application, such as... Figure 4 As shown, to implement the above data transmission method, this application innovatively constructs a multi-level collaborative processing system in the local gateway or client device, including: an HTTP tunnel parsing layer, a session bridging layer, a QUIC stream management layer, and a multi-path aggregation layer. This system, through layered decoupling and functional linkage, forms a full-link processing capability covering data access, session management, transmission optimization, and quality assurance.

[0101] Optionally, the HTTP tunnel parsing layer serves as the entry point for system data, responsible for handling HTTP traffic sent by the terminal. It intercepts and parses HTTP connection requests from the terminal, identifying HTTP CONNECT tunnel requests or ordinary HTTP requests (such as resource requests using GET / POST methods), and extracting key information such as the target server's domain name / IP address, port, and resource path.

[0102] Optionally, the session bridging layer, acting as the core hub for protocol conversion and session association, establishes a session identifier for each parsed HTTP request and maintains the mapping relationship between the HTTP tunnel and the corresponding QUIC stream in real time through a built-in mapping table. The main process is as follows: When HTTP request data is received from the upper layer, the existing mapping table is first searched using the session identifier. If a corresponding QUIC stream already exists, it is directly reused for data forwarding; if no match is found, the QUIC stream management layer is triggered to create a QUIC stream, and the new stream is bound to the session identifier of the current HTTP request and stored in the mapping table. This layer is responsible for finding or creating a QUIC stream based on the request, completing bidirectional data forwarding, and ensuring that protocol conversion is transparent to upper-layer applications.

[0103] Optionally, the QUIC stream management layer, as the core layer carrying the underlying transmission capabilities, uses the QUIC protocol stack implementation library. This layer is responsible for establishing QUIC connections with the backend server and managing the streams based on the target server information transmitted by the session bridging layer. It supports TLS encryption and reliable transmission, achieving end-to-end encryption of data between the transport layer and the application layer. Simultaneously, leveraging QUIC's 0-RTT characteristic, in scenarios where the client and server have already established a connection (with cached session tickets), there is no need to repeat the complete handshake process; connection reuse and data transmission can be completed in just one RTT, significantly reducing connection establishment latency, especially suitable for weak network or frequent reconnection scenarios. This layer dynamically creates or reuses QUIC streams according to the needs of session bridging, thereby optimizing resource utilization and bridging response speed.

[0104] Optionally, a multi-path aggregation layer: As a core enhancement layer that breaks through the single-path transmission limitations of standard QUIC, this layer focuses on the coordinated scheduling and bandwidth aggregation of multiple network interfaces. Through real-time sensing and dynamic management of locally available network interfaces (such as WiFi and 5G), it dynamically schedules QUIC stream data packets to different physical paths based on the bandwidth and latency of each path. At the intelligent scheduling level, this layer employs a path quality-based load balancing algorithm, combining the service attributes of the QUIC stream (priority, real-time requirements) with path quality data to achieve cross-path data distribution and aggregation of QUIC data packets.

[0105] The embodiments described above in this application achieve protocol upgrades with zero modification cost. Without requiring any code or configuration changes on either the client application (App) or the server (HTTP server), a seamless and transparent transition from traditional HTTP / 1.1 / HTTP / 2 (based on TCP) to QUIC (based on UDP) is realized. The system intercepts standard HTTP requests (including CONNECT tunnels and ordinary GET / POST requests) through a local proxy, completing protocol encapsulation and forwarding locally, completely eliminating the dependency on dual-end upgrades, and is suitable for the smooth evolution of existing systems.

[0106] The embodiments described above in this application provide an efficient and intelligent session bridging mechanism. By constructing a lightweight session management hub, a globally unique identifier (Session ID) is assigned to each HTTP session, and a dynamic bidirectional mapping relationship is established between this identifier and the stream identifier (Stream ID) in the QUIC connection. It supports session state persistence, connection reuse, and exception recovery, ensuring that the protocol conversion layer and transport layer work together to achieve the ideal state of "application-unaware and fully optimized transmission."

[0107] The embodiments described above employ a multi-NIC, multi-path parallel aggregation transmission mechanism, fully utilizing the WiFi + 5G / 4G dual NIC resources (and even future WiFi 6E + Satellite) commonly found in smart terminals. This overcomes the single-path limitation of standard QUIC, enabling cross-interface parallel distribution and bandwidth aggregation at the data packet level. Through real-time path quality detection and intelligent scheduling algorithms, traffic is dynamically allocated to the optimal link or multiple links concurrently, increasing total throughput by 1.5 to 2.5 times while enhancing connection redundancy.

[0108] The embodiments described above in this application achieve fine-grained QoS assurance based on business awareness, enabling differentiated service strategies for QUIC streams according to application type, data characteristics, and user priority. For example, low latency priority (such as mobile AI inference and voice commands) → prioritizes low-latency paths and high-priority queues; high throughput priority (such as short video uploads and cloud synchronization) → prioritizes high-bandwidth paths and batch distribution; background traffic (such as log reporting) → low priority, yielding to traffic during congestion, thereby ensuring that critical business experiences are not compromised by non-critical traffic.

[0109] The embodiments described above in this application optimize connection management under high concurrency by introducing a three-layer optimization mechanism: a QUIC connection pool, stream reuse, and 0-RTT fast recovery. The connection pool caches completed QUIC connections for reuse in subsequent requests, avoiding repeated TLS / QUIC negotiation. Stream reuse allows multiple HTTP sessions to be carried using the same QUIC connection, reducing the number of connections and increasing concurrency density. 0-RTT recovery enables rapid data transmission recovery using the QUIC encryption context after a session interruption, achieving near-zero interruption. This comprehensively reduces connection establishment latency by over 60% and supports tens of thousands of concurrent sessions. 0-RTT is actually initiated by the proxy as a QUIC client, which caches the session ticket with the target server. When a new HTTP request arrives for the same target, the proxy reuses the existing QUIC connection.

[0110] The above embodiments of this application achieve enhanced mobility and seamless network switching. By utilizing QUIC's native Connection ID mechanism and path migration capability, combined with the multi-NIC management of this invention, QUIC connection continuity is maintained when the terminal switches from WiFi to 5G without the need for re-handshake or interruption of transmission. This is particularly suitable for frequent switching scenarios such as subways, elevators, and high-speed trains.

[0111] Figure 5 This is a schematic diagram of a session bridging process according to an embodiment of this application, such as... Figure 5 As shown, the steps are as follows:

[0112] Step S501: Initiate an HTTP request;

[0113] Step S502, HTTP tunnel request;

[0114] Step S503: Create an HTT tunnel;

[0115] Step S504: Determine if a QUIC CONNECTION exists; if it exists, reuse the QUIC CONNECTION; otherwise, initiate a QUIC CONNECTION handshake and create a mapped QUIC STREAM.

[0116] Step S505: Request the HTTP server.

[0117] Step S506: Determine whether the HTTP server is successful; if successful, return a Connection Established (200) response message and continue forwarding data; otherwise, return a Bad Request (400) error response.

[0118] Figure 6 This is a schematic diagram of a request forwarding process according to an embodiment of this application, such as... Figure 6 As shown, proxy servers (such as a first proxy server and a second proxy server) are set up on the client (such as an APP) and the server (such as an HTTP server), respectively. Data transmission between the two proxy servers is carried out through QUIC streams. Each proxy server includes: a QUIC stream management layer, a session bridging layer, and an HTTP proxy layer (such as an HTTP tunnel parsing layer and an HTTP tunnel proxy layer), specifically including:

[0119] Step S601: Set up a local proxy for the APP.

[0120] Step S602: Send an HTTP CONNECT to the HTTP tunnel parsing layer of the first proxy server.

[0121] Step S603: Establish a tunnel mapping QUIC session to the session bridging layer.

[0122] Step S604: Send a QUIC stream establishment request to the QUIC stream management layer.

[0123] In step S605, the QUIC flow management layer of the first proxy server initiates a QUIC handshake with the QUIC flow management layer of the second proxy server and transmits 0-RTT data.

[0124] In step S606, the second proxy server extracts the HTTP CONNECT through the QUIC flow management layer and sends it to the session bridge layer.

[0125] Step S607: Initiate tunnel establishment to the HTTP tunnel proxy layer.

[0126] Step S608: The second proxy server establishes a TCP connection with the HTTP server.

[0127] In step S609, the HTTP server returns a message indicating a successful TCP connection to the HTTP tunnel proxy layer of the second proxy server.

[0128] In step S610, the HTTP tunneling proxy layer returns a Connection Established (200) response message to the session bridge layer.

[0129] Step S611: Encapsulate the response message into QUIC stream data.

[0130] In step S612, the second proxy server transmits data to the first proxy server's QUIC stream management layer via QUIC stream through the QUIC stream management layer.

[0131] In step S613, the first proxy server receives QUIC stream data through the QUIC stream management layer.

[0132] In step S614, the session bridge layer maps the HTTP message representing the successful response message based on the QUIC stream data.

[0133] In step S615, the first proxy server returns ConnectionEstablished(200) to the client APP through the HTTP tunnel parsing layer.

[0134] In step S616, the client APP begins forwarding data to the HTTP tunnel parsing layer of the first proxy server;

[0135] In step S617, the HTTP tunnel parsing layer forwards data to the session bridge layer using a "blind relay" method, and finds the QUIC stream through mapping.

[0136] Step S618: Encapsulate the data into QUIC stream data and provide it to the QUIC stream management layer.

[0137] In step S619, the first proxy server transmits data to the second proxy server's QUIC stream management layer via QUIC stream through the QUIC stream management layer.

[0138] In step S620, the second proxy server extracts data through the QUIC flow management layer and finds the corresponding tunnel through the session bridging layer.

[0139] Step S621: The session bridging layer forwards data to the target to the HTTP tunneling proxy layer.

[0140] In step S622, the second proxy server forwards data to the HTTP server through the HTTP tunnel proxy layer.

[0141] In step S623, the second proxy server receives the returned data from the HTTP server through the HTTP tunnel proxy layer.

[0142] In step S624, the HTTP tunnel proxy layer forwards data through the session bridge layer and finds the QUIC stream through mapping.

[0143] In step S625, the session bridge layer encapsulates the data into QUIC stream data and forwards it to the QUIC stream management layer.

[0144] In step S626, the QUIC stream management layer of the second proxy server transmits data to the QUIC stream management layer of the first proxy server via a QUIC stream.

[0145] In step S627, the first proxy server extracts data through the QUIC flow management layer and finds the corresponding tunnel through the session bridging layer.

[0146] Step S628: The session bridging layer forwards data to the target tunnel to the HTTP tunnel contact layer.

[0147] In step S628, the first proxy server forwards data to the client APP through the HTTP tunnel parsing layer.

[0148] Figure 7 This is a schematic diagram of a multi-path scheduling process according to an embodiment of this application, such as... Figure 7As shown, an HTTP request is initiated at the application layer; at the QUIC scheduling layer, the path manager selects the transmission link based on the path ID, RTT / packet loss rate, bandwidth estimation, and link status (active); at the UDP layer, the communication endpoint used to send and receive datagrams based on the UDP protocol is determined; at the physical layer, different transmission links are used for transmission based on the selected communication endpoint, such as Ethernet transmission via a WIFI network card, or cellular network (such as 4G or 5G) transmission via a cellular network card.

[0149] As an optional example, a lightweight acceleration proxy is deployed on a local Android phone device. The complete processing chain is as follows:

[0150] 1. HTTP request interception and parsing, specifically including:

[0151] The proxy listens to the local loopback interface (127.0.0.1), captures all outbound HTTP traffic, distinguishes between CONNECT tunnel requests and ordinary HTTP requests, and extracts key fields such as target host, port, and path.

[0152] 2. Session bridging and mapping establishment, specifically including:

[0153] Generate a Session ID for each request and consult the local mapping table:

[0154] If it already exists, reuse the corresponding QUIC stream;

[0155] If it does not exist, obtain a new QUIC connection from the connection pool or create a new one, open a new stream, and write it to the mapping table.

[0156] Generate HTTP Session ID Two-way binding of QUIC Stream ID.

[0157] 3. Data encapsulation and QUIC stream transmission, specifically including:

[0158] The HTTP message (header + body) is encapsulated into a QUIC STREAM frame and processed by the QUIC flow management layer, which automatically performs encryption, reliable transmission, congestion control, and flow control.

[0159] 4. Multi-path quality assessment and intelligent scheduling, specifically including:

[0160] Real-time detection of RTT, bandwidth, packet loss rate, and signal strength for each network interface card (NIC), combined with QoS priorities, enables packet-level distribution.

[0161] High priority flow → low latency path;

[0162] Large data blocks → multi-path parallel (fragmented transmission);

[0163] Redundant backup → Dual transmission of critical packages.

[0164] 5. Server-side reception and response feedback, specifically including:

[0165] The server receives a QUIC message, decapsulates it, restores it to a standard HTTP request, processes it normally, and returns a response.

[0166] The response is sent back along the original path (or optimized path), restored to an HTTP response via reverse bridging, and delivered to the original App.

[0167] 6. Session closure and resource reclamation, specifically including:

[0168] After the HTTP response is completed, the Session ID is released; the QUIC stream is closed but the connection is retained in the pool, waiting for the next reuse.

[0169] The embodiments described above in this application, through local transparent proxy + HTTP tunnel parsing, achieve zero code modification, allowing existing apps and traditional HTTP servers to enjoy QUIC acceleration without upgrades, solving the problem of high costs for dual-end transformation; through Session Bridge + bidirectional mapping table, session continuity can reach 100%, connection reuse is supported, and handshake counts are reduced by 70%, solving the problem of no session-level protocol bridging; through multi-path aggregation layer + packet-level distribution, throughput is increased by 1.5~2.5 times, solving the problem of single-path bandwidth bottleneck; through flow classification + priority scheduling + cross-path collaboration, low-latency service latency is reduced by 25%, ensuring that critical traffic is not crowded out, solving the technical problem of lack of QoS control; through connection pool + 0-RTT + flow multiplexing, the average connection establishment latency is reduced to <50ms, and concurrency capability is increased by 2~3 times, solving the problem of low connection establishment efficiency; through QUIC connection migration + multi-NIC collaboration, the handover success rate is >99.5%, and transmission is interrupted without awareness, solving the problem of network handover interruption; through HTTP The tunnel protocol enables platform-independent tunnel interception, allowing the same C++ code to run across all platforms with zero deployment adaptation, achieving "write once, accelerate everywhere," and solving cross-platform compatibility and deployment consistency issues.

[0170] As an optional embodiment, one possible implementation process for the above data transmission method includes:

[0171] Step S1: Receive and deeply parse HTTP requests: The local device's client HTTP tunnel parsing layer continuously listens for HTTP connection requests from the terminal APP, performs detailed parsing of HTTP messages, not only distinguishes between CONNECT tunnel requests and ordinary HTTP requests, but also extracts key information such as the target address and method of the request, providing accurate initial data for subsequent processes. This process corresponds to the stage from the client initiating an HTTP request to the creation of the HTTP tunnel through the HTTP tunnel request.

[0172] Step S2, Session Bridging and QUIC Stream Mapping Establishment: Based on the parsing result and target address of the HTTP request, the session bridging layer assigns a unique session ID to the request. Then, it checks the internal mapping table to see if a corresponding QUIC stream exists. If it does, the QUIC stream is reused directly; if it does not exist, a QUIC STREAM handshake process is immediately initiated to create a new QUIC stream, and the mapping table is used to establish a correspondence between the session ID and the QUIC stream, achieving a tight binding between the session and the QUIC stream. This step covers the QUIC stream reuse judgment and handshake initiation logic.

[0173] Step S3, Real-time Multi-path Detection and Intelligent Aggregation: The client's multi-path aggregation layer monitors the status of multiple network interfaces such as WiFi and cellular networks in real time, including core indicators such as bandwidth, latency, and packet loss rate. Based on these indicators, it intelligently decides the optimal transmission path or adopts a traffic splitting strategy to dynamically schedule subsequent data packets of the session to one or more network paths (such as WiFi and cellular networks), thus building an efficient underlying path environment for QUIC transmission.

[0174] Step S4, QUIC Data Transmission and Dynamic QoS Assurance: When QUIC data is transmitted to the server through the QUIC stream, the QUIC protocol automatically performs operations such as data encryption, reliable transmission, and congestion control. At the same time, the session bridging layer, in conjunction with the flow priority, works with the QUIC flow management layer to dynamically adjust the data packet sending rate on each transmission path, thereby achieving fine-grained control of Quality of Service (QoS) and ensuring a smooth transmission experience for traffic of different priorities.

[0175] Step S5, Server-side request processing and response: The server-side HTTP tunnel parsing layer receives the request data transmitted via QUIC, parses it, and initiates a request to the target HTTP server; if the request is successful, it returns a ConnectionEstablished (200) response message; if the request fails, it returns a Bad Request (400) error response, completing the server-side request processing logic.

[0176] Step S6, Response Data Return and Request Closure: The server returns response data to the client via QUIC connection. After the client's QUIC stream management layer receives the data, the session bridging layer finds the corresponding original HTTP session based on the mapping relationship, and then the HTTP tunnel parsing layer parses the response message. Finally, the response is accurately forwarded back to the terminal APP that initiated the request, thus fully realizing the closed loop of the entire process from request initiation to response return.

[0177] As an optional example, in a scenario of accelerating AI inference requests on mobile devices, the user terminal initiates multiple concurrent HTTP requests for AI inference (object recognition) through a browser. Each request carries JPEG images of different resolutions and qualities (file sizes of 400KB, 700KB, 1400KB, and 4000KB, respectively). The system connects these requests to a local HTTP tunnel, converts them into QUIC streams, and transmits them concurrently to the backend inference server via WiFi and 5G.

[0178] Table 1 is a schematic diagram of a comparative experiment according to an embodiment of this application. As shown in Table 1, a comparative experiment can be designed: one group uses the traditional HTTP method (without acceleration), and the other group uses the solution of this invention. The solution of this invention is further subdivided into a lightweight transmission group (corresponding to a 400KB low-resolution image), a standard transmission group (corresponding to a 700KB medium-resolution image), a premium transmission group (corresponding to a 1400KB high-resolution image), and an extreme transmission group (corresponding to a 4000KB ultra-high-resolution image) to evaluate the performance differences under different transmission loads. The test indicators include average response latency, median latency, and 95th percentile latency. This experiment only measures the network latency of the request return (excluding end-side preprocessing and back-end inference calculation latency) to focus on the transmission acceleration effect.

[0179] Table 1

[0180]

[0181] Each method in this test was repeated 100 times in a real Android phone environment. Although there may be network fluctuations in the real environment, the data shows that the average response latency of the present invention is reduced by more than 60% under different groups, and the 95th percentile latency is reduced by 40% to 50%, demonstrating good robustness.

[0182] The embodiments described above in this application innovatively introduce a bidirectional mapping mechanism into the HTTP and QUIC protocol conversion scenario by utilizing a session bridging mechanism. By constructing a dynamic binding relationship between HTTP tunnel requests and QUIC streams, automatic association and full lifecycle management of session IDs are achieved. Specifically, the system generates a unique session identifier for each HTTP tunnel request and records the correspondence between this identifier and the backend QUIC stream in real time through a built-in mapping table. When an HTTP request enters the processing chain, a matching QUIC stream is automatically retrieved or created; when the QUIC stream returns response data, it is reverse-mapped back to the original HTTP session, ensuring cross-protocol session state consistency.

[0183] The embodiments described above in this application innovatively introduce a unified parsing mechanism into cross-protocol transmission scenarios based on transparent protocol conversion. By constructing a standardized HTTP request parsing engine, it performs one-stop processing of HTTP CONNECT tunnels and ordinary HTTP request data, uniformly encapsulating the key data of both types of requests into a data stream format conforming to the QUIC protocol specification. The core advantage of this method is that it makes the protocol conversion completely transparent to both the terminal and the server. Client applications do not need to modify code or configuration, and the server does not need to support QUIC or any special protocol to enjoy QUIC and multi-path acceleration capabilities. This achieves a QUIC protocol upgrade solution for existing services with "zero code modification, zero deployment cost, and zero business interruption."

[0184] The embodiments described above in this application are based on multi-path aggregation transmission. A local multi-NIC dynamic perception and intelligent scheduling algorithm is designed. The idea of ​​multi-path parallel transmission is introduced into the terminal-side QUIC transmission architecture. By adapting to the characteristics of multiple network interfaces (WiFi, 5G, etc.) of terminal devices, data packets are allocated to different paths at the network interface level to improve the overall throughput through bandwidth aggregation.

[0185] The embodiments described above in this application, based on connection pooling and reuse mechanisms, design a QUIC connection pooling management mechanism. By maintaining a QUIC connection pool, when a request arrives, it follows an efficient strategy of "reuse priority, on-demand creation," prioritizing the search and reuse of established available QUIC connections. If no matching connection is found, a new connection is quickly created, thereby achieving connection reuse among multiple requests. This mechanism reduces the overhead of repeated handshakes and improves the system's concurrent processing efficiency.

[0186] This application implements an HTTP protocol upgrade scheme that requires no client-side modifications and is compatible with existing network environments. Utilizing multi-NIC multi-path transmission, it significantly improves data transmission rates; for example, tests in short video / file upload scenarios show an upload speed increase of approximately 22.6%. Session bridging technology enables seamless conversion between different protocols, simplifying the protocol upgrade process. Combined with QoS control and connection multiplexing, it theoretically doubles bandwidth and significantly reduces latency, providing solid support for high-performance transmission in mobile network environments.

[0187] Figure 8 This is a schematic diagram of a data transmission system according to an embodiment of this application, such as... Figure 8 As shown, it includes: a first proxy server 82, used to acquire Hypertext Transfer Protocol (HTTP) messages transmitted to a target address via an HTTP tunnel; determine the target flow matching the HTTP messages based on the first HTTP session to which the HTTP messages belong, and convert the HTTP messages into target messages based on Fast User Datagram Networking Protocol (HUDP); transmit the target messages to a second proxy server via the target flow; a second proxy server 84, used to receive the target messages transmitted via the target flow; determine the second HTTP session matching the target flow, and convert the target messages into HTTP messages; transmit the HTTP messages to the target address via the HTTP tunnel used by the second HTTP session; wherein, the same HTTP session uses the same HTTP tunnel to transmit at least one HTTP message, and the target flow is a HUDP data channel.

[0188] The embodiments described above in this application, through a collaborative architecture of a first proxy server and a second proxy server, achieve end-to-end transparent conversion and bidirectional session association for HTTP tunnel requests. Upon receiving an HTTP message, the first proxy server accurately locates the corresponding QUIC stream based on its session and completes protocol encapsulation. The second proxy server, based on the same session identifier, restores the QUIC message to a standard HTTP request and forwards it to the target server. This mechanism ensures the integrity and consistency of the HTTP session during protocol conversion, avoiding transmission interruptions caused by session disconnection or stream mapping misalignment. It also supports end-to-end collaboration of connection reuse and multipath transmission, improving session continuity and transmission reliability in complex network environments. It is suitable for accelerating existing HTTP services without client modifications and solves the problem of lacking session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in existing technologies.

[0189] Figure 9 This is a schematic diagram of a data transmission apparatus according to an embodiment of this application. Figure 1 ,like Figure 9As shown, the system includes: a first acquisition module 92, configured to acquire Hypertext Transfer Protocol (HTTP) messages transmitted through a Hypertext Transfer Protocol tunnel, wherein at least one HTTP message transmitted through the same HTTP tunnel belongs to the same HTTP session, and the HTTP message carries at least the target address of the message receiver; a first determination module 94, configured to determine a matching target stream based on the HTTP session to which the HTTP message belongs, wherein the target stream is a data channel based on Fast User Datagram Networking Protocol (HUDP); a first conversion module 96, configured to convert the HTTP message into a target message based on HUDP; and a first transmission module 98, configured to transmit the target message to the target address through the target stream.

[0190] The embodiments described above in this application acquire Hypertext Transfer Protocol (HTTP) messages transmitted via a Hypertext Transfer Protocol tunnel and establish a session-level mapping relationship between the HTTP message and the Fast User Datagram Network Connectivity (HUDP) target stream based on the HTTP message's session. This enables unified stream channel allocation for multiple messages within the same HTTP session. Furthermore, the original HTTP messages are transparently converted into target messages conforming to the QUIC protocol format and transmitted to the target address via the corresponding target stream. This process fully preserves the continuity and contextual relevance of the session during protocol conversion, effectively avoiding the defects in existing technologies such as connection reuse failure, session interruption, and state loss caused by the lack of session-level mapping between HTTP tunnel requests and QUIC streams. It achieves efficient, stable, and orderly forwarding of HTTP tunnel traffic in the QUIC network, improving the reliability and transmission performance of protocol interoperability, and thus solving the problem of the lack of session-level mapping and transparent protocol conversion between HTTP tunnel requests and QUIC streams in existing technologies.

[0191] It should be noted that the data transmission device can be used to execute the data transmission method in the embodiments of the present invention. Therefore, the relevant explanations and descriptions in the above data transmission method also apply to the data transmission device, and will not be repeated here.

[0192] It should be noted that each module in the above-mentioned data transmission device can be a program module (for example, a set of program instructions that implement a certain function) or a hardware module. For the latter, it can be manifested in the following forms, but is not limited to them: each of the above modules is manifested as a processor, or the functions of each of the above modules are implemented by a processor.

[0193] As an optional embodiment, the first determining module includes: a first determining unit, used to determine the session identifier of the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs; a querying unit, used to query a target flow identifier corresponding to the session identifier from multiple flow identifiers recorded in a preset mapping table, wherein the preset mapping table is used to record the mapping relationship between flow identifiers and session identifiers, and each flow identifier corresponds to a unique preset flow; a selecting unit, used to select a target flow corresponding to the target flow identifier from multiple preset flows recorded in a connection pool, wherein the connection pool is used to at least represent the correspondence between each pre-established preset flow and flow identifier; and a second determining unit, used to determine the preset flow corresponding to the target flow identifier as the target flow.

[0194] As an optional embodiment, the apparatus further includes: a first creation unit, configured to create a transport stream based on the Fast User Datagram Network Connection Protocol for a session identifier when there is no target flow channel identifier corresponding to the session identifier among multiple flow identifiers recorded in a preset mapping table; a recording unit, configured to record the transport stream through a connection pool; a second creation unit, configured to create a unique transport stream identifier for the transport stream; and a recording unit, configured to record the correspondence between the transport stream identifier and the session identifier through a preset mapping table.

[0195] As an optional embodiment, the first determining unit includes: a first identifying subunit, configured to identify the message type of the Hypertext Transfer Protocol (HTTP) message, wherein the message type includes: an HTTP request message and an HTTP response message, the HTTP response message being the response data returned by the message receiver after receiving the HTTP request message; a first allocating subunit, configured to, in the case of an HTTP request message, create an HTTP tunnel in response to the HTTP request message, and allocate a session identifier to the HTTP request message according to the HTTP session to which the HTTP tunnel belongs; and a second allocating subunit, configured to, in the case of an HTTP response message, determine the HTTP tunnel for transmitting the HTTP response message, and allocate a session identifier to the HTTP response message according to the HTTP session to which the HTTP tunnel belongs, wherein the HTTP response message is transmitted through the HTTP tunnel created by the HTTP request message.

[0196] As an optional embodiment, the first transmission module includes: a splitting unit for splitting a target message into multiple data packets; an allocation unit for allocating a corresponding target link for each data packet among multiple transmission links of the target flow; and a transmission unit for transmitting the data packet corresponding to each target link to the target address through the multiple target links respectively.

[0197] As an optional embodiment, the allocation unit includes: a first detection subunit, used to detect the quality of service for each data packet and obtain the data quality type of each data packet, wherein the data quality type includes at least: a first data packet with low latency priority and a second data packet with high throughput priority; a first detection subunit, used to detect the transmission characteristics of each transmission link in the target flow and obtain the link type of each transmission link, wherein the link type includes: a first link with low latency and a second link with high bandwidth; and a third allocation subunit, used to allocate a first link for the first data packet and allocate a second link for the second data packet.

[0198] As an optional embodiment, the allocation unit includes: a second identification subunit, used to identify the data packet type of each data packet, wherein the data packet type includes: a third data packet carrying key information and a fourth data packet with a data volume greater than a preset data volume threshold; a fourth allocation subunit, used to copy the third data packet into multiple copies and allocate different transmission links to the multiple copied third data packets; and a fifth allocation subunit, used to slice the fourth data packet to obtain multiple data sub-packets of the fourth data packet and allocate different transmission links to each fourth data sub-packet.

[0199] Figure 10 This is a schematic diagram of a data transmission apparatus according to an embodiment of this application. Figure 2 ,like Figure 10 As shown, the system includes: a second acquisition module 1002, used to acquire a target packet based on Fast User Datagram Networking Protocol (HTP) transmitted through a target stream, wherein the target stream is a data channel based on HTP, and the target packet carries at least the target address of the packet receiver; a second determination module 1004, used to determine the Hypertext Transfer Protocol (HTP) session matching the target stream, wherein the same HTP session uses the same HTP tunnel to transmit at least one HTP packet; a second conversion module 1006, used to convert the target packet into a HTP packet; and a second transmission module 1008, used to transmit the HTP packet to the target address through the HTP tunnel used by the HTP session.

[0200] The embodiments described above in this application achieve precise alignment between the response data transmitted via the QUIC protocol and the HTTP session initiated by the client at the protocol stack level by receiving the target message transmitted by the target stream based on the QUIC protocol, identifying the target address carried by the message, and restoring it to the original HTTP message based on the mapping relationship between the QUIC stream to which the message belongs and the previously established HTTP session. The response data is then returned to the requester via the corresponding HTTP tunnel. This allows the QUIC response returned by the backend server to be transparently returned via the original HTTP tunnel without modifying the existing HTTP implementations of the client and server, ensuring bidirectional consistency of the protocol conversion process and improving the integrity and reliability of cross-protocol communication. It is particularly suitable for scenarios where a local proxy intercepts and converts QUIC communication, effectively supporting bidirectional data mapping and session continuation between the HTTP tunnel and the QUIC stream, and solving the problem of lack of session-level mapping and transparent protocol conversion technology between HTTP tunnel requests and QUIC streams in the prior art.

[0201] It should be noted that the data transmission device can be used to execute the data transmission method in the embodiments of the present invention. Therefore, the relevant explanations and descriptions in the above data transmission method also apply to the data transmission device, and will not be repeated here.

[0202] It should be noted that each module in the above-mentioned data transmission device can be a program module (for example, a set of program instructions that implement a certain function) or a hardware module. For the latter, it can be manifested in the following forms, but is not limited to them: each of the above modules is manifested as a processor, or the functions of each of the above modules are implemented by a processor.

[0203] This application also provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the steps of implementing the data transmission methods in various embodiments of this application.

[0204] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the steps of the data transmission method in various embodiments of this application by running the computer program.

[0205] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the data transmission method in various embodiments of this application.

[0206] This application also provides a computer program that, when executed by a processor, implements the steps of the data transmission method in various embodiments of this application.

[0207] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0208] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0210] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0211] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0212] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0213] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A data transmission method, characterized in that, include: Acquire Hypertext Transfer Protocol (HTTP) messages transmitted through a Hypertext Transfer Protocol tunnel, wherein at least one HTTP message transmitted through the same HTTP tunnel belongs to the same HTTP session, and the HTTP message carries at least the destination address of the message receiver. Based on the Hypertext Transfer Protocol session to which the Hypertext Transfer Protocol message belongs, a matching target flow is determined, wherein the target flow is a data channel based on Fast User Datagram Network Connection Protocol. Convert the Hypertext Transfer Protocol message into a target message based on the Fast User Datagram Network Connection Protocol; The target message is transmitted to the target address via the target stream.

2. The method according to claim 1, characterized in that, Based on the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs, the target stream to be matched is determined as follows: Determine the session identifier of the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs; In a preset mapping table, a target flow identifier corresponding to the session identifier is queried from multiple flow identifiers recorded therein. The preset mapping table is used to record the mapping relationship between the flow identifier and the session identifier, and each flow identifier corresponds to a unique preset flow. Among the multiple preset flows recorded in the connection pool, the target flow corresponding to the target flow identifier is selected, wherein the connection pool is used at least to represent the correspondence between each pre-established preset flow and the flow identifier; The preset stream corresponding to the target stream identifier is determined as the target stream.

3. The method according to claim 2, characterized in that, The method further includes: If no target flow channel identifier corresponding to the session identifier is found among the multiple flow identifiers recorded in the preset mapping table, a transport flow based on the Fast User Datagram Network Connection Protocol is created for the session identifier. The transport stream is recorded through the connection pool; Create a unique transport stream identifier for the transport stream; The preset mapping table records the correspondence between the transport stream identifier and the session identifier.

4. The method according to claim 2, characterized in that, The session identifier that determines the Hypertext Transfer Protocol (HTTP) session to which the HTTP message belongs includes: Identify the message type of the Hypertext Transfer Protocol (HTTP) message, wherein the message type includes: HTTP request message and HTTP response message, and the HTTP response message is the response data returned by the message receiver after receiving the HTTP request message; When the message type is the Hypertext Transfer Protocol Request message, in response to the Hypertext Transfer Protocol Request message, the Hypertext Transfer Protocol tunnel is created, and the session identifier is assigned to the Hypertext Transfer Protocol Request message according to the Hypertext Transfer Protocol session to which the Hypertext Transfer Protocol tunnel belongs; When the message type is the Hypertext Transfer Protocol (HTTP) response message, the HTTP tunnel for transmitting the HTTP response message is determined, and the session identifier is assigned to the HTTP response message based on the HTTP session to which the HTTP tunnel belongs, wherein the HTTP response message is transmitted through the HTTP tunnel created in response to the HTTP request message.

5. The method according to claim 1, characterized in that, Transmitting the target message to the target address via the target stream includes: The target message is split into multiple data packets; In the multiple transmission links of the target stream, a corresponding target link is assigned to each data packet; The data packet corresponding to each of the multiple target links is transmitted to the target address.

6. The method according to claim 5, characterized in that, In the multiple transmission links of the target stream, allocating a corresponding target link for each data packet includes: For each data packet, a quality of service (QoS) test is performed to obtain the data quality type of each data packet, wherein the data quality type includes at least: a first data packet with low latency priority and a second data packet with high throughput priority; The transmission characteristics of each transmission link in the target stream are detected to obtain the link type of each transmission link, wherein the link type includes: a first link with low latency and a second link with high bandwidth; The first link is allocated to the first data packet, and the second link is allocated to the second data packet.

7. The method according to claim 5, characterized in that, In the multiple transmission links of the target stream, allocating a corresponding target link for each data packet includes: Identify the data packet type for each of the data packets, wherein the data packet type includes: a third data packet carrying key information and a fourth data packet with a data volume greater than a preset data volume threshold; The third data packet is copied into multiple copies, and different transmission links are assigned to the multiple copied third data packets; The fourth data packet is sliced ​​to obtain multiple data sub-packets, and a different transmission link is assigned to each fourth data sub-packet.

8. A data transmission method, characterized in that, include: Acquire a target message based on Fast User Datagram Networking Protocol (HTP) transmitted through a target stream, wherein the target stream is a data channel based on HTP, and the target message carries at least the target address of the message receiving end; Determine the Hypertext Transfer Protocol (HTTP) session that matches the target stream, wherein the same HTTP session uses the same HTTP tunnel to transmit at least one HTTP message. Convert the target message into the Hypertext Transfer Protocol message; The Hypertext Transfer Protocol (HTTP) message is transmitted to the target address through the HTTP tunnel used by the HTTP session.

9. A data transmission system, characterized in that, include: The first proxy server is used to obtain Hypertext Transfer Protocol (HTTP) messages transmitted to the target address through the HTTP tunnel; Based on the first Hypertext Transfer Protocol session to which the Hypertext Transfer Protocol message belongs, determine the target stream that the Hypertext Transfer Protocol message matches, and convert the Hypertext Transfer Protocol message into a target message based on Fast User Datagram Networking Protocol. The target message is transmitted to the second proxy server through the target stream; A second proxy server is used to receive the target message transmitted through the target stream; Determine the second Hypertext Transfer Protocol session that matches the target stream, and convert the target message into the Hypertext Transfer Protocol message; The Hypertext Transfer Protocol (HTTP) message is transmitted to the target address through the HTTP tunnel used by the second HTTP session; In this context, the same Hypertext Transfer Protocol session uses the same Hypertext Transfer Protocol tunnel to transmit at least one Hypertext Transfer Protocol message, and the target stream is a data channel based on Fast User Datagram Network Connection Protocol.

10. A data transmission device, characterized in that, include: The first acquisition module is used to acquire Hypertext Transfer Protocol (HTTP) messages transmitted through a Hypertext Transfer Protocol tunnel, wherein at least one HTTP message transmitted through the same HTTP tunnel belongs to the same HTTP session, and the HTTP message carries at least the target address of the message receiving end. The first determining module is used to determine the matching target stream based on the Hypertext Transfer Protocol session to which the Hypertext Transfer Protocol message belongs, wherein the target stream is a data channel based on the Fast User Datagram Network Connection Protocol. The first conversion module is used to convert the Hypertext Transfer Protocol message into a target message based on the Fast User Datagram Network Connection Protocol. The first transmission module is used to transmit the target message to the target address through the target stream.

11. A data transmission device, characterized in that, include: The second acquisition module is used to acquire a target message based on the Fast User Datagram Network Connection Protocol (HUDP) transmitted through a target stream, wherein the target stream is a data channel based on the HUDP, and the target message carries at least the target address of the message receiving end. The second determining module is used to determine the Hypertext Transfer Protocol session matched by the target stream, wherein the same Hypertext Transfer Protocol session uses the same Hypertext Transfer Protocol tunnel to transmit at least one Hypertext Transfer Protocol message. The second conversion module is used to convert the target message into the Hypertext Transfer Protocol message; The second transmission module is used to transmit the Hypertext Transfer Protocol (HTTP) message to the target address through the HTTP tunnel used by the HTTP session.

12. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when executed, performs the data transfer method according to any one of claims 1 to 8.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the data transmission method according to any one of claims 1 to 8.

Images