Method and device for detecting UDP service lag, electronic equipment and storage medium

Abstract

The present application relates to the field of network communication, and provides a UDP service lag detection method and device, electronic equipment and storage medium, comprising: acquiring real-time mixed UDP flow based on five-tuple reorganization; based on the current service mode, applying the similarity between the number of packets of the current UDP flow and the average of historical packet numbers, or applying the proportion of the number of packets of the current UDP flow in the number of all flow packets, to identify a to-be-tested core UDP flow from the real-time mixed UDP flow; based on a double sliding window algorithm, adaptively calculating the key features of the to-be-tested core UDP flow under the current service mode; inputting the key features into a trained lag detection model for service lag detection to obtain a detection result, wherein the lag detection model is trained based on sample core UDP flows and corresponding labels. The method, device, electronic equipment and storage medium provided by the present application solve the problem of lack of universality caused by protocol dependence in the traditional scheme.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network communication, and in particular to a UDP service lag detection method and device, electronic equipment and a storage medium. BACKGROUND

[0002] With the rapid development of low-latency real-time interactive applications, the User Datagram Protocol (UDP) has become the mainstream transmission protocol in online gaming, real-time audio and video communication, video conferencing and live streaming, etc. due to its connectionless and low-overhead characteristics. Industry forecasts show that emerging application fields such as cloud gaming, VR / AR collaborative interaction, and industrial Internet of Things will further expand the application range of the UDP protocol in the future.

[0003] However, the popularity of the UDP protocol has also highlighted the issue of quality of service assurance, with user-perceptible lag seriously affecting the quality of experience (QoE). To optimize user experience, an effective lag detection mechanism needs to be established first, but the UDP protocol itself lacks the packet loss detection, retransmission and congestion control mechanisms that the Transmission Control Protocol (TCP) has, making it difficult to directly determine lag through traditional network quality indicators such as packet loss rate and end-to-end latency.

[0004] Some application layer protocols (such as QUIC, RTP / RTCP, etc.) implement custom reliability mechanisms on top of UDP, providing transmission quality monitoring functions similar to TCP. However, from the perspective of operating system and hardware vendors, the specific implementation of these upper-layer protocols is opaque, making it difficult to form a unified cross-application solution. Therefore, there is an urgent need to develop a UDP service lag evaluation method that is not dependent on specific upper-layer protocols and has universal applicability. SUMMARY

[0005] The present application provides a UDP service lag detection method, device, electronic equipment and storage medium to solve the defects of UDP service lag evaluation in universality and adaptability in the prior art.

[0006] The present application provides a UDP service lag detection method, comprising:

[0007] Obtaining a real-time mixed UDP stream based on five-tuple reorganization;

[0008] Based on the current service mode, the similarity between the number of packets of the current UDP stream and the average number of historical packets, or the proportion of the number of packets of the current UDP stream in the total number of packets, is applied to identify the core UDP stream to be tested from the real-time mixed UDP stream;

[0009] Adaptively calculate the key features of the to-be-tested core UDP flow under the current service mode based on a double sliding window algorithm;

[0010] Input the key features into a trained stall detection model for service stall detection, and obtain a detection result output by the stall detection model, which is trained based on sample core UDP flows and corresponding labels.

[0011] According to the UDP service stall detection method provided by the application, the real-time mixed UDP flow based on five-tuple reorganization is obtained, which comprises:

[0012] Filter the original network traffic based on the protocol type of the original network traffic to obtain original UDP traffic.

[0013] Reorganize the original UDP traffic according to five-tuple using a sliding time window to obtain the real-time mixed UDP flow.

[0014] According to the UDP service stall detection method provided by the application, after identifying the to-be-tested core UDP flow from the real-time mixed UDP flow, the method further comprises:

[0015] Monitor the number of received data packets per second of the to-be-tested core UDP flow.

[0016] If the number of packets does not meet the core UDP flow determination standard for a duration greater than a preset duration threshold, re-identify the to-be-tested core UDP flow.

[0017] According to the UDP service stall detection method provided by the application, the key features of the to-be-tested core UDP flow under the current service mode are adaptively calculated based on a double sliding window algorithm, which comprises:

[0018] Identify the current service mode using a long sliding window, calculate the feature mean value under the stable state of the current service mode, perform feature standardization and feature calculation based on the feature mean value, and obtain the key features.

[0019] Calculate the mean difference of the number of received packets per second in the long sliding window and the short sliding window, detect changes when the mean difference is greater than a preset threshold, and determine the feature mean value of the real-time updated service mode when the service mode is detected to switch.

[0020] According to the UDP service stall detection method provided by the application, when the service mode is detected to switch, the feature mean value of the real-time updated service mode is determined, which comprises:

[0021] When the service mode is detected to switch, reset the long sliding window to short sliding window data, update the feature mean value to the median of the current long sliding window, and calculate the feature mean value of the updated service mode after the data is stable.

[0022] According to the UDP service stall detection method provided by the application, the training step of the stall detection model comprises:

[0023] Obtaining a sample core UDP stream and labels corresponding to each time point;

[0024] Extracting key features of the sample core UDP stream based on feature engineering;

[0025] Inputting the key features into an initial model to obtain a prediction result output by the initial model;

[0026] When the prediction result is stall, determining the difference between the prediction result and the labels corresponding to the current time point and the adjacent time point; when the prediction result is smooth, determining the difference between the prediction result and the prediction result of the continuous forward time point of the current time point;

[0027] Training the initial model based on the difference to obtain the stall detection model.

[0028] According to the UDP service stall detection method provided by the application, the key features of the sample core UDP stream are extracted based on feature engineering, which comprises:

[0029] Extracting data stream features of the sample core UDP stream, and sequentially performing feature cleaning and standardization on the data stream features;

[0030] Performing feature construction based on the standardized data stream features to obtain construction features;

[0031] Based on the importance of each feature, key features are selected from the data stream features and the construction features, and the key features include a received packet abnormal interval length, a number of received packets per second, a flow active time period proportion, a packet size distribution kurtosis, and a target data packet proportion.

[0032] The application further provides a UDP service stall detection device, comprising:

[0033] A UDP stream acquisition unit is configured to acquire a real-time mixed UDP stream based on five-tuple recombination;

[0034] A UDP stream identification unit is configured to identify a to-be-tested core UDP stream from the real-time mixed UDP stream based on a current service mode, a similarity between a number of packets of the current UDP stream and a mean value of historical packet numbers, or a proportion of the number of packets of the current UDP stream in the number of all stream packets;

[0035] A feature calculation unit is configured to adaptively calculate key features of the to-be-tested core UDP stream under the current service mode based on a double sliding window algorithm;

[0036] The key features are input into a trained stall detection model for service stall detection, and a detection result output by the stall detection model is obtained, the stall detection model being trained based on a sample core UDP flow and a corresponding label thereof.

[0037] The application further provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the UDP service stall detection method according to any one of the above when executing the computer program.

[0038] The application further provides a non-transitory computer-readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the UDP service stall detection method according to any one of the above.

[0039] The application further provides a computer program product, which includes a computer program, and the computer program is executed by a processor to implement the UDP service stall detection method according to any one of the above.

[0040] The UDP service stall detection method, device, electronic device and storage medium provided by the application break through the limitations of the prior art by recombining UDP data streams in the mixed flow based on the five-tuple, specifically by dynamically determining the core flow by comparing the similarity of the current flow packet number and the historical average packet number, or the packet number ratio, rather than the protocol analysis method, and can support the UDP service (such as online game bare flow) without encapsulating the custom protocol, and solve the problem of lack of universality caused by protocol dependence in the traditional scheme. In addition, compared with the threshold rule method, the stall detection method by machine learning model fusion of multi-dimensional key features significantly improves the stall recognition accuracy. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the present application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0042] Figure 1 is one of the flow diagrams of the UDP service stall detection method provided by the application.

[0043] Figure 2 is a real-time mixed UDP flow acquisition flow diagram provided by the application.

[0044] Figure 3 is a double sliding window algorithm flow diagram provided by the application.

[0045] Figure 4 is a variation detection flowchart provided by the present application.

[0046] Figure 5 is a flowchart of a UDP service stutter detection method provided by the present application.

[0047] Figure 6 is a structural schematic diagram of a UDP service stutter detection device provided by the present application.

[0048] Figure 7 is a structural schematic diagram of an electronic device provided by the present application. DETAILED DESCRIPTION

[0049] In order to make the objectives, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be described clearly and completely below in combination with the drawings in the present application. Obviously, the described embodiments are some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0050] With the rapid development of Internet technology and the popularity of real-time interactive applications, users' requirements for network service quality (QoS) are continuously increasing, especially in application scenarios with high real-time requirements, such as video conferencing, online gaming, real-time audio and video communication, etc. These applications mostly use the User Datagram Protocol (UDP) as the transport layer protocol, mainly because UDP has the characteristics of connectionless and low delay, which can meet the strict requirements of real-time services on timeliness. However, the UDP protocol itself lacks reliability guarantee mechanisms and does not provide services such as packet retransmission and congestion control, which makes UDP services face many transmission quality problems in actual network environments, the most prominent of which is the "stutter" phenomenon that users can perceive.

[0051] The stutter problem manifests itself differently in various UDP services: in video call and live streaming scenarios, it manifests itself as a frozen picture or interrupted sound; in pure audio communication, it manifests itself as intermittent sound; and in online gaming scenarios, it can manifest itself as picture stuttering, abnormal sound, and operation feedback delay. These stuttering phenomena seriously affect user experience and can even cause the service to fail to proceed normally. Therefore, how to detect the stuttering situation of UDP services in real time and accurately has become a key technical problem for improving the service quality of real-time services.

[0052] Current mainstream UDP stutter detection methods mainly include two technical routes: network layer traffic feature analysis and user layer video frame analysis.

[0053] The first is a network layer traffic feature analysis method: the transmission layer feature parameters are extracted to realize the jitter judgment. In the TCP environment, the method can use sequence number, confirmation mechanism, round-trip time (RTT) and other rich protocol features to effectively evaluate the network state. For UDP protocol, existing research mainly analyzes specific upper layer protocols (such as negative acknowledgement frame of QUIC, reliability control mechanism of UDT, etc.) to enhance the feature extraction capability. The detection effect of this kind of method is highly dependent on the completeness of the upper layer protocol design, and its applicability is significantly limited in the case that the protocol information is not available or the protocol mechanism is missing.

[0054] As related technology one: based on UDT / QUIC traffic feature monitoring packet loss, this scheme designs a data structure similar to hash table for quickly extracting UDP traffic features, through which various traffic features of UDP service are extracted, including packet size, throughput, control frame proportion, etc. This scheme defaults the UDP upper layer protocol to UDT / QUIC, then selects the four features with the highest correlation for training the machine learning model, and finally uses the trained model for real-time monitoring system.

[0055] The disadvantage of this scheme is that the default UDP upper layer protocol is UDT / QUIC, which makes this scheme lack of universality and cannot be used for more extensive UDP services. At the same time, the record and use of timing features are lacking. The data structure used in this scheme only records the size and number of data packets, and does not record the time interval of data packets, and the timing features are not utilized. Finally, this scheme is designed based on routers and does not consider to specialize in processing each UDP service, but only monitors whether there is packet loss in the entire UDP stream passing through the router.

[0056] The second is a user layer video frame analysis method: based on computer vision technology, the video stream is decoded and the continuous frame sequence is analyzed in time domain to detect the jitter phenomenon. This method can accurately identify user-perceptible jitter events such as video picture stagnation by calculating frame difference, motion vector and other features. Although this direct measurement method based on QoE is not affected by the underlying transmission protocol, its application has obvious limitations: first, the method is only applicable to video services and cannot detect operation delay in pure audio services (such as voice calls) or interactive applications (such as cloud games); second, the video decoding and frame analysis process has high computational complexity, and it is difficult to realize real-time processing in resource-limited environments such as mobile terminals.

[0057] As the related technology two: based on the video dialing process screen recording frame freezing perception intelligent identification scheme, the scheme is through the computer automatic program to the screen recording file frame processing, using the HSV color model combined with gradient operation extracts the freezing feature, and through the convolution neural network for identification and test, finally can realize the intelligent identification of the frame image. The scheme also adds the anti-misjudgment algorithm for continuous sampling frame, determines the final result through the freezing probability of continuous frame, improves the recognition accuracy. The scheme successfully solves the freezing identification of online video service, and also has reference significance for video live broadcast and remote conference service.

[0058] The disadvantage of the scheme is that it is limited to video or live broadcast service, and cannot be applied to audio call and online game services. Among them, the audio call cannot be judged whether it is frozen through the video screen, and the freezing condition of the online game, such as abnormal user interaction, cannot be judged through the screen. In addition, the model of the scheme is relatively complex, and a lot of memory and operation resources are occupied during detection, which is not conducive to real-time detection on mobile terminals.

[0059] In view of the above problems, the embodiment of the present application provides a UDP service freezing detection method, in which, first, a real-time mixed UDP stream based on five-tuple reorganization is obtained; based on the current service mode, the similarity between the number of packets of the current UDP stream and the average number of historical packets, or the proportion of the number of packets of the current UDP stream in the number of all stream packets, is applied to identify the to-be-tested core UDP stream from the real-time mixed UDP stream; the key features of the to-be-tested core UDP stream under the current service mode are adaptively calculated based on a double sliding window algorithm; the key features are input into a trained freezing detection model for service freezing detection, and a detection result output by the freezing detection model is obtained, and the freezing detection model is trained based on sample core UDP streams and corresponding labels.

[0060] The method provided by the embodiment of the present application does not depend on specific upper layer protocol extension, and realizes cross-application general detection based on UDP transport layer observable features, realizes protocol-independent detection mechanism; has multi-modal freezing identification capability, breaks through the limitation of traditional video analysis, and supports multi-dimensional user experience index evaluation such as audio freezing and interaction delay; in addition, a low-complexity feature extraction and classification algorithm is designed to ensure that the execution efficiency on the terminal device meets the real-time requirement.

[0061] The present application is particularly suitable for the following typical scenarios: (1) operating system level network service quality monitoring, in which upper layer protocol information cannot be obtained; (2) freezing detection of non-video UDP services (such as voice communication and real-time games); (3) real-time quality evaluation demand in resource limited environment. By establishing a standardized UDP service freezing detection framework, the present application will provide basic technical support for improving the user experience of real-time interactive applications.

[0062] The execution subject of the method can be a terminal device, a computer, a server, a server cluster, or a specially designed UDP service stall detection device, etc. electronic device, or a UDP service stall detection device provided in the electronic device. The device can be realized by software, hardware, or a combination of both.

[0063] Figure 1 is one of the flow diagrams of the UDP service stall detection method provided by the application, as shown in Figure 1 The method comprises the following steps:

[0064] Step 110, acquiring real-time mixed UDP flow based on five-tuple reorganization;

[0065] Step 120, based on the current service mode, applying the similarity between the number of packets of the current UDP flow and the average number of historical packets, or applying the proportion of the number of packets of the current UDP flow to the number of all flow packets, to identify the to-be-tested core UDP flow from the real-time mixed UDP flow.

[0066] Specifically, considering that UDP services cover a wide range, especially when a single terminal runs multiple UDP services at the same time, the prior art often has difficulty in distinguishing the traffic characteristics of different services, resulting in a decrease in detection accuracy.

[0067] In this embodiment, the core UDP service flow is first accurately identified from the mixed traffic of the terminal application, and the continuous tracking of the core service flow is realized. For core UDP flow identification, multi-level traffic feature analysis and context association are realized. Specifically, first, the real-time mixed UDP flow is acquired, and then the to-be-tested core UDP flow is identified from the real-time mixed UDP flow.

[0068] In some embodiments, the real-time mixed UDP flow based on five-tuple reorganization is acquired, comprising:

[0069] Step 111, filtering the original network traffic based on the protocol type of the original network traffic to obtain original UDP traffic;

[0070] Step 112, reorganizing the original UDP traffic according to five-tuple by using a sliding time window to obtain real-time mixed UDP flow.

[0071] Specifically, please refer to Figure 2 , Figure 2is a real-time mixed UDP stream acquisition process schematic diagram provided by the application. Here, the original network traffic refers to a set of unprocessed binary data packets directly captured from a network interface (such as a network card or a router), containing all protocol types (such as TCP, UDP, ICMP, etc.). After filtering the original network traffic by protocol type, separating all UDP traffic, and filtering out known auxiliary service ports, only the UDP protocol packets are retained, i.e., the original UDP traffic is obtained.

[0072] Then, a sliding time window is used to recombine the network packets into sessions, and the packet sequence of the same quintuple is combined into a logical stream. The quintuple is a unique identifier of network traffic, used to distinguish different network connections. The quintuple includes the source IP address, the destination IP address, the source port number, the destination port number, and the transport layer protocol type.

[0073] The structured stream data output after quintuple recombination is the real-time mixed UDP stream. The real-time mixed UDP stream refers to a standardized UDP stream record set generated after protocol filtering and session recombination, each record containing complete session metadata such as quintuple, packet sequence characteristics, time window marker, and pointer index of the original load. The real-time mixed UDP stream may contain multiple concurrent UDP service streams, such as video, voice, and games.

[0074] Then, step 120 is performed, based on the current service mode, to identify the core UDP stream to be tested from the real-time mixed UDP stream by applying the similarity between the current packet quantity and the historical packet quantity average of the current UDP stream, or by applying the proportion of the current UDP stream packet quantity to the total flow packet quantity.

[0075] Specifically, the core UDP stream to be tested is the target service stream selected from the mixed stream, aiming to exclude background traffic interference and focus on core services. The core UDP stream to be tested needs to meet one of the following conditions:

[0076] Packet quantity similarity: the similarity between the current packet quantity and the historical average is within a preset range;

[0077] Traffic proportion: the proportion of the current flow packet quantity to the total traffic exceeds a preset proportion threshold. It should be noted that the preset range and the preset proportion threshold can be flexibly adjusted according to actual conditions.

[0078] In the core stream identification stage, different identification methods are used for different service modes. For example, different modes are used for game services and other non-game services (audio and video calls, multi-person conferences, and live broadcasts, etc.).

[0079] In the game service, the packet quantity of the voice service stream accounts for a large proportion, and is not the core stream, so the core stream needs to be identified by the similarity with the historical packet quantity average value. The historical packet quantity average value of each time unit is calculated through offline data A sliding window with a time width of e is further established, and the packet quantity in the window at the current time t is calculated in real time According to the calculation result of the similarity formula, if the result is negative or between 0 and 0.9, it can be determined that it is not a core service stream, and if the result is between 0.9 and 1, it can be determined to be a core service stream. The similarity formula is as follows:

[0080] (1)

[0081] In the non-game service such as audio and video call, multi-person conference and live broadcast, the proportion of the packet quantity of the core service stream to the packet quantity of all streams is high, and the core stream can be directly identified by calculating the proportion of the packet quantity of the service stream to the packet quantity of all streams. If the proportion is greater than 90%, the service stream is considered to be a core service stream.

[0082] In other embodiments, after the to-be-tested core UDP stream is identified from the real-time mixed UDP stream, the method further comprises:

[0083] monitoring the number of received data packets per second of the to-be-tested core UDP stream;

[0084] If the packet quantity does not meet the core UDP stream determination standard for a duration greater than a preset duration threshold, the to-be-tested core UDP stream is re-identified.

[0085] Specifically, in order to further improve the accuracy of core UDP stream identification, the embodiment continuously monitors the stability of the identified stream characteristics. When it is detected that the selected characteristic index, the number of received data packets per second N, does not meet the core stream UDP determination standard for several seconds, the system will automatically trigger the re-evaluation process.

[0086] After the to-be-tested core UDP stream is identified, the key features of the to-be-tested core UDP stream can be further extracted. Considering that in the process of real-time detection of lag, the data is real-time, the future data cannot be predicted, and the business mode may be changing and unknown, therefore, it is necessary to be able to adaptively measure the data feature average value of the current business mode. The embodiment adaptively calculates the key features of the to-be-tested core UDP stream under the current business mode based on a double sliding window algorithm.

[0087] Step 130, adaptively calculating the key features of the to-be-tested core UDP stream under the current business mode based on a double sliding window algorithm.

[0088] Specifically, the dual sliding window algorithm is an adaptive algorithm composed of a long sliding window and a short sliding window. The long sliding window is used to calculate the mean of features in a steady state, such as the average packet interval. The short sliding window is used to detect sudden anomalies, such as a sudden drop in the number of packets. The key features here can be features selected during the model training phase, and specifically include: the length of the abnormal interval of received packets, the number of packets received per second, the proportion of active flow periods, the kurtosis of the packet size distribution, and the proportion of target data packets.

[0089] In some embodiments, step 130 specifically includes:

[0090] Step 131: Use a long sliding window to identify the current business mode and calculate the feature mean under the stable state of the current business mode. Based on the feature mean, perform feature standardization and feature calculation to obtain key features;

[0091] Step 132: Calculate the average difference in the number of packets received per second within the long sliding window and the short sliding window. When the average difference is greater than a preset threshold, perform change detection. When a service mode switch is detected, determine the characteristic average of the service mode that is updated in real time.

[0092] Specifically, please see Figure 3 , Figure 3 This is a flowchart of the dual sliding window algorithm provided by this invention. The long sliding window identifies the current business mode and calculates the mean feature value under stable conditions. The short sliding window distinguishes between business mode switching and network congestion events, outputting the real-time updated mean feature value of the business mode for further standardization and key feature calculation. It should be noted that the network congestion judgment here is only a rough assessment, used only to distinguish it from business mode switching, and does not represent the final output result.

[0093] When the algorithm runs, it first initializes the parameters. There are five initial parameters in total, as shown in Table 1 below:

[0094] Table 1 Initialization Parameter Table

[0095]

[0096] The dual sliding window algorithm needs to calculate two feature means: the average number of packets received per second. and average package size The number of packets received per second It is more stable, therefore it was selected as the detection feature.

[0097] When performing change detection using a short sliding window, continuous detection is performed. Changes, when Mean within the short window The mean within the long window There is a significant difference, and the judgment criteria are as follows:

[0098] (2)

[0099] At this time, the change detection process is triggered, please refer to Figure 4 , Figure 4 is the change detection process provided by the application.

[0100] When the service mode switching is detected, the long sliding window is reset to the short sliding window data, and the median is used instead of the mean, and the absolute deviation of the median is used instead of the variance, and the background mean is updated to the long sliding window median, because at this time the data is less, the median is less affected by the abnormal value. When the data in the long sliding window exceeds half of its length, it is restored to the mean and variance.

[0101] When new data normally arrives and no service mode switching occurs, the update strategy of the background mean is as follows:

[0102] (3)

[0103] wherein is the learning rate, which can be set as needed, such as 0.05.

[0104] Step 140, input the key features into the trained stuttering detection model for service stuttering detection, and obtain the detection result output by the stuttering detection model. The stuttering detection model is trained based on the sample core UDP stream and its corresponding label.

[0105] Specifically, after the to-be-tested core UDP stream is identified and the key features are calculated, the key features are input into the trained stuttering detection model for service stuttering detection, and whether the current is stuttering is output (output 1 represents stuttering, and 0 represents smooth). When the output is 1, stuttering alarm is performed, and when three consecutive seconds are 0, it indicates that the current stuttering is over. When the stuttering lasts for three seconds or more, it is marked as serious stuttering.

[0106] It can be understood that before the real-time UDP stream is detected for stuttering, the stuttering detection model can be obtained through model training. The stuttering detection model is trained based on the sample core UDP stream and its corresponding label.

[0107] The sample core UDP stream can be an offline non-real-time data stream, and the core UDP stream is selected from the captured packet file as the sample core UDP stream. The corresponding label can be obtained by manual annotation according to the screen recording file, such as the position of the picture, sound or interaction stuttering in the screen recording file.

[0108] In some embodiments, the training steps of the stuttering detection model include:

[0109] Obtain the sample core UDP stream and the corresponding label at each time;

[0110] extract key features of the sample core UDP flow based on feature engineering;

[0111] input the key features into the initial model to obtain a prediction result output by the initial model;

[0112] when the prediction result is freezing, determine a difference between the prediction result and a label corresponding to the current time and an adjacent time; when the prediction result is smooth, determine a difference between the prediction result and a prediction result of a continuous forward time of the current time;

[0113] based on the difference, train the initial model to obtain a freezing detection model.

[0114] In this embodiment, after obtaining the sample core UDP flow and the labels corresponding to each time, key features of the sample core UDP flow are extracted based on feature engineering. Feature engineering is a crucial link in the machine learning process, which refers to the process of converting raw data into features (i.e., model input variables) that can better represent the essence of the problem through data analysis and conversion. The goal is to improve the performance (such as accuracy, generalization ability) and efficiency of the model.

[0115] In some embodiments, the extraction of key features specifically includes:

[0116] extracting data stream features of the sample core UDP flow, and sequentially performing feature cleaning and standardization on the data stream features;

[0117] performing feature construction based on the standardized data stream features to obtain constructed features;

[0118] based on the importance of each feature, selecting key features from the data stream features and the constructed features, the key features including a received packet abnormal interval length, a number of received packets per second, a flow active time period proportion, a packet size distribution kurtosis, and a target data packet proportion.

[0119] Specifically, the data stream feature categories of the sample core UDP flow can include packet number features, packet size features, packet timing features, and extreme value features. Each feature is divided into two directions, receiving and sending, and the features are counted in units of one second. Table 2 shows the data stream feature table.

[0120] Table 2 UDP data stream feature table

[0121]

[0122] Then, the data stream features are sequentially cleaned and standardized.

[0123] Feature cleaning

[0124] The features are calculated from the captured packet file statistics, so there are no missing values, and the outliers are the targets of the detection of the application. However, some services have a service preparation phase with a huge difference in traffic characteristics from the normal process of the service, and these two phases are easily misjudged as abnormal, for example, waiting for the loading of the map, character and other models before the game starts, waiting for other players to load, and the like. Therefore, before model training, the part of data needs to be removed to avoid affecting the training result and improve the accuracy of the model.

[0125] There is no universal and accurate method for identifying the service preparation phase, and the embodiments of the application use a combination of multiple methods:

[0126] (1) For the case where there is obvious handshake data packet of the upper layer protocol, specific data packets such as the Initial packet of QUIC can be identified;

[0127] (2) For the service with a relatively stable preparation duration, the preparation duration of several seconds before the formal start of the service can be directly removed;

[0128] (3) In the case where the above two conditions are not met, whether the several key characteristics of the core UDP stream are close to the historical mean can be judged by using the confidence interval.

[0129] Feature standardization

[0130] The main purpose of feature standardization in this embodiment is to eliminate the dimension. Mean normalization is adopted, mainly to perform mean normalization on the average number of sent and received packets per second, the average number of sent and received bytes per second, and the average packet size per second, and the purpose is to retain the proportional relationship of the original data. The calculation formula of the mean normalization is as follows, wherein represents the mean, represents the data stream feature before standardization, represents the data stream feature after standardization:

[0131] (4)

[0132] Then, feature construction is performed based on the standardized data stream feature to obtain the constructed feature. To further reflect the correlation between the feature and the lag, the embodiments of the application construct the following features, as shown in Table 3:

[0133] Table 3: Constructed feature and calculation method table

[0134]

[0135] In the formula, is the length of the abnormal interval, is the interval between the sent and received packets at the moment, is the interval between the sent and received packets at the moment, and is​ the interval of the transceiving packet at the moment, the average interval of the transceiving packet, the number of packets, the proportion of the flow active time period, the kurtosis of the packet size distribution, the packet size sequence, the average packet size, the proportion of the transceiving packet number, the number of sending packets, the number of receiving packets, the proportion of the transceiving packet byte number, the byte number of sending packets, the byte number of receiving packets, the proportion of small packets with byte number less than 64B, the number of small packets with byte number less than 64B.

[0136] Then, based on the importance of each feature, the key features are selected from the data stream features and the constructed features. The feature selection aims to filter the features most useful for predicting the target variable, reducing overfitting and noise. The importance of each feature is calculated by the tree model, and the top five features with the highest importance are selected, as shown in Table 4 below, wherein the number of received packets per second needs to be mean standardized, and the remaining features do not need to be standardized:

[0137] Table 4 Key Feature Table of UDP Data Stream

[0138]

[0139] After obtaining the key features, the model is trained based on the key features. The present application manually annotates by manually comparing the screen recording files, and uses a binary classification machine learning model (random forest, XGBoost, etc.) for supervised training.

[0140] Since the labels of lag / smooth have certain continuity and local consistency, i.e. the labels of adjacent samples are often the same and not completely random, on the one hand, the data is continuous in time, and each lag often lasts more than one second. On the other hand, when manually annotating, the annotator tends to give the same label to consecutive samples. For example, if the actual network status is different for the first two seconds and the last two seconds, and the network status is good for the middle two seconds, the annotator will often consider that the six seconds are all lag.

[0141] When the data label has the above characteristics, a "loose accuracy" can be used for evaluation and training. The "loose accuracy" means that the model prediction result is not only compared with the current sample label, but also compared with the corresponding label at the adjacent time. The adjacent time here can be the previous few adjacent times of the current time, and the latter few adjacent times, and the embodiments of the present application do not make specific limitations. For example, the label of the last three seconds is compared, and the specific method is as follows:

[0142] When the prediction result is 1, as long as one of the three seconds [t-1, t+1] has a label of 1, it means that the evaluation is correct, that is, the evaluation allows one second of jitter time deviation, and the result is as follows:

[0143] (5)

[0144] When the prediction result is 0, only when the previous n consecutive seconds of jitter are all evaluated as 0, it is considered that the evaluation is wrong, that is, the entire jitter event is completely unable to be recognized, and the rest is considered to be correct. The result is as follows, where n represents the value of the previous n consecutive labels of 1:

[0145] (6)

[0146] The advantage of using "loose accuracy" for evaluation is to pay more attention to whether the model can capture the overall pattern change, rather than demanding accurate evaluation at each time point. That is, more attention is paid to whether the occurrence of the jitter event can be captured, rather than accurately judging whether each time point is jitter. On the one hand, this can preserve the characteristic that the network layer UDP flow anomaly occurs earlier than the user perceives the jitter, and can capture the jitter event more timely. On the other hand, the network layer and the user layer are not completely synchronized in time, and demanding accurate evaluation at each time point will lead to overfitting of the model.

[0147] It can be understood that the jitter detection model trained according to the method described in the above embodiments can be used for UDP service jitter detection.

[0148] Based on any of the above embodiments, the applicant found during long-term research that the current technical solutions for UDP service jitter detection mainly face the following challenges and limitations:

[0149] 1. Detection complexity caused by the diversity of service types

[0150] UDP services cover a wide range of applications, including but not limited to video calls, audio conferences, live streaming, online games, and other types. These services differ significantly in data transmission mode, traffic characteristics, and stuttering performance. Traditional detection methods based on fixed thresholds are difficult to adapt to this diversity, while customized detection solutions for specific service types lack generality and cannot form a unified solution. In particular, when a single terminal runs multiple UDP services simultaneously, existing technologies often struggle to distinguish the traffic characteristics of different services, resulting in decreased detection accuracy.

[0151] 2. Conflict between real-time requirements and computational resource limitations

[0152] Most UDP services are extremely sensitive to delay, such as video calls that typically require end-to-end delay to be less than 400ms, and online games that require even stricter delay limits of 100-200ms. This requires the stuttering detection algorithm to complete analysis and judgment within a very short time, while also considering the computational resource limitations of terminal devices. Existing detection methods based on video frame analysis can provide relatively accurate results, but their high computational complexity and large memory usage make it difficult to implement real-time processing on ordinary terminal devices, especially in resource-constrained environments such as mobile terminals.

[0153] 3. Detection difficulties caused by UDP protocol characteristics

[0154] Unlike TCP protocol, UDP protocol itself does not provide network quality indicators such as packet loss, retransmission, and delay, making it difficult to directly apply detection methods based on inherent protocol characteristics. The characteristic information of UDP data flow is relatively scarce, and traditional network quality evaluation methods such as packet loss rate and round-trip time (RTT) are often unavailable or inaccurate in the UDP environment. In addition, the burstiness and irregularity of UDP traffic also increase the difficulty of feature extraction and analysis.

[0155] 4. Challenges of dynamic service changes to detection models

[0156] Modern UDP applications are usually highly dynamic, and service models will change significantly with application state changes. For example, video and audio-only modes may be switched in audio-video calls; participants may join or leave during multi-person conference scenarios; players may turn on or off voice functions at any time in game applications; and software version updates may change data transmission modes. These changes can cause traffic characteristics to change abruptly, causing the detection model based on static features to have a sharp drop in accuracy, resulting in a large number of false positives or false negatives.

[0157] To address the above technical challenges, the embodiments of the present application aim to solve the following core problems:

[0158] (1) How to build a unified stall detection framework suitable for multiple UDP services: Research detection methods that can cross different service types and extract common features to solve the generalization problem caused by service diversity.

[0159] (2) How to achieve accurate stall judgment under limited feature conditions: In view of the characteristics of UDP data stream features, research deep feature extraction technology to mine potential features related to stall from limited network layer and transport layer information.

[0160] (3) How to realize low-overhead real-time detection algorithm: Design a lightweight feature extraction and model inference architecture to ensure real-time requirements under limited computing resources of terminal devices, and solve the contradiction between detection delay and computing complexity.

[0161] (4) How to adapt to the dynamic changes of business models: Research model adaptation technology to enable the detection system to adapt to the mutation of business traffic characteristics without interrupting service, and maintain detection accuracy.

[0162] Therefore, the embodiment provides a stall detection method, which fully utilizes the traffic characteristics of UDP services, discovers general features under different services and different modes, and then trains based on a binary classification model, and finally applies it to real-time detection.

[0163] Please refer to Figure 5 , Figure 5 is a flowchart of the UDP service stall detection method provided by the application, as shown in Figure 5 , the embodiment of the application is divided into two parts: offline training and online detection. The upper half of the figure is the offline training stage, the core UDP stream is manually selected from the captured data packet file, and then feature engineering is performed, including feature extraction, data cleaning, feature transformation, feature construction, key feature selection and other steps, then the screen recording file is manually labeled (the position of the picture, sound or interaction stall in the screen recording file is labeled), and finally the classification model (the data of stall and non-stall is classified) is obtained through model training.

[0164] The feature engineering specifically includes: firstly, extracting original features, including bidirectional features such as the number of transceiving packets per second, byte amount, small packet number, packet size sequence, and packet interval sequence. Then, feature cleaning is performed, and abnormal data is removed through three methods for the business preparation stage (such as game loading): (1) detecting upper-layer protocol handshake packets (such as the Initial packet of QUIC); (2) directly removing the first N seconds of data for stable business; and (3) using a 95% confidence interval to compare the key features with the historical mean. Then, feature transformation is performed: the mean value normalization is performed on the transceiving packet number, byte amount, and average packet size. Further, new features are constructed, including packet interval abnormal length, flow active proportion, and packet size kurtosis. Finally, the tree model is used to screen key features, and the top 5 features in terms of importance are selected for model training.

[0165] In the training stage, firstly, the data is labeled: based on the synchronous screen recording file, the core UDP stream data per second is manually labeled as stuttering (1) or smooth (0). The labeled key feature dataset is generated. The random forest model is selected, and the training / test set is divided according to 7:3 to optimize the parameters. The "loose accuracy" evaluation strategy is adopted: when predicting stuttering, if there is at least 1 second of real stuttering within [t-1, t+1] three seconds, it is judged to be correct; when predicting smooth, it is only judged to be wrong when a continuous stuttering event is completely missed. The test shows that the overall loose accuracy is 94.5%, and the recall rate is 97.7%. Finally, the model is solidified and deployed to the real-time detection process, and the normalized 5-dimensional feature vector is used to output the stuttering state in real time.

[0166] Figure 5 The real-time detection and training process in the lower half are slightly different, and a core UDP stream recognition module and a double sliding window algorithm module are added, wherein the core UDP stream recognition module is used to automatically identify the core UDP stream according to the real-time mixed UDP stream.

[0167] Firstly, the traffic preprocessing is performed: after the system captures the original network traffic, the non-UDP data packets are filtered, and the known auxiliary service ports (such as DNS port 53) are removed. The sliding time window is used to reorganize the data packets according to the five-tuple (source IP, source port, destination IP, destination port, and protocol), and the structured stream data containing session metadata and original load index are generated.

[0168] Then, the core stream recognition is performed: for non-game business (such as audio and video calls), the proportion of the target UDP stream packet number to the total amount of all stream packets is calculated, and if it exceeds 90%, it is determined as the core business stream; for game business, the historical mean similarity is calculated through the packet number similarity formula, and if the matching value is between 0.9 and 1, it is determined as the core stream.

[0169] Finally, the dynamic verification is started: the feature indicators (such as the number of received packets per second) of the core stream are continuously monitored, and if they do not meet the determination standard (such as the packet proportion <80%) for 3 seconds in a row, the stream recognition process is triggered again.

[0170] The double sliding window algorithm module is used to identify the conversion of the service mode (such as the conversion from WeChat video call to audio call) and to calculate the mean value of the data features in the current window in real time, so as to normalize the data features.

[0171] The initialization parameters are: long window (default 300 seconds), short window (default 5 seconds), mode switching threshold m (continuous 3 short windows to confirm switching), and stuttering threshold (60% drop). The number of packets received per second is selected as the detection feature (because it is the most stable). During normal operation, the long and short windows are synchronously updated with data and the mean value is calculated, and the background mean value is updated with a learning rate of a = 0.05. When the short window mean value is significantly deviated from the long window mean value, change detection is triggered: if the fluctuation lasts for three short windows and does not exceed the stuttering threshold, it is determined that the service mode is switched, otherwise it is determined that the network is stuttering; if it is determined that the service mode is switched (such as video to audio), the long window is reset to the short window data, and the switching statistics are the median and the median absolute deviation (MAD), and the mean value calculation is restored after the long window data is more than half. The background mean value is updated synchronously to the median of the current long window.

[0172] The real-time detection process only needs to calculate the key features selected in the training process, and input them into the classification model to output whether it is stuttering or not (output 1 represents stuttering, and 0 represents smooth). When the output is 1, stuttering alarm is performed, and when three seconds in a row are 0, it indicates that the current stuttering is over. When stuttering lasts for three seconds or more, it is marked as serious stuttering.

[0173] The above scheme is tested for various services, and the results are shown in Table 5:

[0174] Table 5 Test Results

[0175]

[0176] It can be seen that the present application has 94.5% accuracy and 97.7% recall rate when tested on a small-scale data set, and the average recognition speed is only -0.07 seconds. Here, the negative number is because the network layer anomaly occurs earlier than the user layer, that is, the UDP flow has already appeared abnormally before the user perceives the stuttering. Therefore, the present application can accurately and in real time evaluate the stuttering condition. Compared with the prior art, the present application embodiment has the beneficial effects including:

[0177] 1. Protocol-independent core flow identification mechanism

[0178] The application provides a core UDP service flow identification method independent of specific upper-layer protocols (such as QUIC / UDT). The technical core is that: based on the five-tuple (source IP, source port, destination IP, destination port, protocol) reorganization of the UDP data flow in the mixed flow, the core service flow is distinguished by packet quantity similarity calculation (rather than protocol analysis). Specifically, the core flow is dynamically determined by comparing the similarity of the current flow packet number with the historical average value. This mechanism breaks through the limitations of the prior art and can natively support UDP services (such as online game bare flow) that are not encapsulated with custom protocols, solving the problem of lack of universality caused by protocol dependence in traditional solutions.

[0179] 2、Dual sliding window adaptive algorithm

[0180] In view of the traffic feature mutation caused by service dynamic switching (such as video call to pure audio), the application designs a dual sliding window adaptive algorithm. The innovation is embodied in that: (1) the long window continuously tracks the steady-state service mode and calculates the feature reference average value; (2) the short window real-time detects the feature fluctuation, and when the short window average value and the long window average value significantly deviate, the service mode switching judgment process is triggered; (3) an anti-interference mechanism is adopted: the median is used to replace the average value as the normalization reference when switching, avoiding the interference of abnormal values, and the average value calculation is restored after the data is stable.

[0181] 3、Lightweight real-time detection architecture

[0182] In order to realize low-overhead real-time detection of terminal equipment, the application constructs a lightweight real-time detection architecture: only 5 key features are reserved as model inputs after tree model screening, reducing the feature dimension; a “loose accuracy rate” is used for evaluation, which retains the characteristic that the network layer UDP flow anomaly occurs earlier than the user perceives the lag time, can capture the lag event more timely, and avoids model overfitting.

[0183] The UDP service lag detection device provided by the application is described below, and the UDP service lag detection device described below can be correspondingly referred to the UDP service lag detection method described above.

[0184] Based on any of the above embodiments, Figure 6 is a structural schematic diagram of the UDP service lag detection device provided by the application, as Figure 6 shown, the device comprises:

[0185] The UDP stream acquisition unit 610 is configured to acquire a real-time mixed UDP stream reorganized based on a five-tuple.

[0186] The UDP flow recognition unit 620 is configured to recognize a to-be-tested core UDP flow from the real-time mixed UDP flow based on a current service mode, similarity between a number of packets of the current UDP flow and a mean value of historical packet numbers, or a proportion of the number of packets of the current UDP flow in numbers of packets of all flows.

[0187] The feature calculation unit 630 is configured to adaptively calculate a key feature of the to-be-tested core UDP flow in the current service mode based on a double sliding window algorithm.

[0188] The freezing detection unit 640 is configured to input the key feature into a trained freezing detection model for service freezing detection, to obtain a detection result output by the freezing detection model, and the freezing detection model is trained based on sample core UDP flows and corresponding labels.

[0189] According to any one of the above embodiments, the UDP flow acquisition unit is specifically configured to:

[0190] Filter the original network traffic based on a protocol type of the original network traffic to obtain original UDP traffic.

[0191] Recombine sessions of the original UDP traffic according to five tuples by using a sliding time window to obtain the real-time mixed UDP flow.

[0192] According to any one of the above embodiments, the monitoring unit is further configured to:

[0193] Monitor a number of received packets per second of the to-be-tested core UDP flow.

[0194] If the number of packets does not satisfy a core UDP flow determination criterion for a duration greater than a preset duration threshold, the to-be-tested core UDP flow is re-recognized.

[0195] According to any one of the above embodiments, the feature calculation unit is specifically configured to:

[0196] Identify a current service mode by using a long sliding window, calculate a mean value of features in a stable state of the current service mode, perform feature standardization and feature calculation based on the mean value of features to obtain the key feature.

[0197] Calculate a mean difference of numbers of received packets per second in the long sliding window and the short sliding window, perform change detection when the mean difference is greater than a preset threshold, and determine a mean value of features of a real-time updated service mode when a service mode switching is detected.

[0198] According to any one of the above embodiments, the feature calculation unit is specifically configured to:

[0199] When detecting the service mode switching, resetting the long sliding window to the short sliding window data, updating the feature mean to the median of the current long sliding window, and calculating the feature mean of the updated service mode after the data is stable.

[0200] Based on any of the above embodiments, further comprising a model training unit for:

[0201] Obtaining a sample core UDP stream and corresponding labels at each time point;

[0202] Based on feature engineering, extracting key features of the sample core UDP stream;

[0203] Inputting the key features into an initial model to obtain a prediction result output by the initial model;

[0204] When the prediction result is stuttering, determining the difference between the prediction result and the corresponding labels at the current time point and the adjacent time point; when the prediction result is smooth, determining the difference between the prediction result and the prediction result of the continuous forward time point of the current time point;

[0205] Based on the difference, training the initial model to obtain the stuttering detection model.

[0206] Based on any of the above embodiments, the model training unit is specifically configured to:

[0207] Extracting data stream features of the sample core UDP stream, and sequentially performing feature cleaning and standardization on the data stream features;

[0208] Based on the standardized data stream features, performing feature construction to obtain constructed features;

[0209] Based on the importance of each feature, selecting key features from the data stream features and the constructed features, the key features including received packet abnormal interval length, number of received packets per second, flow active time period proportion, packet size distribution kurtosis, and target data packet proportion.

[0210] Figure 7 An example of an entity structure diagram of an electronic device is shown in FIG. 1. Figure 7As shown, the electronic device can include a processor 710, a communications interface 720, a memory 730, and a communications bus 740, wherein the processor 710, the communications interface 720, and the memory 730 complete mutual communication through the communications bus 740. The processor 710 can invoke a logic instruction in the memory 730 to execute a UDP service lag detection method, which includes: obtaining a real-time mixed UDP stream based on five-tuple reorganization; based on a current service mode, applying similarity between a packet number of a current UDP stream and a historical packet number average, or applying a proportion of the packet number of the current UDP stream in all stream packet numbers, to identify a to-be-tested core UDP stream from the real-time mixed UDP stream; adaptively calculating a key feature of the to-be-tested core UDP stream under the current service mode based on a double sliding window algorithm; inputting the key feature into a trained lag detection model for service lag detection to obtain a detection result output by the lag detection model, the lag detection model being trained based on a sample core UDP stream and a corresponding label thereof.

[0211] In addition, the logic instruction in the memory 730 described above can be implemented in the form of a software functional unit and sold or used as an independent product, and can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various program code storage media.

[0212] In another aspect, the present application also provides a computer program product comprising a computer program, which can be stored on a non-transitory computer readable storage medium, and the computer program can be executed by a processor to enable a computer to perform the UDP service stall detection method provided by the above-mentioned methods. The method comprises: obtaining real-time mixed UDP streams based on five-tuple reorganization; identifying a to-be-tested core UDP stream from the real-time mixed UDP streams based on a current service mode, similarity between a number of packets of a current UDP stream and a historical average number of packets, or a proportion of the number of packets of the current UDP stream in a number of packets of all streams; adaptively calculating a key feature of the to-be-tested core UDP stream under the current service mode based on a double sliding window algorithm; inputting the key feature into a trained stall detection model for service stall detection to obtain a detection result output by the stall detection model, wherein the stall detection model is trained based on sample core UDP streams and corresponding labels thereof.

[0213] In yet another aspect, the present application also provides a non-transitory computer readable storage medium having a computer program stored thereon, and the computer program can be executed by a processor to implement the UDP service stall detection method provided by the above-mentioned methods. The method comprises: obtaining real-time mixed UDP streams based on five-tuple reorganization; identifying a to-be-tested core UDP stream from the real-time mixed UDP streams based on a current service mode, similarity between a number of packets of a current UDP stream and a historical average number of packets, or a proportion of the number of packets of the current UDP stream in a number of packets of all streams; adaptively calculating a key feature of the to-be-tested core UDP stream under the current service mode based on a double sliding window algorithm; inputting the key feature into a trained stall detection model for service stall detection to obtain a detection result output by the stall detection model, wherein the stall detection model is trained based on sample core UDP streams and corresponding labels thereof.

[0214] The apparatus embodiments described above are merely illustrative, wherein the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., they can be located in one place, or distributed on multiple network units. Part or all of the modules can be selected to achieve the purpose of the present embodiment scheme according to actual needs. Those skilled in the art can understand and implement it without creative labor.

[0215] Those skilled in the art can clearly understand the technical solutions of the various embodiments from the above description of the embodiments, and the various embodiments can be implemented by means of software with the necessary general hardware platforms, and of course, can also be implemented by hardware. Based on such understanding, the above technical solutions, essentially or in other words, the part of the prior art that makes a contribution, can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, and the like, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0216] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some technical features therein; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for detecting UDP traffic congestion, the method comprising: The method comprises the following steps: obtaining real-time mixed UDP streams based on five-tuple reorganization; based on the current service mode, applying the similarity between the number of packets of the current UDP stream and the average number of historical packets, or applying the proportion of the number of packets of the current UDP stream in the number of packets of all streams, to identify the to-be-tested core UDP stream from the real-time mixed UDP stream; adaptively calculating the key features of the to-be-tested core UDP stream under the current service mode based on a double sliding window algorithm; inputting the key features into a trained stall detection model for service stall detection to obtain a detection result output by the stall detection model, wherein the stall detection model is trained based on sample core UDP streams and corresponding labels; the adaptively calculating the key features of the to-be-tested core UDP stream under the current service mode based on the double sliding window algorithm comprises: using a long sliding window to identify the current service mode, calculating the feature mean value under the stable state of the current service mode, performing feature standardization and feature calculation based on the feature mean value, and obtaining the key features; calculating the mean difference of the number of received packets per second in the long sliding window and the short sliding window, detecting changes when the mean difference is greater than a preset threshold, and determining the feature mean value of the real-time updated service mode when the service mode is detected to switch; the training steps of the stall detection model comprise: obtaining sample core UDP streams and corresponding labels at each time; extracting the key features of the sample core UDP streams, wherein the key features include received packet abnormal interval length, number of received packets per second, flow active time period proportion, packet size distribution kurtosis, and target data packet proportion; inputting the key features into an initial model to obtain a prediction result output by the initial model; when the prediction result is stall, determining the difference between the prediction result and the corresponding labels at the current time and adjacent time; when the prediction result is smooth, determining the difference between the prediction result and the prediction result of the continuous forward time of the current time; based on the difference, training the initial model to obtain the stall detection model.

2. The method of claim 1, wherein, The method comprises the following steps: filtering the original network traffic based on the protocol type of the original network traffic to obtain original UDP traffic; reorganizing the original UDP traffic according to five-tuple based on a sliding time window to obtain the real-time mixed UDP stream.

3. The method of claim 2, wherein, After identifying the to-be-tested core UDP stream from the real-time mixed UDP stream, the method further comprises: monitoring the number of received data packets per second of the to-be-tested core UDP stream; if the number of packets does not meet the core UDP stream determination standard for a duration greater than a preset duration threshold, re-identifying the to-be-tested core UDP stream.

4. The method of claim 1, wherein, When the service mode is detected to switch, determining the feature mean value of the real-time updated service mode comprises: when the service mode is detected to switch, resetting the long sliding window to short sliding window data, updating the feature mean value to the median of the current long sliding window, and calculating the feature mean value of the updated service mode after the data is stable.

5. The method of claim 1, wherein, The method comprises the following steps: extracting data stream features of the sample core UDP stream, and sequentially performing feature cleaning and standardization on the data stream features; performing feature construction based on the standardized data stream features to obtain constructed features; selecting the key features from the data stream features and the constructed features based on the importance of each feature.

6. A device for detecting UDP traffic congestion, characterized in that comprise: a UDP stream acquisition unit configured to acquire real-time mixed UDP streams reorganized based on five-tuples; a UDP stream identification unit configured to identify a to-be-tested core UDP stream from the real-time mixed UDP streams based on a current service mode, similarity between a number of packets of the current UDP stream and a mean value of historical packet numbers, or a proportion of the number of packets of the current UDP stream in numbers of packets of all streams; a feature calculation unit configured to adaptively calculate key features of the to-be-tested core UDP stream in the current service mode based on a double sliding window algorithm; a stall detection unit configured to input the key features into a trained stall detection model to perform service stall detection, and obtain a detection result output by the stall detection model, the stall detection model being trained based on sample core UDP streams and corresponding labels thereof; the feature calculation unit is specifically configured to: identify the current service mode using a long sliding window, calculate a feature mean value in a stable state of the current service mode, perform feature standardization and feature calculation based on the feature mean value, and obtain the key features; calculate a mean value difference of numbers of received packets per second in the long sliding window and the short sliding window, perform change detection when the mean value difference is greater than a preset threshold, and determine a feature mean value of a real-time updated service mode when a service mode switch is detected; further comprise a model training unit configured to: acquire sample core UDP streams and corresponding labels at each time point; extract key features of the sample core UDP streams, the key features including a received packet abnormal interval length, a number of received packets per second, a flow active time period proportion, a kurtosis of packet size distribution, and a target data packet proportion; input the key features into an initial model to obtain a prediction result output by the initial model; when the prediction result is stall, determine a difference between the prediction result and corresponding labels at a current time point and an adjacent time point; and when the prediction result is smooth, determine a difference between the prediction result and a prediction result at a continuous forward time point of the current time point; train the initial model based on the difference to obtain the stall detection model.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor executes the computer program to implement the UDP service stall detection method according to any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the UDP service stall detection method according to any one of claims 1 to 5.

Images