Data processing methods, equipment and readable storage media

Abstract

This application provides a data processing method, device, and readable storage medium. During uplink, when the NGINX server receives a first QUIC packet from a client device via a target UDP port, it sends the first QUIC packet to the QUIC protocol stack. The QUIC protocol stack processes the first QUIC packet to obtain application layer data and sends a first data stream containing the first application layer data packet to the upstream server. During downlink, a second data stream is received from the upstream server. The second application layer data packet in the second data stream is cached in a second cache. When the QUIC protocol stack is writable, it is handed over to the QUIC protocol stack for processing to obtain a second QUIC packet, which is then sent to the client device. This approach, by integrating a QUIC protocol stack into the NGINX server, enables simultaneous support for multiple application layer protocols in NGINX-based QUIC usage scenarios, and different application layer protocols use the same UDP port, reducing port overhead.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a data processing method, device and readable storage medium. Background Technology

[0002] User Datagram Protocol (UDP) is a connectionless transport layer protocol in the Open Systems Interconnection (OSI) reference model. Quick UDP Internet Connections (QUIC) is a low-latency internet transport layer protocol based on UDP, developed by Google. It offers many advantages, such as reduced connection latency and avoidance of head-of-line congestion.

[0003] The NGINX server is a high-performance Hypertext Transfer Protocol (HTTP) and reverse proxy server, characterized by high concurrency, good performance, and low memory consumption. Currently, in scenarios using QUIC based on NGINX, port 443 is used to transmit HTTP / 3 messages.

[0004] However, the aforementioned port 443 only supports one application layer protocol, namely HTTP / 3.0, and does not support other application layer protocols. This limits the scenarios in which QUIC is used based on NGINX and cannot support more services. Summary of the Invention

[0005] This application provides a data processing method, device, and readable storage medium. By integrating the QUIC protocol stack on the NGINX server, it enables the simultaneous support of multiple application layer protocols in scenarios using QUIC based on NGINX, and different application layer protocols use the same UDP port, reducing port overhead.

[0006] In a first aspect, embodiments of this application provide a data processing apparatus that receives a first QUIC message from a client device via a target UDP port, wherein the target UDP port supports multiple application layer protocols;

[0007] Send the first QUIC message to the QUIC protocol stack so that the QUIC protocol stack processes the first QUIC message and obtains application layer data;

[0008] Based on the protocol type of the first application layer data packet, a first data stream containing the first application layer data packet is sent to the upstream server. The first application layer data packet contains at least one application layer data corresponding to the first QUIC message.

[0009] In a second aspect, embodiments of this application provide an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it causes the electronic device to implement the method described in the first aspect or various possible implementations of the first aspect.

[0010] Thirdly, embodiments of this application provide a computer-readable storage medium storing computer instructions that, when executed by a processor, are used to implement the method described in the first aspect or various possible implementations of the first aspect.

[0011] The data processing method, apparatus, and readable storage medium provided in this application are applied to an NGINX server integrated with a QUIC protocol stack. During uplink, when the NGINX server receives a first QUIC message from a client device, it sends the first QUIC message to the QUIC protocol stack, allowing the QUIC protocol stack to process the first QUIC message to obtain application layer data and send a first data stream containing the first application layer data packet to the upstream server. During downlink, a second data stream is received from the upstream server, and the second application layer data packet in the second data stream is cached in a second cache. When the QUIC protocol stack is writable, it is handed over to the QUIC protocol stack for processing to obtain a second QUIC message, which is then sent to the client device. This approach, by integrating a QUIC protocol stack on the NGINX server, enables simultaneous support for multiple application layer protocols in scenarios using QUIC within NGINX, and different application layer protocols use the same UDP port, reducing port overhead. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of the network architecture to which the data processing method provided in the embodiments of this application applies;

[0014] Figure 2 This is a schematic diagram of the structure of the NGINX server provided in the embodiments of this application;

[0015] Figure 3 This is a flowchart of the data processing method provided in the embodiments of this application;

[0016] Figure 4 This is a schematic diagram of the structure of the first QUIC message in the data processing method provided in the embodiments of this application;

[0017] Figure 5 This is another flowchart of the data processing method provided in the embodiments of this application;

[0018] Figure 6 This is a schematic diagram illustrating the integration of the QUIC protocol stack on the NGINX server in the data processing method provided in this application embodiment;

[0019] Figure 7 This is a schematic diagram illustrating the pre-registration of callback events in the data processing method provided in this application embodiment;

[0020] Figure 8 A schematic diagram of a data processing apparatus provided in an embodiment of this application;

[0021] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0023] With the widespread adoption of the QUIC protocol, the third version of the Hypertext Transfer Protocol / 3 (HTTP / 3.0) has also been standardized. More and more manufacturers are launching products that support the use of the QUIC protocol to transmit HTTP requests. This application of QUIC is called HTTP / 3.0 over QUIC.

[0024] Real-Time Messaging Protocol (RTMP) is a common protocol in push-pull streaming scenarios in the live streaming field. With the development of the QUIC protocol, there is also a demand for RTMP over QUIC.

[0025] Currently, HTTP / 3.0 over QUIC uses HTTP / 3.0. However, some customers in web pages and other fields require HTTP / 1.1 over QUIC or HTTP / 2.0 over QUIC. Clearly, current QUIC integration scenarios only support HTTP / 3.0 and do not support other application layer protocols such as HTTP / 1.1, HTTP / 2.0, or RTMP. In the HTTP / 3.0 over QUIC scenario, port 443 is used to transmit HTTP / 3.0 messages.

[0026] To enable QUIC to support application layer protocols other than HTTP / 3.0, a common solution is to allocate a UDP port for each application layer protocol, with different application layer protocols corresponding to different UDP ports, thus allowing QUIC to serve multiple different application layer protocols.

[0027] However, when different UDP ports are assigned to different application layer protocols, the number of UDP ports provided to the outside world is large, resulting in high UDP port overhead.

[0028] Based on this, embodiments of this application provide a data processing method, apparatus, device, and system. By integrating the QUIC protocol stack on the NGINX server, the goal of supporting multiple application layer protocols simultaneously in scenarios using QUIC based on NGINX is achieved, and different application layer protocols use the same UDP port, reducing port overhead.

[0029] Figure 1 This is a schematic diagram of the network architecture to which the data processing method provided in this application applies. Please refer to... Figure 1 The network architecture includes an NGINX server 11, a client device 12, and an upstream server 13. A network connection is established between the NGINX server 11 and the client device 12, and a network connection is established between the NGINX server 11 and the upstream server 13.

[0030] NGINX Server 11 integrates a QUIC protocol stack, which may be a self-developed protocol stack or based on an open-source protocol stack. NGINX Server 11 is a proxy server. The addition of QUIC protocol stack processing capabilities to NGINX Server 11 includes, for example, the addition of an NGX-QUIC module. This NGX-QUIC module is responsible for processing the QUIC protocol stack, including QUIC configuration settings and business logic.

[0031] Client device 12 includes, but is not limited to, mobile phones, tablets, personal computers, e-book readers, laptops, desktop computers, and servers running Android, Microsoft, Symbian, Linux, or Apple iOS operating systems. In the live streaming field, client device 12 can be either a broadcaster's or a viewer's terminal device. When client device 12 is a broadcaster, it pushes the stream to upstream server 13 via NGINX server 11. When client device 12 is a viewer, it pulls the stream from upstream server 13 via NGINX server 11.

[0032] Upstream server 13 is, for example, a live streaming server or other streaming media server.

[0033] It should be understood that, Figure 1 The number of NGINX servers 11, client devices 12, and upstream servers 13 shown is merely illustrative. In actual implementation, any number of NGINX servers 11, client devices 12, and upstream servers 13 can be deployed according to actual needs.

[0034] Figure 2 This is a schematic diagram of the NGINX server provided in an embodiment of this application. Please refer to... Figure 2 The NGINX server 200 provided in this application embodiment includes an NGX-QUIC module 21, a detection module 22, and an application layer protocol module 23. The application layer protocol module 23 includes an HTTP / 1.1 unit 231, an HTTP / 2.0 unit 232, and an RTMP unit 233. Figure 2 The client device 100 is equivalent to Figure 1 Client device 12 in the middle, Figure 2 The NGINX server 200 is equivalent to Figure 1 NGINX server 11 in the middle, Figure 2 The upstream server 300 is equivalent to Figure 2 Upstream server 13.

[0035] The NGX-QUIC module 21 is responsible for processing the QUIC protocol stack, including QUIC configuration item processing and QUIC service processing. For uplink, after receiving the first QUIC message from the client device, the NGX-QUIC module 21 sends the first QUIC message to the QUIC protocol stack. After processing by the QUIC protocol stack to obtain the first application layer data packet, the application layer protocol module 23 sends the first data stream containing the first application layer data packet to the upstream server. For downlink, the application layer protocol module 23 receives the second data stream from the upstream server, sends the second application layer data packet from the second data stream to the QUIC protocol stack. After processing by the QUIC protocol stack to obtain the second QUIC message, the NGX-QUIC module 21 sends the second QUIC message to the client device.

[0036] The NGX-QUIC module 21 has a first buffer and a second buffer. The first buffer, also known as the receive buffer, is used when the QUIC protocol stack is readable. The NGX-QUIC module 21 reads the first application layer data packet from the QUIC protocol stack and caches it in the first buffer. The second buffer, also known as the send buffer, is used to cache the second application layer data that the NGINX server 200 is preparing to send. The second application layer data packet is the application layer data packet contained in the second data stream received by the NGINX server 200 from the upstream server. When the QUIC protocol stack is writable, the NGX-QUIC module 21 writes the second application layer data packet from the second buffer into the QUIC protocol stack.

[0037] The NGX-QUIC module 21 also hooks into various interfaces of the QUIC protocol stack, such as new connection creation, new stream creation, stream termination, and connection termination. By implementing these interfaces on the NGX-QUIC module 21, related business functions can be completed.

[0038] The detection module 22 is used to detect the protocol type of the first application layer data packet. When it is necessary to send the first application layer data packet in the first cache to the upstream server through the application layer of the NGINX server 200, the protocol detection module performs protocol detection on the first application layer data packet to detect whether the first application layer data packet is based on HTTP / 1.1, HTTP / 2.0, or RTMP.

[0039] Application layer protocol module 23 is used to read a first application layer data packet from a first cache and send a first data stream containing the first application layer data packet to an upstream server, or to receive a second data stream containing a second application layer data packet from an upstream server and cache the second application layer data packet in a second cache.

[0040] Please refer to Figure 2For uplink (i.e., the NGINX server sending packets to the upstream server), the application layer protocol module 23 is used to read the first application layer data packet from the first cache and send it to the upstream server according to the protocol type of the first application layer data packet. For example, if the NGINX server 200 is required to support HTTP / 1.1 over QUIC, HTTP / 2.0 over QUIC, or RTMP over QUIC, then the application layer protocol module 23 includes an HTTP / 1.1 unit 231, an HTTP / 2.0 unit 232, and an RTMP unit 233, which are used to send the first application layer data packet based on HTTP / 1.1, the first application layer data packet based on HTTP / 2.0, and the first application layer data packet based on RTMP, respectively.

[0041] Figure 2 In the diagram, solid arrows represent the flow of QUIC messages, dashed arrows represent the flow of the first application layer data packets, and dotted-dash arrows represent the flow of the first and second data streams.

[0042] For downlink processing, each unit of the application layer protocol module 23 receives second application layer data packets from the upstream server. These second application layer data packets are also known as the application layer data packets that the NGINX server is preparing to send. The application layer protocol module 23 buffers these second application layer data packets in the second buffer of the NGX-QUIC module 21. When the QUIC protocol stack is writable, the second application layer data packets in the second buffer are written to the QUIC protocol stack, so that the QUIC protocol stack processes the second application layer data packets and obtains a second QUIC message. The NGX-QUIC module 21 then sends the second QUIC message to the client device.

[0043] Below, based on Figure 1 The network architecture shown and Figure 2 The structure of the NGINX server shown illustrates the data processing method described in this application embodiment. For example, please refer to... Figure 3 .

[0044] Figure 3 This is a flowchart of the data processing method provided in this application embodiment. This embodiment is described from the perspective of an NGINX server integrated with a QUIC protocol stack, and includes:

[0045] 301. Receive the first QUIC message from the client device through the target UDP port, wherein the target UDP port supports multiple application layer protocols.

[0046] In this embodiment, the target UDP port is, for example, port 443, and multiple different application layer protocols use the same target UDP port. These multiple application layer protocols include, but are not limited to, HTTP / 1.1, HTTP / 2.0, or RTMP. The NGINX server listens on the target UDP port and receives the first QUIC packet from the client from the network interface card.

[0047] Figure 4 This is a schematic diagram of the structure of the first QUIC message in the data processing method provided in this application embodiment. Please refer to... Figure 4 The payload of the UDP packet includes a first QUIC packet, which includes a QUIC header and a QUIC payload. The QUIC payload contains encrypted application layer data, such as data based on HTTP / 1.1, HTTP / 2.0, or RTMP.

[0048] 302. Send the first QUIC message to the QUIC protocol stack so that the QUIC protocol stack processes the first QUIC message and obtains application layer data.

[0049] After receiving the first QUIC packet, the NGINX server does not send it directly to the application layer. Instead, it forwards it to the QUIC protocol stack, which then processes it. For example, the NGINX server might hook into the read event handler of a target UDP port. Inside the read event handler, it receives the first QUIC packet and passes it to the QUIC protocol stack via its interface. This approach, by hooking into the read event handler of the target UDP port, intercepts and sends the first QUIC packet to the QUIC protocol stack, offering a simple and fast method.

[0050] To improve performance, the NGINX server can use kernel-supported combined packet receiving functions to receive packets (i.e., receive the first QUIC message). Examples of combined packet receiving functions include recvmmsg, etc., and this application embodiment is not limited to these functions.

[0051] For uplink processing, the QUIC protocol stack handles out-of-order reordering, duplicate filtering, verification, and decryption, ultimately producing the first application layer data packet. For example, the QUIC protocol stack receives two first QUIC packets sequentially. The first packet carries 200 bytes of application layer data with sequence number 20, and the second carries 300 bytes of application layer data with sequence number 19. The QUIC protocol stack decrypts the two packets to obtain the plaintext application layer data, reassembles it to obtain a 500-byte first application layer data packet, in which the application layer data with sequence number 19 comes first, followed by the application layer data with sequence number 20.

[0052] For example, if the QUIC protocol stack receives two first QUIC messages carrying the same application layer data, the QUIC protocol stack will delete one of the first QUIC messages.

[0053] For example, the QUIC protocol stack receives two first QUIC packets and decrypts them into plaintext data. One first QUIC packet carries application layer data with sequence number 3, and the other carries application layer data with sequence number 14. The QUIC protocol stack places application layer data with sequence number 3 and 14 into its read buffer, but does not notify the application layer to read them; that is, the QUIC protocol stack is unreadable. Only after application layer data with sequence numbers 4-13 are placed into the QUIC protocol stack's read buffer can the QUIC protocol stack become readable, and it then notifies the application layer to read one or more first application layer data packets corresponding to application layer data with sequence numbers 3-14 from the QUIC protocol stack.

[0054] 303. Based on the protocol type of the first application layer data packet, send a first data stream containing the first application layer data packet to the upstream server, wherein the first application layer data packet contains at least one application layer data corresponding to the first QUIC message.

[0055] In this embodiment, the application layer of the NGINX server sends a first data stream containing the first application layer data packet to the upstream server according to the protocol type of the first application layer data packet. Clearly, the first application layer data packet in the first data stream sent by the application layer is not obtained from the target UDP port by the listening network interface card, but rather is the first application layer data packet obtained after processing by the QUIC protocol stack. The first application layer data packet may be an RTMP-based data packet, an HTTP / 1.1-based data packet, an HTTP / 2.0-based data packet, etc.

[0056] The data processing method provided in this application is applied to an NGINX server integrated with a QUIC protocol stack. When the NGINX server receives a first QUIC message from a client device, it sends the first QUIC message to the QUIC protocol stack, allowing the QUIC protocol stack to process the first QUIC message and obtain application layer data. Then, based on the protocol type of the first application layer data packet, it sends a first data stream containing the first application layer data packet to an upstream server. This approach, by integrating a QUIC protocol stack on the NGINX server, enables simultaneous support for multiple application layer protocols in scenarios using QUIC within NGINX, while different application layer protocols use the same UDP port, reducing port overhead.

[0057] Optionally, in the above embodiments, during the process of the NGINX server sending a first data stream containing the first application layer data packet to the upstream server according to the protocol type of the first application layer data packet, when the QUIC protocol stack is readable, the first application layer data packet is read from the QUIC protocol stack and cached in the first cache. Then, according to the protocol type of the first application layer data packet, the first application layer data packet is read from the first cache and sent to the upstream server as a first data stream containing the first application layer data packet.

[0058] In this embodiment, when the QUIC protocol stack's read buffer contains the first application layer data packet, it indicates that the QUIC protocol stack is readable. At this time, the NGINX server reads the first application layer data packet from the QUIC protocol stack's read buffer and caches the first application layer data packet in the first buffer, i.e., the receive buffer.

[0059] When the first application-layer data packet is present in the first buffer, the NGINX server's application layer reads the first application-layer data packet from the first buffer according to its protocol type. Then, it sends a first data stream containing the first application-layer data packet to the upstream server.

[0060] With this approach, when the QUIC protocol stack is readable, the NGINX server reads the first application layer data packet from the QUIC protocol stack and caches it in the first cache. Instead of listening to the network card, the first application layer data packet is read from the first cache in the application layer. This enables the use of QUIC in NGINX scenarios to support multiple application layer protocols at the same time, and different application layer protocols use the same UDP port, reducing port overhead.

[0061] The above explanation focuses on the upstream perspective. The following section details the downstream process, specifically how the NGINX server's application layer sends the second application-layer data packets from the second data stream to the client after receiving the second data stream from the upstream server. For an example, please refer to [link to example]. Figure 5 .

[0062] Figure 5 This is another flowchart of the data processing method provided in this application embodiment. This embodiment is described from a downstream perspective. This embodiment includes:

[0063] 501. Receive the second data stream from the upstream server.

[0064] In this step, the NGINX server's application layer receives a second data stream from an upstream server, such as a streaming media server. This second data stream contains at least one second application layer data packet. These second application layer data packets are referred to as data packets that the NGINX server's application layer is prepared to send out.

[0065] 502. Cache the second application layer data packets contained in the second data stream into the second cache.

[0066] In this embodiment of the application, after the application layer of the NGINX server receives the second data stream, it does not directly send the second application layer data packet to the client through the network card, but instead caches the second application layer data packet in the second cache, that is, the sending cache.

[0067] 503. When the QUIC protocol stack is writable, the second application layer data packet in the second buffer is sent to the QUIC protocol stack so that the QUIC protocol stack processes the second application layer data packet and obtains the second QUIC message.

[0068] In this embodiment, when the write buffer of the QUIC protocol stack is free, it indicates that the QUIC protocol stack is writable. For example, if 50% of the write buffer is free, it means that the QUIC protocol stack is writable. At this time, the NGINX server writes the second application layer data packet in the second buffer into the write buffer of the QUIC protocol stack, so that the QUIC protocol stack performs QUIC packet assembly operations such as adding QUIC headers and UDP headers to the second application layer data packet and encrypting it, thereby obtaining the second QUIC packet.

[0069] 504. Send the second QUIC message to the client device through the target UDP port.

[0070] The NGINX server sends a second QUIC message to the client device via the target UDP port. For example, the NGINX server hooks into the packet sending interface of the QUIC protocol stack, and the NGX-QUIC module assembles the second application-layer data packet into a second QUIC message before sending it. To improve sending performance, the NGINX server can use kernel-supported combined packet sending functions to send packets, i.e., send the second QUIC message. Examples of combined packet sending functions include the Generic SegmentationOffload (GSO) function and the sendmmsg function.

[0071] This approach allows for the simultaneous support of multiple application layer protocols in NGINX-based QUIC scenarios by caching the second application layer data packets in the second data stream and handing them over to the QUIC protocol stack during downlink processing. Furthermore, different application layer protocols use the same UDP port, reducing port overhead.

[0072] Optionally, in the above embodiments, before sending the first application layer data packet to the upstream server according to the protocol type of the first application layer data packet, the NGINX server also hooks the first HTTP-based receiving interface of the NGINX server application layer and reads the first application layer data packet from the first cache through the first receiving interface. Then, the protocol type of the first application layer data packet is detected, and the protocol type includes HTTP / 1.1, HTTP / 2.0, or RTMP.

[0073] Please refer to Figure 2 In this embodiment, the NGINX server needs to support HTTP / 1.1, HTTP / 2.0, HTTP / 3.0, and RTMP simultaneously, and requires a probing module. The NGINX server has a native receive (recv) interface for application layer connections, but it can be augmented, for example, by attaching the same interface to receive packets and then sending them to different application layer units. The native receive (recv) interface can distinguish between HTTP / 1.1, HTTP / 2.0, and RTMP. For example, two simple functions can be attached to the native receive (recv) interface, corresponding to the first receive interface for HTTP and the second receive interface for the RTMP unit, respectively. Both the HTTP / 1.1 and HTTP / 2.0 units utilize the first receive interface to read the first application layer data packets from the first buffer.

[0074] When the first application-layer data packet is present in the first cache, the NGX-QUIC module 21 of the NGINX server 200 hooks the application-layer HTTP-based first receive interface, such as a first receive interface or a second receive interface. Then, the first application-layer data packet is read from the first cache through the first receive interface, for example, one or several bytes of the first application-layer data packet are read, and the protocol type of the first application-layer data packet is detected based on the read bytes, the protocol type including HTTP / 1.1, HTTP / 2.0, or RTMP, etc.

[0075] In this way, the bytes read by the protocol probe enter the probe module from the HTTP unit, such as the HTTP / 1.1 unit. The probe module analyzes one or several bytes of the first application layer data packet to determine which application layer protocol the first application layer data packet uses. The application layer protocol includes, but is not limited to, HTTP / 1.1, HTTP / 2.0, or RTMP.

[0076] This approach uses protocol probing to enable different application layer protocols to use the same target UDP port, allowing the same UDP port to serve different application layer protocols simultaneously. This reduces UDP port overhead and expands the applicability of scenarios using QUIC based on NGINX.

[0077] Optionally, in the above embodiments, when the NGINX server probes the protocol type of the first application layer data packet through the probing module, it creates an application layer connection for the first application layer data packet using a first file descriptor (fd), wherein the first fd is different from the second fd of the first QUIC message. Then, a peek interface is added to the application layer connection, and the peek interface is used to probe the protocol type of the first application layer data packet.

[0078] In traditional schemes using different application layer protocols based on the Transmission Control Protocol (TCP) to share a port, HTTP / 2.0 and RTMP probing is performed by executing the MSG_PEEK operation on the receive interface of the TCP file descriptor (fd) that has completed the three-way handshake. However, in this embodiment, the application layer fd, i.e., the first fd, has not undergone the three-way handshake, so the peek will fail. Therefore, in this embodiment, an application layer connection is created for the first application layer data packet, a probing interface is added to this connection, and the HTTP / 2.0 or RTMP probing function is modified. The HTTP / 1.1 probing function is not modified because the first application layer data packet used for protocol probing enters from the HTTP / 1.1 unit.

[0079] During protocol probing, if a first-layer application-layer packet is a UDP packet, the probing interface added for the application layer is used for probing. If it is a TCP packet, a traditional TCP-based port-sharing probing scheme is used.

[0080] In this embodiment, the probe interface added for the application layer connection hooks a probe function, such as the `ngx_quic_peek` function, into the NGX-QUIC module. Inside this probe function, data received from the QUIC protocol stack is simply copied to the upper layer, i.e., the application layer module, such as RTMP or HTTP / 2.0. After copying, the corresponding index does not move; that is, the pointer does not move. This ensures that the data is still present when the application layer module calls the receive function (`ngx_quic_recv`) the next time, allowing data to be read from the beginning. In other words, the NGX-QUIC module does not handle protocol probing. Protocol probing uses the peek interface added by the kernel layer for the application layer connection, attaching a new probe interface for UDP protocol probing. After probing, the data remains in its original location instead of being read away. For example, if only one or a few bytes of the first application layer data packet are probed, these bytes remain in the first buffer. This type of probing cannot be considered a read operation because a read operation would move the pointer forward. However, in this application, by adding a probe (peek) interface, the pointer is prevented from moving.

[0081] It should be noted that a QUIC connection can have multiple streams, and each stream corresponds to an application layer connection. The application layer connection is virtual, and the first file descriptor (fd) is not obtained through a three-way handshake. Application layer connections include, for example, HTTP connections, RTMP connections, etc.

[0082] This approach improves the TCP-based port sharing detection scheme, enabling the protocol detection module to simultaneously support both TCP-based and UDP-based port sharing detection. This expands the applicability of the NGINX server to other services while reducing costs and workload.

[0083] Optionally, in the above embodiments, when the NGINX server sends the first application layer data packet to the upstream server according to the protocol type of the first application layer data packet, it hooks the second receiving interface of the NGINX server application layer based on RTMP. When the protocol type of the first application layer data packet is RTMP, the first application layer data packet is read from the first cache through the second receiving interface and sent to the upstream server; when the protocol type of the first application layer data packet is HTTP / 1.1 or HTTP / 2.0, the first application layer data packet is read from the first cache through the first receiving interface and sent to the upstream server.

[0084] For example, in order for NGINX to support HTTP / 1.1 over QUIC, HTTP / 2.0 over QUIC, or RTMP over QUIC simultaneously, HTTP / 1.1 units, HTTP / 2.0 units, and RTMP units are set up on the NGINX server respectively. The HTTP / 1.1 unit is used to handle the sending and receiving of HTTP / 1.1 protocol, the HTTP / 2.0 unit is used to handle the sending and receiving of HTTP / 2.0 protocol, and the RTMP unit is used to handle the sending and receiving of RTMP protocol.

[0085] For receiving packets in HTTP / 1.1 and HTTP / 2.0, taking HTTP / 1.1 as an example, the NGX-QUIC module of the NGINX server hooks onto the first receive interface 1 of the NGINX server's native application layer. Inside the receive function corresponding to the first receive interface 1, the read interface of the QUIC protocol stack is called to read the first application layer data packet that has been processed by the QUIC protocol stack and cached in the first cache, and then the HTTP / 1.1 unit processes it. The HTTP / 1.1 unit places the first application layer data packet in the HTTP data stream and sends it to the upstream server.

[0086] Similarly, taking HTTP / 2.0 packet reception as an example, the NGX-QUIC module of the NGINX server hooks into the NGINX server's native application layer first receive interface. Inside the receive function corresponding to the first receive interface, it calls the read interface of the QUIC protocol stack to read the first application layer data packet that has been processed by the QUIC protocol stack and cached in the first cache, and then sends it to the HTTP / 2.0 unit for processing. The HTTP / 2.0 unit then places the first application layer data packet in the HTTP data stream and sends it to the upstream server.

[0087] For RTMP packet reception, the NGX-QUIC module of the NGINX server hooks into the NGINX server's native application layer second receive interface. Inside the receive function corresponding to this second receive interface, the QUIC protocol stack's read interface is called to read the first application layer data packet, which has already been processed by the QUIC protocol stack and buffered in the first buffer, and then the RTMP unit processes it. The RTMP unit then places the first application layer data packet in the RTMP data stream and sends it to the upstream server.

[0088] By using this approach, different protocol units of the application layer can read the first application layer data from the first cache and send it to the upstream server by hooking the native application layer receive interface of the NGINX server. The process is simple and low-cost.

[0089] The above describes how the NGINX server's application layer receives and forwards the first QUIC message to the upstream server after the client device sends it. Below, we will explain in detail how the NGINX server's application layer sends packets after the upstream server sends the second data stream to the NGINX server.

[0090] Optionally, in the above embodiments, when the QUIC protocol stack is writable, the NGINX server receives the second data stream from the upstream server and caches the second application layer data packets contained in the second data stream into the second cache.

[0091] When the QUIC protocol stack is writable, for HTTP / 1.1 and HTTP / 2.0 packet transmission, the NGX-QUIC module of the NGINX server hooks onto the NGINX server's native first sending interface, such as the send_chain interface. Within this first sending interface, the second application layer data packet prepared for transmission (HTTP / 1.1 or HTTP / 2.0 unit) is written to the QUIC protocol stack's write buffer via the QUIC protocol stack's write interface. The QUIC protocol stack then determines when to send it to the client device. The NGX-QUIC module of the NGINX server can attach the same first sending interface or different first sending interfaces for HTTP / 1.1 and HTTP / 2.0; this embodiment is not limited to these options.

[0092] When the QUIC protocol stack is writable, that is, when there is a lot of free space in the write buffer of the QUIC protocol stack, for RTMP packet transmission, the NGX-QUIC module of the NGINX server hooks the second send interface of the NGINX server, such as the send interface. Inside the second send interface, the second application layer data packet that the RTMP unit is preparing to send is written into the write buffer of the QUIC protocol stack through the write interface of the QUIC protocol stack. The QUIC protocol stack then decides when to send it to the client device.

[0093] By using this approach, different application layer protocol units can send the second application layer data, which is ready to be sent to the client device, to the QUIC protocol stack by hooking the native sending interface of the NGINX server. The process is simple and low-cost.

[0094] Optionally, in the above embodiments, when the NGINX server sends the first QUIC message to the QUIC protocol stack, during a hot update or upgrade of the NGINX server, a target process group is determined from multiple process groups in the port multiplexing group based on the four-tuple carried in the first QUIC message. Each process group in the multiple process groups has independent ebpf resources. Then, a target file descriptor is selected from the file descriptors of each process in the target process group; and the first QUIC message is sent to the QUIC protocol stack using the target file descriptor.

[0095] For example, hot updates, also known as reloads, configuration updates, hot reloads, or reload configurations, refer to dynamically loading configurations and updating parameters in application services deployed on the NGINX server, without changing the entire application service or upgrading its version. Upgrades, on the other hand, involve replacing the old application service with the new one. After the NGINX server starts, it creates a master process for each application service, which in turn creates a group of worker processes. When a hot update is performed on the application service, a new process group is created each time a reload occurs, resulting in multiple process groups. At this point, the NGINX server determines the target process group from among the multiple process groups on the target UDP port based on the four-tuple carried in the first QUIC message. Each process group has independent ebpf resources. Then, it selects the target file descriptor (fd) from the file descriptors (fds) of each process in the target process group. For example, the NGINX server might determine the process with the lowest load from the multiple processes in the target process group, use that process's fd as the target fd, and send the first QUIC message to the QUIC protocol stack using the target fd.

[0096] This approach uses ebpf to incorporate application-layer decision-making when the kernel selects a route for the first QUIC packet. It distinguishes different client devices using a four-tuple method, thus resolving the packet corruption problem caused by hot updates or upgrades.

[0097] Figure 6 This is a schematic diagram illustrating the integration of the QUIC protocol stack on an NGINX server in the data processing method provided in this application embodiment. Please refer to... Figure 6 In the uplink scenario, after the first QUIC packet sent by the client device enters the NGINX server, it is forwarded to the QUIC protocol stack by the NGX-QUIC module. After handshake processing, certificate loading, and mode selection, the QUIC protocol stack performs connection processing. Subsequently, the QUIC protocol stack performs stream processing on the first QUIC packet, such as out-of-order reordering and verification, to obtain the first application layer data packet. This first application layer data packet is buffered in the QUIC protocol stack's read buffer. The QUIC protocol stack's read buffer is not shown in the diagram.

[0098] When the QUIC protocol stack's read buffer contains the first application layer data, it indicates that the QUIC protocol stack is readable. At this point, a stream readable event is triggered. The NGX-QUIC module reads the first application layer data packet from the QUIC protocol stack and buffers it in the first buffer (not shown in the diagram). Because the NGX-QUIC module is hooked to the first or second receive interface of the application layer protocol module, each protocol unit of the application layer protocol module can read the first application layer data packet from the first buffer, thus completing application layer packet reception. Afterwards, each protocol unit sends the data packet read from the first buffer to the upstream server via a stream.

[0099] In the downlink scenario, after the second data stream from the upstream server arrives at the NGINX server, because the NGX-QUIC module is hooked to the first and second sending interfaces of the application layer protocol module, the NGX-QUIC module buffers the second data stream into a second buffer (not shown in the diagram). When the write buffer of the QUIC protocol stack becomes writable, a stream writable event is triggered. The NGX-QUIC module writes the second application layer data packet from the second buffer into the write buffer of the QUIC protocol stack. The QUIC protocol stack processes the second application layer data packet to obtain the second QUIC packet. Then, the QUIC protocol stack performs flow control, such as congestion control. After flow control is complete, the QUIC protocol stack's packet sending function is called at an appropriate time to send the second QUIC packet out, such as using GSO packet sending.

[0100] Figure 7 This is a schematic diagram illustrating the pre-registration of callback events in the data processing method provided in this application embodiment. Please refer to... Figure 7 The read event handler function for the target UDP port listened to by the NGX-QUIC module is, for example, ngx_quic_read_handler. During the initialization of the NGINX server's worker process, callback events are registered with the QUIC protocol stack. These callback events include stream read and stream write events. Subsequently, during uplink and downlink operations, when any target event in the callback events triggers a callback, the target event is processed.

[0101] In addition to the stream read and stream write events mentioned above, callback events may optionally include new connection creation events, new stream creation events, stream close events, or connection close events.

[0102] Please refer to Figure 7Initialization includes initializing the QUIC protocol stack, setting the stream callback, setting the certificate load callback, setting the server name authentication callback, setting the QUIC conn read handler, setting the packet sending function callback, and adding a timer to process the QUIC conns.

[0103] Figure 7 In the NGINX protocol stack, the callback function is, for example, `Process quic conns`. After receiving the first QUIC packet via the `ngx_quic_read_handler` function, the NGINX server sends it to the QUIC protocol stack, which then performs tasks such as packet reordering and verification. When the QUIC protocol stack becomes readable, the NGX-QUIC module handles the readable event callback.

[0104] The NGX-QUIC module calls the protocol stack callback function `Processquic conns` to handle all callback events, including new connection creation events, new stream creation events, stream readable events, stream writable events, stream closed events, and connection closed events. These callback events are registered during the initialization of the NGINX server's worker process.

[0105] This approach involves registering various callback events with the QUIC protocol stack during the initialization of the NGINX server's worker process, ensuring that the NGINX server supports multiple application layer protocols and expanding the scope of applications using QUIC based on NGINX.

[0106] In this embodiment of the application, a data packet sending callback is added to the QUIC protocol stack to send the second QUIC message that the QUIC protocol stack has assembled and is ready to send. This is also set during the initialization of the worker process.

[0107] Please refer to Figure 7Add a timer to handle various events in the QUIC protocol stack. This is because after the QUIC protocol stack receives the first QUIC message, its read buffer may not be immediately readable. For example, if the first QUIC message carries application layer data number 4, and the application layer protocol module has already read application layer data number 2 from the first buffer, then since application layer data number 3 has not yet been received, it cannot buffer the message carrying application layer data number 4 into the first buffer. If the QUIC protocol stack is not readable, a timer is needed to handle subsequent QUIC protocol stack readable events.

[0108] In response to the QUIC protocol stack callback for new connection events, the NGINX server uses the first file descriptor (fd) to create an application-layer connection. This avoids the second file descriptor of the target UDP port being closed by the application layer's `close` function or other operations that might cause problems with the second file descriptor. The application-layer connection is hooked to HTTP, setting corresponding receive and send functions such as `recv`, `send`, or `send_chain`, and then initializing it through an HTTP listener function.

[0109] For QUIC protocol stack callback readable events: The NGX-QUIC module reads the first application layer data packet from the QUIC protocol stack's read buffer and stores it in the buffer corresponding to the application layer connection. Each application layer connection has its own buffer. Then, it calls the first or second receive interface of the application layer, such as the HTTP / 1.1 unit, HTTP / 2.0 unit, or RTMP unit, to read the first application layer data packet from the first buffer.

[0110] Regarding the QUIC protocol stack callback writable event: The NGX-QUIC module buffers the second application layer data packets prepared for sending by each protocol unit of the application layer protocol module using send or send_chain into a second buffer. When the QUIC protocol stack is writable, the data is written to the QUIC protocol stack's write buffer through the QUIC protocol stack's write interface. The QUIC protocol stack then calls its packet sending function at an appropriate time to send the second QUIC packet, such as using GSO (Global Order Message) method.

[0111] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0112] Figure 8This is a schematic diagram of a data processing device provided in an embodiment of this application. The data processing device 800 is integrated on an NGINX server, which also integrates a QUIC protocol stack. The data processing device 800 includes a receiving module 81, a sending module 83, and a processing module 82.

[0113] The receiving module 81 is configured to receive a first QUIC message from a client device through a target UDP port, wherein the target UDP port supports multiple application layer protocols;

[0114] Processing module 82 is used to send the first QUIC message to the QUIC protocol stack so that the QUIC protocol stack processes the first QUIC message and obtains application layer data.

[0115] The sending module 83 is used to send a first data stream containing the first application layer data packet to an upstream server according to the protocol type of the first application layer data packet, wherein the first application layer data packet contains at least one application layer data corresponding to the first QUIC message.

[0116] In one feasible implementation, the processing module 82 is further configured to read the first application layer data packet from the QUIC protocol stack and cache it in the first cache when the QUIC protocol stack is readable, and read the first application layer data packet from the first cache according to the protocol type of the first application layer data packet;

[0117] The sending module 83 is used to send a first data stream containing the first application layer data packet to the upstream server.

[0118] In one feasible implementation, before the sending module 83 sends the first data stream containing the first application layer data packet to the upstream server, the processing module 82 is further configured to hook the first HTTP-based receiving interface of the NGINX server application layer; read the first application layer data packet from the first cache through the first receiving interface; and detect the protocol type of the first application layer data packet, wherein the protocol type includes HTTP / 1.1, HTTP / 2.0, or RTMP.

[0119] In one feasible implementation, when the processing module 82 detects the protocol type of the first application layer data packet, it is used to create an application layer connection for the first application layer data packet using a first file descriptor fd, wherein the first fd is different from the second fd of the first QUIC message; add a detection interface to the application layer connection; and use the detection interface to detect the protocol type of the first application layer data packet.

[0120] In one feasible implementation, the processing module 82 is used to hook the second RTMP-based receiving interface of the NGINX server application layer. When the protocol type of the first application layer data packet is RTMP, the first application layer data packet is read from the first buffer through the second receiving interface. The sending module 83 is used to send the first application layer data packet to the upstream server.

[0121] The processing module 82 is used to hook the second receiving interface of the NGINX server application layer based on RTMP. When the protocol type of the first application layer data packet is HTTP / 1.1 or HTTP / 2.0, it reads the first application layer data packet from the first cache through the first receiving interface and sends it to the upstream server through the sending module 83.

[0122] In one feasible implementation, the receiving module 81 is further configured to receive a second data stream from an upstream server;

[0123] The processing module 82 is further configured to cache the second application layer data packets contained in the second data stream to a second cache;

[0124] The sending module 83 is further configured to, when the QUIC protocol stack is writable, send the second application layer data packet in the second buffer to the QUIC protocol stack, so that the QUIC protocol stack processes the second application layer data packet and obtains the second QUIC message; and send the second QUIC message to the client device through the target UDP port.

[0125] In one feasible implementation, the processing module 82 is further configured to hook the first sending interface of the NGINX server;

[0126] The sending module 83 is used to write the second application layer data packet in the second cache into the QUIC protocol stack through the first sending interface when the protocol type of the second application layer data packet is HTTP / 1.1 or HTTP / 2.0 and the QUIC protocol stack is writable.

[0127] The processing module 82 is also used to hook the second sending interface of the NGINX server;

[0128] The sending module 83 is used to write the second application layer data packet in the second buffer into the QUIC protocol stack through the second sending interface when the protocol type of the second application layer data packet is RTMP and the QUIC protocol stack is writable.

[0129] In one feasible implementation, the processing module 82 is further configured to register callback events with the QUIC protocol stack during the initialization of the NGINX server's worker process. The callback events include: stream readable events and stream writable events. When any target event in the callback events triggers the callback, the target event is processed.

[0130] In one feasible implementation, the processing module 82 is further configured to hook the read event handling function of the target UDP port;

[0131] The sending module 83 is used to send the first QUIC message to the QUIC protocol stack using the read event handling function.

[0132] The data processing apparatus provided in this application embodiment can execute the actions of the NGINX server in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0133] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device 900 is, for example, the aforementioned NGINX server, and the electronic device 900 includes:

[0134] Processor 91 and memory 92;

[0135] The memory 92 stores computer instructions;

[0136] The processor 91 executes the computer instructions stored in the memory 92, causing the processor 91 to perform the data processing method implemented by the NGINX server as described above.

[0137] The specific implementation process of processor 91 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0138] Optionally, the electronic device 900 also includes a communication component 93. The processor 91, memory 92, and communication component 93 can be connected via a bus 94.

[0139] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, are used to implement the data processing method implemented by the NGINX server as described above.

[0140] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the data processing method implemented by the NGINX server as described above.

[0141] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0142] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data processing method, characterized in that, The method, applied to an NGINX server integrating a QUIC protocol stack, includes: The target UDP port receives UDP packets from the client device. The payload of the UDP packet includes a first QUIC packet, which includes a QUIC header and a QUIC payload. The QUIC payload contains encrypted application layer data, which is based on HTTP / 1.1, HTTP / 2.0, or RTMP. The target UDP port supports multiplexing of HTTP / 1.1, HTTP / 2.0, and RTMP protocols. Send the first QUIC message to the QUIC protocol stack so that the QUIC protocol stack processes the first QUIC message and obtains application layer data; Based on the protocol type of the first application layer data packet, a first data stream containing the first application layer data packet is sent to the upstream server. The first application layer data packet contains at least one application layer data corresponding to the first QUIC message.

2. The method according to claim 1, characterized in that, The step of sending a first data stream containing the first application layer data packet to the upstream server according to the protocol type of the first application layer data packet includes: When the QUIC protocol stack is readable, the first application layer data packet is read from the QUIC protocol stack and cached in the first cache; Based on the protocol type of the first application layer data packet, the first application layer data packet is read from the first cache and a first data stream containing the first application layer data packet is sent to the upstream server.

3. The method according to claim 2, characterized in that, Before reading the first application layer data packet from the first cache according to the protocol type of the first application layer data packet and sending the first data stream containing the first application layer data packet to the upstream server, the method further includes: Hook the first HTTP-based receive interface of the NGINX server application layer; The first application layer data packet is read from the first cache through the first receiving interface; The protocol type of the first application layer data packet is detected, and the protocol type includes HTTP / 1.1, HTTP / 2.0, or RTMP.

4. The method according to claim 3, characterized in that, The method of detecting the protocol type of the first application layer data packet includes: An application layer connection is created using the first file descriptor fd for the first application layer data packet, wherein the first file descriptor fd is different from the second file descriptor fd of the target UDP port; Add a probe interface to the application layer connection; The protocol type of the first application layer data packet is detected using the detection interface.

5. The method according to claim 3, characterized in that, The step of reading the first application layer data packet from the first cache and sending a first data stream containing the first application layer data packet to the upstream server according to the protocol type of the first application layer data packet includes: Hook the second RTMP-based receiving interface of the NGINX server application layer. When the protocol type of the first application layer data packet is RTMP, read the first application layer data packet from the first buffer through the second receiving interface and send it to the upstream server. When the protocol type of the first application layer data packet is HTTP / 1.1 or HTTP / 2.0, the first application layer data packet is read from the first cache through the first receiving interface and sent to the upstream server.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: Receive the second data stream from the upstream server; Cache the second application layer data packets contained in the second data stream into the second cache; When the QUIC protocol stack is writable, the second application layer data packet in the second buffer is sent to the QUIC protocol stack so that the QUIC protocol stack can process the second application layer data packet and obtain the second QUIC message; The second QUIC message is sent to the client device through the target UDP port.

7. The method according to claim 6, characterized in that, When the QUIC protocol stack is writable, sending the second application layer data packet from the second buffer to the QUIC protocol stack includes: Hook the first sending interface of the NGINX server, and when the protocol type of the second application layer data packet is HTTP / 1.1 or HTTP / 2.0, write the second application layer data packet in the second cache into the QUIC protocol stack through the first sending interface; Hook the second sending interface of the NGINX server, and when the protocol type of the second application layer data packet is RTMP, write the second application layer data packet in the second buffer into the QUIC protocol stack through the second sending interface.

8. The method according to any one of claims 1 to 5, characterized in that, Also includes: When the NGINX server's worker process initializes, it registers callback events with the QUIC protocol stack. These callback events include stream readable events and stream writable events.

9. The method according to any one of claims 1 to 5, characterized in that, Sending the first QUIC message to the QUIC protocol stack includes: Hook the read event handling function of the target UDP port; The first QUIC message is sent to the QUIC protocol stack using the read event handling function.

10. An electronic device comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it causes the electronic device to implement the method as described in any one of claims 1 to 9.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 9.

Images