Request message scheduling method and device and readable storage medium

Abstract

The embodiment of the invention provides a request message scheduling method and device and a readable storage medium, under the condition that a terminal device establishes QUIC connection with a first edge node, after the first edge node receives a request message carrying a URL through the QUIC connection, if the URL carries a target field, a first CID bound with a second edge node is determined, and the first CID is sent to the second edge node; and sending the first CID to the terminal device. And after receiving the first CID, the terminal equipment initiates a subsequent message carrying the first CID through QUIC connection with the first edge node, the first edge node routes the subsequent message to the second edge node according to the first CID, and the second edge node replaces the first edge node to respond to the subsequent message. In the process migration process, the QUIC connection between the terminal equipment and the first edge node is kept uninterrupted, and 302 jump does not need to be executed, so that the dependence on terminal equipment behaviors in the subsequent message scheduling process is reduced, and the additional jump overhead is reduced.

Description

Technical Field

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

[0002] User Datagram Protocol (UDP) is a connectionless transport layer network protocol. Quick UDP Internet Connections (QUIC) is a UDP-based transport layer network protocol with features such as end-to-end encryption and multiplexing. It effectively improves application performance, reduces transmission latency, and enhances data transmission security, thus gaining widespread application.

[0003] In Content Delivery Network (CDN) and edge computing scenarios, services are typically deployed on edge nodes. User devices establish QUIC connections with these edge nodes, allowing them to send request messages to obtain the desired content, significantly improving access speed. When traffic scheduling is required, the edge nodes that have established QUIC connections with the devices typically use application-layer redirection to guide the devices to re-establish QUIC connections with other edge nodes and switch service requests to the new QUIC connections. The original QUIC connections can then be released or gradually phased out.

[0004] The application-layer redirection method described above relies heavily on the client's correct implementation of the redirection logic on the terminal device. However, due to differences in environment, version, and other factors, different terminal devices or clients can easily lead to redirection failures, which in turn cause traffic scheduling failures. Summary of the Invention

[0005] This application provides a request message scheduling method, device, and readable storage medium. During traffic migration, a first edge node determines a first CID bound to a second edge node and sends the first CID to a terminal device. This allows the terminal device to still initiate subsequent messages carrying the first CID through the QUIC connection with the first edge node. The first edge node routes the subsequent messages to the second edge node based on the first CID, without needing to perform a 302 redirect. This achieves traffic migration without relying on application-layer redirection mechanisms, thereby improving the success rate of traffic migration.

[0006] In a first aspect, embodiments of this application provide a request message scheduling method, applied to a first edge node in a content delivery network, the method comprising: Receive a request message carrying a URL from the terminal device via a QUIC connection with the terminal device; When the URL carries a target field, a first CID bound to a second edge node in the content delivery network is determined, the target field being used to indicate a request message to be scheduled; The first CID is sent to the terminal device via the QUIC connection; Receive subsequent messages carrying the first CID from the terminal device via the QUIC connection; The subsequent messages are routed to the second edge node based on the first CID.

[0007] Secondly, embodiments of this application provide a request message scheduling method, applied to a second edge node in a content delivery network, the method comprising: Identify subsequent packets routed to itself by the first edge node based on the first CID. The first CID is determined by the first edge node after receiving a request packet carrying a URL from the terminal device through a QUIC connection with the terminal device, and the URL carries a target field. The first CID is bound to the second edge node. Respond to the subsequent message.

[0008] Thirdly, embodiments of this application provide a request message scheduling method, applied to a terminal device, the method comprising: A request message carrying a URL is sent to a first edge node in the content delivery network via a QUIC connection, wherein the QUIC connection is a connection between the terminal device and the first edge node. When the URL contains a target field, the request message is used to enable the first edge node to determine a first CID bound to a second edge node in the content delivery network. Receive the first CID from the first edge node via the QUIC connection; The first edge node is then sent a subsequent message carrying the first CID via the QUIC connection.

[0009] Fourthly, embodiments of this application provide a request message scheduling device, which is integrated on a first edge node in a content delivery network. The request message scheduling device includes: The transceiver module is used to receive request messages carrying URLs from the terminal device via a QUIC connection with the terminal device. The determination module is used to determine a first CID bound to a second edge node in the content delivery network when the URL carries a target field, wherein the target field is used to indicate a request message to be scheduled; The transceiver module is also configured to send the first CID to the terminal device via the QUIC connection, and receive subsequent messages carrying the first CID from the terminal device via the QUIC connection. The processing module is used to route the subsequent packets to the second edge node based on the first CID.

[0010] Fifthly, embodiments of this application provide a request message scheduling device, which is integrated on a second edge node in a content delivery network. The request message scheduling device includes: The identification module is used to identify subsequent packets routed to itself by the first edge node based on the first CID. The first CID is determined by the first edge node after receiving a request packet carrying a URL from the terminal device through a QUIC connection with the terminal device, and the URL carries a target field. The first CID is bound to the second edge node. The processing module is used to respond to the subsequent messages.

[0011] Sixthly, embodiments of this application provide a request message scheduling device, which is integrated into a terminal device, and the request message scheduling device includes: The sending module is used to send a request message carrying a URL to a first edge node in the content delivery network via a QUIC connection, wherein the QUIC connection is a connection between the terminal and the first edge node, and when the URL contains a target field, the request message is used to enable the first edge node to determine a first CID bound to a second edge node in the content delivery network; The receiving module is configured to receive a first CID from the first edge node via the QUIC connection; The sending module is also configured to send a subsequent message carrying the first CID to the first edge node via the QUIC connection.

[0012] In a seventh 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; or, when the processor executes the computer program, it causes the electronic device to implement the method described in the second aspect or various possible implementations of the second aspect; or, when the processor executes the computer program, it causes the electronic device to implement the method described in the third aspect or various possible implementations of the third aspect.

[0013] Eighthly, 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; or, when executed by a processor, the computer instructions are used to implement the method described in the second aspect or various possible implementations of the second aspect; or, when executed by a processor, the computer instructions are used to implement the method described in the third aspect or various possible implementations of the third aspect.

[0014] Ninthly, embodiments of this application provide a computer program product comprising a computing program, wherein when the computer program is executed by a processor, it implements the method described in the first aspect or various possible implementations of the first aspect as described above; or, when the computer program is executed by a processor, it implements the method described in the second aspect or various possible implementations of the second aspect as described above; or, when the computer program is executed by a processor, it implements the method described in the third aspect or various possible implementations of the third aspect as described above.

[0015] The request message scheduling method, device, and readable storage medium provided in this application embodiment, when a terminal device establishes a QUIC connection with a first edge node, after the first edge node receives a request message carrying a URL through the QUIC connection, if the URL carries a target field used to indicate the request message to be scheduled, the first edge node determines a first CID bound to a second edge node and sends the first CID to the terminal device. After receiving the first CID, the terminal device still initiates subsequent messages carrying the first CID through the QUIC connection with the first edge node. The first edge node routes the subsequent messages to the second edge node according to the first CID, and the second edge node responds to the subsequent messages on behalf of the first edge node. This approach ensures uninterrupted QUIC connection between the terminal device and the first edge node during process migration, eliminating the need for 302 redirects. This allows the first and second edge nodes to accurately schedule subsequent packets at the data level, reducing reliance on terminal device behavior and minimizing additional redirection overhead. Consequently, subsequent packet scheduling can be achieved without relying on application-layer redirection mechanisms, improving routing correctness and stability in multi-region, multi-data center, cross-carrier, and multi-tenant parallel scenarios. Attached Figure Description

[0016] 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.

[0017] Figure 1 This is a schematic diagram of the network architecture to which the request message scheduling method provided in this application embodiment applies; Figure 2 This is a flowchart of a request message scheduling method provided in an embodiment of this application; Figure 3 This is another flowchart of the request message migration method provided in the embodiments of this application; Figure 4A This is a schematic diagram of a request message scheduling method provided in an embodiment of this application; Figure 4B This is another process diagram of the request message scheduling method provided in the embodiments of this application; Figure 5 This is another process diagram of the request message scheduling method provided in the embodiments of this application; Figure 6 This is a schematic diagram of a request message scheduling device provided in an embodiment of this application; Figure 7This is another schematic diagram of the request message scheduling device provided in the embodiments of this application; Figure 8 This is yet another schematic diagram of the request message scheduling device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] In modern internet CDN and edge computing scenarios, services are typically deployed in complex network environments spanning multiple regions, data centers, and carriers. To achieve proximity access, load balancing, fault isolation, and cost optimization, service requests need to be scheduled and migrated between different edge nodes. Traditional solutions typically use application-layer redirection to guide terminal devices to access new edge nodes, thereby completing traffic switching and aggregation. For example, a terminal device initially establishes a QUIC connection a with edge node 1 and accesses services based on this connection. Through application-layer redirection, edge node 1 guides the terminal device to establish a QUIC connection b with edge node 2, switching service requests to QUIC connection b, and the terminal device accesses services through QUIC connection b. QUIC connection a can be released or gradually phased out. For example, QUIC connection a can be disconnected after QUIC connection b is successfully established; or, QUIC connection a can be disconnected after coexisting with QUIC connection b for a period of time.

[0019] However, with the evolution of application forms and transmission protocols, the above-mentioned application layer redirection method has gradually revealed its limitations: On the one hand, this method relies on the client's correct implementation of the 302 redirection logic, but differences in different terminal devices, system components, or embedded browser versions may lead to redirection failure or inconsistent behavior, which in turn causes problems such as session interruption and experience fluctuations; on the other hand, application layer redirection requires the establishment of a new QUIC connection, thereby introducing additional connection establishment overhead, key negotiation overhead, and path verification overhead, which has a significant impact on low-latency and highly continuous interactive services.

[0020] Furthermore, in cross-regional or cross-carrier scenarios, the controllability of application-layer redirection paths is relatively weak, which may lead to business requests being rerouted and cross-network segment transmissions increasing, resulting in higher bandwidth costs and lower resource utilization.

[0021] With the widespread adoption of transport protocols such as QUIC, connection and session continuity increasingly relies on transport layer mechanisms for maintenance. QUIC supports multiplexing, connection identifier and address changes, making connection maintenance possible without altering application layer semantics. However, in actual CDN projects, business request migration typically involves two issues: first, how to determine which target edge node the business request should be migrated to; and second, how to maintain the continuity of the original connection context and session state during migration. Relying on application layer redirection to switch edge nodes can easily lead to session state loss or excessively high reconstruction costs. While relying on QUIC's built-in general connection migration mechanism can ensure uninterrupted connections, it doesn't know which target edge node to route the business request to and lacks rules for generating and verifying the ConnectionIdentifier (CID). Furthermore, it lacks scheduling rules for business requests specific to CDN scenarios and a collaborative binding mechanism between the CID and the target edge node for edge node switching scenarios.

[0022] Based on this, embodiments of this application provide a request message scheduling method, device, and readable storage medium. During traffic migration, a first edge node determines a first CID bound to a second edge node and sends the first CID to a terminal device, so that the terminal device still initiates subsequent messages carrying the first CID through the QUIC connection with the first edge node. The first edge node routes the subsequent messages to the second edge node according to the first CID. During the process migration, the QUIC connection between the terminal device and the first edge node is kept uninterrupted, and there is no need to execute a 302 redirect. Thus, traffic migration is achieved without relying on the application layer redirection mechanism, thereby improving the success rate of traffic migration.

[0023] Figure 1 This is a schematic diagram of the network architecture to which the request message scheduling method provided in this application applies. Please refer to... Figure 1 The network architecture includes a first edge node 11, a second edge node 12, and a terminal device 13. A QUIC connection 14, also known as a fast connection, is established between the terminal device 13 and the first edge node 11. A state synchronization channel 15 is established between the first edge node 11 and the second edge node 12. The first edge node 11 and the second edge node 12 are different edge nodes in the CDN. Edge nodes, also known as cache nodes, are the backbone and core working units of the CDN, widely distributed globally, used to pull and cache content from the origin server. This content includes, but is not limited to, videos, images, web pages, and software installation packages. Content cached at the edge nodes is referred to as cached files, cached resources, or business content.

[0024] Terminal device 13 can be a mobile phone, laptop, desktop computer, central control unit, etc. Applications such as a browser are installed on terminal device 13. After establishing a QUIC connection 14 between terminal device 13 and the first edge node 11, terminal device 13 initiates a request message through the application and sends the request message to the first edge node 11 through the QUIC connection 14. Normally, the first edge node 11 responds to the request message. If the first edge node 11 has cached the content requested by the request message, it directly responds to the user's request message; if the first edge node 11 has not cached the content requested by the request message, it retrieves it from the origin server (not shown in the figure). This application embodiment is applicable to request message scheduling scenarios, also known as traffic scheduling or traffic migration. In a traffic scheduling scenario, the first edge node 11 schedules request messages according to a preset routing strategy. The preset routing strategy indicates the target field; if the URL carried by the request message contains the target field, it indicates that the request message needs to be scheduled. The target field is the complete target URL, a partial field of the target URL, or a regular expression that matches the target URL.

[0025] Taking the target URL https: / / example.com / a / b.flv?c=1&d=2 as an example, in one approach, the target field is the entire target URL. In another approach, the target field is https: / / example.com / a / b.flv. In yet another approach, the target field is a regular expression: https: / / example.com / a / .*.flv$, which means that all URLs starting with https: / / example.com / a / and ending with .flv are considered a match.

[0026] After receiving a request message carrying a URL, and the URL carrying a target field, the first edge node 11 determines the second edge node 12 from the CDN based on the URL, and generates a first CID based on the second edge node 12, thus obtaining the CID bound to the second edge node 12. Then, the first edge node 11 synchronizes the session state information of the QUIC connection 14 to the second edge node 12. In addition, the first edge node 11 also forwards the request message or its service processing information to the second edge node 12. Upon receiving the session state information and the request message, the second edge node 12 performs session recovery or state alignment based on the session state information, and then responds to the request message on behalf of the first edge node 11, thereby migrating the request message traffic from the first edge node 11 to the second edge node 12.

[0027] In addition, the first edge node 11 also sends the first CID to the terminal device 13. After receiving the first CID, the terminal device 13 initiates a request message carrying the first CID. For clarity, the request message initiated by the first edge node 11 after receiving the first CID will be referred to as a subsequent message. Obviously, the subsequent message is a request message, not an ACK message. It can be understood that the only difference between the subsequent message and the request message is that the request message does not carry the first CID but carries the initial CID, while the subsequent message carries the first CID but does not need to carry the initial CID. The initial CID is the CID bound to the first edge node. That is to say, before the first edge node 11 determines the first CID, the message initiated by the terminal device 13 is called a request message. After the first edge node 11 determines the first CID and sends the first CID to the terminal device 13, the request message initiated by the terminal device 13 is called a subsequent message. The difference between the subsequent message and the ACK message is that the ACK message does not carry the URL, while the subsequent message carries the URL. Upon receiving a subsequent message, if the URL carried by the subsequent message contains a target field or meets the requirements of the target field, the first edge node 11 routes the subsequent message to the second edge node 12 based on the first CID. If the URL carried by the subsequent message does not contain a target field or does not meet the requirements of the target field, even if the subsequent message carries the first CID, the first edge node 11 does not route the subsequent message; instead, the first edge node 11 responds to the subsequent message itself. Furthermore, before routing the subsequent message to the second edge node 12 based on the first CID, the first edge node 11 verifies the first CID. Only if the first CID passes verification will the first edge node 11 route the subsequent message to the second edge node 12 based on the first CID.

[0028] It should be noted that although this example illustrates how the first edge node 11 first determines whether the URL carried in subsequent messages contains the target field or meets the requirements of the target field, and then verifies the first CID, this embodiment is not limited to this. In other feasible implementations, the first edge node 11 can also verify the first CID first. Only if the first CID passes verification will it determine whether the URL carried in subsequent messages contains the target field or meets the requirements of the target field.

[0029] It should be understood that, Figure 1 The number of terminal devices 13 and edge nodes (including the first edge node 11 and the second edge node 12) shown in the diagram is merely illustrative. In actual implementation, any number of terminal devices 13 and edge nodes can be deployed according to actual needs.

[0030] Furthermore, the embodiments of this application do not limit the direction of traffic migration. For example, traffic can be migrated from the first edge node 11 to the second edge node 12, or traffic can be migrated from the second edge node 12 to the first edge node 11.

[0031] The request message scheduling method described in the embodiments of this application will now be described in detail. For example, please refer to... Figure 2 , Figure 2 This is a flowchart of a request message scheduling method provided in this application embodiment. This embodiment is described from the perspective of the interaction between the terminal device, the first edge node, and the second edge node. This embodiment includes: 201. The terminal device sends a request message carrying a URL to the first edge node in the content delivery network via a QUIC connection.

[0032] Accordingly, the first edge node receives a request message carrying a URL from the terminal device via a QUIC connection with the terminal device. When the URL contains a target field, the request message is used to enable the first edge node to determine a first CID bound to a second edge node in the content delivery network.

[0033] In this embodiment, when a QUIC connection is established between the terminal device and the first edge node, the terminal device initiates a request message to the first edge node through the QUIC connection. The request message is also known as a service request, QUIC message, or QUIC request message. The request message carries a URL, used to request the service content corresponding to the URL, such as images, video clips, installation packages, or application programming interfaces (APIs).

[0034] In this embodiment of the application, when a QUIC connection is established between the terminal device and the first edge node, all subsequent request messages initiated by the terminal device are directed to the first edge node, that is, they are all sent to the first edge node through the QUIC connection.

[0035] 202. When the URL carries a target field, the first edge node determines a first CID bound to the second edge node in the content delivery network, and the target field is used to indicate the request message to be scheduled.

[0036] In this embodiment, a routing policy is pre-configured on the first edge node, and the routing policy indicates the target field. If a request message carries a URL that contains the target field or meets the requirements of the target field, it indicates that the request message is a request message to be scheduled. The target field may be, for example, the complete target URL, a partial field of the target URL, or a regular expression. If a request message carries a URL that does not contain the target field or does not meet the requirements of the target field, it indicates that there is no need to schedule the request message, and the first edge node itself responds to the request message.

[0037] After receiving the request message, the first edge node parses the URL from the request message and further determines whether the URL contains the target field or meets the requirements of the target field. If the URL contains the target field or meets the requirements of the target field, the second edge node is determined from the CDN, and a first CID is generated based on the second edge node, thus obtaining the first CID bound to the second edge node.

[0038] 203. The first edge node sends the first CID to the terminal device via the QUIC connection.

[0039] Accordingly, the terminal device receives a first CID from the first edge node via a QUIC connection. This first CID carries an identification field of the second edge node. The identification field includes, for example, the second edge node's serverID and address.

[0040] 204. The terminal device sends a subsequent message carrying the first CID to the first edge node via the QUIC connection.

[0041] Accordingly, the first edge node receives subsequent messages from the terminal device carrying the first CID via the QUIC connection.

[0042] In this embodiment, after receiving the first CID, the terminal device initiates a request message again. That is, when initiating subsequent messages, the initial CID is replaced with the first CID, so that subsequent messages carry the first CID. However, the subsequent messages carrying the first CID are still sent through the QUIC connection with the first edge node. That is, compared with the request message, the entry point of the subsequent messages has not changed and is still the first edge node.

[0043] 205. The first edge node routes the subsequent packets to the second edge node based on the first CID.

[0044] After receiving subsequent packets, the first edge node parses out the first CID from the subsequent packets, parses out the identifier field of the second edge node from the first CID, and routes the subsequent packets to the second edge node based on the identifier field.

[0045] In this embodiment of the application, the first edge node can route the entire subsequent message to the second edge node, or it can only route the service processing information of the subsequent message to the second edge node.

[0046] 206. Response to subsequent messages.

[0047] After receiving subsequent messages, the second edge node responds to the subsequent messages based on the session state information of the QUIC connection, the subsequent messages, or the service processing information of the subsequent messages.

[0048] In this embodiment, the second edge node obtains the session state information of the QUIC connection provided by the first edge node through a state synchronization channel with the first edge node. In addition to synchronizing the session state information to the second edge node, the first edge node also forwards the request message or its service processing information from step 201 to the second edge node, enabling the second edge node to accept the request message based on the session state information and its service processing information. The first edge node also forwards the subsequent message or its service processing information from step 204 to the second edge node, enabling the second edge node to accept the subsequent message based on the session state information and its service processing information.

[0049] This application does not limit the method by which the first edge node forwards subsequent messages or their service processing information to the second edge node. For example, when a pre-established state synchronization channel exists between the first and second edge nodes, the first edge node reuses the state synchronization channel to forward subsequent messages or their service processing information to the second edge node. Alternatively, when no state synchronization channel exists between the first and second edge nodes, the first and second edge nodes establish a state synchronization channel as needed, and the first edge node forwards subsequent messages or their service processing information to the second edge node through this channel. The state synchronization channel is also known as an internal communication channel or internal communication link.

[0050] The request message scheduling method provided in this application embodiment, when a terminal device establishes a QUIC connection with a first edge node, after the first edge node receives a request message carrying a URL through the QUIC connection, if the URL carries a target field used to indicate the request message to be scheduled, the first edge node determines a first CID bound to a second edge node and sends the first CID to the terminal device. After receiving the first CID, the terminal device still initiates subsequent messages carrying the first CID through the QUIC connection with the first edge node. The first edge node routes the subsequent messages to the second edge node according to the first CID, and the second edge node responds to the subsequent messages on behalf of the first edge node. This approach ensures uninterrupted QUIC connection between the terminal device and the first edge node during process migration, eliminating the need for 302 redirects. This allows the first and second edge nodes to accurately schedule subsequent packets at the data level, reducing reliance on terminal device behavior during packet scheduling and minimizing additional redirection and connection establishment overhead. Consequently, it enables packet scheduling without relying on application-layer redirection mechanisms, improving routing correctness and stability in multi-region, multi-datacenter, cross-carrier, and multi-tenant parallel scenarios.

[0051] In this embodiment, the first edge node needs to provide the second edge node with the session state information of the QUIC connection. This embodiment does not limit the method by which the first edge node provides the session state information to the second edge node, nor does it limit whether a connection is established between the first and second edge nodes or what protocol version is used. It only needs to ensure that a state synchronization channel is established between the first and second edge nodes to synchronize the session state information of the QUIC connection. The state synchronization channel, also known as an information exchange channel, internal communication channel, or internal communication link, is used to transmit the session state information of the QUIC connection. The second edge node takes over the QUIC based on the session state information. Additionally, the first edge node can also forward request messages or request message processing information to the second edge node through the state synchronization channel. Furthermore, the terminal device may initiate subsequent messages multiple times. Each time the first edge node receives a subsequent message, if the URL carried in the subsequent message contains a target field or meets the requirements of the target field, the first edge node forwards the subsequent message or its processing information to the second edge node through the state synchronization channel.

[0052] This approach provides the QUIC connection's session state information to the second edge node, enabling the second edge node to take over the QUIC connection and respond to request messages and subsequent messages on behalf of the first edge node. This allows the first and second edge nodes to accurately schedule request messages at the data level, reducing reliance on terminal device behavior during request message scheduling and minimizing additional hop overhead. As a result, request message scheduling can be achieved without relying on application-layer hop mechanisms.

[0053] The status synchronization channel will now be explained in detail.

[0054] In one approach, a direct connection is established between the first edge node and the second edge node. However, this connection is not a QUIC connection, but rather a Transmission Control Protocol (TCP) connection, a Remote Procedure Call (RPC) connection, a Hypertext Transfer Protocol Version 2 (HTTP / 2) connection, etc. The TCP connection, RPC connection, or HTTP / 2 connection serves as a state synchronization channel.

[0055] In another approach, a direct connection is not required between the first and second edge nodes. The first edge node writes session state information to a shared database, creates a state synchronization channel based on the shared database, and provides the QUIC connection's session state information to the second edge node through this state synchronization channel. The shared database can be, for example, a remote dictionary server (Redis), a key-value (KV) in-memory database, or a self-built state data management middleware within the enterprise. A sharing mechanism is created at the system level through the shared database in the CDN, and a state synchronization channel is formed based on this sharing mechanism.

[0056] This approach eliminates the need for direct connections between the first and second edge nodes. Instead, it synchronizes session state information through a shared database, reducing the overhead of establishing connections between edge nodes. Furthermore, it efficiently synchronizes session state information via a state synchronization channel, thereby improving the reliability of request message scheduling.

[0057] In another approach, a QUIC connection is established between the first edge node and the second edge node, and the QUIC connection is used as a state synchronization channel.

[0058] Optionally, after the first edge node initially determines the first CID, it also sets an expiration date for the first CID. This way, if subsequent packets carry a URL and the URL contains a target field or meets the requirements of the target field, the first edge node determines whether the first CID is still valid. If the first CID has not expired, the subsequent packets are directly scheduled to the second edge node. If the first CID has expired, a new first CID is determined.

[0059] Similarly, the first edge node can also set an expiration time for the session state information. Only when the session state information is valid will subsequent packets be scheduled to the second edge node; otherwise, the first edge node will provide the QUIC connection session state information to the second edge node again.

[0060] In this embodiment, a routing policy is pre-configured on the first edge node. This routing policy indicates a target field, which can be a complete target URL, a partial field of the target URL, or a regular expression matching the target URL. Continuing with the example of a target URL of https: / / example.com / a / b.flv?c=1&d=2, when the target field is a complete target URL, after the first edge node obtains the first CID and schedules the request message to the second edge node so that the second edge node responds to the request message on behalf of the first edge node, if a subsequent message initiated by the terminal device carries a URL and that URL is a complete target URL, the first edge node will schedule the subsequent message to the second edge node. However, if the URL carried by the subsequent message is https: / / example.com / a / b.flv?e=3&f=4, since this URL does not contain a target field, the first edge node itself responds to the request message.

[0061] Continuing with the example of the target URL https: / / example.com / a / b.flv?c=1&d=2, when the target field is https: / / example.com / a / b.flv, meaning the target field is a part of the target URL, if the subsequent message initiated by the terminal device carries the URL https: / / example.com / a / b.flv?e=3&f=4, since this URL contains the target field, the first edge node will schedule the subsequent message to the second edge node.

[0062] Continuing with the example of a target URL of https: / / example.com / a / b.flv?c=1&d=2, when the target field is the regular expression "https: / / example.com / a / .*.flv$", assuming the first edge node initially receives a request message carrying the URL https: / / example.com / a / b.flv?e=3&f=4, since this URL does not conform to the regular expression, the first edge node does not schedule this request message but responds to it itself. However, if the request message initiated by the terminal device carries the URL https: / / example.com / a / video / live_2026.flv, since this URL conforms to the regular expression, the first edge node determines the first CID and schedules the request message to the second edge node, allowing the second edge node to respond to the request message on behalf of the first edge node.

[0063] It is understandable that multiple subsequent packets can be sent concurrently over the same QUIC connection, and these subsequent packets share the same protocol context of the QUIC connection. Assuming these subsequent packets carry different URLs, if the first edge node determines different second edge nodes for different subsequent packets, i.e., schedules different subsequent packets to different second edge nodes, connection-level state splitting can easily occur, leading to conflicts in packet numbering, ACK processing, flow control, and encryption context. Therefore, when the same QUIC connection carries multiple subsequent packets carrying different URLs, if these subsequent packets are concurrent requests, the dominant service is determined from the multiple subsequent packets, the second edge node is determined based on the dominant service, and all subsequent packets are scheduled to the same second edge node. Concurrent scenarios include, but are not limited to, watching videos, watching live streams, downloading large files, and batch API calls. The dominant service refers to the subsequent packet among the multiple concurrent subsequent packets that has the highest priority, highest business value, largest data volume, longest duration, highest bandwidth usage, or highest preset priority. Here's an example of a first edge node deciding on different second edge nodes for different follow-up messages: Target field 1 is https: / / www.example.com / index.html, and target field 2 is https: / / www.example.com / about.html. Multiple concurrent follow-up messages include a follow-up message carrying URLa and a follow-up message carrying URLb. URLa is https: / / www.example.com / index.html, and URLb is https: / / www.example.com / about.html. The first edge node determines second edge node A for the follow-up message carrying URLa and second edge node B for the follow-up message carrying URLb. However, since URLa has the highest priority, the first edge node schedules both the follow-up message carrying URLa and the follow-up message carrying URLb to second edge node A. Alternatively, the first edge node schedules the follow-up message carrying URLa to second edge node A, but does not schedule the follow-up message carrying URLb; instead, it responds to the follow-up message carrying URLb itself.

[0064] If these subsequent messages are sequential, for example, target field 1 is https: / / www.example.com / index.html, target field 2 is https: / / www.example.com / about.html, the first subsequent message carries URLa, and the second subsequent message carries URLb, where URLa is https: / / www.example.com / index.html and URLb is https: / / www.example.com / about.html. This causes the first edge node to determine the second edge node A for the subsequent message carrying URLa and the second edge node B for the subsequent message carrying URLb. In this case, the first edge node will schedule the subsequent message carrying URLa to the second edge node A and the subsequent message carrying URLb to the second edge node B. However, at any given time, only one subsequent message can be migrated to the same second edge node.

[0065] It's understandable that, regardless of whether multiple subsequent packets are concurrent or sequential, in many implementation scenarios, the URLs of each subsequent packet carried by the same QUIC connection are business-related. These URLs correspond to the same URL rules or policy ranges, and the decisions are made within the same business scope. Therefore, regardless of whether these subsequent packets are concurrent or sequential, the routing range corresponding to the same CID can be reused. That is, if these URLs contain the same target fields or meet the requirements of the same target fields, then regardless of whether multiple subsequent packets are concurrent or sequential, they will be scheduled to the same second edge node. However, there is also a scenario where the URL of one or more subsequent packets contains different target fields than the URL of the request packet, or the URL of the subsequent packet and the URL of the request packet meet the requirements of different target fields. In other words, the URL of the subsequent packet corresponds to a different CID, and this CID is different from the first CID. In this case, the first edge node itself responds to the subsequent packets or re-executes scheduling and generates a new CID, i.e., the second CID. The second CID is used to indicate a new edge node, i.e., the third edge node.

[0066] Optionally, in the above embodiments, during the process of the second edge node responding to the subsequent message, the second edge node first completes session recovery and state alignment based on the session state information to process the subsequent message and obtain a first response message. Then, the second edge node sends the first response message to the terminal device.

[0067] For example, after obtaining the session state information of the QUIC connection, the second edge node performs session recovery and state alignment based on the session state information, including encryption context and flow control status, thereby taking over the QUIC connection without emphasizing a full context migration. The session state information, also known as QUIC connection state information, indicates the minimum necessary set of states required for QUIC connection continuity. This minimum necessary set of states includes session recovery information, key identifier KeyID, CID mapping relationship, and necessary packet number (PN). Session recovery information includes, for example, a session ticket or its index. Afterward, the second edge node processes subsequent packets to generate a first response packet and sends it to the terminal device.

[0068] This approach enables rapid state alignment and QUIC connection takeover based on session state information, eliminating the need for connection establishment and key negotiation with terminal devices. This reduces latency and interaction overhead, ensuring service continuity during traffic scheduling.

[0069] Figure 3 This is another flowchart of the request message migration method provided in this application embodiment. This embodiment includes the following steps: 301. The terminal device sends a request message carrying a URL to the first edge node in the content delivery network via a QUIC connection.

[0070] Accordingly, the first edge node receives a request message carrying a URL from the terminal device via a QUIC connection with the terminal device.

[0071] For details, please refer to the above. Figure 2 The description of step 201 will not be repeated here.

[0072] 302. When the URL carries a target field, the first edge node determines the first CID bound to the second edge node in the content delivery network. The target field is used to indicate the request message to be scheduled.

[0073] For details, please refer to the above. Figure 2 The description of step 202 will not be repeated here.

[0074] 303. The first edge node sends the first CID to the terminal device via a QUIC connection.

[0075] Accordingly, the terminal device receives a first CID from the first edge node. This first CID carries an identification field of the second edge node. The identification field may include, for example, the second edge node's serverID, address, etc.

[0076] 304. The terminal device sends a response message carrying the first CID to the first edge node via the QUIC connection. The response message is used to indicate that the terminal device has received the first CID.

[0077] After receiving the first CID, the terminal device sends an acknowledgment (ACK) message to the first edge node. Upon receiving the ACK message, the first edge node determines that the terminal device has completed the reception and confirmation of the first CID, and that subsequent messages initiated by the terminal device carry the first CID, not the initial CID. The acknowledgment message carries the first CID, which encodes the identification field of the second edge node mentioned in step 302, such as the second edge node's identity identifier (ServerID) and address (ServerAddr). After receiving the ACK message, the first edge node forwards the request message or its service processing information to the second edge node, thus scheduling the request message to the second edge node. Similarly, the first edge node forwards subsequent messages or their service processing information to the second edge node, thus scheduling the subsequent messages to the second edge node.

[0078] 305. The first edge node provides the second edge node with the session state information of the QUIC connection.

[0079] For details, please refer to the above description of the session state information of the first edge node providing QUIC connection to the second edge node, which will not be repeated here.

[0080] 306. The second edge node responds to the request message based on the session state information.

[0081] For details, please refer to the above. Figure 2 The description of step 206 will not be repeated here.

[0082] 307. The terminal device sends a subsequent message carrying the first CID to the first edge node via the QUIC connection.

[0083] It is understood that the embodiments of this application do not limit the order of steps 306 and 307.

[0084] 308. The first edge node routes subsequent packets to the second edge node based on the first CID.

[0085] Upon receiving a subsequent message, if the URL carried by the subsequent message contains a target field or meets the requirements of the target field, the first edge node routes the subsequent message to the second edge node based on the first CID. If the URL carried by the subsequent message does not contain a target field or does not meet the requirements of the target field, even if the subsequent message carries the first CID, the first edge node does not route the subsequent message; instead, the first edge node responds to the subsequent message itself. Furthermore, before routing the subsequent message to the second edge node based on the first CID, the first edge node verifies the first CID. Only if the first CID passes verification will the first edge node route the subsequent message to the second edge node based on the first CID.

[0086] It should be noted that although this example illustrates the process of the first edge node determining whether the URL carried in subsequent messages contains the target field or meets the requirements of the target field before verifying the first CID, this embodiment is not limited to this. In other feasible implementations, the first edge node can also verify the first CID first. Only if the first CID passes verification is the determination made regarding whether the URL carried in subsequent messages contains the target field or meets the requirements of the target field.

[0087] 309. The second edge node responds with subsequent messages.

[0088] The request message initiated by the terminal device after sending a response message is called a subsequent message. This subsequent message carries a first CID. The first edge node identifies and forwards the subsequent message based on the identifier field in the first CID. Thus, without modifying the IP address, port, or performing application-layer redirection, the subsequent message can be scheduled to the second edge node simply by updating the initial CID to the first CID, and the QUIC connection between the terminal device and the first edge node remains uninterrupted during the scheduling process. The initial CID is the CID carried in the request message initiated by the terminal device in step 301, and can be considered as a CID bound to the first edge node.

[0089] In this embodiment, after receiving the first CID, the terminal device subsequently initiates ACK packets and subsequent packets, using the first CID instead of the initial CID while maintaining the QUIC connection. This allows the first edge node to accurately complete targeted forwarding and failure rollback at the data level, reducing the dependence on the terminal device's behavior during request packet scheduling. This achieves smooth migration of request packets without relying on application-layer jump mechanisms. Targeted forwarding refers to forwarding the request packet or its service processing information, subsequent packets, or their service processing information in step 301, as detailed above. Figure 2The description of how the first edge node forwards subsequent messages or the service processing information of such subsequent messages to the second edge node in step 206 will not be repeated here.

[0090] This approach utilizes CID updates to perform traffic scheduling while ensuring uninterrupted QUIC connections between the terminal device and the first edge node during the scheduling process. Furthermore, upon confirming that the terminal device has received the first CID, session state information synchronization and traffic scheduling are performed to prevent routing errors caused by state inconsistencies, thereby improving the success rate of request packet scheduling.

[0091] The following section provides a detailed explanation of how the first edge node determines the first CID.

[0092] In this embodiment, after the first edge node parses the URL in the request message, it continues to parse the URL. If the URL carries a target field, the identity identifier (serverID) and address (serverAddr) of the second edge node are determined based on the target field. Then, the first edge node determines the first CID based on the identity identifier of the second edge node, etc. The first CID is bound to the second edge node using structured field encoding. Optionally, the first CID carries a verification field, etc. The first CID contains at least one of the following fields: a. Version field (Version, Ver) indicates the encoding format version of the first CID.

[0093] b. The business domain field is used to identify the tenant or business domain, preventing cross-domain reuse and resulting crosstalk or incorrect routing. Business domains include, but are not limited to, short video business domains, web access business domains, etc.

[0094] c. Identification fields, used to indicate the second edge node, such as the identity identifier (ServerID) and address (ServerAddr) of the second edge node.

[0095] d. The expiration field indicates the effective time window or expiration time of the first CID, to avoid long-term misrouting caused by the expiration of the first CID.

[0096] e. The nonce field or sequence (seq) field is used to prevent duplicates.

[0097] f. The Integrity Tag field is used to verify the integrity of the first CID, protecting it from forgery or tampering. The Integrity Tag field is generated based on a pre-shared key or key identifier, etc.

[0098] As described above, the first CID in this embodiment is not simply address information, but is generated according to preset generation rules and includes at least an identifier field. In addition to fields a to f, the first CID may also include a key identifier. By carrying identifier fields, domain isolation fields, and integrity label fields in the first CID, it acquires the attributes of being tamper-proof and unforgeable, thereby ensuring that subsequent messages carrying the first CID or their service processing information can only be routed to the corresponding second edge node.

[0099] After the first edge node determines the first CID, it sends the first CID bound to the second edge node to the terminal device via a QUIC connection to trigger traffic scheduling, i.e., the scheduling of request packets. This mechanism ensures that traffic scheduling is applied at the URL level, rather than just at the domain level, thus forming URL-level scheduling for feasible CDN services.

[0100] Optionally, during the process of the first edge node routing subsequent packets to the second edge node based on the first CID, the first edge node parses the first CID in the subsequent packets to obtain a verification field and an identification field of the second edge node. The verification field includes at least one of the following fields: an integrity label field, a service domain field, or a validity period field. Then, the first edge node verifies the first CID based on the verification field. If the first CID passes the verification field verification, the subsequent packets are routed to the second edge node based on the identification field.

[0101] For example, after receiving a subsequent message carrying the first CID, the first edge node performs integrity verification, domain isolation verification, and validity period verification on the first CID. Specifically, the integrity verification involves verifying the value of the integrity tag field in the first CID; if the verification fails, the request message is not scheduled.

[0102] Domain isolation verification: This checks whether the value of the business domain field in the first CID matches the value of the entry domain. If they match, the request message is scheduled; otherwise, the request message is rejected. The entry domain refers to the business domain carried in the request message initiated by the terminal device via the QUIC connection.

[0103] Validity verification: The first edge node determines whether the reception time of subsequent messages carrying the first CID is within the effective time window indicated by the validity period field. If the reception time is within the effective time window, the subsequent message is scheduled; if the reception time is not within the effective time window, it means that the first CID has expired, and the subsequent message is refused to be scheduled, that is, the subsequent message is refused to be scheduled to the second edge node.

[0104] This approach utilizes a verification field to validate the first CID, ensuring its validity. If the first CID passes the verification, subsequent packets are scheduled to the second edge node. This eliminates the need for application-layer redirection in traffic scheduling, thereby reducing interaction pressure while improving routing accuracy and stability.

[0105] Optionally, in the above embodiments, under preset conditions, the first edge node determines a third edge node from the content delivery network and determines a second CID bound to the third edge node. The preset conditions include: the first CID fails the verification of the verification field, the subsequent message does not reach the second edge node, or the second edge node is abnormal. Then, the first edge node sends the second CID to the terminal device via a QUIC connection. After receiving the second CID, the terminal device sends a response message carrying the second CID to the first edge node via the QUIC connection. For details regarding the determination method of the second CID and the fields included in the second CID, please refer to the description of the first field above; it will not be repeated here.

[0106] In this embodiment of the application, in order to further ensure that the request message is routed to the correct second edge node, a fallback mechanism is also set for the following types of requests.

[0107] Scenario 1: First CID verification fails and rollback occurs.

[0108] When the first edge node detects that the first CID fails integrity verification, domain isolation verification, or validity verification, it will not schedule subsequent packets to the second edge node based on the first CID. Instead, it will trigger a rerouting decision. That is, the first edge node will re-determine the edge node based on the target field contained in the URL; this will be referred to as the third edge node. After determining the third edge node, the first edge node will determine the second CID bound to it and send it to the terminal device through a connection identifier update mechanism. Upon receiving the second CID, the terminal device will send a response packet carrying the second CID to the first edge node, causing the second edge node to route subsequent packets to the third edge node based on the second CID. The connection identifier update mechanism refers to the first edge node sending the second CID generated based on the rerouting decision to the terminal device through a QUIC connection with the terminal device, so that the terminal device carries the second CID in subsequent packets.

[0109] When the first CID fails integrity verification or domain isolation verification, in addition to the rerouting strategy, the first edge node can also return a controllable retry indication to the terminal device, so that the terminal device can re-initiate subsequent packets; or, so that the terminal device can re-acquire a usable CID and re-initiate subsequent packets. The retry indication can be a display protocol indication, application layer prompt, connection control signal, or preset error code, etc., and is not limited in this embodiment. In some embodiments, the terminal device can automatically initiate a retry after receiving the retry indication. For terminal devices with human-computer interaction capabilities, a retry can also be initiated after user confirmation.

[0110] Case 2: The second edge node is unreachable and a rollback is possible.

[0111] When the first edge node discovers that the second edge node is unreachable or abnormal while scheduling subsequent packets, it triggers a rerouting decision and issues a second CID, provided that the business policy is satisfied, to ensure that the session can continue to be processed. For a description of the rerouting decision, please refer to Case 1 above; it will not be repeated here.

[0112] This approach allows for a fallback in cases of first CID verification failure, expiration, or second edge node unreachability, routing subsequent packets to the third edge node. This avoids the risks of misrouting and crosstalk caused by terminal differences, dynamic adjustments to routing policies, cluster scaling, or multi-tenant parallel operation. It also reduces the overhead of additional interaction and connection reconstruction during the scheduling process, improving the correctness, stability, and maintainability of URL-granular traffic scheduling.

[0113] Optionally, in the above embodiments, after the second edge node receives the first response message in response to subsequent messages, in one approach, the second edge node sends the first response message to the first edge node. After receiving the first response message, the first edge node encapsulates the first response message according to its own communication address to obtain a second response message. Then, the first edge node provides the second response message to the terminal device.

[0114] In this approach, the first response message obtained by the second edge node in response to subsequent messages reaches the terminal device through the first edge node. To ensure the terminal device continues to communicate with the first edge node, the first edge node, after obtaining the first response message based on a shared database, encapsulates its own communication address into the first response message to obtain a second response message. This encapsulation process is also known as packet consistency processing, which includes entry address consistency processing, session association representation maintenance, and necessary message forwarding. Afterward, the first edge node sends the second response message to the terminal device via a QUIC connection.

[0115] Figure 4AThis is a schematic diagram of a request message scheduling method provided in an embodiment of this application. Please refer to... Figure 4A The first edge node includes a QUIC parsing module, a routing decision module, a session management module, a verification and forwarding module, a session state alignment module, and a return packet consistency processing module. The functions of each module are described in detail below.

[0116] The QUIC parsing module is used to parse request messages carrying URLs received from terminal devices via a QUIC connection to extract the URL, initial CID, business domain identifier, etc. Additionally, the QUIC parsing module is also responsible for parsing subsequent messages to obtain the first CID, etc.

[0117] In the routing decision module, when the URL contains a target field, the QUIC parsing module inputs the URL into the routing decision module. The routing decision module determines the second edge node based on the routing strategy and calculates the identity identifier (serverID), address (serverAddr), etc., of the second edge node. The routing strategy includes, but is not limited to, exact URL matching, prefix matching, regular expression rule matching, or parameter feature matching, and can be combined with load status, cost strategy, or regional operator strategy.

[0118] The session management module is used to determine the first CID bound to the second edge node according to the CID generation rules, maintain the binding relationship between the first CID and the second edge node, and control the lifecycle of the first CID. In addition, the session management module also generates QUIC control information for connection identifier updates and sends the first CID in the QUIC control information to the terminal device. After receiving the QUIC control information carrying the first CID, subsequent packets initiated by the terminal device carry the first CID, and subsequent packets are still sent through the QUIC connection without requiring application-layer redirection, thus achieving seamless migration preparation on the client side.

[0119] The verification and forwarding module is used to perform integrity verification, domain isolation verification, and validity period verification on the first CID after receiving subsequent packets carrying the first CID. Based on the identity identifier parsed from the first CID, the module schedules the subsequent packets to the second edge node. This eliminates the need to rely on application layer redirection logic and the need for the terminal device to be aware of the routing switch. Directed forwarding can be completed at the data level based solely on the first CID, thereby ensuring that subsequent packets are routed to the correct second edge node.

[0120] The session state alignment module is used to provide the second edge node with session state information of the QUIC connection in the scheduling scenario. This session state information includes, for example, the minimum necessary set of states required to take over the QUIC connection.

[0121] The response consistency processing module is used to perform response consistency processing on the first response message provided by the second edge node. That is, it encapsulates the communication address of the first edge node into the first response message to obtain the second response message, and returns the second response message to the terminal device, so that the terminal device can maintain communication with the first edge node in terms of perception.

[0122] Optional, Figure 4A In this module, a shared database is established between the session state alignment module and the second edge node. When the first edge node provides session state information to the second edge node, it writes the session state information into the shared database, creates a state synchronization channel based on the shared database, and provides the QUIC connection session state information to the second edge node through the state synchronization channel.

[0123] In this scheme, the first edge node encapsulates the first response message to obtain the second response message and then sends it to the terminal device, so that the terminal device can maintain communication with the first edge node in terms of perception and realize seamless scheduling of subsequent messages.

[0124] In another approach, the second edge node encapsulates the first response message based on the communication address of the first edge node to obtain a second response message. Then, the second edge node sends the second response message to the terminal device.

[0125] Figure 4B This is another schematic diagram of the request message scheduling method provided in this application embodiment. Figure 4A The difference is, Figure 4B The first edge node shown does not include a return packet consistency processing module. In this approach, the first edge node does not need to relay the first response message. Instead, the second edge node actively encapsulates the first response message into a second response message and sends it to the terminal device. This ensures that the terminal device still perceives that it is communicating with the first edge node, enabling seamless scheduling of subsequent messages.

[0126] Figure 5 This is another schematic diagram of the request message scheduling method provided in this application embodiment. In this embodiment, the video-on-demand service is deployed on edge nodes in multiple regions, taking the scheduling of cross-regional cost-optimized video-on-demand service as an example. In this embodiment, the first edge node and the second edge node include an eXpress Data Path (XDP) module, a traffic detection module, a session module, and a Service Controller (SC) module, wherein the traffic detection module is also called the shark module, and the session module is also called the Mamba module. Please refer to... Figure 4AThe XDP module is equivalent to the verification and forwarding module; the shark module is equivalent to the sum of the QUIC parsing module, session management module, and session state alignment module; and the Mamba module is equivalent to the routing decision module. The SC module is used to control the shark module, etc. The SC module is not shown in the first edge node. This embodiment includes the following steps: 501. The terminal device sends a request message carrying URLa through the QUIC connection.

[0127] After receiving a request message carrying a URL from the terminal device, the traffic detection module of the first edge node parses the request message to extract the URL, initial CID, business domain identifier, etc. The address of the first edge node is, for example, 1.1.1.1.

[0128] 502. The traffic detection module of the first edge node sends a query request to the session module.

[0129] After receiving the query request, the session module, assuming the URL contains a target field, determines the second edge node based on the routing policy and calculates the second edge node's identity (serverID), address (serverAddr), etc. The IP address of the second edge node is 1.1.3.1.

[0130] 503. The session module of the first edge node sends a query response to the traffic detection module.

[0131] The query response carries the IP address of the second edge node, 1.1.3.1. The traffic detection module also generates a first CID bound to the second edge node.

[0132] 504. The traffic detection module of the first edge node sends QUIC control information for connection identifier update to the terminal device.

[0133] The QUIC control information carries a first CID, which in turn carries the IP address of the second edge node, 1.1.3.1. Examples of QUIC control information include the new_connection_id frame.

[0134] 505. The terminal device sends a response message carrying the first CID to the first edge node.

[0135] 506. The traffic detection module of the first edge node synchronizes the session state information of the QUIC connection to the second edge node.

[0136] Session state information is used to enable the second edge node to reset the state of the QUIC connection, including but not limited to the private key, sessionTicket, first CID, PN, and the address of the terminal device.

[0137] 507. The traffic detection module of the second edge node sends a second response message to the terminal device.

[0138] For example, after the second edge node receives the first response message in response to the request message, it encapsulates the communication address of the first edge address, etc., into the first response message to obtain the second response message, and then... Figure 4B Send it to the terminal device in the manner shown.

[0139] 508. The terminal device sends a response message carrying the first CID to the first edge node, indicating that the second response message has been received.

[0140] Accordingly, the XDP module of the first edge node receives a response message indicating that the terminal device has received the second response message.

[0141] 509. The first edge node sends a response message to the second edge node to indicate that the terminal device has received the second response message.

[0142] For example, the XDP module of the first edge node parses the first CID from the response message and extracts the address of the second edge node from the first CID. Then, it forwards the response message to the second edge node based on the address of the second edge node. For instance, the first edge node forwards the response message to the second edge node via a state synchronization channel.

[0143] It is understood that in this application example, the first edge node synchronizes the session state information of the QUIC connection to the second edge node through the state synchronization channel, forwards request messages or service processing information of request messages to the second edge node, forwards subsequent messages or service processing information of subsequent messages to the second edge node, and forwards response messages to the second edge node, etc.

[0144] Figure 5In this embodiment, after the terminal device obtains the first CID through the new_connection_id frame, subsequent packets initiated carry the first CID. Upon receiving the subsequent packets, the first edge node, in one approach, first determines whether the URL carried in the subsequent packets contains a target field or meets the requirements of the target field. When the URL carried in the subsequent packets contains a target field or meets the requirements of the target field, the first edge node further verifies the first CID carried in the subsequent packets. When the first CID passes verification, the first edge node routes the subsequent packets to the second edge node based on the identifier field encoded by the first CID. When the URL carried in the subsequent packets does not contain a target field or does not meet the requirements of the target field, even if the subsequent packets carry the first CID, the first edge node does not route the subsequent packets. Instead, the first edge node itself responds to the subsequent packets or re-executes scheduling to generate a second CID and routes the subsequent packets to the third edge node bound to the second CID. In addition, if the URL carried by a subsequent message contains the target field or meets the requirements of the target field, but the first CID fails the verification, the first edge node re-executes the scheduling to generate the second CID and routes the subsequent message to the edge node indicated by the second CID, namely the third edge node mentioned above.

[0145] In another approach, the first edge node first verifies the first CID carried in subsequent packets, and then determines whether the URL contains the target field or meets the requirements of the target field. In this approach, after generating the first CID bound to the second edge node, the first edge node further associates the first CID with range constraints such as business scope, resource scope, or URL rule scope. When the first edge node receives a subsequent packet carrying the first CID from the terminal device, it first verifies the first CID. If the first CID passes verification, the first edge node further determines whether the URL carried in the subsequent packet contains the target field or meets the requirements of the target field, i.e., whether the URL carried in the subsequent packet satisfies the range constraints associated with the first CID. If the URL carried in the subsequent packet contains the target field or meets the requirements of the target field, the first edge node schedules the subsequent packet according to the identifier field in the first CID; if the URL carried in the subsequent packet does not contain the target field or does not meet the requirements of the target field, i.e., the URL carried in the subsequent packet does not meet the range constraints associated with the first CID, the first edge node itself responds to the subsequent packet or re-executes scheduling to generate a second CID, and routes the subsequent packet to the edge node indicated by the second CID.

[0146] In this approach, the first CID is verified first, followed by a determination of whether the URL contains the target field or meets the requirements of the target field. Therefore, if the first CID fails verification, regardless of whether the URL contains the target field or meets the requirements of the target field, the first edge node re-executes scheduling to generate a second CID and routes subsequent packets to the edge node indicated by the second CID, i.e., the aforementioned third edge node.

[0147] 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.

[0148] Figure 6 This is a schematic diagram of a request message scheduling device provided in an embodiment of this application. The request message scheduling device 600 is integrated on a first edge node in a content delivery network, and the request message scheduling device 600 includes: a transceiver module 61, a determination module 62, and a processing module 63.

[0149] The transceiver module 61 is used to receive a request message carrying a URL from the terminal device via a QUIC connection with the terminal device; The determination module 62 is used to determine a first CID bound to a second edge node in the content delivery network when the URL carries a target field, wherein the target field is used to indicate a request message to be scheduled; The transceiver module 61 is further configured to send the first CID to the terminal device via the QUIC connection, and receive subsequent messages carrying the first CID from the terminal device via the QUIC connection. Processing module 63 is used to route the subsequent packets to the second edge node according to the first CID.

[0150] In one feasible implementation, when the URL carries a target field, after the determining module 62 determines the first CID bound to the second edge node in the content delivery network, the processing module 63 is further configured to provide the second edge node with the session state information of the QUIC connection.

[0151] In one feasible implementation, the processing module 63 is used to write the session state information into a shared database; create a state synchronization channel based on the shared database; and provide the QUIC connection session state information to the second edge node through the state synchronization channel.

[0152] In one feasible implementation, the processing module 63 is used to parse the first CID in the subsequent message to obtain a verification field and an identifier field of the second edge node. The verification field includes at least one of the following fields: an integrity label field, a business domain field, or a validity period field; verify the first CID according to the verification field; and if the first CID passes the verification field, route the subsequent message to the second edge node according to the identifier field.

[0153] In one feasible implementation, the processing module 63 is further configured to determine a third edge node from the content delivery network under preset conditions, wherein the preset conditions include: the first CID fails the verification of the verification field, the subsequent message does not reach the second edge node or the second edge node is abnormal; and determine a second CID bound to the third edge node.

[0154] In one feasible implementation, after the processing module 63 routes the subsequent message to the second edge node according to the first CID, it is further configured to obtain a first response message obtained by the second edge node in response to the subsequent message; and encapsulate the first response message according to the communication address of the first edge node to obtain a second response message. The transceiver module 61 is further configured to send the second response message to the terminal device.

[0155] The request message scheduling provided in this application embodiment can execute the actions of the first edge node in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0156] Figure 7 This is another schematic diagram of the request message scheduling device provided in this application embodiment. The request message scheduling device 700 is integrated on a second edge node in the content delivery network, and the request message scheduling device 700 includes: an identification module 71 and a processing module 72.

[0157] The identification module 71 is used to identify subsequent packets routed to itself by the first edge node according to the first CID. The first CID is determined by the first edge node after receiving a request packet carrying a URL from the terminal device through a QUIC connection with the terminal device, and the URL carries a target field. The first CID is bound to the second edge node. Processing module 72 is used to respond to the subsequent message.

[0158] In one feasible implementation, before the identification module 71 identifies subsequent packets routed to itself by the first edge node based on the first CID, the processing module 72 is further configured to obtain session state information of the QUIC connection between the first edge node and the terminal device in the content delivery network. The session state information is provided by the first edge node after receiving a request packet carrying a URL through the QUIC connection, and determining the first CID bound to the second edge node in the case that the URL carries a target field; and responds to the request packet based on the session state information.

[0159] In one feasible implementation, the processing module 72 is used to complete session recovery and state alignment based on the session state information, so as to process the subsequent messages to obtain a first response message; and send the first response message to the terminal device.

[0160] In one feasible implementation, the processing module 72 is used to encapsulate the first response message according to the communication address of the first edge node to obtain a second response message; and send the second response message to the terminal device.

[0161] The request message scheduling provided in this application embodiment can execute the actions of the second edge node in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0162] Figure 8 This is another schematic diagram of the request message scheduling device provided in the embodiments of this application. The request message scheduling device 800 is integrated into the terminal device and includes: a sending module 81 and a receiving module 82.

[0163] Sending module 81 is used to send a request message carrying a URL to a first edge node in the content delivery network via a QUIC connection, wherein the QUIC connection is a connection between the terminal and the first edge node, and when the URL contains a target field, the request message is used to enable the first edge node to determine a first CID bound to a second edge node in the content delivery network; Receiver module 82 is configured to receive a first CID from the first edge node via the QUIC connection; The sending module 81 is also configured to send a subsequent message carrying the first CID to the first edge node via the QUIC connection.

[0164] In one feasible implementation, after the sending module 81 sends a subsequent message carrying the first CID to the first edge node via the QUIC connection, the receiving module 82 is further configured to receive a second CID from the first edge node via the QUIC connection. The second CID is bound to a third edge node in the content delivery network. The second CID is a CID generated by the first edge node under preset conditions. The preset conditions include: the first CID fails the verification of the verification field, the subsequent message does not reach the second edge node, or the second edge node is abnormal. The sending module 81 is also configured to send a response message carrying the second CID to the first edge node via the QUIC connection.

[0165] In one feasible implementation, the receiving module 82 is used to receive a second response message from the second edge node. The second response message is obtained by the second edge node by encapsulating the first response message according to the communication address of the first edge node. The first response message is obtained by the second edge node in response to the subsequent message.

[0166] The request message scheduling provided in this application embodiment can execute the actions of the terminal device in the above embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0167] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device, such as the first edge node, second edge node, or terminal device described above, includes: Processor 91 and memory 92; The memory 92 stores computer instructions and test data; The processor 91 executes the computer instructions stored in the memory 92, causing the processor 91 to perform the request message scheduling method as described above.

[0168] 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.

[0169] 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.

[0170] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, are used to implement the request message scheduling method described above.

[0171] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the request message scheduling method described above.

[0172] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application 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 embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0173] 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 request message scheduling method, characterized in that, The method, applied to a first edge node in a content delivery network, includes: Receive a request message carrying a URL from the terminal device via a QUIC connection with the terminal device; When the URL carries a target field, a first CID bound to a second edge node in the content delivery network is determined, the target field being used to indicate a request message to be scheduled; The first CID is sent to the terminal device via the QUIC connection; Receive subsequent messages carrying the first CID from the terminal device via the QUIC connection; The subsequent messages are routed to the second edge node based on the first CID.

2. The method according to claim 1, characterized in that, When the URL carries a target field, after determining the first CID bound to the second edge node in the content delivery network, the method further includes: Provide the second edge node with the session state information of the QUIC connection.

3. The method according to claim 2, characterized in that, Providing the QUIC connection session state information to the second edge node includes: Write the session state information into the shared database; A status synchronization channel is created based on the shared database; The session state information of the QUIC connection is provided to the second edge node through the state synchronization channel.

4. The method according to any one of claims 1 to 3, characterized in that, The step of routing subsequent packets to the second edge node based on the first CID includes: Parse the first CID in the subsequent message to obtain the verification field and the identification field of the second edge node. The verification field includes at least one of the following fields: integrity label field, business domain field, or validity period field. Verify the first CID according to the verification field; If the first CID is verified by the verification field, the subsequent message is routed to the second edge node according to the identifier field.

5. The method according to claim 4, characterized in that, Also includes: Under the condition that preset conditions are met, a third edge node is determined from the content delivery network, wherein the preset conditions include: the first CID fails the verification of the verification field, the subsequent message does not reach the second edge node, or the second edge node is abnormal; Determine the second CID bound to the third edge node.

6. The method according to claim 2, characterized in that, After routing the subsequent packets to the second edge node based on the first CID, the method further includes: Obtain the first response message obtained by the second edge node in response to the subsequent message; The first response message is encapsulated according to the communication address of the first edge node to obtain the second response message; Send the second response message to the terminal device.

7. A request message scheduling method, characterized in that, The method, applied to a second edge node in a content delivery network, includes: Identify subsequent packets routed to itself by the first edge node based on the first CID. The first CID is determined by the first edge node after receiving a request packet carrying a URL from the terminal device through a QUIC connection with the terminal device, and the URL carries a target field. The first CID is bound to the second edge node. Respond to the subsequent message.

8. The method according to claim 7, characterized in that, The identification process, prior to the first edge node routing subsequent packets to itself based on the first CID, also includes: The session state information of the QUIC connection between the first edge node and the terminal device in the content delivery network is obtained. The session state information is provided by the first edge node after receiving a request message carrying a URL through the QUIC connection, and after determining the first CID bound to the second edge node in the case that the URL carries a target field. The request message is responded to based on the session state information.

9. The method according to claim 8, characterized in that, The response to the subsequent message includes: Based on the session state information, session recovery and state alignment are completed to process subsequent messages and obtain the first response message; The first response message is sent to the terminal device.

10. The method according to claim 9, characterized in that, Sending the first response message to the terminal device includes: The first response message is encapsulated based on the communication address of the first edge node to obtain the second response message; Send the second response message to the terminal device.

11. A request message scheduling method, characterized in that, Applied to a terminal device, the method includes: A request message carrying a URL is sent to a first edge node in the content delivery network via a QUIC connection, wherein the QUIC connection is a connection between the terminal device and the first edge node. When the URL contains a target field, the request message is used to enable the first edge node to determine a first CID bound to a second edge node in the content delivery network. Receive the first CID from the first edge node via the QUIC connection; The first edge node is then sent a subsequent message carrying the first CID via the QUIC connection.

12. The method according to claim 11, characterized in that, After sending a subsequent message carrying the first CID to the first edge node via the QUIC connection, the method further includes: The second CID is received from the first edge node through the QUIC connection. The second CID is bound to the third edge node in the content delivery network. The second CID is generated by the first edge node under preset conditions. The preset conditions include: the first CID fails the verification field, the subsequent message does not reach the second edge node, or the second edge node is abnormal. A response message carrying the second CID is sent to the first edge node via the QUIC connection.

13. The method according to claim 11 or 12, characterized in that, Sending a subsequent message carrying the first CID to the first edge node via the QUIC connection includes: The second response message is received from the second edge node. The second response message is obtained by the second edge node by encapsulating the first response message according to the communication address of the first edge node. The first response message is obtained by the second edge node in response to the subsequent message.

14. 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 13.

15. 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 13.

Images