Download rate determination method and device and computer readable storage medium

After receiving the client's data download request on the server, sending the first data and obtaining the successful sending data amount and sending time when the client's data download process is over, calculating the client's download rate, solving the problem that the client's real download rate cannot be accurately reflected in the prior art, and achieving more accurate network congestion control and service quality monitoring.

CN120128547APending Publication Date: 2025-06-10HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410156124.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-12-08
Filing Date
2024-02-01
Publication Date
2025-06-10

AI Technical Summary

Technical Problem

When calculating the download rate of a client, the existing technology cannot accurately reflect the real download rate of the client, resulting in poor network congestion control and service quality monitoring.

Method used

After receiving the client's data download request on the server, the first data is sent and the successful data transmission amount and sending time are obtained when the client's data download process is completed, and the download rate of the client is calculated.

Benefits of technology

This method can more accurately reflect the real download rate of the client and improve the effectiveness of network congestion control and service quality monitoring.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120128547A_ABST
    Figure CN120128547A_ABST
Patent Text Reader

Abstract

The invention provides a downloading rate determination method and device and a computer readable storage medium, and is applied to a server in a data downloading system.The method comprises the steps that in the process that the server sends a plurality of data packets (referring to data needing to be downloaded by a client) to the client, the server sends the plurality of data packets to the client; if a confirmation message of the last data packet in the plurality of data packets returned by the client side is received, or a connection ending request or a reset request is sent to the client side, or the connection ending request or the reset request sent by the client side is received, the data volume successfully sent to the client side and the consumed sending time are obtained; according to the method and the system, the client side is provided with the successfully sent data volume and the sending time, and the successfully sent data volume is divided by the sending time to obtain the calculation efficiency of the client side. The obtained successfully sent data volume is very close to or even equal to the real downloading volume of the client side, and the obtained sending time is very close to the real downloading time of the client side; therefore, the calculated downloading rate of the client is closer to the real downloading rate of the client.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202311686395.0, filed with the China National Intellectual Property Administration on December 8, 2023, and the invention title "Method, Apparatus, and Computer-Readable Storage Medium for Determining Client Download Rate", the entire content of which is incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer networks, and in particular, to a method, apparatus, and computer-readable storage medium for determining download rate. Background Art

[0003] In a data download scenario, a server providing data download services calculates the download rate of a client to replace the download rate fed back by the client, so as to quickly optimize network congestion control algorithms (such as congestion control algorithms based on bandwidth and delay feedback (bottleneck bandwidth and round-trip propagation time, abbreviated as BBR), Cubic, etc.), better perform network congestion control, or, monitor the data download situation of the client in real time according to the download rate, so as to monitor the service quality provided to users.

[0004] Currently, the server takes the total amount of data to be sent to the client as the download data volume of the client, and takes the time when the server writes all the total data volume into the send buffer of the server as the download time of the client. Then, the download rate of the client is calculated by dividing the download data volume of the client by the download time of the client. After a large number of experimental verifications, the download rate of the client calculated by this method is very different from the true download rate of the client (referring to the download rate calculated by the client according to its actual download data situation), and cannot accurately reflect the true download rate of the client. As a result, after the server optimizes the network congestion control algorithm based on the calculated download rate of the client, the optimized network congestion control algorithm cannot perform good network congestion control, or the server cannot well monitor the service quality provided to users based on the calculated download rate of the client. Summary of the Invention

[0005] This application provides a method, apparatus, and computer-readable storage medium for determining download rate, which can enable the download rate of the client calculated by the server to be closer to the true download rate of the client and can more accurately reflect the true download rate of the client.

[0006] In a first aspect, a method for determining a download rate is provided, which is applied to a server in a data download system. The method includes the following steps: The server receives a data download request sent by a client and sends first data to the client based on the data download request. When the server determines that a first condition is met, it obtains the amount of data successfully sent to the client in the first data and the time consumed for sending, and calculates the download rate of the client based on the amount of data successfully sent to the client in the first data and the sending time. Herein, the first condition is that the server determines that it has received the acknowledgment (ACK) packet of the last packet among the multiple packets included in the first data returned by the client, or the first condition is that the server sends a finish request (which can also be referred to as a FIN packet) or a reset request (which can also be referred to as a RESET packet) to the client, or the first condition is that the server receives a finish request or a reset request sent by the client. The last packet is the packet with the largest sequence number among the multiple packets.

[0007] It can be understood that the client sends an ACK packet for the last data packet to the server, indicating that the client has received all the data packets and the data download process of the client ends. Therefore, if the server determines that it has received the ACK packet for the last data packet among the multiple data packets included in the first data returned by the client, it can determine that all the multiple data packets in the first data have been successfully sent to the client, and thus the server can determine that the data download process of the client ends; the server sends a FIN packet to the client, usually when the server has received the ACK packet for the last data packet returned by the client and determines that the first data has been successfully sent to the client in its entirety, to end the connection with the client. Therefore, if the server sends a FIN packet to the client, it can determine that the data download process of the client ends; the server sends a RESET packet to the client, usually when the server determines that an exception has occurred (such as the network being attacked, a network failure, not receiving a packet sent by the client within a certain period of time (i.e., the connection with the client times out), etc.), to forcibly interrupt the connection with the client. Therefore, if the server sends a RESET packet to the client, it can determine that the data download process of the client ends; the client sends a FIN packet to the server, usually after the client sends an ACK packet for the last data packet to the server, to end the connection with the server. Therefore, if the server receives a FIN packet sent by the client, it can determine that the client has received all the data packets, and thus determine that the data download process of the client ends; the client sends a RESET packet to the server, usually when the client determines that an exception has occurred (such as the network being attacked, a network failure, not receiving a packet sent by the client within a certain period of time (i.e., the connection with the client times out), etc.), to forcibly interrupt the connection with the server. Therefore, if the server receives a RESET packet sent by the client, it can determine that the data download process of the client ends.

[0008] In summary, the server determines that the first condition is met, that is, the server determines that the data download process of the client ends.

[0009] In the above solution, when the server meets the first condition, that is, when it determines that the data download process of the client ends, it calculates the download rate of the client based on the amount of data successfully sent to the client in the total data to be sent to the client (i.e., the above-mentioned first data) and the time consumed for sending. Since the amount of data successfully sent to the client is obtained as the downloaded data volume of the client, compared with the prior art where the server directly uses the total data volume to be sent to the client as the downloaded data volume of the client, obviously, the former is closer to or even is the actual downloaded data volume of the client (referring to the data volume downloaded when the client ends the data download process). Therefore, the former can more accurately reflect the actual downloaded data volume of the client. In addition, in the above solution, since the server uses the time consumed for sending the amount of data successfully sent to the client to the client as the download time of the client, compared with the prior art where the server uses the time when the total data volume to be sent to the client is written into the server's send buffer as the download time of the client, obviously, the former is closer to the actual download time of the client (referring to the time interval between the moment when the client sends a data download request to the server and the moment when the client ends the data download process). Therefore, the former can more accurately reflect the actual download time of the client.

[0010] It can be understood that when the obtained download time and downloaded data volume of the client are closer to the actual download time and actual downloaded data volume of the client and can more accurately reflect the actual download time and actual downloaded data volume of the client, the download rate of the client calculated based on the solution is closer to the actual download rate of the client than the download rate of the client calculated by the prior art and can more accurately reflect the actual download rate of the client.

[0011] In some possible implementation manners, the sending time is the time interval between the moment when the server determines that the first condition is met and the moment when the server receives the data download request.

[0012] To improve the flexibility of the solution, in some possible implementation manners, the sending time is the time interval between the moment when the server determines that the first condition is met and the first moment, and the first moment is any moment between the moment when the server receives the data download request and the moment when the server starts to write the first data into the server's send buffer.

[0013] In some possible implementation manners, the amount of data in the first data that is successfully sent to the client is the number of data packets in multiple data packets that are successfully sent to the client.

[0014] In some possible implementation manners, the server can specifically obtain the amount of data in the first data that is successfully sent to the client through the following method:

[0015] Based on the sequence number carried in the first ACK packet, and the sequence number of the first packet among multiple packets, calculate the number of packets successfully sent to the client among the multiple packets, where the first ACK packet is the last ACK packet received by the server from the client based on the received packets before determining that the first condition is met, and the first packet is the packet with the smallest sequence number among the multiple packets.

[0016] In some possible implementation manners, the above method further includes the following steps: The server receives the ACK packet of the first packet returned by the client, and the first packet belongs to multiple packets; when the server determines that the sequence number carried in the ACK packet of the first packet is greater than the sequence number of the last packet among the multiple packets, it determines that it has received the ACK packet of the last packet among the multiple packets included in the first data returned by the client.

[0017] In some possible implementation manners, the above method further includes the following steps: The server sends the download rate of the client to the client.

[0018] The server sends the download rate of the client to the client, and the client displays the download rate to the user. Without the user having to spend effort to monitor it, the user's workload can be reduced and the user experience can be optimized.

[0019] In some possible implementation manners, the above method further includes the following steps: The server uses an extended Berkeley packet filter (eBPF) to monitor each packet of the interaction between the server and the client, and determines whether the first condition is met based on each packet.

[0020] In the above implementation manner, the server uses the eBPF method to determine whether the first condition is met. Since the eBPF method belongs to a kernel-level technology, and each packet of the interaction between the server and the client is stored in the kernel space of the server, the server can run the eBPF program in the kernel space to directly monitor each packet of the interaction between the server and the client stored in the kernel space, and determine whether the first condition is met. For example, it determines whether the packet received by the server is the ACK packet of the last packet sent by the client, or the FIN packet or RESET packet sent by the client, without copying each packet of the interaction between the server and the client stored in the kernel space to the user space and having the application program in the user space determine whether the first condition is met, which can improve the monitoring efficiency and thus improve the acquisition efficiency of the download rate of the client.

[0021] In some possible implementation manners, the first data is video, audio, document, table or picture.

[0022] Second aspect, a download rate determination device is provided, which is applied to a server in a data download system. The device includes:

[0023] A receiving module, configured to receive a data download request sent by a client;

[0024] A sending module, configured to send first data to the client based on the data download request;

[0025] A processing module, configured to, when determining that a first condition is satisfied, obtain the amount of data successfully sent to the client in the first data and the time consumed for sending, where the first condition is that the server determines that it has received an ACK message for the last data packet among a plurality of data packets included in the first data sent to the client, or the first condition is that the server sends a connection close request or a reset request to the client, or the first condition is that the server receives a connection close request or a reset request sent by the client, and the last data packet is the data packet with the largest sequence number among the plurality of data packets;

[0026] The processing module is further configured to calculate the download rate of the client based on the amount of data successfully sent to the client in the first data and the sending time.

[0027] In some possible implementation manners, the sending time is the time interval between the moment when the server determines that the first condition is satisfied and the moment when the server receives the data download request.

[0028] In some possible implementation manners, the sending time is the time interval between the moment when the server determines that the first condition is satisfied and a first moment, where the first moment is any moment between the moment when the server receives the data download request and the moment when the server starts to write the first data into the sending buffer of the server.

[0029] In some possible implementation manners, the amount of data successfully sent to the client in the first data is the number of data packets successfully sent to the client among the plurality of data packets.

[0030] In some possible implementation manners, the processing module is specifically configured to:

[0031] Based on the sequence number carried in the first ACK packet and the sequence number of the first packet among the multiple packets, calculate the number of packets successfully sent to the client among the multiple packets, where the first ACK packet is the last ACK packet received by the server from the client based on the received packets before determining that the first condition is satisfied, and the first packet is the packet with the smallest sequence number among the multiple packets.

[0032] In some possible implementation manners, the receiving module is further configured to receive an ACK packet of a first packet returned by the client, where the first packet belongs to the multiple packets;

[0033] The processing module is further configured to, when determining that the sequence number carried in the ACK packet of the first packet is greater than the sequence number of the last packet among the multiple packets, determine that the ACK packet of the last packet among the multiple packets included in the first data returned by the client is received.

[0034] In some possible implementation manners, the sending module is further configured to send the download rate of the client to the client.

[0035] In some possible implementation manners, the processing module is configured to monitor each packet of the interaction between the server and the client by using the eBPF method, and determine whether the first condition is satisfied based on each packet.

[0036] In some possible implementation manners, the first data is video, audio, document, table or picture.

[0037] In a third aspect, a computing device is provided, which includes a processor and a memory. The memory is used to store instructions, and the processor is used to execute the instructions so that the computing device implements the method described in the first aspect and any implementation manner of the first aspect.

[0038] In a fourth aspect, a computer-readable storage medium is provided, in which instructions are stored. When the instructions are run by a computing device or a computing device cluster, the method described in the first aspect and any implementation manner of the first aspect is implemented.

[0039] In a fifth aspect, a computing device cluster is provided, which includes at least one computing device. Each computing device in the at least one computing device includes a processor and a memory. The processor of the at least one computing device is used to execute the instructions stored in the memory of the at least one computing device so that the computing device cluster implements the method described in the first aspect and any implementation manner of the first aspect.

[0040] In a sixth aspect, there is provided a computer program product comprising instructions, which can run on a computing device or be stored in software or a program product in any available medium. When the computer program product runs on a computing device or a cluster of computing devices, the computing device or the cluster of computing devices is caused to execute the method described in the first aspect and any implementation manner of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 FIG. is a schematic architecture diagram of a video resource download system according to an embodiment of the present application;

[0042] Figure 2 FIG. is a schematic diagram of a process for a server to send a video resource to a client according to an embodiment of the present application;

[0043] Figure 3 FIG. is a schematic flowchart of a download rate determination method according to an embodiment of the present application;

[0044] Figure 4 FIG. is a schematic diagram of a flag bit in a message according to an embodiment of the present application;

[0045] Figure 5 FIG. is a schematic flowchart of a process for a server to obtain the amount of data successfully sent to a client in first data and the transmission time consumed according to an embodiment of the present application;

[0046] Figure 6 FIG. is a schematic flowchart of another process for a server to obtain the amount of data successfully sent to a client in first data and the transmission time consumed according to an embodiment of the present application;

[0047] Figure 7 FIG. is a schematic flowchart of another download rate determination method according to an embodiment of the present application;

[0048] Figure 8 FIG. is a schematic structural diagram of a download rate determination device according to an embodiment of the present application;

[0049] Figure 9 FIG. is a schematic structural diagram of a computing device according to an embodiment of the present application;

[0050] Figure 10 FIG. is a schematic structural diagram of a cluster of computing devices according to an embodiment of the present application;

[0051] Figure 11 FIG. is a schematic structural diagram of another cluster of computing devices according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0052] First, a data download scenario related to the present application will be introduced in detail.

[0053] Taking Figure 1 the video resource download scenario shown as an example, as Figure 1 shown, the video resource download system includes multiple clients 100 and a server 200.

[0054] The client 100 can also be referred to as a receiving end or a download end, and is deployed on the user's terminal device for realizing human-computer interaction. It can receive the video download operation input by the user and process the operation into a video download request to send to the server 200, requesting to download the required video resources. The client 100 can be an application (APP), a plug-in, etc. with video download and playback functions running on the terminal device controlled by the user, such as a personal computer (PC) client, or a web client accessed based on a browser, or an application (APP) client running on a mobile terminal, or a console of a cloud platform. This application does not make specific limitations. The terminal device includes personal computers, smart phones, wearable devices, handheld processing devices, tablet computers, mobile notebooks, augmented reality (AR) devices, virtual reality (VR) devices, integrated handheld game consoles, wearable devices, in-vehicle devices, intelligent conference devices, intelligent advertising devices, intelligent household appliances, etc. Specific limitations are not made here.

[0055] The server 200 can also be referred to as a sending end or a resource providing end, and is deployed in a single computing device or a computing device cluster composed of multiple computing devices. Among them, the computing device includes a bare metal server (BMS), a virtual machine (VM), a container, or an edge computing device. BMS refers to a general physical server, for example, an ARM server or an X86 server; a virtual machine refers to a complete computer system with complete hardware system functions simulated by software and running in a completely isolated environment. All the work that can be completed in a physical computer can be achieved in a virtual machine. When creating a virtual machine in a computing device, a part of the hard disk and memory capacity of the physical machine needs to be used as the hard disk and memory capacity of the virtual machine. Each virtual machine has an independent basic input / output system (BIOS), hard disk, and operating system, and can be operated like a physical machine; a container is a portable software unit that can combine an application and all its dependencies into a software package, and this software package is not restricted by the underlying host operating system, so there is no need to build a complex environment anymore, simplifying the process from application development to deployment; an edge computing device refers to a device that is closer to the data source and end user and has the characteristics of low latency and high bandwidth, such as an intelligent router, an edge server, etc.; the computing device cluster can include multiple of the above-mentioned computing devices, such as a data center, which is not specifically limited in this application.

[0056] A large number of video resources are locally stored in the server 200, including one or more of movies (such as comedy movies, suspense movies), TV series (such as ancient costume TV series, fantasy TV series), variety shows (such as food shows, travel shows), live videos (such as sports event live broadcasts, news live broadcasts), animations (such as funny animations, thriller animations), etc. When receiving a video download request sent by the client 100, the corresponding video resource can be found based on the video download request and returned to the client 100. Optionally, a large number of video resources can also be stored by a dedicated storage system. When the server 200 receives a video download request sent by the client 100, it accesses the storage system based on the video download request, requests to obtain the corresponding video resource, and returns it to the client 100 after obtaining the corresponding video resource.

[0057] The process of the server 200 returning the corresponding video resource to the client 100 is as Figure 2As shown in the figure: First, the application program in the user space of the server 200 writes the video resource into the send buffer in the kernel space of the server 200. Then, the kernel in the kernel space transfers the video resource in the send buffer to the client 100, thus realizing the transfer of the video resource to the client 100. Among them, the application program in the user space of the server 200 refers to the program code responsible for processing video resource search and sending services, which can also be called business layer code, or application layer code, etc.; the send buffer in the kernel space of the server 200 refers to the buffer used by the server 200 to store data to be sent, which can be understood as a temporary cache; by using the send buffer, after the application program in the user space of the server 200 copies the video resource to the send buffer, it can immediately process other tasks, and the remaining task of sending the video resource in the send buffer to the client 100 is executed by the kernel in the kernel space.

[0058] It can be seen that there is a communication connection between the client 100 and the server 200. In a specific implementation, this communication connection can be a wired network connection or a wireless network connection. Further, the client 100 and the server 200 can communicate through the Transmission Control Protocol (TCP). This application does not make specific limitations.

[0059] It should be understood that Figure 1 Merely as an example of the video resource download scenario. For example, in actual applications, the number of the client 100 and the server 200 can be one or any number. Another example is that the video resource download scenario also includes network devices for forwarding communication data between the client 100 and the server 200, such as base stations, routers, switches, etc. This application does not make specific limitations.

[0060] It can be understood that in addition to the above video resource download scenario, there can be other application scenarios. For example, the audio resource download scenario, and the audio resources in this scenario include but are not limited to songs, pure music, audiobooks, etc. For example, the document resource download scenario, and the document resources in this scenario include but are not limited to e-books, exam questions, papers, patents, etc. For example, the picture resource download scenario, and the picture resources in this scenario include but are not limited to wallpapers, avatars, high-definition beautiful pictures, etc.

[0061] In the above data download scenario, the server 200 usually calculates the download rate of the client 100 to use this download rate instead of the download rate feedback by the client 100 to quickly optimize the network congestion control algorithm (such as BBR, Cubic, etc.) and better control network congestion, or, according to this download rate, monitor the data download situation of the client in real time, so as to monitor the service quality provided to users.

[0062] Currently, the server 200 calculates the download rate of the client 100 in the following way: the server 200 uses the total amount of data to be sent to the client 100 as the download data volume of the client 100, and uses the time when the server 200 writes all the total data volume into the send buffer of the server 200 as the download time of the client 100. Then, the download rate of the client 100 is calculated by dividing the download data volume of the client 100 by the download time of the client 100.

[0063] However, through a large number of experimental verifications, the download rate of the client 100 calculated by the server 200 in the above way is very different from the true download rate of the client 100 (referring to the download rate calculated by the client 100 according to its actual downloaded data situation), and it cannot accurately reflect the true download rate of the client 100. As a result, after the server 200 optimizes the network congestion control algorithm based on the calculated download rate of the client 100, the optimized network congestion control algorithm cannot well control the network congestion, or it leads to the situation that the server cannot well monitor the service quality provided to users based on the calculated download rate of the client.

[0064] Regarding the problem that the download rate of the client 100 calculated by the server 200 is very different from the true download rate of the client 100 and cannot accurately reflect the true download rate of the client 100, this application provides a download rate determination method and device, etc., which will be introduced in detail below with reference to the corresponding drawings.

[0065] See Figure 3 , Figure 3 is a schematic flowchart of a download rate determination method provided by an embodiment of this application. As Figure 3 shown, it includes the following steps:

[0066] S301: The server receives a data download request sent by the client and sends the first data to the client based on the data download request.

[0067] The data download request is used to request the download of the first data, and may include the identifier of the first data, so that the server can find the first data from a large amount of data according to the identifier and return it to the client. Among them, the identifier of the first data can be the storage path of the first data (such as the uniform resource locator (URL)), the name of the first data, etc. The first data can be videos, audios, pictures, documents, tables, etc. Videos include but are not limited to movies, TV dramas, variety shows, live videos, animations, etc. Audios include but are not limited to songs, pure music, audiobooks, etc. Pictures include but are not limited to wallpapers, avatars, high-definition beautiful pictures, etc. Documents include but are not limited to e-books, exam questions, papers, patents, etc. Taking the identifier of the first data as the name of the first data as an example, when the first data is a movie video, the name of the first data can be the movie name, and when the first data is a song audio, the name of the first data can be the song name.

[0068] Optionally, the data download request may further include the domain name corresponding to the server where the first data is located, so that the server can find the server to which the first data belongs from different servers under different domain names according to the domain name, and then find the first data from the server to which the first data belongs according to the identifier of the first data. Among them, the domain name of the server can be understood as the unique identifier of the server for the client to access it. For example, the server can pre-store the corresponding relationship between server C and the domain name C' of server C, and pre-store the corresponding relationship between server D and the domain name D' of server D. Subsequently, if the server receives a data download request from the client carrying the domain name C', it can locate to server C according to the domain name C' in the data download request, find the data required for download by the client on server C, and return it to the client. If it receives a data download request from the client carrying the domain name D', it can locate to server D according to the domain name D' in the data download request, find the data required for download by the client on server D, and return it to the client.

[0069] Optionally, the data download request may further include a session ID between the server and the client, usually composed of the source IP address, source port number, destination IP address, and destination port number. This session ID is used to identify the connection between the server and the client. So that after the server locates the first data, it can locate the client according to this session ID and send the first data to the client. In addition, the session ID remains unchanged during the entire session between the server and the client (i.e., during the entire data download process). In other words, during the entire session, all interaction messages between the server and the client will carry this session ID. Therefore, the session ID can be used by the server to track each message during the session process and monitor the entire session process. Among them, the source IP address refers to the IP address of the device to which the client belongs, used to identify the device to which the client belongs. The source port number refers to the port number used by the client to communicate with the server. The destination IP address refers to the IP address of the device to which the server belongs, used to identify the device to which the server belongs. The destination port number refers to the port number used by the server to communicate with the client.

[0070] When the server sends the first data to the client based on the data download request, for reliable transmission, the first data is usually split into multiple data packets with sequence numbers. Then, the multiple data packets are transmitted to the client one by one in ascending order of the sequence numbers. The sequence numbers of the multiple data packets can start from 0 or any value. For example, if the server splits the first data into 100 data packets, the sequence numbers of these 100 data packets can be 0 - 99, or 1 - 100. This application does not make specific limitations on this.

[0071] Further, the process of the server transmitting the multiple data packets to the client one by one in ascending order of the sequence numbers is as follows: The server first writes the multiple data packets into the server's send buffer one by one in ascending order of the sequence numbers, and then sends the multiple data packets in the send buffer to the client one by one in ascending order of the sequence numbers.

[0072] Specifically, when the server sends each data packet in the send buffer to the client, the data packet will carry its own sequence number. Therefore, the server can track and confirm the sent data packets according to the sequence numbers. Moreover, since the data packets sent by the server to the client carry sequence numbers, when the client receives the data packets from the server, it can confirm the received data packets according to the sequence numbers carried by the data packets, and determine whether there are any missing data packets according to the sequence numbers of the data packets. When it is determined that there are missing data packets, it can send a notification to the server, requesting the server to retransmit the missing data packets. After the client receives all the data packets, it can also perform data recombination according to the sequence numbers of the data packets.

[0073] In addition, each time the client receives a data packet, it sends an acknowledgement (ACK) message carrying the sequence number of the next data packet expected to be received by the client to the server. Among them, the sequence number of the next data packet expected to be received by the client = the sequence number of the data packet received by the client this time + 1. Therefore, when the server receives the ACK message from the client, based on the sequence number of the next data packet expected to be received by the client carried in the ACK message, the server can know which is the next data packet expected to be received by the client and can know that the client has successfully received the data packets sent by the server before.

[0074] S302: The server determines whether the first condition is met. When it is determined that the first condition is met, S303 is executed. When it is determined that the first condition is not met, S302 is executed again.

[0075] The first condition is that the server determines that it has received the ACK message of the last data packet among the multiple data packets included in the first data returned by the client, or the first condition is that the server sends a finish message (which can also be called a FIN message, a close connection request, etc.) or a reset message (which can also be called a RESET message, a reset request, etc.) to the client, or the first condition is that the server receives a FIN message or a RESET message sent by the client. Among them, the last data packet among the multiple data packets refers to the data packet with the largest sequence number after sorting the multiple data packets in ascending order of sequence number, and it is also the data packet that the server finally sends to the client among the multiple data packets.

[0076] It can be understood that the client sends an ACK message for the last data packet to the server, indicating that the client has received all data packets and the data download process of the client ends. Therefore, if the server determines that it has received the ACK message for the last data packet among the multiple data packets included in the first data returned by the client, it can determine that all the multiple data packets in the first data have been successfully sent to the client, and thus the server can determine that the data download process of the client ends; the server sends a FIN message to the client, usually when the server has received the ACK message for the last data packet returned by the client and determines that the first data has been all successfully sent to the client, to end the connection with the client. Therefore, if the server sends a FIN message to the client, it can determine that the data download process of the client ends; the server sends a RESET message to the client, usually when the server determines that an exception occurs (such as the network being attacked, network failure, not receiving a message sent by the client within a certain time (i.e., the connection with the client times out), etc.), to forcibly interrupt the connection with the client. Therefore, if the server sends a RESET message to the client, it can determine that the data download process of the client ends; the client sends a FIN message to the server, usually after the client sends the ACK message for the last data packet to the server, to end the connection with the server. Therefore, if the server receives the FIN message sent by the client, it can determine that the client has received all data packets, and thus determine that the data download process of the client ends; the client sends a RESET message to the server, usually when the client determines that an exception occurs (such as the network being attacked, network failure, not receiving a message sent by the client within a certain time (i.e., the connection with the server times out), etc.), to forcibly interrupt the connection with the server. Therefore, if the server receives the RESET message sent by the client, it can determine that the data download process of the client ends.

[0077] It can also be understood that when the server determines that the data download process of the client ends, when executing S303, the data volume successfully sent by the server to the client and the transmission time consumed will be relatively accurate, so that the download rate of the client calculated based on the data volume successfully sent to the client and the transmission time consumed will also be relatively accurate.

[0078] The process by which the server determines whether the first condition is met is described in detail below. The ways for the server to determine whether the first condition is met include at least the following two:

[0079] In the first way, the server determines whether the first condition is met based on the message sent by the server to the client.

[0080] Specifically, when the server sends each message (which may carry data packets or may not carry data packets) to the client, it can determine whether the message is a FIN message or a RESET message based on the flag bit indicating the message type in each message. Specifically, as Figure 4 shown, when the FIN field of the flag bit indicating the message type in the message is "1", the server can determine that the message is a FIN message, and then determine that it has sent a FIN message to the client, determining that the first condition is met. When the RST field of the flag bit indicating the message type in the message is "1", the server can determine that the message is a RESET message, and then determine that it has sent a RESET message to the client, determining that the first condition is met. When other fields of the flag bit indicating the message type in the message are "1", the server can determine that the message is neither a FIN message nor a RESET message, and then determine that it has not sent a FIN message or a RESET message to the client, determining that the first condition is not met.

[0081] In the second method, the server determines whether the first condition is met based on the message received from the client.

[0082] Specifically, when the server receives each message from the client, it can determine whether the message is an ACK message, a FIN message, or a RESET message based on the flag bit indicating the message type in each message. Specifically, when the ACK field of the flag bit indicating the message type in the message is "1", the server can determine that the message is an ACK message, and then determine that it has received an ACK message sent by the client. Then, the server can further determine whether the ACK message is the ACK message for the last data packet (see the description in the next paragraph for the specific determination process). When it is determined that the ACK message is the ACK message for the last data packet, the server can determine that the first condition is met. When it is determined that the ACK message is not the ACK message for the last data packet, the server can determine that the first condition is not met. When the FIN field of the flag bit indicating the message type in the message is "1", the server can determine that the message is a FIN message, and then determine that it has received a FIN message sent by the client, determining that the first condition is met. When the RST field of the flag bit indicating the message type in the message is "1", the server can determine that the message is a RESET message, and then determine that it has received a RESET message sent by the client, determining that the first condition is met. When other fields of the flag bit indicating the message type in the message are "1", the server can determine that the message is not an ACK message, a FIN message, or a RESET message, and then determine that it has not received an ACK message, a FIN message, or a RESET message sent by the client, thereby determining that the first condition is not met.

[0083] The process for the server to determine whether the ACK packet from the client is the ACK packet of the last data packet is as follows: When the server sends the first data to the client, it records the sequence number of the last data packet. Then, when the server determines that it has received an ACK packet from the client, it judges whether the sequence number of the next data packet that the client expects to receive carried by the ACK packet is greater than the sequence number of the last data packet recorded by the server. If it is determined to be greater, it is determined that the ACK packet is the ACK packet of the last data packet; otherwise, it is determined that the ACK packet is not the ACK packet of the last data packet. For example, assume that the first data includes 100 data packets with corresponding sequence numbers 0 - 99, and the sequence number of the last data packet recorded by the server is 99. If the server receives an ACK packet from the client based on the data packet with a sequence number of 50, since the sequence number of the next data packet that the client expects to receive carried by the ACK packet is 51, the server determines that the sequence number 51 is less than the sequence number 99 of the last data packet recorded, and thus determines that the ACK packet is not the ACK packet of the last data packet (i.e., the data packet with a sequence number of 99). Assume again that the server receives an ACK packet from the client based on the data packet with a sequence number of 99. Since the sequence number of the next data packet that the client expects to receive carried by the ACK packet is 100, the server determines that the sequence number 100 is greater than the sequence number 99 of the last data packet recorded, and thus determines that the ACK packet is the ACK packet of the last data packet (i.e., the data packet with a sequence number of 99).

[0084] In a possible embodiment, the server may provide data download services for multiple clients within the same time period. Some of these multiple clients may need to calculate the download rate, while some do not. The server only needs to determine whether the first condition is met for the clients that need to calculate the download rate. Specifically, the server can monitor the interaction packets between the server and the clients that need to calculate the download rate according to the session identifier, and determine whether the first condition is met based on the interaction packets.

[0085] For example, for client A that needs to calculate the download rate, when the server receives a data download request from client A, it can record the session identifier of the server and client A carried in the data download request (for the description of the session identifier, please refer to the relevant description in S301). For client B that does not need to calculate the download rate, when the server receives a data download request from client B, it does not need to record the session identifier of the server and client B carried in the data download request. Then, when the server sends and receives each packet, it can check whether the session identifier carried in the packet exists in the recorded session identifiers. If it is determined that it exists, it is determined that the packet belongs to the packet of the client that needs to calculate the download rate. Then, based on the packet, it is determined whether the first condition is satisfied. If it is determined that it does not exist, it is determined that the packet does not belong to the packet of the client that needs to calculate the download rate, and there is no need to determine whether the first condition is satisfied based on the packet.

[0086] In a possible embodiment, the server may provide data download services for different servers under multiple domain names (such as server C with domain name C' and server D with domain name D') within the same time period. Different servers under the multiple domain names may partially need to monitor the download rate of the clients accessing them, and some servers do not need to monitor the download rate of the clients accessing them. The server only needs to determine whether it is necessary to calculate the download rate for the clients of the servers that need to monitor the clients accessing them. Specifically, the server can determine whether the client needs to calculate the download rate according to the domain name.

[0087] For example, for server C (domain name C′) that needs to monitor the download rate of the client accessing it, the server can pre-store the domain name C′ of server C. For server D (domain name D′) that does not need to monitor the download rate of the client accessing it, the server does not need to pre-store the domain name D′ of server D. Then, when the server receives a data download request from client E, it can check whether the domain name carried in the data download request of client E exists in the pre-stored domain names. If it is determined that the domain name carried in the data download request of client E exists in the pre-stored domain names, it is determined that client E needs to calculate the download rate, and then the session identifier of the server and client E carried in the data download request is recorded. Then, when the server sends and receives each message, it can check whether the session identifier carried in the message exists in the recorded session identifiers. If it is determined that it exists, it is determined that the message belongs to the message of the client that needs to calculate the download rate, and it is determined whether the first condition is satisfied based on the message. If it is determined that it does not exist, it is determined that the message does not belong to the message of the client that needs to calculate the download rate, and there is no need to determine whether the first condition is satisfied based on the message; if it is determined that the domain name carried in the data download request of client E does not exist in the pre-stored domain names, it is determined that client E does not need to calculate the download rate.

[0088] S303: The server obtains the amount of data successfully sent to the client in the first data and the time consumed for sending, and calculates the download rate of the client based on the amount of data successfully sent to the client in the first data and the time consumed for sending.

[0089] The amount of data successfully sent to the client in the first data can be understood as the amount of data successfully downloaded by the client in the first data statistically by the server. The downloaded data amount can be in bytes or in the number of data packets. This application does not make specific limitations on this.

[0090] The time consumed for sending obtained by the server can be understood as the download time of the client statistically by the server.

[0091] The server can directly use the quotient obtained by dividing the amount of data successfully sent to the client in the first data by the time consumed for sending as the download rate of the client.

[0092] Optionally, the server can also correct the amount of data successfully sent to the client in the first data and the time consumed for sending (such as rounding, accurate to several decimal places), and then use the quotient obtained by dividing the corrected amount of data successfully sent to the client by the corrected sending time as the download rate of the client.

[0093] Optionally, the server can also correct (such as rounding, or being accurate to a certain number of decimal places) the quotient obtained by dividing the amount of data successfully sent to the client in the first data by the consumed sending time, and use the corrected value as the download rate of the client.

[0094] For the process by which the server obtains the amount of data successfully sent to the client in the first data and the consumed sending time, please refer to Figure 5 and Figure 6 the relevant descriptions.

[0095] In a possible embodiment, after calculating the download rate of the client, the server can also send the download rate to the client, and the client can display the download rate to the user. This way, the user does not need to spend effort on monitoring, which can reduce the user's workload and optimize the user experience.

[0096] Optionally, after statistically obtaining the download data volume and download time of the client, the server can also send the download data volume and download time of the client to the client, and the client can display the download data volume and download time to the user. This way, the user does not need to spend effort on monitoring, which can reduce the user's workload and optimize the user experience.

[0097] In the above Figure 3 scheme, when the first condition is met, that is, when it is determined that the data download process of the client ends, the server calculates the download rate of the client based on the amount of data successfully sent to the client in the total data to be sent to the client (i.e., the above-mentioned first data) and the consumed sending time. Since the amount of data obtained is the amount of data successfully sent to the client and is used as the download data volume of the client, compared with the prior art where the server directly uses the total data volume to be sent to the client as the download data volume of the client, obviously, the former is closer to or even is the real download data volume of the client (referring to the data volume downloaded when the client ends the data download process). Therefore, the former can more accurately reflect the real download data volume of the client. In addition, since in the above Figure 3 scheme, the server uses the sending time consumed for sending the amount of data successfully sent to the client to the client as the download time of the client, compared with the prior art where the server uses the time when the total data volume to be sent to the client is written into the sending buffer of the server as the download time of the client, obviously, the former is closer to the real download time of the client (referring to the time interval between the moment when the client sends a data download request to the server and the moment when the client ends the data download process). Therefore, the former can more accurately reflect the real download time of the client.

[0098] It can be understood that in Figure 3The download time and download data volume of the client obtained by the shown solution are closer to the true download time and true download data volume of the client, and can more accurately reflect the true download time and true download data volume of the client. Based on Figure 3 The download rate of the client calculated according to the shown solution is closer to the true download rate of the client than the download rate of the client calculated by the prior art, and can more accurately reflect the true download rate of the client.

[0099] The following combines Figure 5 and Figure 6 to introduce possible implementation manners for the server to obtain the data volume successfully sent to the client in the first data and the consumed sending time.

[0100] Possible implementation manner 1, see Figure 5 the process shown:

[0101] S501: When the server receives a data download request sent by the client, record the first moment as the start download moment of the client.

[0102] The data download request can refer to the introduction in S301.

[0103] The first moment is the moment when the server receives the data download request sent by the client, or any moment between the moment when the server receives the data download request sent by the client and the moment when the server starts to write the first data into the sending buffer of the server based on the data download request.

[0104] The first moment can also be understood as the start sending moment of the server, which refers to the moment when the server starts to send the first data to the client.

[0105] S502: When the server sends the first data to the client based on the data download request, record the sequence number start_seq of the first data packet and the sequence number end_seq of the last data packet in the multiple data packets included in the first data.

[0106] The first data, multiple data packets, and sequence numbers of multiple data packets can refer to the introduction in S301.

[0107] Since the server sends multiple data packets to the client one by one in ascending order of the sequence numbers of the multiple data packets, it can be understood that the first data packet, that is, the first data packet to be sent by the server to the client, is the data packet with the smallest sequence number among the multiple data packets, and the last data packet, that is, the last data packet to be sent by the server to the client, is the data packet with the largest sequence number among the multiple data packets.

[0108] S503: The server determines whether the first condition is met. When it is determined that the first condition is met, S504 - S506 are executed. When it is determined that the first condition is not met, S503 is executed again.

[0109] The first condition can be referred to the introduction in S302.

[0110] The process of the server determining whether the first condition is met has been described in detail in S302. Please refer to the relevant content of S302. For the sake of simplicity of the specification, it will not be elaborated here.

[0111] S504: The server records the second moment as the end - download moment of the client. The second moment is the moment when the server determines that the first condition is met.

[0112] Based on the description in S302, when the server determines that the first condition is met, the server can also determine that the data - download process of the client ends. Therefore, the server can record the second moment as the end - download moment of the client.

[0113] Optionally, the second moment can also be any moment within a very short period (such as a few microseconds) after the server determines that the first condition is met. This application does not make specific limitations on the second moment.

[0114] S505: The server calculates the consumed transmission time as the download time of the client based on the end - download moment of the client and the start - download moment of the client.

[0115] The download time of the client = the consumed transmission time = the end - download moment of the client - the start - download moment of the client = the second moment - the first moment.

[0116] S506: The server calculates the amount of data successfully sent from the first data to the client as the downloaded data volume of the client based on the sequence number carried in the ACK packet returned by the client based on the received data packet for the last time before determining that the first condition is met, and the sequence number start_seq of the first data packet recorded in S502.

[0117] The server can calculate the amount of data successfully sent from the first data to the client through the following calculation method (1):

[0118] Calculation method (1), the amount of data successfully sent from the first data to the client = the sequence number carried in the ACK packet returned by the client based on the received data packet for the last time before determining that the first condition is met - the sequence number start_seq of the first data packet recorded in S502.

[0119] Optionally, S506 can also be: when the server determines that the first condition is met, based on the sequence numbers of the remaining data packets in the server's send buffer and the sequence number start_seq of the first data packet recorded in S502, the server calculates the amount of data successfully sent to the client in the first data. Specifically, the server can calculate it through the following calculation method (2) to obtain the amount of data successfully sent to the client in the first data:

[0120] Calculation method (2): The amount of data successfully sent to the client in the first data = the minimum sequence number of the remaining data packets in the server's send buffer - the sequence number start_seq of the first data packet recorded in S502. Taking the sequence numbers of multiple data packets as 0 - 99, and when the server determines that the first condition is met, the minimum sequence number of the remaining data packets in the server's send buffer is 49 as an example, then the amount of data successfully sent to the client in the first data calculated by the server = the minimum sequence number 49 of the remaining data packets in the server's send buffer - the sequence number start_seq (i.e., 0) of the first data packet recorded in S502 = 49.

[0121] It can be understood that when the first condition is that the server determines that it has received the ACK packet of the last data packet among the multiple data packets included in the first data returned by the client, or when the first condition is that the server has sent a FIN packet to the client, or when the first condition is that the server has received a FIN packet sent by the client, the last ACK packet returned by the client based on the received data packets received by the server is the ACK packet of the last data packet. At this time, the server can also calculate the amount of data successfully sent to the client in the first data through the following calculation formula: The amount of data successfully sent to the client in the first data = the sequence number end_seq of the last data packet - the sequence number start_seq of the first data packet + 1, where the sequence number end_seq of the last data packet can be the one recorded in S502 or the sequence number of the next data packet expected to be received by the client carried in the ACK packet of the last data packet - 1.

[0122] It should be understood that the above calculation methods for the amount of data successfully sent to the client in the first data are only examples and should not be regarded as specific limitations.

[0123] In Figure 5In S501, the server records the first moment as the start download moment of the client. The first moment is the moment when the server receives the data download request sent by the client, or the first moment is any moment between the moment when the server receives the data download request sent by the client and the moment when the server starts writing the first data into the server's send buffer based on the data download request. Compared with the prior art, in which the server takes the moment when it starts writing the data required by the client into the server's send buffer after finding the data required by the client based on the data download request as the start download moment of the client, the former is closer to the real start download moment of the client (the moment when the client sends the data download request to the server), and can more accurately reflect the real start download moment of the client. In addition, in Figure 5 In S504, the server records the second moment as the end download moment of the client. The second moment is the moment when the server determines that the first condition is met, that is, the moment when the server determines that the data download process of the client ends. Compared with the prior art, in which the server takes the moment when it writes all the data required by the client into the server's send buffer after finding the data required by the client based on the data download request as the end download moment of the client, the former is closer to the real end download moment of the client and can more accurately reflect the real end download moment of the client. Therefore, in Figure 5 In S505, the download time of the client calculated by the server based on the end download moment and the start download moment of the client is closer to the real download time of the client and can more accurately reflect the real download time of the client compared with the download time of the client calculated by the server in the prior art.

[0124] In addition, in Figure 5 In S506, the server calculates the amount of data successfully sent to the client in the first data as the download data amount of the client based on the sequence number carried in the ACK packet returned by the client for the last received data packet before determining that the first condition is met, and the sequence number start_seq of the first data packet recorded in S502. Compared with the prior art, in which the server takes the total data amount of the data required by the client found based on the data download request as the download data amount of the client, the former is closer to the real download data amount of the client and can more accurately reflect the real download data amount of the client.

[0125] In summary, it can be understood that since the download time and download data volume of the client obtained in this application are closer to the actual download time and actual download data volume of the client, and can more accurately reflect the actual download time and actual download data volume of the client. Therefore, the download rate of the client calculated based on the download time and download data volume of the client obtained in this application is closer to the actual download rate of the client and can more accurately reflect the actual download rate of the client compared with the download rate of the client calculated by the prior art.

[0126] Possible implementation method 2, see Figure 6 the process shown below:

[0127] S601: When the server receives a data download request sent by the client, record the first moment as the start download moment of the client.

[0128] It can be seen that S601 is the same as S501. Please refer to the relevant description of S501.

[0129] S602: When the server sends the first data to the client based on the data download request, record the data volume of the first data.

[0130] Here, the data volume of the first data is in bytes, such as 10,000 bytes.

[0131] S603: The server determines whether the first condition is satisfied. When it is determined that the first condition is satisfied, execute S604 - S606. When it is determined that the first condition is not satisfied, execute S603 again.

[0132] It can be seen that S603 is the same as S503. Please refer to the relevant description of S503.

[0133] S604: The server records the second moment as the end download moment of the client, and the second moment is the moment when the server determines that the first condition is satisfied.

[0134] It can be seen that S604 is the same as S504. Please refer to the relevant description of S504.

[0135] S605: The server calculates the consumed sending time as the download time of the client based on the end download moment of the client and the start download moment of the client.

[0136] It can be seen that S605 is the same as S505. Please refer to the relevant description of S505.

[0137] S606: When the server determines that the first condition is satisfied, calculate the data volume of the first data that has been successfully sent to the client based on the remaining data volume in the server's sending buffer and the data volume of the first data recorded in S602.

[0138] The server can calculate the amount of data in the first data that has been successfully sent to the client through the following calculation method (1):

[0139] Calculation method (1): The amount of data in the first data that has been successfully sent to the client = the amount of data of the first data recorded in S502 - the remaining data in the server's send buffer when the server determines that the first condition is met.

[0140] Optionally, S506 can also be: During the process of the server sending each data packet to the client, record the amount of data of the data packets that have been sent. When the server determines that the first condition is met, calculate the amount of data in the first data that has been successfully sent to the client through the following calculation method (2):

[0141] Calculation method (2): The amount of data of the data packets in the first data that has been successfully sent to the client = the amount of data of the data packets that have been sent recorded by the server when the server determines that the first condition is met.

[0142] It should be understood that the above calculation methods for the amount of data in the first data that has been successfully sent to the client are only examples and should not be regarded as specific limitations.

[0143] In Figure 6 of S601, the server records the first moment as the start download moment of the client. The first moment is the moment when the server receives the data download request sent by the client, or the first moment is any moment between the moment when the server receives the data download request sent by the client and the moment when the server starts writing the first data into the server's send buffer based on the data download request. Compared with the prior art, when the server finds the data required by the client based on the data download request and then takes the moment when the server starts writing the data required by the client into the server's send buffer as the start download moment of the client, the former is closer to the true start download moment of the client (referring to the moment when the client sends the data download request to the server) and can more accurately reflect the true start download moment of the client. In addition, in Figure 6 of S604, the server records the second moment as the end download moment of the client. The second moment is the moment when the server determines that the first condition is met, that is, the moment when the server determines that the data download process of the client ends. Compared with the prior art, when the server finds the data required by the client based on the data download request and then takes the moment when the server writes all the data required by the client into the server's send buffer as the end download moment of the client, the former is closer to the true end download moment of the client and can more accurately reflect the true end download moment of the client. Therefore, in Figure 6In S605, the download time of the client calculated by the server based on the end download time of the client and the start download time of the client is closer to the true download time of the client and can more accurately reflect the true download time of the client than the download time of the client calculated by the server in the prior art.

[0144] In addition, in Figure 6 In S606, when the server determines that the first condition is met, it calculates the amount of data in the first data that has been successfully sent to the client based on the remaining data volume in the server's send buffer and the data volume of the first data recorded in S502, and uses it as the download data volume of the client. Compared with the prior art where the server uses the total data volume of the client's required data found based on the data download request as the download data volume of the client, the former is closer to the true download data volume of the client and can more accurately reflect the true download data volume of the client.

[0145] In summary, it can be understood that since the download time and download data volume of the client obtained in this application are closer to the true download time and true download data volume of the client and can more accurately reflect the true download time and true download data volume of the client, the download rate of the client calculated based on the download time and download data volume of the client obtained in this application is closer to the true download rate of the client and can more accurately reflect the true download rate of the client than the download rate of the client calculated in the prior art.

[0146] It should be understood that the above possible implementation manners 1 and 2 are only examples of the process of the server obtaining the amount of data in the first data that has been successfully sent to the client and the consumed sending time, and should not be regarded as specific limitations.

[0147] In a possible embodiment, the above download rate determination method may be implemented by the server using methods such as Berkeley Packet Filter (BPF) (such as Extended Berkeley Packet Filter (eBPF)).

[0148] Taking the server implementing the above possible implementation manner 1 to obtain the amount of data in the first data that has been successfully sent to the client and the consumed sending time as an example, a complete embodiment of the server implementing the above download rate determination method using the eBPF method is introduced in detail. Refer to Figure 7 , and this embodiment may include the following steps:

[0149] S701: An application program in the user space of the server receives a data download request sent by the client.

[0150] The application program in the user space of the server refers to the program code responsible for processing data search and sending services located in the user space of the server.

[0151] S702: The application program determines whether the domain name carried in the data download request exists among the multiple stored domain names. If it is determined to exist, S703 - S705 are executed; if it is determined not to exist, S711 is executed.

[0152] The multiple domain names correspond to multiple servers that provide data download services by the server, and the server needs to monitor the download rates of the clients accessing these servers.

[0153] S703: The application program records the first moment and the session identifier between the server and the client carried in the data download request into the shared memory (eBPF MAP).

[0154] The eBPF MAP (also known as the eBPF hash table) is a data structure in the eBPF method, located in the kernel space of the server, used to store data in the kernel space, and can store and retrieve data in the form of key - value pairs (key, value). For example, the server records {key: session identifier, value: start_time} into the eBPF MAP, where the value of start_time corresponding to value is the first moment.

[0155] The application program and the eBPF program in the kernel space of the server described below can achieve data sharing through the eBPF MAP.

[0156] S704: The application program writes multiple data packets included in the first data into the send buffer of the server based on the data download request, and records the sequence number start_seq of the first data packet and the sequence number end_seq of the last data packet into the eBPF MAP.

[0157] Taking the example where the server records {key: session identifier, value: start_time} into the eBPF MAP as described in S703, the server can add the sequence number start_seq of the first data packet and the sequence number end_seq of the last data packet to {key: session identifier, value: start_time} in the eBPF MAP. For example, after the addition is completed, the eBPF MAP stores {key: session identifier, value: start_time, start_seq, end_seq}.

[0158] S705: The eBPF program in the kernel space of the server monitors each packet of the interaction between the server and the client, and determines whether the first condition is met based on each packet. When it is determined that the first condition is met, S706 - S707 are executed. When it is determined that the first condition is not met, S705 is executed again.

[0159] The eBPF program can be written in a programming language (eBPF bytecode), and the eBPF program can access data structures in the kernel space of the server, such as accessing the eBPF MAP in the kernel space.

[0160] The process of the eBPF program determining whether the first condition is met can be as follows: The eBPF program monitors whether the session identifier carried in each packet of the interaction between the server and the client is the same as the session identifier recorded in the eBPF MAP. When it is determined that they are the same, it is determined that the packet belongs to the packets of the session to be monitored, and then it is determined whether the packet is the ACK packet of the last data packet, whether it is a FIN packet or a RESET packet, so as to determine whether the first condition is met.

[0161] The process of the eBPF program determining whether the packet is the ACK packet of the last data packet, whether it is a FIN packet or a RESET packet, so as to determine whether the first condition is met, is the same as the process described in S302 where the server determines whether the packet sent or received is the ACK packet of the last data packet, whether it is a FIN packet or a RESET packet, so as to determine whether the first condition is met. Please refer to the relevant content of S302. For the sake of simplicity of the specification, it will not be elaborated further.

[0162] S706: The eBPF program calculates the consumed transmission time based on the second moment and the first moment in the eBPF MAP, and records it in the eBPF MAP.

[0163] S707: The eBPF program calculates the amount of data successfully sent to the client in the first data based on the sequence number carried in the ACK packet returned by the client based on the received data packet for the last time before it is determined that the first condition is met, and the sequence number start_seq of the first data packet in the eBPF MAP, and records it in the eBPF MAP.

[0164] S708: The application program accesses the eBPF MAP to obtain the amount of data successfully sent to the client and the consumed transmission time stored in the eBPF MAP.

[0165] S709: The application program calculates the download rate of the client based on the amount of data successfully sent to the client and the consumed transmission time.

[0166] S710: The application sends the download rate of the client to the client.

[0167] S711: The application sends the first data to the client based on the data download request.

[0168] For the sake of simplicity in description, Figure 7 the embodiments do not expand the descriptions of the definitions of data download requests, domain names, session identifiers, first data, first moments, first conditions, second moments, etc. For details, please refer to Figure 3 and Figure 5 the descriptions of the definitions of relevant data download requests, domain names, session identifiers, first data, first moments, first conditions, second moments, etc. Figure 7 The embodiments also do not introduce the method of calculating the download rate of the client based on the amount of data successfully sent to the client and the transmission time consumed, and the way of calculating the download rate of the client. For details, please refer to Figure 3 the relevant description of S303 in

[0169] The server uses the eBPF method to determine whether the first condition is met. Since the eBPF method belongs to the kernel-level technology and each message exchanged between the server and the client is stored in the kernel space of the server, the server can run the eBPF program in the kernel space to directly monitor each message exchanged between the server and the client stored in the kernel space, and determine whether the first condition is met. For example, it can be determined whether the message received by the server is the ACK message of the last data packet sent by the client, or the FIN message or RESET message sent by the client, without copying each message exchanged between the server and the client stored in the kernel space to the user space and having the application program in the user space determine whether the first condition is met, which can improve the monitoring efficiency and thus improve the acquisition efficiency of the download rate of the client.

[0170] It should be noted that the above embodiments of the download rate determination method are all described by taking the server sending data to the client one by one in ascending order of the sequence numbers of multiple data packets as an example. The inventive concept provided by this application can also be applied to the scenario where the server sends data to the client one by one in descending order of the sequence numbers of multiple data packets. The specific implementation process is similar to the above embodiments of the download rate determination method. For the sake of simplicity of the specification, it will not be elaborated further.

[0171] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of this application.

[0172] The method for determining the download rate provided by the embodiments of the present application is elaborated in detail above. Based on the same inventive concept, the download rate determination device and the computing device cluster provided by the embodiments of the present application will be introduced below.

[0173] The download rate determination device can be applied to the server to implement the function of calculating the download rate of the client. The download rate determination device can be divided into one or more unit modules. Exemplarily, refer to Figure 8 , Figure 8 which is a schematic structural diagram of a download rate determination device provided by the embodiments of the present application. As shown in Figure 8 , it includes: a receiving module 810, a processing module 820, and a sending module 830. The functions of each module of the download rate determination device 800 will be introduced exemplarily below.

[0174] The receiving module 810 is configured to receive a data download request sent by the client.

[0175] The sending module 830 is configured to send the first data to the client based on the data download request.

[0176] The processing module 820 is configured to, when determining that the first condition is satisfied, obtain the amount of data successfully sent to the client in the first data and the time consumed for sending, where the first condition is that the server determines that it has received the ACK packet of the last packet among the multiple packets included in the first data sent by the client, or the first condition is that the server sends a connection close request or a reset request to the client, or the first condition is that the server receives a connection close request or a reset request sent by the client, and the last packet is the packet with the largest sequence number among the multiple packets.

[0177] The processing module 820 is further configured to calculate the download rate of the client based on the amount of data successfully sent to the client in the first data and the sending time.

[0178] In some possible embodiments, the sending time is the time interval between the moment when the server determines that the first condition is satisfied and the moment when the server receives the data download request.

[0179] In some possible embodiments, the sending time is the time interval between the moment when the server determines that the first condition is satisfied and the first moment, where the first moment is any moment between the moment when the server receives the data download request and the moment when the server starts to write the first data into the sending buffer of the server.

[0180] In some possible embodiments, the amount of data successfully sent to the client in the first data is the number of packets successfully sent to the client among the multiple packets.

[0181] In some possible embodiments, the processing module 820 can specifically obtain the amount of data successfully sent to the client in the first data in the following manner: Based on the sequence number carried in the first ACK packet and the sequence number of the first packet among the multiple packets, calculate the number of packets successfully sent to the client among the multiple packets, where the first ACK packet is the ACK packet returned by the client based on the received packets that the server received last before determining that the first condition is satisfied, and the first packet is the packet with the smallest sequence number among the multiple packets.

[0182] In some possible embodiments, the receiving module 810 is further configured to receive the ACK packet of the first packet returned by the client, and the first packet belongs to the multiple packets; the processing module 820 is further configured to determine that the ACK packet of the first packet received by the client is the ACK packet of the last packet among the multiple packets included in the first data when determining that the sequence number carried in the ACK packet of the first packet is greater than the sequence number of the last packet among the multiple packets.

[0183] In some possible embodiments, the sending module 830 is further configured to send the download rate of the client to the client.

[0184] In some possible embodiments, the processing module 820 is configured to monitor each packet of the interaction between the server and the client by using the eBPF method and determine whether the first condition is satisfied based on each packet.

[0185] In some possible embodiments, the first data is video, audio, document, table, or picture.

[0186] Regarding Figure 8 The shown sending buffer and the eBPF MAP have been introduced in detail in the above embodiments of the download rate determination method. Please refer to the relevant introduction above.

[0187] In specific implementation, the receiving module 810, the processing module 820, and the sending module 830 can all be implemented by software or by hardware. Exemplarily, next, taking the processing module 820 as an example, the implementation manner of the processing module 820 is introduced. Similarly, the implementation manners of the receiving module 810 and the sending module 830 can refer to the implementation manner of the processing module 820.

[0188] As an example of a software functional unit, the processing module 820 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above computing instance may be one or more. For example, the processing module 820 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers for running the code may be distributed in the same availability zone (AZ) or in different AZs, and each AZ includes one data center or multiple geographically proximate data centers. Usually, one region may include multiple AZs.

[0189] Similarly, the multiple hosts / virtual machines / containers for running the code may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, one VPC is set within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, a communication gateway needs to be set in each VPC, and the interconnection between VPCs is achieved through the communication gateway.

[0190] As an example of a hardware functional unit, the processing module 820 may include at least one computing device, such as a server, etc. Alternatively, the processing module 820 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The above PLD may be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0191] When the processing module 820 includes multiple computing devices, the multiple computing devices included may be distributed in the same region or in different regions. The multiple computing devices included in the processing module 820 may be distributed in the same availability zone (AZ) or in different AZs. Similarly, the multiple computing devices included in the processing module 820 may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Among them, the multiple computing devices may be any combination of computing devices such as servers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), and generic array logic (GALs).

[0192] It should be noted that in other embodiments, the processing module 820 may be used to execute any step in the above download rate determination method, the receiving module 810 may be used to execute any step in the above download rate determination method, and the sending module 830 may be used to execute any step in the above download rate determination method. The steps to be implemented by the receiving module 810, the processing module 820, and the sending module 830 can be specified as needed. By the receiving module 810, the processing module 820, and the sending module 830, different steps in the above download rate determination method are respectively implemented to realize all functions of the download rate determination device 800.

[0193] It should be understood that the functions of the above-described respective modules are only the functions that the download rate determination device 800 may have in some embodiments of the present application. The present application does not limit the functions of the respective modules.

[0194] It should also be understood that Figure 8 is an exemplary partitioning method. The download rate determination device 800 may also include more or fewer modules. Specifically, the partitioning method of the modules in the download rate determination device 800 can be flexibly adjusted based on the actual service scenario. The present application does not make specific limitations. For example, the processing module 820 is split into a judgment module and a calculation module. Among them, the judgment module is used to judge whether the first condition is satisfied, and the calculation module is used to obtain the amount of data successfully sent to the client and the time consumed for sending in the first data when the judgment module determines that the first condition is satisfied, and calculate the download rate of the client based on the amount of data successfully sent to the client and the time consumed for sending in the first data.

[0195] Specifically, the specific implementation of the above download rate determination device 800 performing various operations can refer to the description in the relevant content of the above download rate determination method embodiment. For the sake of simplicity of the specification, it will not be elaborated here.

[0196] An embodiment of the present application further provides a computing device 900. The computing device 900 can be deployed Figure 8 with the download rate determination device 800 shown, or can be the aforementioned server to implement the above download rate determination method.

[0197] As shown Figure 9 in FIG. 448, the computing device 900 includes: a processor 910, a memory 920, and a communication interface 930. Among them, the processor 910, the memory 920, and the communication interface 930 can be interconnected with each other through a bus 940.

[0198] The processor 910 can read the program code (including instructions) stored in the memory 920 and execute the program code stored in the memory 920, so that the computing device 900 executes the above-mentioned download rate determination method, or enables the computing device 900 to deploy the download rate determination device 800.

[0199] The processor 910 can have various specific implementation forms. For example, it can be a central processing unit (abbreviated as CPU), or a combination of a CPU and a hardware chip. The above-mentioned hardware chip can be an ASIC, a PLD, or a combination thereof. The above-mentioned PLD can be a CPLD, an FPGA, a GAL, or any combination thereof. The processor 910 executes various types of digital storage instructions, such as software or firmware programs stored in the memory 920, which can enable the computing device 900 to provide a wide variety of services.

[0200] In a specific implementation, as an embodiment, the processor 910 includes one or more CPUs.

[0201] In a specific implementation, as an embodiment, the computing device 900 also includes multiple processors. Each of these processors can be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). Here, the processor refers to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0202] The memory 920 is used to store program code and is controlled by the processor 910 to execute the above-mentioned download rate determination method. The program code can include one or more software modules, and these one or more software modules can be Figure 8 the software modules provided in the embodiments, such as the receiving module 810, the processing module 820, and the sending module 830.

[0203] The memory 920 may include volatile memory, such as random access memory (RAM); the memory 920 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); the memory 920 may further include a combination of the above types.

[0204] The communication interface 930 may be a wired interface (such as an Ethernet interface, a fiber optic interface, other types of interfaces (e.g., InfiniBand interface)) or a wireless interface (such as a cellular network interface or using a wireless local area network interface) for communicating with other computing devices or apparatuses. The communication interface 930 may adopt a protocol family over the Transmission Control Protocol / Internet Protocol (TCP / IP), such as, for example, the Remote Function Call (RFC) protocol, the Simple Object Access Protocol (SOAP) protocol, the Simple Network Management Protocol (SNMP) protocol, the Common Object Request Broker Architecture (CORBA) protocol, and distributed protocols, etc.

[0205] The bus 940 may be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL), a Cache Coherent Interconnect for Accelerators (CCIX), etc. The bus 940 may be divided into an address bus, a data bus, a control bus, etc.

[0206] In addition to the data bus, the bus 940 may further include a power bus, a control bus, a status signal bus, etc. However, for the sake of clear illustration, all kinds of buses are labeled as the bus 940 in the figure. For the sake of easy representation, Figure 9 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0207] The above-mentioned computing device 900 is used to execute the above-mentioned download rate determination method, and the specific implementation process can be seen in the above-mentioned method embodiments and will not be elaborated here.

[0208] It should be understood that the computing device 900 is only an example provided in the embodiments of the present application, and, the computing device 900 may have more or fewer components than Figure 9 the components shown, two or more components may be combined, or different configurations of components may be implemented. For the content not shown or described in the embodiments of the present application, reference may be made to the relevant descriptions in the foregoing Figures 1 - 8 embodiments and will not be elaborated here.

[0209] The present application further provides a computing device cluster 1000, and the computing device cluster 1000 may deploy Figure 8 the download rate determination device 800 shown, or may be the aforementioned server to implement the above-mentioned download rate determination method.

[0210] As Figure 10 shown, the computing device cluster 1000 includes at least one computing device 900. In the memory 920 of one or more computing devices 900 in the computing device cluster, the same instructions for executing the above-mentioned download rate determination method may be stored. The computing device 900 may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device 900 may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0211] In some possible implementation manners, the memory 920 of one or more computing devices 900 in the computing device cluster 1000 may also separately store instructions for executing the above-mentioned download rate determination method. In other words, a combination of one or more computing devices 900 may jointly execute the instructions for executing the above-mentioned download rate determination method.

[0212] It should be noted that the memories 920 in different computing devices 900 in the computing device cluster 1000 may store different instructions, respectively used to execute partial functions of the download rate determination device 800. That is, the instructions stored in the memories 920 of different computing devices 900 may implement the functions of one or more modules among the receiving module 810, the processing module 820, and the sending module 830.

[0213] In some possible implementations, one or more computing devices 900 in the computing device cluster 1000 can be connected via a network. Among them, the network can be a wide area network or a local area network, etc. Figure 11 A possible implementation is shown, as Figure 11 shown, there is a connection between two computing devices 900A and 900B via a network. Specifically, it is connected to the network through the communication interfaces in each computing device. In this type of possible implementation, the memory 920 in the computing device 900A stores instructions for executing the functions of the receiving module 810 and the sending module 830. At the same time, the memory 920 in the computing device 900B stores instructions for executing the function of the processing module 820.

[0214] Figure 11 The connection method between the computing device clusters 1000 shown can be considered because the download rate determination method provided in the embodiments of the present application needs to calculate the download rates of a large number of clients. Therefore, it is considered to hand over the function implemented by the processing module 820 for implementing the download rate calculation function of the client to the computing device 900B for execution.

[0215] It should be understood that Figure 11 the functions of the computing device 900A shown can also be completed by multiple computing devices 900. Similarly, the functions of the computing device 900B can also be completed by multiple computing devices 900.

[0216] The present application also provides a computer program product containing instructions. This computer program product can be software or a program product containing instructions that can run on a computing device or be stored in any available medium. When the computer program product runs on at least one computing device, it causes at least one computing device to execute the above-mentioned download rate determination method.

[0217] The present application also provides a computer-readable storage medium. This computer-readable storage medium can be any available medium that a computing device can store or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a high-density digital video disc (DVD)), or a semiconductor medium (for example, a solid-state drive), etc. This computer-readable storage medium includes instructions that direct the computing device to execute the above-mentioned download rate determination method.

[0218] In the above embodiments, the descriptions of each embodiment have their own focuses. For parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0219] In the above embodiments, it can be implemented in whole or in part by software, hardware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that the computer can access or a data storage device such as a server or data center that includes one or more integrated available media. The available medium may be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium, etc.

[0220] As described above, the foregoing are only specific embodiments of the present application. Those skilled in the art of this technology, based on the specific embodiments provided by the present application, can conceive of variations or substitutions, which should all be covered within the protection scope of the present application.

Claims

1. A method for determining a download rate, characterized in that: Applied to a server in a data download system, the method comprises: The server receives a data download request sent by a client, and sends first data to the client based on the data download request; When it is determined that the first condition is met, the amount of data in the first data that is successfully sent to the client and the time consumed for sending the data are obtained, wherein the first condition is that the server determines that it has received an ACK message for the last data packet among multiple data packets included in the first data returned by the client, or the first condition is that the server sends a connection closing request or a reset request to the client, or the first condition is that the server receives a connection closing request or a reset request sent by the client, and the last data packet is the data packet with the largest sequence number among the multiple data packets; The download rate of the client is calculated based on the amount of data in the first data successfully sent to the client and the sending time.

2. The method according to claim 1, characterized in that The sending time is the time interval between the moment when the server determines that the first condition is satisfied and the moment when the server receives the data download request.

3. The method according to claim 1, characterized in that The sending time is the time interval between the moment when the server determines that the first condition is met and the first moment, and the first moment is any moment between the moment when the server receives the data download request and the moment when the server starts to write the first data into the sending buffer of the server.

4. The method according to any one of claims 1 to 3, characterized in that: The amount of data in the first data that is successfully sent to the client is the number of data packets in the multiple data packets that are successfully sent to the client.

5. The method according to claim 4, characterized in that The obtaining the amount of data in the first data successfully sent to the client includes: Based on the sequence number carried in the first ACK message and the sequence number of the first data packet among the multiple data packets, the number of data packets successfully sent to the client among the multiple data packets is calculated, wherein the first ACK message is the ACK message returned by the client based on the received data packet, which is the last time received by the server before determining that the first condition is met, and the first data packet is the data packet with the smallest sequence number among the multiple data packets.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: receiving an ACK message of a first data packet returned by the client, where the first data packet belongs to the multiple data packets; When it is determined that the sequence number carried by the ACK message of the first data packet is greater than the sequence number of the last data packet among the multiple data packets, it is determined that the ACK message of the last data packet among the multiple data packets included in the first data returned by the client is received.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: The download rate of the client is sent to the client.

8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: An extended Berkeley packet filter (eBPF) method is used to monitor each message exchanged between the server and the client, and whether the first condition is met is determined based on each message.

9. The method according to any one of claims 1 to 8, characterized in that: The first data is video, audio, document, table or picture.

10. A download rate determination device, characterized in that: Applied to a server in a data download system, the device comprises: A receiving module, used for receiving a data download request sent by a client; A sending module, configured to send first data to the client based on the data download request; a processing module, configured to obtain, when determining that a first condition is satisfied, the amount of data in the first data that is successfully sent to the client and the time consumed for sending the data, wherein the first condition is that the server determines that it has received an ACK message of the last data packet among multiple data packets included in the first data returned by the client, or the first condition is that the server sends a connection closing request or a reset request to the client, or the first condition is that the server receives a connection closing request or a reset request sent by the client, and the last data packet is the data packet with the largest sequence number among the multiple data packets; The processing module is further configured to calculate a download rate of the client based on the amount of data in the first data successfully sent to the client and the sending time.

11. The device according to claim 10, characterized in that The sending time is the time interval between the moment when the server determines that the first condition is satisfied and the moment when the server receives the data download request.

12. The device according to claim 10, characterized in that The sending time is the time interval between the moment when the server determines that the first condition is met and the first moment, and the first moment is any moment between the moment when the server receives the data download request and the moment when the server starts to write the first data into the sending buffer of the server.

13. The device according to any one of claims 10 to 12, characterized in that The amount of data in the first data that is successfully sent to the client is the number of data packets in the multiple data packets that are successfully sent to the client.

14. The device according to claim 13, characterized in that The processing module is specifically used for: Based on the sequence number carried in the first ACK message and the sequence number of the first data packet among the multiple data packets, the number of data packets successfully sent to the client among the multiple data packets is calculated, wherein the first ACK message is the ACK message returned by the client based on the received data packet, which is the last time received by the server before determining that the first condition is met, and the first data packet is the data packet with the smallest sequence number among the multiple data packets.

15. The device according to any one of claims 10 to 14, characterized in that The receiving module is further configured to receive an ACK message of a first data packet returned by the client, where the first data packet belongs to the multiple data packets; The processing module is also used to determine that an ACK message of the last data packet among the multiple data packets included in the first data returned by the client is received when it is determined that the sequence number carried by the ACK message of the first data packet is greater than the sequence number of the last data packet among the multiple data packets.

16. The device according to any one of claims 10 to 15, characterized in that The sending module is further used to send the download rate of the client to the client.

17. The device according to any one of claims 10 to 16, characterized in that The processing module is used to monitor each message exchanged between the server and the client using the eBPF method, and determine whether the first condition is met based on each message.

18. The device according to any one of claims 10 to 17, characterized in that The first data is video, audio, document, table or picture.

19. A computing device cluster, characterized in that: It includes at least one computing device, each of which includes a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 9.

20. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 9.