A broadband speed measurement method based on TCP protocol

Abstract

The present application relates to the technical field of broadband speed measurement, and discloses a broadband speed measurement method based on a TCP protocol, which solves the problem that the existing broadband speed measurement method cannot meet the demand of an operator for local precise speed measurement of a user end and cannot accurately return a broadband speed measurement rate under different speed measurement servers and network environments.The present application first matches and counts speed measurement target messages through a kernel hook function, and excludes non-speed measurement data interference; then dynamically adjusts the ACK reply frequency and the TCP congestion window size according to the real-time sending rate of the speed measurement server, quickly adapts the network state to occupy the available bandwidth; finally, the IQR algorithm is used to eliminate outliers in the speed measurement result and calculate the effective average value, and finally the speed measurement result that conforms to the real bearing capacity of the broadband line is output, which meets the demand of the operator for local precise speed measurement of the user end.

Description

Technical Field

[0001] This invention relates to the field of broadband speed measurement technology, and specifically to a broadband speed measurement method based on the TCP protocol. Background Technology

[0002] With the rapid development of fiber optic communication technology, home and business users have an increasingly urgent need for accurate assessment and actual broadband speed performance. Currently, the mainstream broadband speed testing methods mainly rely on user terminals (such as computers and mobile phones) accessing third-party speed test websites through browsers or using dedicated speed test apps to complete the speed test. However, these methods have significant drawbacks and cannot meet the operators' needs for accurate monitoring of the actual bandwidth quality at the user's end, as detailed below:

[0003] (1) Speed ​​measurement results are easily affected by the performance and configuration of terminal equipment:

[0004] The CPU processing power, memory usage, network adapter model, and background programs running on the user terminal (such as download software and video streaming media) all consume network resources or hardware computing power, causing speed test results to deviate from the actual broadband speed. For example, when the network card's transmission rate limit of an older terminal is lower than the broadband contract rate, the speed test results will be limited by the terminal's hardware bottleneck; when background programs consume bandwidth, it will further lower the speed test value, failing to reflect the actual carrying capacity of the broadband line itself.

[0005] (2) The impact of speed test server node selection and network path fluctuations on accuracy:

[0006] Third-party speed test websites often have unevenly distributed server nodes. User terminals typically automatically match the nearest node, but if that node is overloaded (e.g., during peak hours when many users are simultaneously testing), or if there is congestion or excessive routing hops in the network path between the user and the server, it can lead to increased TCP packet transmission latency and packet loss rate, ultimately resulting in a lower-than-expected speed test result. Furthermore, differences in server performance across different speed test platforms (such as bandwidth limits and concurrent processing capabilities) can also cause inconsistencies in the speed data obtained by the same user on different platforms, lacking a unified and reliable evaluation standard.

[0007] (3) Traditional TCP protocol speed testing relies on fixed parameters and has weak adaptability to complex network environments:

[0008] Existing TCP-based speed measurement methods mostly use the TCP protocol stack built into the operating system kernel. Their congestion window adjustment follows the standard TCP congestion control algorithm, which requires a slow update process (additive growth) to approximate the available network bandwidth, resulting in long speed measurement times. Furthermore, the ACK reply frequency is mostly fixed and cannot be dynamically adjusted according to the sending rate of the speed measurement server and the real-time status of the network link. In complex environments such as weak networks and high packet loss, the slow window sliding can lead to insufficient rate measurement or excessively high ACK frequency, causing network congestion and further reducing the accuracy of speed measurement.

[0009] Furthermore, existing broadband speed test solutions lack local monitoring capabilities. Current speed tests all rely on users initiating them, making it difficult for operators to obtain real-time speed data from the user's optical modem (the core terminal for broadband access). This makes it impossible to promptly detect speed issues caused by factors such as broadband line attenuation or abnormal optical modem configuration. Investigating slow speeds reported by users requires dispatching personnel for on-site testing, which not only increases maintenance costs but also leads to delays in fault location.

[0010] In summary, existing broadband speed testing methods are insufficient for accurate speed testing in complex network environments, cannot meet operators' needs for refined broadband quality management, and cannot provide users with a true and reliable basis for speed assessment. Summary of the Invention

[0011] The technical problem to be solved by this invention is to provide a broadband speed measurement method based on the TCP protocol, which solves the problem that existing broadband speed measurement methods are difficult to meet the operators' requirements for accurate local speed measurement on the user end and cannot accurately return the broadband speed measurement rate under different speed measurement servers and network environments.

[0012] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows:

[0013] A broadband speed test method based on the TCP protocol, used for local speed testing on the user's optical modem, includes:

[0014] The application layer of the optical modem establishes a socket connection based on the address specified by the speed test server and sends an HTTP GET request to the speed test server to trigger the download of the specified speed test file;

[0015] The optical modem receives a response message from the speed test server containing the Content-Length of the speed test file, and passes the socket information and the speed test file size information to the kernel TCP protocol processing driver. At the same time, the socket information is stored in a tuple linked list.

[0016] The optical modem starts a kernel hook function, which analyzes the received TCP packets and matches the socket information in the tuple list to filter out the target packets for speed testing. The length of the successfully matched target packets is added to the total received data variable. When the value of the total received data variable is greater than Content-Length, the download of the speed test file is terminated.

[0017] During TCP packet transmission, the ACK reply frequency and TCP congestion window size are dynamically adjusted according to the real-time sending rate of the speed test server. At the same time, a timer with a timeout of 1 second is started. If the download timeout period has not been reached when the timer is triggered, the current real-time speed test rate is recorded in the speed test result array, the maximum rate value in the array is updated, and the timer is restarted.

[0018] After the download of the speed test file is terminated, the IQR (interquartile range) algorithm is used to remove outliers from the real-time speed test rates in the speed test result array, and the average value of the remaining effective rate values ​​is calculated as the final broadband speed test result.

[0019] Furthermore, the dynamic adjustment of the ACK response frequency specifically includes:

[0020] In the initial stage of speed measurement, ACK messages are sent to the first n received speed measurement target messages at a frequency of sending one ACK reply for each received message;

[0021] When receiving the nth rate measurement target message, the actual TCP congestion window size is calculated using the formula: Congestion window size = (Current reception time - Last ACK message transmission time) × Theoretical transmission rate / n / 8;

[0022] Based on the calculated actual TCP congestion window size and TCP packet payload, the target ACK response frequency is determined according to the formula: ACK response frequency = congestion window size / TCP payload, and subsequent ACK packets are sent at this target ACK response frequency.

[0023] Furthermore, the method also includes: disabling the delayed acknowledgment mechanism in the early stage of speed testing, and immediately sending an ACK reply to each received speed test target message to quickly improve the sending rate of the speed test server.

[0024] Furthermore, the dynamic adjustment of the TCP congestion window size specifically includes:

[0025] By calling socket options provided by the Linux kernel or using the network congestion control algorithm module interface, the TCP congestion window size is set to a target value dynamically calculated based on the currently sampled real-time rate measurement rate. This target value is estimated by the ratio of the latest sampled real-time rate measurement rate to the current TCP congestion window size, thus skipping the slow additive growth phase of the standard TCP congestion control algorithm and quickly approaching and filling the available bandwidth of the current network path.

[0026] Furthermore, the step of analyzing the received TCP packets through the hook function and matching the socket information in the tuple list to filter out the target packets for speed testing specifically includes:

[0027] When the kernel receives a TCP packet, the hook function extracts the four-tuple information of the TCP packet, calculates the hash value, and compares it with the nodes in the tuple list. If the hash value matches, it is determined to be the target packet for speed testing, and the length accumulation operation is performed; if it does not match, the statistics are skipped, and it is processed according to the normal TCP process.

[0028] The beneficial effects of this invention are:

[0029] (1) Improve the accuracy of broadband speed measurement and avoid interference from multiple factors:

[0030] This invention uses kernel hook functions to accurately match target packets for speed testing, and only performs length accumulation statistics on TCP packets related to speed testing to avoid interference from non-speed testing data. At the same time, after the speed test is completed, the IQR algorithm is used to eliminate outliers in the rate per second, and then the average effective rate is calculated. This effectively eliminates speed test deviations caused by terminal background programs, instantaneous network fluctuations, etc. Compared with traditional speed test methods that rely on terminals or third-party servers, the results are closer to the actual carrying capacity of broadband lines.

[0031] (2) Dynamically adapt to complex network environments to ensure speed measurement efficiency and reliability:

[0032] During TCP packet transmission, this invention dynamically adjusts the ACK response frequency and TCP congestion window size based on the real-time sending rate of the speed test server. It quickly increases the sending rate by disabling delayed acknowledgments in the initial stage, and then calculates the optimal ACK response frequency based on the congestion window and TCP payload. At the same time, it skips the slow additive growth stage of standard TCP congestion control and quickly fills the available network bandwidth. This avoids the problem of insufficient rate measurement in weak network and high packet loss environments when using fixed-parameter speed tests, and also prevents network congestion caused by excessively high ACK frequencies, thus achieving efficient and stable speed testing in complex network environments.

[0033] (3) Meet the operator's local precise monitoring needs and reduce operation and maintenance costs:

[0034] The solution of this invention can be deployed on local access devices such as user optical modems. It does not require the user terminal to initiate speed tests. Operators can directly obtain the real local speed data of the user terminal, and promptly detect problems such as broadband line attenuation and abnormal equipment configuration. This avoids the lag in on-site investigation after traditional user complaints and reduces the manpower and time costs of operation and maintenance.

[0035] (4) The speed measurement process is highly controllable and the data statistics are accurate:

[0036] This invention achieves targeted filtering and precise control of the download process for speed test packets by passing socket information and the size (Content-Length) of the speed test file into the kernel and associating them with a tuple list. The download is automatically terminated when the cumulative received length exceeds the Content-Length. At the same time, the real-time rate is recorded and the maximum value is updated every 1 second to ensure the integrity and timeliness of the speed test data and provide a reliable data foundation for subsequent result analysis. Attached Figure Description

[0037] Figure 1 This is a flowchart of a broadband speed measurement method based on the TCP protocol in an embodiment of the present invention. Detailed Implementation

[0038] This invention aims to provide a broadband speed measurement method based on the TCP protocol, addressing the shortcomings of existing methods that fail to meet operators' demands for accurate local speed measurement at the user end and cannot accurately return broadband speed rates under different speed test servers and network environments. The core idea is to address the problems of existing broadband speed measurement methods being susceptible to terminal interference, strong server dependence, and insufficient accuracy due to fixed TCP parameters. This is achieved by incorporating precise packet filtering, dynamic parameter adjustment, and speed result error correction into the TCP protocol speed measurement process, enabling accurate broadband speed measurement in complex network environments. Specifically, firstly, kernel hook functions are used to match and statistically analyze target packets for speed measurement, eliminating interference from non-speed test data; secondly, based on the real-time sending rate of the speed test server, the ACK reply frequency and TCP congestion window size are dynamically adjusted to quickly adapt to network conditions and fully utilize available bandwidth; finally, the IQR algorithm is used to remove outliers in the speed test results and calculate the effective average value, ultimately outputting speed test results that closely reflect the actual carrying capacity of the broadband line, while simultaneously meeting operators' demands for accurate local speed measurement at the user end.

[0039] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0040] Taking the application of the present invention to a user's optical modem for local speed testing as an example, the implementation process of a broadband speed testing method based on the TCP protocol provided in this embodiment is as follows: Figure 1 It includes the following implementation process:

[0041] 1. Establish socket communication with the server:

[0042] In this step, the speed test application (application layer) built into the optical modem obtains the address of the speed test server specified by the operator, and completes the transmission connection initialization by establishing a TCP three-way handshake with the speed test server.

[0043] After the connection is established, the application layer constructs an HTTP GET request message, carries the specified speed test file path in the request header, and sends the request to the speed test server to trigger the speed test file download process.

[0044] After the application layer receives the HTTP response message returned by the speed test server (containing a Content-Length field that records the total number of bytes in the speed test file), it uses ioctl to pass two key pieces of information to the kernel TCP protocol processing driver. These two key pieces of information include: ① the socket connection's four-tuple information (source IP, source port, destination IP, destination port), stored in a tuple list maintained by the kernel, so that when filtering target speed test packets, the four-tuple can be used to quickly match whether the currently received TCP packet belongs to the current speed test connection; ② the Content-Length value, used to determine whether the download is complete.

[0045] 2. Receive and match speed measurement messages via hook functions:

[0046] In this step, the kernel TCP protocol processing driver of the optical modem automatically registers a hook function. The core function of this function is to intercept all TCP packets entering the kernel in real time and perform speed test connection matching.

[0047] When the kernel receives a TCP packet, the hook function extracts the packet's four-tuple information, calculates the hash value, and compares it with the nodes in the tuple list. If the hash value matches (i.e., the packet belongs to the current speed test connection), it is determined to be the target packet for the speed test, and the length accumulation operation is performed. If it does not match (such as other network connections being made simultaneously by the optical modem, such as packets from users browsing web pages), the statistics are skipped, and the packet is processed according to the normal TCP process.

[0048] The kernel maintains a global variable for total received data (initially 0). For a successfully matched speed test target packet, the hook function extracts the effective payload length of the TCP packet (i.e., the length excluding the TCP header and IP header) and adds it to the global variable for total received data.

[0049] After each accumulation, the hook function triggers the termination judgment logic: compare the current total received data length with the Content-Length. If the current total received data length > Content-Length, it is determined that the speed test file has been downloaded. Otherwise, it continues to receive messages.

[0050] Based on kernel hook functions, filtering can be completed early in the process of packets entering the protocol stack, and only rate test packets are counted, which significantly reduces system resource consumption.

[0051] III. Sending the reply message:

[0052] This step employs innovative methods of dynamically adjusting the ACK response frequency and dynamically optimizing the TCP congestion window size to solve the problems of poor adaptability and slow rate approximation in traditional fixed-parameter speed measurement. Details are as follows:

[0053] (1) Dynamically adjust the ACK reply frequency:

[0054] After the optical modem establishes socket communication with the server, the optical modem kernel automatically sets the ACK reply frequency to 1 (that is, it sends one ACK message immediately for every speed test target message received), and disables the default delayed acknowledgment mechanism of the Linux kernel.

[0055] Since the server needs to quickly perceive the available network bandwidth in the early stages of speed testing, delayed confirmation will cause the server to mistakenly believe that the packet has been lost, thereby reducing the sending rate. Therefore, setting the ACK reply frequency to 1 can allow the server to receive confirmation quickly and avoid excessively long speed testing time due to the initial low rate.

[0056] When the nth packet is received, the actual TCP congestion window size for these n packets is calculated. Here, n is a preset threshold for the number of packets to be counted, for example, 20. The actual TCP congestion window size is calculated as follows:

[0057] Actual TCP congestion window size = (current reception time - last ACK packet transmission time) × theoretical transmission rate / n / 8; where the current reception time and the last ACK packet transmission time are obtained through the kernel clock; the theoretical transmission rate is the subscribed rate reference value for this speed test, used to initially estimate the upper limit of the window; dividing by n is to average the transmission time of n packets, avoiding the impact of single packet delay fluctuations; dividing by 8 converts bits (bps) to bytes (B), consistent with the unit (byte) of the congestion window.

[0058] After calculating the actual TCP congestion window size, the kernel further calculates the target ACK response frequency:

[0059] Target ACK response frequency = congestion window size / TCP payload length;

[0060] When receiving subsequent speed test target messages, the kernel sends ACK messages according to the target ACK reply frequency, and no longer uses the initial frequency.

[0061] The reasoning behind the above-mentioned calculation method for the target ACK response frequency is as follows: Since the ACK response frequency directly affects the server's window sliding speed, an excessively high ACK response frequency will cause the server to frequently adjust its sending window, potentially leading to network congestion; while an excessively low frequency will cause the server window to slide slowly, failing to fully utilize the bandwidth. The congestion window directly reflects the maximum number of packets the current network can handle. Therefore, calculating the ACK response frequency based on the actual congestion window allows for a dynamic match between the response frequency and the network's carrying capacity, maximizing the data rate while avoiding congestion.

[0062] Every time the kernel receives n packets, it repeatedly executes the logic of congestion window calculation and adjusting the ACK frequency according to the congestion window to ensure that the ACK reply frequency always matches the current network's sending rate.

[0063] (2) Dynamic optimization of TCP congestion window size:

[0064] Traditional TCP congestion window growth follows a slow start pattern, requiring multiple iterations to approach the maximum bandwidth. This results in low initial speed measurements, affecting overall accuracy. This embodiment skips the slow growth phase by forcibly setting a target congestion window size: the congestion window size is set to a target value dynamically calculated based on the current sampling rate. This target value is estimated by the ratio of the latest sampled real-time speed measurement rate to the current TCP congestion window size. This bypasses the slow additive growth phase of the standard TCP congestion control algorithm, quickly approaching and filling the available bandwidth of the current network path.

[0065] IV. Calculation of velocity measurement rate per second:

[0066] When the speed test begins, the application layer creates a 1-second periodic timer, which triggers once every 1 second. At the same time, a download timeout is set to prevent the speed test process from being blocked due to excessive load on the speed test server or network interruption.

[0067] When the timer is triggered, if it is determined that the current download timeout has not exceeded the preset download timeout, the current speed measurement value is recorded in the speed measurement result array, and the recorded maximum speed value is updated. If the recorded maximum speed value is less than the current speed measurement value, the current speed measurement value is used as the new maximum speed value.

[0068] If the current download time exceeds the preset download timeout, the speed test will be forcibly terminated to avoid indefinite waiting due to server-side failure.

[0069] V. Speed ​​Measurement Results Statistics:

[0070] Because transient packet loss and retransmission may occur during speed testing, directly calculating the average of all 1-second speeds would lead to results that deviate from the actual bandwidth. To more accurately reflect the actual bandwidth speed, the speed test results are corrected after the test. For example, the statistically recorded rate per second is calculated using the IQR (interquartile range) algorithm to eliminate outliers before the average speed is calculated as the final result.

[0071] Although embodiments of the present invention have been described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the present invention, and all such changes and alterations shall not depart from the protection scope of the present invention.

Claims

1. A broadband speed measurement method based on the TCP protocol, used for local speed measurement on the user's optical modem, characterized in that, The method includes: The application layer of the optical modem establishes a socket connection based on the address specified by the speed test server, and sends an HTTP GET request to the speed test server to trigger the download of the specified speed test file; The optical modem receives a response message from the speed test server containing the Content-Length of the speed test file, and passes the socket information and the speed test file size information to the kernel TCP protocol processing driver. At the same time, the socket information is stored in a tuple linked list. The optical modem starts a kernel hook function, which analyzes the received TCP packets and matches the socket information in the tuple list to filter out the target packets for speed testing. The length of the successfully matched target packets is added to the total received data variable. When the value of the total received data variable is greater than Content-Length, the download of the speed test file is terminated. During TCP packet transmission, the ACK reply frequency and TCP congestion window size are dynamically adjusted according to the real-time sending rate of the speed test server. At the same time, a timer with a timeout of 1 second is started. If the download timeout period has not been reached when the timer is triggered, the current real-time speed test rate is recorded in the speed test result array, the maximum rate value in the array is updated, and the timer is restarted. After the download of the speed test file is terminated, the IQR algorithm is used to remove outliers from the real-time speed test rate in the speed test result array, and the average value of the remaining effective rate values ​​is calculated as the final broadband speed test result.

2. The broadband speed measurement method based on the TCP protocol as described in claim 1, characterized in that, The dynamic adjustment of the ACK response frequency specifically includes: In the initial stage of speed measurement, ACK messages are sent to the first n received speed measurement target messages at a frequency of sending one ACK reply for each received message; When receiving the nth rate measurement target message, the actual TCP congestion window size is calculated using the formula: Congestion window size = (Current reception time - Last ACK message transmission time) × Theoretical transmission rate / n / 8. Based on the calculated actual TCP congestion window size and TCP packet payload, the target ACK response frequency is determined according to the formula: ACK response frequency = congestion window size / TCP payload, and subsequent ACK packets are sent at this target ACK response frequency.

3. The broadband speed measurement method based on the TCP protocol as described in claim 1, characterized in that, The method also includes: disabling the delayed acknowledgment mechanism in the early stages of speed testing, and immediately sending an ACK reply to each received speed test target message.

4. The broadband speed measurement method based on the TCP protocol as described in claim 2, characterized in that, The dynamic adjustment of the TCP congestion window size specifically includes: The TCP congestion window size is set to a target value that is dynamically calculated based on the currently sampled real-time rate measurement rate by calling socket options provided by the Linux kernel or by using the network congestion control algorithm module interface; this target value is estimated by the ratio of the latest sampled real-time rate measurement rate to the current TCP congestion window size.

5. A broadband speed measurement method based on the TCP protocol as described in any one of claims 1-4, characterized in that, The process of analyzing received TCP packets using this hook function and matching socket information in a tuple list to filter out target packets for speed testing specifically includes: When the kernel receives a TCP packet, the hook function extracts the four-tuple information of the TCP packet, calculates the hash value, and compares it with the nodes in the tuple list. If the hash value matches, it is determined to be the target packet for speed testing, and the length accumulation operation is performed; if it does not match, the statistics are skipped, and it is processed according to the normal TCP process.

Images