A data transmission detection method, electronic equipment, storage medium and product

Abstract

The application discloses a data transmission detection method, electronic equipment, storage medium and product. The method comprises the following steps: obtaining first data and second data; wherein the first data is an audit snapshot voucher generated by a sending end; the audit snapshot voucher is a non-tamperable snapshot storage voucher generated in real time for streaming service data; the second data is a receiving end confirmation voucher generated by a receiving end; the receiving end confirmation voucher is a feedback confirmation voucher generated after the receiving end completes data reception; a pre-set rule library is traversed to determine a first rule corresponding to the first data and the second data; and a first report is generated according to the first rule and a first confidence degree corresponding to the first rule. The technical scheme can realize accurate abnormal transmission tracing, full-process visual control, greatly simplify the troubleshooting process, reduce operation and maintenance costs, and effectively adapt to the efficient operation and maintenance and compliance tracing requirements of complex wide area network multi-node transmission.

Description

Technical Field

[0001] This invention relates to the field of security and transmission technology, and in particular to a data transmission detection method, electronic device, storage medium, and product. Background Technology

[0002] Currently, the industry commonly uses hash algorithms such as MD5 and SHA-256 combined with Merkle tree structures for data integrity verification. This method is mostly used for static data storage verification and end-to-end consistency comparison after transmission. Meanwhile, various commercial transmission acceleration software in wide area network scenarios mainly rely on multi-threaded transmission and proprietary communication protocols to improve throughput efficiency, but their integrity assurance is all based on end-to-end post-verification mode, and audit logs only retain the final transmission result, not covering the entire transmission process.

[0003] Current mainstream solutions focus solely on proving the integrity of the data itself, with compliance verification typically completed after transmission via hash comparison and Merkle block tree verification. However, this technical architecture has significant shortcomings: First, audit credentials only retain data fingerprint information, failing to establish a correlation with the system status and operating parameters throughout the transmission process; second, in the event of transmission anomalies or verification failures, only data corruption or tampering can be identified, without accurately distinguishing the source of the fault or determining whether the problem originates from the sender, network link, or receiver. Furthermore, existing data integrity auditing capabilities are independent of the overall operation and maintenance monitoring system, outputting only a binary judgment of pass or fail, without simultaneously recording key operational indicators during transmission, resulting in severely insufficient visibility and traceability throughout the process. Summary of the Invention

[0004] This invention provides a data transmission detection method, electronic device, storage medium, and product that can achieve accurate source tracing of transmission anomalies, full-process visibility and control, greatly simplifying troubleshooting processes, reducing operation and maintenance costs, and effectively adapting to the needs of efficient operation and maintenance and compliant source tracing for complex wide area network multi-node transmission.

[0005] According to one aspect of the present invention, a data transmission detection method is provided, the method being executed by a service layer, the method comprising: Acquire first data and second data; wherein, the first data is an audit snapshot certificate generated by the sending end; the audit snapshot certificate is an immutable snapshot evidence certificate generated in real time for streaming business data; the second data is a receiver confirmation certificate generated by the receiving end; the receiver confirmation certificate is a feedback confirmation certificate generated by the receiving end after completing data reception. Traverse the pre-set rule base to determine the first rule corresponding to the first data and the second data; wherein, the first rule is used to characterize the data transmission failure situation between the sending end and the receiving end; A first report is generated based on the first rule and the first confidence level corresponding to the first rule.

[0006] According to another aspect of the present invention, a data transmission detection method is provided, the method being performed by a sending end, the method comprising: Obtain third data; wherein, the third data is streaming business data; The third data is divided into blocks to obtain individual first data blocks; Perform a hash operation on the first data block within the pre-configured sliding window to obtain the first hash value; The root node of the pre-set node tree is updated based on the first hash value to obtain the second hash value; First data is generated based on the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value; wherein, the fourth data is the running status data of the sending end; and the third hash value is the hash value generated in the previous round of update.

[0007] According to another aspect of the present invention, a data transmission detection method is provided, the method being performed by a receiving end, the method comprising: Obtain the fifth data; The fifth data is parsed to determine the first data and the control frame; The first data and the control frame are verified to obtain the verification result. The second data is generated based on the verification result and the sixth data; wherein, the sixth data is the operating status data of the receiving end; The second data is uploaded to the service layer asynchronously.

[0008] According to another aspect of the present invention, a data transmission detection apparatus is provided, the apparatus being configured in a service layer, the apparatus comprising: The data acquisition module is used to acquire first data and second data; wherein, the first data is an audit snapshot certificate generated by the sending end; the audit snapshot certificate is an immutable snapshot evidence certificate generated in real time for streaming business data; the second data is a receiver confirmation certificate generated by the receiving end; the receiver confirmation certificate is a feedback confirmation certificate generated by the receiving end after completing data reception. The first rule determination module is used to traverse a pre-set rule base to determine the first rule corresponding to the first data and the second data; wherein, the first rule is used to characterize the data transmission failure situation between the sending end and the receiving end; The first report generation module is used to generate a first report based on the first rule and the first confidence level corresponding to the first rule.

[0009] According to another aspect of the present invention, a data transmission detection device is provided, the device being configured at a transmitting end, the device comprising: The third data acquisition module is used to acquire third data; wherein, the third data is streaming business data; The first data block obtaining module is used to divide the third data into blocks to obtain each first data block; The first hash value acquisition module is used to perform hash operations on the first data block within a pre-configured sliding window to obtain the first hash value; The second hash value acquisition module is used to update the root node of the pre-set node tree based on the first hash value to obtain the second hash value; The first data generation module is used to generate first data based on the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value; wherein the fourth data is the running status data of the sending end; and the third hash value is the hash value generated in the previous round of update.

[0010] According to another aspect of the present invention, a data transmission detection device is provided, the device being disposed at a receiving end, the device comprising: The fifth data acquisition module is used to acquire the fifth data. The first data determination module is used to parse the fifth data to determine the first data and the control frame; The verification result acquisition module is used to verify the first data and the control frame to obtain the verification result; The second data generation module is used to generate second data based on the verification result and the sixth data; wherein the sixth data is the running status data of the receiving end; The second data upload module is used to asynchronously upload the second data to the service layer.

[0011] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a data transmission detection method according to any embodiment of the present invention.

[0012] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement a data transmission detection method according to any embodiment of the present invention.

[0013] According to another aspect of the present invention, a computer product is provided, wherein the computer program is configured to cause a processor to execute a data transmission detection method as described in any embodiment of the present invention.

[0014] The technical solution of this invention involves acquiring first data and second data; traversing a pre-set rule base to determine a first rule corresponding to the first data and the second data; and generating a first report based on the first rule and the first confidence level corresponding to the first rule. This technical solution enables accurate source tracing of transmission anomalies, full-process visibility and controllability, significantly simplifies troubleshooting processes, reduces operation and maintenance costs, and effectively adapts to the efficient operation and maintenance and compliant source tracing requirements of complex wide area network multi-node transmission.

[0015] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of a data transmission detection method provided in Embodiment 1 of the present invention; Figure 2 This is a system architecture diagram provided for Embodiment 1 of this application; Figure 3 The flowchart for audit analysis and intelligent fault delimitation provided in Embodiment 1 of this application; Figure 4 A flowchart of another data transmission detection method provided in Embodiment 2 of the present invention; Figure 5 This is a flowchart of the sending-end streaming audit and transmission process provided in Embodiment 2 of this application; Figure 6 This is a flowchart of another data transmission detection method provided in Embodiment 3 of the present invention; Figure 7 This is a flowchart of the receiver verification and evidence chain closed loop provided in Embodiment 3 of this application; Figure 8 This is a key interaction timing diagram provided for Embodiment 3 of this application; Figure 9 This is a schematic diagram of the structure of a data transmission detection device provided in Embodiment 4 of the present invention; Figure 10 This is a schematic diagram of another data transmission detection device provided in Embodiment 5 of the present invention; Figure 11 This is a schematic diagram of the structure of another data transmission detection device provided in Embodiment Six of the present invention; Figure 12 This is a schematic diagram of the structure of an electronic device that implements a data transmission detection method according to an embodiment of the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] Example 1 Figure 1 This is a flowchart of a data transmission detection method according to Embodiment 1 of the present invention. This embodiment is applicable to data transmission detection. The method can be executed by a data transmission detection device, which can be implemented in hardware and / or software and can be configured in a device. For example, the device can be a backend server or other device with communication and computing capabilities. The method is executed by the service layer, such as... Figure 1 As shown, the method includes: S110. Obtain first data and second data; wherein, the first data is an audit snapshot certificate generated by the sending end; the audit snapshot certificate is an immutable snapshot evidence certificate generated in real time for streaming business data; the second data is a receiver confirmation certificate generated by the receiving end; the receiver confirmation certificate is a feedback confirmation certificate generated by the receiving end after completing data reception.

[0021] In this plan, Figure 2 The system architecture diagram provided for Embodiment 1 of this application is as follows: Figure 2 As shown, the system consists of a sender, a receiver, and a service layer deployed along the data path. The sender and receiver, deployed on the client host, are the core software, integrating high-throughput transmission, streaming auditing, and diagnostic data acquisition capabilities. Asynchronous pipelines ensure that audit calculations do not block the main data stream. Simultaneously, through protocol stack integration, it achieves the encapsulation and parsing of custom In-Protocol Control Frames (IPCF), realizing deep coupling between transmission and auditing. The service layer uses the Audit Log Service (ALS) as a unified data aggregation node, combined with the Fault Localization Engine (FLE) relying on a rule base to complete intelligent analysis, forming a complete operation and audit control system.

[0022] In this embodiment, Figure 3 The flowchart for audit analysis and intelligent fault delimitation provided in Embodiment 1 of this application is as follows: Figure 3 As shown, this illustrates how the backend service utilizes the trusted evidence chain generated in the preceding stages to perform automated and intelligent fault diagnosis and report generation.

[0023] The first data is the audit snapshot certificate generated by the sending end; the audit snapshot certificate is an immutable snapshot evidence certificate generated in real time for streaming business data; the second data is the receiver confirmation certificate generated by the receiving end; the receiver confirmation certificate is a feedback confirmation certificate generated by the receiving end after the receiving end completes the data reception.

[0024] Specifically, the Fault Delimitation Engine (FLE) queries the first and second data from the audit log service. The Fault Delimitation Engine (FLE) is a core component for intelligent fault analysis and root cause localization, designed for streaming and distributed business scenarios.

[0025] Optionally, obtain the first data and the second data, including: When a trigger condition is detected, first data and second data are acquired; wherein, the trigger condition includes at least one of the following: the timing duration reaches a preset time threshold, or a preset trigger action is identified.

[0026] In this scheme, the triggering conditions include at least one of the following: the timing duration reaches a preset time threshold, or a preset triggering action is detected.

[0027] In this embodiment, when the Fault Demarcation Engine (FLE) detects the triggering condition, it queries and retrieves first data and second data from the audit log service. The first data and second data together constitute an ASC-RAC bidirectional credential chain that completes the association binding.

[0028] This on-demand, trigger-based data acquisition mechanism is flexible and controllable. It can automatically initiate the data retrieval process based on timed periods or specified event actions, enabling the fault delimitation engine to accurately retrieve strongly associated ASC-RAC bidirectional credential chain data at appropriate times. Conditional triggering of data collection avoids the resource consumption of routine full-volume queries, reducing system computation and access load. It also allows for timely retrieval of complete paired audit credentials in scenarios of anomalies or periodic inspections, providing complete, time-aligned, and mutually corroborating reliable data support for subsequent rule-based reasoning, link tracing, and accurate fault delimitation. This effectively improves the real-time performance, relevance, and overall operational efficiency of fault analysis.

[0029] S120. Traverse the pre-set rule base to determine the first rule corresponding to the first data and the second data; wherein, the first rule is used to characterize the data transmission failure situation between the sending end and the receiving end.

[0030] In this solution, the system's pre-defined rule base contains multiple clearly categorized candidate rules, covering various typical anomaly scenarios. For example, rule R1 is used to determine resource bottleneck faults at the sending end, rule R2 is used to identify network anomalies such as downlink packet loss and excessive transmission latency, and rule R3 is used to specifically identify local operational faults such as abnormal storage read / write operations and data processing overload at the receiving end.

[0031] In this embodiment, the first rule is used to characterize data transmission failure between the sender and receiver. For example, the first rule can be rule R1 or rule R2.

[0032] Specifically, the fault delimitation engine loads a predefined rule base, performs automated credential chain correlation analysis and logical judgment on the first and second data, and determines the first rule corresponding to the first and second data. For example, when the first data shows that CPU resources are continuously under high load, the sliding window is adaptively expanding, and the verification latency of the second data is increasing synchronously, rule R1 is automatically matched; if the second data is completely retained, but the corresponding second data is missing, rule R2 is accurately matched, thereby realizing intelligent identification of various transmission and device anomalies.

[0033] Furthermore, the fault delimitation engine loads a dynamically iterative and flexibly expandable rule base to traverse and intelligently analyze each pair of paired ASC-RAC associated credential data. This rule base adopts a modular and scalable design, enabling continuous iteration, supplementation, and smooth expansion as operational experience and fault scenarios accumulate, adapting to the identification needs of diverse business anomaly scenarios.

[0034] For example, rule R1 is used to identify resource bottlenecks at the sending end. When the CPU utilization rate in the diagnostic metadata carried by multiple consecutive first data messages is consistently higher than 85%, the sliding window size shows an increasing trend, and the verification latency of the corresponding second data message increases synchronously, it can be determined with high confidence that the sending end's computing resources are insufficient. Rule R2 targets downlink network anomaly scenarios. If the sending end generates and reports the first data normally, but the matching second data is missing, or the difference between the high-precision timestamps at both ends significantly exceeds the baseline network latency range, it can be determined with medium confidence that there is a downlink packet loss, congestion, or transmission delay problem. Rule R3 focuses on receiver operational anomalies. Under the premise that the first data is complete and valid, if the verification result of the second data fails and the receiver's diagnostic metadata does not detect obvious network anomaly indicators, the fault can be located with medium confidence as originating from receiver storage read / write anomalies, data processing overload, or hardware media failure.

[0035] S130. Generate a first report based on the first rule and the first confidence level corresponding to the first rule.

[0036] The first confidence level is used to characterize the credibility of the first rule and can be quantified as a percentage. For example, the first confidence level for the first rule is 90%.

[0037] In this embodiment, the first report is a data transmission detection and analysis report, which includes integrity verification results, suspected fault links, related time periods, key performance indicator deviation charts, troubleshooting suggestions, etc.

[0038] Specifically, based on the final decision results, the system automatically completes the standardized compilation and structured output of the first report: It categorizes and displays various diagnostic conclusions according to three major fault domains: the sending end, the transmission network, and the receiving end, with each result accompanied by a quantitative confidence level and a summary of core evidence. Simultaneously, it automatically correlates operational data from the abnormal period, generating trend visualization charts of key indicators such as CPU load and transmission latency, presenting the abnormal characteristics and data basis in an intuitive manner. Furthermore, by combining the diagnostic conclusions with the built-in troubleshooting knowledge base, it outputs targeted, clear, and feasible operation and maintenance suggestions, specifying concrete operational steps and detection methods, thus achieving an integrated closed loop of fault diagnosis, evidence display, and auxiliary handling.

[0039] The fault delimitation engine integrates all rule analysis results and quantitative confidence levels. Relying on the bidirectional correlation credential evidence chain and sender-receiver diagnostic metadata, it automatically analyzes and generates an integrated audit diagnostic report covering transmission integrity conclusions, suspected fault ranges, abnormal timelines, and key performance indicators. This upgrades traditional passive anomaly alarms to intelligent diagnostic capabilities that can accurately distinguish fault domains and output root cause probabilities. It achieves a technological leap from basic compliance auditing to proactive fault assessment, effectively solving the prominent problems of traditional operation and maintenance relying too much on manual labor and low fault troubleshooting efficiency.

[0040] Optionally, based on the first rule and the first confidence level corresponding to the first rule, a first report is generated, including: Determine the second confidence level corresponding to the first rule; wherein, the second confidence level is the original confidence level; The second confidence level is multiplied by a pre-set confidence level weight to obtain the third confidence level; The first confidence level corresponding to the first rule of the same type is obtained by summing all the third confidence levels. The second rule is selected from the first rule based on the first confidence level; Based on the detection results corresponding to the second rule, a first report is generated.

[0041] In this solution, the system pre-determines differentiated weightings for various rules, assigning higher weights to direct measurement rules and deterministic rules, while reducing the weights of indirect derivation rules and rules susceptible to noise fluctuations. For example, CPU utilization in the sender's diagnostic metadata is a real-time direct acquisition rule, and its weight is higher than that of indirect derivation parameters such as sliding window size; while deterministic judgment rules such as receiver verification failure have significantly higher weights than reference rules that are susceptible to environmental noise, such as verification delay fluctuations, thus ensuring the accuracy and rationality of reasoning and judgment.

[0042] In this embodiment, the second confidence level corresponding to the first rule is determined based on the fault delimitation engine; wherein, the second confidence level is the original confidence level.

[0043] Furthermore, by multiplying the second confidence level by the corresponding weight, the corrected third confidence level is finally calculated.

[0044] Specifically, the first rule of the same type refers to multiple rules pointing to the same root cause of the failure. The system collects the third confidence scores corresponding to all the first rules under this type of target and sums them up. Through the fusion and superposition of multi-rule evidence, the system finally aggregates and calculates the first confidence score corresponding to the unified failure conclusion of this type.

[0045] In this embodiment, the first rule is composed of multiple independent candidate rules, and there may be conflicting judgment conclusions among different candidate rules. The system selects the best rule based on the first confidence level corresponding to each fault conclusion, and outputs the optimal second rule from the first rule set, thereby completing the automatic identification and resolution of conflicting rules, and ensuring that the final diagnosis conclusion is unique, reasonable and reliable.

[0046] Specifically, typical scenarios are as follows: Rule A determines the sender resource bottleneck based on high CPU usage, with a weighted confidence score of 85; Rule B determines the network downlink anomaly based on missing RAC credentials, with a weighted confidence score of 80. The specific arbitration mechanism includes four optional strategies: First, a confidence-priority strategy, directly selecting the conclusion with the highest comprehensive score as the final judgment result; in this example, the sender bottleneck will be prioritized. Second, the principle of direct evidence, prioritizing core evidence from more fundamental sources and with more direct relevance, such as network native indicators like missing messages and credentials, which have higher priority than indirect system resource representation parameters. Third, time window linkage analysis; if the confidence scores of two conflicting conclusions change alternately over time and their temporal sequences are correlated, a comprehensive judgment can be made regarding a complex cascading failure, such as excessive sender load leading to network queue congestion and transmission blockage. Fourth, an uncertainty fallback strategy; when multiple pieces of evidence contradict each other and the conflict cannot be effectively resolved, the system outputs an uncertain conclusion and lists multiple competing judgment results to assist maintenance personnel in conducting manual review and in-depth investigation.

[0047] This processing flow, which combines multi-level confidence weighted fusion, aggregation and superposition of homogeneous rules, and multi-strategy conflict arbitration mechanism, can quantify and distinguish the reference value of different evidence, effectively resolve conflicts in multi-rule judgments, accurately output the optimal diagnostic conclusion, significantly improve the scientificity, accuracy and interpretability of fault root cause analysis, and reduce the cost of manual investigation.

[0048] The technical solution of this invention involves acquiring first data and second data; traversing a pre-set rule base to determine a first rule corresponding to the first data and the second data; and generating a first report based on the first rule and the first confidence level corresponding to the first rule. By executing this technical solution, accurate source tracing of transmission anomalies can be achieved, and the entire process can be visualized and controlled, greatly simplifying the troubleshooting process, reducing operation and maintenance costs, and effectively adapting to the efficient operation and maintenance and compliant source tracing requirements of complex wide area network multi-node transmission.

[0049] Example 2 Figure 4 This is a flowchart of another data transmission detection method provided in Embodiment 2 of the present invention. The method is executed by the sending end, such as... Figure 4 As shown, the method includes: S410. Obtain third data; wherein, the third data is streaming service data.

[0050] In this embodiment, before the transmission session is established, the sending end and the receiving end pre-complete two-way identity authentication through a certificate-based TLS (Transport Layer Security) secure channel, and negotiate various core operating parameters of this communication session, including: single transmission data block size, initial sliding window size, hash algorithm used for Merkle tree verification, digital signature algorithm for business data, and diagnostic metadata collection switch identifier; at the same time, the two parties exchange public key credentials to provide a trusted foundation for subsequent end-to-end data signature verification, integrity verification, and security auditing.

[0051] In this plan, Figure 5 This is a flowchart of the sending-end streaming audit and transmission process provided in Embodiment 2 of this application, as follows: Figure 5 The diagram illustrates the entire process from receiving streaming service data to generating, encapsulating, and transmitting audit credentials at the sending end. Its core is a "transmit-and-compute" streaming processing model.

[0052] The third type of data is streaming service data. Streaming service data is a continuous, real-time, and uninterrupted stream of business data. The data is generated continuously in chronological order and transmitted and processed one by one or in segments. It is not stored in the database in batches at once, and requires low latency and real-time processing, which is different from offline data that is processed in batches at scheduled times. For example, streaming service data can be network communication logs, video streams, real-time voice services, etc.

[0053] Specifically, the sending end acquires third-party data in real time.

[0054] S420. Divide the third data into blocks to obtain each first data block.

[0055] In this scheme, the third data is evenly divided according to a preset fixed data block size, and split into several independent first data blocks. .

[0056] Furthermore, each first data block is sequentially stored into a fixed-capacity sliding window for unified scheduling and management according to the transmission order. All data blocks are written to the sliding window buffer using a first-in, first-out mechanism, and the window capacity remains constant. When the window is full and a new data block is written, the earliest stored data block is automatically removed, completing the cyclical replacement.

[0057] S430. Perform a hash operation on the first data block within the pre-configured sliding window to obtain the first hash value.

[0058] In this scheme, when the sliding window fills up or the timer times out, the asynchronous audit pipeline is triggered immediately, and the main data sending thread is not blocked. In the asynchronous pipeline, the hash values ​​of all first data blocks within the sliding window are calculated to obtain the first hash value.

[0059] Specifically, when the amount of data in the sliding window reaches a preset threshold, or when the timer times out and triggers a time-limiting mechanism (to avoid delays in the generation of audit vouchers in sparse data flow scenarios), the system immediately wakes up an independent audit calculation thread or a coroutine to perform the calculation asynchronously; the main thread does not need to be blocked and can continuously process subsequent data sending and receiving tasks in parallel, thereby achieving asynchronous decoupling and overlapping execution of audit calculation and network input or output operations, effectively improving the overall transmission and processing efficiency.

[0060] In this embodiment, the data volume threshold is typically set to 50%-80% of the sliding window capacity. This ensures that calculations begin before the window is full, closely aligning voucher generation with the data flow schedule and avoiding unnecessary delays caused by waiting for the window to fill, thus optimizing the real-time nature of auditing. The time-based threshold (timer) serves as a necessary supplement to the data volume threshold, primarily addressing situations with sparse or fluctuating data flows. Its timeout period is set based on the maximum tolerable audit latency, such as 100 milliseconds. This guarantees that audit vouchers can be generated periodically even during low-traffic periods, meeting the requirements of continuous monitoring.

[0061] Specifically, for each data block within the current sliding window Calculate its cryptographic hash value to generate the corresponding first hash value. .

[0062] S440. Update the root node of the pre-set node tree according to the first hash value to obtain the second hash value.

[0063] The system's overall node tree is organized using a Merkle tree (hash tree) architecture. This structure is based on hierarchical hash iterative computation, which divides fragmented streaming business data into blocks, calculates hash digests independently, aggregates them layer by layer upwards to generate hashes for higher-level nodes, and finally forms a unique root hash value, i.e., the second hash value.

[0064] Specifically, the system does not need to completely rebuild the Merkle tree for each sliding window, but instead continuously maintains a dynamically iterative tree structure. When a new first hash value... The old hash value enters the window along with the data block. When moving out of the window, only all tree nodes along the path from the old and new leaf nodes to the root node are incrementally updated. Specifically, the hashes of the left and right child nodes of each intermediate node are persistently stored. After a leaf node is added, removed, or replaced, the hash of the parent node is recalculated iteratively layer by layer from bottom to top. Finally, the root hash corresponding to the current sliding window is updated and output. This is the second hash value. This incremental update mechanism avoids redundant full computation, reducing the overall algorithm complexity from... Optimized to near This significantly improves computational efficiency.

[0065] Optionally, the root node of a pre-set node tree is updated based on the first hash value to obtain a second hash value, including: Determine the target node corresponding to the first hash value; Traverse the pre-set node tree to determine the target path between the target node and the root node; the target path includes the target node, the root node, and all intermediate nodes between the target node and the root node, and the nodes are arranged in order from the target node to the root node. According to the node order of the target path, the first data block associated with each node is hashed sequentially to obtain the second hash value step by step; wherein, the second hash value is the final hash value obtained after hashing the first data block associated with the root node.

[0066] In this scheme, firstly, the Merkle tree target node corresponding to the first hash value to be updated is accurately located; then, the pre-constructed global node tree structure is traversed to retrieve and determine the complete target path from the target node to the top-level root node. This target path strictly covers the target node, all intermediate parent nodes at all levels, and the final root node. All nodes are arranged in an orderly manner from the bottom leaf nodes upwards to the root node, forming a unique iterative update link.

[0067] Subsequently, following the determined target path, hash iteration calculations are carried out level by level according to the node arrangement order from bottom to top: first, the hash replacement and assignment of the target node are completed, and then the hash values ​​of the corresponding sibling nodes are combined to re-aggregate and calculate the new hash digests of the intermediate nodes at each level layer by layer; the update is recursively updated layer by layer, and the hash data of the parent node at the upper level is corrected level by level until the hash recalculation of the top root node is completed.

[0068] Finally, the final hash result of the root node obtained after the step-by-step update along the entire path is the second hash value corresponding to the current sliding window. This incremental update method only modifies a small number of nodes on the target path, while the data of the remaining non-related branches and nodes in the tree are completely preserved. There is no need to reconstruct the entire tree, which significantly reduces the hash calculation overhead while ensuring the accuracy of data integrity verification.

[0069] Specifically, taking a Merkle tree containing 8 data blocks as an example, the leaf nodes are H1 to H8, corresponding to the first hash value of each data block. As the sliding window iterates forward, the hash value of the new data block... Replaced the old hash In this example, the original leaf node H3 is replaced, completing the update and replacement of the leaf node at the specified position.

[0070] Furthermore, locating and replacing leaf nodes: the system first locates... The location of the leaf node (H3). Update the hash value of this node to... .

[0071] The process proceeds from bottom to top, updating parent nodes layer by layer: After updating a leaf node, the hashes of its ancestor nodes are recursively recalculated from that leaf node upwards, layer by layer, until the root node. This process involves only one path.

[0072] Step 1 (Update parent node A): Find The parent node (assuming it is the middle node) Its original hash was calculated from H3 and H4. Since child node H3 has become... Therefore, it is necessary to use Combine the hashes of node A and its sibling node H4 to recalculate a new hash for node A.

[0073] .

[0074] Step 2 (Update parent node C): After node A is updated, its parent node (let's assume it's the higher-level node C, whose original hash was calculated from A and B) also becomes invalid. Therefore, using... Using the hash of its sibling node B, recalculate the new hash of node C.

[0075] .

[0076] Step 3 (Update Root Node): After node C is updated, the root node is updated last. The root node hash is recalculated using the hash of its sibling node D and the hash of its sibling node D.

[0077] .

[0078] At this point, the path from leaf node H3 to the root node (H3 -> A -> C -> Root) has been completely updated. All other nodes in the tree not on this path (such as subtrees rooted at H1, H2, H5, H6, H7, and H8) remain unchanged. The new root hash... That is, the second hash value of the current window. .

[0079] By locating the target node to be updated and extracting its unique update path to the root node, incremental hash recalculation is performed only on the nodes along the path from bottom to top. This eliminates the need for a full reconstruction and repetitive calculation of the entire Merkle tree, effectively reducing redundant operations and lowering the algorithm's time complexity. Simultaneously, relying on a sliding window combined with the Merkle tree's dynamic update mechanism, the system achieves efficient real-time generation of audit credentials while ensuring the integrity, immutability, and verifiability of batch data blocks. It balances data security verification, transmission processing performance, and resource consumption, adapting to various data stream transmission scenarios such as high-frequency, continuous, and sparse data streams, significantly improving the overall system's concurrent processing capabilities and operational efficiency.

[0080] S450. Generate first data based on the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value; wherein, the fourth data is the running status data of the sending end; and the third hash value is the hash value generated in the previous round of update.

[0081] In this solution, the system synchronously collects real-time operational status data from the transmitting end, and uniformly aggregates multi-dimensional monitoring indicators, including the utilization rate of CPU cores bound to the audit thread, the available percentage of system memory, the real-time sliding window size under dynamic load control, the backlog depth of the network protocol stack sending queue, and high-precision local timestamps and other operational parameters. The above full status information is integrated and summarized into System Diagnostic Metadata (SDM), and uniformly defined as the fourth type of data, providing complete and fine-grained basic data support for subsequent link anomaly analysis, load assessment, and fault tracing.

[0082] In this embodiment, the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value are assembled and signed with a private key to generate an Audit Snapshot Credential (ASC), which is the first data.

[0083] Specifically, the sender's private key is used. ,right timestamp Sliding window Third hash value (Used to form a chain) and the plaintext or hash of the fourth data are digitally signed to generate Finally, it is assembled into an enhanced audit snapshot certificate, i.e., the first data: .

[0084] Optionally, after generating the first data based on the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value, the method further includes: Based on the first data and the pre-set control frame, the fifth data is generated; wherein the control frame is used to transmit verification information; The first data is asynchronously uploaded to the service layer; and the fifth data is sent to the receiving end.

[0085] In this scheme, the In-Protocol Control Frame (IPCF) is used to transmit verification information.

[0086] In this embodiment, the generated first data is uniformly encapsulated into a custom IPCF control frame of the uQUIC (ultra-light Quick UDP Internet Connections) and uRDMA (ultra-light Remote Direct Memory Access) underlying transport protocols to complete network transmission; the sending end uQUIC and other protocol stacks add a dedicated control frame type, and the protocol encapsulation adapter serializes the current audit snapshot data. Perform payload filling to achieve standardized encapsulation of protocol messages.

[0087] Specifically, the control frame and the encrypted user data frame share the same uQUIC or uRDMA transmission connection, and are uniformly scheduled and transmitted in a mixed manner by the network stack, achieving co-transmission of control signaling and service data. The receiving end protocol stack can accurately identify this custom frame type, automatically complete message parsing and payload stripping, and forward it to the local audit module for processing. No additional transmission connection needs to be established throughout the process, and no additional round-trip time (RTT) is added. Simultaneously, the first data is asynchronously reported to the service layer, and the fifth data is reliably pushed to the receiving end, ensuring efficient transmission of audit signaling while balancing link resource reuse and overall communication real-time performance.

[0088] The technical solution of this invention involves: acquiring third data; dividing the third data into blocks to obtain first data blocks; performing a hash operation on the first data blocks within a pre-configured sliding window to obtain a first hash value; updating the root node of a pre-set node tree based on the first hash value to obtain a second hash value; and generating first data based on the second hash value, the sequence number of the sliding window, the timestamp, fourth data, and the third hash value. By executing this technical solution, real-time, low-overhead integrity proof for an infinite data stream is achieved through an incremental sliding window Merkle tree, overcoming the latency problem of traditional post-audit. Simultaneously, the asynchronous pipeline design of the audit task decouples intensive computation from data transmission, ensuring that high-throughput transmission performance is not affected. Furthermore, the diagnostic metadata binding and credential protocol embedding technology respectively associate the transmission process state with the cryptographic integrity proof and eliminate the overhead of establishing an independent audit channel, thereby generating a lightweight, context-rich, trusted credential at the source.

[0089] Example 3 Figure 6 This is a flowchart of another data transmission detection method provided in Embodiment 3 of the present invention, which is executed by the receiving end. Figure 6 As shown, the method includes: S610, Obtain the fifth data.

[0090] In this plan, Figure 7 The flowchart of the receiver verification and evidence chain closed loop provided in Embodiment 3 of this application is as follows: Figure 7 As shown, this demonstrates how the receiving end processes data and audit credentials in parallel, completing verification and forming a closed loop of an end-to-end trusted evidence chain.

[0091] Specifically, the receiving end receives the fifth data sent by the sending end.

[0092] S620. Analyze the fifth data to determine the first data.

[0093] Specifically, the receiving end protocol stack parses the fifth data to determine the first data.

[0094] S630. Verify the first data to obtain the verification result.

[0095] In this embodiment, the extracted first data is sent to the asynchronous verification pipeline to perform multiple verification operations in parallel: verifying the validity of the sender's signature and the integrity and continuity of the credential chain; based on the received first data, the Merkle tree is reconstructed locally using the same-source algorithm, and a bidirectional comparison of the root hash value is completed; verifying whether the third hash value in the first data is consistent with the hash value updated in the previous round stored locally; and finally outputting the complete data verification result.

[0096] Specifically, perform the exact same hash calculation and incremental Merkle tree update algorithm as the sender (using the same window size and order) to obtain the locally computed root hash. Comparison and In Are they consistent?

[0097] S640. Generate second data based on the verification result and the sixth data; wherein the sixth data is the operating status data of the receiving end.

[0098] Specifically, upon completion of data verification, multi-dimensional operational and transmission status indicators of the receiving end are collected synchronously and integrated to generate receiver diagnostic metadata (RDM), also known as the sixth data.

[0099] In this scheme, the sixth piece of data includes verification latency, number of out-of-order packet counts, and local high-precision timestamp. Verification latency (verification_latency) represents the time from receiving the data block to completing the root hash. The time consumed by the verification calculation can directly reflect the processing performance of the receiving end. When this indicator rises abnormally while the number of out-of-order packets is normal, it can be directly determined that there is a bottleneck in computing resources or storage latency at the receiving end. The number of out-of-order packets (packet_disorder_count) is the core basis for measuring the quality of the transmission link. Even if the data transmission is complete, a persistently high number of this indicator can also corroborate potential network anomalies such as link congestion and routing fluctuations, and can be used to warn of network jitter and reduced effective throughput. The local high-precision timestamp (local_timestamp) can be accurately matched with the timestamp in the audit snapshot certificate of the sending end, stripping away the processing time of the business at both ends, measuring the pure end-to-end network latency, providing a quantitative basis for Service Level Agreement (SLA) assessment, and relying on a unified high-precision time sequence benchmark, realizing global time sequence calibration and orderly concatenation of audit events across the entire link, and constructing an immutable and complete time sequence audit link.

[0100] Furthermore, by combining the verification results with the sixth data, a Receipt Confirmation Certificate (RAC) is generated, and after being signed, it forms the second data.

[0101] Specifically, the recipient uses their own private key to verify the result (SUCCESS or FAIL) and the corresponding... The identifier and RDM are used to sign and generate a receiver confirmation credential. .

[0102] S650. The second data is asynchronously uploaded to the service layer.

[0103] Specifically, the second data is asynchronously uploaded to the service layer and stored in association with the first data uploaded by the sending end, forming an immutable, dual-perspective complete chain of evidence.

[0104] The technical solution of this invention involves acquiring fifth data; parsing the fifth data to determine first data; verifying the first data to obtain a verification result; generating second data based on the verification result and sixth data; and asynchronously uploading the second data to the service layer. By executing this technical solution, the asynchronous verification pipeline at the receiving end ensures verification efficiency without affecting data storage. The system, by having the receiving end generate and send back confirmation credentials, which are then associated with and stored in the audit service along with the sending end's credentials, naturally forms an immutable two-way chain of evidence. This completely solves the problem of audit silos in distributed transmission, where behavior is difficult to trace and correlate afterward. Simultaneously, the receiving end's diagnostic metadata also provides a basis for evaluating the quality of the network endpoint.

[0105] In this plan, Figure 8 The key interaction timing diagram provided for Embodiment 3 of this application is as follows: Figure 8 As shown, from a temporal perspective, the cross-end collaboration and message interaction sequence of the four roles—sender, receiver, service layer, and fault delimitation engine—when processing a data window is presented.

[0106] Specifically, step one: session initialization and parameter negotiation Before transmission begins, the sender and receiver authenticate each other via a secure channel (such as certificate-based TLS) and negotiate key parameters for the session. These parameters include, but are not limited to: block size (e.g., 1MB), initial sliding window size (e.g., 10 blocks, corresponding to 10MB), hash algorithm used for the Merkle tree (e.g., SHA-256), digital signature algorithm (e.g., ECDSA), and diagnostic metadata collection flags. Both parties exchange public keys used to verify signatures.

[0107] Step 2: Sending end streaming data processing and enhanced audit voucher generation Data Segmentation and Window Management: The streaming business data generated by the sending application is divided into fixed-size data blocks by the segmentation module. These blocks are sequentially pushed into a first-in, first-out (FIFO) sliding window buffer. The window has a fixed capacity, and when a new data block arrives, the oldest data block is removed (if the window is full).

[0108] Triggering the asynchronous audit pipeline: When the amount of data in the window reaches a preset threshold, or a timer times out (to prevent vouchers from being generated late when the data flow is sparse), the system immediately triggers an independent audit calculation thread or coroutine, and the main thread continues to process the subsequent data sending and receiving, so as to achieve the overlap of calculation and input or output.

[0109] Detailed process for generating audit snapshot vouchers (executed in an asynchronous pipeline): Data hash calculation: For each data block within the current sliding window Calculate its cryptographic hash value .

[0110] Incremental Merkle tree construction and updates: The system does not build a complete Merkle tree from scratch for each window. It maintains a dynamic tree structure, updating it with new hash values. Add window (corresponding to old hash) When leaving, only update from and The nodes on the path from the current window to the root are represented. The specific algorithm is as follows: record the left and right child hashes of each intermediate node; when a leaf node changes, recalculate its parent node hash from bottom to top until the root node. Finally, output the root hash of the current window. This method reduces computational complexity from dropped to near .

[0111] Sender diagnostic metadata synchronization collection: at the root hash At the same moment the calculation is completed, the system collects a set of lightweight but critical operational status indicators, which constitute the sender diagnostic metadata (SDM).

[0112] Signature and credential assembly: using the sender's private key ,right timestamp Window serial number The hash of the previous ASCII code (Used to form a chain) and digitally sign the plaintext or hash of the SDM to generate: .

[0113] Finally, it is assembled into an enhanced audit snapshot certificate: .

[0114] Step 3: High-performance packaging and transmission Protocol Embedded Encapsulation: A new control frame type is defined in the network protocol stack of the sending end (such as the uQUIC implementation). The protocol encapsulation adapter will... After serialization, it serves as the payload of the control frame.

[0115] Co-channel transmission: This control frame shares the same uQUIC or uRDMA connection as the encrypted user data frame. The network stack is responsible for scheduling and sending it together with the data frame. The receiver's protocol stack can identify this frame type and extract it for the audit module. The entire process does not establish an additional connection or introduce additional RTT.

[0116] Step 4: Receiver verification, diagnosis and confirmation Parallel processing: The receiving end's protocol stack receives data frames and control frames in parallel. Data frames are decrypted and written to storage; control frames are parsed and their contents extracted. .

[0117] Asynchronous verification pipeline: Signatures and Chained Verification: Verification using the sender's public key middle The validity of [the data / information]. Simultaneously, verify [the data / information]. Check if it matches the hash of the previous ASC stored locally to ensure the continuity of the audit chain.

[0118] Local integrity reconstruction verification: Using the received original data block, perform the exact same hash calculation and incremental Merkle tree update algorithm as the sender (using the same window size and order) to obtain the locally computed root hash. Comparison and In Are they consistent?

[0119] Receiver diagnostic metadata collection: Upon completion of verification, the receiver status is collected to form the RDM. Generate confirmation credentials: The recipient uses their private key to verify the result (SUCCESS or FAIL) and the corresponding... The identifier and RDM are used to sign and generate the receiver's confirmation credential. .

[0120] Step 5: Audit Log Aggregation and Related Storage asynchronous upload from the sending end The receiver asynchronously uploads the corresponding RAC to the audit log service. This service stores each pair (ASC, RAC) in the database in time sequence, on a per-transmission-session basis, forming a complete audit trail chain that is two-way, time-aligned, and rich in diagnostic information.

[0121] Step Six: Intelligent Fault Bounding Analysis The Fault Bounding Engine (FLE) can analyze the audit chain of storage periodically or on demand.

[0122] Data association: FLE precisely pairs the ASCII and RAC values ​​within the same window.

[0123] Rule base analysis: The engine loads a scalable rule base and analyzes each pair of data. Because the core design principle of the rule base is scalability, it should be continuously enriched as operational experience accumulates.

[0124] Report Generation: FLE synthesizes the analysis results of all rules to generate an enhanced, integrated audit and diagnostic report. This report not only lists the final statistics of integrity verification (such as success rate), but also identifies suspected faulty components, related time periods, key performance indicator deviations, and provides preliminary troubleshooting suggestions (such as "check the CPU load of the sending server" and "probe the network quality to the receiving end"). FLE Integrated Analysis and Decision-Making Process Phase 1: Triggering and Collection The engine iterates through all rules in the rule base, applying the current (ASC, RAC) evidence to each input rule for conditional judgment. All triggered rules output their preliminary conclusion (e.g., "Sender CPU bottleneck") and an initial confidence score (e.g., "High"). This stage may collect multiple, even competing, conclusions.

[0125] Phase Two: Quantification and Weighting This stage involves the quantitative integration of the collected conclusions, which is the mathematical core of comprehensive analysis.

[0126] 1. Weight assignment: The system predefines weights for different types of evidence.

[0127] 2. Calculate the overall confidence level: The final confidence level of each rule = the original confidence level × ∑ (the weight of the evidence used for its triggering condition).

[0128] 3. Conclusion Aggregation: The overall confidence scores of all rules pointing to the same fault conclusion (such as "network downlink anomaly") are summed to obtain the total confidence score of the conclusion.

[0129] Phase Three: Conflict Resolution and Decision Making This is the core logic, handling conflicts between rules.

[0130] Scenario: Rule A (based on high CPU) infers "sender bottleneck" (score 85), and Rule B (based on missing RAC) infers "network downlink anomaly" (score 80).

[0131] Arbitration strategy (configurable): 1. Confidence Priority: Adopt the conclusion with the highest score (sender bottleneck).

[0132] 2. Principle of directness of evidence: Adopt conclusions based on more direct and underlying evidence (e.g., missing network packets are more direct evidence of network problems than high CPU usage).

[0133] 3. Time window analysis: If the confidence levels of two conclusions alternate at different time points, it may be inferred that it is a compound fault (such as "overload of the sender leading to network queue accumulation").

[0134] 4. Escalate to Uncertain: If the conflict cannot be resolved, output "Uncertain" and list the competing conclusions for manual evaluation.

[0135] Phase Four: Report Generation Based on the decision-making results, the organization reports: 1. Structured presentation: The final diagnostic items are listed according to the fault domain (sender, network, receiver), and each item is accompanied by the final confidence level (e.g., 90%) and a summary of key evidence.

[0136] 2. Visualization support: Automatically associates and generates performance indicator trend charts (such as CPU and latency) for abnormal time periods, visualizing data evidence.

[0137] 3. Generate suggestions: Based on the diagnostic conclusions, map them to a predefined troubleshooting knowledge base and output specific and actionable suggestions (such as "1. Log in to the sending server 10.0.0.1 and check the CPU usage of process X; 2. Perform ICMP and TCP port probing from the receiving end to the sending end").

[0138] The Incremental Sliding Window Merkle Tree (ISW-MT) streaming audit model primarily addresses the technical pain points of massive streaming business data that cannot wait for transmission to complete before centralized auditing, and the high memory overhead and difficulty in outputting real-time audit nodes when constructing a complete Merkle tree for the entire dataset. This solution uses a fixed-capacity sliding window as the smallest audit unit, dynamically constructing a local Merkle tree only for active data within the window. Combined with an optimized tree update algorithm, only incremental updates of the affected branch hashes are needed during window sliding, requiring only logarithmic-level computational overhead, without the need for a full tree reconstruction. This model boasts multiple technical innovations and advantages: achieving constant memory overhead, with resource consumption only related to the sliding window size and decoupled from the total amount of transmitted data, making it adaptable to ultra-long, unlimited streaming business scenarios ranging from TB to PB; relying on a mechanism of continuous window scrolling updates and synchronous voucher generation, achieving millisecond-level real-time auditing capabilities, meeting the synchronous regulatory needs of highly immediacy-sensitive businesses such as financial transactions; simultaneously, each ASC voucher precisely corresponds to a continuous data window, allowing for rapid identification of problematic data ranges when anomalies are detected, enabling precise location and tracing of violations.

[0139] The fully asynchronous pipeline for auditing tasks, combined with a dynamic negative feedback adjustment mechanism, aims to address the performance bottleneck issue of CPU-intensive computations such as hashing and signing required for integrity proofs. If these computations are executed synchronously on the critical transmission and reception paths, they can easily block I / O and restrict overall throughput. This solution first achieves complete decoupling of production and consumption. A separate auditing computation thread pool is deployed. The main I / O thread acts as the producer, pushing ready data blocks and window information to a lock-free queue. The auditing thread acts as the consumer, asynchronously pulling tasks for parallel computation. The queue enables rate adaptation, achieving complete parallel overlap between I / O interaction and auditing computation. Building upon this, a two-layer collaborative mechanism is formed through queue buffer capacity control and dynamic negative feedback adjustment: a FIFO lock-free buffer with a capacity limit is set, triggering a mild backpressure strategy when the queue is full to prevent infinite task backlog and memory overflow; simultaneously, a load conditioner is incorporated to collect core operating metrics such as task queue depth and CPU utilization in real time, constructing a closed-loop negative feedback control logic. When queue depth or CPU load consistently exceeds limits, the system automatically and linearly expands the sliding window size, reducing the number of audit vouchers generated per unit of data, thus reducing computational pressure at the source. When the system load is high and the queue level is low, the system adaptively shrinks the window and increases the audit granularity, fully releasing idle computing resources. This entire mechanism can dynamically balance the audit task production rate and consumption processing capacity according to load changes, keeping the queue load stable within a reasonable range over the long term. This design achieves zero blocking on critical data transmission and reception paths, fully guaranteeing the high throughput and low latency characteristics of the uQUIC and uRDMA underlying protocol stacks; it also has self-protection capabilities against system overload, and can adaptively reduce audit density under high business load scenarios, prioritizing the stability of core data transmission, significantly improving the overall architecture's operational resilience and environmental adaptability.

[0140] The integrated solution for atomic encapsulation of audit credentials and underlying transport protocols primarily addresses the three-way handshake latency and additional protocol overhead caused by establishing separate TCP connections for transmitting audit credentials, as well as the bandwidth contention between independent congestion control strategies and business data flows. This solution adds a lightweight dedicated control frame to the uQUIC and other user-space protocol stacks. A standardized frame structure is designed, including frame type identifiers, payload length, and variable-length credential payloads. The payload carries a complete, serialized audit credential, encompassing key information such as root hash, timestamp, diagnostic metadata, and digital signature. After generating audit credentials such as ASC and RAC at the sending end, encapsulation and injection are directly completed through the protocol stack extension interface. The receiving end accurately identifies the control frame based on the frame type identifier and quickly extracts the credential content and distributes it to the audit module through a preset callback function, achieving channel reuse and logical isolation between business data flows and audit control flows. Audit control frames are integrated into the protocol stack scheduling and management along with ordinary business data frames, sharing the same transmission queue, encrypted session, congestion control strategy, and reliable retransmission mechanism. They maintain complete coordination in timing scheduling, encryption protection, traffic control, and packet loss compensation, achieving integrated transmission through a single connection and protocol state machine, eliminating the need for additional link construction. This design achieves zero-connection overhead for audit credential transmission, ensuring fairness and consistency between control frames and data frames in network scheduling, bandwidth management, and transmission reliability. Furthermore, leveraging the atomic binding characteristics of co-stream transmission, it ensures a high degree of matching between the arrival order and timing of audit credentials and corresponding business data, effectively simplifying the data and credential association verification logic at the receiving end. This improves audit transmission efficiency and security while enhancing the overall system's network adaptability and operational stability.

[0141] In traditional architectures, operation and maintenance monitoring system metrics and business integrity audit data are fragmented and stored in separate domains, resulting in drawbacks such as inaccurate timestamp alignment, difficulty in post-event correlation analysis, and insufficient evidence credibility. This solution integrates diagnostic metadata synchronous collection logic into the generation chain of ASC audit snapshot credentials and RAC reception confirmation credentials. Within the same atomic critical execution interval of hash operation and digital signature generation, a low-overhead, lightweight collection interface captures the instantaneous system operating status in microseconds, covering CPU utilization, memory pressure, network queue depth, high-precision timestamps, and multi-dimensional diagnostic metadata such as receiver verification latency and message out-of-order count. The collected raw metadata or its digest hash is then concatenated with core audit fields such as Merkle tree root hash and serial number, serving as the raw input for the digital signature. This achieves deep cryptographic binding between the cryptographic fingerprint representing business data integrity and the diagnostic status snapshot representing the instantaneous system operating condition during transmission, within the same time dimension and under the same signature logic. This mechanism fundamentally ensures strong spatiotemporal consistency, temporal uniqueness, and non-repudiation of diagnostic data and audit evidence. It not only solves the problem of difficulty in accurately associating and tracing heterogeneous data, but also transforms isolated and scattered operation and maintenance monitoring indicators into credible and high-value diagnostic evidence strongly coupled with single transmission services, greatly improving the analytical accuracy and reliability of fault delimitation, behavior tracing, and compliance auditing results.

[0142] This intelligent fault delimitation mechanism, based on a chain of associated credentials and a rule engine, fundamentally addresses the pain points of low efficiency and insufficient accuracy in manually troubleshooting after audit verification failures. This solution naturally constructs a bidirectional associated view of the same transmission event between the sender and receiver through paired storage of ASC and RAC credentials, forming a complete and traceable credential evidence chain. Simultaneously, it incorporates an interpretable rule engine based on an "IF-THEN" deterministic structure. Domain experts pre-define rule sets using a fault tree model, with each rule explicitly including fault triggering conditions and corresponding inference conclusions, transforming manual maintenance experience into automatically executable analytical logic. When the rule engine runs, it first performs Boolean judgments on the triggering conditions of all rules for the associated ASC and RAC credentials to be analyzed. The triggering rules output preliminary conclusions and confidence levels. Then, through preset evidence weighting, confidence level merging, and conflict resolution strategies, it completes multi-layered automated decision-making, ultimately generating a unified fault delimitation conclusion with a confidence rating. The entire analysis process is based on a chain of evidence, with transparent and traceable rule mapping, reasoning paths, and final conclusions. This not only automates the analysis of root causes of faults and significantly shortens the mean time to recovery (MTTR), but also, thanks to its interpretability, enables maintenance personnel to clearly understand the origins of the conclusions and quickly take targeted measures. This effectively solves the problem of "finding a needle in a haystack" in traditional fault diagnosis and improves maintenance efficiency and fault location accuracy.

[0143] In summary, the integrated trusted transmission system constructed in this solution is widely adaptable to various high-value, high-requirement cross-domain data interaction scenarios, such as cross-domain gene data migration under the East-West Computing Project, intraday settlement document synchronization for financial institutions, and SLA-compliant cloud services provided by cloud vendors to enterprise customers. The solution deeply integrates the traditionally fragmented and passively handled transmission, integrity verification, link monitoring, and fault diagnosis processes into a self-controllable, intelligently linked, and inherently trustworthy data delivery process. While ensuring the high throughput performance of the underlying transmission is not compromised, the system continuously generates standardized results with cryptographic authority and operational reference value in real time, namely, independently verifiable transmission integrity certificates and link health diagnostic reports. These reports can completely resolve data consistency trust disagreements among multiple parties at the technical level, while significantly reducing the fault diagnosis cycle in cross-domain scenarios, improving the efficiency of source tracing and location from hours or even days to minutes. It can accurately define problem boundaries and quickly pinpoint specific issues such as overloaded computing power at the sending end, abnormal local links in the backbone network, and storage I / O failures at the receiving end. Therefore, this solution can effectively reduce business operation risks, improve cross-organizational collaboration and data flow efficiency, and provide solid support for service compliance and SLA quantitative assessment, thereby continuously strengthening the platform's operational advantages and core business competitiveness.

[0144] This solution presents a streaming data transmission integrity auditing and fault delimitation system, which integrates a comprehensive audit and diagnostic system deeply with wide-area high-throughput transmission protocols (such as uQUIC or uRDMA). Through a unique incremental sliding window Merkle tree technique, it achieves streaming generation of integrity credentials; through asynchronous pipeline design, it ensures that audit computations do not block the high-throughput main data stream; and by cryptographically binding diagnostic metadata such as CPU, memory, and network queues with audit credentials, it makes the system's operational status part of the trusted evidence. Finally, the system utilizes the associated sender-receiver credential chain and a rule engine for automated analysis to accurately locate and diagnose transmission faults (such as sender overload, network congestion, and receiver anomalies), transforming traditional passive auditing into proactive intelligent operation and maintenance.

[0145] By employing "incremental sliding window Merkle tree" and "asynchronous audit pipeline" technologies, the challenge of achieving real-time, streaming data integrity auditing without compromising the performance of wide-area, high-throughput data transmission is solved. This technology abandons the traditional post-event batch verification model, decouples audit calculation from data transmission, and dynamically generates credentials in units of sliding windows, thereby providing continuous integrity proof without affecting the throughput and latency of the main data stream.

[0146] By employing "cryptographic binding of diagnostic metadata and audit credentials" and "fault delimitation based on associated credential chains and rule engines," this technology addresses the operational pain point of traditional auditing, which can only verify data integrity but cannot pinpoint transmission failures. This technology simultaneously embeds a system state snapshot when generating audit credentials and constructs an evidence chain linking the sending and receiving ends. It utilizes interpretable rules for automated analysis, thus upgrading audit output from a simple "pass or fail" binary conclusion to an intelligent diagnostic report that accurately indicates the root cause of the fault (such as problems at the sending end, network, or receiving end).

[0147] This solution represents a paradigm shift from outcome-based judgment to precise diagnosis. It innovatively integrates high-performance streaming integrity auditing with refined O&M fault delineation, overcoming the limitations of existing technologies that only output binary verification conclusions. It can accurately identify the fault's origin and reconstruct real-time operational status, extending auditing capabilities from compliance verification to intelligent O&M. Simultaneously, leveraging an asynchronous pipeline architecture to offload computational load and employing embedded protocol transmission mechanisms to reduce additional network overhead, it achieves full coverage of spatiotemporally unified fine-grained observation data across the entire link while keeping performance loss from high-throughput transmission to within 1%. This effectively addresses industry pain points in O&M monitoring for high-performance business scenarios. Furthermore, the solution combines chained audit credentials and a rule engine to build an automated fault assessment system, solidifying O&M expert experience and implementing strategic deployments. In the event of transmission anomalies, it quickly outputs actionable, targeted troubleshooting guidelines, reducing the fault location cycle in wide-area, complex architectures from hours to minutes, comprehensively improving system O&M efficiency, business stability, and service delivery quality.

[0148] Example 4 Figure 9 This is a schematic diagram of a data transmission detection device provided in Embodiment 4 of the present invention. Figure 9 As shown, the device includes: The data acquisition module 910 is used to acquire first data and second data; wherein, the first data is an audit snapshot certificate generated by the sending end; the audit snapshot certificate is an immutable snapshot evidence certificate generated in real time for streaming business data; the second data is a receiver confirmation certificate generated by the receiving end; the receiver confirmation certificate is a feedback confirmation certificate generated by the receiving end after the receiving end completes data reception. The first rule determination module 920 is used to traverse a pre-set rule base to determine the first rule corresponding to the first data and the second data; wherein, the first rule is used to characterize the data transmission failure situation between the sending end and the receiving end; The first report generation module 930 is used to generate a first report based on the first rule and the first confidence level corresponding to the first rule.

[0149] Optional, the data acquisition module 910 is specifically used for: When a trigger condition is detected, first data and second data are acquired; wherein, the trigger condition includes at least one of the following: the timing duration reaches a preset time threshold, or a preset trigger action is identified.

[0150] Optionally, the first report generation module 930 is specifically used for: Determine the second confidence level corresponding to the first rule; wherein, the second confidence level is the original confidence level; The second confidence level is multiplied by a pre-set confidence level weight to obtain the third confidence level; The first confidence level corresponding to the first rule of the same type is obtained by summing all the third confidence levels. The second rule is selected from the first rule based on the first confidence level; Based on the detection results corresponding to the second rule, a first report is generated.

[0151] The data transmission detection device provided in this embodiment of the invention can execute the data transmission detection method provided in Embodiment 1 of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0152] Example 5 Figure 10 This is a schematic diagram of another data transmission detection device provided in Embodiment 5 of the present invention. Figure 10 As shown, the device includes: The third data acquisition module 1010 is used to acquire third data; wherein, the third data is streaming business data; The first data block obtaining module 1020 is used to divide the third data into blocks to obtain each first data block; The first hash value acquisition module 1030 is used to perform hash operations on the first data block within a pre-configured sliding window to obtain the first hash value; The second hash value acquisition module 1040 is used to update the root node of the pre-set node tree based on the first hash value to obtain the second hash value; The first data generation module 1050 is used to generate first data based on the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value; wherein the fourth data is the running status data of the sending end; and the third hash value is the hash value generated in the previous round of update.

[0153] Optionally, the second hash value is used to obtain module 1040, specifically for: Determine the target node corresponding to the first hash value; Traverse the pre-set node tree to determine the target path between the target node and the root node; the target path includes the target node, the root node, and all intermediate nodes between the target node and the root node, and the nodes are arranged in order from the target node to the root node. According to the node order of the target path, the first data block associated with each node is hashed sequentially to obtain the second hash value step by step; wherein, the second hash value is the final hash value obtained after hashing the first data block associated with the root node.

[0154] Optionally, the device further includes: The fifth data generation module is used to generate fifth data based on the first data and a pre-set control frame; wherein the control frame is used to transmit verification information. The data sending module is used to asynchronously upload the first data to the service layer; and to send the fifth data to the receiving end.

[0155] The data transmission detection device provided in this embodiment of the invention can execute the data transmission detection method provided in Embodiment 2 of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0156] Example 6 Figure 11 This is a schematic diagram of another data transmission detection device provided in Embodiment Six of the present invention. Figure 11 As shown, the device includes: The fifth data acquisition module 1110 is used to acquire the fifth data; The first data determination module 1120 is used to parse the fifth data and determine the first data and the control frame; The verification result acquisition module 1130 is used to verify the first data and the control frame to obtain the verification result; The second data generation module 1140 is used to generate second data based on the verification result and the sixth data; wherein the sixth data is the running status data of the receiving end; The second data upload module 1150 is used to asynchronously upload the second data to the service layer.

[0157] The data transmission detection device provided in this embodiment of the invention can execute the data transmission detection method provided in Embodiment 3 of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0158] Example 7 Figure 12A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0159] like Figure 12 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0160] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0161] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a data transmission detection method.

[0162] In some embodiments, a data transmission detection method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the data transmission detection method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a data transmission detection method by any other suitable means (e.g., by means of firmware).

[0163] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0164] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0165] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0166] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0167] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0168] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0169] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication unit 19, or installed from storage unit 18, or installed from ROM 12. When the computer program is executed by processor 11, it performs the functions defined in the methods of the embodiments of the present invention.

[0170] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0171] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A data transmission detection method, characterized in that, The method is executed by the service layer, and the method includes: Acquire first data and second data; wherein, the first data is an audit snapshot certificate generated by the sending end; the audit snapshot certificate is an immutable snapshot evidence certificate generated in real time for streaming business data; the second data is a receiver confirmation certificate generated by the receiving end; the receiver confirmation certificate is a feedback confirmation certificate generated by the receiving end after completing data reception. Traverse the pre-set rule base to determine the first rule corresponding to the first data and the second data; wherein, the first rule is used to characterize the data transmission failure situation between the sending end and the receiving end; A first report is generated based on the first rule and the first confidence level corresponding to the first rule.

2. The method according to claim 1, characterized in that, Obtain the first and second data, including: When a trigger condition is detected, first data and second data are acquired; wherein, the trigger condition includes at least one of the following: the timing duration reaches a preset time threshold, or a preset trigger action is identified.

3. The method according to claim 1, characterized in that, Based on the first rule and the first confidence level corresponding to the first rule, a first report is generated, including: Determine the second confidence level corresponding to the first rule; wherein, the second confidence level is the original confidence level; The second confidence level is multiplied by a pre-set confidence level weight to obtain the third confidence level; The first confidence level corresponding to the first rule of the same type is obtained by summing all the third confidence levels. The second rule is selected from the first rule based on the first confidence level; Based on the detection results corresponding to the second rule, a first report is generated.

4. A data transmission detection method, characterized in that, The method is executed by the sending end, and the method includes: Obtain third data; wherein, the third data is streaming business data; The third data is divided into blocks to obtain individual first data blocks; Perform a hash operation on the first data block within the pre-configured sliding window to obtain the first hash value; The root node of the pre-set node tree is updated based on the first hash value to obtain the second hash value; First data is generated based on the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value; wherein, the fourth data is the running status data of the sending end; and the third hash value is the hash value generated in the previous round of update.

5. The method according to claim 4, characterized in that, The root node of the pre-set node tree is updated based on the first hash value to obtain the second hash value, including: Determine the target node corresponding to the first hash value; Traverse the pre-set node tree to determine the target path between the target node and the root node; the target path includes the target node, the root node, and all intermediate nodes between the target node and the root node, and the nodes are arranged in order from the target node to the root node. According to the node order of the target path, the first data block associated with each node is hashed sequentially to obtain the second hash value step by step; wherein, the second hash value is the final hash value obtained after hashing the first data block associated with the root node.

6. The method according to claim 4, characterized in that, After generating the first data based on the second hash value, the sequence number of the sliding window, the timestamp, the fourth data, and the third hash value, the method further includes: Based on the first data and the pre-set control frame, the fifth data is generated; wherein the control frame is used to transmit verification information; The first data is asynchronously uploaded to the service layer; and the fifth data is sent to the receiving end.

7. A data transmission detection method, characterized in that, The method is executed by the receiving end, and the method includes: Obtain the fifth data; The fifth data is parsed to determine the first data; The first data is verified to obtain the verification result; The second data is generated based on the verification result and the sixth data; wherein, the sixth data is the operating status data of the receiving end; The second data is uploaded to the service layer asynchronously.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a data transmission detection method according to any one of claims 1-3, 4-6, or 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute and implement a data transmission detection method according to any one of claims 1-3, 4-6, or 7.

10. A computer program product comprising a computer program that, when executed by a processor, implements a data transmission detection method according to any one of claims 1-3, 4-6, or 7.

Images