Link probing method, apparatus, device, and medium

Abstract

Embodiments of the present application provide a link detection method, device, equipment and medium. The method is executed by a client deployed in an edge service node in a content distribution network. The method comprises: obtaining a detection task pool issued by a policy end, and sending a detection data packet to a target network address indicated by a detection task in the detection task pool; receiving a response data packet for the detection data packet, determining link detection information from the client to the target network address based on the response data packet; and reporting the link detection information to a proxy end, so that the proxy end analyzes a link network state based on the link detection information. By using the embodiments of the present application, the link coverage in the content distribution network can be improved, and the effectiveness of the link detection result can be improved.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and in particular to a link detection method, apparatus, device, and medium. Background Technology

[0002] A Content Delivery Network (CDN) is a new type of network content service system that can bypass bottlenecks and links on the Internet that may affect data transmission speed and stability, making content delivery faster and more stable. Daily operation and maintenance of a CDN system involves thousands of data centers and hundreds of thousands of devices providing services to the live network. These devices often experience link failures due to various unforeseen factors, thus affecting the user experience of CDN users. Therefore, it is necessary to probe the CDN to ensure stable network quality.

[0003] Current detection systems typically rely on HTTP (Hypertext Transfer Protocol) probing, simulating user HTTP requests to CDN nodes within the CDN's own data center to determine the success rate. For example, a corresponding domain can be added to the HTTP probing system, and real-world probing can be performed on this domain using simulated user access. The success rate of these probings can then be used to determine the link status from users in different geographical regions and from different ISPs to the platform hosting that domain. However, it's clear that each domain to be tested needs to be added manually, and the probing process for each domain is simulated, which cannot fully cover the link status from users to each domain. This can easily lead to blind spots in the detection, resulting in inaccurate link detection results. Summary of the Invention

[0004] This application provides a link detection method, apparatus, device, and medium, which can improve link coverage in content delivery networks and enhance the effectiveness of link detection results.

[0005] This application provides a link detection method, which is executed by a client deployed at an edge service node in a content delivery network. The method includes:

[0006] Obtain the probe task pool issued by the policy terminal, and send probe data packets to the target network address indicated by the probe task in the probe task pool;

[0007] Receive response packets in response to probe packets, and determine the link probe information from the client to the target network address based on the response packets;

[0008] The link detection information is reported to the agent so that the agent can analyze the link network status based on the link detection information.

[0009] This application provides a link detection method, which is executed by a proxy, including:

[0010] Obtain link probe information reported by the client; the client is deployed on the edge service node in the content delivery network, and the link probe information is determined by the response data packet corresponding to the probe data packet. The probe data packet is sent by the client to the target network address indicated by the probe task in the probe task pool. The probe task pool is sent to the client by the policy terminal through the heartbeat terminal.

[0011] Based on the link detection information, analyze the network status of the link from the client to the target network address.

[0012] This application provides a link detection device, which is applied to a client deployed at an edge service node in a content delivery network; including:

[0013] The sending module is used to obtain the probe task pool issued by the policy terminal and send probe data packets to the target network address indicated by the probe task in the probe task pool;

[0014] The receiving module is used to receive response data packets in response to probe data packets, and to obtain link probe information from the client to the target network address based on the response data packets;

[0015] The reporting module is used to report link detection information to the agent so that the agent can analyze the link network status based on the link detection information.

[0016] The sending module includes:

[0017] The heartbeat packet sending unit is used to send heartbeat data packets to the heartbeat end according to the time frequency information, so that the heartbeat end can obtain the client's heartbeat information based on the reception time of the heartbeat data packet, and encapsulate the probe task pool issued by the policy end into a response data packet corresponding to the heartbeat data packet;

[0018] The task pool acquisition unit is used to receive the response data packet returned by the heartbeat end and acquire the probe task pool carried in the response data packet.

[0019] The device also includes:

[0020] The version update module receives version update information for the client from the heartbeat terminal and retrieves the target installation package corresponding to the client based on the version update information; and

[0021] Used to execute the installation script corresponding to the target installation package in the edge service node, and update the client to the target version indicated by the version update information.

[0022] The detection task pool includes N detection tasks, where N is a positive integer;

[0023] The sending module includes:

[0024] The format setting unit is used to obtain the i-th probe task in the probe task pool and set the message format corresponding to the i-th probe task; i is a positive integer less than or equal to N;

[0025] The serialization unit is used to generate a task identifier and a unique identification code for the i-th probe task. Based on the message format, it serializes the task identifier and the unique identification code into a probe data packet and sends the probe data packet to the target network address indicated by the i-th probe task.

[0026] Specifically, the receiving module is used for:

[0027] If the packet identifier corresponding to the response packet is the same as the task identifier, then the response packet is deserialized to obtain the verification identification code corresponding to the response packet.

[0028] When the identification code to be verified is the same as the unique identification code, the callback function corresponding to the i-th probe task is obtained; the callback function is registered by the client based on the task identifier and the unique identification code before sending the probe data packet;

[0029] In the callback function, the response data packet is validated to obtain the validation result corresponding to the response data packet. When the validation result indicates that the response data packet has passed the validation, the execution result corresponding to the i-th probe task is determined based on the response data packet.

[0030] Based on the execution results, the link detection information from the client to the target network address is determined, and the memory of the detection task pool is reset.

[0031] The device also includes:

[0032] The preprocessing module is used to obtain the timestamp when the client sends the probe data packet to the target network address, and to determine the corresponding response time range based on the timestamp; and

[0033] This is used to remove the target network address from the probe task pool if the client does not receive the response packet corresponding to the probe packet within the response time range.

[0034] The device also includes:

[0035] The task restart module is used to save the running information of the i-th probe task on the client when the client's network connection is lost; and

[0036] This is used to continue executing the i-th probe task in the client based on the runtime information when the client's network connection is successfully reconnected.

[0037] The device also includes:

[0038] The memory limit module is used to obtain the client's memory usage on the edge service node; and

[0039] Used to restart the client in the edge service node when memory usage exceeds the memory usage threshold.

[0040] One embodiment of this application provides a link detection device, which is applied at a proxy end and includes:

[0041] The acquisition module is used to acquire link probe information reported by the client. The client is deployed on the edge service node in the content delivery network. The link probe information is determined by the response data packet corresponding to the probe data packet. The probe data packet is sent by the client to the target network address indicated by the probe task in the probe task pool. The probe task pool is sent to the client by the policy terminal through the heartbeat terminal.

[0042] The link analysis module is used to analyze the network status of the link from the client to the target network address based on the link detection information.

[0043] The link analysis module includes:

[0044] The packet loss rate statistics unit is used to calculate the packet loss rate of the first link from the client to the target network address based on the link detection information.

[0045] The fault marking unit is used to determine that the network status of the link from the client to the target network address is faulty when the first link packet loss rate is greater than or equal to the first packet loss threshold, and to mark the target network address as a faulty network address.

[0046] The device also includes:

[0047] The packet loss rate acquisition module is used to obtain the packet loss rate of the second link from the client to the faulty network address;

[0048] The fault cancellation module is used to determine the network status of the link from the client to the faulty network address as recovered when the packet loss rate of the second link is less than the second packet loss threshold, and to cancel the marking of the faulty network address.

[0049] One aspect of this application provides a computer device, including a memory and a processor. The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the method provided in one aspect of this application.

[0050] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having a processor performs the method provided in one aspect of this application.

[0051] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in the above aspect.

[0052] In this embodiment, a client deployed in an edge service node of the content delivery network can obtain a probe task pool issued by the policy terminal and send probe data packets to the target network address indicated by the probe tasks in the probe task pool. It can also receive response data packets corresponding to the probe data packets, and based on these response data packets, obtain link probe information from the client to the target network address. Furthermore, it can report the link probe information to the proxy terminal, enabling the proxy terminal to analyze the link network status based on the link probe information. Therefore, the probe process can start from a client deployed in the edge service node of the content delivery network, sending probe data packets to the target network address accessed by real users on the current network (i.e., the network address indicated by the probe tasks in the probe task pool). The response data packets corresponding to these probe data packets can then be used to analyze the link network status from the client to the target network address, improving link coverage in the content delivery network and enhancing the effectiveness of the link probe results. Attached Figure Description

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

[0054] Figure 1 This is a schematic diagram of the structure of a link detection system provided in an embodiment of this application;

[0055] Figure 2This is a flowchart illustrating a link detection method provided in an embodiment of this application;

[0056] Figure 3 This is a flowchart illustrating a ping packet provided in an embodiment of this application;

[0057] Figure 4 This is a schematic diagram of a detection mission architecture provided in an embodiment of this application;

[0058] Figure 5 This is a schematic diagram of a client heartbeat and task scheduling mechanism provided in an embodiment of this application;

[0059] Figure 6 This is a flowchart illustrating another link detection method provided in an embodiment of this application;

[0060] Figure 7 This is a schematic diagram of a proxy architecture provided in an embodiment of this application;

[0061] Figure 8 This is a schematic diagram of a heartbeat terminal architecture provided in an embodiment of this application;

[0062] Figure 9 This is a schematic diagram of an alarm message provided in an embodiment of this application;

[0063] Figure 10 This is a schematic diagram of a strategy-side architecture provided in an embodiment of this application;

[0064] Figure 11 This is a schematic diagram of the device management page in a link detection system provided in an embodiment of this application;

[0065] Figure 12 This is a statistical diagram illustrating the packet loss rate of a CDN node provided in an embodiment of this application;

[0066] Figure 13 This is a statistical diagram illustrating a single client probe data provided in an embodiment of this application;

[0067] Figure 14 This is a schematic diagram of a query interface for a single detection record provided in an embodiment of this application;

[0068] Figure 15 This is a schematic diagram of the structure of a link detection device provided in an embodiment of this application;

[0069] Figure 16 This is a schematic diagram of another link detection device provided in an embodiment of this application;

[0070] Figure 17 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0072] To facilitate understanding of the technical solutions proposed in the embodiments of this application, the relevant technologies involved in the embodiments of this application will be briefly introduced below.

[0073] Cloud computing is a computing model that distributes computing tasks across a large pool of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, resources in the cloud appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage. As the foundational providers of cloud computing capabilities, they establish cloud resource pools (or cloud platforms, often referred to as IaaS (Infrastructure as a Service) platforms), deploying various types of virtual resources within these pools for external customers to choose from. The cloud resource pool primarily includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0074] Based on logical function, a PaaS (Platform as a Service) layer can be deployed on top of the IaaS (Infrastructure as a Service) layer, and a SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is a platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally speaking, SaaS and PaaS are upper layers compared to IaaS.

[0075] Content Delivery Network (CDN) nodes can be deployed across multiple locations and different networks. These nodes can dynamically transmit content to each other, optimizing user download behavior and thereby reducing bandwidth costs for content providers, improving download speeds, and enhancing system stability. The number of CDN nodes required varies depending on demand, potentially requiring tens of thousands of servers depending on the size of the target audience.

[0076] ICMP (Internet Control Message Protocol) is a sub-protocol of the TCP / IP (Transmission Control Protocol / Internet Protocol) protocol suite, used to transmit control messages between IP hosts and routers. Control messages refer to network-related information such as whether the network is accessible, whether a host is reachable, and whether a route is available.

[0077] Ping (Packet Internet Groper) is a program used to test network connectivity. The ping command can be used to check network availability; for example, it sends test packets (or probe packets) to a network address to see if the address responds and tracks the response time, thus testing the network. The ping command uses the ICMP protocol to send test packets.

[0078] Edge data centers (OC) can refer to EIC (Edge Internet Data Center) and GOC (Carrier Cooperative Data Center) data centers built by enterprises and operators in various cities. Edge data centers can also be called edge data centers or edge nodes.

[0079] An operator can refer to a telecommunications service company that operates a network and provides services. Operators need to understand the network's operational status not only from a network perspective but also from a service perspective. In this application's embodiments, the operator can refer to a telecommunications service company that provides fixed-line telephone, mobile phone, and internet access.

[0080] This application provides a link probing system based on the ICMP protocol, also known as a CDN anti-ping probing system. The probing process initiated by this system can start from the CDN server itself, probing the target IP of a real user accessing the network and the ISP IP of intermediate nodes. For example, it can send probe packets to the target IP and then determine the link status based on the received response packets. Here, "anti-ping" refers to the path of sending probe packets to the target IP, which is the opposite of the path taken by the real user. The CDN server itself can refer to a server deployed in the CDN data center, referred to as a CDN node. CDN nodes can deploy anti-ping clients (clients used to perform probing tasks). The client can be considered the probe object in the link probing system, and both the target IP and the ISP IP can be considered as the objects being probed. Therefore, this link probing system can comprehensively cover the entire link from the user to the CDN data center, fully reflecting the actual network situation. Furthermore, this link detection system can deploy clients across all CDN data centers, covering all geographical regions and operators (e.g., all provinces and major operators nationwide), enabling comprehensive detection of the entire link without any omissions, thereby improving the effectiveness of link detection.

[0081] The server corresponding to the CDN node can be an independent physical server, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. This application does not limit this.

[0082] To facilitate understanding, before detailing the link detection system proposed in this application's embodiments, a few concepts involved in this application's embodiments will be briefly explained. A CDN node can refer to any node server in a CDN network. A CDN node can be considered as a server corresponding to an IP address. These servers can form a data center to provide live network services. In other words, a CDN data center can be composed of multiple CDN nodes. Simply put, CDN is a technology that can effectively shorten latency. Its core concept is to cache content near the end user. For example, a cache server can be newly built near the end user. This newly built cache server can be called a CDN edge service node (or OC node). That is to say, OC nodes are the main type of CDN node. Deploying an anti-ping client in a CDN node means that an anti-ping client can also be deployed in an OC node (the anti-ping client here can also be called an OC client, which will be simply referred to as a client for ease of understanding). This application's embodiments will specifically describe the OC node type in CDN nodes as an example.

[0083] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a link detection system provided in an embodiment of this application. Figure 1 As shown, this link detection system may include clients, heartbeat terminals, proxy terminals, and policy terminals, among which:

[0084] The client can be deployed on OC nodes. Its functional characteristics may include: ① The client itself does not retain policies, only executes them; for example, the client does not retain probe policies (which include probe tasks designed in the probe system), but only executes probe tasks. ② The client can report results to management tools or message queues (MQ); for example, the client can report the probe results of probe tasks to management tools or message queues. Management tools can refer to SaaS products that provide IT (internet technology) performance management, which can periodically manage the uptime and response time of websites, services, and servers. If a website becomes inaccessible, the web server load is too high, the database pressure is too great, or a server error occurs, the management tool will notify the website administrator in the shortest possible time, minimizing losses caused by website downtime. Message queues are important components in distributed systems, mainly used to solve problems such as application coupling, asynchronous messaging, and traffic shaping. ③ The client can maintain or postpone task execution even when the network is disconnected; for example, the client can continue executing a probe task while the network is disconnected, and postpone the execution of the probe task. ④ The client can report its own status (e.g., the liveness status of the OC node to which the client belongs; when the network connection to the OC node is unobstructed, the client's own status can be determined to be live; when the network connection to the OC node is disconnected, the client's own status can be determined to be faulty) and execution results (e.g., the results of the probe task executed by the client) to the log stack. ⑤ The client can limit its own resource usage; for example, the client can limit its resource usage in real time according to its own needs. The resource usage here may include, but is not limited to, the CPU (central processing unit) utilization and memory usage of the client in its OC node.

[0085] The heartbeat endpoint can be a self-built data center, which offers more stable performance than a CDN data center. The heartbeat endpoint's functionalities include: ① Receiving and maintaining client status reports; for example, when a client reports its status to the log repository, it first sends its status to the heartbeat endpoint, which then reports the client's status to the log repository. The heartbeat endpoint maintains the received status. ② Providing data query functionality for the policy endpoint; for example, the policy endpoint can use the heartbeat endpoint's data query functionality to check the overall operation of the link detection system. ③ Receiving and distributing commands from the policy endpoint; that is, the heartbeat endpoint can receive commands from the policy endpoint and distribute them to the client; for example, the heartbeat endpoint can use the script box AJS deployed in the link detection system and the pulled CDNBEST to distribute commands from the policy endpoint to the client.

[0086] It should be noted that the script box AJS can refer to an internal tool that distributes the client version to the OC node, responsible for distributing the installation package to the OC node and executing the corresponding installation script; CDNBEST is a source site for storing installation packages, and the script box AJS can obtain the client version installation package that needs to be distributed to the OC node from CDNBEST.

[0087] The functional characteristics of the strategy end can include: ① The strategy end can obtain the overall operation status of the CDN system through the heartbeat end; for example, it can query the operation information of each OC node in the CDN system through the data query function provided by the heartbeat end. ② The strategy end can send client deployment commands to OC nodes to facilitate client deployment on OC nodes; that is, whether a client needs to be deployed on an OC node can be determined by the strategy end. When the strategy end sends a client deployment command to an OC node through the heartbeat end, it can pull the installation package of the corresponding client version from CDNBEST through the client deployment command, and the script box AJS is responsible for sending the installation package to the OC node and executing the corresponding installation script, thereby successfully deploying the client for performing probe tasks on the OC node. ③ The strategy end can distribute or subdivide probe tasks within the same data center; for example, the strategy end can be responsible for allocating the number of probe tasks for each OC node in the CDN data center. ④ The policy side can be responsible for controlling the distribution of information from the client IP to the destination IP at the granular level. Here, the client IP can refer to the network address of the target object (client) (or the IP of the OC node to which the client belongs), and the destination IP can refer to the network address of the target object, such as the target IP of a real user accessing the network or the ISP IP of an intermediate node. ⑤ The policy side can retain all policy UUIDs (Universally Unique Identifiers). A UUID is a software standard designed to provide unique identification information for all elements in a distributed system. Here, the policy UUID can refer to the UUID of all probe policies in the link probing system. For example, the policy side can retain a unique identifier, i.e., a UUID, for each probe policy (e.g., each probe task) in the link probing system.

[0088] The proxy's functionalities can include: ① The proxy can collect all client probe information; for example, all client-related probe task information deployed in the OC node can be reported to the proxy, allowing the proxy to collect probe information from various clients. ② The proxy can mark globally faulty IPs; for example, when a client sends probe packets to a target IP accessed by a real user on the live network, and the received response times out or is not received at all, the target IP can be marked as a faulty IP. ③ The proxy can summarize and report to the Elasticsearch cluster; for example, the proxy can summarize all collected client probe information and globally faulty IPs, and report the summarized results to the Elasticsearch cluster.

[0089] Elasticsearch (ES) is a distributed full-text search framework that hides complex processing mechanisms. Internally, it uses sharding, cluster discovery, and sharded load balancing (LB) request routing. ES can divide a complete index into multiple shards, thus splitting a large index into multiple parts and distributing them across different nodes. An ES cluster can include multiple nodes, one of which is the master node, which is elected. The other nodes are called slave nodes. Here, the master and slave nodes refer to the internal structure of the ES cluster.

[0090] like Figure 1 As shown, the link detection system may also include a management tool, a log archive, a cache database, and a database (DB). The management tool can monitor the operation of clients, heartbeat terminals, policy terminals, and agents in real time; the log archive can record information such as the status of clients, heartbeat terminals, policy terminals, and agents; the database can store data from heartbeat terminals, agents, and policy terminals; and the cache database can cache data from heartbeat terminals. This cache database may include, but is not limited to, Redis (a key-value database), Memcached (an in-memory database), and MongoDB (a document-oriented data system based on distributed file storage). For ease of understanding, this embodiment uses Redis as an example of a cache database. Redis is an open-source, in-memory structured data storage medium that can be used as a database, caching service, or messaging service.

[0091] Please see Figure 2 , Figure 2 This is a flowchart illustrating a link detection method provided in an embodiment of this application; it can be understood that this link detection method can be... Figure 1 The client in the link detection system shown is deployed on an edge service node (or simply CDN edge service node) within a Content Delivery Network (CDN). Figure 2 As shown, the link detection method may include the following steps S101 to S103:

[0092] Step S101: Obtain the probe task pool issued by the policy terminal, and send probe data packets to the target network address indicated by the probe task in the probe task pool.

[0093] In one or more embodiments, Figure 1In the link detection system shown, the policy-side can be responsible for issuing client deployment commands to CDN edge service nodes (OC nodes). For example, when the policy-side issues a client deployment command to an OC node in the CDN system, a client (also known as an anti-ping client) can be deployed on that OC node to perform the detection task. In other words, whether or not a client needs to be deployed on each OC node in the CDN system is determined by the policy-side.

[0094] For an OC node with a client deployed, the client can obtain a probe task pool issued by the policy provider for its current OC node. This probe task pool can contain one or more probe tasks, such as N, where N is a positive integer. When executing a probe task, the client can send probe packets to the target network address (target IP) indicated by the probe task. These probe packets can be used to detect the network connectivity between the client (or the OC node where the client is located) and the target IP. The target IP can be considered as the IP address accessed by a real user on the live network.

[0095] It's important to note that the probe task pool issued by the policy-side is not directly sent to the clients. Instead, the heartbeat endpoint serves as the channel for issuing probe tasks (or probe policies). For example, when the policy-side issues a probe policy to a client deployed on an OC node in the CDN system, it first sends the probe policy to the heartbeat endpoint. Upon receiving the probe policy, the heartbeat endpoint processes it. A heartbeat mechanism can be established between the client deployed on the OC node and the heartbeat endpoint to maintain a long-lived connection. For instance, if the client receives a response packet for every heartbeat data packet sent to the heartbeat endpoint, a long-lived connection is maintained. Conversely, if the client fails to receive a response packet for every heartbeat data packet sent, a connection failure is detected.

[0096] Specifically, the client can send heartbeat data packets to the heartbeat terminal according to the time frequency information. This allows the heartbeat terminal to obtain the client's heartbeat information based on the reception time of the heartbeat data packets. The client can then encapsulate the probe task pool indicated by the probe policy issued by the policy terminal into a response data packet corresponding to the heartbeat data packet. The client can receive the response data packet returned by the heartbeat terminal and obtain the probe task pool carried in the response data packet. The aforementioned time frequency information refers to the time interval information at which the client sends heartbeat data packets to the heartbeat terminal. For example, this time frequency information can be set to 1 minute, in which case the client can send heartbeat data packets to the heartbeat terminal every minute, i.e., report heartbeats to the heartbeat terminal every minute. Thus, the heartbeat terminal can obtain the client's heartbeat information. Similarly, clients deployed in each OC node of the CDN system can report heartbeat information to the heartbeat terminal. In other words, the heartbeat terminal can obtain the heartbeat information of each client, and this heartbeat information can directly reflect the network connection status of the current network. After receiving the heartbeat data packet sent by the client, the heartbeat terminal can send the probe task issued by the policy terminal to the client in the form of a response data packet. The client can obtain the probe task pool issued by the policy terminal through the received response data packet.

[0097] For any probe task in the probe task pool (such as the i-th probe task, where i can be a positive integer less than or equal to N), a message format corresponding to the i-th probe task can be defined. This allows the generation of a random task identifier (which can be denoted as ID, or Identification) and a unique identification code (also called a universally unique identifier, or UUID) for the i-th probe task. Based on this message format, the task identifier and unique identification code can be serialized into a probe data packet, which can then be sent to the target network address indicated by the i-th probe task. The specific structure of the probe data packet can be found below. Figure 3 The descriptions in the corresponding embodiments will not be repeated here.

[0098] In one or more embodiments, the client deployed in the OC node can be updated to a new version, and the updated client version is sent to the OC node by the heartbeat terminal. For example, the client deployed in the OC node can receive version update information for the client sent by the heartbeat terminal. Based on the version update information, the client can obtain the target installation package (e.g., the latest installation package) corresponding to the client from CDNBEST. Then, the script box AJS can be responsible for executing the installation script corresponding to the target installation package in the OC node and updating the client to the target version indicated by the version update information.

[0099] Step S102: Receive a response data packet in response to the probe data packet, and determine the link probe information from the client to the target network address based on the response data packet.

[0100] Specifically, the client can receive the response packet corresponding to the probe packet. This response packet determines the link probe information from the client to the target IP. After receiving the response packet, the client can verify its identifier. If the packet identifier matches the task identifier (i.e., the probe task packet ID matches the response packet ID), the response packet can be deserialized (e.g., the Data can be deserialized, represented in 8+16 bits) to obtain the verification identifier (or the verification UUID). When the verification identifier matches the unique identifier, the callback function corresponding to the i-th probe task is retrieved. This callback function is registered by the client based on the task identifier and unique identifier before sending the probe packet. The response packet (represented as a serialized response packet) is verified within the callback function to obtain the verification result. When the verification result indicates that the response packet verification passed, the execution result of the i-th probe task is determined based on the response packet. The link probe information from the client to the target network address is determined based on the execution result, and the probe task pool is reset. The client's processing of response data packets can also be found in [reference needed]. Figure 3 The descriptions in the corresponding embodiments will not be repeated here.

[0101] Step S103: The link detection information is reported to the agent so that the agent can analyze the link network status based on the link detection information.

[0102] Specifically, the client can report link probe information to the proxy. After receiving the link probe information reported by the client, the proxy can analyze the corresponding link network status based on the link probe information. It can be understood that clients deployed on each OC node in the CDN system can report the link probe information corresponding to the probe task to the proxy. That is, the proxy can obtain the link probe information from clients deployed on each OC node, aggregate all received link probe information, and analyze the link network status based on the aggregated link probe information. The link network status here can include fault status and normal status. A fault status indicates that the target IP of the corresponding link has a connection failure, while a normal status indicates that the target IP of the corresponding link is connected normally. Deploying the proxy in the link probe system can isolate the clients and policy-side components in the link probe system, thereby preventing the policy-side component from being directly exposed to the external network.

[0103] Optionally, before executing probe tasks in the probe task pool, the clients deployed in the OC node can preprocess the probe tasks in the pool. For example, they can obtain the timestamp when the client sends the probe data packet to the target network address and determine the corresponding response time range based on the timestamp. If the client does not receive a response data packet corresponding to the probe data packet within the response time range, the target network address is removed from the probe task pool. In other words, if the client sends a probe data packet to the target IP indicated by the probe task and does not receive a response data packet within a preset time (i.e., the duration of the response time range, which starts from the timestamp of the sending), the target IP can be removed from the probe task pool.

[0104] Optionally, the client can also maintain connection interruption and postpone the execution of the probe task. For example, if the client's network connection is detected to be disconnected during the execution of the i-th probe task contained in the probe task pool, the running information of the i-th probe task in the client can be saved. When the client's network connection is successfully reconnected, the i-th probe task can continue to be executed in the client based on the running information. For example, the i-th probe task can be resumed after restarting the client.

[0105] Optionally, clients deployed on the OC node can be configured with self-limiting mechanisms, which may include, but are not limited to, CPU (central processing unit) limits, memory limits, and error restarts. The following example illustrates memory limits (also known as a fallback mechanism). For instance, the client's memory usage on the edge service node (OC node) can be obtained. When the memory usage exceeds a threshold (e.g., the threshold could be set to 512MB, but other values ​​can be set according to actual needs; this application does not limit this), the client is restarted on the edge service node. For the aforementioned CPU limit and error restart mechanisms, please refer to the following... Figure 3 The descriptions in the corresponding embodiments will not be repeated here.

[0106] The following will combine Figures 2 to 10 ,right Figure 1 Each part of the link detection system shown is described separately.

[0107] In one or more embodiments, for Figure 1The link probing system shown depicts a client used to perform probing tasks. Issues this client needs to address include, but are not limited to: individual client performance (e.g., each client's probing tasks should not impact existing network services), dynamic changes in daily probed IPs (e.g., the client needs to dynamically adapt to the existing network conditions when performing probing tasks), self-restart mechanisms (e.g., automating the link probing system through client self-restart mechanisms to reduce human intervention), tracing mechanisms (e.g., obtaining target IPs for existing network services through the client in the link probing system), maintaining expiration policies (e.g., ensuring no probing gaps occur through the client), and removing faulty IPs (e.g., the client focuses on dynamic packet loss rather than routinely pinging different IPs). Based on these issues, the client's design mechanism can be specifically described from three aspects: ping packets, probing tasks, and the client itself. Specifically:

[0108] (1) For details on the design of the ping packet, please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating a ping packet provided in an embodiment of this application; as shown... Figure 2 As shown, clients deployed on OC nodes can retrieve new ping tasks from the ping task storage pool and execute them. This ping task storage pool can be accessed externally, and each ping task in the pool can be considered a pingIP task; in this case, the ping task belongs to the probe task within the link probing system.

[0109] During the execution of a new ping task, the client can first define the message format corresponding to the new ping task. Specifically, this can include the message formats for Echo request (ping request) and Echo Reply (ping reply). For example, an Echo request can be defined using Message{Type:8 code:0 body:icmp.Echo{}}, where "Type:8" indicates that the ICMP type field is 8, "code:0" indicates that the ICMP type field is 0, and "body:icmp.Echo{}" indicates that the ICMP body is an icmp.Echo packet. Similarly, an Echo Reply can be defined using Message{Type:0 code:0 body:icmp.Echo{}}. The difference between Echo Reply and Echo request lies in the ICMP type field; the ICMP type field for Echo Reply is 0.

[0110] Furthermore, the client can mark new ping tasks by generating a random UUID and a random ID (which can be any number in the range of 0-65534; the ID here can also be called the task identifier) ​​based on the new ping task. Then, the UUID and ID can be serialized, for example, the UUID and ID can be serialized into an icmp.Echo packet. Then, the callback function of the new ping task is registered with the UUID and ID, and an icmp.Echo request is sent to the network address specified by the new ping task. For example, an IMCP Echo request packet (also known as a packet sending or probe packet) can be sent to the network address specified by the ping task.

[0111] If the client receives a response packet from the network address specified in the ping task (which can be understood as the response from the network device corresponding to that network address after receiving the IMCP Echo request packet, such as an IMCP Echo Reply packet, or simply a reply packet), the ID of the reply packet can be verified. If the verification passes, the UUID can be extracted from the deserialized data (Data), and the UUID can be verified and the callback function can be read. Within the callback function, the sequence number (which can refer to the reply packet represented in serialized form) is verified, and each ping task object is cleaned up and its memory is reset.

[0112] like Figure 2As shown, the design of the ping packet can include the design of the icmp.Echo packet, whose design mechanism can be understood as a data return mechanism. The icmp.Echo packet design allows for a custom ID; that is, the previously generated random ID is custom-defined, and the sending ID and the receiving ID are the same. The sequence number (seq) can represent the Nth receiving packet. The icmp.Echo packet design can also include custom data, which can be 24 bits (i.e., 8+16), with the first 8 bits serialized as a timestamp and the last 16 bits serialized as a UUID.

[0113] The design of the ping packet can incorporate a task manager, which ensures data isolation under high concurrency. The tasks of this manager include: ① listening to raw sockets; ② registering callback functions for ping tasks; ③ after receiving a response packet, filtering it using a double-locking mechanism, obtaining the packet ID and UUID, and executing the callback function.

[0114] The introduction of a double-lock filtering mechanism in the ping packet design optimizes the performance of individual clients in the CDN network. In this mechanism, ID verification can utilize atomic locks for access operations, improving efficiency. Since IDs from different ping tasks may be duplicated, a mapping between UUIDs and callback functions can be generated. During the execution of each ping task, each ping task object can support memory reset without requiring memory reallocation. Introducing memory reset into the ping packet design avoids frequent memory allocation and reclamation, and the internal lock for seq (sequence) verification can be a lock pointer, preventing packet loss upon return.

[0115] (2) The architecture design of the exploration mission can be found in [reference]. Figure 4 , Figure 4 This is a schematic diagram of a detection mission architecture provided in an embodiment of this application; as shown... Figure 4 The pingRerport probe shown is... Figure 1 The link detection system shown includes the detection tasks involved. Among them, the pingRerport long detection task is the main detection task in the link detection system. In addition to the long detection task, it can also include the trace short task and the ping short task. The trace short task and the ping short task can be used to find and verify the target IP at the policy end.

[0116] The main process of pingRerport probe long-running tasks can include task storage / recovery, a timed reset smoother, a target IP preprocessing mechanism, and aggregated reporting (for example, aggregated reporting can be performed using a CDN quality monitoring platform, which can remove poor-quality links from the live network based on data provided by the link detection system). Task storage / recovery refers to the storage and recovery processes of long-running probe tasks. The timed reset smoother can include: each cycle of a pingRerport probe long-running task can release a pingIP task pool (which can also be considered as the aforementioned...). Figure 2 The ping task pool shown (or probe pool) can be configured such that, for example, a period of one minute, one ping IP task can be released every minute. Each ping IP task can be considered a blocking coroutine (a program component), and its execution speed is controlled by a token generator. The task pool and token generator are reset in the next period to prevent coroutine accumulation. This smoother may include a token generator using a channel (chan), which controls the maximum number of coroutines in a token-like manner, and uses a channel (chan) to implement the ping IP task pool.

[0117] PingRerport's long-running ping probes can reset the IPs to be probed from a file each cycle (e.g., every minute). This provides an entry point for manually removing probed IPs. Clients can temporarily store the IPs to be pinged each cycle (e.g., every minute) in a file to preserve data for on-site fault analysis and allow scripts to intervene in the probe process. The target IP preprocessing mechanism means that the pingRerport long-running ping probes need to be preprocessed before execution; IPs that do not return packets normally will be removed from the ping IP task pool, thus avoiding excessively high packet loss under normal circumstances. Aggregated reporting refers to collecting, aggregating, and reporting the execution results of the long-running ping probes through a CDN quality monitoring platform (e.g., Coffee).

[0118] (3) For the client's architecture design, please refer to Figure 5 , Figure 5 This is a schematic diagram of a client heartbeat and task scheduling mechanism provided in an embodiment of this application; as shown... Figure 5As shown, the client design may include, but is not limited to, the following mechanisms: support for three task strategies (such as ping / trace / pingReport tasks), heartbeat mechanism, intelligent reporting (for example, by organizing and studying the client's link detection information to generate and report a report), task parsing, policy service reporting, task waiting queue, expired task stacking, and task recovery. The client can access the Tencent Kubernetes Engine (TKE) workload through two external network cloud load balancers (CLBs), such as a heartbeat client and a proxy client. It should be noted that the number of CLBs here is only for illustrative purposes; this application can determine the number of CLBs according to actual needs, and this application does not impose any limitations on this.

[0119] Specifically, the client is deployed as an agent on the existing OC nodes and is responsible for executing specific tasks. The core mechanisms of this client can include: ① The client's architecture design can include a heartbeat mechanism, such as the client reporting heartbeat information every minute and obtaining the policy issued by the heartbeat end; ② The client can support three task types: ping, trace, and pingReport, i.e., ping tasks, trace tasks, and pingReport tasks. Ping and trace tasks are short tasks, while pingReport tasks are long-term probe tasks; ③ The client can save runtime information and support task recovery after agent restart, such as restoring tasks before restarting when the agent restarts; ④ Expired pingReport tasks will not be closed until the next pingReport task is issued; ⑤ For ping / trace tasks, they can enter a waiting queue before execution to prevent too many tasks from being executed simultaneously. Typically, the default number of concurrent task executions is 10, but other values ​​can be set, which are not limited in this application.

[0120] In addition to the aforementioned core mechanisms, the client can also design a self-limiting mechanism to ensure that the business of a single client is not affected. This self-limiting mechanism may include: ① CPU limiting: The CPULIMIT command can be used to start the client deployed on the corresponding OC node, locking the CPU utilization at a fixed value (e.g., 15%, which is not limited in this application); the CPULIMIT command can be used to limit the CPU rate and the CPU percentage of a specified process; ② Memory limiting: Every cycle (the cycle here can be set to 6 hours, which is not limited in this application) checks the process memory usage, and if it exceeds a preset threshold (e.g., 512MB, which is not limited in this application), it will restart (also known as a fallback mechanism); ③ Error restart: A restart can be performed after a low-level error occurs.

[0121] Please see Figure 6 , Figure 6 This is a flowchart illustrating another link detection method provided in this application embodiment; it can be understood that this link detection method is composed of... Figure 1 The link detection system shown is executed by the agent; wherein, the link detection method may include the following steps S201 to S202:

[0122] Step S201: Obtain the link probe information reported by the client; the client is deployed on the edge service node in the content delivery network, and the link probe information is determined by the response data packet corresponding to the probe data packet. The probe data packet is sent by the client to the target network address indicated by the probe task in the probe task pool. The probe task pool is sent to the client by the policy terminal through the heartbeat terminal.

[0123] Step S202: Analyze the network status of the link from the client to the target network address based on the link detection information.

[0124] The proxy can obtain link probe information reported by the client. By analyzing all received link probe information, it can determine the network status of the link from the client to the target IP. More specifically, the proxy can calculate the first link packet loss rate from the client to the target network address based on the link probe information. When the first link packet loss rate is greater than or equal to a first packet loss threshold (which can be set to 98% or other values), the proxy determines that the link from the client to the target network address is in a faulty state and marks the target network address as a faulty network address. The proxy then obtains the second link packet loss rate from the client to the faulty network address. When the second link packet loss rate is less than a second packet loss threshold (which can be set to 70% or other values), the proxy determines that the link from the client to the faulty network address is in a recovered state and removes the faulty network address from the list.

[0125] It should be noted that, in addition to marking and canceling faulty IPs, the design mechanism of the proxy can also include other mechanisms, such as pulling IPs separately for each client's geographical region (e.g., the province where the OC node deploying the client is located) + client carrier (i.e., the carrier to which the OC node deploying the client is located) and performing TOP (here, TOP can refer to the TOP command, which can be used to display the CPU usage and memory usage of each process), which can avoid data distortion.

[0126] against Figure 1 In the link detection system shown, the proxy terminal's architecture design may include, but is not limited to: ① The proxy terminal is used to isolate the client and the policy terminal to prevent the policy terminal from being directly exposed to the external network, thereby improving the security of the policy terminal; ② The proxy terminal can add global processing policies, and all detection information is aggregated at the proxy terminal, allowing for secondary processing of the data; ③ For target IPs where all detection terminals (detected objects) experience 100% packet loss, the proxy terminal can mark them as faulty IPs to prevent such data from affecting subsequent automated removal decisions.

[0127] Based on the aforementioned design, the architecture design of the proxy side can be found in [reference needed]. Figure 7 , Figure 7 This is a schematic diagram of a proxy architecture provided in an embodiment of this application; as shown... Figure 7 As shown, the client agent deployed on the OC node can access the TKE workload through two external CLBs. These two external CLBs can be CLBs from different geographical regions, such as CLB in region 1 and CLB in region 2. The proxy is located at a convergence point of all data in the link detection system and can add global policies, such as faulty IP policies. Therefore, designing a proxy in the link detection system is essential. The proxy can be responsible for data transformation, faulty IP identification, reporting to Insight (a CDN log collection system), faulty IP discovery, and data decompression. For example, the proxy can perform faulty IP checks every cycle and be responsible for marking and unmarking faulty IPs. The cycle here can be one minute, and faulty IP checks can be performed every minute. This cycle can be set according to actual needs, and this application does not limit it.

[0128] The faulty IP strategy can logically include, but is not limited to: ① IPs with a total packet loss rate exceeding a first packet loss threshold within a given period can be marked as faulty IPs; ② IPs with a total packet loss rate less than a second packet loss threshold within a given period can be removed from the faulty IP list; ③ IPs are retrieved separately for each client's province and carrier dimension to avoid data distortion; ④ All nodes (referring to proxy nodes) compete for a distributed lock, and daily check and recovery tasks are continuously executed by different nodes. Through the above faulty IP screening strategy, the packet loss rate of a certain link in the current network can be reduced from approximately 1.6 to approximately 0.15, which clearly significantly reduces the link packet loss rate.

[0129] It should be noted that the first packet loss threshold mentioned above can be set to 98%, and the second packet loss threshold can be set to 70%. The aforementioned distributed lock refers to the search for faulty IPs, requiring a distributed lock to ensure the synchronized operation of all nodes. Since there are no performance requirements in this scenario, a MySQL (relational database) table can be chosen to implement this distributed lock. For example, the proxy can connect to the database (MySQL) via PDO (PHP Data Objects), an interface for connecting to databases in PHP (Hypertext Preprocessor). The aforementioned reporting to Insight can be understood as data reporting. Anti-ping data can be submitted to the MQ specified by Insight (i.e., Insight-MQ) and collected into the Elasticsearch cluster storage for data statistics and removal decisions by the CDN quality observation platform, Coffee. Furthermore, information such as the proxy's own status can be reported to the log repository, and information such as the proxy's operational status can be reported to the management tools.

[0130] against Figure 1 The heartbeat terminal in the link detection system shown can be designed in the following ways: ① The essence of the heartbeat terminal is to separate the heartbeat information reflecting the current situation from the policy that requires decision calculation into a heartbeat terminal and a policy terminal; ② The heartbeat terminal can obtain all client heartbeat information, and thus directly reflect the current network; ③ The heartbeat terminal can independently maintain the entire client coverage network and perform daily inspections to identify and address any gaps; ④ The heartbeat terminal can serve as a channel for policy distribution, that is, the detection policy issued by the policy terminal can be sent to the heartbeat terminal first, and then the heartbeat terminal will distribute the detection policy to the client.

[0131] The design mechanism of the heartbeat end can include, but is not limited to: OM (which can be understood as a CDN resource device management system) information caching, version update mechanism, heartbeat information, policy distribution, daily activation, daily coverage check, MySQL distributed lock, etc. Please see below. Figure 8 , Figure 8 This is a schematic diagram of a heartbeat terminal architecture provided in an embodiment of this application; as shown... Figure 8 As shown, the heartbeat architecture can include a policy center, a heartbeat center, and a management center. The policy center can include policy collection and policy integration; specifically, the policy center can receive probe policies from the policy service (policy end) and organize and distribute them when the corresponding OC node heartbeats.

[0132] The heartbeat center can include heartbeat procedures, individual client information integration and verification, policy distribution, and heartbeat information querying. Specifically, the heartbeat center can receive HTTP heartbeat packets from clients and transmit the probe policy to the client in the form of a response packet (also known as the response packet corresponding to the heartbeat packet). In addition, the heartbeat center can also provide the policy service with heartbeat information for all available Objective-C nodes. The heartbeat procedure can include: receiving heartbeats and updating DB (database) records; checking if the policy center has received probe policies that need to be distributed; if it is found that the policy center has received probe policies that need to be distributed, then the policy can be distributed.

[0133] The management center can include version updates, daily activation, daily coverage checks, and device availability management (which can be understood as availability management of OC nodes). Specifically, the management center can be responsible for managing the liveness status of all clients and maintaining the availability of OC nodes in the entire link detection system. Daily checks, alarms, and deployments on the live network can all be implemented by the management center.

[0134] The client version update strategy may include, but is not limited to: ① deploying a new version to a single client; ② deploying a new version to a data center; ③ conducting multiple batch gray-scale releases of the new version at a granularity of 10%; ④ conducting multiple batch gray-scale releases of the new version at a granularity of 30%; ⑤ after a full rollout, deploying the new version to unavailable devices and setting the device availability status based on the results.

[0135] Daily data center coverage checks can include data center screening rules and control rules. The data center screening rules are based on all CDN data centers recorded on om, and data centers that simultaneously meet the following three conditions can be included in the control: their status is "normal", their operator is "Type 1 operator", "Type 2 operator" or "Type 3 operator", and their name contains the word "OC". The control rules can include: checking at a fixed time every day (or at a fixed time in each cycle), and if there are uncovered data centers and uncovered IPs under the name of the uncovered data center, an alarm can be pushed.

[0136] Please see Figure 9 , Figure 9 This is a schematic diagram of an alarm message provided in an embodiment of this application; as shown below. Figure 9 As shown, CDN data center coverage checks can be performed daily. If there are still data centers that are not covered after the client deployment is sent to the CDN data center, it indicates that the client deployment failed due to other factors (i.e., factors other than the failure to deploy the client). In this case, an alarm message can be pushed to the relevant person in charge. The alarm message may include, but is not limited to: project introduction, application used in the project, IP, abnormal time, and alarm content (for example, the alarm content may include the number of data centers that need to deploy the client, the specific data center where the client deployment failed, and the number of data centers).

[0137] It should be noted that the policy center, heartbeat center, and management center included in the heartbeat terminal can all be connected to the MySQL database. Through MySQL, the data in the policy center, heartbeat center, and management center can be managed. The heartbeat center can also be connected to the cache database. In addition, the heartbeat terminal's own status and other information can also be reported to the log repository, and the heartbeat terminal's operational status and other information can be reported to the management tools.

[0138] against Figure 1 In the link detection system shown, the policy-side architecture design may include, but is not limited to: ① The policy-side can retrieve the actual request IPs (also known as target IPs, such as IPs accessing the CDN network from the current network) daily and perform tracing operations on them. After obtaining the results, they can be distributed to clients the next day to execute new detection tasks; ② On the policy-side, a single IP can ping all operators in the same geographical region; for example, a single IP can ping all operators in the same province; ③ IPs in the same data center can poll and divide target IPs for collaborative detection, which can multiply the detection scope; ④ The policy-side can issue new detection policies daily to control the client's detection behavior.

[0139] The strategy design mechanism may include, but is not limited to: daily collection of target IPs by region (geographic area), target IP-trace task scheduling, IP region verification, target IP-ping task scheduling, callback mechanism, daily policy distribution, all geographic regions of a single IP (e.g., province), round-robin targeting of target IPs within the same data center, and minimum number of target IPs, etc. Please refer to the following... Figure 10 , Figure 10 This is a schematic diagram of a strategy-side architecture provided in an embodiment of this application; as shown... Figure 10 As shown, the policy architecture can include a link calculation module, a policy control module, and a task distribution module. The link calculation module can include operations such as trace policy distribution, ping policy distribution, and data processing. Here, trace and ping policies can both be referred to as probe policies. The link calculation mechanism corresponding to this module can include: ① defining "target operator + target geographical region + data center operator" as a link; ② calculating the target IP to be distributed for each link independently; ③ the link calculation process requires the participation of OC nodes (CDN service edge nodes) to distribute trace and ping tasks, jointly creating the IP pool to be distributed.

[0140] Policy control can include operations such as target IP polling and policy distribution. The policy mechanism corresponding to this policy control can include: ① daily collection of regional target IPs; ② daily policy distribution; ③ polling and segmenting target IPs in all geographical regions (e.g., provinces) of a single IP within the same data center, with a minimum number of target IPs.

[0141] The task delivery module can include operations such as trace task callback registration, ping task callback registration, and pingReport task delivery. The corresponding delivery callback registration mechanism of this task delivery module can include: ① delivery of trace and ping tasks, and registration of callback processing; ② this task delivery module can access the heartbeat terminal and deliver policy tasks to the heartbeat terminal, and deliver tasks when the corresponding client IP heartbeat occurs; ③ it can listen to the message queue (MQ) and receive return information; ④ using the task UUID as the key, execute the callback processing result.

[0142] It should be noted that information such as the status of the policy terminal itself can also be reported to the log repository, and information such as the operational status of the policy terminal can be reported to the management and control tools; the policy control center can also store the target IPs it polls and collects in a database (DB); the design mechanism of the policy terminal architecture can rely on the Insight live network logs. The time period "daily" involved in the embodiments of this application is only an example, and other time periods can be used in actual applications, which are not limited in this application.

[0143] In this embodiment, the link information reported by the client is used to remove links based on the triplet "target operator + target geographical region + data center operator". In scenarios where a link fails, it can be automatically removed from the existing network coverage, and other normal data centers can be used to cover the link. This allows for the removal and recovery of network failures without manual intervention, ensuring a good user experience for CDN users and reducing the operational pressure on CDN maintenance personnel. Furthermore, the link detection system provided in this embodiment can periodically perform coverage and device checks to ensure comprehensive coverage of its own detection device pool (which may include multiple OC nodes). It automatically deploys clients in newly built data centers to ensure high reliability and availability, providing stable and reliable services to the existing network. Simultaneously, it can maintain and explore target IPs daily, finding truly detectable target IPs by tracing network logs and tracing policies, thus achieving automated maintenance of the target IP pool.

[0144] In one or more embodiments, the above-described link detection system can also provide users with a data query function. This function allows users (e.g., CDN system operators or developers) to query the link information they need. The following will combine... Figures 11 to 14 The data query function provided by the link detection system is described in detail.

[0145] Users can use the data query function provided by the link detection system to query the number of data centers deployed by various operators in different geographical regions, thus ensuring the detection capability of links in each geographical region. For example, a regional node management page can be displayed at the front end of any OC node in the link detection system. On the regional node management page, users can select the type of operator to query (e.g., Type 1 operator) and the object to query (e.g., CDN data center). After completing the selection, users can trigger the query control on the regional node management page, which will then display the number of data centers deployed by Type 1 operators in each geographical region. This provides a clear view of the number of data centers where clients are deployed in each geographical region. Of course, users can also select all types of operators, which will display the number of data centers deployed by all operators in each geographical region.

[0146] Optionally, for OC nodes (or OC devices with deployed clients), adjustments and enabling / disabling operations can be performed to achieve fine-grained adjustment of the probe device pool in the probe system, thereby improving the effectiveness of device management in the link probe system. Please refer to [link to relevant documentation]. Figure 11 , Figure 11This is a schematic diagram of the device management page interface in a link detection system provided in an embodiment of this application; as shown... Figure 11 The device management page shown may include controls such as "Start Device", "Disable Device", "Add OC Device", "Update Client Version", and "Query". The "Start Device" control is used to start an OC device with a client deployed, the "Disable Device" control is used to disable an OC device with a client deployed, the "Add OC Device" control can be used to add an OC device with a client deployed, the "Update Client Version" control is used to update the client version deployed in the OC device, and the "Query" control is used to find relevant information based on the query conditions entered on the device management page.

[0147] like Figure 11 As shown, users can enter (or select) query conditions in area 10a of the device management page. These conditions can include geographical area (e.g., province), operator type, data center, client version, and status (including active and disabled status). After entering the query conditions, users can trigger the "Query" control in area 10a. In response to this trigger, the device management page will display relevant information about each OC device under the aforementioned query conditions. This includes information such as the IP address, geographical area (province), operator, data center, client version, and status of each OC device. The content displayed on the device management page is merely an example; in actual applications, the displayed content can be selected based on specific needs. This application does not impose any limitations on this. Figure 11 As shown, all OC devices are in the active state. If the user selects the OC device corresponding to area 10b and performs a trigger operation on the "Disable Device" control, the state of the OC device corresponding to area 10b can be switched from active to disabled.

[0148] Optionally, users can also use the management tools in the link detection system to view the packet loss rate of each CDN node to the national link. Please see [link to relevant documentation]. Figure 12 , Figure 12 This is a statistical diagram illustrating the packet loss rate of a CDN node provided in an embodiment of this application; for example... Figure 12 As shown in the figure, the packet loss rate of a certain CDN node to the national link is shown in the statistical figure 20a. The statistical figure 20a can include the packet loss rate of the CDN node in the current period and the comparison period, and can intuitively perceive the difference between the packet loss rate of the CDN node in the current period and the comparison period.

[0149] Optionally, users can also view the probe data of a single client (single machine) through the management tools in the link detection system (a client may include probe data from multiple target IPs). This probe data may include, but is not limited to, the number of probe packets, the number of lost packets, and the packet loss rate. Please see [link to relevant documentation]. Figure 13 , Figure 13 This is a statistical diagram illustrating a single client probe data provided in an embodiment of this application; for example... Figure 13 As shown, when users view individual client probe data through the management tool, they can choose the presentation method for the data, such as selecting the current period as the current day (or allowing for a custom time), selecting different ratios or year-on-year comparisons, or choosing to present it as a line graph or bar chart. For individual client probe data, the number of packet losses can be displayed as follows: Figure 13 As shown in Statistical Figure 30a, the packet loss rate can be calculated as follows: Figure 13 As shown in the statistical chart 30b, the number of probe packets can be as follows: Figure 13 The statistical chart 30c is shown in the figure; among them, statistical charts 30a, 30b and 30c can all include relevant data statistics within the current period and the comparison period, which can intuitively compare the detection data within the two periods.

[0150] Optionally, users can also query the detection records of individual clients through the management tools in the link detection system, or they can aggregate and view them according to their actual needs. Please see [link to relevant documentation]. Figure 14 , Figure 14 This is a schematic diagram of a query interface for a single detection record provided in an embodiment of this application; as shown... Figure 14 The query results shown are from a clustering analysis. Users can select the number of metrics, dimensions, and the number of references for each dimension when performing a top analysis. For example, the user can select client IPs as the dimension, and the number of references for each client IP when performing a top analysis is 1000. Selected metrics can include current result percentage (%) / total percentage (%), average packet loss rate (%), total number of failures (times), total number of packets (times), packet loss rate (%), average latency (ms), etc. After the user completes the above selections, they can trigger the analysis control to display the values ​​of each client IP for the selected metrics.

[0151] In this embodiment, when certain geographical areas block CDN nodes (e.g., OC nodes), the CDN platform can automatically remove the blocked IPs, which can improve the responsiveness of the existing network. When a fault occurs, the platform operation and maintenance can also directly obtain the real data reflecting the existing network by viewing the data of the link detection system (CDN anti-ping detection system), which can locate the cause of the fault more quickly, and then formulate a fault recovery strategy, which can increase the service quality of the CDN platform and shorten the fault recovery time.

[0152] It is understood that in the specific implementation of this application, the network address (IP address) accessed by the user may be involved. When the above embodiments of this application are applied to specific products or technologies, the user's permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0153] Please see Figure 15 , Figure 15 This is a schematic diagram of a link detection device provided in an embodiment of this application. It can be understood that this link detection device can be applied to a client in a link detection system, the client being deployed at an edge service node (which can be called a CDN edge service node) in a content delivery network; wherein, Figure 15 The link detection device 1 shown may include: a sending module 11, a receiving module 12, and a reporting module 13;

[0154] Sending module 11 is used to obtain the probe task pool issued by the policy terminal and send probe data packets to the target network address indicated by the probe task in the probe task pool;

[0155] The receiving module 12 is used to receive the response data packet in response to the probe data packet, and to obtain the link probe information from the client to the target network address based on the response data packet;

[0156] The reporting module 13 is used to report link detection information to the agent so that the agent can analyze the link network status based on the link detection information.

[0157] Optionally, the receiving module 12 is specifically used for:

[0158] If the packet identifier corresponding to the response packet is the same as the task identifier, then the response packet is deserialized to obtain the verification identification code corresponding to the response packet.

[0159] When the identification code to be verified is the same as the unique identification code, the callback function corresponding to the i-th probe task is obtained; the callback function is registered by the client based on the task identifier and the unique identification code before sending the probe data packet;

[0160] In the callback function, the response data packet is validated to obtain the validation result corresponding to the response data packet. When the validation result indicates that the response data packet has passed the validation, the execution result corresponding to the i-th probe task is determined based on the response data packet.

[0161] Based on the execution results, the link detection information from the client to the target network address is determined, and the memory of the detection task pool is reset.

[0162] The specific functional implementation of the sending module 11, receiving module 12, and reporting module 13 can be found in [reference needed]. Figure 2 Steps S101 to S103 in the corresponding embodiments will not be described again here.

[0163] In one or more embodiments, the sending module 11 includes: a heartbeat packet sending unit 111, a task pool acquisition unit 112, a format setting unit 113, and a serialization unit 114.

[0164] The heartbeat packet sending unit 111 is used to send heartbeat data packets to the heartbeat end according to the time frequency information, so that the heartbeat end can obtain the client's heartbeat information based on the reception time of the heartbeat data packets, and encapsulate the probe task pool issued by the strategy end into a response data packet corresponding to the heartbeat data packet;

[0165] The task pool acquisition unit 112 is used to receive the response data packet returned by the heartbeat terminal and acquire the probe task pool carried in the response data packet.

[0166] The format setting unit 113 is used to obtain the i-th probe task in the probe task pool and set the message format corresponding to the i-th probe task; i is a positive integer less than or equal to N;

[0167] The serialization unit 114 is used to generate a task identifier and a unique identification code for the i-th probe task, serialize the task identifier and unique identification code into a probe data packet based on the message format, and send the probe data packet to the target network address indicated by the i-th probe task.

[0168] The specific functional implementation of the heartbeat packet sending unit 111, task pool acquisition unit 112, format setting unit 113, and serialization unit 114 can be found in [reference needed]. Figure 2 Step S101 in the corresponding embodiment will not be described again here.

[0169] In one or more embodiments, the link detection device 1 further includes: a version update module 14, a preprocessing module 15, a task restart module 16, and a memory limit module 17;

[0170] Version update module 14 is used to receive version update information for the client from the heartbeat terminal, and obtain the target installation package corresponding to the client based on the version update information; and

[0171] Used to execute the installation script corresponding to the target installation package in the edge service node, and update the client to the target version indicated by the version update information.

[0172] Optionally, the probe task pool includes N probe tasks, where N is a positive integer;

[0173] Preprocessing module 15 is used to obtain the sending timestamp when the client sends the probe data packet to the target network address, and determine the response time range corresponding to the probe data packet based on the sending timestamp; and

[0174] This is used to remove the target network address from the probe task pool if the client does not receive the response packet corresponding to the probe packet within the response time range.

[0175] Task restart module 16 is used to save the running information of the i-th probe task on the client when the client's network connection is lost; and

[0176] This is used to continue executing the i-th probe task in the client based on the runtime information when the client's network connection is successfully reconnected.

[0177] Memory limit module 17 is used to obtain the memory usage of the client in the edge service node; and

[0178] Used to restart the client in the edge service node when memory usage exceeds the memory usage threshold.

[0179] The specific implementation methods of the version update module 14, preprocessing module 15, task restart module 16, and memory limit module 17 can be found in [link to documentation]. Figure 2 Step S102 in the corresponding embodiment will not be described again here.

[0180] In this embodiment, the probing process can start from the client deployed in the edge service node of the content delivery network and send a probe data packet to the target network address accessed by the real user in the current network (i.e., the network address indicated by the probe task in the probe task pool). Then, the link network status from the client to the target network address can be analyzed based on the response data packet corresponding to the probe data packet, which can improve the link coverage in the content delivery network and enhance the effectiveness of the link probing results.

[0181] Please see Figure 16 , Figure 16 This is a schematic diagram of a link detection device provided in an embodiment of this application. It can be understood that this link detection device can be applied in the proxy end of a link detection system; wherein, Figure 16 The link detection device 2 shown may include: an acquisition module 21 and a link analysis module 22;

[0182] The acquisition module 21 is used to acquire the link probe information reported by the client. The client is deployed on the edge service node in the content delivery network. The link probe information is determined by the response data packet corresponding to the probe data packet. The probe data packet is sent by the client to the target network address indicated by the probe task in the probe task pool. The probe task pool is sent to the client by the policy terminal through the heartbeat terminal.

[0183] The link analysis module 22 is used to analyze the link network status from the client to the target network address based on the link detection information.

[0184] The specific functional implementation methods of the acquisition module 21 and the link analysis module 22 can be found in [reference]. Figure 6 Steps S201 to S202 in the corresponding embodiments will not be described again here.

[0185] The link analysis module 22 includes: a packet loss rate statistics unit 221 and a fault marking unit 222;

[0186] The packet loss rate statistics unit 221 is used to calculate the packet loss rate of the first link from the client to the target network address based on the link detection information.

[0187] The fault marking unit 222 is used to determine that the network status of the link from the client to the target network address is faulty when the first link packet loss rate is greater than or equal to the first packet loss threshold, and to mark the target network address as a faulty network address.

[0188] The specific functional implementation methods of the packet loss rate statistics unit 221 and the fault marking unit 222 can be found in [reference]. Figure 6 Step S202 in the corresponding embodiment will not be described again here.

[0189] In one or more embodiments, the link detection device 2 further includes: a packet loss rate acquisition module 23 and a fault cancellation module 24;

[0190] Packet loss rate acquisition module 23 is used to acquire the packet loss rate of the second link from the client to the faulty network address;

[0191] The fault cancellation module 24 is used to determine that the link network status from the client to the faulty network address is in a recovered state and cancel the marking of the faulty network address when the second link packet loss rate is less than the second packet loss threshold.

[0192] The specific implementation methods of the packet loss rate acquisition module 23 and the fault cancellation module 24 can be found in [reference needed]. Figure 6 Step S202 in the corresponding embodiment will not be described again here.

[0193] In this embodiment, the probing process can start from the client deployed in the edge service node of the content delivery network and send probing data packets to the target network address accessed by real users on the existing network (i.e., the network address indicated by the probing task in the probing task pool). Then, the link network status from the client to the target network address can be analyzed based on the response data packets corresponding to the probing data packets, which can improve the link coverage in the content delivery network and enhance the effectiveness of the link probing results. Through the fault IP filtering strategy deployed on the proxy end, the link packet loss rate can be significantly reduced.

[0194] Further, please see Figure 17 , Figure 17 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 17 As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components; the user interface 1003 may include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 17 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0195] Among them, Figure 17 In the computer device 1000 shown, the network interface 1004 provides network communication functions, while the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0196] Obtain the probe task pool issued by the policy terminal, and send probe data packets to the target network address indicated by the probe task in the probe task pool;

[0197] Receive response packets in response to probe packets, and determine link probe information from the client to the target network address based on the response packets;

[0198] The link detection information is reported to the agent so that the agent can analyze the link network status based on the link detection information.

[0199] The client is deployed on an edge service node in the content delivery network.

[0200] Alternatively, processor 1001 can be used to call the device control application stored in memory 1005 to achieve:

[0201] Obtain link probe information reported by the client; the client is deployed on the edge service node in the content delivery network, and the link probe information is determined by the response data packet corresponding to the probe data packet. The probe data packet is sent by the client to the target network address indicated by the probe task in the probe task pool. The probe task pool is sent to the client by the policy terminal through the heartbeat terminal.

[0202] Based on the link detection information, analyze the network status of the link from the client to the target network address.

[0203] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 2 or Figure 6 The description of the link detection method in any of the corresponding embodiments can also be performed as described above. Figure 15 The corresponding embodiment includes link detection device 1 and Figure 16 The description of the link detection device 2 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0204] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned link detection device 1 and link detection device 2. The computer program includes computer instructions, and when the processor executes the computer instructions, it can execute the aforementioned... Figure 2 or Figure 6 The description of the link detection method in any of the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application. As an example, computer instructions can be deployed and executed on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. These multiple computing devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0205] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, causing the computer device to perform the aforementioned actions. Figure 2 or Figure 6 The description of the link detection method in any of the corresponding embodiments is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0206] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0207] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0208] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0209] 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 computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0210] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A link detection method, characterized in that, The method is executed by a client deployed at an edge service node in a content delivery network; the method includes: According to the time frequency information, the heartbeat data packet is sent to the heartbeat end so that the heartbeat end encapsulates the probe task pool issued by the strategy end into the response data packet corresponding to the heartbeat data packet; The system receives the response data packet returned by the heartbeat terminal, obtains the probe task pool carried by the response data packet, and sends a probe data packet to the target network address indicated by the probe task in the probe task pool; the target network address indicated by the probe task in the probe task pool is the target network address accessed by a real user on the current network. Receive a response data packet in response to the probe data packet, and obtain link probe information from the client to the target network address based on the response data packet; The link detection information is reported to the agent so that the agent can analyze the link network status based on the link detection information.

2. The method according to claim 1, characterized in that, Also includes: Receive version update information for the client sent by the heartbeat terminal, and obtain the target installation package corresponding to the client based on the version update information; The installation script corresponding to the target installation package is executed in the edge service node to update the client to the target version indicated by the version update information.

3. The method according to claim 1, characterized in that, The detection task pool includes N detection tasks, where N is a positive integer; Sending probe data packets to the target network address indicated by the probe task in the probe task pool includes: Obtain the i-th probe task from the probe task pool, and set the message format corresponding to the i-th probe task; i is a positive integer less than or equal to N; A task identifier and a unique identification code are generated for the i-th probe task. Based on the message format, the task identifier and the unique identification code are serialized into a probe data packet, and the probe data packet is sent to the target network address indicated by the i-th probe task.

4. The method according to claim 3, characterized in that, The step of obtaining link probe information from the client to the target network address based on the response data packet includes: If the data packet identifier corresponding to the response data packet is the same as the task identifier, then the response data packet is deserialized to obtain the verification identification code corresponding to the response data packet. When the identification code to be verified is the same as the unique identification code, the callback function corresponding to the i-th probe task is obtained; the callback function is registered by the client based on the task identifier and the unique identification code before sending the probe data packet; In the callback function, the response data packet is verified to obtain the verification result corresponding to the response data packet. When the verification result indicates that the response data packet has passed the verification, the execution result corresponding to the i-th probe task is determined based on the response data packet. Based on the execution result, the link detection information from the client to the target network address is determined, and the memory of the detection task pool is reset.

5. The method according to claim 1, characterized in that, Also includes: Obtain the sending timestamp when the client sends the probe data packet to the target network address, and determine the response time range corresponding to the probe data packet based on the sending timestamp; If the client does not receive a response data packet corresponding to the probe data packet within the response time range, the target network address is deleted from the probe task pool.

6. The method according to claim 3, characterized in that, Also includes: When the network connection of the client is disconnected, the running information of the i-th probe task in the client is saved; When the client's network connection is successfully reconnected, the i-th probe task continues to be executed in the client based on the running information.

7. The method according to claim 1, characterized in that, Also includes: Obtain the memory usage of the client in the edge service node; When the memory usage exceeds the memory usage threshold, the client is restarted in the edge service node.

8. A link detection method, characterized in that, The method is executed by the agent and includes: The system acquires link probe information reported by the client. The client is deployed on an edge service node in the content delivery network. The link probe information is determined by the response data packet corresponding to the probe data packet. The probe data packet is sent by the client to the target network address indicated by the probe task in the probe task pool. The target network address indicated by the probe task in the probe task pool is the target network address accessed by a real user on the current network. The probe task pool is issued by the policy terminal to the heartbeat terminal. When the heartbeat terminal receives the heartbeat data packet sent by the client, it sends it to the client in the form of a response data packet corresponding to the heartbeat data packet. Based on the link detection information, analyze the network status of the link from the client to the target network address.

9. The method according to claim 8, characterized in that, The step of analyzing the link network status from the client to the target network address based on the link detection information includes: Based on the link detection information, the packet loss rate of the first link from the client to the target network address is calculated. When the first link packet loss rate is greater than or equal to the first packet loss threshold, the network status of the link from the client to the target network address is determined to be faulty, and the target network address is marked as a faulty network address.

10. The method according to claim 9, characterized in that, Also includes: Obtain the packet loss rate of the second link from the client to the faulty network address; When the second link packet loss rate is less than the second packet loss threshold, the link network status from the client to the faulty network address is determined to be in a recovered state, and the faulty network address is unmarked.

11. A link detection device, characterized in that, The device is applied to a client, which is deployed at an edge service node in a content delivery network; the device includes: The heartbeat packet sending unit is used to send heartbeat data packets to the heartbeat end according to time frequency information, so that the heartbeat end encapsulates the probe task pool issued by the strategy end into a response data packet corresponding to the heartbeat data packet; The task pool acquisition unit is used to receive the response data packet returned by the heartbeat terminal, acquire the probe task pool carried by the response data packet, and send probe data packets to the target network address indicated by the probe task in the probe task pool; the target network address indicated by the probe task in the probe task pool is the target network address accessed by a real user on the current network. The receiving module is used to receive a response data packet in response to the probe data packet, and to obtain link probe information from the client to the target network address based on the response data packet; The reporting module is used to report the link detection information to the agent, so that the agent can analyze the link network status based on the link detection information.

12. A link detection device, characterized in that, The device is applied to the agent end and includes: The acquisition module is used to acquire link probe information reported by the client. The client is deployed on an edge service node in the content delivery network. The link probe information is determined by the response data packet corresponding to the probe data packet. The probe data packet is sent by the client to the target network address indicated by the probe task in the probe task pool. The target network address indicated by the probe task in the probe task pool is the target network address accessed by a real user on the current network. The probe task pool is issued by the policy terminal to the heartbeat terminal. When the heartbeat terminal receives the heartbeat data packet sent by the client, it sends it to the client in the form of a response data packet corresponding to the heartbeat data packet. The link analysis module is used to analyze the link network status from the client to the target network address based on the link detection information.

13. A computer device, characterized in that, Including memory and processor; The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to invoke the computer programs so that the computer device performs the method according to any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1 to 10.

15. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the method according to any one of claims 1 to 10.

Images