Round-trip delay determination method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of Internet, and provides a round-trip delay determination method and device, electronic equipment and a storage medium, and the method comprises the steps: sequentially extracting feature value heads, receiving and transmitting packet flag bits, check codes and feature value tails corresponding to all sampling UDP messages in a game process; based on the eigenvalue head and the eigenvalue tail corresponding to each sampling UDP message, determining a game UDP message meeting an eigenvalue rule from all the sampling UDP messages; the characteristic value rule is used for representing a structured mode corresponding to a characteristic value field in a data part of the game UDP message; dividing all the game UDP messages into client-side packet sending and server-side packet returning based on packet receiving and sending flag bits or port pointing corresponding to the game UDP messages; and determining the optimized round-trip delay based on the check codes of the packet sent by the client and the packet returned by the server. According to the embodiment of the invention, the round-trip delay can be calculated and optimized without depending on cooperation or decryption of the data content by the server side.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method, apparatus, electronic device, and storage medium for determining round-trip time delay. Background Technology

[0002] In existing technologies, round-trip time is generally calculated using data packets. Specifically, during the game, multiple data packets are defined, and specific identifiers or features in the game are used to associate the data packets with events or states in the game. The round-trip time of the data packets is calculated by comparing the sending and receiving times of the data packets.

[0003] However, because game data packets use UDP (User Datagram Protocol) for data exchange, and UDP is a connectionless protocol with no built-in acknowledgment mechanism, and most of the data content is encrypted, it is impossible to extract important game information from the data packets. Existing technologies typically use PING to collect round-trip latency, but PING data transmitted via ICMP (Internet Control Message Protocol) is easily intercepted at the gateway and does not actually reach the server, thus failing to accurately reflect UDP round-trip latency. Furthermore, UDP PING testing requires server-side cooperation; without sending the correct data recognized by the server, the server will not respond. Therefore, existing methods have significant limitations. Summary of the Invention

[0004] This application provides a round-trip time delay determination method, apparatus, electronic device, and storage medium to address the shortcomings of existing technologies where round-trip time delay calculation requires server-side cooperation and has significant limitations.

[0005] In a first aspect, embodiments of this application provide a method for determining round-trip delay, comprising the following steps.

[0006] Extract the feature header, send / receive flags, checksum, and feature tail of each sampled UDP packet during the game process in sequence; Based on the feature value header and feature value tail corresponding to each of the sampled UDP packets, game UDP packets that satisfy the feature value pattern are determined from all sampled UDP packets; the feature value pattern is used to characterize the structured pattern corresponding to the feature value field in the data part of the game UDP packet; Based on the send / receive flags or port pointers corresponding to each game UDP packet, all game UDP packets are divided into client-sent packets and server-return packets. Based on the verification codes of the client's sent packets and the server's returned packets, the round-trip latency is optimized.

[0007] In one embodiment, determining the optimized round-trip latency based on the checksums of the client's sent packets and the server's returned packets includes: The checksums of the client packets and the server responses are matched to obtain multiple matching data pairs; each matching data pair includes client packets and server responses with the same checksum. Based on the corresponding packet receiving timestamp and packet sending timestamp of each of the matching data pairs, the single round-trip delay of each of the matching data pairs is determined; Based on the number of matched data pairs, the latency of all single round trips, and the perceived latency of the game screen during the same period as each single round trip, the optimal round trip latency is determined.

[0008] In one embodiment, the feature headers corresponding to all sampled UDP packets during the game are extracted, including: S11. Based on the initial feature value header of each sampled UDP packet, the preset game feature value header, and all sampled UDP packets, determine the first initial matching value corresponding to all sampled UDP packets; S12. Increment the length of the initial feature value header to obtain the first feature value header; S13. Based on the first feature value header, the preset game feature value header, and all sampled UDP packets, determine the first matching value corresponding to all sampled UDP packets; S14. When the first matching value is equal to the first initial matching value, the first feature value header is determined as the new initial feature value header. Steps S12 and S13 are repeated until the first matching value is equal to the first initial matching value. The final initial feature value header is then determined as the feature value header corresponding to all sampled UDP packets. S15. If the first matching value is not equal to the first initial matching value, the initial feature value header is determined as the feature value header corresponding to all sampled UDP packets.

[0009] In one embodiment, the packet sending and receiving flags include a packet sending flag and a packet receiving flag; Extract the send / receive flags corresponding to all sampled UDP packets during the game, including: Based on port pointing, all sampled UDP packets are divided into client packet sending packets and server response packets, and the length of the aforementioned feature value header bytes in the client packet sending packets and the server response packets is removed; Based on the first flag bit corresponding to different packet offsets in each client packet, the preset packet flag bit, all client packet packets and the first preset threshold, the packet matching result is determined; If the packet matching result is a successful packet matching, determine the packet sending flag, and determine the packet receiving matching result based on the position of the packet sending flag, the preset packet receiving flag, all server response packets and the first preset threshold. If the packet matching result is a successful packet matching, then the packet receiving flag is determined.

[0010] In one embodiment, determining the packet matching result based on the first flag bit corresponding to different packet offsets in each of the client packet messages, the preset packet flag bit, all client packet messages, and the first preset threshold includes: Based on the first flag bit corresponding to the first packet offset in each client packet, the preset packet flag bit, and all client packet packets, determine the second initial matching value corresponding to all client packet packets; If the second initial matching value is less than the first preset threshold, the first packet offset is incremented to obtain the second packet offset; the second flag corresponding to the second packet offset is set as the new first flag, and the step of determining the second initial matching value is repeated until the second packet offset is greater than the length of each client packet message, and the packet matching result is determined to be a packet matching failure. If the second initial matching value is greater than or equal to the first preset threshold, the packet matching result is determined to be a successful packet matching.

[0011] In one embodiment, determining the packet matching result based on the position of the sending flag, the preset receiving flag, all server response packets, and the first preset threshold includes: Determine the third flag bit in each of the server-side response packets that is in the same position as the packet sending flag bit; Based on each of the third flag bits, the preset packet receiving flag bits, and all server response packets, determine the third initial matching value corresponding to the server response packet; If the third initial matching value is greater than the first preset threshold, the packet receiving matching result is determined to be a successful packet receiving match; If the third initial matching value is less than or equal to the first preset threshold, the packet receiving matching result is determined to be a packet receiving matching failure.

[0012] In one embodiment, the checksums corresponding to all sampled UDP packets during the game are extracted, including: Based on the length of the feature header and the position of the send / receive flag, determine the initial offset corresponding to the server's response packet and the client's sent packet, respectively. The initial packet checksum corresponding to the initial offset in each of the server-side response packets is matched with the initial packet checksum corresponding to the initial offset in each of the client-side packet packets to obtain the checksum matching result. If the verification matching result is that all initial return packet verification codes match all initial sending packet verification codes one by one, then each initial return packet verification code is determined as the verification code corresponding to each server-side return packet message, and each initial sending packet verification code is determined as the verification code corresponding to each client-side sending packet message. If the verification matching result shows that at least one pair of initial return packet checksums and initial send packet checksums do not match, the initial offset is incremented to obtain an incrementing offset, and the step of determining the verification matching result is repeated until the verification matching result shows that all initial return packet checksums match all initial send packet checksums one by one. The final initial return packet checksums are then determined as the checksums corresponding to the server-side return packet messages, and the initial send packet checksums are determined as the checksums corresponding to the client-side send packet messages.

[0013] In one embodiment, the feature tails corresponding to all sampled UDP packets during the game are extracted, including: Based on the length of the feature header, the position of the send / receive packet flag, and the position of the checksum, the first initial feature tail corresponding to the initial tail offset in each sampled UDP packet is determined; Based on the first initial feature value tail of each sampled UDP packet, the preset game feature value tail, and all sampled UDP packets, determine the fourth initial matching value corresponding to all sampled UDP packets. Based on the fourth initial matching value and the second preset threshold, the starting offset corresponding to the tail of the feature value is determined; Based on the initial length and the starting offset, determine the second initial feature value tail corresponding to each sampled UDP packet; Based on the second initial feature value tail corresponding to each of the sampled UDP packets, the preset game feature value tail, all sampled UDP packets, and the second preset threshold, the fifth initial matching value corresponding to all sampled UDP packets is determined; The feature value tail is determined based on the fifth initial matching value, the second preset threshold, and the starting offset.

[0014] In one embodiment, determining the starting offset corresponding to the feature value tail based on the fourth initial matching value and the second preset threshold includes: When the fourth initial matching value is equal to the second preset threshold, the initial tail offset is determined as the starting offset corresponding to the feature value tail; If the fourth initial matching value is less than the second preset threshold, the initial tail offset is incremented to obtain a first tail offset. The first feature value tail corresponding to the first tail offset is determined as the new first initial feature value tail. The first tail offset is determined as the new initial tail offset, and the step of determining the fourth initial matching value is repeated until the fourth initial matching value is equal to the second preset threshold. Then, the final initial tail offset is determined as the starting offset corresponding to the feature value tail.

[0015] In one embodiment, determining the feature value tail based on the fifth initial matching value, the second preset threshold, and the starting offset includes: If the fifth initial matching value is not equal to the second preset threshold, the second initial feature value tail is determined as the feature value tail; If the fifth initial matching value is equal to the second preset threshold, the initial length is incremented to obtain a first length. The first length is determined as the new initial length, and the second feature value tail is determined as the new second initial feature value tail. The step of determining the fifth initial matching value is repeated until the fifth initial matching value is not equal to the second preset threshold. Then, the final second initial feature value tail is determined as the feature value tail. The second feature value tail is determined based on the first length and the starting offset.

[0016] In one embodiment, the method further includes: Game test IP data with round-trip latency exceeding the latency quality threshold will be identified as poor-quality IPs. Path tracing is performed on the poor-quality IPs to determine the IP analysis data corresponding to them.

[0017] Secondly, embodiments of this application provide a round-trip delay determination device, including the following modules.

[0018] The extraction module is used to sequentially extract the feature header, send / receive flags, checksum, and feature tail of each sampled UDP packet during the game process; The first determining module is used to determine game UDP packets that satisfy the feature value pattern from all sampled UDP packets based on the feature value header and feature value tail corresponding to each of the sampled UDP packets; the feature value pattern is used to characterize the structured pattern corresponding to the feature value field in the data part of the game UDP packet; The classification module is used to classify all game UDP packets into client-sent packets and server-return packets based on the send / receive flags or port pointers corresponding to each game UDP packet. The second determining module is used to determine the optimized round-trip latency based on the verification codes of the client's sent packets and the server's returned packets.

[0019] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the round-trip delay determination methods described above.

[0020] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the round-trip delay determination method as described above.

[0021] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the round-trip delay determination method as described above.

[0022] The round-trip time (RTT) determination method, apparatus, electronic device, and storage medium provided in this application sequentially extract the feature value header, send / receive flags, checksum, and feature value tail of each sampled UDP packet during the game process. Based on the feature value header and tail of each sampled UDP packet, game UDP packets that satisfy the feature value pattern corresponding to the structured pattern of the feature value fields in the data part of the game UDP packet are selected from all sampled UDP packets. Based on the send / receive flags or port pointers of each game UDP packet, all game UDP packets are divided into client packets and server responses. Based on the checksums of the client packets and server responses, the optimized RTT is determined. In this application embodiment, by independently analyzing the feature fields of UDP packets, game UDP packets that satisfy the feature value pattern are identified from out-of-order sampled UDP packets. The optimized RTT is calculated without relying on server cooperation or data decryption, solving the problem of inaccurate strategy for game UDP packet RTT due to gateway interception, data encryption, or server non-response. This effectively improves the reliability of RTT determination, thereby improving game network quality and user experience. Attached Figure Description

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

[0024] Figure 1 This is a flowchart illustrating the round-trip delay determination method provided in the embodiments of this application.

[0025] Figure 2 This is a schematic diagram of the structure of the sampled UDP packet provided in the embodiments of this application.

[0026] Figure 3 This is a schematic diagram of the structure of the feature values ​​of the data portion in the sampled UDP packet provided in the embodiments of this application.

[0027] Figure 4 This is a schematic diagram illustrating an example of feature value header extraction provided in this application embodiment.

[0028] Figure 5 This is a schematic diagram illustrating an example of extracting the packet sending flag provided in an embodiment of this application.

[0029] Figure 6 This is a comparison trend chart of perceived latency and single round-trip latency provided in the embodiments of this application.

[0030] Figure 7 This is a comparison trend chart of single round-trip time delay jitter and perceived time delay jitter provided in the embodiments of this application.

[0031] Figure 8 This is a comparison trend chart of optimized round-trip latency and perceived latency provided in the embodiments of this application.

[0032] Figure 9 This is a schematic diagram of the round-trip delay determination device provided in the embodiments of this application.

[0033] Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] To address the limitation of existing technologies that require server-side cooperation for round-trip time calculation, this application provides a method for determining round-trip time. Figure 1 This is a flowchart illustrating the round-trip delay determination method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes steps 110 to 140.

[0036] Step 110: Extract the feature header, send / receive flag, checksum, and feature tail of each sampled UDP packet during the game process.

[0037] It should be noted that before executing step 110, all sampled UDP packets were accurately extracted from the data packets in the game by associating the game process with the IP (Internet Protocol) port.

[0038] Specifically, after acquiring all sampled UDP packets, for each sampled UDP packet, the four fields of feature header, send / receive flag, checksum and feature tail of the data part of each sampled UDP packet are extracted in sequence.

[0039] It should be noted that, Figure 2 This is a schematic diagram of the structure of the sampled UDP packet provided in the embodiments of this application, as shown below. Figure 2 As shown, the sampled UDP packets in the game include a header and a data portion.

[0040] (1) The header includes the source port, destination port, length, and checksum. The source port represents the port used by the game client to send data; the destination port represents the port used by the server to reply with data; the length is the length of the sampled UDP packet; and the checksum is used to detect whether the sampled UDP packet data has changed during transmission, ensuring the integrity of the sampled UDP packet data.

[0041] (2) The data part includes characteristic values, which indicate that the first N bits of the data part of the sampled UDP packet have the following characteristic value pattern. The characteristic value pattern characterizes the structured pattern corresponding to the characteristic value field in the data part of the game UDP packet, that is, the distribution pattern of the field in the characteristic value. N is an integer greater than 1. Figure 3 This is a schematic diagram of the structure of the feature values ​​of the data portion in the sampled UDP packet provided in the embodiments of this application, such as... Figure 3As shown, the feature value includes a feature header, send / receive flags, a checksum, and a feature end. The feature header consists of the first bytes of data in the data portion of the sampled UDP packet. The feature header is identical for all sampled UDP packets within the same game and cannot be empty. The send / receive flags include the send flag for the client and the receive flag for the server. These flags can be empty; if empty, they can be assigned the values ​​of the source and destination ports in the sampled UDP packet. The checksum is used to match the send flag for the client and the receive flag for the server, and is used for subsequent calculations to optimize round-trip latency. This checksum cannot be empty. The feature end is the end marker for the feature value of the sampled UDP packet. The feature end is identical for all sampled UDP packets within the same game and can be empty.

[0042] Step 120: Based on the feature value header and feature value tail corresponding to each of the sampled UDP packets, determine the game UDP packets that satisfy the feature value pattern from all the sampled UDP packets; the feature value pattern is used to characterize the structured pattern corresponding to the feature value field in the data part of the game UDP packet.

[0043] Specifically, after extracting each field of the feature value from the data portion of each sampled UDP packet, based on the feature value pattern that the feature value header and feature value tail of each sampled UDP packet in the same game are the same, game UDP packets with complete data belonging to the same game are selected from all sampled UDP packets. This filters out noise data generated by the game process and improves the accuracy of subsequent calculations to optimize round-trip latency.

[0044] Step 130: Based on the send / receive flags or port pointers corresponding to each game UDP packet, divide all game UDP packets into client-side packets and server-side response packets.

[0045] Specifically, after filtering out game UDP packets, if the game UDP packets contain send / receive flags, they are categorized based on these flags, classifying each packet as either a client-side send or server-side reply. If the game UDP packets do not contain send / receive flags, they are categorized based on port pointers. For example, assuming the source port is the client port and the destination port is the server port, if the port pointer points from the source port to the destination port, the game UDP packet is classified as a client-side send; if the port pointer points from the destination port to the source port, the game UDP packet is classified as a server-side reply. This categorization of game UDP packets facilitates subsequent checksum matching and resolves out-of-order issues caused by connectionless UDP connections.

[0046] Step 140: Based on the verification codes of the client's packet and the server's response packet, determine the optimized round-trip latency.

[0047] Specifically, after classifying and obtaining the client's sent packets and the server's returned packets, the checksums of all client sent packets are matched one by one with the checksums of all server returned packets to determine the round-trip time. Based on all the round-trip times, the optimal round-trip time is determined.

[0048] The round-trip time (RTT) determination method provided in this application extracts the feature value header, send / receive flags, checksum, and feature value tail of each sampled UDP packet during the game process. Based on the feature value header and tail of each sampled UDP packet, game UDP packets that satisfy the feature value pattern corresponding to the structured pattern of the feature value fields in the data part of the game UDP packet are selected from all sampled UDP packets. Based on the send / receive flags or port pointers of each game UDP packet, all game UDP packets are divided into client packets and server responses. Based on the checksums of the client packets and server responses, the optimized RTT is determined. In this application embodiment, by independently analyzing the feature fields of UDP packets, game UDP packets that satisfy the feature value pattern are identified from out-of-order sampled UDP packets. The optimized RTT is calculated without relying on server cooperation or data decryption, solving the problem of inaccurate strategy for game UDP packet RTT due to gateway interception, data encryption, or server non-response. This effectively improves the reliability of RTT determination, thereby improving game network quality and user experience.

[0049] In one embodiment, the feature headers corresponding to all sampled UDP packets during the game are extracted, including: S11. Based on the initial feature value header of each sampled UDP packet, the preset game feature value header, and all sampled UDP packets, determine the first initial matching value corresponding to all sampled UDP packets; S12. Increment the length of the initial feature value header to obtain the first feature value header; S13. Based on the first feature value header, the preset game feature value header, and all sampled UDP packets, determine the first matching value corresponding to all sampled UDP packets; S14. When the first matching value is equal to the first initial matching value, the first feature value header is determined as the new initial feature value header. Steps S12 and S13 are repeated until the first matching value is equal to the first initial matching value. The final initial feature value header is then determined as the feature value header corresponding to all sampled UDP packets. S15. If the first matching value is not equal to the first initial matching value, the initial feature value header is determined as the feature value header corresponding to all sampled UDP packets.

[0050] For example, Figure 4 This is a schematic diagram illustrating an example of feature header extraction provided in an embodiment of this application, such as... Figure 4 As shown, taking an initial feature header of 4 bytes and a first initial match value of 100% as an example, firstly, the first 4 bytes of all sampled UDP packets are extracted as the initial feature header. The initial feature header of each sampled UDP packet is then matched against the preset game feature header corresponding to the preset game. The number of matches is determined from all sampled UDP packets. Next, the ratio of the number of matches to the total number of sampled UDP packets is calculated; this ratio is the first initial match value. A first initial match value of 100% indicates that the first 4 bytes of all sampled UDP packets are identical to the preset game feature header, and this first initial match value is used as the baseline. Then, the length of the initial feature header is incremented, from the first 4 bytes to the first 5 bytes, resulting in a first feature header of the first 5 bytes. In step S13, each first feature value header is matched with a preset game feature value header to determine the number of matches from all sampled UDP packets. Then, the ratio of the number of matches to the total number of all sampled UDP packets is calculated. This ratio is the first matching value. The first matching value is 100%, which means that the first 5 bytes of all sampled UDP packets are the same as the preset game feature value header and the same as the first initial matching value. Therefore, the first feature value header is used as the new initial feature value header and incremented again, that is, from the first 5 bytes to the first 6 bytes. The above steps of calculating the first matching value and comparing it with the first initial matching value are repeated. If the first matching value is still the same as the first initial matching value, i.e., 100%, it indicates that all sampled UDP packets have longer feature headers. The value is then incremented, and the above operation is repeated until the first matching value is not equal to the first initial matching value. This indicates that the length n+1 of the current first feature header exceeds the maximum length of the feature header. At this point, the initial feature header corresponding to the current first feature header can be determined as the feature header, and the length n of the initial feature header is 1 less than the length n+1 of the current first feature header. That is, the length ch1 of the feature header is 1, and the position of the feature header is U[0:n].

[0051] In this embodiment, the abrupt change point of the matching value is determined by the reverse order algorithm, which accurately captures the common boundary of the feature value header of all sampled UDP packets, ensuring the accuracy of feature value header extraction. Moreover, the matching process does not require prior knowledge of the specific format of the game UDP packets, which can adapt to the communication protocols of different games and improve versatility.

[0052] In one embodiment, the send / receive flag bits corresponding to all sampled UDP packets during the game are extracted, including: Based on port pointing, all sampled UDP packets are divided into client packet sending packets and server response packets, and the length of the aforementioned feature value header bytes in the client packet sending packets and the server response packets is removed; Based on the first flag bit corresponding to different packet offsets in each client packet, the preset packet flag bit, all client packet packets and the first preset threshold, the packet matching result is determined; If the packet matching result is a successful packet matching, determine the packet sending flag, and determine the packet receiving matching result based on the position of the packet sending flag, the preset packet receiving flag, all server response packets and the first preset threshold. If the packet matching result is a successful packet matching, then the packet receiving flag is determined.

[0053] Specifically, firstly, based on the port pointer, all sampled UDP packets are classified into client-sending packets and server-return packets. Due to the continuity of the feature value fields, the first ch1 bytes of both the client-sending and server-return packets are removed, leaving the feature value headers in the remaining packets. Next, for client-sending packets, the initial first sending offset ch2 = 0 bytes, while the length of the send / receive flags is 2 bytes. Therefore, two bytes are truncated from the first sending offset ch2 to obtain the first flag corresponding to that offset. Then, based on the first flag, the preset sending flag, all client-sending packets, and the first preset threshold, the packet matching result is determined. If the packet matching result is a successful match, the sending flag is determined. Based on the position of the sending flag, the preset receiving flag, all server-return packets, and the first preset threshold, the receiving matching result is determined. If the receiving matching result is a successful match, the receiving flag is further determined. If the packet sending match result is "packet sending match failed" or the packet receiving match result is "packet receiving match failed", it indicates that all sampled UDP packets do not have the send / receive flag bit.

[0054] In one embodiment, determining the packet matching result based on the first flag bit corresponding to different packet offsets in each of the client packet messages, the preset packet flag bit, all client packet messages, and the first preset threshold includes: Based on the first flag bit corresponding to the first packet offset in each client packet, the preset packet flag bit, and all client packet packets, determine the second initial matching value corresponding to all client packet packets; If the second initial matching value is less than the first preset threshold, the first packet offset is incremented to obtain the second packet offset; the second flag corresponding to the second packet offset is set as the new first flag, and the step of determining the second initial matching value is repeated until the second packet offset is greater than the length of each client packet message, and the packet matching result is determined to be a packet matching failure. If the second initial matching value is greater than or equal to the first preset threshold, the packet matching result is determined to be a successful packet matching.

[0055] For example, Figure 5 This is a schematic diagram illustrating an example of extracting the packet sending flag bit provided in an embodiment of this application, such as... Figure 5 As shown, taking a first packet offset of 0 and a first preset threshold of 95% as an example, two bytes are extracted from the first packet offset of 0 to obtain the first flag bit. The first flag bit of each client's packet is matched with the preset packet flag bit to determine the number of matches. The ratio of the number of matches to the total number of all client packets is calculated, and this ratio is the second initial matching value, which is 10%. Next, the second initial matching value is compared with the first preset threshold. The second initial matching value of 10% is less than the first preset threshold of 90%, indicating that the matching value is too low. At this time, the first packet offset is incremented, that is, the first packet offset is incremented from 0 to 1, and the second packet offset is 1. Two bytes are truncated from the second packet offset to obtain the second flag bit. The second packet offset is used as the new first packet offset, and the second flag bit is used as the new first flag bit. The above steps of calculating the second initial matching value and comparison are repeated until the second initial matching value is 95%. When the second initial matching value is greater than the first preset threshold, the matching value is satisfied. At this time, it can be considered that there is a packet flag bit in each client packet, the packet matching result is that the packet matching is successful, and the middle first flag bit is determined as the packet flag bit, and the position of the packet flag bit is [ch2, ch2+2]. If the second initial matching value clock is still less than the first preset threshold until the second packet offset is greater than the length of each client packet, the packet matching result is packet matching failure, that is, there is no packet flag bit in the client packet. At this time, the extraction of the packet flag bit can be ended.

[0056] In one embodiment, determining the packet matching result based on the position of the sending flag, the preset receiving flag, all server response packets, and the first preset threshold includes: Determine the third flag bit in each of the server-side response packets that is in the same position as the packet sending flag bit; Based on each of the third flag bits, the preset packet receiving flag bits, and all server response packets, determine the third initial matching value corresponding to the server response packet; If the third initial matching value is greater than the first preset threshold, the packet receiving matching result is determined to be a successful packet receiving match; If the third initial matching value is less than or equal to the first preset threshold, the packet receiving matching result is determined to be a packet receiving matching failure.

[0057] Specifically, after determining that a sending flag exists in the client's packet, since the sending flag and receiving flag are in the same position, a third flag is determined based on the position of the sending flag. Then, the third flag of each server's response packet is matched against a preset receiving flag to determine the number of matches. The ratio of the number of matches to the total number of server response packets is then calculated; this ratio is the third initial matching value. If this third initial matching value is greater than a first preset threshold, it indicates that the matching value is satisfied, the server's response packet contains a receiving flag, and the receiving match result is successful. In this case, the third flag can be determined as the receiving flag, and its position is determined to be [ch2, ch2+2]. If the third initial matching value is less than or equal to the first preset threshold, it indicates that the matching value is too low, the server's response packet does not contain a receiving flag, and the receiving match result is failed. In this case, it can be considered that no sending or receiving flags exist in the sampled UDP packet.

[0058] In one embodiment, the checksums corresponding to all sampled UDP packets during the game are extracted, including: Based on the length of the feature header and the position of the send / receive flag, determine the initial offset corresponding to the server's response packet and the client's sent packet, respectively. The initial packet checksum corresponding to the initial offset in each of the server-side response packets is matched with the initial packet checksum corresponding to the initial offset in each of the client-side packet packets to obtain the checksum matching result. If the verification matching result is that all initial return packet verification codes match all initial sending packet verification codes one by one, then each initial return packet verification code is determined as the verification code corresponding to each server-side return packet message, and each initial sending packet verification code is determined as the verification code corresponding to each client-side sending packet message. If the verification matching result shows that at least one pair of initial return packet checksums and initial send packet checksums do not match, the initial offset is incremented to obtain an incrementing offset, and the step of determining the verification matching result is repeated until the verification matching result shows that all initial return packet checksums match all initial send packet checksums one by one. The final initial return packet checksums are then determined as the checksums corresponding to the server-side return packet messages, and the initial send packet checksums are determined as the checksums corresponding to the client-side send packet messages.

[0059] Specifically, due to the continuity of the feature values, the initial offset ch3 = ch1 + ch2 + 2 can be set for the checksum field in both the server-side response packet and the client-side packet. Since this checksum field is 2 bytes, the last 2 bytes of the initial offset in the client-side packet and the last 2 bytes of the initial offset in the server-side response packet are extracted as the initial checksum. Then, all initial checksums are matched one by one with all initial response checksums. If all initial checksums match one by one, the match is successful, and each initial checksum is determined as the checksum corresponding to each client-side packet and each initial response checksum is determined as the checksum corresponding to each server-side response packet. At this point, the offset value ch3 = ch3 - ch2 - ch1 can be determined. If none of the initial packet checksums match all the initial response checksums, then increment the initial offset by 1. This incremented offset is then used as the new initial offset. This process is repeated until all the initial packet checksums match all the initial response checksums. In this case, the match is successful, and each initial packet checksum is assigned as the checksum for each client's packet and each initial response checksum is assigned as the checksum for each server's response packet.

[0060] In one embodiment, the feature tails corresponding to all sampled UDP packets during the game are extracted, including: Based on the length of the feature header, the position of the send / receive packet flag, and the position of the checksum, the first initial feature tail corresponding to the initial tail offset in each sampled UDP packet is determined; Based on the first initial feature value tail of each sampled UDP packet, the preset game feature value tail, and all sampled UDP packets, determine the fourth initial matching value corresponding to all sampled UDP packets. Based on the fourth initial matching value and the second preset threshold, the starting offset corresponding to the tail of the feature value is determined; Based on the initial length and the starting offset, determine the second initial feature value tail corresponding to each sampled UDP packet; Based on the second initial feature value tail corresponding to each of the sampled UDP packets, the preset game feature value tail, all sampled UDP packets, and the second preset threshold, the fifth initial matching value corresponding to all sampled UDP packets is determined; The feature value tail is determined based on the fifth initial matching value, the second preset threshold, and the starting offset.

[0061] Specifically, due to the continuity of the feature value fields, the initial tail offset of the feature value tail field in the sampled UDP packet can be set to ch4 = ch1 + ch2 + ch3 + 2. Since the length of the feature value tail is at least 4 bytes, the last 4 bytes after the initial tail offset of the sampled UDP packet are extracted as the first initial feature value tail. Then, each first initial feature value tail is matched with a preset game feature value tail to determine the number of matches. The ratio of the number of matches to the total number of all sampled UDP packets is calculated; this ratio is the fourth initial matching value corresponding to all sampled UDP packets. Next, based on the comparison result of the fourth initial matching value and the second preset threshold, and using the ascending order algorithm, the initial tail offset is incremented sequentially until the fourth initial matching value meets the second preset threshold, at which point the starting offset corresponding to that feature value tail is obtained. Next, starting from the initial offset, the last four bytes are extracted to obtain the second initial feature value tail. Each second initial feature value tail is matched with a preset game feature value tail to determine the number of matches. The ratio of the number of matches to the total number of sampled UDP packets is calculated, and this ratio is the fifth initial matching value for all sampled UDP packets. Then, based on the comparison result of the fifth initial matching value and the second preset threshold, and using the reverse order algorithm, the initial length is incremented sequentially from the initial offset until the fifth initial matching value is not equal to the second preset threshold. At this point, the termination offset of the feature value tail is determined, thus determining the feature value tail based on the initial offset and the termination offset.

[0062] In one embodiment, determining the starting offset corresponding to the feature value tail based on the fourth initial matching value and the second preset threshold includes: When the fourth initial matching value is equal to the second preset threshold, the initial tail offset is determined as the starting offset corresponding to the feature value tail; If the fourth initial matching value is less than the second preset threshold, the initial tail offset is incremented to obtain a first tail offset. The first feature value tail corresponding to the first tail offset is determined as the new first initial feature value tail. The first tail offset is determined as the new initial tail offset, and the step of determining the fourth initial matching value is repeated until the fourth initial matching value is equal to the second preset threshold. Then, the final initial tail offset is determined as the starting offset corresponding to the feature value tail.

[0063] Specifically, taking an initial tail offset of 0 as an example, the fourth initial matching value is compared with the second preset threshold. If the fourth initial matching value equals the second preset threshold, the initial tail offset is determined as the starting offset corresponding to the feature value tail. If the fourth initial matching value corresponding to the first initial feature value tail is not equal to the second preset threshold, the initial tail offset is incremented, i.e., the initial tail offset is incremented from 0 to 1, resulting in a first tail offset of 1. The four bytes after the first tail offset are truncated as the first feature value tail. Then, the first tail offset is determined as the new initial tail offset, and the first feature value tail is determined as the new first initial feature value tail. The fourth initial matching value is calculated and compared repeatedly. This continues until the fourth initial matching value equals 100% of the second preset threshold, at which point the final initial tail offset is determined as the starting offset corresponding to the feature value tail.

[0064] In one embodiment, determining the feature value tail based on the fifth initial matching value, the second preset threshold, and the starting offset includes: If the fifth initial matching value is not equal to the second preset threshold, the second initial feature value tail is determined as the feature value tail; If the fifth initial matching value is equal to the second preset threshold, the initial length is incremented to obtain a first length. The first length is determined as the new initial length, and the second feature value tail is determined as the new second initial feature value tail. The step of determining the fifth initial matching value is repeated until the fifth initial matching value is not equal to the second preset threshold. Then, the final second initial feature value tail is determined as the feature value tail. The second feature value tail is determined based on the first length and the starting offset.

[0065] Specifically, the fifth initial matching value is compared with the second preset threshold. If the fifth initial matching value is not equal to the second preset threshold, it indicates that the termination offset of the feature value tail has been determined. That is, the sum of the starting offset and the initial length (i.e., 4 bytes) is determined as the termination offset, and the second initial feature value tail is determined as the feature value tail. If the fifth initial matching value is equal to the second preset value, it indicates that the sampled UDP packet has a longer feature value tail. In this case, the initial length is incremented from 4 bytes to 5 bytes, resulting in a first length of 5 bytes. Starting from the starting offset, 5 bytes after the starting offset are truncated as the second feature value tail. Then, the first length is determined as the new initial length, and the second feature value tail is determined as the new second initial feature value tail. The steps of calculating the fifth initial matching value and comparing are repeated until the fifth initial matching value is not equal to the second preset threshold, at which point the increment stops. At this point, the termination offset of the feature value tail can be determined as the sum of the starting offset and the final initial length, and the final second initial feature value tail is determined as the feature value tail.

[0066] In one embodiment, determining the optimized round-trip latency based on the checksums of the packets sent by each client and the responses from each server includes: The checksums of the client packets and the server responses are matched to obtain multiple matching data pairs; each matching data pair includes client packets and server responses with the same checksum. Based on the corresponding packet receiving timestamp and packet sending timestamp of each of the matching data pairs, the single round-trip delay of each of the matching data pairs is determined; Based on the number of matched data pairs, the latency of all single round trips, and the perceived latency of the game screen during the same period as each single round trip, the optimal round trip latency is determined.

[0067] Specifically, after extracting the checksums corresponding to the client's sent packets and the server's returned packets, the checksums of all client-sent packets are matched one by one with the checksums of the server's returned packets, resulting in multiple matching data pairs. Each matching data pair includes client-sent packets and server-return packets with the same checksum. Then, for each matching data pair, the difference between the timestamp of the server's returned packet and the timestamp of the client's sent packet is calculated. This difference is the round-trip time (RTT) for that matching data pair. i =Rt i -St i , among which, rtt i Let Rt represent the round-trip time corresponding to the i-th matching data pair. i St represents the timestamp of the received packet corresponding to the server's response in the i-th matching data pair. i This represents the packet sending timestamp corresponding to the client's packet in the i-th matching data pair, where i is an integer greater than 0 and less than or equal to the total number of matching data pairs.

[0068] To verify the accuracy of round-trip latency in the game, in this embodiment of the application, the perceived latency in the game screen is collected to obtain a set of perceived latency datasets. The average perceived latency and the average difference of perceived latency corresponding to the datasets are calculated, and the perceived latency datasets are compared with the single round-trip latency at the corresponding time. Figure 6 This is a comparison trend chart of perceived latency and single round-trip latency provided in the embodiments of this application, such as... Figure 6 As shown, the perceived latency of the game screen is slightly larger than the single round-trip latency. Then, the jitter of the single round-trip latency and the perceived latency are calculated and compared. Figure 7 This is a comparison trend chart of single round-trip delay jitter and perceived delay jitter provided in the embodiments of this application, such as... Figure 7As shown, the linear trend graphs of single round-trip delay jitter and perceived delay jitter have a high degree of overlap, but fluctuations still exist.

[0069] Based on the above comparison, in this embodiment, after determining the single round-trip latency, the perceived latency of the game screen during the same time period as the single round-trip latency is obtained. This perceived latency is the time difference between the network latency calculated by the game application and the game screen display latency. Then, the absolute value of the sum of the single round-trip latency and the perceived latency during the same time period is calculated, and the mean of all absolute values ​​is calculated. This mean is the optimized round-trip latency after optimization using perceived latency.

[0070] After determining the optimized round-trip time, the optimized round-trip time is compared with the perceived time. Figure 8 This is a comparison trend chart of optimized round-trip latency and perceived latency provided in the embodiments of this application, such as... Figure 8 As shown, the optimized round-trip latency is closer to the perceived latency.

[0071] It should be noted that after determining the round-trip time for a single trip, the average round-trip time corresponding to all single round-trip times can also be calculated. This average round-trip time is expressed as... Where RTTargv represents the average round-trip time, and m represents the total number of matched data pairs. The average difference in round-trip time corresponding to all individual round-trip times can also be calculated, and this average difference in round-trip time is expressed as... Where Jitter represents the average difference in round-trip delay.

[0072] In one embodiment, the method further includes: Game test IP data with round-trip latency exceeding the latency quality threshold will be identified as poor-quality IPs. Path tracing is performed on the poor-quality IPs to determine the IP analysis data corresponding to them.

[0073] Specifically, the platform analyzes a large amount of reported game test IP data. This involves calculating the optimized round-trip latency (RTT) for each game test IP and comparing it to a latency quality deterioration threshold. If the optimized RTT exceeds the threshold, the game test IP is identified as a poor-quality IP. Details about the poor-quality IP can be obtained through the poor-quality IP details page. This information may include the IP address, IP owner, ISP, optimized RTT, RTT variance, and packet loss rate. For example, the details of such a poor-quality IP are shown in Table 1.

[0074] Table 1 IP address deploy IP address Operators Optimize round-trip latency / ms Round trip delay variance Packet loss rate xxx.xxx.x.xxx game City A Cloud other 124 16 0.41 xxx.xxx.x.xxx game City A Cloud other 129 18 0.15 xxx.xxx.x.xxx game City A Cloud other 120 17 0 xxx.xxx.x.xxx game City A Cloud other 130 14 0.07 xxx.xxx.x.xxx game City A Cloud other 124 19 0.07 xxx.xxx.x.xxx game City A Cloud other 127 20 0 Afterwards, the path of the poor-quality IP can be traced through the details page of the poor-quality IP. On the trace details page, you can get the path of the poor-quality IP and obtain the IP analysis data corresponding to the poor-quality IP. This IP analysis data can include the IP addresses that the poor-quality IP passed through, the IP address to which it belongs, and the time taken.

[0075] In addition, the scheduling quality of the game in each province can be determined by the location of the game's IP server, and the distribution of low-quality IPs in each province can be reflected by counting the total number of low-quality IPs in each province.

[0076] After obtaining optimized round-trip latency and low-quality IPs, game acceleration optimization can be assisted through the following three methods: First, game developer-assisted optimization, where the game developer optimizes and adjusts the game servers. Second, network link optimization, where low-quality IPs are provided to network link optimization companies, who then optimize and adjust the game link. Third, local network optimization, increasing the network bandwidth of terminal devices. By optimizing game acceleration, the game network quality can be effectively improved, enhancing the game network environment and thus improving the user's gaming experience.

[0077] It should be noted that if the send / receive flags in the game's UDP packets are not empty, the packet loss rate can be calculated by comparing the total number of packets sent by the client with the total number of matched data. This packet loss rate is expressed as Lost = ((S num -m) / S num )×100%, where Lost represents the packet loss rate, S num This indicates the total number of packets sent by the client.

[0078] The round-trip delay determination apparatus provided in this application is described below. The round-trip delay determination apparatus described below can be referred to in correspondence with the round-trip delay determination method described above.

[0079] This application provides a round-trip delay determination device. Figure 9 This is a schematic diagram of the round-trip delay determination device provided in the embodiments of this application, as shown below. Figure 9 As shown, the round-trip delay determination device 900 includes: an extraction module 910, a first determination module 920, a classification module 930, and a second determination module 940.

[0080] The extraction module 910 is used to sequentially extract the feature value header, send / receive flag, checksum and feature value tail of each sampled UDP packet during the game process; The first determining module 920 is used to determine game UDP packets that satisfy the feature value pattern from all sampled UDP packets based on the feature value header and feature value tail corresponding to each of the sampled UDP packets; the feature value pattern is used to characterize the structured pattern corresponding to the feature value field in the data part of the game UDP packet; The classification module 930 is used to classify all game UDP packets into client-sent packets and server-return packets based on the send / receive flags or port pointers corresponding to each game UDP packet. The second determining module 940 is used to determine the optimized round-trip latency based on the checksums of the packets sent by each client and the responses from each server.

[0081] The round-trip time (RTT) determination device provided in this application sequentially extracts the feature value header, send / receive flags, checksum, and feature value tail of each sampled UDP packet during the game. Based on the feature value header and tail of each sampled UDP packet, it filters game UDP packets that satisfy the feature value pattern corresponding to the structured pattern of the feature value fields in the data part of the game UDP packet from all sampled UDP packets. Based on the send / receive flags or port pointers of each game UDP packet, it divides all game UDP packets into client packets and server responses. Based on the checksums of the client packets and server responses, it determines the optimized RTT. In this application embodiment, by independently analyzing the feature fields of UDP packets, game UDP packets that satisfy the feature value pattern are identified from out-of-order sampled UDP packets. The optimized RTT is calculated without relying on server cooperation or data decryption, solving the problem of inaccurate strategy for game UDP packet RTT due to gateway interception, data encryption, or server non-response. This effectively improves the reliability of RTT determination, thereby improving game network quality and user experience.

[0082] Optionally, the extraction module 910 is specifically used for: S11. Based on the initial feature value header of each sampled UDP packet, the preset game feature value header, and all sampled UDP packets, determine the first initial matching value corresponding to all sampled UDP packets; S12. Increment the length of the initial feature value header to obtain the first feature value header; S13. Based on the first feature value header, the preset game feature value header, and all sampled UDP packets, determine the first matching value corresponding to all sampled UDP packets; S14. When the first matching value is equal to the first initial matching value, the first feature value header is determined as the new initial feature value header. Steps S12 and S13 are repeated until the first matching value is equal to the first initial matching value. The final initial feature value header is then determined as the feature value header corresponding to all sampled UDP packets. S15. If the first matching value is not equal to the first initial matching value, the initial feature value header is determined as the feature value header corresponding to all sampled UDP packets.

[0083] Optionally, the packet sending and receiving flags include a packet sending flag and a packet receiving flag.

[0084] Optionally, the extraction module 910 is specifically used for: Based on port pointing, all sampled UDP packets are divided into client packet sending packets and server response packets, and the length of the aforementioned feature value header bytes in the client packet sending packets and the server response packets is removed; Based on the first flag bit corresponding to different packet offsets in each client packet, the preset packet flag bit, all client packet packets and the first preset threshold, the packet matching result is determined; If the packet matching result is a successful packet matching, determine the packet sending flag, and determine the packet receiving matching result based on the position of the packet sending flag, the preset packet receiving flag, all server response packets and the first preset threshold. If the packet matching result is a successful packet matching, then the packet receiving flag is determined.

[0085] Optionally, the extraction module 910 is specifically used for: Based on the first flag bit corresponding to the first packet offset in each client packet, the preset packet flag bit, and all client packet packets, determine the second initial matching value corresponding to all client packet packets; If the second initial matching value is less than the first preset threshold, the first packet offset is incremented to obtain the second packet offset; the second flag corresponding to the second packet offset is set as the new first flag, and the step of determining the second initial matching value is repeated until the second packet offset is greater than the length of each client packet message, and the packet matching result is determined to be a packet matching failure. If the second initial matching value is greater than or equal to the first preset threshold, the packet matching result is determined to be a successful packet matching.

[0086] Optionally, the extraction module 910 is specifically used for: Determine the third flag bit in each of the server-side response packets that is in the same position as the packet sending flag bit; Based on each of the third flag bits, the preset packet receiving flag bits, and all server response packets, determine the third initial matching value corresponding to the server response packet; If the third initial matching value is greater than the first preset threshold, the packet receiving matching result is determined to be a successful packet receiving match; If the third initial matching value is less than or equal to the first preset threshold, the packet receiving matching result is determined to be a packet receiving matching failure.

[0087] Optionally, the extraction module 910 is specifically used for: Based on the length of the feature header and the position of the send / receive flag, determine the initial offset corresponding to the server's response packet and the client's sent packet, respectively. The initial packet checksum corresponding to the initial offset in each of the server-side response packets is matched with the initial packet checksum corresponding to the initial offset in each of the client-side packet packets to obtain the checksum matching result. If the verification matching result is that all initial return packet verification codes match all initial sending packet verification codes one by one, then each initial return packet verification code is determined as the verification code corresponding to each server-side return packet message, and each initial sending packet verification code is determined as the verification code corresponding to each client-side sending packet message. If the verification matching result shows that at least one pair of initial return packet checksums and initial send packet checksums do not match, the initial offset is incremented to obtain an incrementing offset, and the step of determining the verification matching result is repeated until the verification matching result shows that all initial return packet checksums match all initial send packet checksums one by one. The final initial return packet checksums are then determined as the checksums corresponding to the server-side return packet messages, and the initial send packet checksums are determined as the checksums corresponding to the client-side send packet messages.

[0088] Optionally, the extraction module 910 is specifically used for: Based on the length of the feature header, the position of the send / receive packet flag, and the position of the checksum, the first initial feature tail corresponding to the initial tail offset in each sampled UDP packet is determined; Based on the first initial feature value tail of each sampled UDP packet, the preset game feature value tail, and all sampled UDP packets, determine the fourth initial matching value corresponding to all sampled UDP packets. Based on the fourth initial matching value and the second preset threshold, the starting offset corresponding to the tail of the feature value is determined; Based on the initial length and the starting offset, determine the second initial feature value tail corresponding to each sampled UDP packet; Based on the second initial feature value tail corresponding to each of the sampled UDP packets, the preset game feature value tail, all sampled UDP packets, and the second preset threshold, the fifth initial matching value corresponding to all sampled UDP packets is determined; The feature value tail is determined based on the fifth initial matching value, the second preset threshold, and the starting offset.

[0089] Optionally, the extraction module 910 is specifically used for: When the fourth initial matching value is equal to the second preset threshold, the initial tail offset is determined as the starting offset corresponding to the feature value tail; If the fourth initial matching value is less than the second preset threshold, the initial tail offset is incremented to obtain a first tail offset. The first feature value tail corresponding to the first tail offset is determined as the new first initial feature value tail. The first tail offset is determined as the new initial tail offset, and the step of determining the fourth initial matching value is repeated until the fourth initial matching value is equal to the second preset threshold. Then, the final initial tail offset is determined as the starting offset corresponding to the feature value tail.

[0090] Optionally, the extraction module 910 is specifically used for: If the fifth initial matching value is not equal to the second preset threshold, the second initial feature value tail is determined as the feature value tail; If the fifth initial matching value is equal to the second preset threshold, the initial length is incremented to obtain a first length. The first length is determined as the new initial length, and the second feature value tail is determined as the new second initial feature value tail. The step of determining the fifth initial matching value is repeated until the fifth initial matching value is not equal to the second preset threshold. Then, the final second initial feature value tail is determined as the feature value tail. The second feature value tail is determined based on the first length and the starting offset.

[0091] Optionally, the second determining module 940 is specifically used for: The checksums of the client packets and the server responses are matched to obtain multiple matching data pairs; each matching data pair includes client packets and server responses with the same checksum. Based on the corresponding packet receiving timestamp and packet sending timestamp of each of the matching data pairs, the single round-trip delay of each of the matching data pairs is determined; Based on the number of matched data pairs, the latency of all single round trips, and the perceived latency of the game screen during the same period as each single round trip, the optimal round trip latency is determined.

[0092] Optionally, the round-trip delay determination device further includes a network quality analysis module, which is specifically used for: Game test IP data with round-trip latency exceeding the latency quality threshold will be identified as poor-quality IPs. Path tracing is performed on the poor-quality IPs to determine the IP analysis data corresponding to them.

[0093] Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application, such as... Figure 10 As shown, the electronic device may include: a processor 1010, a communications interface 1020, a memory 1030, and a communication bus 1040, wherein the processor 1010, the communications interface 1020, and the memory 1030 communicate with each other through the communication bus 1040. The processor 1010 can call logical instructions in the memory 1030 to execute a round-trip delay determination method, which includes: sequentially extracting the feature value header, send / receive flags, checksum, and feature value tail corresponding to each sampled UDP packet during the game; determining game UDP packets that satisfy the feature value pattern from all sampled UDP packets based on the feature value header and feature value tail corresponding to each sampled UDP packet; the feature value pattern is used to characterize the structured pattern corresponding to the feature value field in the data part of the game UDP packet; dividing all game UDP packets into client packets and server packets based on the send / receive flags or port pointers corresponding to each game UDP packet; and determining the optimized round-trip delay based on the checksums of the client packets and the server packets.

[0094] Furthermore, the logical instructions in the aforementioned memory 1030 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0095] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the round-trip delay determination method provided by the above methods. The method includes: sequentially extracting the feature value header, send / receive flag, checksum, and feature value tail corresponding to each of the sampled UDP packets during the game; determining game UDP packets that satisfy the feature value pattern from all sampled UDP packets based on the feature value header and feature value tail corresponding to each of the sampled UDP packets; the feature value pattern is used to characterize the structured pattern corresponding to the feature value field in the data part of the game UDP packet; dividing all game UDP packets into client packets and server packets based on the send / receive flag or port pointer corresponding to each of the game UDP packets; and determining the optimized round-trip delay based on the checksum of the client packets and the server packets.

[0096] Furthermore, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a round-trip delay determination method provided by the above methods. This method includes: sequentially extracting the feature value header, send / receive flags, checksum, and feature value tail corresponding to each of the sampled UDP packets during the game; determining game UDP packets that satisfy the feature value pattern from all sampled UDP packets based on the feature value header and feature value tail corresponding to each of the sampled UDP packets; the feature value pattern is used to characterize the structured pattern corresponding to the feature value field in the data part of the game UDP packet; dividing all game UDP packets into client-side packets and server-side packets based on the send / receive flags or port pointers corresponding to each of the game UDP packets; and determining the optimized round-trip delay based on the checksums of the client-side packets and the server-side packets.

[0097] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0099] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for determining round-trip time delay, characterized in that, include: Extract the feature header, send / receive flags, checksum, and feature tail of each sampled UDP packet during the game process in sequence; Based on the feature value header and feature value tail of each sampled UDP packet, game UDP packets that satisfy the feature value pattern are determined from all sampled UDP packets. The eigenvalue pattern is used to characterize the structured pattern corresponding to the eigenvalue field in the data part of the game UDP packet; Based on the send / receive flags or port pointers corresponding to each game UDP packet, all game UDP packets are divided into client-sent packets and server-return packets. Based on the verification codes of the client's sent packets and the server's returned packets, the round-trip latency is optimized.

2. The round-trip time delay determination method according to claim 1, characterized in that, The step of determining optimized round-trip latency based on the verification codes of the client's packet transmission and the server's response includes: The checksums of the client packets and the server responses are matched to obtain multiple matching data pairs; each matching data pair includes client packets and server responses with the same checksum. Based on the corresponding packet receiving timestamp and packet sending timestamp of each of the matching data pairs, the single round-trip delay of each of the matching data pairs is determined; Based on the number of matched data pairs, the latency of all single round trips, and the perceived latency of the game screen during the same period as each single round trip, the optimal round trip latency is determined.

3. The round-trip time delay determination method according to claim 1, characterized in that, Extract the feature headers corresponding to all sampled UDP packets during the game, including: S11. Based on the initial feature value header of each sampled UDP packet, the preset game feature value header, and all sampled UDP packets, determine the first initial matching value corresponding to all sampled UDP packets; S12. Increment the length of the initial feature value header to obtain the first feature value header; S13. Based on the first feature value header, the preset game feature value header, and all sampled UDP packets, determine the first matching value corresponding to all sampled UDP packets; S14. When the first matching value is equal to the first initial matching value, the first feature value header is determined as the new initial feature value header. Steps S12 and S13 are repeated until the first matching value is equal to the first initial matching value. The final initial feature value header is then determined as the feature value header corresponding to all sampled UDP packets. S15. If the first matching value is not equal to the first initial matching value, the initial feature value header is determined as the feature value header corresponding to all sampled UDP packets.

4. The round-trip time delay determination method according to claim 1, characterized in that, The packet sending and receiving flags include a packet sending flag and a packet receiving flag; Extract the send / receive flags corresponding to all sampled UDP packets during the game, including: Based on port pointing, all sampled UDP packets are divided into client packet sending packets and server response packets, and the length of the aforementioned feature value header bytes in the client packet sending packets and the server response packets is removed; Based on the first flag bit corresponding to different packet offsets in each client packet, the preset packet flag bit, all client packet packets and the first preset threshold, the packet matching result is determined; If the packet matching result is a successful packet matching, determine the packet sending flag, and determine the packet receiving matching result based on the position of the packet sending flag, the preset packet receiving flag, all server response packets and the first preset threshold. If the packet matching result is a successful packet matching, then the packet receiving flag is determined.

5. The round-trip time delay determination method according to claim 4, characterized in that, The step of determining the packet matching result based on the first flag bit corresponding to different packet offsets in each client packet, the preset packet flag bit, all client packet messages, and the first preset threshold includes: Based on the first flag bit corresponding to the first packet offset in each client packet, the preset packet flag bit, and all client packet packets, determine the second initial matching value corresponding to all client packet packets; If the second initial matching value is less than the first preset threshold, the first packet offset is incremented to obtain the second packet offset; the second flag corresponding to the second packet offset is set as the new first flag, and the step of determining the second initial matching value is repeated until the second packet offset is greater than the length of each client packet message, and the packet matching result is determined to be a packet matching failure. If the second initial matching value is greater than or equal to the first preset threshold, the packet matching result is determined to be a successful packet matching.

6. The round-trip time delay determination method according to claim 4, characterized in that, The step of determining the packet matching result based on the position of the sending flag, the preset receiving flag, all server response packets, and the first preset threshold includes: Determine the third flag bit in each of the server-side response packets that is in the same position as the packet sending flag bit; Based on each of the third flag bits, the preset packet receiving flag bits, and all server response packets, determine the third initial matching value corresponding to the server response packet; If the third initial matching value is greater than the first preset threshold, the packet receiving matching result is determined to be a successful packet receiving match; If the third initial matching value is less than or equal to the first preset threshold, the packet receiving matching result is determined to be a packet receiving matching failure.

7. The round-trip time delay determination method according to any one of claims 4-6, characterized in that, Extract the checksums of all sampled UDP packets during the game, including: Based on the length of the feature header and the position of the send / receive flag, determine the initial offset corresponding to the server's response packet and the client's sent packet, respectively. The initial packet checksum corresponding to the initial offset in each of the server-side response packets is matched with the initial packet checksum corresponding to the initial offset in each of the client-side packet packets to obtain the checksum matching result. If the verification matching result is that all initial return packet verification codes match all initial sending packet verification codes one by one, then each initial return packet verification code is determined as the verification code corresponding to each server-side return packet message, and each initial sending packet verification code is determined as the verification code corresponding to each client-side sending packet message. If the verification matching result shows that at least one pair of initial return packet checksums and initial send packet checksums do not match, the initial offset is incremented to obtain an incrementing offset, and the step of determining the verification matching result is repeated until the verification matching result shows that all initial return packet checksums match all initial send packet checksums one by one. The final initial return packet checksums are then determined as the checksums corresponding to the server-side return packet messages, and the initial send packet checksums are determined as the checksums corresponding to the client-side send packet messages.

8. The round-trip time delay determination method according to claim 1, characterized in that, Extract the feature values ​​of the tails of all sampled UDP packets during the game, including: Based on the length of the feature header, the position of the send / receive packet flag, and the position of the checksum, the first initial feature tail corresponding to the initial tail offset in each sampled UDP packet is determined; Based on the first initial feature value tail of each sampled UDP packet, the preset game feature value tail, and all sampled UDP packets, determine the fourth initial matching value corresponding to all sampled UDP packets. Based on the fourth initial matching value and the second preset threshold, the starting offset corresponding to the tail of the feature value is determined; Based on the initial length and the starting offset, determine the second initial feature value tail corresponding to each sampled UDP packet; Based on the second initial feature value tail corresponding to each of the sampled UDP packets, the preset game feature value tail, all sampled UDP packets, and the second preset threshold, the fifth initial matching value corresponding to all sampled UDP packets is determined; The feature value tail is determined based on the fifth initial matching value, the second preset threshold, and the starting offset.

9. The round-trip time delay determination method according to claim 8, characterized in that, The step of determining the starting offset corresponding to the tail of the feature value based on the fourth initial matching value and the second preset threshold includes: When the fourth initial matching value is equal to the second preset threshold, the initial tail offset is determined as the starting offset corresponding to the feature value tail; If the fourth initial matching value is less than the second preset threshold, the initial tail offset is incremented to obtain a first tail offset. The first feature value tail corresponding to the first tail offset is determined as the new first initial feature value tail. The first tail offset is determined as the new initial tail offset, and the step of determining the fourth initial matching value is repeated until the fourth initial matching value is equal to the second preset threshold. Then, the final initial tail offset is determined as the starting offset corresponding to the feature value tail.

10. The round-trip time delay determination method according to claim 8, characterized in that, The step of determining the feature value tail based on the fifth initial matching value, the second preset threshold, and the starting offset includes: If the fifth initial matching value is not equal to the second preset threshold, the second initial feature value tail is determined as the feature value tail; If the fifth initial matching value is equal to the second preset threshold, the initial length is incremented to obtain a first length. The first length is determined as the new initial length, and the second feature value tail is determined as the new second initial feature value tail. The step of determining the fifth initial matching value is repeated until the fifth initial matching value is not equal to the second preset threshold. Then, the final second initial feature value tail is determined as the feature value tail. The second feature value tail is determined based on the first length and the starting offset.

11. The round-trip time delay determination method according to claim 1, characterized in that, The method further includes: Game test IP data with round-trip latency exceeding the latency quality threshold will be identified as poor-quality IPs. Path tracing is performed on the poor-quality IPs to determine the IP analysis data corresponding to them.

12. A round-trip time delay determination device, characterized in that, include: The extraction module is used to sequentially extract the feature header, send / receive flags, checksum, and feature tail of each sampled UDP packet during the game process; The first determining module is used to determine the game UDP packets that satisfy the feature value pattern from all the sampled UDP packets based on the feature value header and feature value tail corresponding to each of the sampled UDP packets. The eigenvalue pattern is used to characterize the structured pattern corresponding to the eigenvalue field in the data part of the game UDP packet; The classification module is used to classify all game UDP packets into client-sent packets and server-return packets based on the send / receive flags or port pointers corresponding to each game UDP packet. The second determining module is used to determine the optimized round-trip latency based on the verification codes of the client's sent packets and the server's returned packets.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the round-trip delay determination method as described in any one of claims 1 to 11.

14. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the round-trip delay determination method as described in any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the round-trip delay determination method as described in any one of claims 1 to 11.

Images