Method and system for comprehensive verification of quality of service of communication network

Abstract

The application relates to the technical field of communication and discloses a comprehensive communication network service quality closed-loop verification method and system. The method comprises the following steps: acquiring end-to-end network performance data of a target application and a service realization rate index generated based on a predefined service side feedback signal; based on a preset window period, comprehensively judging the network performance data and the service realization rate index by using a worst item principle to determine a window experience level of the window period; automatically triggering a preset settlement or compensation processing according to a cumulative length of time during which the window experience level is lower than a preset service baseline; and performing data freezing processing on the window experience level and the settlement or compensation result to generate a forensic record containing a password school verification value. The application realizes credible quantification and closed-loop management of service quality, significantly reduces dispute costs and guarantees the authenticity of evidence.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to network communication and quality of service management technology. Background Technology

[0002] With the rapid development of cloud computing, artificial intelligence (AI), and cross-border internet services, businesses and users are increasingly reliant on network services. To ensure service stability and reliability, service providers typically sign Service Level Agreements (SLAs) with their clients. Existing SLAs are generally used as the primary standard for measuring service quality, and their assessment criteria mainly focus on network-level performance indicators, such as bandwidth, packet loss rate, round-trip time (RTT), and network availability.

[0003] However, in real-world business scenarios, especially for highly sensitive applications such as cross-border Software as a Service (SaaS), generative AI applications, or high-definition video conferencing, relying solely on traditional network layer metrics is insufficient to accurately reflect the user's final experience. This is mainly reflected in the following aspects:

[0004] First, there is a disconnect between actual user experience and traditional network metrics. Traditional SLA monitoring focuses on link connectivity and transmission quality. However, in many cases, even with sufficient bandwidth and extremely low packet loss rates at the network layer, application-layer issues such as insufficient server processing capacity, slow database responses, or software logic errors can still cause users to experience lag, unresponsiveness, or even service interruptions. This phenomenon of "network metrics meeting standards but services being unavailable" makes evaluation systems based on traditional network metrics unable to accurately quantify the true application experience.

[0005] Secondly, service-side business logic constraints cannot be reflected in traditional SLAs. Modern cloud services typically include complex flow control and quota mechanisms. For example, service providers may implement "rate limiting" or "quota" management for specific accounts based on policies. When these policies are triggered, even if the network link is open, user requests may be directly rejected by the server (e.g., returning an HTTP 429 error). Existing network monitoring tools often treat such situations as normal network connectivity, thus ignoring the problem that the service is not actually being fulfilled effectively.

[0006] Finally, existing settlement and compensation mechanisms lack real-time updates and credible chains of evidence. Current SLA compensation processes largely rely on manual reconciliation and appeals after the fact. When service quality disputes arise, the lack of a mechanism to solidify monitoring data in real time and automatically link it to settlement logic often requires both buyers and sellers to spend considerable time verifying data and defining responsibilities. Furthermore, monitoring data is typically stored in ordinary log format, lacking effective anti-tampering and evidence collection methods, making it difficult to provide credible objective evidence in the event of a dispute. Summary of the Invention

[0007] One objective of this application is to provide a comprehensive communication network service quality closed-loop verification method and system, which can establish a service quality verification and settlement mechanism that can comprehensively consider network transmission performance and service-side performance status, and can achieve automation based on quantitative results and has traceable evidence support.

[0008] This application discloses a comprehensive closed-loop verification method for communication network service quality, including:

[0009] Acquire end-to-end network performance data of the target application, and a service fulfillment rate indicator reflecting the service fulfillment status of the target application, wherein the service fulfillment rate indicator is generated based on a predefined service-side feedback signal;

[0010] Based on a preset window period, the network performance data and the service fulfillment rate index are comprehensively judged to generate a window experience level for the window period. The comprehensive judgment adopts the worst-case principle, and the worse of the first experience level determined based on the network performance data and the second experience level determined based on the service fulfillment rate index is taken as the window experience level.

[0011] Based on the cumulative duration when the window experience level is lower than the preset service baseline, a preset settlement or compensation process will be automatically triggered; and

[0012] The data freezing process is performed on the window experience level and the settlement or compensation result generated by the settlement or compensation process. The data freezing process includes generating forensic records containing cryptographic verification values ​​for the data of the window period for traceability and verification.

[0013] In a preferred embodiment, the service-side feedback signal includes at least one or more selected from the group consisting of: HTTP response status codes, HTTP response headers related to rate limiting or quotas, error codes carried in application layer protocols, or server logs indicating changes to service nodes or service policies.

[0014] In a preferred embodiment, the network performance data includes at least two of the following: round-trip time, packet loss rate, jitter, and throughput.

[0015] The window period is 5 minutes, and the sampling data within the window period is statistically analyzed using the 95th percentile value or a sample compliance rate of not less than 80%.

[0016] In a preferred embodiment, before acquiring the end-to-end network performance data of the target application, the method further includes dynamically adjusting the frequency and metric collection dimensions of active probing according to a collection strategy, wherein the collection strategy is determined based on at least one of the following factors:

[0017] Business period factor: According to the preset business period division, a first detection frequency is used during peak business periods and a second detection frequency is used during off-peak business periods, wherein the first detection frequency is higher than the second detection frequency;

[0018] Application category factor: The detection method and collection dimensions are determined according to the application category of the target application. For real-time audio and video applications, the collection weight of jitter metric is increased and the detection frequency is increased; for transactional applications, the collection weight of round-trip latency and packet loss rate metrics is increased; for large file transfer applications, the collection weight of throughput metric is increased.

[0019] Abnormal heat factor: When the number of times a target application experiences a downgrade or failure level exceeds a preset threshold within a recent preset number of window periods, it is determined to be an abnormal heat increase, and the detection frequency of the target application is increased to the third detection frequency. At the same time, the indicator collection dimensions are expanded to include more granular diagnostic indicators. When no downgrade or failure level occurs within a consecutive preset number of window periods, the detection frequency is restored to the normal level.

[0020] In a preferred embodiment, the automatic triggering of preset settlement or compensation processing includes:

[0021] When the cumulative duration of the window experience level being faulty reaches the first duration threshold, a daily average amount of the monthly service fee will be reduced.

[0022] When the cumulative duration of the window experience level being faulty reaches the second duration threshold, the full amount of the service fee for that month will be waived.

[0023] Wherein, the second duration threshold is greater than the first duration threshold.

[0024] In a preferred embodiment, generating an forensic record containing a cryptographic verification value for the data in the window period includes:

[0025] Arrange the data records within the window period in chronological order;

[0026] Calculate the hash value for each data record, and chain the hash value of the current data record with the hash value of the previous data record to form a chained hash sequence;

[0027] Obtain a trusted timestamp and digitally sign the end hash value of the chained hash sequence;

[0028] The chained hash sequence, the trusted timestamp, and the digital signature are stored as evidence records in a read-only storage medium.

[0029] In a preferred embodiment, obtaining the end-to-end network performance data of the target application includes:

[0030] The first network performance data is obtained through active measurement methods, including at least one of TCP handshake probing, TLS handshake probing, HTTP endpoint probing, and small file transfer sampling.

[0031] And / or, second network performance data can be obtained through passive measurement methods, including session statistics of actual service traffic and application layer throughput observation.

[0032] In a preferred embodiment, the process of generating a service fulfillment rate metric based on predefined service-side feedback signals includes performing semantic parsing and dynamic weighting steps on application layer protocol metadata:

[0033] For the response header or payload content of the target application, extract the resource control field value that represents the resource quota status. The resource control field value includes the remaining call count, token bucket status, or computational resource queuing depth.

[0034] A non-linear score decay model is constructed to map the resource control field value to a normalized service availability score, wherein the service availability score decays exponentially when the resource control field value indicates that the service is about to trigger a circuit breaker or rate limiting.

[0035] During the comprehensive assessment, if the service availability score is lower than a preset critical threshold, a "one-vote veto" mechanism for the experience level is triggered. The excellent indicators in the network performance data are ignored, and the window experience level is directly locked as a fault level to represent a hidden fault state where the network is connected but the service is unavailable.

[0036] In a preferred embodiment, the step of comprehensively classifying the network performance data and the service fulfillment rate index based on a preset window period includes:

[0037] Each indicator in the network performance data is mapped to a level to obtain multiple network indicator levels, including round-trip latency level, packet loss rate level, jitter level, and throughput level.

[0038] The service fulfillment rate metric is mapped to a level to obtain a service fulfillment level. The service fulfillment rate metric is generated in the following way:

[0039] Extract quota status signal, rate limit signal, error response signal and service policy change signal from the service-side feedback signal;

[0040] Each type of signal is quantitatively scored to obtain quota status score, response status score, error type score, and strategy change score;

[0041] The various scores are weighted and combined according to preset weights to obtain the service fulfillment rate score. The calculation formula is as follows: in, Scoring the quota status Scoring the distribution of HTTP status codes Rate the error type Rate the service strategy change; , , , The corresponding weight coefficients, and satisfying ;

[0042] The multiple network indicator levels are combined with the service fulfillment level, and the worst-case scenario principle is used to determine the window experience level, that is:

[0043]

[0044] in, For window experience level, , , , These are respectively round-trip latency level, packet loss rate level, jitter level, and throughput level. The service experience level is determined by the service level. Each level is mapped to a numerical value in order of superiority or inferiority. The min function returns the smallest value, which is the worst level, as the window experience level.

[0045] This application also discloses a comprehensive communication network service quality closed-loop verification system, including a processor and a memory, wherein the memory stores computer-executable instructions, and when the processor executes the executable instructions, the system implements the method described above.

[0046] In the embodiments of this application, a comprehensive closed-loop verification method for communication network service quality, including service fulfillment rate indicators and network performance data, is constructed. The worst-case principle is used to comprehensively classify multi-dimensional data based on a window period, and the classification results are directly linked to automatic settlement or compensation triggering mechanisms. Simultaneously, data freezing processing including cryptographic verification values ​​effectively solves the technical problem in current Service Level Agreements (SLAs) that only focus on network layer indicators while ignoring the actual service performance status at the application layer (such as rate limiting, quota exhaustion, etc.). This achieves a closed-loop process from application experience perception, quantitative classification, automatic settlement to tamper-proof evidence collection. In particular, by introducing the service fulfillment rate indicator, it can capture hidden faults where the network is connected but the service is unavailable. The automated settlement triggering mechanism reduces the cost of manual calculation and the risk of disputes. Through data freezing and cryptographic recording, the authenticity, integrity, and non-repudiation of settlement evidence are ensured in complex scenarios such as cross-border SaaS and AI services, thereby significantly improving the transparency and credibility of network service quality management.

[0047] Furthermore, by extracting service-side feedback signals from HTTP response status codes, rate limiting headers, application-layer error codes, or server-side logs to generate service fulfillment rate metrics, the "soft fault" state of the application layer can be accurately perceived. This allows the system to accurately determine the impaired experience even when network transport layer metrics are normal but the service side refuses service due to policy restrictions, thus filling the blind spot of traditional network monitoring at the application logic level.

[0048] Furthermore, by selecting key indicators such as round-trip latency and packet loss rate, and setting a 5-minute window and a statistical standard that the 95th percentile or 80% of samples meet the criteria, it is possible to smooth out instantaneous network jitter interference while sensitively capturing persistent performance degradation that has a substantial impact on user experience, thus ensuring the statistical significance of the rating results and the consistency with the business experience.

[0049] Furthermore, by dynamically adjusting the detection frequency and data collection dimensions based on business periods, application categories, and anomaly activity, monitoring resources can be rationally allocated while ensuring monitoring accuracy during critical business periods and abnormal periods, reducing unnecessary interference with production operations, and achieving an adaptive balance between monitoring system performance overhead and fault detection capabilities.

[0050] Furthermore, by setting tiered compensation thresholds based on the cumulative duration of the fault (such as triggering a daily limit or a full monthly reduction for accumulated duration), the technical fault duration can be automatically mapped to the commercial settlement logic. Complex compensation agreements can be executed without manual intervention, significantly improving the efficiency and standardization of default handling.

[0051] Furthermore, by using chained hash sequences, trusted timestamps, and digital signatures to solidify and store window data, a time-series dependency relationship of data records can be established. Once historical data is tampered with, the hash chain will break, thus providing legally valid electronic evidence for subsequent monthly reconciliation and dispute arbitration, ensuring the integrity of the evidence chain.

[0052] Furthermore, by combining active measurement (such as TCP / TLS handshake) and passive measurement (such as actual traffic observation), we can take into account both connectivity verification of specific service endpoints and experience statistics of real user traffic, avoid sample bias caused by a single measurement method, and ensure that the obtained performance data can fully reflect the real application operating environment.

[0053] Furthermore, by constructing a nonlinear scoring decay model and a "one-vote veto" mechanism, semantic parsing is performed on the fields representing resource quotas. When the server is about to trip or has already implemented rate limiting, the experience level can be forcibly judged as a failure, thereby ensuring that the classification results can prioritize reflecting critical issues in service availability and preventing excellent network transmission indicators from masking the fact that application services are unavailable.

[0054] Furthermore, through specific weighted fusion formulas and multi-dimensional level mapping logic, the quantitative calculation path from a single indicator to a synthetic experience level is clarified. The worst-case principle (min function) is used to ensure that the final rating is determined by the system's "weakest link," which conforms to the barrel effect principle and can most strictly guarantee that the actual user experience is not diluted by the average value algorithm.

[0055] The various technical features disclosed in the above-described invention, the various technical features disclosed in the following embodiments and examples, and the various technical features disclosed in the accompanying drawings can be freely combined to form various new technical solutions (all of which should be considered as having been recorded in this specification), unless such a combination of technical features is technically infeasible. For example, in one example, feature A+B+C is disclosed, and in another example, feature A+B+D+E is disclosed. Features C and D are equivalent technical means that serve the same function, and technically only one needs to be used; it is impossible to use both simultaneously. Feature E can be technically combined with feature C. Therefore, the solution A+B+C+D should not be considered as having been recorded because it is technically infeasible, while the solution A+B+C+E should be considered as having been recorded. Attached Figure Description

[0056] Figure 1 This is a schematic diagram of the overall process of the comprehensive communication network service quality closed-loop verification method according to Embodiment 1 of the present invention, which shows the complete processing flow from data collection to settlement and compensation and then to data freezing. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0058] Example 1

[0059] This embodiment provides a comprehensive closed-loop verification method for communication network service quality. This method comprehensively considers network performance data and service performance status, and achieves quantitative verification and closed-loop management of application experience through window-level rating, automatic settlement and compensation, and data freezing for evidence collection.

[0060] This embodiment uses a cross-border AI service scenario as an example. Assume the target application is an AI API service accessed by enterprise users via a dedicated network, and the domain name of this service is api.ai.com. The flowchart of this embodiment is as follows. Figure 1 As shown.

[0061] In step 101, the system first acquires the end-to-end network performance data of the target application. Specifically, the network performance data includes four metrics: Round-Trip Time (RTT), Packet Loss Rate (PLR), Jitter, and Throughput. RTT is obtained by sending probe packets to the target domain and recording the response time. In this embodiment, HTTPS endpoint probing is used, sending an HTTP HEAD request to the api.ai.com / v1 / models endpoint and recording the time interval from sending the request to receiving the response header as the RTT value. Packet Loss Rate is calculated by statistically analyzing the proportion of probe packets lost within a preset time period. If 100 probe requests are sent within a statistical window, and 3 of them do not receive a response, the packet loss rate for that window is 3%. Jitter reflects the fluctuation of network latency and is obtained by calculating the statistical difference in RTT values ​​between adjacent probe samples. Throughput is obtained through small file transfer sampling. The system periodically initiates small file download requests to the target application and records the transmission rate as the downlink throughput metric.

[0062] While acquiring network performance data, the system also needs to obtain a service fulfillment rate metric that reflects the service fulfillment status of the target application. The service fulfillment rate metric is generated based on predefined service-side feedback signals, which reflect fulfillment-related information such as server-side quota status, rate limiting policies, and error responses. In the cross-border AI service scenario of this embodiment, service-side feedback signals are mainly extracted from HTTP responses, including response status codes (e.g., 429 indicating too many requests, 503 indicating service unavailable), rate-limit-related response headers (e.g., x-ratelimit-remaining indicating remaining quota, x-ratelimit-reset indicating quota reset time), and error codes carried in the response body (e.g., rate_limit_exceeded, insufficient_quota, etc.). The system parses these signals and performs weighted scoring to generate a service fulfillment rate score from 0 to 100.

[0063] In step 102, after acquiring network performance data and service fulfillment rate indicators, the system performs a comprehensive assessment of these data based on a preset window period. This embodiment uses a 5-minute window period, meaning a statistical window is formed every 300 seconds. Within each window, the system performs statistical processing on the collected sample data, using the 95th percentile (p95) or a sample compliance rate of no less than 80% to ensure that the statistical results reflect the main performance within the window rather than extreme outliers. Taking the RTT indicator as an example, if 120 RTT samples are collected within a window, using the p95 statistical standard, the value of the 114th sample after sorting is taken as the RTT statistical value for that window; if the 80% sample compliance standard is used, it is determined whether at least 96 samples have RTT values ​​below a preset threshold.

[0064] The comprehensive rating adopts the worst-case principle, taking the worse of the first experience level determined by network performance data and the second experience level determined by service fulfillment rate as the final experience level for that window. This embodiment defines five experience levels: O, P, S, D, and F, where O represents excellent, P represents good, S represents acceptable, D represents degraded, and F represents failure. For each indicator in the network performance data, the system maps levels according to preset thresholds. Taking Round Trip Time (RTT) as an example, RTT less than 80 milliseconds is mapped to level O, 80 to 120 milliseconds to level P, 100 to 199 milliseconds to level S, 180 to 300 milliseconds to level D, and greater than or equal to 350 milliseconds or unreachable probes to level F. The packet loss rate (PLR) level mapping rules are: less than 0.5% is level O, 0.5% to 1% is level P, 1% to 3% is level S, 3% to 5% is level D, and greater than or equal to 5% is level F. The system maps four network metrics—RTT, PLR, Jitter, and throughput—into grades, and then selects the worst grade as the overall network performance grade. This overall performance grade is then compared to the grade corresponding to the service fulfillment rate, and the worse grade is taken as the final experience grade for that window. For example, if a window has an RTT grade of P, a PLR grade of S, a Jitter grade of O, a throughput grade of S, and a service fulfillment rate grade of D, then the final experience grade for that window is D.

[0065] In step 103, when the window experience level is lower than the preset service baseline, the system will accumulate the corresponding downgrade or failure duration and automatically trigger the preset settlement or compensation process accordingly. In this embodiment, level S is set as the service baseline. Windows with a level of S or higher (i.e., O, P, S) are considered compliant windows, while windows with a level lower than S (i.e., D, F) are considered abnormal windows. The system accumulates the duration of level F windows in real time, and triggers compensation when the accumulated duration reaches a preset threshold. The specific compensation rules are as follows: for every 3 hours (180 minutes, corresponding to 36 5-minute windows) of accumulated level F duration, a daily average amount of the monthly service fee is reduced; when the accumulated level F duration reaches 45 hours (2700 minutes, corresponding to 540 5-minute windows), the entire monthly service fee is reduced. The daily average amount is calculated by dividing the monthly service fee by the number of calendar days in the month. For example, if a customer's service fee for the month is 3,000 yuan and there are 30 days in the month, the daily average limit is 100 yuan. If the cumulative downtime for the month is 9 hours, then a reduction of 3 daily average limits will be triggered, which is a reduction of 300 yuan.

[0066] In step 104, to ensure the traceability and non-repudiation of the assessment results and settlement data, the system performs data freezing processing on the window experience level and settlement or compensation results. Data freezing processing includes generating forensic records containing cryptographic verification values ​​for each window period. Specifically, at the end of each natural day (T+1 mechanism), the system freezes all window records generated the previous day. During the freezing process, the system first arranges all window records for the day in chronological order, then calculates the SHA-256 hash value for each record, and concatenates the hash value of the current record with the hash value of the previous record before calculating the hash again, forming a chained hash sequence. The construction of the chained hash ensures that any tampering with historical data will result in changes to all subsequent hash values, thus being detected. After completing the chained hash calculation, the system obtains a trusted timestamp and uses a private key to digitally sign the end hash value of the chained hash sequence, generating an unforgeable forensic credential. Finally, the complete forensic record, including the original data, chained hash sequence, timestamp, and digital signature, is written to a read-only storage medium using Write-once-Read-Many (WORM) technology to ensure that the data cannot be modified or deleted after being written. The frozen data can be exported as CSV and JSON report files, as well as verification files containing signature information, for use in settlement reconciliation or dispute arbitration.

[0067] Through the above technical solution, this embodiment realizes a complete closed loop from data collection, comprehensive assessment, automatic settlement to data freezing, transforming the application experience that is difficult to quantify in traditional SLAs into a service quality indicator system that is measurable, assessable, settleable, and traceable.

[0068] Example 2

[0069] This embodiment, based on Embodiment 1, provides an in-depth explanation of the process for generating the service fulfillment rate indicator and the detailed implementation of the comprehensive rating.

[0070] The service fulfillment rate metric is a key technical feature that distinguishes this invention from traditional network SLAs. Its core lies in incorporating the server's fulfillment status into the experience evaluation system. In practical applications, even if network-level metrics such as RTT and packet loss rate perform well, users may still fail to receive the expected service experience due to server-side quota exhaustion, rate limiting policies being triggered, or service degradation. Therefore, the service fulfillment rate metric fills the experience blind spots that traditional network metrics cannot reflect by capturing and analyzing server-side feedback signals.

[0071] The sources of service-side feedback signals are diverse. In this embodiment, service fulfillment-related information is mainly extracted from the following four types of signal sources. The first type is HTTP response status codes, including 429 (Too Many Requests) indicating a rate limit has been triggered, 503 (Service Unavailable) indicating that the service is temporarily unavailable, 502 (Bad Gateway) indicating an upstream service error, and 500 (Internal Server Error) indicating an internal server error. The second type is HTTP response headers related to rate limits or quotas, with common fields including x-ratelimit-limit (quota limit), x-ratelimit-remaining (remaining quota), x-ratelimit-reset (quota reset timestamp), and retry-after (suggested retry waiting time). The third type is error codes carried in application layer protocols. For example, the error.type field returned by the AI ​​API may contain error types such as rate_limit_exceeded (rate limit), insufficient_quota (insufficient quota), and model_not_available (model unavailable). The fourth category is server logs that indicate changes to service nodes or service policies, such as switchover records from GPT-4 model to GPT-3.5-turbo model, and route changes from primary area to backup area.

[0072] After extracting the aforementioned service-side feedback signals, the system quantifies and scores each type of signal, then weights and fuses them to generate a service fulfillment rate score. The following calculation formula is used in this embodiment:

[0073]

[0074] in, The quota status score is calculated based on the remaining quota percentage; The HTTP status code distribution is scored based on the percentage of successful responses (2xx); Error types are scored, weighted based on the severity of the error response; The score for service policy changes is calculated based on whether service degradation or regional switching has occurred. Weighting coefficients are used. , , , These can be set to, for example, 0.35, 0.25, 0.25, and 0.15, respectively, to meet the requirements. The constraints are as follows. Each scoring item ranges from 0 to 100 points. The value range is also from 0 to 100.

[0075] Quota status score The calculation requires parsing the resource control fields in the response header. Taking the x-ratelimit-remaining and x-ratelimit-limit fields as examples, the system calculates the remaining quota percentage. Then, it is converted into a score value through a nonlinear mapping function. This embodiment uses a piecewise linear function: when hour, ;when hour, ;when hour, ;when hour, This non-linear mapping ensures that the score decays rapidly when the quota is nearly exhausted, thus promptly reflecting the risk that the service is about to trigger rate limiting.

[0076] HTTP status code distribution and scoring Calculation based on the frequency of occurrence of various status codes within the window. Assume there are a total of... This request, including 2xx responses 429 response 5xx responses Secondary and other responses Then, the scoring formula is:

[0077]

[0078] If the score is negative, it will be 0; if it exceeds 100, it will be 100.

[0079] Error type rating Differentiated scoring is applied based on the severity of the error. The system predefines the severity weights for different error types, such as rate_limit_exceeded (0.6), insufficient_quota (0.9), model_not_available (0.8), and server_error (1.0). If an error response appears in the window, points are deducted based on the error type and the frequency of occurrence. The lower limit of the result is 0.

[0080] Service strategy change rating This reflects whether the server has made any policy adjustments that affect user experience. The system detects service degradation or region switching by parsing fields such as model identifier and region identifier in the response content. If a degradation from a high-level model to a low-level model is detected (e.g., from GPT-4 to GPT-3.5), 30 points are deducted; if a switch from a primary region to a backup region is detected, 20 points are deducted; if no policy change is detected, ... .

[0081] To further enhance the ability to capture service anomalies, this embodiment also implements semantic parsing and dynamic weighting steps for application layer protocol metadata. The system extracts resource control field values ​​representing resource quota status from the response header or payload content of the target application. These field values ​​include remaining call counts, token bucket status, or computational resource queuing depth, etc. The system constructs a non-linear score decay model, mapping resource control field values ​​to normalized service availability scores. The characteristic of this decay model is that when the resource control field value indicates that the service is about to trigger circuit breaking or rate limiting, the service availability score decays exponentially. The specific mathematical expression is as follows:

[0082]

[0083] in This refers to the percentage of resources available (such as the ratio of remaining quota to total quota). For the attenuation coefficient, this embodiment takes... .when When the score drops from 1 to 0.5, it drops from 100 to approximately 71; When it drops further to 0.2, the score drops rapidly to around 20; when As the score approaches zero, the score also approaches zero. This exponential decay characteristic provides a strong early warning signal when the service is nearing unavailability.

[0084] In the comprehensive assessment, the system implements a "one-vote veto" mechanism. If the service availability score is lower than a preset critical threshold (70 points in this embodiment), a one-vote veto is triggered, ignoring the excellent indicators in the network performance data and directly locking the window experience level to F (fault level). This mechanism can accurately characterize the hidden fault state of "network connectivity but service unavailable," avoiding the masking of serious service-level problems due to good network indicators.

[0085] The complete comprehensive rating process is as follows: The system first maps the four indicators in the network performance data—round-trip latency, packet loss rate, jitter, and throughput—to rating levels, resulting in... , , , Four rating levels. Then, the service fulfillment rate is scored. Perform level mapping, when The time mapping is S level, when When the time mapping is D level, The time mapping is assigned to level F, resulting in the service fulfillment level. Finally, the worst-case scenario principle was adopted, and the worst of the five levels was selected as the window experience level:

[0086]

[0087] Each level is mapped to a value of 5, 4, 3, 2, and 1 respectively, in the order of superiority (O, P, S, D, F). The min function returns the smallest value, indicating the worst level. Through this comprehensive rating method, the system can fully reflect the end-to-end experience quality of the target application; any degradation in any dimension will be accurately captured and reflected in the final window experience rating.

[0088] Example 3

[0089] This embodiment provides a detailed explanation of the dynamic adjustment of the data acquisition strategy and the specific implementation methods of active and passive measurement.

[0090] Data acquisition is the foundation of the entire closed-loop verification method, and the quality and timeliness of the acquired data directly affect the accuracy of the grading results. This embodiment implements an intelligent acquisition strategy that can dynamically adjust the frequency of proactive detection and the dimensions of indicator acquisition based on factors such as business time period, application category, and abnormal popularity, thereby reducing the impact on production operations while ensuring data quality.

[0091] The processing logic for business time period factors is as follows: The system pre-configures business time period division rules, dividing each day into peak and off-peak periods. Taking an enterprise office scenario as an example, 9:00-12:00 and 14:00-18:00 on weekdays are typically peak periods, while the remaining times are off-peak periods. During peak periods, the system uses a higher first detection frequency, set to 20 detections per minute in this embodiment, i.e., sending a detection request every 3 seconds, to ensure timely detection of network fluctuations and service anomalies. During off-peak periods, the system uses a lower second detection frequency, set to 5 detections per minute in this embodiment, i.e., sending a detection request every 12 seconds, to meet basic monitoring needs while reducing the network resource consumption of detection traffic. The determination of time periods supports differentiated configuration based on weekdays and non-weekdays, and the system has a built-in holiday calendar to support automatic recognition.

[0092] The processing logic for application category factors reflects differentiated monitoring strategies for different types of applications. The system predefines the mapping relationship between application categories and detection strategies. For real-time audio and video applications (such as video conferencing and online education), since user experience is extremely sensitive to network jitter, the system increases the collection weight of jitter metrics, tightens the judgment threshold of jitter metrics (for example, adjusting the S-level threshold of jitter from 50 milliseconds to 30 milliseconds), and increases the detection frequency by 50% to detect jitter degradation more promptly. For transactional applications (such as online payment and securities trading), since the business has extremely high requirements for latency and reliability, the system increases the collection weight of round-trip latency and packet loss rate metrics, and enables additional monitoring of TCP connection success rate. For large file transfer applications (such as cloud storage synchronization and large data transfer), the system increases the collection weight of throughput metrics and periodically performs large-scale transmission sampling tests (such as uplink and downlink transmission of 10MB files) to accurately evaluate actual transmission performance. Application categories can be determined through domain name rule matching, port number identification, or manual configuration.

[0093] The logic for handling abnormal activity factors enables adaptive responses to abnormal states. The system continuously monitors the historical rating results of each target application. When an application is detected to have received more than two D or F ratings within the last six window periods (i.e., 30 minutes), its abnormal activity level is determined to have increased. Once the abnormal activity level increases, the system increases the detection frequency of the application to a third detection frequency (30 times per minute in this embodiment), while expanding the dimensions of indicator collection to include more granular diagnostic indicators, such as segmented latency indicators like TCP connection establishment latency, TLS handshake latency, and DNS resolution latency, as well as transmission quality indicators like TCP retransmission rate and out-of-order packet ratio. These expanded indicators help pinpoint the specific cause of the anomaly. When no D or F ratings occur for 12 consecutive window periods (i.e., one hour), the system determines that the abnormal state has recovered and restores the detection frequency and collection dimensions to normal levels.

[0094] End-to-end network performance data for a target application can be obtained through both active and passive measurement methods. These two methods can be used individually or in combination to obtain a more comprehensive performance view.

[0095] Active measurement refers to the system proactively initiating probe requests to obtain network performance data by analyzing the characteristics of requests and responses. This embodiment implements the following active measurement methods: TCP handshake probe: Initiating a TCP three-way handshake to the target application's service port, recording the time from sending a SYN packet to receiving a SYN-ACK packet as the TCP connection establishment latency. This metric reflects the basic connectivity and latency level of the network layer. TLS handshake probe: Performing a TLS protocol handshake after the TCP connection is established, recording the time from ClientHello to receiving ServerHello and subsequent handshake messages as the TLS handshake latency. This metric reflects the efficiency of encrypted transmission establishment. This embodiment supports TLS 1.2 and TLS 1.3 protocols. For TLS 1.3, due to its optimized handshake process, the latency is typically significantly lower than TLS 1.2. HTTP endpoint probe: Sending HTTP requests (supporting HEAD, GET, POST, etc.) to the target application's health check endpoint or API endpoint, recording the time from sending the request to receiving a complete response as the HTTP response latency, and simultaneously parsing the response status code and response header fields for service fulfillment rate evaluation. Small file transfer sampling tests evaluate actual transfer performance by uploading or downloading small test files (in this example, a 100KB test file is used by default) to the target application, recording the transfer completion time and calculating the throughput. This method can truly reflect the end-to-end performance of application data transfer.

[0096] Passive measurement refers to the system acquiring network performance data by bypassing or statistically analyzing actual business traffic without generating additional probe traffic. This embodiment implements passive measurement methods including session statistics and application layer throughput observation of actual business traffic. Session statistics involve deploying traffic mirroring or TAP devices at the network egress or access point to collect packet header information of actual business traffic and statistically analyze metrics such as RTT (based on ACK timestamp), retransmission rate, and out-of-order rate of TCP sessions. Application layer throughput observation involves parsing application layer protocols in actual business traffic and statistically analyzing metrics such as latency distribution, success rate, and throughput of request and response. The advantage of passive measurement is its ability to reflect the performance status of real business operations, but its limitation is that it may not be able to obtain sufficient samples when business traffic is low. Therefore, the system implements a linkage strategy between active and passive measurement: when passively observed business traffic is sufficient (e.g., the number of sessions within a window exceeds 50), the passive measurement results are used as the primary factor, and the active measurement results are used as a secondary factor for weighted fusion; when business traffic is sparse, the active probe frequency is automatically increased to ensure sufficient performance samples are obtained.

[0097] By combining the above dynamic acquisition strategies and multiple measurement methods, the system can continuously acquire high-quality performance data under different business scenarios and network conditions, providing a reliable data foundation for subsequent comprehensive assessment.

[0098] Example 4

[0099] This embodiment provides a detailed description of the specific implementation of the data freezing and evidence collection mechanism, focusing on the technical details of chained hash generation, timestamp signing, and read-only storage.

[0100] Data freezing and evidence collection mechanisms are key technical means to ensure the legal validity and arbitrability of closed-loop verification results. In traditional SLA monitoring systems, monitoring data is usually stored in ordinary databases, which are at risk of being tampered with afterward, making it difficult to provide convincing evidence to both parties in the event of a dispute. This embodiment constructs a tamper-proof, traceable, and verifiable evidence collection link through cryptographic and read-only storage technologies.

[0101] Data freezing is performed using a T+1 mechanism, meaning that all data generated the previous day is frozen at midnight on the day following the end of each calendar day (e.g., 00:30 each day). The reason for choosing T+1 instead of real-time freezing is twofold: firstly, it is necessary to ensure that all window data from the previous day has been fully collected and classified; secondly, centralized batch processing is more efficient in terms of computation and storage.

[0102] The chained hash sequence generation process is as follows. First, the system extracts all window records from the database for the previous day (Day T). Each record contains fields such as window start and end timestamps, statistical values ​​of network performance metrics, service fulfillment rate score, comprehensive rating result, and details of abnormal events. Then, all records are sorted in ascending order of window start timestamps to ensure the determinism and reproducibility of the record order. Next, the system uses the SHA-256 hash algorithm to perform hash calculations on each record. For the first record, its hash value... For the first records ( ), its hash value The hash symbol "||" represents string concatenation. This chained hash structure ensures data integrity: if any historical record is tampered with, its hash value will change, leading to a chain reaction of hash value changes for all subsequent records, ultimately culminating in the final hash value at the end of the chained hash sequence. If the value does not match the original value, the tampering can be detected.

[0103] The process of obtaining and generating timestamp signatures is as follows. After completing the chained hash calculation, the system sends the final hash value to a trusted timestamp service provider. The system obtains a timestamp proof that the hash value existed at a specific moment. Trusted timestamp service providers typically use a time source synchronized with the National Time Service Center, and their issued timestamps have legal validity. The timestamp proof includes the hash value, the precise time, and the digital signature of the timestamp service provider. After obtaining the trusted timestamp, the system uses its own private key to digitally sign "end hash value || trusted timestamp" to generate a system signature. This embodiment uses a 2048-bit RSA key for signing, with the private key securely stored in the Hardware Security Module (HSM) to ensure the security of the signing process. Through a dual-signature mechanism (signature from a timestamp service provider and signature from the system itself), the evidence record possesses non-repudiation in both the time and source dimensions.

[0104] The evidence records are stored using read-only storage media to ensure that data cannot be modified or deleted after it is written. This embodiment supports several read-only storage solutions. The first solution is to use WORM (Write Once Read Many) storage devices, such as enterprise-grade WORM tape libraries or object storage services that support WORM features (such as Amazon S3 Object Lock, Alibaba Cloud OSS compliance retention policies, etc.). The characteristic of this type of storage is that data is locked once written and cannot be deleted or overwritten during the retention period. The second solution is to use blockchain evidence storage services, storing the end-of-chain hash value and timestamp on the blockchain, using the immutability of the blockchain to provide additional notarization protection. This embodiment defaults to using cloud object storage with ObjectLock functionality, with a retention period set to 12 months, meeting the retention period requirements of most service contracts for evidence data.

[0105] The frozen evidence records support export in multiple formats to meet the needs of different scenarios. CSV export outputs the window records in tabular form, facilitating viewing and analysis in spreadsheet software. JSON export retains complete data structure and field type information, facilitating programmatic processing and data exchange between systems. The signature verification file (.sig) contains a chained hash sequence, a trusted timestamp, and a digital signature for independent verification by a third party. The verification process is as follows: the verifier first recalculates the chained hash sequence based on the original data and checks whether the final hash value matches the one recorded in the signature file; then, it verifies the validity of the digital signature using the system's public key; finally, it verifies the authenticity of the timestamp with the timestamp service provider. If all the above verifications pass, it can be confirmed that the evidence data has not been tampered with since the freezing time.

[0106] In practical applications, the data freezing and evidence collection mechanism mainly serves the following scenarios: During monthly settlement and reconciliation, the service provider and the client can obtain evidence collection records for verification, and chain hashing ensures that the data seen by both parties is completely consistent; In the event of a service quality dispute, either party can extract the evidence collection records and invite a third party to conduct independent verification, and signatures and timestamps ensure the authenticity and timeliness of the data; During regulatory audits, the evidence collection records can be submitted as objective evidence of service quality to meet compliance requirements.

[0107] Example 5

[0108] This embodiment provides a comprehensive communication network service quality closed-loop verification system. The system includes a processor and a memory. The memory stores computer-executable instructions. When the processor executes the executable instructions, it implements the methods described in Embodiments 1 to 4 above.

[0109] The system in this embodiment adopts a distributed architecture design, including two main components: edge acquisition nodes deployed on the user side and a central processing platform deployed in the cloud. The edge acquisition nodes are responsible for performing active detection and passive observation tasks to collect raw performance data; the central processing platform is responsible for core processing tasks such as data aggregation, statistical classification, calculation, and data freezing.

[0110] The hardware form of edge acquisition nodes can be software agents, virtualized probes, or dedicated hardware devices. When using a software agent, the agent program is installed on the user's existing servers, terminal devices, or network devices, and performs probing functions by calling the operating system's network interface. This form offers flexible deployment, low cost, and is suitable for distributed office scenarios. When using a virtualized probe, the probe is deployed as a virtual machine or container on the user's virtualization or container platform, gaining independent computing resources and network configuration, making it suitable for scenarios requiring high-precision measurements. When using a dedicated hardware device, the device is deployed as an independent network device at key nodes in the user's network. This embodiment uses an embedded device based on an ARM Cortex-A72 processor, running a customized Linux operating system, and supporting multiple gigabit Ethernet interfaces for traffic mirroring and management communication. This form offers high measurement accuracy and stability, making it suitable for enterprise-level applications with strict data quality requirements.

[0111] The software architecture of the edge acquisition node comprises four main components: a detection engine module, a passive observation module, a policy management module, and a data reporting module. The detection engine module implements active measurement functions such as TCP handshake detection, TLS handshake detection, HTTP endpoint detection, and small file transfer sampling, supporting configuration of parameters such as detection targets, detection methods, and detection frequencies. The passive observation module implements traffic mirroring, session statistics, and protocol parsing functions, supporting the extraction of performance metrics and service-side feedback signals from mirrored traffic. The policy management module receives acquisition policies from the central platform and dynamically adjusts detection behavior based on local conditions (such as business hours and abnormal activity levels). The data reporting module is responsible for preprocessing the collected raw data locally before reporting it to the central processing platform, supporting data compression, encrypted transmission, and breakpoint resume functionality.

[0112] The hardware deployment of the central processing platform can utilize physical server clusters or cloud computing resources. This embodiment employs a public cloud deployment scheme, using cloud server instances for computing resources, cloud object storage services for storage resources, and cloud database services for the database. The software architecture of the central processing platform comprises four layers: a data access layer, a computing processing layer, a storage layer, and an application layer.

[0113] The data access layer is responsible for receiving raw data reported by edge acquisition nodes and implementing preprocessing functions such as data verification, deduplication, and buffering. In this embodiment, a message queue (such as Apache Kafka) is used as the buffer layer for data access to ensure that no data is lost during sudden data spikes, while also providing a data source for subsequent streaming computing.

[0114] The computational processing layer is the core of the system, implementing core algorithms such as statistical aggregation, comprehensive grading, and settlement calculation. This embodiment uses a streaming computing engine (such as Apache Flink) to achieve window-level real-time statistics and grading. The streaming computing job continuously consumes raw data from the message queue, performs aggregation statistics in 5-minute windows, calculates the p95 value or sample compliance rate for each indicator, then calls the grading algorithm to obtain the window experience level, and finally writes the grading results to the database and pushes them to the application layer. The settlement calculation module summarizes the grading results monthly, accumulates fault duration, calculates compensation amounts, and generates settlement reports.

[0115] The storage layer is responsible for persistently storing various types of data. Time-series databases (such as InfluxDB or TimescaleDB) are used to store window-level metric statistics and ranking results, supporting efficient time-range queries and aggregation analysis. Relational databases (such as PostgreSQL) are used to store structured data such as application configurations, user information, contract parameters, and settlement records. Object storage (such as Amazon S3) is used to store evidence records and exported files after data freeze, with object lock policies configured to ensure data immutability.

[0116] The application layer provides a user interface and external integration interfaces. The read-only dashboard module displays real-time assessment results, historical trends, anomaly details, and settlement statistics in a web page format, supporting filtering and drill-down by application, time range, and grade type. Dashboard data originates from the output of the computation processing layer, employing a front-end / back-end separation architecture; the front-end is developed using the React framework, and the back-end uses the Spring Boot framework. The evidence export module provides online viewing and downloading of evidence records, supporting selection of date ranges and export formats. Permission verification is performed before exporting to ensure that only authorized users can access sensitive data. The API interface module provides a RESTful programming interface, allowing external systems (such as customer operation and maintenance systems and financial systems) to obtain assessment results, settlement data, and evidence records through the interface, supporting OAuth 2.0 authentication to ensure interface security.

[0117] The system's security design encompasses three aspects: transmission security, storage security, and access control. For transmission security, data transmission between edge nodes and the central platform uses TLS 1.3 encryption, and the API interface only supports HTTPS access. For storage security, the database uses Transparent Data Encryption (TDE), sensitive fields (such as contract amounts) employ application-layer encryption, and the signing private key is stored in a hardware security module. Regarding access control, the system implements Role-Based Access Control (RBAC), differentiating permissions for different roles such as administrators, maintenance personnel, and customers. Critical operations (such as modifying contract parameters or exporting evidence records) require multi-factor authentication.

[0118] Through the above system architecture and hardware / software configuration, this embodiment implements a complete comprehensive communication network service quality closed-loop verification system, which can support continuous monitoring, real-time grading, automatic settlement and trusted evidence collection for large-scale applications, and establish a transparent, quantifiable and traceable service quality assurance mechanism between service providers and customers.

[0119] Accordingly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the various method embodiments of this application. Computer-readable storage media include permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media do not include transient computer-readable media, such as modulated data signals and carrier waves.

[0120] Furthermore, embodiments of this application also provide a computer program product, including computer-executable instructions that, when executed by a processor, implement the steps in the above-described method embodiments.

[0121] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. In this application, if it refers to performing an action according to an element, it means performing the action at least according to that element, including two cases: performing the action only according to that element, and performing the action according to that element and other elements. Expressions such as "multiple," "repeatedly," and "various" include two, two times, two kinds, and more than two, more than two times, and more than two kinds.

[0122] The numbering used in describing the steps of a method does not inherently limit the order of these steps. For example, a step with a higher number does not necessarily have to be executed after a step with a lower number; it can be executed first and then second, or even in parallel, as long as this execution order is reasonable to someone skilled in the art. Similarly, multiple steps with consecutively numbered sequences (e.g., step 101, step 102, step 103, etc.) do not restrict other steps from being executed between them; for example, there can be other steps between step 101 and step 102.

[0123] This specification includes combinations of various embodiments described herein. Individual references to embodiments are made (e.g., "one embodiment," "some embodiments," or "preferred embodiments"); however, these embodiments are not mutually exclusive unless indicated to be mutually exclusive or are readily apparent to those skilled in the art. It should be noted that the word "or" is used in a non-exclusive sense throughout this specification unless the context explicitly indicates or requires it.

[0124] All references to this specification are considered to be incorporated integrally into the disclosure of this application so that they can serve as the basis for modifications if necessary. Furthermore, it should be understood that the above descriptions are merely preferred embodiments of this specification and are not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the scope of protection of one or more embodiments of this specification.

[0125] In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A comprehensive communication network service quality closed-loop verification method, characterized in that, The method comprises: acquiring end-to-end network performance data of a target application and a service realization rate indicator reflecting a service fulfillment state of the target application, wherein the service realization rate indicator is generated based on a predefined service-side feedback signal; based on a preset window period, comprehensively grading the network performance data and the service realization rate indicator to generate a window experience level of the window period, wherein the comprehensive grading adopts a worst item principle, and the worse of a first experience level determined according to the network performance data and a second experience level determined according to the service realization rate indicator is taken as the window experience level; automatically triggering a preset settlement or compensation process according to a cumulative length of time when the window experience level is lower than a preset service baseline; and performing a data freezing process on the window experience level and a settlement or compensation result generated by the settlement or compensation process, the data freezing process comprising generating a forensic record containing a password school verification value for the data of the window period for tracing and verification.

2. The integrated communication network service quality closed loop verification method of claim 1, wherein, The service-side feedback signal at least includes one or more selected from the following group: an HTTP response status code, an HTTP response header related to rate limiting or quota, an error code carried in an application layer protocol, or a service-side log indicating a change in a service node or service policy.

3. The integrated communication network service quality closed loop verification method of claim 1, wherein, The network performance data at least includes at least two of round-trip delay, packet loss rate, jitter and throughput rate; The window period is 5 minutes, and the 95th percentile value statistics or the sample compliance ratio statistics of no less than 80% are adopted for the sampling data in the window period.

4. The integrated communication network service quality closed loop verification method of claim 1, wherein, Before acquiring the end-to-end network performance data of the target application, the method further comprises dynamically adjusting the frequency and index collection dimension of active probing according to a collection strategy, the collection strategy being determined based on at least one of the following factors: a business period factor: according to a preset business period division, a first probing frequency is adopted in a business peak period and a second probing frequency is adopted in a business trough period, wherein the first probing frequency is higher than the second probing frequency; an application category factor: the probing mode and collection dimension are determined according to the application category to which the target application belongs, wherein for real-time audio and video applications, the collection weight of the jitter index is increased and the probing frequency is increased; for transactional applications, the collection weight of the round-trip delay and packet loss rate indexes is increased; for large file transmission applications, the collection weight of the throughput rate index is increased; an abnormal heat factor: when it is detected that the target application has appeared degradation or failure level more than a preset threshold value in a preset number of window periods, it is determined that the abnormal heat is increased, and the probing frequency of the target application is increased to a third probing frequency, and the index collection dimension is expanded to include more fine-grained diagnostic indexes; when there is no longer degradation or failure level in a continuous preset number of window periods, the probing frequency is restored to a regular level.

5. The integrated communication network service quality closed loop verification method of claim 1, wherein, The automatic triggering of the preset settlement or compensation process comprises: when the cumulative length of time when the window experience level is at a failure level reaches a first length threshold value, a daily average amount of the monthly service fee is exempted; When the cumulative duration of the window experience level being the failure level reaches a second duration threshold, the entire amount of the current month service fee is exempted; The second duration threshold is greater than the first duration threshold.

6. The integrated communication network service quality closed loop verification method of claim 1, wherein, The data of the window period is generated to include a forensic record of a cryptographic school experience value, including: The data records in the window period are arranged in chronological order; A hash value is calculated for each data record, and the hash value of the current data record is chained with the hash value of the previous data record to form a chained hash sequence; A trusted timestamp is obtained and the end hash value of the chained hash sequence is digitally signed; The chained hash sequence, the trusted timestamp and the digital signature are stored as the forensic record to a read-only storage medium.

7. The integrated communication network service quality closed loop verification method of claim 1, wherein, The end-to-end network performance data of the target application is obtained, including: First network performance data is obtained by an active measurement method, and the active measurement method includes at least one of TCP handshake detection, TLS handshake detection, HTTP endpoint detection and small file transmission detection; And / or, second network performance data is obtained by a passive measurement method, and the passive measurement method includes session statistics and application layer throughput observation on actual business traffic.

8. The integrated communication network service quality closed loop verification method of claim 1, wherein, The process of generating the service realization rate indicator based on the pre-defined service side feedback signal includes the steps of performing semantic analysis and dynamic weighting of application layer protocol metadata: For the response message header or load content of the target application, a resource control field value representing the resource quota state is extracted, and the resource control field value includes the remaining number of calls, the token bucket state or the computing resource queue depth; A nonlinear scoring decay model is constructed to map the resource control field value to a normalized service availability score, wherein when the resource control field value indicates that the service is about to trigger a fuse or a flow limit, the service availability score exponentially decays; In the comprehensive judgment level, if the service availability score is lower than a preset critical threshold, a "one vote veto" mechanism is triggered, the excellent indicators in the network performance data are ignored, and the window experience level is directly locked as a failure level to represent an implicit failure state of network connectivity but service unavailability.

9. A comprehensive communication network service quality closed-loop verification system, comprising a processor and a memory, wherein the memory stores computer-executable instructions, characterized in that, The processor executes the executable instructions to cause the system to implement the method of any one of claims 1-8.

Images