Back-to-source test method, computer device and storage medium

Abstract

The application discloses a source return test method, computer equipment and a storage medium, and relates to the technical field of content distribution networks, wherein the source return test method realizes active pushing of configuration information by the mode of sending complete configuration information to a source station server in advance before effectiveness test; in this way, when the source station server receives a source return request of a target edge server, the configuration information carried by the source return request can be compared with the configuration information stored by the source station server in detail, and the source return test result is fed back to the client in real time after comparison, so that the client can know the processing condition of the source return request in time, and corresponding operation can be performed in time according to the feedback result. The whole source return test process does not need cumbersome operations such as packet capturing by using a packet capturing tool on the source station server, and CDN configuration effectiveness test can be completed quickly and accurately. The quick and efficient test process also shortens the whole test period, and thus the efficiency and quality of the source return test work are greatly improved.

Description

Technical Field

[0001] This disclosure generally relates to the field of content delivery network technology, and more particularly to a back-to-origin testing method, computer equipment, and storage medium. Background Technology

[0002] For Content Delivery Networks (CDNs), testers first configure custom request headers, caching mechanisms, origin timeout retries, and origin URI rewriting, among other settings. Then, they access the network environment of the origin server and use specialized packet capture tools to extract CDN-related data packets from massive amounts of data. The extracted packets are then manually compared and analyzed to determine if the configuration is working as expected. This entire testing process is not only time-consuming and labor-intensive, but also susceptible to factors such as network environment and proficiency with packet capture tools, resulting in low accuracy and reliability of test results and making automated testing difficult. Summary of the Invention

[0003] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide a back-to-origin testing method, computer equipment and storage medium. The entire back-to-origin testing process does not require cumbersome operations such as using packet capture tools on the origin server, and can quickly and accurately complete the CDN configuration effectiveness test. The fast and efficient testing process also shortens the entire testing cycle, thereby greatly improving the efficiency and quality of back-to-origin testing.

[0004] Firstly, this application provides a back-to-origin testing method applied to a content delivery network, the content delivery network including origin server nodes and multiple edge server nodes, the method comprising:

[0005] When the origin configuration has been completed in the content delivery network system, the origin server node responds to the configuration effectiveness test request initiated by the client, extracts the first configuration information from the configuration effectiveness test request and stores it in the configuration table;

[0006] In response to a back-to-origin request initiated by a target edge service node, the second configuration information carried in the back-to-origin request is matched with the configuration table; the target edge service node is an edge service node among the plurality of edge service nodes that has a back-to-origin requirement;

[0007] The origin test result is determined based on the matching result, and the origin test result is fed back to the client; the origin test result is used to characterize whether the origin configuration is effective.

[0008] In conjunction with the first aspect, in one possible implementation, matching the second configuration information carried in the origin request with the configuration table includes:

[0009] If the second configuration information includes test type, request ID, and second test information, determine whether the test type matches the preset test type;

[0010] If the test type matches the preset test type, then look up the request ID in the configuration table;

[0011] If the request ID is found in the configuration table, the first information to be tested and the second information to be tested in the configuration table are matched; the first information to be tested belongs to the first configuration information.

[0012] In conjunction with the first aspect, in one possible implementation, matching the first test information and the second test information in the configuration table includes:

[0013] When the test type is a custom request header and the configuration table is a custom request header table, the key entry value in the first test information is matched with the key parameter in the second test information;

[0014] If the key entry value matches the key parameter, then the value of the value entry in the first test information is matched with the value parameter in the second test information.

[0015] In conjunction with the first aspect, in one possible implementation, matching the first test information and the second test information in the configuration table includes:

[0016] When the test type is a caching mechanism and the configuration table is a caching mechanism table, it is determined whether the count value in the second test information matches the first preset count threshold.

[0017] If the count value does not match the first preset count threshold, then determine whether the count value matches the second preset count threshold;

[0018] If the count value matches the second preset count threshold, then the time difference between the current request time and the previous request time is determined, and it is determined whether the difference between the time difference and the first preset threshold matches the cache time item value in the first test information; wherein, the current request time is the time when the client initiates the configuration effective test request this time, and the previous request time is the time when the client previously initiated the configuration effective test request.

[0019] In conjunction with the first aspect, in one possible implementation, matching the second configuration information carried in the origin request with the configuration table includes:

[0020] If the second configuration information includes a test type and a request ID, and the configuration table is a back-to-origin timeout retry table, determine whether the test type is a back-to-origin timeout retry.

[0021] If the test type is the origin timeout retry, then determine whether the request id matches the id entry value in the origin timeout retry table;

[0022] If the request ID matches the value of the id table entry, then determine whether the count table entry value and the retry table entry value in the origin timeout retry table match.

[0023] In conjunction with the first aspect, in one possible implementation, matching the first test information and the second test information in the configuration table includes:

[0024] When the test type is Origin URI rewriting and the configuration table is an Origin URI rewriting table, determine whether the URI entry value in the first test information matches the URI in the second test information.

[0025] Secondly, this application provides a back-to-origin testing method applied to a client, the method comprising:

[0026] A configuration activation test request is sent to the origin server node, the configuration activation test request carrying first configuration information; wherein, the origin server node is configured to, in the case that the origin configuration has been completed in the content delivery network system, respond to the configuration activation test request initiated by the client, extract the first configuration information from the configuration activation test request and store it in a configuration table; and, in response to the origin request initiated by the target edge service node, match the second configuration information carried in the origin request with the configuration table; the target edge service node is an edge service node among multiple edge service nodes that has an origin request requirement; and determine the origin test result based on the matching result, and feed the origin test result back to the client; the origin test result is used to characterize whether the origin configuration is effective; the multiple edge service nodes and the origin server node all belong to the content delivery network;

[0027] The second configuration information required for verification of the back-to-origin is determined based on the first configuration information, and the second configuration information is sent to the edge service node so that the edge service node can send the back-to-origin request carrying the second configuration information to the origin service node when it has a back-to-origin requirement.

[0028] Obtain the origin server service node's feedback of the back-to-origin test results.

[0029] In conjunction with the second aspect, in one possible implementation, the method further includes:

[0030] If the back-to-origin test result representation caching mechanism configuration is not effective and the cumulative number of tests is not greater than the preset number threshold, a test interface access request is sent to the target edge service node; the test interface access request carries the request ID and test type from the first configuration information;

[0031] Obtain the request response result corresponding to the test interface access request, and if the current count value matches the request ID, stop for the first preset time, update the current count value, and then execute the step of sending the test interface access request to the edge service node.

[0032] If the current count value does not match the first preset count threshold but matches the third preset count threshold, then stop for the second preset time, update the current count value, and then execute the step of sending a test interface access request to the edge service node.

[0033] If the current count value does not match the third preset count threshold but matches the fourth preset count threshold, then stop the first preset time, update the current count value, and then execute the step of sending a test interface access request to the edge service node.

[0034] If the current count value does not match the fourth preset count threshold, the cumulative number of tests is updated, and then it is determined whether the updated cumulative number of tests is greater than the preset number threshold.

[0035] Thirdly, this application provides a computer device including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the back-to-source testing method as described in the first aspect.

[0036] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the back-to-source testing method as described in the first aspect.

[0037] The origin server test method, computer equipment, and storage medium provided in this application embodiment include a method that proactively pushes configuration information to the origin server by sending complete configuration information to the origin server before the effectiveness test. This process ensures that the origin server can obtain the latest configuration content in a timely manner, providing an accurate and timely data foundation for subsequent comparison work. Thus, when the origin server receives an origin server request from the target edge server, it can meticulously compare the configuration information carried in the request with its own stored configuration information and provide real-time feedback on the origin server test results to the client after the comparison is completed. This ensures that the client can promptly understand the processing status of the origin server request and take appropriate actions based on the feedback results. The entire origin server test process eliminates the need for cumbersome operations such as packet capture on the origin server, enabling rapid and accurate CDN configuration effectiveness testing. The fast and efficient testing process also shortens the entire testing cycle, thereby greatly improving the efficiency and quality of origin server testing. Attached Figure Description

[0038] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0039] Figure 1 This is one of the flowcharts illustrating the back-to-source testing method in one embodiment;

[0040] Figure 2 This is a schematic diagram of the architecture of a back-to-source testing method in one embodiment;

[0041] Figure 3 This is a schematic diagram of the source server task interface process in one embodiment;

[0042] Figure 4 This is the second flowchart of a back-to-source testing method in one embodiment;

[0043] Figure 5 This is the third flowchart of a back-to-source testing method in one embodiment;

[0044] Figure 6 This is the fourth flowchart of a back-to-source testing method in one embodiment;

[0045] Figure 7 This is the fifth flowchart illustrating the back-to-source testing method in one embodiment;

[0046] Figure 8 This is the sixth flowchart of a back-to-source testing method in one embodiment;

[0047] Figure 9 This is the seventh flowchart of a back-to-source testing method in one embodiment;

[0048] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0049] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0050] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0051] First, the relevant terms used in this application will be explained:

[0052] CDN: A service that caches and delivers website content through globally deployed server nodes, primarily used to accelerate content delivery, improve user experience, and reduce the load on origin servers.

[0053] Client: refers to the party that actively initiates requests and receives service responses in network communication.

[0054] Server-side: A targeted service program. The server serves the client, providing services such as offering resources and storing client data.

[0055] CDN edge servers are a group of servers deployed throughout a CDN to cache content closer to end users and accelerate the transmission of internet content. As a component of the CDN, edge servers store copies of content from the origin server and provide services directly to users, reducing reliance on the central origin server.

[0056] Origin server: A server that stores the original content of a website, usually a web server, responsible for handling user requests and returning the original content.

[0057] Origin pull: This refers to the process where, when the content requested by a user does not exist on the CDN edge server or the cache has expired, the CDN edge server sends a request to the origin server to retrieve the latest content and return it to the user.

[0058] 502: A Hypertext Transfer Protocol (HTTP) status code that indicates that a gateway or proxy server has received an invalid response, usually caused by a communication failure between servers.

[0059] For CDNs, testers first configure custom request headers, caching mechanisms, origin timeout retries, and origin URI rewriting, among other settings. Then, they go to the network environment where the origin server is located and use professional packet capture tools to extract data packets related to the CDN configuration from massive amounts of data packets. The extracted data packets are then manually compared and analyzed to determine whether the configuration is working as expected. The entire testing process is not only time-consuming and labor-intensive, but also easily affected by factors such as network environment and proficiency in using packet capture tools. This results in low accuracy and reliability of the test results and makes automated testing difficult.

[0060] For example, with custom request header configuration, testers need to verify whether the CDN correctly processes and forwards the request headers as expected, such as whether specific custom request headers have been added. After configuring custom request headers in the CDN, testers initiate a request on the client side, capture packet information on the origin server, find the request, and check whether the request headers carry the configured custom request information.

[0061] For caching mechanism configuration, testers need to verify whether the CDN can correctly cache and update content according to preset caching strategies, such as cache expiration time and caching rules. This involves checking the cache hit rate and the effectiveness of the update mechanism after cache expiration. After configuring the caching mechanism in the CDN, testers initiate multiple requests from the client, checking the CDN hit status and whether the cached time in the CDN has expired. Within the cached time, they capture packets on the origin server to check if the request returns to the origin server, and after the cache expires, they capture packets on the origin server to check if the request returns to the origin server.

[0062] Configure the origin server timeout and retry count to specify the number of origin server requests sent by the CDN edge server and the timeout period. After configuring the origin server timeout and retry in the CDN, testers initiated a request on the client side and verified the number of requests sent by the CDN edge server and the time interval between each request by capturing packets on the origin server.

[0063] For origin URI rewriting configuration, testers must ensure that the CDN correctly rewrites the request URI according to the configuration requirements, and that the rewritten parameters take effect correctly in subsequent request processing. After configuring origin URI rewriting in the CDN, testers also need to configure the corresponding rewritten resources on the origin server. When a request is initiated from the client, packet capture information is performed on the origin server to locate the request, verify whether the URI in the request is the rewritten URI, and also verify whether the resource returned to the client is the rewritten resource.

[0064] During testing of the above configurations, testers typically need to access the network environment of the origin server and use professional packet capture tools (such as Wireshark and tcpdump) to capture and analyze network traffic. This capture process requires careful screening and filtering of relevant network request packets to extract information packets related to the CDN configuration from a massive amount of data. These packets are then manually compared and analyzed to determine if the configuration is working as expected. This process is not only time-consuming and labor-intensive but also easily affected by factors such as network environment and proficiency with the packet capture tools, making it difficult to guarantee the accuracy and reliability of the verification results. Furthermore, it is difficult to automate the testing using automated scripts.

[0065] To address the aforementioned technical problems, this application provides a back-to-origin testing method, a computer device, and a storage medium. The back-to-origin testing method is applied to a content delivery network system, which includes an origin server node and multiple edge server nodes.

[0066] To facilitate understanding of the source-following testing method provided in this application, the following exemplary embodiments will provide a detailed description of the method. It is understood that these exemplary embodiments can be combined with each other, and similar or identical concepts or processes may not be repeated in some embodiments.

[0067] refer to Figure 1 This is a flowchart illustrating the back-to-source testing method provided in an embodiment of this application, as shown below. Figure 1 As shown, the back-to-source testing method includes the following steps 101 to 103.

[0068] Step 101: If the origin configuration has been completed in the content delivery network system, the origin server node responds to the configuration activation test request initiated by the client, extracts the first configuration information from the configuration activation test request, and stores it in the configuration table.

[0069] It should be noted that the origin server configuration completed in step 101 includes, but is not limited to, custom request header configuration, caching mechanism configuration, origin server timeout retry configuration, and origin server URI rewriting configuration, and other configurations. Furthermore, all of the above configurations can be completed by testers using the client to send configuration parameters to the specified software or interface in the CDN.

[0070] The configuration activation test request generated by the client can be determined based on the type of test that has been completed. For example, when a custom request header configuration has been completed, the corresponding configuration activation test request is used to test whether the custom request header has taken effect; when a caching mechanism configuration has been completed, the corresponding configuration activation test request is used to test whether the caching mechanism has taken effect; when an origin timeout retry configuration has been completed, the corresponding configuration activation test request is used to test whether the origin timeout and retry count have taken effect; and when an origin URI rewriting configuration has been completed, the corresponding configuration activation test request is used to test whether the origin URI rewriting has taken effect.

[0071] The configuration table varies depending on the test type. For example, the configuration table for a test with a custom request header is the custom request header table; the configuration table for a test with a caching mechanism is the caching mechanism table; the configuration table for a test with a timeout retry is the timeout retry table; and the configuration table for a test with a rewritten URI is the rewritten URI table.

[0072] Similarly, the first configuration information extracted from the configuration activation test request will also differ depending on the test type. For example, the first configuration information mainly includes the test type ID and the first information to be tested, which are stored as entries in the corresponding configuration table. It is understandable that the test type ID can be one of the following: a custom request header ID, a cache configuration ID, an origin timeout retry ID, or an origin URI rewrite ID.

[0073] Step 102: In response to the origin request initiated by the target edge service node, match the second configuration information carried in the origin request with the configuration table; the target edge service node is an edge service node with origin request among multiple edge service nodes.

[0074] It should be noted that in step 102, when a resource of one of the multiple edge service nodes is not cached and triggers the origin request behavior, the origin service node can first determine the edge service node as the target edge service node that actually initiates the origin request, then extract the second configuration information carried by it from the origin request, and then match the second configuration information with the pre-stored configuration table item by item.

[0075] For example, specifically, when the test type is a custom request header and the corresponding first configuration information includes type, request id, and key and value parameters for random number generation, the corresponding second configuration information may include the key and value parameters of the custom request header.

[0076] When the test type is a caching mechanism and the corresponding first configuration information includes type, request id, and cache time generated by random number, the corresponding second configuration information may include cache time.

[0077] When the test type is origin timeout retry and the corresponding first configuration information includes type, request id, and origin timeout time and retry count generated by random number, the corresponding second configuration information can include origin timeout time and retry count.

[0078] When the test type is origin URI rewriting and the corresponding first configuration information includes type, request id, and URI generated by random number, the corresponding second configuration information includes this URI.

[0079] Step 103: Determine the origin test result based on the matching result and send the origin test result back to the client; the origin test result is used to indicate whether the origin configuration is effective.

[0080] It should be noted that when the origin server service node matches the second configuration information carried in the origin request with the pre-stored configuration table item by item, it can determine the origin test result that represents whether the origin configuration is effective based on the matching result, and feed the origin test result back to the client; thus completing the automated test loop.

[0081] For example, refer to Figure 2 The schematic diagram of the back-to-source testing method shown is as follows: Figure 2 As shown, the tester sends a test request to the client; after receiving the test request, the client begins the test; simultaneously, tests are performed on custom request headers, caching mechanisms, origin retrieval timeout retry, and origin URI rewriting, and the origin test results are obtained and saved to the client; after the test is completed, all information recorded in the test record table is returned to the client as the origin test results. By viewing the test results, the client can determine whether the test was successful or failed, check the test type to determine which type of test failed, check the ID to locate which test of the test type failed, and check the configuration information to locate the reason for the failure.

[0082] Figure 2The client can send a configuration validity test request to the task interface of the origin server node, carrying the test type, test ID, and configuration information; it can also send the second configuration information to be tested to the CDN server; it can also send a request to the CDN server, carrying the test type and ID; it can also obtain the test results. If the test result is that the verification is passed, the test ends. If the test result is that the verification is failed, it checks whether the cumulative number of retries is greater than or equal to the retry threshold set by the system. If it is greater than or equal to the retry threshold, the test ends and the test failure is sent to the origin server node for recording.

[0083] for Figure 2 For the origin server service node in the process, it can listen to different ports, initialize tables, and set task interface processes. Specifically, the initialization table can initialize a custom request header table, a caching mechanism table, a back-to-origin timeout retry table, a back-to-origin URI rewriting table, and a test record table.

[0084] For the custom request table, its entries can be custom request header id, key, and value; this table is used to store custom request header configurations.

[0085] For the caching mechanism table, its entries can be cache configuration id, cache age, and time. The initial value of time is 0 by default. This table is used to store the caching mechanism configuration.

[0086] For origin pull timeout retries, the table entries are origin pull timeout id, origin pull port (port), time (default initial value is 0), origin pull timeout duration (timeout), count (default initial value is 0), number of retries (retry), and result (result); this table is used to store the origin pull timeout retries configuration.

[0087] For origin URI rewriting, the table entries can be origin URI id or URI; this table is used to store origin URI rewriting configuration.

[0088] The test record table contains test type, test ID, configuration information, and test result; this table is used to store test records in automated testing.

[0089] The task interface setup process includes: After receiving the configuration activation test request from the client, the task interface of the origin server node first determines the test type. If it is a custom request header, cached configuration, origin timeout retry, or origin URI rewriting, the first configuration information carried in the configuration activation test request is inserted into the corresponding table; otherwise, an error message is returned indicating that the test type cannot be recognized. This application does not specify the order in which the test type is determined.

[0090] For example, refer to Figure 3 The diagram shown illustrates the source server task interface flow. Figure 2 In this example, the test type is evaluated in the following order: custom request header → cache configuration → origin timeout retry → origin URI rewriting. Of course, other orders can also be used.

[0091] The origin server test method provided in this application proactively pushes configuration information by sending complete configuration information to the origin server before the validity test. This process ensures that the origin server can obtain the latest configuration content in a timely manner, providing an accurate and timely data foundation for subsequent comparison work. Thus, when the origin server receives the origin server request from the target edge server, it can meticulously compare the configuration information carried in the request with its own stored configuration information, and provide real-time feedback on the origin server test results to the client after the comparison is completed. This ensures that the client can promptly understand the processing status of the origin server request and take appropriate actions based on the feedback results. The entire origin server test process eliminates the need for cumbersome operations such as packet capture on the origin server, enabling rapid and accurate CDN configuration effectiveness testing. The fast and efficient testing process also shortens the entire testing cycle, thereby greatly improving the efficiency and quality of origin server testing.

[0092] Based on the above Figure 1 In one example embodiment of the method shown, step 102 involves matching the second configuration information carried in the origin request with the configuration table. The specific process in this embodiment can be achieved through... Figure 4 Steps 201 to 203 shown are implemented.

[0093] Step 201: If the second configuration information includes the test type, request ID, and second test information, determine whether the test type matches the preset test type.

[0094] Step 202: If the test type matches the preset test type, then look up the request ID in the configuration table.

[0095] Step 203: If the request ID is found in the configuration table, then match the first and second information to be tested in the configuration table; the first information to be tested belongs to the first configuration information.

[0096] Specifically, after the origin service node receives the origin request initiated by the target edge service node, it first extracts the test type from the second configuration information carried in the origin request. If it is determined that the extracted test type is the test type that needs to be verified, it searches its own pre-stored corresponding configuration table for a test ID that is the same as the request ID, based on the request ID in the second configuration information. If a test ID that is the same as the request ID is found in the corresponding configuration table, the first test information in the configuration table is then matched with the second configuration information.

[0097] In short, if it is determined that the extracted test type is not the test type that needs to be verified, the test ends; if no test ID with the same request ID is found in the corresponding configuration table, the verification fails, and the test result is "ID mismatch" and the test type, test ID and first test information are stored in the test record table.

[0098] Through the above technical solutions, the embodiments of this application realize automated verification of multiple types of back-to-source configurations. The hierarchical matching mechanism ensures the integrity and accuracy of configuration verification, the test type filtering mechanism avoids invalid data processing, the request ID retrieval mechanism ensures the reliability of configuration association, and the automatic parameter comparison mechanism improves verification efficiency. This solution can effectively identify scenarios where the configuration has not taken effect. For example, when there is a difference between the request parameters of the edge node and the storage configuration of the source station, the matching failure result can be immediately fed back, which significantly reduces the time cost and error rate of manual verification.

[0099] Based on the above Figure 4 In one example embodiment of the method shown, step 203 involves matching the first and second test information in the configuration table. The specific process of this matching can be described in this embodiment. Figure 5 Steps 301 and 302 shown are implemented.

[0100] Step 301: When the test type is a custom request header and the configuration table is a custom request header table, match the key entry value in the first test information with the key parameter in the second test information.

[0101] Step 302: If the key entry value matches the key parameter, then match the value entry value in the first test information with the value parameter in the second test information.

[0102] Specifically, for custom request header testing, the origin server service node's origin port (e.g., port 80) receives an origin request that can be denoted as a / test_header request. The second test information carried in the / test_header request includes the test type, request ID, key parameter, and value parameter. If the test type is a custom request header and a test ID matching the request ID is found in the custom request header table, it is determined whether the key entry value in the first test information is the same as the key parameter in the second test information. If the key entry value and the key parameter are different, it is determined that the key entry value is not in the request header of the / test_header request. At this time, the verification fails, and the origin test result, which indicates that the request header key parameter is not effective, along with the test type, request ID, key parameter, and value parameter, are stored in the test record table.

[0103] If the value of the key entry is the same as the key parameter, then the value of the key entry is determined to be in the request header of the / test_header request. At this point, it is further determined whether the value of the value entry in the first test information is the same as the value parameter in the second test information. If the value of the value entry is the same as the value parameter, then the value of the value entry is determined not to be in the request header of the / test_header request. At this point, the verification fails, and the test result, which is that the request header value parameter is not effective, along with the test type, request ID, key parameter, and value parameter, are stored in the test record table.

[0104] If the value of the value entry is the same as the value parameter, then the value of the value entry is determined to be in the request header of the / test_header request. At this time, the client can be fed back the test result indicating that the test passed. The test result indicating that the custom request header test passed, as well as the test type, request ID, key parameter and value parameter, are stored in the test record table.

[0105] It should be noted that before executing the custom request header test process on the origin server node, the following client process should first be executed on the client:

[0106] (1) Set the test type (type) to a custom request header, generate the request ID using a timestamp, use a random number for the key and value parameters, and send a configuration activation test request carrying the type, request ID, key and value parameters to the task interface set by the origin server service node, and then proceed to (2).

[0107] (2) Set the request header key to be the same as the key parameter, the request header value to be the same as the value parameter, and set the origin port to 80. Send the custom request header configuration information to be verified to the CDN service node, and go to (3).

[0108] (3) Set number to 0, start the loop test, and go to (4).

[0109] (4) Determine whether number is greater than or equal to the retry threshold set by the same method. If yes, end the test and send the failed custom request header to the origin server service node for recording. Otherwise, if no, proceed to (5).

[0110] (5) Send a request to the CDN service node to access the / test_header interface. The request carries type and id. The type is the same as the type in (1), and the id is the same as the request id in (1). Then go to (6).

[0111] (6) Obtain the back-to-origin test result fed back by the origin service node. If the back-to-origin test result indicates that the verification has passed, the effective test for the custom request header is completed; otherwise, if the back-to-origin test result indicates that the verification has failed, increment number by 1 and go to (4).

[0112] An exemplary embodiment for validating custom request headers:

[0113] The system test retry threshold is set to 3, the test type is custom request header, the request ID is 1749891804, the custom request header key parameter is 123, and the custom request header value parameter is 456.

[0114] The client-side process includes the following steps 1) to 7):

[0115] 1) Send a configuration activation parameter request to the task interface set on the origin server service node, carrying parameters type 1, id 1749891804, key 123 and value 456, then proceed to 2).

[0116] 2) Send a custom request header configuration to the CDN service node with a request header key parameter of 123, a request header value parameter of 456, and an origin port of 80. (Go to 3).

[0117] 3) Set number to 0, start the loop test, go to 4).

[0118] 4) Check if number is greater than or equal to 3. If yes, end the test and send the failed custom request header to the origin server node for recording; otherwise, go to step 5).

[0119] 5) Send a request to the CDN service node to access the / test_header interface, with type 1 and id 1749891804 in the request, then proceed to step 6).

[0120] 6) Obtain the origin server service node's feedback on the back-to-origin test result, and determine whether the back-to-origin test result indicates that the verification has passed. If yes, complete the test; if no, increment number by 1 and go to step 4.

[0121] The server-side includes the task assignment process and the business process:

[0122] Task distribution process: The task interface of the origin server service node receives the configuration activation test request initiated by the client, and determines whether the type is 1. If it is, the test id: 1749891804, key parameter: 123, and value parameter: 456 carried in the configuration activation test request are stored in the custom request header table; otherwise, an error message that the type cannot be recognized is returned.

[0123] The business process includes the following 7)~11):

[0124] 7) When the origin server service node receives the / test_header request on port 80, it extracts the type, id, key, and value parameters from the / test_header request, and determines whether the type is 1. If not, it returns the end; otherwise, it proceeds to step 8.

[0125] 8) Obtain the id 1749891804 from the / test_header request, search for this id in the custom request header table. If it is not found, return a validation failure and store the test result "id mismatch" along with the type, id, key, and value parameters in the test record table. Otherwise, if it is found, proceed to 9).

[0126] 9) Retrieve the key: 123 from the entry in the custom request header table, and determine whether the key: 123 corresponds to the key parameter in the / test_header request header. If they do not correspond, return a verification failure, and store the test result that the request header key parameter is not effective, along with the type, id, key, and value parameters for this test, in the test record table; if they correspond, proceed to 10).

[0127] 10) Retrieve the value: 456 from the entry in the custom request header table. Determine if the value: 456 corresponds to the value parameter in the / test_header request header. If they do not correspond, return a verification failure and store the test result (the request header value parameter is not effective) along with the type, id, key, and value parameters in the test record table. If they correspond, return a verification success to the client and store the test result (custom request header test successful) along with the type, id, key, and value parameters in the test record table. Proceed to 11).

[0128] 11) After the test is completed, generate the back-to-origin test results and check whether the custom request header test passed. If it fails, check the reason for the failure.

[0129] As can be understood from the above examples of verifying custom request headers, testers do not need to capture packets multiple times on the origin server to check whether the custom request headers configured in the CDN are effective. Instead, they only need to rely on the return information received by the client to quickly and accurately verify whether the CDN's custom request header configuration is effective.

[0130] Based on the above Figure 4 In one example embodiment of the method shown, step 203 involves matching the first and second test information in the configuration table. The specific process of this matching can be described in this embodiment. Figure 6 Steps 401 to 403 shown are implemented.

[0131] Step 401: If the test type is a caching mechanism and the configuration table is a caching mechanism table, determine whether the count value in the second test information matches the first preset count threshold.

[0132] Step 402: If the count value does not match the first preset count threshold, then determine whether the count value matches the second preset count threshold.

[0133] Step 403: If the count value matches the second preset count threshold, determine the time difference between the current request time and the previous request time, and determine whether the difference between the time difference and the first preset threshold matches the cache time table item value in the first test information.

[0134] The current request time is the time when the client initiated the configuration activation test request this time, and the previous request time is the time when the client previously initiated the configuration activation test request.

[0135] For example, the first preset counting threshold is 0, the second preset counting threshold is 3, and the first preset threshold is 1.

[0136] Specifically, for caching mechanism testing, the origin server service node's origin port (e.g., port 80) receives a request for the origin server to perform a cache request, which can be recorded as a / test_cache request. The second test information carried in the / test_cache request includes the test type (type), request ID, and count value (count parameter). If the test type is caching mechanism and a test ID with the same request ID is found in the cache mechanism table, it is determined whether the count parameter is 0. If the count parameter is 0, the time of this request is recorded in the time entry of the cache mechanism table, and the request ID of this request is fed back to the client. If the count parameter is not 0, it is determined whether the count parameter is 3.

[0137] If the count parameter is not 3, the verification fails, and the test result indicating that the caching mechanism is ineffective, along with the type, request id, and count parameters, is stored in the test record table. Conversely, if the count parameter is 3, the current request time is subtracted from the previous request time recorded in the aforementioned time table entry. The difference obtained by subtracting 1 from the time difference is then compared with the cache time in the cache time (age) table of the caching mechanism table. If the difference is not equal to the cache time in the age table entry, the verification fails, and the test result indicating that the caching mechanism is ineffective, along with the type, request id, and count parameters, is stored in the test record table. If the subtraction result is equal to the cache time in the age table entry, the client is fed back with the request id + the cache time in the age table entry, indicating that the verification passes, and the test result indicating that the caching mechanism test passes, along with the type, request id, and count parameters, is stored in the test record table.

[0138] It should be noted that before executing the caching mechanism test process on the origin server node, the following client process should first be executed on the client:

[0139] (1) Set the test type to caching mechanism, use timestamp to generate request id, use random number to generate cache time age (range: system set age threshold); send configuration effective test request to the task interface of the source server service node, carrying type, request id and age parameters, and then (2).

[0140] (2) Set the cache time to be the same as the cache time randomly generated in (1), set the origin port to 80, send the cache mechanism configuration information to be verified to the CDN service node, and go to (3).

[0141] (3) Set number to 0, start the loop test, and go to (4).

[0142] (4) Determine whether number is greater than or equal to the retry threshold set by the system. If yes, return that the caching mechanism test failed and record the result to the source server service node; otherwise, go to (5).

[0143] (5) Set the count value to 0 and go to (6).

[0144] (6) Send a request to the CDN service node to access the / test_cache interface, carrying the parameters type, id and count. The type here is the same as the caching mechanism set in (1), and the id is the same as the randomly generated request id in (1). Go to (7).

[0145] (7) Obtain the origin test result returned by the origin service node, and determine whether the returned origin test result is the requested request ID. If it is the request ID, proceed to (8); otherwise, if it is not the request ID, proceed to (11).

[0146] (8) Determine if count is 0. If it is 0, stop for 1 second, increment count by 1, and go to (6); if it is not 0, go to (9).

[0147] (9) Determine if count is 1. If it is 1, stop time is the cache time generated in (1) - 1, count + 1, go to (6); otherwise, if it is not 1, go to (10).

[0148] (10) Determine if count is 2. If it is 2, stop for 1 second, increment count by 1, and go to (6); otherwise, if it is not 2, increment number by 1 and go to (4).

[0149] (11) Determine whether the back-to-origin test result returned by the origin service node is the cache time in the id+age table of this request. If yes, the test ends; otherwise, number+1 and go to (4).

[0150] An exemplary embodiment of the verification caching mechanism:

[0151] The system test retry threshold is 3, the cache time age threshold is 300, the test type is caching mechanism, the request ID is 1751956527, and the cache time age is 30.

[0152] The client-side process includes the following steps 1) to 11):

[0153] 1) Send a configuration activation test request to the task interface of the origin server node, carrying parameters type 2, test id 1751956527, age 30, and forward to step 2.

[0154] 2) Send caching mechanism configuration information with a cache time of 30 seconds and a return port of 80 to the CDN service node, then proceed to 3).

[0155] 3) Set number to 0, then go to step 4.

[0156] 4) Determine if number is greater than or equal to the system-set retry threshold 3. If yes, return that the caching mechanism test failed and record the result to the origin server service node; otherwise, go to step 5.

[0157] 5) Set count to 0, then proceed to 6).

[0158] 6) Send a request to the CDN service node to access the / test_cache interface, carrying parameters including type 2, id 1751956527 and count, then go to 7).

[0159] 7) Obtain the origin test result returned by the origin server service node, and determine whether the returned origin test result is 1751956527. If it is 1751956527, then go to 8); otherwise, if it is not 1751956527, then go to 11).

[0160] 8) Check if count is 0. If it is 0, stop for 1 second, increment count by 1, and go to step 6; if it is not 0, go to step 9.

[0161] 9) Check if count is 1. If it is 1, stop the cache time generated in step 1) - 1, increment count by 1, and go to step 6); otherwise, if it is not 1, go to step 10).

[0162] 10) Check if count is 2. If it is 2, stop for 1 second, increment count by 1, and go to step 6. Otherwise, if it is not 2, increment number by 1 and go to step 4.

[0163] 11) Determine if the origin server service node returns the origin test result as 1751956557 (i.e., 1751956527+30). If yes, the test ends; otherwise, increment number by 1 and go to step 4.

[0164] The server-side includes the task assignment process and the business process:

[0165] Task distribution process: The task interface of the origin server service node receives the configuration effectiveness detection request initiated by the client, and determines whether the type is 2. If the type is 2, the test id: 1751956527 and age: 30 in the configuration effectiveness detection request are stored in the cache mechanism table; if the type is not 2, an error message that the type cannot be identified is returned.

[0166] The business process includes the following 12) to 18):

[0167] 12) When the origin server service node receives the / test_cache request on port 80, it extracts the type, id, and count from the / test_cache request, and determines whether the type is 2. If it is not 2, it returns the end; otherwise, if it is 2, it goes to 13).

[0168] 13) Retrieve the id: 1751956527 from the / test_cache request. Use this id: 1751956527 to search the cache mechanism table. If no matching test id is found, return a verification failure and store the test result (id mismatch) along with the type, id, and age of this test in the test record table. Otherwise, if a matching test id is found, proceed to 14).

[0169] 14) Check if count is 0. If it is 0, store the current request time (1751956587) in the time table of the cache mechanism table and return the id of this request (1751956527) to the client; otherwise, if it is not 0, go to 15).

[0170] 15) Check if count is 3. If it is 3, go to 16); otherwise, if it is not 3, return that the validation failed and store the test result that the caching mechanism is not effective, as well as the type, id, and count of this test, in the test record table.

[0171] 16) Subtract the cache time (1751956587) from the time table entry in 14) of the current request time (1751956618). Determine if the time difference (31-1) equals the cache time (30) in the age table of the cache mechanism table. If they are not equal, return a verification failure and store the test result (cache time not effective) along with the type, id, and count of this instance in the test record table. Otherwise, if they are equal, proceed to 17).

[0172] 17) Return 1751956557 (i.e., 1751956527+30) to the client, indicating that the verification passed. The test result is that the caching mechanism passed the test, and the type, id, and count are stored in the test record table. Proceed to 18).

[0173] 18) After the test is completed, generate the test results and check whether the caching mechanism test passed. If it fails, check the reason for the failure.

[0174] As can be understood from the above examples of verifying the caching mechanism, testers do not need to capture packets multiple times on the origin server to check whether the caching mechanism configured in the CDN is effective. Instead, they only need to verify whether the CDN's caching mechanism configuration is effective based on the return information received by the client.

[0175] Based on the above Figure 1 In one example embodiment of the method shown, step 102 involves matching the second configuration information carried in the origin request with the configuration table. The specific process in this embodiment can be achieved through... Figure 7 Steps 501 to 503 shown are implemented.

[0176] Step 501: If the second configuration information includes the test type and request ID, and the configuration table is the origin timeout retry table, determine whether the test type is origin timeout retry.

[0177] Step 502: If the test type is Origin Timeout Retry, then determine whether the request ID matches the id entry value in the Origin Timeout Retry table.

[0178] Step 503: If the request ID matches the value in the id table, then determine whether the count value in the origin timeout retry table matches the value in the retry table.

[0179] Specifically, for origin server timeout retries, the origin server service node first determines whether the test type carried in the / test_restry request is origin server timeout retries. If not, it returns the test end; otherwise, if it is an origin server timeout retries, it extracts the origin port parameter from the / test_restry request, queries the origin server timeout retries table with the origin port parameter in the request, and obtains the request ID in the / test_restry request.

[0180] The test checks if the request ID matches the value of the `id` entry in the Origin Timeout Retry table. If they don't match, the test fails and the result (ID mismatch) along with the test type and request ID is stored in the test record table. Conversely, if they match, the test retrieves the `count` and `retry` entries from the Origin Timeout Retry table. It then checks if the `count` and `retry` values ​​are equal. If they don't match, the test clears all entries in the Origin Timeout Retry table, returns a failed test result, and stores the `result` record, the test type, and request ID in the test record table. Conversely, if the `count` and `retry` values ​​match, the test clears all entries in the Origin Timeout Retry table, returns a successful test result, and stores the test type and request ID in the test record table.

[0181] It should be noted that the values ​​of the count and retry entries in the origin timeout retry table are determined by the origin timeout retry business process on the server side, which includes the following (1) to (4):

[0182] (1) When the source server service node receives the synchronization packet (syn packet), it queries the source timeout retry table through the request port, obtains the values ​​of each table entry, and determines whether the time table entry value is 0. If the time table entry value is not 0, it proceeds to (2); otherwise, if the time table entry value is 0, it sets the time table entry value to the first current timestamp and determines whether the count table entry value is 0. If the count table entry value is 0, it increments the count table entry value by 1 and ends; otherwise, if the count table entry value is not 0, it proceeds to (4).

[0183] (2) Use the second current timestamp - the first timestamp in the time table entry to determine whether the timestamp difference is equal to the timeout entry value. If the timestamp difference is equal to the timeout entry value, then go to (3); otherwise, if the timestamp difference is not equal to the timeout entry value, then record the result in the entry as the timeout period is not effective and end.

[0184] (3) Determine whether the count entry value is greater than the retry entry value. If the count entry value is greater than the retry entry value, go to (4); otherwise, if the count entry value is not greater than the retry entry value, set the time entry value to the current timestamp, increment the count entry value by 1, and end.

[0185] (4) The result record in the table is not effective for the number of retries, and the process ends.

[0186] It should be noted that before the origin server service node executes the origin timeout retry test process, the following client processes (5) to (12) are executed on the client first:

[0187] (5) Set type to origin timeout retry, use timestamp to generate request id, use random number to generate origin timeout (range: system set timeout threshold), and random number to generate retry count (range: system set retry threshold); send configuration effective test request to the task interface of origin service node, carrying type, request id, timeout and retry parameters, and go to (6).

[0188] (6) Set the origin timeout time to be the same as the timeout in (5) and the number of retries to be the same as the retry in (5). Set the origin port to the origin retry port (range: system set origin port retry threshold). Send the origin timeout retry configuration information to be verified to CDN and go to (7).

[0189] (7) Set number to 0, start the loop test, go to (8).

[0190] (8) Determine whether number is greater than or equal to the retry threshold set by the system. If yes, end the test and send the failed retry test due to timeout to the source server service node for recording. Otherwise, if not, proceed to (9).

[0191] (9) Send a request to the CDN service node to access the / test_retry interface, then proceed to (10).

[0192] (10) After obtaining the response from the CDN, determine whether the response is 502. If it is 502, go to (11); otherwise, if it is not 502, increment number by 1 and go to (8).

[0193] (11) Access the / test_retry interface of the origin server service node. The access request carries type, id and port. The type here is the same as the type in (5), the id here is the same as the request id in (5), and the port here is the same as the return port set in (6). Go to (12).

[0194] (12) Obtain the back-to-origin test result returned by the source service node, and determine whether the back-to-origin test result is verified. If it is verified, the test is completed; otherwise, if it is not verified, number+1 and go to (8).

[0195] An exemplary embodiment for verifying origin timeout retries:

[0196] The system test retry threshold is 3, the retry timeout threshold is 10, the retry count threshold is 6, the origin port retry threshold is [82-100], the test type is origin timeout retry, the request ID is 1751962856, the origin timeout timeout is 5, and the retry count is 3.

[0197] The client-side process includes the following steps 1) to 8):

[0198] 1) Send a configuration activation test request to the task interface of the origin server node, carrying type 3, id 1751962856, timeout 5, retry 3, and forward to step 2.

[0199] 2) Send a configuration to the CDN server with a timeout of 5 seconds, 3 retries, and port 85 for origin pull. (Go to step 3).

[0200] 3) Set number to 0, start the loop test, go to 4).

[0201] 4) Determine if number is greater than or equal to the system-set retry threshold of 3. If it is 3, end the test and send the failed timeout retry test to the origin server node for recording; otherwise, if it is not 3, proceed to step 5.

[0202] 5) Send a request to the CDN service node to access the / test_retry interface, then proceed to 6).

[0203] 6) After obtaining the response returned by the CDN, check if it is a 502 error. If it is not a 502 error, increment the number by 1 and go to step 4. Otherwise, if it is a 502 error, go to step 7.

[0204] 7) Access the server's / test_retry interface, carrying parameters type 3, id 1751962856, and port 85, then redirect to step 8.

[0205] 8) Obtain the origin server service node's back-to-origin test result, determine whether the back-to-origin test result is a successful verification, if yes, complete the test, otherwise increment number by 1 and go to 4).

[0206] The server-side includes the task assignment process, the business processes shown in 9) to 12), and the query process shown in 13) to 16).

[0207] Task distribution process: When the task interface of the origin server service node receives the configuration activation test request, it determines whether the type is 3. If it is 3, it stores the id: 1751962856, timeout: 5, and retry: 3 in the configuration activation test request into the origin timeout retry table; if it is not 3, it returns an error message that the type cannot be identified.

[0208] Business process:

[0209] 9) When the origin server node receives the synchronization packet (SYN packet), it queries the origin timeout retry table on port 85, obtains each table entry, and determines whether the value of the time table entry is 0. If the value of the time table entry is not 0, it proceeds to (10); otherwise, if the value of the time table entry is 0, it sets the time table entry value to the current timestamp: 1751962900, and determines whether the value of the count table entry is 0. If the value of the count table entry is 0, it increments the count table entry value by 1 and ends; if the value of the count table entry is not 0, it proceeds to (12).

[0210] 10) Using the current timestamp: 1751962905 - the timestamp in the time table entry: 1751962900, check if the timestamp difference: 5 is the same as the value in the timeout table entry. If they are equal, go to 11). If they are not equal, record the result in the table entry as the timeout period is not effective, and end.

[0211] 11) Check if the value of the count table entry is greater than the value of the retry table entry. If it is greater, go to 12). If it is not greater, set the value of the time table entry to 1751962905, increment the value of the count table entry by 1, and end.

[0212] 12) The retries record in the table field is not effective; end.

[0213] Query process:

[0214] 13) Query port 83 to receive the / test_restry request, and determine if the type in the / test_restry request is 3. If it is not 3, return to end; if it is 3, go to 14).

[0215] 14) Extract port 85 from the / test_restry request. Query the origin timeout retry table using port 85 to obtain the id: 1751962856 from the / test_restry request. Determine if this id: 1751962856 is equal to the id entry value in the origin timeout retry table. If they are not equal, return a verification failure and store the test result "id mismatch" along with the type and id of this instance in the test record table; otherwise, if they are equal, proceed to 15).

[0216] 15) Retrieve the value of the count table and the value of the retry table (3). Check if the count in the origin timeout retry table is 3. If it is not 3, clear the values ​​of each item in the origin timeout retry table, return "validation failed", and store the record of result in the origin timeout retry table, along with the type and id here, in the test record table. Otherwise, if it is 3, clear the values ​​of each item in the origin timeout retry table, return "validation passed", and store the test result "origin timeout retry test passed" along with the type and id here in the test record table. Proceed to 16).

[0217] 16) After the test is completed, generate a test record and check whether the test passed the timeout retry test. If it failed, check the reason for the failure.

[0218] As can be understood from the above example of verifying origin timeout retries, testers do not need to capture packets multiple times on the origin server to check whether the origin timeout time and number of origin retries configured in the CDN are effective. Instead, they only need to quickly and accurately verify whether the relevant CDN configurations are effective based on the return information received by the client.

[0219] Based on the above Figure 4 In one example embodiment of the method shown, step 203 involves matching the first and second test information in the configuration table. The specific process in this embodiment can be implemented through the following steps.

[0220] When the test type is Origin URI rewriting and the configuration table is an Origin URI rewriting table, determine whether the URI entry value in the first test information matches the URI in the second test information.

[0221] It should be noted that when the test type is Origin URI rewriting and the configuration table is Origin URI rewriting table, the Origin URI rewriting test process includes the following client process (1) to (6) and server process (7) to (9).

[0222] Client-side process:

[0223] (1) Set type to origin URI rewrite, use timestamp to generate request id, and random number to generate URI; send configuration effective detection request to the task interface of origin service node, carrying type, id and URI parameters, and then (2).

[0224] (2) Set the origin URI rewrite to be the same as the URI in (1), set the origin port to 80, send the origin URI rewrite configuration to be verified to the CDN service node, and go to (3).

[0225] (3) Set number to 0, start the loop test, and go to (4).

[0226] (4) Determine whether number is greater than or equal to the retry threshold set by the system. If it is, end the test and send the failed test result to the origin server service node for recording. Otherwise, if it is not, proceed to (5).

[0227] (5) Send an HTTP request to the CDN service node to access the / test_uri interface. The HTTP request parameters include type, id, and URI parameters. The type is the same as the type in (1), and the id is the same as the id in (1). Then proceed to (6).

[0228] (6) Obtain the back-to-origin test result returned by the source service node, determine whether the back-to-origin test result is verified. If it is, complete the test. If not, increment number by 1 and go to (4).

[0229] Server-side process:

[0230] (7) When the source server service node receives an HTTP request on port 80, it extracts the type, id and URI from the HTTP request and determines whether the type is a rewrite of the origin URI. If it is not a rewrite of the origin URI, it returns to the end; otherwise, if it is a rewrite of the origin URI, it proceeds to (8).

[0231] (8) Get the id in the HTTP request, search for the test id that is the same as the id in the Origin URI Rewrite Table. If it is not found, return that the verification failed and store the test result as id inconsistency, as well as the type, id and URI of this test in the test record table; otherwise, if it is found, go to (9).

[0232] (9) Retrieve the URI from the URI table entry and determine whether the URI is in the HTTP request, that is, whether the URI is the same as the URI in the second test information. If it is not in the HTTP request, return that the verification failed and store the test result as "origin URI rewriting not effective" and the type, id and URI of this test in the test record table; otherwise, if it is in the HTTP request, return that the verification passed to the client and store the test result as "origin URI rewriting test passed" and the type, id and URI of this test in the test record table.

[0233] An exemplary embodiment for verifying origin URI rewriting:

[0234] The system test retry threshold is 3, the test type is origin URI rewriting, the request ID is 1751946023, and the origin URI is 231.

[0235] The client process is as follows: 1) ~ 6):

[0236] 1) Send a configuration activation test request to the origin server node, carrying type 4, id 1751946023, URI 231, and forward to step 2.

[0237] 2) Send the origin URI rewrite configuration to the CDN with origin URI 231 and origin port 80, then go to 3).

[0238] 3) Set number to 0, start the loop test, go to 4).

[0239] 4) Determine if number is greater than or equal to the test reset threshold 3. If it is greater than or equal to 3, end the test and send the failed test result to the origin server service node for recording; otherwise, if it is less than 3, proceed to step 5.

[0240] 5) Send a request to the CDN service node to access the / test_uri interface, carrying type 4 and id 1751946023, then forward to step 6.

[0241] 6) Obtain the origin server service node's back-to-origin test result, and determine whether the back-to-origin test result is a successful verification. If the verification is successful, the test is completed; if the verification fails, increment the number by 1 and proceed to step 4.

[0242] The server-side process includes the following task assignment process and business processes 7) to 10):

[0243] Task distribution process: The task interface of the origin server service node receives the configuration activation test request, determines whether the type is 4, and if it is 4, stores the id: 1751946023 and URI: 231 in the activation test request in the origin URI rewrite table; if it is not 4, it returns an error message that the type cannot be recognized.

[0244] Business process:

[0245] 7) When the origin server node receives the HTTP request, it extracts the type, id, and URI from the HTTP request, and determines whether the type is 4. If it is not 4, it returns the end; if it is 4, it proceeds to step 8.

[0246] 8) Obtain the id from the HTTP request: 1751946023. Search for a test id that matches this id in the origin URI rewriting table. If not found, return a validation failure and store the test result "id mismatch" along with the type, id, and URI of this test in the test record table; otherwise, if found, proceed to 9).

[0247] 9) Retrieve URI: 231 from the table entry. Determine if URI: 231 corresponds to the URI in the HTTP request. If they do not correspond, return a "validation failed" message and store the test result (origin URI rewriting not effective) along with the type, id, and URI of this request in the test record table. Otherwise, if they correspond, return a "validation passed" message to the client and store the test result (origin URI rewriting test passed) along with the type, id, and URI of this request in the test record table. Proceed to 10).

[0248] 10) After the test is completed, generate the test results and check whether the origin URI rewriting test passed. If it failed, check the reason for the failure.

[0249] As can be understood from the above example of verifying origin URI rewriting, testers only need to verify whether the CDN configuration is effective through the returned information, without needing to capture packets on the origin server node to find out whether the URI in the CDN server request information has been rewritten.

[0250] Reference Figure 8 This is a flowchart illustrating the back-to-source testing method provided in an embodiment of this application, as shown below. Figure 8 As shown, this back-to-origin testing method is applied to the client, and the method includes the following steps 601 to 603.

[0251] Step 601: Send a configuration activation test request to the origin server node, the configuration activation test request carrying first configuration information; wherein, the origin server node is used to, in the case that the back-to-origin configuration has been completed in the content delivery network system, respond to the configuration activation test request initiated by the client, extract the first configuration information from the configuration activation test request and store it in the configuration table; and respond to the back-to-origin request initiated by the target edge service node, match the second configuration information carried in the back-to-origin request with the configuration table; the target edge service node is an edge service node among multiple edge service nodes that has a back-to-origin requirement; and determine the back-to-origin test result according to the matching result, and feed back the back-to-origin test result to the client; the back-to-origin test result is used to characterize whether the back-to-origin configuration is effective; multiple edge service nodes and the origin server node all belong to the content delivery network.

[0252] Step 602: Determine the second configuration information required for origin retrieval based on the first configuration information, and send the second configuration information to the edge service node so that the edge service node can send an origin retrieval request carrying the second configuration information to the origin service node when it has an origin retrieval requirement.

[0253] Step 603: Obtain the origin test results from the origin server service node.

[0254] Specifically, when the test type is a custom request header and the corresponding first configuration information includes type, request id, and key and value parameters for random number generation, the corresponding second configuration information can include the key and value parameters of the custom request header.

[0255] When the test type is a caching mechanism and the corresponding first configuration information includes type, request id, and cache time generated by random number, the corresponding second configuration information may include cache time.

[0256] When the test type is origin timeout retry and the corresponding first configuration information includes type, request id, and origin timeout time and retry count generated by random number, the corresponding second configuration information can include origin timeout time and retry count.

[0257] When the test type is origin URI rewriting and the corresponding first configuration information includes type, request id and URI generated by random number, the corresponding second configuration information includes the origin URI rewritten.

[0258] Based on the above Figure 8 In one example embodiment, after step 603, the back-to-source testing method provided in this application further includes, as shown in the example, Figure 9 Steps 701 to 705 are shown.

[0259] Step 701: If the back-to-origin test result representation caching mechanism configuration is not effective and the cumulative number of tests is not greater than the preset number threshold, send a test interface access request to the target edge service node; the test interface access request carries the request ID and test type from the first configuration information.

[0260] Step 702: Obtain the request response result corresponding to the test interface access request. If the current count value matches the first preset count threshold when the request response result matches the request ID, stop for the first preset time, update the current count value, and then execute the step of sending the test interface access request to the edge service node.

[0261] Step 703: If the current count value does not match the first preset count threshold but matches the third preset count threshold, then stop for the second preset time, update the current count value, and then execute the step of sending a test interface access request to the edge service node.

[0262] Step 704: If the current count value does not match the third preset count threshold but matches the fourth preset count threshold, then stop for the first preset time, update the current count value, and then execute the step of sending a test interface access request to the edge service node.

[0263] Step 705: If the current count value does not match the fourth preset count threshold, then update the cumulative number of tests, and then determine whether the updated cumulative number of tests is greater than the preset number threshold.

[0264] For example, the third preset counting threshold is 1, the fourth preset counting threshold is 2, the first preset time is 1 second, the second preset time is the set cache time - 1, and the preset number of attempts threshold is the retry threshold set by the system.

[0265] Steps 701 to 705 are specifically implemented through the following (1) to (11).

[0266] (1) Set the test type to caching mechanism, use timestamp to generate request id, use random number to generate cache time age (range: system set age threshold); send configuration effective test request to the task interface of the source server service node, carrying type, request id and age parameters, and then (2).

[0267] (2) Set the cache time to be the same as the cache time randomly generated in (1), set the origin port to 80, send the cache mechanism configuration information to be verified to the CDN service node, and go to (3).

[0268] (3) Set number to 0, start the loop test, and go to (4).

[0269] (4) Determine whether number is greater than or equal to the retry threshold set by the system. If yes, return that the caching mechanism test failed and record the result to the source server service node; otherwise, go to (5).

[0270] (5) Set the current count value to 0, then proceed to (6).

[0271] (6) Send a request to the CDN service node to access the / test_cache interface, carrying the parameters type, id and count. The type here is the same as the caching mechanism set in (1), and the id is the same as the randomly generated request id in (1). Go to (7).

[0272] (7) Obtain the origin test result returned by the origin service node, and determine whether the returned origin test result is the requested request ID. If it is the request ID, proceed to (8); otherwise, if it is not the request ID, proceed to (11).

[0273] (8) Determine whether count is the first preset counting threshold (e.g., 0). If it is 0, stop for 1 second, update the current count value by count+1, and go to (6); if it is not 0, go to (9).

[0274] (9) Determine if count is 1. If it is 1, stop time is the cache time generated in (1) - 1, then update the current count value by count + 1, and go to (6); otherwise, if it is not 1, go to (10).

[0275] (10) Determine if count is 2. If it is 2, stop for 1 second and update the current count value by count+1, then go to (6); otherwise, if it is not 2, update the cumulative number of tests by number+1, then go to (4).

[0276] (11) Determine whether the back-to-origin test result returned by the origin service node is the cache time in the id+age table of this request. If yes, the test ends; otherwise, number+1 and go to (4).

[0277] It should be noted that for testing client-side features such as custom request headers, caching mechanisms, origin timeout retries, and origin URI rewriting, please refer to the aforementioned examples. These will not be repeated here.

[0278] This application not only reduces operational steps and avoids the complex operation of packet capture, greatly simplifying the verification process; it also enables automated verification, with the system automatically triggering operations such as sending configuration information to the source server node, performing comparisons, and providing feedback results, eliminating the need for manual intervention by testers at each stage; it also reduces labor costs, as the reduction of tedious packet capture operations and manual comparison and analysis processes lowers the professional skill requirements for testers; it also reduces time costs, with the efficient verification process shortening the entire testing cycle; and it provides accurate feedback on test results, as the source server node can provide detailed verification information to the client, allowing testers to clearly see the configuration comparison results and helping them quickly locate problems.

[0279] The following is for reference. Figure 10 It shows a schematic diagram of the structure of a computer system 1000 suitable for implementing computer devices or servers in the embodiments of this application.

[0280] like Figure 10 As shown, the computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to programs stored in read-only memory (ROM) 1002 or programs loaded from storage section 1008 into random access memory (RAM) 1003. The RAM 1003 also stores various programs and data required for the operation of the computer system 1000. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0281] The following components are connected to the input / output (I / O) interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the input / output (I / O) interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1010 as needed so that computer programs read from it can be installed into the storage section 1008 as needed.

[0282] Specifically, according to embodiments of this application, the above references Figure 1 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing instructions for performing... Figure 1 The program code for the method. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable media 1011.

[0283] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0284] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0285] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0286] On the other hand, this application also provides a computer-readable storage medium, which may be included in the computer device described in the above embodiments, or may exist independently and not assembled into the computer device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figure 1 The steps of the method shown.

[0287] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 1 The steps of the method shown.

[0288] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile 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. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0289] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A back-to-source testing method, characterized in that, The method is applied to a content distribution network including a source station service node and a plurality of edge service nodes, and comprises: In the case that the source station service node has completed the source returning configuration in the content distribution network system, the source station service node extracts first configuration information from a configuration validation test request initiated by a client and stores the first configuration information into a configuration table in response to the configuration validation test request; In response to a source returning request initiated by a target edge service node, the second configuration information carried in the source returning request is matched with the configuration table; the target edge service node is an edge service node having a source returning demand in the plurality of edge service nodes; A source returning test result is determined according to a matching result, and the source returning test result is fed back to the client; the source returning test result is used to represent whether the source returning configuration is validated; wherein the second configuration information is configuration information required to be verified by the client according to the first configuration information for source returning, and the target edge service node sends the source returning request carrying the second configuration information to the source station service node in the case of having a source returning demand.

2. The method of claim 1, wherein, The matching of the second configuration information carried in the source returning request with the configuration table comprises: In the case that the second configuration information includes a test type, a request id and second to-be-tested information, it is judged whether the test type matches a preset test type; If the test type matches the preset test type, the request id is searched in the configuration table; If the request id is found in the configuration table, the first to-be-tested information in the configuration table and the second to-be-tested information are matched; the first to-be-tested information belongs to the first configuration information.

3. The method of claim 2, wherein, The matching of the first to-be-tested information in the configuration table and the second to-be-tested information comprises: In the case that the test type is a custom request header and the configuration table is a custom request header table, a key table item value in the first to-be-tested information and a key parameter in the second to-be-tested information are matched; If the key table item value and the key parameter match, a value table item value in the first to-be-tested information and a value parameter in the second to-be-tested information are matched.

4. The method of claim 2, wherein, The matching of the first to-be-tested information in the configuration table and the second to-be-tested information comprises: In the case that the test type is a cache mechanism and the configuration table is a cache mechanism table, it is judged whether a count value in the second to-be-tested information matches a first preset count threshold value; If the count value does not match the first preset count threshold value, it is judged whether the count value matches a second preset count threshold value; If the count value matches the second preset count threshold, a time difference between a current request time and a previous request time is determined, and it is determined whether a difference between the time difference and a first preset threshold matches a cache time table item value in the first to-be-tested information; the current request time is a time at which the client initiates the configuration effective test request this time, and the previous request time is a time at which the client initiates the configuration effective test request last time.

5. The method of claim 1, wherein, The matching of the second configuration information carried in the source return request with the configuration table includes: In a case where the second configuration information includes a test type and a request id, and the configuration table is a source return timeout retry table, it is determined whether the test type is source return timeout retry; If the test type is the source return timeout retry, it is determined whether the request id matches an id table item value in the source return timeout retry table; If the request id matches the id table item value, it is determined whether a count table item value and a retry table item value in the source return timeout retry table match.

6. The method of claim 2, wherein, The matching of the first to-be-tested information and the second to-be-tested information in the configuration table includes: In a case where the test type is source return URI rewriting and the configuration table is a source return URI rewriting table, it is determined whether a URI table item value in the first to-be-tested information matches a URI in the second to-be-tested information.

7. A back-to-source testing method, characterized in that, The method applied to a client includes: sending a configuration effective test request to a source station service node, the configuration effective test request carrying first configuration information; wherein the source station service node is configured to, in a case where a source return configuration in a content distribution network system has been completed, in response to the configuration effective test request initiated by the client, extract the first configuration information from the configuration effective test request and store the first configuration information into a configuration table; and in response to a source return request initiated by a target edge service node, match second configuration information carried in the source return request with the configuration table; the target edge service node is an edge service node having a source return demand in a plurality of edge service nodes; and determine a source return test result according to a matching result, and feed back the source return test result to the client; the source return test result is used to represent whether the source return configuration is effective; the plurality of edge service nodes and the source station service node belong to a content distribution network; determining the second configuration information required for source return verification according to the first configuration information, and sending the second configuration information to an edge service node, so that the edge service node sends the source return request carrying the second configuration information to the source station service node in a case where the edge service node has a source return demand; obtaining the source return test result fed back by the source station service node.

8. The method of claim 7, wherein, The method further includes: in a case where the source return test result represents that a cache mechanism configuration is not effective, and a cumulative test number is not greater than a preset number threshold, sending a test interface access request to the target edge service node; the test interface access request carries a request id and a test type in the first configuration information. obtaining a request response result corresponding to the test interface access request, and if the request response result matches the request id, stopping for a first preset time if the current count value matches a first preset count threshold, updating the current count value, and then performing the step of sending the test interface access request to the edge service node; if the current count value does not match the first preset count threshold and matches a third preset count threshold, stopping for a second preset time, updating the current count value, and then performing the step of sending the test interface access request to the edge service node; if the current count value does not match the third preset count threshold and matches a fourth preset count threshold, stopping for the first preset time, updating the current count value, and then performing the step of sending the test interface access request to the edge service node; if the current count value does not match the fourth preset count threshold, updating the cumulative test count, and then determining whether the updated cumulative test count is greater than the preset number threshold.

9. A computer device comprising a processor, a memory, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the source return test method in any one of claims 1 to 8.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the source return test method in any one of claims 1 to 8.

Images