Client request back-to-source method, device, computer equipment, computer-readable storage medium, and computer program product

Abstract

The present application relates to a client request back-to-source method, apparatus, computer equipment, computer-readable storage medium, and computer program product. The method comprises: receiving a client request, determining a target back-to-source path from the client request to the source node from a content distribution network, wherein a unified session ticket key is deployed between each node in the content distribution network; querying a session ticket cache corresponding to the next-hop node in the target back-to-source path; when it is determined that there is no session ticket cache, generating session structure data and encrypting the session structure data using the session ticket key to obtain a new session ticket; using the new session ticket to establish a handshake connection with the next-hop node, transmitting the client request to the next-hop node; when the next-hop node is a source node, sending a back-to-source request of the client request to the source node and receiving a request response result corresponding to the back-to-source request. The use of this method can reduce handshake delay.

Description

Technical Field

[0001] The present application relates to the field of data communication technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for client requesting a return to the source. Background Art

[0002] When a Content Delivery Network (CDN) dynamically accelerates HTTP requests sent from clients to servers back to the source, the request typically passes through multiple parent nodes. Furthermore, each node in the back-to-source process must establish a Secure Sockets Layer (SSL) handshake connection with the origin server, resulting in significant back-to-source latency.

[0003] Traditionally, to improve the efficiency of Secure Sockets Layer (SSL) connections, SSL session reuse is often employed. For example, after the SSL handshake is completed during the first back-to-origin connection, a session ticket for that domain name can be saved. Subsequent back-to-origin requests from clients under that domain can be directly restored using the saved session ticket, thus reducing the latency required for the complete handshake process.

[0004] However, when using the transmission method in the above-mentioned traditional technology, since a complete secure socket layer handshake operation needs to be performed during the first return to the source in the content distribution network, there is still a problem of high handshake delay in the request return to the source process. Summary of the Invention

[0005] Based on this, it is necessary to provide a low-latency client request back-to-source method, apparatus, computer equipment, computer-readable storage medium and computer program product to address the above technical issues.

[0006] In a first aspect, the present application provides a method for requesting a client to return to the source, comprising:

[0007] Receive a client request and determine a target back-to-source path from the client request to a source node in a content distribution network, wherein a unified session ticket key is deployed between nodes in the content distribution network;

[0008] Querying the session ticket cache corresponding to the next hop node in the target back-to-source path;

[0009] If it is determined that the session ticket cache does not exist, generating session structure data and encrypting the session structure data using the session ticket key to obtain a new session ticket;

[0010] Using the new session ticket to establish a handshake connection with the next hop node, and transmitting the client request to the next hop node;

[0011] In the case where the next hop node is the source node, a back-to-source request of the client request is sent to the source node, and a request response result corresponding to the back-to-source request returned by the source node is received.

[0012] In one embodiment, querying the session ticket cache corresponding to the next hop node in the target back-to-source path includes:

[0013] In a case where the next hop node is a parent node in the content distribution network, determining a session cache key corresponding to the parent node according to a backend type of the parent node;

[0014] The session ticket cache is queried based on the session cache key.

[0015] In one embodiment, querying the session ticket cache corresponding to the next hop node in the target back-to-source path includes:

[0016] When the next hop node is the source station node, determining a currently used ticket reuse granularity;

[0017] Determining a session cache key corresponding to the source node according to the backend type of the source node and the ticket reuse granularity;

[0018] The session ticket cache is queried based on the session cache key.

[0019] In one embodiment, determining the session cache key corresponding to the source node based on the backend type of the source node and the ticket reuse granularity includes:

[0020] In a case where the ticket reuse granularity includes domain name granularity, determining a session cache key corresponding to the source node using the backend type of the source node and the domain name address of the source node;

[0021] In the case where the ticket reuse granularity includes machine granularity, the backend type of the source node and the network address of the source node are used to determine the session cache key corresponding to the source node.

[0022] In one embodiment, the method further comprises:

[0023] If it is determined that the session ticket cache exists and the next hop node is a parent node, verify whether the session ticket cache is expired;

[0024] When the session ticket cache expires, the operation of generating session structure data and encrypting the session structure data using the session ticket key to obtain a new session ticket is performed, and the expired session ticket cache is released.

[0025] In one embodiment, the method further comprises:

[0026] In the case where the target back-to-source path changes, the new session ticket is used to restore the secure socket layer session between each parent node in the target back-to-source path.

[0027] In a second aspect, the present application further provides a client request return-to-origin device, comprising:

[0028] A request receiving module, configured to receive a client request and determine a target back-to-source path from the client request to a source node in a content distribution network, wherein a unified session ticket key is deployed between nodes in the content distribution network;

[0029] A cache query module, configured to query a session ticket cache corresponding to a next-hop node in the target back-to-source path;

[0030] A ticket generation module is used to generate session structure data and encrypt the session structure data using the session ticket key to obtain a new session ticket when it is determined that the session ticket cache does not exist;

[0031] a connection establishing module, configured to use the new session ticket to establish a handshake connection with the next hop node, and transmit the client request to the next hop node;

[0032] The request response module is used to send a back-to-source request requested by the client to the source station node when the next hop node is the source station node, and receive a request response result corresponding to the back-to-source request returned by the source station node.

[0033] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the client request back-to-source method described in any embodiment of the first aspect.

[0034] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the client request back-to-source method described in any embodiment of the first aspect.

[0035] In a fifth aspect, the present application further provides a computer program product, comprising a computer program that, when executed by a processor, implements the client request back-to-source method described in any one of the embodiments of the first aspect.

[0036] The client request back-to-source method, apparatus, computer device, computer-readable storage medium, and computer program product described above receive a client request, determine a target back-to-source path from the client request to the source node in a content distribution network, deploy a unified session ticket key between each node in the content distribution network, query the session ticket cache corresponding to the next-hop node in the target back-to-source path, and if it is determined that no session ticket cache exists, generate session structure data and encrypt the session structure data using the session ticket key to obtain a new session ticket. The new session ticket is used to establish a handshake connection with the next-hop node, transmit the client request to the next-hop node, and if the next-hop node is the source node, send a back-to-source request for the client request to the source node and receive a request response corresponding to the back-to-source request returned by the source node. This allows session encryption and decryption to be implemented using a unified session ticket key across different nodes, thereby omitting the key negotiation process during the handshake connection process. This allows for rapid establishment of a communication connection between nodes during the first handshake connection when no session ticket cache exists, without requiring a full three-way handshake operation, significantly reducing handshake latency and CPU resource consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0038] Figure 1 This is a diagram of an application environment of a method for requesting a back-to-origin request from a client in one embodiment;

[0039] Figure 2 A schematic diagram of a process for requesting a back-to-origin method by a client in one embodiment;

[0040] Figure 3 A flowchart of a session ticket cache query step in one embodiment;

[0041] Figure 4 This is a flowchart of a method for requesting a client to return to the source in another embodiment;

[0042] Figure 5 This is a structural block diagram of a client request back-to-origin device 500 in one embodiment;

[0043] Figure 6 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0045] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0046] The client request back-to-source method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown.

[0047] The client node 120 may be used to represent a Hyper Text Transfer Protocol (HTTP) request sent by a client to a server.

[0048] The content delivery network 140 (CDN) may be used to represent a network composed of server groups distributed at different geographical locations as nodes. A unified session ticket key is deployed between each node in the content delivery network.

[0049] Edge nodes 142 may be used to represent server nodes closest to clients in content distribution network 140. Edge nodes 142 may be used to cache content from origin nodes 160 to reduce latency in client requests and reduce the load on origin nodes 160. Edge nodes 142 may be distributed around the world to more quickly respond to client requests.

[0050] Parent node 144 may be used to represent an intermediate node in content distribution network 140, typically located between edge node 142 and origin node 160. Parent node 144 may be used to provide cache support for edge node 142: for example, when edge node 142 does not have the cache resources required by a client request, it may request the resource from parent node 144, thereby further reducing the load on origin node 160.

[0051] Origin node 160 can be used to represent the server node that stores the original content. When no node in content distribution network 140 stores the cache resources required by the client request, content distribution network 140 can request the relevant data resources from origin node 160. Origin node 160 is typically the main server of a website or application, responsible for providing the latest content.

[0052] The proxy server 180 may include but is not limited to any one or more of a variety of servers such as Squid (a common web proxy server, commonly used to control access, record logs, accelerate access, etc.), Apache (a commonly used reverse proxy server that can forward client requests to the back-end server, thereby improving the server's load capacity), Nginx (can be used to represent a high-performance Hypertext Transfer Protocol request and reverse proxy network server).

[0053] Exemplarily, proxy server 180 may receive a client request sent by client node 120 via edge node 142 in content distribution network 140 that is closest to client node 120. Based on the connection paths between edge node 142 and parent node 144, parent node 144 and parent node 144, and parent node 144 and origin node 160 in content distribution network 140, proxy server 180 determines a target back-to-source path from the client request to origin node 160 within content distribution network 140. Proxy server 180 may query the session ticket cache corresponding to the next-hop node in the target back-to-source path within edge node 142. If it is determined that no session ticket cache exists, proxy server 180 generates session structure data and encrypts the session structure data using a pre-deployed unified session ticket key to obtain a new session ticket. Proxy server 180 may use the new session ticket to resume the Secure Sockets Layer session between edge node 142 and the next-hop node of edge node 142, thereby establishing a handshake connection between edge node 142 and the next-hop node of edge node 142 and transmitting the client request from edge node 142 to the next-hop node. In the case where the next hop node is the source node 160 , the proxy server 180 may receive a request response result corresponding to the client request and returned by the source node 160 .

[0054] In this embodiment, a unified session ticket key is deployed for each node in the content distribution network. This unified session ticket key is used to encrypt the session structure data during client back-to-origin requests, generating a new session ticket. This allows each node to automatically encrypt and decrypt the session structure data without requiring communication. This reduces the time required to negotiate encryption keys between nodes and reduces handshake latency during client back-to-origin requests.

[0055] In an exemplary embodiment, Figure 2As shown, a client request back-to-source method is provided, which is applied to Figure 1 The proxy server 180 in the example can be used as an example to illustrate the process, including the following steps S202 to S210.

[0056] Step S202: Receive a client request and determine a target back-to-source path from the client request to the source node in the content distribution network.

[0057] A unified session ticket key is deployed between all nodes in a content delivery network. A session ticket key (also known as a session ticket key) is used to encrypt and decrypt session tickets. Session ticket keys are typically used in content delivery networks to manage and protect the security of user sessions.

[0058] For example, the proxy server may select the node closest to the client node as an edge node based on the distance between the client node and each node in the content distribution network to receive the client request sent by the client node. The proxy server may determine the next hop node corresponding to the edge node based on the parent node connected to the edge node stored in the content distribution network. The proxy server may determine the next hop node corresponding to the next hop node based on the parent node connected to the next hop node stored in the content distribution network, until the next hop node connects to the source node, thereby forming a target back-to-source path for the client request from the edge node to the source node.

[0059] Step S204: query the session ticket cache corresponding to the next hop node in the target back-to-source path.

[0060] The session ticket cache can be used to represent cached data of session tickets. Session tickets can be used to quickly resume HTTP sessions without having to redo the full TLS handshake, thereby speeding up connections and reducing latency.

[0061] For example, the proxy server can read the cached data of the edge node currently receiving the client request. In the cached data of the edge node, based on the node identifier, network address, and other information of the next hop node of the edge node in the target back-to-source path, the proxy server queries the session ticket cache corresponding to the next hop node.

[0062] Step S206: If it is determined that there is no session ticket cache, session structure data is generated and encrypted using the session ticket key to obtain a new session ticket.

[0063] For example, if the proxy server determines that no session ticket cache exists, it can proactively generate session structure data in a Secure Sockets Layer (SSL) session format through the edge node based on pre-defined SSL session logic. The proxy server can encrypt the session structure data using a session ticket key that is common across all nodes, generating a new session ticket and storing it in the data cache of the edge node.

[0064] Step S208: Use the new session ticket to establish a handshake connection with the next hop node, and transmit the client request to the next hop node.

[0065] For example, the proxy server can use the new session ticket through the edge node to perform a Secure Sockets Layer (SSL) handshake with the corresponding next-hop node on the target back-to-source path. Since the next-hop node also stores a unified session ticket key, the next-hop node currently performing the handshake can use the session ticket key to decrypt the new session ticket proactively generated by the edge node, obtaining the edge node's session structure data. Furthermore, the information required to restore the SSL session, such as the session key and session algorithm suite, can be extracted from the session structure data, ultimately restoring the SSL session between the edge node and the next-hop node. This allows the edge node to reuse the restored SSL session during the first SSL handshake with the next-hop node without having to perform a full SSL handshake, significantly reducing handshake latency and CPU resource consumption. After a successful handshake between the edge node and the next-hop node, a communication connection can be established between the edge node and the next-hop node, and the client request can be sent to the next-hop node via the established communication connection.

[0066] Step S210: When the next hop node is a source node, a request response result corresponding to the client request and returned by the source node is received.

[0067] Exemplarily, the proxy server can request the client to use the current node as the new next hop node and determine the next hop node corresponding to the new next hop node in the target back-to-source path. Then, the above steps S204 to S208 are repeated to establish communication connections between two adjacent hop nodes in the target back-to-source path, thereby realizing the transmission of the client request. In the case where the next hop node is the final source station node in the target back-to-source path, the proxy server can send a back-to-source request requested by the client to the source station node through the communication connection between the previous hop node of the source station node and the source station node. The back-to-source request is used to instruct the source station node to return the data resources required for the client request. The request response result corresponding to the back-to-source request returned by the source station node is received through the previous hop node of the source station node. Then, the request response result is returned to the client through the node on the target back-to-source path, or the currently obtained request response result is used to quickly respond to the client when the client sends a client request next time.

[0068] In the above-mentioned client request back-to-source method, by receiving a client request, determining the target back-to-source path from the client request to the source station node from the content distribution network, deploying a unified session ticket key between each node in the content distribution network, querying the session ticket cache corresponding to the next hop node in the target back-to-source path, and when it is determined that there is no session ticket cache, generating session structure data and encrypting the session structure data using the session ticket key to obtain a new session ticket, using the new session ticket to establish a handshake connection with the next hop node, transmitting the client request to the next hop node, and when the next hop node is the source station node, sending a back-to-source request of the client request to the source station node, and receiving a request response result corresponding to the back-to-source request returned by the source station node. The unified session ticket key can be used in different nodes to implement session encryption and decryption, thereby omitting the key negotiation process during the handshake connection process. In the first handshake connection process when there is no session ticket cache, the communication connection between the nodes can be quickly established without performing a complete three-way handshake operation, significantly reducing the handshake delay and central processing unit resource consumption.

[0069] In an exemplary embodiment, the above step S204 may further include: when the next hop node is a parent node in the content distribution network, determining a session cache key corresponding to the parent node according to the backend type of the parent node; and querying the session ticket cache according to the session cache key.

[0070] The backend type (also known as backend_type) can be used to distinguish between parent nodes and source nodes.

[0071] The session cache key (also known as $session_cache_key) can be used as a query key for the session ticket cache to quickly query the corresponding session ticket cache.

[0072] For example, if the next-hop node is a parent node serving as an intermediate node in a content delivery network, the proxy server can use the parent node's backend type (e.g., parent) to construct a session cache key (e.g., parent@@) corresponding to the parent node. Based on string matching, the obtained session cache key is matched against the edge node's data cache to query the session ticket cache corresponding to the parent node.

[0073] In this embodiment, when the next hop node is the parent node, the session cache key corresponding to the parent node is determined according to the backend type of the parent node, and the session ticket cache is queried according to the session cache key, thereby improving the query efficiency and accuracy of the session ticket cache.

[0074] In an exemplary embodiment, Figure 3 As shown, the above step S204 may further include the following steps S302 to S306. Among them:

[0075] Step S302: When the next hop node is the source node, determine the currently used ticket reuse granularity.

[0076] Step S304: Determine the session cache key corresponding to the source node according to the backend type of the source node and the ticket reuse granularity.

[0077] Step S306: query the session ticket cache according to the session cache key.

[0078] The ticket reuse granularity may be used to characterize the data granularity used by each node in the content distribution network to store the session ticket cache.

[0079] For example, each node in a content distribution network can use a red-black tree data structure to store session ticket caches with origin nodes. When the next-hop node is an origin node, the proxy server can retrieve the currently used ticket reuse granularity from a local database or from the client. The source node's backend type (e.g., origin) and ticket reuse granularity are combined to form a session cache key corresponding to the origin node. The session cache key corresponding to the origin node is used to query the red-black tree data structure for the session ticket cache corresponding to the origin node.

[0080] In this embodiment, flexible management of the session ticket cache between each node in the content distribution network and the source station node is achieved by setting the ticket reuse granularity. The session cache key corresponding to the source station node is determined according to the ticket reuse granularity and the backend type of the source station node, and the session ticket cache is queried according to the session cache key. This can improve the flexibility of session ticket reuse and meet the different usage needs of users.

[0081] In an exemplary embodiment, step S304 includes: when the ticket reuse granularity includes domain name granularity, determining the session cache key corresponding to the source node using the backend type of the source node and the domain name address of the source node. When the ticket reuse granularity includes machine granularity, determining the session cache key corresponding to the source node using the backend type of the source node and the network address of the source node.

[0082] For example, when the ticket reuse granularity includes domain name granularity, the proxy server can use the backend type of the origin node and the domain name address of the origin node to form a session cache key corresponding to the origin node. For example, if the domain name address of the origin node is a.com, a session cache key of "origin@a.com@" can be formed. This achieves session ticket reuse with the domain name address of the origin node as the storage granularity.

[0083] When the ticket reuse granularity includes machine granularity, the proxy server can use the source node's backend type and the source node's network address to form a session cache key corresponding to the source node. For example, if the source node's network address is 1.1.1.1, a session cache key of "origin@@1.1.1.1" can be formed. This enables session ticket reuse at the source node's network address as the storage granularity.

[0084] Optionally, in some embodiments, the red-black tree data structure can be configured to store session ticket caches based on the source station's Internet Protocol (IP) address or domain name address. For example, if the next-hop node is a parent node, the values ​​of the parent node's session ticket cache's network address key ($session_ip) and domain name address key ($session_host) stored in the red-black tree are empty.

[0085] In the case where the next-hop node is the source node, if the domain name granularity is used to reuse the session ticket, the domain name address key ($session_host) of the session ticket of the source node stored in the red-black tree will be the domain name configured by the customer, and the network address key ($session_ip) will be empty. If the machine granularity is used to reuse the session ticket, the domain name address key ($session_host) of the session ticket of the source node stored in the red-black tree will be empty, and the network address key ($session_ip) will be the network address of the source node. Furthermore, the proxy server can also configure the combination to obtain the session cache key in the following way:

[0086] "set $session_cache_key $backend_type@$session_host@$session_ip".

[0087] Among them, $session_cache_key can represent the session cache key. $backend_type can represent the backend type key of the node. $session_host can represent the domain address key. $session_ip can represent the network address key.

[0088] In this embodiment, by querying the session ticket cache based on the domain name address or network address of the source station node as the reuse granularity of the session ticket, the session ticket reuse storage rules of the source station can be configured in a personalized and customized manner based on user needs, thereby improving the flexibility of the client request back-to-source method.

[0089] In an exemplary embodiment, the client request back-to-origin method provided herein may further include: if it is determined that a session ticket cache exists and the next-hop node is a parent node, verifying whether the session ticket cache has expired. If the session ticket cache has expired, generating session structure data and encrypting the session structure data using a session ticket key to obtain a new session ticket, and releasing the expired session ticket cache.

[0090] For example, if the proxy server determines that a session ticket cache exists for the next-hop node and that the next-hop node is a parent node, it can read the storage time of the session ticket cache. Based on a preset expiration threshold, the proxy server verifies the storage time of the session ticket cache to determine whether the session ticket cache has expired. If the session ticket cache has expired, the edge node can generate session structure data and encrypt the session structure data using the session ticket key to obtain a new session ticket, thereby releasing the expired session ticket cache.

[0091] Optionally, in other implementations, when it is determined that there is an unexpired session ticket cache and the next hop node is a parent node, the edge node may reuse the session ticket cache to perform a handshake connection with the next hop node.

[0092] In this embodiment, when a session ticket cache exists and the next hop node is a parent node, whether the session ticket cache is expired is determined, and then corresponding operations are performed, thereby ensuring data security during the client request back to the source.

[0093] In an exemplary embodiment, the client request back-to-source method provided in this application may further include: using a session ticket to restore a secure socket layer session between parent nodes in the target back-to-source path when the target back-to-source path changes.

[0094] For example, because each node in the content distribution network is equipped with a unified session ticket key, all parent nodes passed through during a client's back-to-source request can use the same session ticket cache for communication, eliminating the need to store a session ticket cache for each parent node. Therefore, if the target back-to-source path changes, the new session ticket generated in step S206 can still be used to restore the Secure Sockets Layer session between the parent nodes in the changed target back-to-source path.

[0095] In this embodiment, by using the same session ticket cache at each parent node, memory consumption during the client request back-to-source process can be reduced.

[0096] In an exemplary embodiment, Figure 4 As shown, a method for requesting a client to return to the source is also provided, including the following steps S402 to S412.

[0097] Step S402: Receive a client request and determine a target back-to-source path from the client request to the source node in the content distribution network.

[0098] Step S404: query the session ticket cache corresponding to the next hop node in the target back-to-source path according to the session cache key of the next hop node.

[0099] Exemplarily, the proxy server can receive the client request sent by the client node through the edge node in the content distribution network, and determine the target back-to-source path from the client request to the source node with the shortest time or the least resource consumption from the content distribution network. Through a preset callback function, the session cache key of the next hop node is determined according to the backend type of the next hop node and the currently used ticket reuse granularity. The session cache key is used to query the red-black tree data structure of the edge node for the session ticket cache corresponding to the next hop node in the target back-to-source path. If it is determined that a session ticket cache exists, the operation of the following step S406 is performed. If it is determined that no session ticket cache exists, the operation of the following step S410 is performed.

[0100] Step S406: When the next hop node is the parent node, check whether the session ticket cache is expired.

[0101] Exemplarily, the proxy server may perform the following step S408 if the next hop node is a parent node and the session ticket cache is not expired. If the next hop node is a parent node and the session ticket cache is expired, the proxy server may perform the following step S410.

[0102] Step S408: Use the session ticket cache to establish a handshake connection with the next hop node, and transmit the client request to the next hop node.

[0103] Step S410: Generate session structure data and encrypt the session structure data using the session ticket key to obtain a new session ticket. Establish a handshake connection with the next hop node through the new session ticket and transmit the client request to the next hop node.

[0104] Exemplarily, after completing step S408 or step S410, the proxy server may jump to the execution node of step S404 and repeatedly execute the above step S404 until the next hop node is the source station node and execute the following step S412.

[0105] Step S412: When the next hop node is the source node, a back-to-source request requested by the client is sent to the source node, and a request response result corresponding to the back-to-source request is received from the source node.

[0106] In this embodiment, by deploying a unified session ticket key in each node of the content distribution network, each parent node can automatically generate a corresponding new session ticket. Even if the original session ticket cache expires, the session ticket can be automatically updated without performing a complete handshake operation. This can greatly improve the reuse rate of the session ticket and reduce the delay of the new secure socket layer handshake connection and the consumption of processor resources. In addition, since the session ticket keys of each parent node are the same, the parent nodes passed through during the process of returning to the source by the client request can use the same session ticket cache without having to store the session ticket cache of each parent node separately, thereby reducing the memory consumption during the process of the client request returning to the source. In addition, since the ticket reuse granularity is set, the ticket reuse can also be customized and personalized by the user, thereby improving the flexibility of the client request returning to the source.

[0107] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times. The order of execution of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0108] Based on the same inventive concept, embodiments of the present application also provide a client request return-to-source device for implementing the aforementioned client request return-to-source method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more embodiments of the client request return-to-source device provided below can be found in the limitations of the client request return-to-source method described above and will not be repeated here.

[0109] In an exemplary embodiment, Figure 5 As shown, a client request back-to-source device 500 is provided, comprising: a request receiving module 502, a cache query module 504, a ticket generating module 506, a connection establishing module 508, and a request response module 510, wherein:

[0110] The request receiving module 502 is used to receive a client request and determine a target back-to-source path from the client request to the source node in the content distribution network. A unified session ticket key is deployed between each node in the content distribution network.

[0111] The cache query module 504 is configured to query the session ticket cache corresponding to the next hop node in the target back-to-source path.

[0112] The ticket generation module 506 is configured to generate session structure data and encrypt the session structure data using the session ticket key to obtain a new session ticket when it is determined that no session ticket cache exists.

[0113] The connection establishing module 508 is configured to use the new session ticket to establish a handshake connection with the next hop node, and transmit the client request to the next hop node.

[0114] The request response module 510 is configured to send a back-to-source request requested by the client to the source node when the next hop node is the source node, and receive a request response result corresponding to the back-to-source request returned by the source node.

[0115] In an exemplary embodiment, the cache query module 504 is further used to determine the session cache key corresponding to the parent node according to the backend type of the parent node when the next hop node is a parent node in the content distribution network; and query the session ticket cache according to the session cache key.

[0116] In an exemplary embodiment, the cache query module 504 is also used to determine the currently used ticket reuse granularity when the next hop node is a source station node; determine the session cache key corresponding to the source station node based on the backend type of the source station node and the ticket reuse granularity; and query the session ticket cache based on the session cache key.

[0117] In an exemplary embodiment, the cache query module 504 is also used to determine the session cache key corresponding to the source station node using the backend type of the source station node and the domain name address of the source station node when the ticket reuse granularity includes domain name granularity; and to determine the session cache key corresponding to the source station node using the backend type of the source station node and the network address of the source station node when the ticket reuse granularity includes machine granularity.

[0118] In an exemplary embodiment, the client request back-to-source device 500 also includes: a time validity verification module, which is used to verify whether the session ticket cache is expired when it is determined that there is a session ticket cache and the next hop node is the parent node; when the session ticket cache is expired, it executes the operation of generating session structure data and encrypting the session structure data using the session ticket key to obtain a new session ticket, and releases the expired session ticket cache.

[0119] In an exemplary embodiment, the client request back-to-source apparatus 500 further includes a path change module for restoring the secure socket layer session between parent nodes in the target back-to-source path using a new session ticket when the target back-to-source path changes.

[0120] Each module in the client request back-to-source device 500 can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a memory in a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0121] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 6 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data such as client requests, target return paths, session ticket caches, new session tickets, etc. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through a network connection. When the computer program is executed by the processor, a client request return method is implemented.

[0122] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0123] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0124] In an exemplary embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0125] In an exemplary embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0126] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In particular, any reference to a memory, database, or other medium used in the embodiments provided in this application can include at least one of a non-volatile memory and a volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0127] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0128] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A method for requesting a client to return to the source, characterized in that: The method comprises: Receive a client request and determine a target back-to-source path from the client request to a source node in a content distribution network, wherein a unified session ticket key is deployed between nodes in the content distribution network; Querying the session ticket cache corresponding to the next hop node in the target back-to-source path; If it is determined that the session ticket cache does not exist, generating session structure data and encrypting the session structure data using the session ticket key to obtain a new session ticket; Using the new session ticket to establish a handshake connection with the next hop node, and transmitting the client request to the next hop node; In the case where the next hop node is the source node, a back-to-source request of the client request is sent to the source node, and a request response result corresponding to the back-to-source request returned by the source node is received.

2. The method according to claim 1, characterized in that The querying of the session ticket cache corresponding to the next hop node in the target back-to-source path includes: In a case where the next hop node is a parent node in the content distribution network, determining a session cache key corresponding to the parent node according to a backend type of the parent node; The session ticket cache is queried based on the session cache key.

3. The method according to claim 1, characterized in that The querying of the session ticket cache corresponding to the next hop node in the target back-to-source path includes: When the next hop node is the source station node, determining a currently used ticket reuse granularity; Determining a session cache key corresponding to the source node according to the backend type of the source node and the ticket reuse granularity; The session ticket cache is queried based on the session cache key.

4. The method according to claim 3, characterized in that The determining, according to the backend type of the source node and the ticket reuse granularity, a session cache key corresponding to the source node includes: In a case where the ticket reuse granularity includes domain name granularity, determining a session cache key corresponding to the source node using the backend type of the source node and the domain name address of the source node; In the case where the ticket reuse granularity includes machine granularity, the backend type of the source node and the network address of the source node are used to determine the session cache key corresponding to the source node.

5. The method according to claim 1, wherein The method further comprises: If it is determined that the session ticket cache exists and the next hop node is a parent node, verify whether the session ticket cache is expired; When the session ticket cache expires, the operation of generating session structure data and encrypting the session structure data using the session ticket key to obtain a new session ticket is performed, and the expired session ticket cache is released.

6. The method according to claim 1, characterized in that The method further comprises: In the case where the target back-to-source path changes, the new session ticket is used to restore the secure socket layer session between each parent node in the target back-to-source path.

7. A client request back to source device, characterized in that: The device comprises: A request receiving module, configured to receive a client request and determine a target back-to-source path from the client request to a source node in a content distribution network, wherein a unified session ticket key is deployed between nodes in the content distribution network; A cache query module, configured to query a session ticket cache corresponding to a next-hop node in the target back-to-source path; A ticket generation module is used to generate session structure data and encrypt the session structure data using the session ticket key to obtain a new session ticket when it is determined that the session ticket cache does not exist; a connection establishing module, configured to use the new session ticket to establish a handshake connection with the next hop node, and transmit the client request to the next hop node; The request response module is used to send a back-to-source request requested by the client to the source station node when the next hop node is the source station node, and receive a request response result corresponding to the back-to-source request returned by the source station node.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images