Header routing analysis and real-time monitoring system and method in network IP packet transmission
Patent Information
- Application Number
- CN202610987658.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-03
- Publication Date
- 2026-09-29
AI Technical Summary
网络IP包传输中的报头路由解析与实时监控系统及方法,及其相关技术,以解决现有技术中报头解析效率低、兼容性差、实时监测能力不足、监控链路不闭环等技术问题或其组合
(1)本发明通过采用高速采集和报头预处理技术手段,获得了低时延、高完整性的报文输入效果,相较于传统依赖内核协议栈的抓包方案,减少了数据拷贝和上下文切换带来的延迟,提高了高速链路下的数据接收稳定性。
Smart Images

Figure CN122845694A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of IP packet parsing and monitoring technology, and in particular to a system and method for header routing parsing and real-time monitoring in network IP packet transmission. Background Technology
[0002] With the rapid development of enterprise intranets, carrier backbone networks, government networks, and cloud-edge collaborative networks, IP packets have become the basic unit of network layer data transmission. The IP packet header contains core information such as source IP address, destination IP address, TTL, protocol type, identification field, and checksum field, serving as crucial evidence for routing, network monitoring, fault location, and security analysis. In existing network operation and security protection processes, it is typically necessary to collect IP packets in the network, parse headers, identify source / destination addresses, detect anomalies, and monitor the entire process to identify issues such as address spoofing, header tampering, routing anomalies, and abnormal traffic.
[0003] In existing technologies, the parsing and monitoring of IP packet headers generally adopt the following methods: network packets are obtained through ordinary packet capture software or kernel protocol stack, and then the source address and destination address in the IPv4 or IPv6 header are extracted by software programs; the route attribution of the destination address is resolved by the traditional longest prefix matching algorithm (LPM) or linear traversal of the routing table; the validity of some fields in the header, such as length, TTL, and checksum, is verified by a rule engine; and the collected data is logged, anomaly displayed, and alerted through a centralized monitoring platform.
[0004] However, existing technologies have at least the following drawbacks and shortcomings: (1) Header extraction relies on the software protocol stack, resulting in significant processing delay: Traditional solutions typically obtain network packets through the operating system kernel protocol stack and then extract fields at the application layer. This approach suffers from multiple switching between kernel and user modes and high data copy overhead. In gigabit, 10-gigabit, or even higher-speed network environments, it is prone to acquisition delays, extraction lags, and packet loss.
[0005] (2) Poor compatibility of address resolution algorithms in complex network environments: Most existing routing address resolution algorithms are designed for single IPv4 static routing scenarios. In scenarios such as dynamic routing, NAT address translation, IPv4 / IPv6 dual stack, NAT64 / DNS64, etc., problems such as resolution gaps, incomplete address mapping, and inability to associate upstream and downstream addresses are likely to occur.
[0006] (3) Inefficient traditional matching algorithms: In the process of route matching, the linear search method has a high time complexity. Even the conventional prefix tree will have problems of decreased query efficiency and high memory usage when facing massive routing table entries or IPv6 long address matching, making it difficult to meet the real-time parsing requirements in high-speed networks.
[0007] (4) Insufficient real-time detection capability: Most existing header detection schemes are pure software rule detection or offline analysis mode, which are difficult to identify with low latency behaviors such as abnormal header fields, abnormal address access, and header tampering. Especially in the case of sudden large traffic, DDoS attack, address forgery, etc., the detection response is not timely enough, which can easily lead to missed detection and false detection.
[0008] (5) Incomplete monitoring link: Existing systems often implement header parsing, anomaly detection, monitoring display, and early warning handling separately, lacking a unified closed loop. It is difficult to form an integrated processing system of "collection-parsing-detection-monitoring-early warning-handling-tracing", resulting in low efficiency in locating, associating and handling abnormal events, even though they can be detected.
[0009] (6) Lack of multi-scenario deployment and adaptation capabilities: Centralized monitoring is suitable for small local area networks, but it is easy to form a single point of bottleneck in large backbone networks, cross-regional networks and cloud-edge collaborative environments; while traditional distributed solutions have problems such as complex node collaboration, untimely rule synchronization and low data aggregation efficiency, making it difficult to balance real-time performance and scalability. Summary of the Invention
[0010] The purpose of this invention is to provide: A system and method for header routing parsing and real-time monitoring in network IP packet transmission, and related technologies, to solve technical problems such as low header parsing efficiency, poor compatibility, insufficient real-time monitoring capabilities, and non-closed-loop monitoring links in existing technologies, or combinations thereof.
[0011] This invention provides a method for header routing parsing and real-time monitoring in network IP packet transmission.
[0012] Includes the following steps: S1. Collect raw IP packet data from the network, including raw message data of link layer frame header and network layer data; S2. Perform preprocessing operations on the raw IP packet data collected in step S1; S3. For the data processed in step S2, identify the type of the current message, specifically including IPv4, IPv6, and IPv9, and extract the key fields of different types of headers. S4. Extract key fields from IPv4, IPv6, and IPv9 headers and convert them to source / destination address formats. S5. Determine whether the current IP packet transmission network scenario is a normal scenario or a complex scenario. Based on the data after the IPv4, IPv6, and IPv9 headers are converted, parse the data for different scenarios separately. Perform the corresponding operation for the complex scenario and then perform the operation for the normal scenario. S6. Combine the extraction results from step S3 with the parsing results from step S5 to perform real-time detection on IP packets and obtain abnormal detection values. S7. Set the anomaly level, compare the anomaly detection value from step S6 with the anomaly level, and obtain the anomaly result.
[0013] In step S3, the source IP address, destination IP address, TTL, identifier, protocol type, header length, and checksum are extracted from the identified IPv4 version data; the source address, destination address, hop limit, next header field, and flow label are extracted from the identified IPv6 version data; and the communication flow type, flow label, payload length, next header, hop limit, source address, destination address, time, and authentication code are extracted from the identified IPv9 version data.
[0014] In step S4, the extracted IPv4 address is converted to dotted decimal, the extracted IPv6 address is converted to colon-separated hexadecimal, and the extracted IPv9 address is converted to a full decimal number format with specific delimiters.
[0015] In step S5, the content of step S51 is executed for typical scenarios. Specifically, the route resolution is performed on the source IP address and the destination IP address. After the route resolution, a hash cache is established for hot network segments or high-frequency source / destination addresses. When the cache is hit, the resolution result is output directly. When the cache is not hit, the prefix tree matching is entered, and the result of the prefix tree matching is cached.
[0016] In step S51, the route resolution process is as follows: IPv4 uses LPM / hierarchical prefix tree, IPv6 uses a binary prefix tree adapted to 128-bit addresses, and IPv9 uses a multi-bit prefix tree adapted to variable-length, domain-separated decimal addresses.
[0017] In step S51, the prefix tree matching process is as follows: using the source IP address and destination IP address, the longest prefix match is performed using the local or synchronized routing table to obtain the routing entry for each source IP address and destination IP address. A hierarchical prefix tree structure is used to quickly index the obtained routing entries. A hash cache is established for high-frequency address ranges. If dynamic route updates are detected, incremental synchronization of the routing table is performed. The corresponding resolution engine is called for IPv4, IPv6, and IPv9 respectively.
[0018] Among them, the complex scenarios in step S5 include NAT address translation, multi-hop routing, IPv4 / IPv6 / IPv9 multi-stack, and cross-version scenarios.
[0019] Specifically, for complex scenarios, the content of step S52 is executed as follows: special processing is performed for different complex scenarios, and after the special processing for each complex scenario is executed, the content of step S51 is executed. The special processing performed for different complex scenarios includes: when it is a NAT address translation scenario, a mapping table of public IP-internal IP-port-protocol is constructed, and the addresses before and after the translation are associated; when it is a multi-hop routing scenario, the IP packet forwarding path is restored by combining the TTL or hop count limit field and the forwarding records of each node; when it is an IPv4 / IPv6 / IPv9 multi-stack scenario and a cross-version scenario, multi-stack resolution and version mapping processing are performed.
[0020] The anomaly detection value P in step S6 is calculated using the following formula: ; , , , , The following relationship exists between them: ; ; ; ; ; In the above formula, Indicates the valid values for the header fields. Indicates the legal weight of the header field. This indicates an abnormal value indicating address access behavior. Indicates the weight of abnormal address access behavior. This indicates that the header has been tampered with. This indicates abnormal weighting due to header tampering. This indicates an abnormal hop count. Indicates abnormal weights in route hop count. Indicates an abnormal value in transmission delay. This indicates the weight of transmission delay anomalies.
[0021] In step S7, the anomaly levels include high anomaly, moderate anomaly, low anomaly, and blacklist anomaly. When the anomaly detection value is less than 40, it is judged as low anomaly; when the anomaly detection value is greater than or equal to 40 but less than 70, it is judged as moderate anomaly; when the anomaly detection value is greater than or equal to 70, it is judged as high anomaly; when the blacklist is hit, it is directly judged as blacklist anomaly.
[0022] The present invention has at least the following beneficial effects: (1) By adopting high-speed acquisition and header preprocessing techniques, this invention achieves low latency and high integrity message input. Compared with traditional packet capture schemes that rely on kernel protocol stacks, it reduces the latency caused by data copying and context switching, and improves the data reception stability under high-speed links.
[0023] (2) By adopting unified IPv4 / IPv6 / IPv9 resolution and complex scenario mapping technology, this invention achieves stronger address resolution compatibility and can adapt to complex environments such as dynamic routing, NAT, multi-stack, and cross-version address translation, avoiding the resolution interruption and address loss problems that occur in traditional technologies.
[0024] (3) By adopting hierarchical prefix tree and hash caching technology, this invention achieves higher routing resolution efficiency, reduces routing table lookup complexity, and improves the hit speed of high-frequency address segments, making it suitable for large-scale routing environments.
[0025] (4) By employing header field legality detection, address behavior modeling and field association verification techniques, this invention achieves a higher anomaly identification accuracy; it can perform multi-dimensional identification of behaviors such as address forgery, header tampering, abnormal access, and abnormal hop count, thereby reducing missed detections and false detections.
[0026] (5) By adopting hardware and software co-acceleration technology, the present invention has obtained real-time detection capability applicable to gigabit, 10-gigabit and higher throughput networks, meeting the low latency parsing and detection requirements in high-concurrency network scenarios.
[0027] (6) By adopting closed-loop monitoring and early warning linkage technology, this invention achieves higher operation and maintenance efficiency and fault handling efficiency, and can realize an automated process from discovering anomalies to triggering early warnings and then to log tracing, thereby improving network security protection and fault diagnosis capabilities. Attached Figure Description
[0028] Figure 1 This is a flowchart of the method of the present invention.
[0029] Figure 2 This is a schematic diagram of the system of the present invention.
[0030] Figure 3 This is a flowchart of the real-time detection and early warning system of the present invention.
[0031] Figure 4 This is a flowchart of the routing resolution method of the present invention.
[0032] Figure 5 This is a schematic diagram of the centralized / distributed / cloud-edge collaborative deployment architecture of this invention. Detailed Implementation
[0033] The following non-limiting embodiments are intended to enable those skilled in the art to gain a more comprehensive understanding of the present invention, but do not limit the invention in any way. The following content is merely an exemplary description of the scope of protection claimed by the present invention, and those skilled in the art can make various changes and modifications to the present invention based on the disclosed content, and such changes should also fall within the scope of protection claimed by the present invention.
[0034] The present invention will be further described below by way of specific embodiments. Unless otherwise specified, all instruments, devices, equipment, reagents, products, etc., used in the embodiments of the present invention are obtained through conventional commercial means.
[0035] Example 1 like Figure 1 , Figure 3 As shown, this embodiment provides a method for header routing parsing and real-time monitoring in network IP packet transmission, including the following steps: S1. Collect raw IP packet data in the network. Specifically, this is done through port mirroring, fiber optic splitting, packet capture network cards, or user-space high-speed acquisition components to collect raw data streams in the network link, including raw packets of link layer frame headers and network layer data.
[0036] Other acquisition methods include kernel protocol stack acquisition, DPDK user space acquisition, or eBPF acquisition.
[0037] S2. Perform preprocessing operations on the raw messages collected in step S1, specifically including the following steps: S21. Strip the link layer frame header from the original message and retain the IP layer data.
[0038] S22. Verify whether the packet length in the retained IP data is valid. If it is invalid, the original packet needs to be retrieved again.
[0039] S23. For IPv4 packets, perform header checksum and verification operations using the one's complement summation algorithm. If the result is not all 1s, it indicates that the packet data is corrupted, and the data packet is discarded.
[0040] S24. Cache, reassemble, or mark out-of-order packets and fragmented packets; filter corrupted packets, broken packets, and invalid packets.
[0041] S3. For the data preprocessed in step S2, identify the IP protocol version and extract key fields from the header. Specifically, by reading the version field of the IP header, identify whether the current packet is IPv4, IPv6, or IPv9. For the identified IPv4 version data, extract its source IP address, destination IP address, TTL, identifier, protocol type, header length, and checksum. For the identified IPv6 version data, extract its source address, destination address, hop limit, next header field, and flow label. For the identified IPv9 version data, extract its communication flow type (including address length, communication category, and authentication method), flow label, payload length, next header, hop limit, source address (16-2048 bits, variable length), destination address (16-2048 bits, variable length), time, and authentication code.
[0042] S4. Perform source / destination address format conversion on the data extracted in step S3. Specifically, convert the extracted raw binary address into a standard readable format: convert the extracted IPv4 address into dotted decimal, convert the extracted IPv6 address into colon-separated hexadecimal, and convert the extracted IPv9 address into a full decimal number format with specific delimiters. At the same time, perform zero-compression normalization on the data after the destination IP address is converted.
[0043] S5. Determine whether the current IP packet transmission network scenario is a normal scenario or a complex scenario. For normal scenarios, execute step S51; for complex scenarios, execute step S52. Complex scenarios include NAT address translation scenarios, multi-hop routing scenarios, IPv4 / IPv6 / IPv9 multi-stack scenarios, and cross-version scenarios. All scenarios other than complex scenarios are normal scenarios.
[0044] S51, such as Figure 4 As shown, route resolution is performed on the source IP address and destination IP address. After route resolution, a hash cache is established for hot network segments or high-frequency source / destination addresses. When the cache is hit, the resolution result is output directly. When the cache is not hit, the prefix tree matching is entered, and the result of the prefix tree matching is cached.
[0045] The routing resolution process is as follows: IPv4 uses an optimized LPM / hierarchical prefix tree, IPv6 uses a binary prefix tree adapted to 128-bit addresses, and IPv9 uses a multi-bit prefix tree adapted to variable-length, domain-separated decimal addresses.
[0046] The prefix tree matching process is as follows: using the source IP address and destination IP address, the longest prefix match is performed using the local or synchronized routing table to obtain the routing entry for each source IP address and destination IP address. A hierarchical prefix tree structure is used to quickly index the obtained routing entries. A hash cache is established for high-frequency address ranges to speed up repeated resolution. If dynamic route updates are detected, incremental synchronization of the routing table is performed. The corresponding resolution engine is called for IPv4, IPv6 and IPv9 respectively.
[0047] S52. Perform special processing for different complex scenarios. After the special processing for each complex scenario is performed, the content in step S51 is executed. The special processing performed for different complex scenarios includes: when it is a NAT address translation scenario, construct a mapping table of public IP-internal IP-port-protocol and associate the addresses before and after the translation; when it is a multi-hop routing scenario, combine the TTL or hop count limit field and the forwarding records of each node to restore the IP packet forwarding path; when it is an IPv4 / IPv6 / IPv9 multi-stack scenario and a cross-version scenario, perform multi-stack resolution and version mapping processing.
[0048] S6. Perform real-time anomaly detection. Based on the extraction results of step S4 and the parsing results of step S5, perform real-time detection on IP packets, including header field validity detection, address access behavior anomaly detection, header tampering detection, route hop count anomaly detection, and transmission latency anomaly detection, based on a comprehensive judgment using a rule engine, threshold model, and lightweight machine learning model. Quantify the above detection results to obtain the anomaly detection value P, which is calculated using the following formula: ; In the above formula, Indicates the valid values for the header fields. Indicates the legal weight of the header field. This indicates an abnormal value indicating address access behavior. Indicates the weight of abnormal address access behavior. This indicates that the header has been tampered with. This indicates abnormal weighting due to header tampering. This indicates an abnormal hop count. Indicates abnormal weights in route hop count. Indicates an abnormal value in transmission delay. This indicates the weight of transmission delay anomalies.
[0049] , , , , The method for obtaining the data is as follows: A lightweight machine learning model is used for training. Normal and abnormal data from previous IP packet detection results (header field validity detection, address access behavior anomaly detection, header tampering detection, route hop count anomaly, and transmission delay anomaly detection) are input into the lightweight machine learning model for training, thus obtaining the final trained anomaly detection model. This model can output corresponding header field validity values, address access behavior anomaly values, header tampering anomaly values, route hop count anomaly values, and transmission delay anomaly values. Specifically, the detection model quantizes these values into values from 0 to 100.
[0050] , , , , The following relationship exists between them: ; ; ; ; ; S7. Set the anomaly level, including high anomaly, medium anomaly, low anomaly and blacklist anomaly. Compare the anomaly detection value obtained in step S6 with the anomaly level and output the final anomaly result. High anomalies are directly marked and reported. Medium and low anomalies are cached and then subjected to secondary verification. Blacklisted anomaly traffic is directly blocked or isolated.
[0051] When the anomaly detection value is less than 40, it is judged as low-level anomaly; when the anomaly detection value is greater than or equal to 40 but less than 70, it is judged as moderate-level anomaly; when the anomaly detection value is greater than or equal to 70, it is judged as high-level anomaly; when it hits the blacklist, it is directly judged as blacklist anomaly.
[0052] S8. Send the parsing results, detection results, routing information, anomaly level, flow identifier, timestamp and other data to the monitoring platform to generate monitoring views, statistical reports and early warning information; trigger SMS, email, pop-up or interface linkage alarms when preset conditions are met.
[0053] S9. Execution Log Retention and Source Tracing Analysis: Store IP packet parsing records, address mapping relationships, anomaly detection logs, early warning records, and handling records for subsequent source tracing analysis, fault location, and network forensics.
[0054] Example 2 like Figure 2 As shown, this embodiment provides a header routing parsing and real-time monitoring system for network IP packet transmission, including a data acquisition module, a header preprocessing module, an address field extraction module, an address format conversion module, a routing parsing module, a scenario adaptation module, a real-time detection module, a result evaluation module, a monitoring display and early warning module, and a data storage and analysis module. The data acquisition module collects raw network packets and outputs the IP packet data to be processed. The header preprocessing module strips link-layer data, verifies packet validity, and processes out-of-order or fragmented packets. The address field extraction module identifies IPv4, IPv6, and IPv9 protocol types and extracts the source address, destination address, and key packet fields. The address format conversion module is used for... The system converts binary addresses to standard string format; the routing resolution module performs address attribution resolution and path matching based on routing tables, prefix trees, and caching mechanisms; the scenario adaptation module handles complex scenario resolutions such as NAT mapping, multi-stack mapping, and multi-hop path association; the real-time detection module detects header field anomalies, address behavior anomalies, tampering anomalies, and routing anomalies; the result evaluation module grades, scores, filters, and performs secondary verification on abnormal results; the monitoring, display, and early warning module displays traffic, address distribution, anomaly information, and routing topology, and triggers multi-channel early warnings; and the data storage and analysis module stores resolution logs, detection results, early warning records, and behavior profiles, and performs statistical analysis and source tracing.
[0055] like Figure 5 As shown, the deployment architecture in the system can be centralized, distributed, master-slave, cloud-edge collaborative, or layered aggregation.
[0056] Verification of technical effectiveness and / or analysis of technical problem solving This invention achieves low latency and high integrity in message input by employing high-speed acquisition and header preprocessing techniques. Compared with traditional packet capture schemes that rely on kernel protocol stacks, it reduces the latency caused by data copying and context switching, and improves the stability of data reception under high-speed links.
[0057] This invention achieves stronger address resolution compatibility by employing unified IPv4 / IPv6 / IPv9 resolution and complex scenario mapping techniques. It can adapt to complex environments such as dynamic routing, NAT, multi-stack, and cross-version address translation, avoiding resolution interruption and address loss problems that occur in traditional technologies.
[0058] This invention achieves higher routing resolution efficiency, reduces routing table lookup complexity, and improves the hit speed of high-frequency address segments by employing hierarchical prefix trees and hash caching techniques, making it suitable for large-scale routing environments.
[0059] This invention achieves a higher accuracy rate in anomaly identification by employing header field validity detection, address behavior modeling, and field association verification techniques. It can perform multi-dimensional identification of behaviors such as address forgery, header tampering, abnormal access, and abnormal hop count, thereby reducing missed detections and false detections.
[0060] This invention employs a hardware and software co-acceleration technology to achieve real-time detection capabilities applicable to gigabit, 10-gigabit, and higher throughput networks, meeting the low-latency parsing and detection requirements in high-concurrency network scenarios.
[0061] This invention achieves higher operation and maintenance efficiency and fault handling efficiency by adopting closed-loop monitoring and early warning linkage technology. It can realize an automated process from anomaly detection to triggering early warning and then to log tracing, thereby improving network security protection and fault diagnosis capabilities.
[0062] Finally, it should be noted that the above content is only used to illustrate the technical solution of the present invention, and is not intended to limit the scope of protection of the present invention. Simple modifications or equivalent substitutions made by those skilled in the art to the technical solution of the present invention do not depart from the essence and scope of the technical solution of the present invention.
Claims
1. A method for header routing parsing and real-time monitoring in network IP packet transmission, characterized in that, Includes the following steps: S1. Collect raw IP packet data from the network, including raw message data of link layer frame header and network layer data; S2. Perform preprocessing operations on the raw IP packet data collected in step S1; S3. For the data processed in step S2, identify the type of the current message, specifically including IPv4, IPv6, and IPv9, and extract the key fields of different types of headers. S4. Extract key fields from IPv4, IPv6, and IPv9 headers and convert them to source / destination address formats. S5. Determine whether the current IP packet transmission network scenario is a normal scenario or a complex scenario. Based on the data after the IPv4, IPv6, and IPv9 headers are converted, parse the data for different scenarios separately. Perform the corresponding operation for the complex scenario and then perform the operation for the normal scenario. S6. Combine the extraction results from step S3 with the parsing results from step S5 to perform real-time detection on IP packets and obtain abnormal detection values. S7. Set the anomaly level, compare the anomaly detection value from step S6 with the anomaly level, and obtain the anomaly result.
2. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 1, characterized in that, In step S3, the source IP address, destination IP address, TTL, identifier, protocol type, header length, and checksum are extracted from the identified IPv4 version data; the source address, destination address, hop limit, next header field, and flow label are extracted from the identified IPv6 version data; and the communication flow type, flow label, payload length, next header, hop limit, source address, destination address, time, and authentication code are extracted from the identified IPv9 version data.
3. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 2, characterized in that, In step S4, the extracted IPv4 addresses are converted to dotted decimal, the extracted IPv6 addresses are converted to colon-separated hexadecimal, and the extracted IPv9 addresses are converted to full decimal number format with specific delimiters.
4. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 1, characterized in that, In step S5, the content of step S51 is executed for typical scenarios. Specifically, route resolution is performed on the source IP address and destination IP address. After route resolution, a hash cache is established for hot network segments or high-frequency source / destination addresses. When the cache is hit, the resolution result is output directly. When the cache is not hit, the prefix tree matching is entered, and the result of the prefix tree matching is cached.
5. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 4, characterized in that, In step S51, the route resolution process is as follows: IPv4 uses LPM / hierarchical prefix tree, IPv6 uses binary prefix tree adapted to 128-bit addresses, and IPv9 uses multi-bit prefix tree adapted to variable-length, domain-separated decimal addresses.
6. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 4, characterized in that, In step S51, the prefix tree matching process is as follows: using the source IP address and destination IP address, the longest prefix match is performed using the local or synchronized routing table to obtain the routing entry for each source IP address and destination IP address. A hierarchical prefix tree structure is used to quickly index the obtained routing entries. A hash cache is established for high-frequency address ranges. If dynamic route updates are detected, incremental synchronization of the routing table is performed. The corresponding resolution engine is called for IPv4, IPv6, and IPv9 respectively.
7. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 4, characterized in that, Complex scenarios in the S5 process include NAT address translation, multi-hop routing, IPv4 / IPv6 / IPv9 multi-stack, and cross-version scenarios.
8. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 7, characterized in that, For complex scenarios, the content of step S52 is executed as follows: special processing is performed for different complex scenarios, and after the special processing for each complex scenario is executed, the content of step S51 is executed. Special processing for different complex scenarios includes: when performing NAT address translation, constructing a mapping table of public IP address - internal IP address - port - protocol, and associating the addresses before and after translation; In multi-hop routing scenarios, the IP packet forwarding path is restored by combining the TTL or hop count limit fields and the forwarding records of each node; in IPv4 / IPv6 / IPv9 multi-stack scenarios and cross-version scenarios, multi-stack resolution and version mapping are performed.
9. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 1, characterized in that, The anomaly detection value P in step S6 is calculated using the following formula: ; , , , , The following relationship exists between them: ; ; ; ; ; In the above formula, Indicates the valid values for the header fields. Indicates the legal weight of the header field. This indicates an abnormal value indicating address access behavior. Indicates the weight of abnormal address access behavior. This indicates that the header has been tampered with. This indicates abnormal weighting due to header tampering. This indicates an abnormal hop count. Indicates abnormal weights in route hop count. Indicates an abnormal value in transmission delay. This indicates the weight of transmission delay anomalies.
10. The method for header routing parsing and real-time monitoring in network IP packet transmission according to claim 1, characterized in that, The anomaly levels in step S7 include high anomaly, moderate anomaly, low anomaly, and blacklist anomaly. When the anomaly detection value is less than 40, it is judged as low anomaly; when the anomaly detection value is greater than or equal to 40 but less than 70, it is judged as moderate anomaly; when the anomaly detection value is greater than or equal to 70, it is judged as high anomaly; when the blacklist is hit, it is directly judged as blacklist anomaly.