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

Abstract

The invention relates to a client request back-to-source method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: receiving a client request, determining a target back-to-source path from the client request to a source station node from a content distribution network, and deploying a unified session bill key between nodes in the content distribution network; querying a session bill cache corresponding to a next hop node in the target back-to-source path; under the condition of determining that the session bill cache does not exist, generating session structure data and encrypting the session structure data by using the session bill key to obtain a new session bill; establishing a handshake connection with a next hop node by using the new session bill, and transmitting a client request to the next hop node; and under the condition that the next hop node is the source station node, sending a back-to-source request requested by the client to the source station node and receiving a request response result corresponding to the back-to-source request. By adopting the method, the handshake time delay can be reduced.

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 requesting a client to return to the source. Background Art

[0002] When the Content Delivery Network (CDN) dynamically accelerates the return of a Hypertext Transfer Protocol request sent by a client to a server, it usually needs to pass through multiple parent nodes. In addition, during the return process, each node must establish a Secure Socket Layer (SSL) handshake connection with the source station, resulting in a large return delay.

[0003] In traditional technology, in order to improve the efficiency of secure socket layer connection, the secure socket layer session reuse technology is usually used. For example, after the first return to the source completes the secure socket layer handshake, the session ticket of the domain name can be saved. When the client under the domain name subsequently requests to return to the source again, the saved session ticket can be directly used to restore the secure socket layer session, thereby reducing the delay required for the complete handshake process.

[0004] However, when the transmission method in the above-mentioned traditional technology is adopted, 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 process of requesting return to the source. Summary of the invention

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

[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 station node from a content distribution network, wherein a unified session ticket key is deployed between nodes in the content distribution network;

[0008] Querying a session ticket cache corresponding to a 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] 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;

[0011] In the case where the next hop node is the source station node, a back-to-source request of the client request is sent to the source station node, and a request response result corresponding to the back-to-source request returned by the source station 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 according to 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] In the case where the next hop node is the source station node, determining a currently used ticket reuse granularity;

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

[0018] The session ticket cache is queried according to the session cache key.

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

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

[0021] In the case where the ticket reuse granularity includes machine granularity, the session cache key corresponding to the source station node is determined using the backend type of the source station node and the network address of the source station 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] In the case where 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-source device, comprising:

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

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

[0030] A ticket generation module, for generating session structure data and encrypting 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 establishment 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, wherein the computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the client request back-to-source method described in any one of the embodiments of the first aspect is implemented.

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

[0035] In a fifth aspect, the present application further provides a computer program product, including a computer program, which, 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 receive a client request, determine a target back-to-source path from the client request to the source station node from 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, 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 there is no session ticket cache, use the new session ticket to establish a handshake connection with the next hop node, transmit the client request to the next hop node, send a back-to-source request of the client request to the source station node when the next hop node is a source station node, and receive a request response result corresponding to the back-to-source request returned by the source station node, so that encryption and decryption of the session can be realized in different nodes using a unified session ticket key, thereby omitting the key negotiation process in the handshake connection process, and realizing that in the first handshake connection process when there is no session ticket cache, a communication connection between nodes can be quickly established without performing a complete three-way handshake operation, which greatly reduces the handshake delay and central processing unit 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 drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. 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 creative work.

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

[0039] Figure 2 A schematic diagram of a process of requesting a method for returning to the source by a client in one embodiment;

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

[0041] Figure 4 A schematic diagram of a flow chart of a method for requesting a client to return to the source in another embodiment;

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

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

[0044] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present 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 return 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 (Content Delivery Network, CDN for short) may be used to represent a network composed of server groups distributed in different geographical locations as nodes, and a unified session ticket key is deployed between each node in the content delivery network.

[0049] The edge node 142 may be used to represent a server node closest to a client in the content distribution network 140. The edge node 142 may be used to cache the content of the origin node 160 to reduce the access delay of the user's client request and reduce the load of the origin node 160. The edge node 142 may be distributed around the world to respond to the user's client request more quickly.

[0050] The parent node 144 may be used to represent an intermediate node in the content distribution network 140, and is usually located between the edge node 142 and the source node 160. The parent node 144 may be used to provide cache support for the edge node 142: for example, when the edge node 142 does not have the cache resources required by the client request, it may request the parent node 144, thereby further reducing the load of the source node 160.

[0051] The source node 160 may be used to represent a server node storing the original content. When no node in the content distribution network 140 stores the cache resources required by the client request, the content distribution network 140 may request the relevant data resources from the source node 160. The source node 160 is usually 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, often 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 to increase 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, the proxy server 180 may receive the client request sent by the client node 120 through the edge node 142 in the content distribution network 140 that is closest to the client node 120. According to the connection paths between the edge node 142 and the parent node 144, the parent node 144 and the parent node 144, and the parent node 144 and the source station node 160 in the content distribution network 140, the target back-to-source path of the client request to the source station node 160 is determined from the content distribution network 140. The proxy server 180 may query the session ticket cache corresponding to the next hop node in the target back-to-source path in the edge node 142. In the case of determining that there is no session ticket cache, the session structure data is generated and encrypted using a pre-deployed unified session ticket key to obtain a new session ticket. The proxy server 180 may use the new session ticket to restore the secure socket layer session between the edge node 142 and the next hop node of the edge node 142, so as to establish a handshake connection between the edge node 142 and the next hop node of the edge node 142, and transmit the client request from the edge node 142 to the next hop node. In the case where the next hop node is the source station node 160 , the proxy server 180 may receive a request response result corresponding to the client request and returned by the source station node 160 .

[0054] In this embodiment, by deploying a unified session ticket key for each node in the content distribution network, the unified session ticket key is used to encrypt the session structure data in the process of client requesting back to the source, and a new session ticket is obtained, so that each node can automatically complete the encryption and decryption operations of the session structure data without communication interaction. This saves the time for negotiating encryption keys between nodes and reduces the handshake delay in the process of client requesting back to the source.

[0055] In an exemplary embodiment, Figure 2As shown, a method for client requesting to return to the source is provided, and this method is applied to Figure 1 The proxy server 180 in the example can be used as an example to illustrate, including the following steps S202 to S210. Among them:

[0056] Step S202: receiving a client request and determining a target back-to-source path from the client request to the source station node from the content distribution network.

[0057] Among them, a unified session ticket key is deployed between each node in the content distribution network. The session ticket key (also known as session ticket key) is a key used to encrypt and decrypt session tickets. The session ticket key is usually used in the content distribution network to manage and protect the security of user sessions.

[0058] Exemplarily, the proxy server may select the node closest to the client node as the edge node to receive the client request sent by the client node based on the distance between the client node and each node in the content distribution network. According to the parent node stored in the content distribution network that has a connection relationship with the edge node, the next hop node corresponding to the edge node is determined. According to the parent node stored in the content distribution network that has a connection relationship with the next hop node, the next hop node corresponding to the next hop node is determined until the next hop node is connected to the source station node, forming a target back-to-source path for the client request from the edge node to the source station node.

[0059] Step S204, querying 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 the cached data of the session ticket. The session ticket can be used to achieve fast recovery in the HTTP session without having to re-do the complete TLS handshake process, thereby speeding up the connection and reducing latency.

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

[0062] Step S206: When 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] Exemplarily, when the proxy server determines that there is no session ticket cache, it can actively generate session structure data that conforms to the secure socket layer session format through the edge node based on the preset secure socket layer session logic. The proxy server can encrypt the session structure data using the same session ticket key between each node, obtain a new session ticket and save 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] Exemplarily, the proxy server can use the new session ticket through the edge node to perform a secure socket layer 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 actively generated by the edge node to obtain the session structure data of the edge node. Then, the information required to restore the secure socket layer session, such as the session key and the session algorithm suite, is extracted from the session structure data, and the secure socket layer session between the edge node and the next hop node is finally restored. As a result, the edge node can reuse the restored secure socket layer session during the first secure socket layer handshake with the next hop node without performing a complete secure socket layer handshake operation, which greatly reduces the handshake delay and CPU resource consumption. After the handshake between the edge node and the next hop node is successful, a communication connection between the edge node and the next hop node can be established, and the client request is sent to the next hop node through the established communication connection.

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

[0067] Exemplarily, the proxy server can request the current node of the client to be a 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 repeat the operations of steps S204 to S208, and establish the communication connection between the two adjacent hop nodes in the target back-to-source path in sequence, so as to realize 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 the back-to-source request of the client request 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 indicate that the source station node returns 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 request response result currently obtained is used to quickly respond to the client when the client sends the client request next time.

[0068] In the above-mentioned client request back-to-source method, by receiving the 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 the back-to-source request of the client request to the source station node, and receiving the 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 realize encryption and decryption of the session, thereby omitting the key negotiation process in the handshake connection process, and realizing that 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, which greatly reduces the handshake delay and the CPU 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] Among them, the backend type (also known as backend_type) can be used to distinguish between the parent node and the source node.

[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] Exemplarily, when the next hop node is a parent node that is an intermediate node in the content distribution network, the proxy server can use the backend type of the parent node (such as parent) to construct a session cache key (such as parent@@) corresponding to the parent node. Based on the string matching method, the currently obtained session cache key is matched with the data cache of the edge node 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, which can improve the query efficiency and accuracy of the session ticket cache.

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

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

[0076] Step S304, determining the session cache key corresponding to the source station node according to the backend type of the source station 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] Exemplarily, each node in the content distribution network can use a red-black tree data structure to store a session ticket cache with the source station node. When the next hop node is the source station node, the proxy server can read the currently used ticket reuse granularity from the local database or from the client. The backend type of the source station node (such as origin) and the ticket reuse granularity are combined to form a session cache key corresponding to the source station node. The session cache key corresponding to the source station node is used to query the session ticket cache corresponding to the source station node in the red-black tree data structure.

[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. 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 requirements of users.

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

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

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

[0084] Optionally, in some embodiments, the red-black tree data structure may be configured to store the session ticket cache according to the source station network address (Internet Protocol, IP for short) or the source station domain name address. For example, when the next hop node is the parent node, the values ​​of the network address key ($session_ip) and the domain name address key ($session_host) of the session ticket cache of the parent node 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 value of the domain name address key ($session_host) of the session ticket of the source node stored in the red-black tree is the domain name configured by the customer, and the value of the network address key ($session_ip) is empty; if the machine granularity is used to reuse the session ticket, the value of the domain name address key ($session_host) of the session ticket of the source node stored in the red-black tree is empty, and the value of the network address key ($session_ip) is 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, $ssession_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 name 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-source method provided by the present application may further include: in the case where it is determined that there is a session ticket cache and the next hop node is a parent node, checking whether the session ticket cache is expired. In the case where the session ticket cache is expired, performing 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 releasing the expired session ticket cache.

[0090] Exemplarily, the proxy server can read the storage time of the session ticket cache when it is determined that there is a session ticket cache corresponding to the next hop node and the next hop node is a parent node. Based on a preset time threshold, the storage time of the session ticket cache is verified to determine whether the session ticket cache is expired. In the case where the session ticket cache expires, the edge node can generate session structure data and use the session ticket key to encrypt the session structure data to obtain a new session ticket, and release the expired session ticket cache.

[0091] Optionally, in some 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, it is determined whether the session ticket cache is expired and then a corresponding operation is performed, thereby ensuring data security in the process of client requesting back to the source.

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

[0094] For example, since a unified session ticket key is deployed in each node in the content distribution network, all parent nodes passed through during the client request back to the source can use the same session ticket cache for communication, without the need to store a session ticket cache for each parent node. Therefore, in the case where the target back to the source path changes, the new session ticket generated in step S206 can still be used to restore the secure socket layer session between each parent node in the changed target back to the 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 the source 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, comprising the following steps S402 to S412. Among them:

[0097] Step S402: receiving a client request and determining a target back-to-source path from the client request to the source station node from 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 session ticket cache corresponding to the next hop node in the target back-to-source path in the red-black tree data structure of the edge node. When it is determined that there is a session ticket cache, the operation of step S406 of the following step is performed. When it is determined that there is no session ticket cache, the operation of step S410 of the following step 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 following step S410 is performed.

[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 use the session ticket key to encrypt the session structure data 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 executing 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 a source station node, a back-to-source request requested by the client is sent to the source station node, and a request response result corresponding to the back-to-source request returned by the source station node is received.

[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, which 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 return process of 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 client request return process. 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 return.

[0107] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indications of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, 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 part of the steps in the flowcharts involved in 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, and the execution order 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 part of the steps or stages in other steps.

[0108] Based on the same inventive concept, the embodiment of the present application also provides a client request return to source device for implementing the client request return to source method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more client request return to source device embodiments provided below can refer to the limitations of the client request return to source method 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 station 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 used 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 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 there is no session ticket cache.

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

[0114] The request response module 510 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.

[0115] In an exemplary embodiment, the cache query module 504 is also 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 according to the backend type of the source station node and the ticket reuse granularity; and query the session ticket cache according to 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 device 500 further includes a path change module, which is used to restore the secure socket layer session between each parent node 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 above-mentioned client request back-to-source device 500 can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each of the above modules.

[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, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, 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 the 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 an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a client request back to the source 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 those shown in the figure, or combine certain components, or have a different arrangement of components.

[0123] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned 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, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0126] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and 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 embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and 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. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0127] The technical features of the above embodiments may be combined arbitrarily. 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 only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached 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 station node from a content distribution network, wherein a unified session ticket key is deployed between nodes in the content distribution network; Querying a session ticket cache corresponding to a 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; 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; In the case where the next hop node is the source station node, a back-to-source request of the client request is sent to the source station node, and a request response result corresponding to the back-to-source request returned by the source station 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 according to 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: In the case where the next hop node is the source station node, determining a currently used ticket reuse granularity; Determine a session cache key corresponding to the source station node according to the backend type of the source station node and the ticket reuse granularity; The session ticket cache is queried according to the session cache key.

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

5. The method according to claim 1, characterized in that 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; In the case where 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, used to receive a client request and determine a target back-to-source path from the client request to a source station node from a content distribution network, wherein a unified session ticket key is deployed between each node in the content distribution network; A cache query module, used to query the session ticket cache corresponding to the next hop node in the target back-to-source path; A ticket generation module, for generating session structure data and encrypting 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 establishment 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