Call bill synthesis method and device, equipment, storage medium and program product

Abstract

The invention discloses a ticket synthesis method and device, equipment, a storage medium and a program product. The method comprises the following steps: gathering ticket data of all machine rooms in a target area to obtain gathered data; associating messages belonging to the same ticket in the aggregated data according to a preset address rule to obtain asymmetric associated ticket data; and for each hypertext transfer security protocol ticket, backfilling the associated domain name system resolution domain name and alias record field into the hypertext transfer security protocol ticket to obtain a deep packet inspection ticket synthesis result. According to the embodiment of the invention, by integrating the dispersed and one-way network flow data into the complete and two-way associated ticket, and performing association backfilling on the domain name system ticket and the hypertext transfer security protocol ticket to obtain the DPI ticket, network transmission resources can be effectively saved, data packet loss is reduced, the two-way integrity and recognition degree of the ticket are improved, and the success rate of data transmission is improved. And powerful big data basic support is provided for internet content resource operation and the like.

Description

Technical Field

[0001] This application belongs to the field of big data edge computing technology, and in particular relates to a call detail record (CDR) synthesis method, apparatus, device, storage medium and program product. Background Technology

[0002] Deep Packet Inspection (DPI) call detail record (CDR) synthesis plays a crucial role in modern network management and security monitoring. By integrating scattered, unidirectional network traffic data into complete, bidirectional CDR records, DPI systems significantly improve the accuracy and comprehensiveness of service identification. Service identification is the core of a DPI system and the foundation for supporting analytical work. Existing technical solutions enhance DPI's service identification capabilities through multi-stage collaboration.

[0003] Existing technologies enhance service identification capabilities through multi-stage collaboration, such as direct identification based on message features, synthesis of same-origin and same-destination traffic within and across data centers, and secondary identification based on call detail record (CDR) fields. However, these methods have significant drawbacks. Synthesis of same-origin and same-destination traffic across data centers places high demands on network transmission resources and has low utilization efficiency. Furthermore, sampling leads to a decrease in the accuracy and availability of CDRs. Manual extraction of message features is slow to update and is incomplete in identifying encrypted traffic. Summary of the Invention

[0004] This application provides a call detail record (CDR) synthesis method, apparatus, device, storage medium, and program product, which can effectively save network transmission resources, reduce data packet loss, process all data, improve the bidirectional integrity and recognition of CDRs, quickly respond to changes in HTTPS service characteristics, expand DPI CDR service recognition and analysis capabilities, and provide strong big data foundation support for Internet content resource operation, etc.

[0005] In a first aspect, embodiments of this application provide a call detail record (CDR) synthesis method, comprising: aggregating CDR data from all data centers within a target area into a target message queue to obtain aggregated data; associating packets belonging to the same CDR in the aggregated data according to preset address rules to obtain asymmetric associated CDR data; associating Domain Name System (DNS) CDRs and Hypertext Transfer Security Protocol (HTTP) CDRs in the asymmetric associated CDR data according to a time window; and backfilling the associated DNS resolution domain name and alias record fields into the HTTP HTTP CDR for each HTTP HTTP CDR to obtain a deep packet inspection (DPI) CDR synthesis result.

[0006] In one possible implementation, the step of associating packets belonging to the same call detail record (CDR) in the aggregated data according to a preset address rule to obtain asymmetric associated CDR data includes: grouping the packets in the aggregated data according to 5-tuples or 6-tuples, determining the target number of groups and the offloading data; associating the offloading data in each group corresponding to the target number of groups with packets of the same 5-tuple into a CDR, and associating packets of the same 6-tuple into a CDR, thereby obtaining asymmetric associated CDR data.

[0007] In one possible implementation, grouping the packets in the aggregated data according to 5-tuples or 6-tuples to determine the target number of packets and the diverted data includes: grouping the aggregated data according to 5-tuples or 6-tuples; grouping request data and response data of the same 5-tuple or 6-tuple stream data in the aggregated data into the same group to determine the target number of packets; using a hash algorithm to obtain the hash code corresponding to the source and destination addresses of the aggregated data in each data center; and performing a modulo division operation on the target number of packets based on the hash code to determine the diverted data corresponding to each packet.

[0008] In one possible implementation, the process of associating the split data in each group corresponding to the target number of groups into a single call detail record (CDR) based on the same 5-tuple and the same 6-tuple to obtain asymmetric associated CDR data includes: associating and merging the request data and message data in each group corresponding to the target number of groups according to the source and destination addresses in the 5-tuple or 6-tuple to obtain composite data; and determining the latency index for association backfilling based on the composite data and the target timestamp to obtain asymmetric associated CDR data corresponding to each group.

[0009] In one possible implementation, the step of associating Domain Name System (DNS) call detail records (CDRs) and Hypertext Transfer Security (HTTP) call detail records (HDRs) in the asymmetric association CDR data according to a time window, and backfilling the associated DNS resolution domain name and alias record fields into the HTTP HDR for each HTTP HDR to obtain a deep packet inspection (DPI) CDR synthesis result, includes: extracting data from the asymmetric association CDR data according to different protocol types to obtain DNS and HTTP HDRs; associating the DNS and HTTP HDRs based on a time window to obtain associated CDRs; obtaining DNS resolution requests and HTTP HDR requests from the asymmetric association CDR data; and backfilling the DNS resolution domain name into the associated CDRs with the same source and destination addresses based on the DNS resolution requests and HTTP HDR requests to obtain a DPI CDR synthesis result.

[0010] In one possible implementation, the step of associating the Domain Name System (DNS) call detail records (CDRs) and the Hypertext Transfer Security Protocol (HTTP) call detail records based on a time window to obtain associated CDRs includes: marking the DNS and HTTP call detail records separately to obtain a DNS Resilient Distributed Dataset and an HTTPS Resilient Distributed Dataset; and associating the DNS Resilient Distributed Dataset and the HTTPS Resilient Distributed Dataset in DNS host records based on a time window to obtain associated CDRs in the DNS host records.

[0011] In one possible implementation, the step of backfilling the DNS resolution domain name for the associated call records with the same source and destination addresses based on the DNS resolution request and the Hypertext Transfer Security Protocol (HTTP) call record request to obtain a deep packet inspection (DPI) call record synthesis result includes: calculating the DPI timestamp field of the associated call records for packets with the same source and destination IP addresses based on the DNS resolution request and the HTTP HTTP call record request, and calculating the DNS time field in the corresponding log of the DNS record; taking the minimum value of the difference between the DPI timestamp field and the DNS time field as the target backfill record; backfilling the DNS resolution domain name and alias record fields into the target backfill record to determine the HTTPS association backfill result; and obtaining the deep packet inspection (DPI) call record synthesis result based on the HTTPS association backfill result.

[0012] In one possible implementation, obtaining the deep packet inspection call detail record (CDR) synthesis result based on the HTTPS association backfilling result includes: if the HTTPS association backfilling result is successful, outputting the successfully associated HTTPS CDR to the target message queue; if the HTTPS association backfilling result is unsuccessful, outputting the unassociated HTTPS CDR and DNS CDR to the target cache, and performing the HTTPS CDR and DNS CDR association backfilling operation corresponding to the next time window.

[0013] Secondly, embodiments of this application provide a call detail record (CDR) synthesis apparatus, comprising: an aggregation module for aggregating CDR data from all data centers within a target area into a target message queue to obtain aggregated data; an asymmetric association module for associating packets belonging to the same CDR in the aggregated data according to preset address rules to obtain asymmetric associated CDR data; and an association backfilling module for associating Domain Name System (DNS) CDRs and Hypertext Transfer Security Protocol (HTTP) CDRs in the asymmetric associated CDR data according to a time window, and backfilling the associated DNS domain name and alias record fields into the HTTP HTTP CDR for each HTTP HTTP CDR to obtain a deep packet inspection (DPI) CDR synthesis result.

[0014] Thirdly, embodiments of this application provide a call detail record (CDR) synthesis device, the device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the CDR synthesis method as described in any one of the first aspects.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the call detail record (CDR) synthesis method as described in any one of the first aspects.

[0016] Fifthly, embodiments of this application provide a computer program product, wherein instructions in the computer program product, when executed by a processor of an electronic device, cause the electronic device to perform the call detail record (CDR) synthesis method as described in any one of the first aspects.

[0017] The call detail record (CDR) synthesis method, apparatus, device, storage medium, and program product of this application can aggregate CDR data from all data centers within a target area to obtain aggregated data. Then, according to preset address rules, packets belonging to the same CDR in the aggregated data are associated to obtain asymmetric associated CDR data. Next, Domain Name System (DNS) CDRs and Hypertext Transfer Security (HPS) CDRs in the asymmetric associated CDR data are associated. Then, the associated DNS resolution domain name and alias record fields of the HPS CDRs are backfilled into the HPS CDRs to obtain the deep packet inspection (DPI) CDR synthesis result. This can effectively save network transmission resources, reduce data packet loss, process all data, improve the bidirectional integrity and recognition of CDRs, and quickly respond to changes in HTTPS service characteristics. It can also expand the DPI CDR service recognition and analysis capabilities and provide strong big data foundation support for Internet content resource operation. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a call detail record (CDR) synthesis method provided in an embodiment of this application. Figure 2 This is a flowchart illustrating another call detail record (CDR) synthesis method provided in an embodiment of this application. Figure 3 This is a schematic diagram of a process for determining asymmetric associated call detail record (CDR) data provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a process for determining the number of target groups and the distribution of data, provided in an embodiment of this application. Figure 5 This is a flowchart illustrating a process of diverting traffic from the same source and destination, as provided in an embodiment of this application. Figure 6 This is a schematic diagram of another process for determining asymmetric associated call detail record (CDR) data provided in an embodiment of this application; Figure 7 This is a flowchart illustrating a call detail record (CDR) association backfilling process provided in an embodiment of this application. Figure 8 This is a flowchart illustrating another call detail record (CDR) synthesis method provided in this application embodiment; Figure 9 This is a schematic diagram of a process for determining associated call detail records provided in an embodiment of this application; Figure 10 This is a flowchart illustrating another call detail record (CDR) synthesis method provided in an embodiment of this application. Figure 11 This is a flowchart illustrating another call detail record (CDR) association backfilling process provided in an embodiment of this application. Figure 12 This is a flowchart illustrating another call detail record (CDR) association backfilling process provided in the embodiments of this application; Figure 13 This is a flowchart illustrating another call detail record (CDR) association backfilling process provided in an embodiment of this application. Figure 14 This is a schematic diagram of a call detail record (CDR) synthesis device provided in an embodiment of this application; Figure 15 This is a schematic diagram of the structure of a call detail record (CDR) synthesis device provided in an embodiment of this application. Detailed Implementation

[0020] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0021] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0022] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0023] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0024] Deep Packet Inspection (DPI) call detail record (CDR) synthesis is the process of parsing, correlating, and formatting collected network traffic data (such as user behavior, application protocols, and content) to generate standardized CDRs (such as XDR CDRs). These synthesized CDRs can be used in various scenarios such as network quality analysis, service awareness assessment, and security testing.

[0025] Domain Name System (DNS) query detail records (DDR) records, including DNS queries and responses. These records provide detailed information about the domain name resolution process, such as the queried domain name, its corresponding IP address, the query time, and the response status. These logs are extremely useful for network troubleshooting, security analysis, and traffic monitoring.

[0026] HTTPS call detail records refer to a list of all communication logs transmitted via the HTTPS protocol, providing original evidence for subsequent security audits, troubleshooting, and data analysis.

[0027] Association backfilling is the process of extracting key identifying information from data and associating scattered multi-source data with the same entity record. It is commonly used in scenarios such as data integration and log analysis.

[0028] To address the problems of existing technologies, this application provides a call detail record (CDR) synthesis method, apparatus, device, storage medium, and program product. It aggregates CDR data from all data centers within a target area to obtain aggregated data; then, according to preset address rules, packets belonging to the same CDR in the aggregated data are associated to obtain asymmetric associated CDR data; next, Domain Name System (DNS) CDRs and Hypertext Transfer Security (HPS) CDRs in the asymmetric associated CDR data are associated, and then the associated DNS domain name and alias record fields are backfilled into the HPS CDRs to obtain the deep packet inspection (DPI) CDR synthesis result. This effectively saves network transmission resources, reduces data packet loss, processes all data, improves the bidirectional integrity and recognizability of CDRs, and can quickly respond to changes in HTTPS service characteristics, expanding DPI CDR service recognition and analysis capabilities, providing strong big data foundation support for Internet content resource operation, etc. The CDR synthesis method provided in this application is described below.

[0029] Figure 1 This is a flowchart illustrating a call detail record (CDR) synthesis method provided in an embodiment of this application. Figure 1 As shown, the specific steps of the call detail record (CDR) synthesis method include: S101~S103.

[0030] S101. Aggregate the call detail records (CDRs) of all data centers within the target area into the target message queue to obtain aggregated data.

[0031] Because different regions contain different data centers, to quickly synthesize call detail records (CDRs), we first select CDR data from all data centers in multiple different regions (provinces, cities, or prefecture-level cities, etc.). The CDR data from all data centers in different regions is then aggregated and processed according to certain rules, sent to different collection servers, thus redistributing the data and obtaining aggregated data. This provides relational data support for the next step of synthesizing CDRs from the aggregated data.

[0032] S102. According to the preset address rules, the packets belonging to the same call detail record (CDR) in the aggregated data are associated to obtain asymmetric associated CDR data.

[0033] Address rules are constraints related to the address information of the aggregated data, such as source IP address, source and destination IP address, etc. Asymmetric associated call detail record (CDR) data can be understood as stream data from different data centers that do not have a symmetrical relationship due to differences in content information; this is called asymmetric associated CDR data.

[0034] Furthermore, when information is transmitted in the network, uplink and downlink are distinguished. Uplink and downlink packets may pass through routers in different equipment rooms, but DPI and acquisition equipment combine bidirectional traffic within the same equipment room into a single record based on a 5-tuple (source and destination IP, source and destination ports, and protocol type), and perform service identification on a packet-by-packet basis, finally outputting a flow record. The flow record contains information such as the 5-tuple, service ID, and uplink and downlink traffic. If uplink and downlink packets pass through different equipment rooms, they cannot be combined, and only two unidirectional flow records can be generated, i.e., one uplink or one downlink flow record. Most of the time, packet characteristics only appear in the request direction, and the traffic in the response direction is not identifiable. Therefore, it is necessary to associate the uplink and downlink flow records of different equipment rooms into a single call detail record (CDR). By aggregating the flow data from different equipment rooms to obtain aggregated data, data with the same address are grouped together, and the aggregated data with the same IP address is associated with uplink and downlink data to obtain asymmetric associated CDR data, realizing bidirectional CDR synthesis.

[0035] S103. According to the time window, associate the Domain Name System (DNS) call detail records (CDRs) and Hypertext Transfer Security Protocol (HTTP) call detail records (CTDRs) in the asymmetric association CDR data. For each HTTP CTDR, backfill the associated DNS domain name and alias record fields into the HTTP CTDR to obtain the deep packet inspection (DPI) CDR synthesis result.

[0036] To protect user privacy and network security, the current standard call detail record (CDR) synthesis process uses the Hypertext Transfer Security (HTTPS) protocol employed by internet operators to encrypt information transmitted over the network, with some major companies announcing full-stack HTTPS implementation. As internet applications become more numerous and updated more rapidly, and as more applications adopt HTTPS for traffic encryption, the challenge of improving call detail record accuracy will become increasingly severe.

[0037] The Hypertext Transfer Security (HTTPS) protocol is an HTTP protocol built on top of the session layer TLS / SSL protocol. Information from the application layer is encrypted using TLS before being passed to the transport layer, resulting in encrypted messages throughout the link, making it difficult to extract usable features. The `server_name` feature can only be seen in messages such as client hello requests, but the fill rate of this field is still insufficient, hindering the identification of existing encrypted services.

[0038] To address the aforementioned issues, considering that DNS resolution requests and HTTPS requests occur sequentially, the resolved IP returned by the DNS request is the same as the server IP connected to the HTTPS request. For some HTTPS services, DPI (Deep Packet Inspection) only knows the source and destination IPs, ports, and traffic volume, but not the content of the traffic. However, DNS, which also knows the source and destination IPs and ports but not the traffic volume, does know the accessed domain name. This means that the source and destination IPs can act as an intermediary between DPI and DNS, organically combining traffic volume and domain name, and backfilling the DNS-resolved domain name into the HTTPS call detail record (CDR), achieving deep parsing of HTTPS encrypted traffic. For the same user's access records, combined with a time window, DNS CDRs and HTTPS CDRs are correlated. For each HTTPS CDR, the associated DNS-resolved domain name and alias record fields are backfilled into the HTTPS CDR, resulting in the Deep Packet Inspection (DPI) CDR composite result.

[0039] This application provides a call detail record (CDR) synthesis method. It involves aggregating CDR data from all data centers within a target area to obtain aggregated data. Then, according to preset address rules, packets belonging to the same CDR in the aggregated data are associated to obtain asymmetric associated CDR data. Next, Domain Name System (DNS) CDRs and Hypertext Transfer Security (HPS) CDRs from the asymmetric associated CDR data are associated. Finally, the associated DNS domain name and alias record fields are backfilled into the HPS CDRs to obtain the deep packet inspection (DPI) CDR synthesis result. This method effectively saves network transmission resources, reduces data packet loss, processes all data, improves the bidirectional integrity and recognizability of CDRs, and can quickly respond to changes in HTTPS service characteristics. It also expands the DPI CDR service recognition and analysis capabilities, providing strong big data infrastructure support for internet content resource operation.

[0040] against Figure 1 The corresponding caller ID synthesis method, Figure 2 This is a flowchart illustrating another call detail record (CDR) synthesis method provided in an embodiment of this application. According to... Figure 2The provided diagram illustrates that, to achieve DPI call detail record (CDR) synthesis, the DPI hardware first matches a pre-extracted and maintained manual message feature library to associate service IDs. Data from different data centers is then linked through data splitting to achieve a shared source and destination. Furthermore, asymmetric big data streaming association is used to bidirectionally associate the streaming data from different data centers. Unlike existing technologies that directly identify associated streaming data based on message features, this approach associates DNS and HTTPS CDRs, backfilling the DNS-resolved domain name into the HTTPS CDR to achieve CDR synthesis. The CDRs are then sent to a big data cluster for further secondary identification, effectively saving network transmission resources, reducing data packet loss, and improving the bidirectional integrity and recognizability of CDRs. This provides strong big data infrastructure support for internet content resource operation and other related tasks.

[0041] Figure 3 This is a schematic diagram of a process for determining asymmetric associated call detail record (CDR) data provided in an embodiment of this application. Figure 3 This refers to the process of determining asymmetric associated call detail record (CDR) data in step S102. Figure 3 Is Figure 1 The description is based on the corresponding embodiments. Figure 3 The provided diagram shows that the steps for determining asymmetric associated call detail record (CDR) data include: S301~S302.

[0042] S301. Group the messages in the aggregated data according to five-tuples or six-tuples, and determine the target number of groups and the diversion data.

[0043] S302. For each group corresponding to the target number of groups, the split data is associated with the messages of the same five-tuple as a single call detail record (CDR), and the messages of the same six-tuple are associated as a single CDR to obtain asymmetric associated CDR data.

[0044] The 5-tuple mentioned here can be understood as source IP address, destination IP address, source port, destination port, and protocol type. The 6-tuple can be understood as source IP address, destination IP address, source port, destination port, protocol type, and transaction ID.

[0045] For aggregated data that may include information such as 5-tuples, service IDs, and uplink / downlink traffic, the process first merges aggregated data from the same data center into a single record based on 5-tuples, then identifies services for each packet, and finally outputs the flow record. For 6-tuples, uplink / downlink flow records from different data centers are associated into a single call detail record (CDR), thus enabling data association operations on aggregated data with the same source and destination, resulting in asymmetric associated CDR data. Finally, the system distributes flow records and mirrored packets collected from all data center DPIs according to certain IP rules (source IP or source-destination IP pairs) to the corresponding data centers, ensuring that packets with the same source IP are distributed to the same collection server, facilitating association.

[0046] This application embodiment achieves the same source and destination for aggregated data by aggregating streaming data from different regions and equipment rooms and then re-collecting it according to the processor. The aggregated data from the same equipment room is then associated with their respective call detail records according to different five-tuples or six-tuples.

[0047] Figure 4 This is a schematic diagram of a process for determining the number of target groups and the diversion of data, provided in an embodiment of this application. Figure 4 This refers to the process of determining the target number of groups and the diversion of data in step S301. Figure 4 Is Figure 3 The description is based on the corresponding embodiments. Figure 4 The provided diagram shows the steps for determining the target number of groups and the diversion data, including: S401~S403.

[0048] S401. Group the aggregated data according to 5-tuples or 6-tuples, group the request data and response data of the same 5-tuple or 6-tuple stream data in the aggregated data into the same group, and determine the target number of groups.

[0049] S402. Use a hash algorithm to obtain the hash code corresponding to the source and destination addresses of the aggregated data in each computer room.

[0050] S403. Perform a modulo division operation on the target number of packets based on the hash code to determine the split data corresponding to each packet.

[0051] The aggregated data is read from the message queue and matched with the corresponding metadata. All flow records and mirrored packets collected by the DPIs in all data centers are grouped / bucketed according to certain IP rules or 5-tuples and 6-tuples (source IP or source-destination IP pairs), resulting in c groups, which determines the target number of groups. For example, if a province has n user IPs and the DPIs are deployed in c data centers for data collection and call detail record (CDR) synthesis, theoretically, each data center could collect n IPs. Requests and responses for the same flow data are grouped into the same bucket, and multiple request and response packets in the same bucket are associated to obtain the target number of groups and the corresponding data for each group. Then, a hash algorithm is used to obtain the hash code of the source-destination IP address of each packet collected by the DPIs in each data center. This hash code is then modulo (mod, i.e., modulo) the target number of groups c. This allows the data to be divided into c groups based on IP address characteristics, with data from the same IP address assigned to the same group, resulting in the distributed data for each group. For each of the c data centers, c sets of data are retrieved to the local machine via transmission links. The data acquisition software in each local machine then performs bidirectional call detail record (CDR) synthesis. The synthesized CDRs are then transmitted again to the big data platform for storage and subsequent use by consumers.

[0052] In one possible example scenario, Figure 5 This is a flowchart illustrating a process for routing data from the same source and destination, as provided in an embodiment of this application. According to... Figure 5 The provided diagram illustrates how DPI call detail records (CDRs) and streaming data collected from all data centers are grouped into five-tuples or six-tuples. Specifically, DPIs and streaming data within the same data center are grouped and distributed to different collection servers, while DPIs and streaming data from different data centers with the same source and destination IP addresses are distributed to the same collection server. Data on each collection server is then correlated to achieve a shared-source-same-destination flow. The correlated and synthesized data is stored in a big data platform, enabling asymmetric correlation of big data streams. This achieves the effect of shared-source-same-destination flow, solving the problem of high network transmission resource requirements and low utilization efficiency when DPI traffic converges across data centers with the same source and destination.

[0053] Figure 6 This is a schematic diagram of another process for determining asymmetric associated call detail record (CDR) data provided in an embodiment of this application. Figure 6 This refers to the process of determining asymmetric associated call detail record (CDR) data in step S302. Figure 6 Is Figure 3 The description is based on the corresponding embodiments. Figure 6 The provided diagram shows that the steps for determining asymmetric associated call detail record (CDR) data include: S601~S602.

[0054] S601. For each group corresponding to the target number of groups, the request data and message data are associated and merged according to the source and destination addresses in the five-tuple or six-tuple to obtain the composite data.

[0055] S602. Based on the synthetic data and target timestamp, determine the latency index of the associated backfilling and obtain the asymmetric associated call detail record data corresponding to each group.

[0056] The source and destination addresses mentioned here refer to the source IP address and the destination IP address.

[0057] Furthermore, the streaming data is grouped or batched according to a six-tuple (source and destination IPs and ports, protocol type, and transaction ID). Requests and responses from the same stream are grouped into the same bucket to obtain a batch. Multiple request and response messages within the same bucket are associated to form a single call detail record (CDR), and the latency metrics of the entire stream are calculated and backfilled based on relevant timestamps, achieving asymmetric data association and synthesis. The bidirectional CDR of the associated and synthesized data is then transmitted to the next stage, realizing the association between Domain Name System (DNS) CDRs and Hypertext Transfer Security Protocol (HTTPS) CDRs.

[0058] This application embodiment groups and merges streaming data from the same data center according to five-tuples or six-tuples, and uses timestamps to set different time windows to provide an environment for the next step of association backfilling.

[0059] In one possible example scenario, Figure 7 This is a flowchart illustrating a call detail record (CDR) association backfilling process provided in an embodiment of this application. According to... Figure 7 The provided diagram illustrates that in DNS call detail records (CDRs), the IP address returned by the user's DNS resolution request is the same as the server IP address used to establish the connection in the HTTPS (i.e., DPI XDR CDR) request. This provides crucial identification information for the backfilling of the association. Comparing the information within the dashed box, due to the encryption operations of some HTTPS services, DPI can only know the source and destination IP addresses, ports, and traffic volume, but not the content of the traffic. However, DNS CDRs, which also know the source and destination IP addresses and ports but not the traffic volume, do know the DNS domain name being accessed. This presents a deficiency in CDR synthesis between the two, but this deficiency is complementary. The source and destination IP addresses within the dashed box can be used as a medium between DPI and DNS CDRs. By associating DPI and DNS CDRs, the traffic volume and DNS domain name can be organically combined. The DNS domain name can then be backfilled in the HTTPS CDR (i.e., DPI XDR CDR). Based on the information of the backfilled DNS domain name, the corresponding traffic content of the associated HTTPS CDR can be found, achieving deep analysis of HTTPS encrypted traffic. Optionally, based on... Figure 7 As shown, based on the same public IP address used in the two processes within the dashed box, but different user ports, for the same user's access records, the timestamp can be combined to backfill the domain name with the closest time difference or within a certain threshold range, thereby determining the principle of association backfilling between DNS call detail records and HTTPS call detail records.

[0060] Figure 8 This is a flowchart illustrating another call detail record (CDR) synthesis method provided in this application embodiment. Figure 8 This refers to the process of determining call detail record (CDR) synthesis in step S103. Figure 8 Is Figure 1 The description is based on the corresponding embodiments. Figure 8 The provided diagram shows that the steps of the call detail record (CDR) synthesis method include: S801~S804.

[0061] S801. Extract data from asymmetric association call detail records (CDRs) according to different protocol types to obtain Domain Name System (DNS) CDRs and Hypertext Transfer Security Protocol (HTTP) CDRs.

[0062] S802. Based on the time window, perform association processing on Domain Name System (DNS) call detail records (CDRs) and Hypertext Transfer Security Protocol (HTTP) call detail records (CDRs) to obtain associated CDRs.

[0063] S803. Obtain Domain Name System (DNS) resolution requests and Hypertext Transfer Security Protocol (HTTP) call detail records (CDRs) from asymmetric association call detail record (CDR) data.

[0064] S804. Based on Domain Name System (DNS) resolution requests and Hypertext Transfer Security Protocol (HTTP) call detail record (CDR) requests, backfill the DNS resolution domain name for associated CDRs with the same source and destination addresses to obtain the deep packet inspection (DPI) CDR synthesis result.

[0065] Because asymmetric association call detail record (CDR) data contains both HTTPS and DNS protocol types, data is extracted according to different protocol types to obtain CDRs corresponding to each protocol type. Hypertext Transfer Security Protocol (HTTPS) CDRs are obtained by extracting data from HTTPS protocol type data; Domain Name System (DNS) CDRs are obtained by extracting data from DNS protocol type data. After grouping the CDRs by source and destination IP addresses, a time window is set for each bucket batch. DNS and HTTPS CDRs belonging to the same bucket are associated within the current time window, and the successfully associated CDRs are recorded as associated CDRs. Then, DNS domain name resolution requests and HTTPS CDR requests in the DNS CDRs are processed within the current time window to obtain the corresponding DNS resolution domain names. The obtained DNS resolution domain names are then backfilled into the HTTPS CDR requests within the current time window, achieving the association and backfilling of DNS and HTTPS CDRs, resulting in the DPI (Depth Packet Inspection) CDR synthesis result for the current time window. The same operational steps are then followed until the next time window to associate and backfill DNS and HTTPS CDRs in the other bucket.

[0066] This application embodiment obtains DPI call detail records (CDRs) from upstream asymmetric association via streaming operations. During the asymmetric association stage, CDRs are bucketed according to source and destination IPs. HTTPS and DNS bidirectional CDRs are extracted from the DPI CDRs based on protocol type. The HTTPS and DNS CDRs are then associated within a time window. By responding to DNS resolution requests, the corresponding DNS resolution domain name is obtained and backfilled into the HTTPS CDR, achieving the association and backfilling of HTTPS and DNS CDRs to obtain the final DPI CDR. This enables fast, accurate, and lightweight service feature extraction and identification, compensating for the shortcomings of DPI in identifying encrypted services and solving the problems of slow update speed and incomplete identification of encrypted traffic when manually extracting packet features.

[0067] Figure 9 This is a schematic diagram of a process for determining associated call detail records provided in an embodiment of this application. Figure 9 This refers to the process of determining the associated call detail records in step S802. Figure 9 Is Figure 8 The description is based on the corresponding embodiments. Figure 9 The provided diagram shows that the steps to determine the associated call detail records include: S901~S902.

[0068] S901. Data tagging is performed on Domain Name System (DNS) call detail records (CDRs) and Hypertext Transfer Security Protocol (HTTP) call detail records (CDRs) to obtain DNS Resilient Distributed Dataset and HTTPS Resilient Distributed Dataset.

[0069] S902. Based on the time window, perform data association between the DNS Elastic Distributed Dataset and the HTTPS Elastic Distributed Dataset in the DNS host records to obtain the associated call detail records in the DNS host records.

[0070] The DNS Resilient Distributed Dataset mentioned here is referred to as dnsRDD, and the HTTPS Resilient Distributed Dataset is referred to as httpsRDD.

[0071] Furthermore, after grouping the aggregated data, multiple groups are obtained, each group serving as a bucket. The DNS and HTTPS call detail records (CDRs) within each bucket are then labeled, resulting in the DNS Resilient Distributed Dataset (dnsRDD) and the HTTPS Resilient Distributed Dataset (httpsRDD). Within the time window of the current bucket, the dnsRDD and httpsRDD are associated with the DNS host records (DNS HOST records), yielding the associated CDRs. This provides reference data for the next step of HTTPS CDR sharing and storage.

[0072] In this embodiment, the data is grouped according to different source and destination IP addresses to obtain multiple group data. Each group of data corresponds to a time window. Within different time windows, the marked DNS elastic distributed dataset and HTTPS elastic distributed dataset are associated to achieve the purpose of associating the IP address information in the DNS call detail record with the IP address in the HTTPS call detail record, providing reference data for the next step of synthesizing DPI call detail records.

[0073] Figure 10 This is a flowchart illustrating another call detail record (CDR) synthesis method provided in this application embodiment. Figure 10 This refers to the call detail record (CDR) synthesis process in step S804. Figure 10 Is Figure 8 The description is based on the corresponding embodiments. Figure 10 The provided diagram shows that the steps for determining asymmetric associated call detail record (CDR) data include: S1001~S1004.

[0074] S1001. Calculate the DPI timestamp field of the associated call detail records (CDRs) for packets with the same source and destination IP addresses based on Domain Name System (DNS) resolution requests and Hypertext Transfer Security Protocol (HTTP) call detail record (CDR) requests, and calculate the DNS time field in the corresponding log of the DNS CDR.

[0075] S1002. Use the minimum difference between the DPI timestamp field and the DNS time field as the target backfill record.

[0076] S1003. Fill the DNS resolution domain name and alias record fields back into the target backfill record to determine the HTTPS association backfill result.

[0077] S1004. Based on the HTTPS association backfilling results, obtain the deep packet inspection call detail record synthesis results.

[0078] Within each bucket batch with the same source and destination IP addresses, the difference between the DPI call detail record timestamp field and the time field in the DNS log is calculated to obtain target backfill records in multiple buckets. For each HTTPS call detail record, the target backfill record with the smallest time difference is selected as the final selected HTTPS call detail record. The DNS resolution domain name and alias record CNAME fields are backfilled to obtain the HTTPS association backfill result. This provides data reference for the next step of data record storage and the association backfill of DNS call detail records and HTTPS call detail records in the next time window, thus realizing DPI call detail record synthesis.

[0079] This application embodiment uses streaming association to backfill DNS call detail records (CDRs) and HTTPS CDRs, backfilling the DOMAIN domain name and CNAME from the DNS resolution process into the HTTPS CDR, thereby achieving fast, accurate, and lightweight extraction and identification of service features.

[0080] Figure 11 This is a flowchart illustrating another call detail record (CDR) association backfilling process provided in this application embodiment. Figure 11 This refers to the call detail record (CDR) association backfilling process in step S1004. Figure 11 Is Figure 10 The description is based on the corresponding embodiments. Figure 11 The provided diagram shows that the steps for determining asymmetric associated call detail record (CDR) data include: S1101~S1102.

[0081] S1101. If the HTTPS association backfill result is successful, output the successfully associated HTTPS call detail records to the target message queue.

[0082] S1102. If the HTTPS association backfilling result is that the association failed, output the failed HTTPS call detail records (CDRs) and DNS call detail records to the target cache, and perform the HTTPS CDR and DNS CDR association backfilling operation corresponding to the next time window.

[0083] After performing association backfilling operations on DNS and HTTPS call records (CDRs) within different time windows, there is an issue of whether the association backfilling is successful. If the HTTPS association backfilling result is successful, the resulting DPI CDR is stored in a message queue. If the HTTPS association backfilling result is unsuccessful, and the reason for the failure is uncertain, the failed HTTPS and DNS CDRs are output to the target cache for temporary storage. Before the next time window executes the association backfilling process between the included DNS and HTTPS CDRs, the failed HTTPS and DNS CDRs stored in the target cache are sent to the next time window, merged with the DNS and HTTPS CDRs to be associated and backfilled in the next time window, and then the DNS and HTTPS CDR association backfilling operation is performed. This ensures that failed association CDRs can quickly generate DPI CDRs.

[0084] This application embodiment analyzes the results of the association backfilling of DNS call detail records (CDRs) and HTTPS call detail records (CDRs), and further stores the successfully backfilled CDRs in the message queue; it also temporarily stores the failed DNS and HTTPS CDRs in the cache to wait for the next association backfilling operation in the next time window, which effectively improves the association backfilling efficiency of DNS and HTTPS CDRs and improves the DPI CDR synthesis effect.

[0085] In one possible example scenario, Figure 12 This is a flowchart illustrating another call detail record (CDR) association backfilling process provided in an embodiment of this application. According to... Figure 12The provided diagram illustrates that within each bucket of the source and destination IP addresses (e.g., the current bucket batch1), the difference between the DPI call detail record timestamp field (Procedure_Start_Time) and the time field (Procedure_Time) in the DNS log is calculated. For each HTTPS call detail record, the record with the smallest time difference is selected as the final selected record, and the DNS resolution domain name and CNAME fields are backfilled. Successfully associated HTTPS call detail records are output to the Kafka message queue; unassociated HTTPS and DNS call detail records are placed in the cache, awaiting association in the next batch2. The second batch2 job reads the DPI call detail record R0 from the next time window (i.e., the output of batch2 is R0) and reads the unassociated data R1 from the previous batch1 (i.e., the output of batch1 is R1) from the cache, and performs association backfilling again. Successfully associated HTTPS call detail records are output to streaming data and shared downstream; HTTPS and DNS call detail records that failed to associate in the first attempt are placed in the cache, awaiting association in the next batch. For the second failed association of HTTPS CDRs, or if a set association failure threshold is set, when the number of failed associations between HTTPS and DNS CDRs exceeds the set threshold, the failed HTTPS and DNS CDRs are deleted, the data is cleaned up, the corresponding locations are set to empty, and the data is also put into sharing, thus achieving periodic cleanup of cached data. Subsequent batches are the same as the second batch, performing streaming association within a time window, continuously running and outputting CDRs to obtain the final DPI CDR.

[0086] In one possible example scenario, Figure 13 This is a flowchart illustrating another call detail record (CDR) association backfilling process provided in an embodiment of this application. According to... Figure 13 The provided diagram illustrates the call detail record (CDR) synthesis process as follows: Step 1: Aggregate the streaming data of DNS call detail records and HTTPS call detail records from different data centers into the message queue Kafka; Step 2: Read the call detail record (CDR) stream data from the message queue; Step 3: Bucket the call detail record (CDR) stream data according to IP addresses such as 5-tuples or 6-tuples (source and destination IP and port, protocol type, transaction ID, etc.) (group the data according to the same IP to obtain multiple buckets / batches). Group the requests and responses of the same stream data into the same bucket, and associate the uplink and downlink stream records of different data centers into a single CDR to achieve asymmetric association operation of CDRs. Step 4: In each bucket, the source and destination IP addresses are used as the medium between DPI call detail records (CDRs) and DNS call detail records (DDRs) to organically combine the traffic volume and domain name in the CDRs. The DNS resolution domain name and CNAME field are then backfilled into the HTTPS CDRs to achieve deep parsing of HTTPS encrypted traffic. Step 5: If the backfill association is successful, the backfill data is stored in the message queue Kafka and the downstream call detail record (CDR) is pushed. If the backfill fails, the failed backfill data is stored in the cache and waited for the next time the association backfill corresponding to the time serial port to be called to re-associate and backfill. If the association backfill fails multiple times, the failed data is cleared to realize DPI call detail record synthesis.

[0087] Figure 14 This is a schematic diagram of a call detail record (CDR) synthesis device provided in an embodiment of this application. Figure 14 The provided diagram shows that the specific structure of the call detail record (CDR) synthesizer 100 includes: The aggregation module 1401 is used to aggregate call detail records (CDRs) from all data centers within the target area into the target message queue to obtain aggregated data. The asymmetric association module 1402 is used to associate packets belonging to the same call detail record (CDR) in the aggregated data according to preset address rules to obtain asymmetric association CDR data. The associated backfill module 1403 is used to associate Domain Name System (DNS) call detail records (CDRs) and Hypertext Transfer Security Protocol (HTTP) call detail records (CTDRs) in asymmetric association call detail record (CTDR) data according to a time window. For each HTTP CTDR, the associated DNS domain name and alias record fields are backfilled into the HTTP CTDR to obtain the deep packet inspection (DPI) call detail record synthesis result.

[0088] The call detail record (CDR) synthesizer provided in this embodiment can be as follows: Figure 14 The call detail record (CDR) synthesizer 100 shown can achieve Figures 1-13 For a detailed description of the technical effects of the call detail record (CDR) synthesis method shown, please refer to [link / reference]. Figures 1-13 The corresponding explanation is concise and will not be elaborated upon here.

[0089] Figure 15 This is a schematic diagram of a call detail record (CDR) synthesis device provided in an embodiment of this application. The CDR synthesis device may include a processor 1501 and a memory 1502 storing computer program instructions.

[0090] Specifically, the processor 1501 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0091] Memory 1502 may include mass storage for data or instructions. For example, and not limitingly, memory 1502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1502 may include removable or non-removable (or fixed) media. Where appropriate, memory 1502 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 1502 is non-volatile solid-state memory.

[0092] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this application.

[0093] The processor 1501 reads and executes computer program instructions stored in the memory 1502 to implement any of the call detail record (CDR) synthesis methods in the above embodiments.

[0094] In one example, the call detail record (CDR) synthesis device may also include a communication interface 1503 and a bus 1510. For example, Figure 15 As shown, the processor 1501, memory 1502, and communication interface 1503 are connected through bus 1510 and complete communication with each other.

[0095] The communication interface 1503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0096] Bus 1510 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0097] Furthermore, in conjunction with the call detail record (CDR) synthesis methods described in the above embodiments, this application can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the CDR synthesis methods described in the above embodiments.

[0098] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the call detail record (CDR) synthesis methods described in the above embodiments.

[0099] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0100] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0101] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0102] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0103] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for synthesizing call detail records (CDRs), characterized in that, include: The call detail records (CDRs) of all data centers within the target area are aggregated into the target message queue to obtain aggregated data. According to preset address rules, packets belonging to the same call detail record (CDR) in the aggregated data are associated to obtain asymmetric associated CDR data. According to the time window, the DNS records and Hypertext Transfer Security Protocol (HTTP) records in the asymmetric association call detail record (CDR) data are associated. For each HTTP HTTP record, the associated DNS resolution domain name and alias record fields are backfilled into the HTTP HTTP record to obtain the deep packet inspection (DPI) CDR synthesis result.

2. The method according to claim 1, characterized in that, The step of associating packets belonging to the same call detail record (CDR) in the aggregated data according to preset address rules to obtain asymmetric associated CDR data includes: The packets in the aggregated data are grouped according to five-tuples or six-tuples to determine the target number of groups and the diverted data; For each group corresponding to the target number of groups, the traffic splitting data is associated into a single call detail record (CDR) based on messages with the same five-tuple, and messages with the same six-tuple are associated into a single CDR to obtain asymmetric associated CDR data.

3. The method according to claim 2, characterized in that, The step of grouping the packets in the aggregated data according to five-tuples or six-tuples to determine the target number of packets and the diverted data includes: The aggregated data is grouped according to 5-tuples or 6-tuples. The request data and response data of the same 5-tuple or 6-tuple stream data in the aggregated data are grouped into the same group to determine the target number of groups. The hash code corresponding to the source and destination addresses of the aggregated data in each computer room is obtained using a hash algorithm. Based on the hash code, a modulo division operation is performed on the target number of groups to determine the split data corresponding to each group.

4. The method according to claim 3, characterized in that, The traffic splitting data in each group corresponding to the target number of groups is associated into a single call detail record (CDR) based on messages with the same 5-tuple, and messages with the same 6-tuple are associated into a single CDR, resulting in asymmetric associated CDR data, including: The request data and message data in each group corresponding to the target number of groups are associated and merged according to the source and destination addresses in the five-tuple or six-tuple to obtain the composite data. Based on the synthesized data and the target timestamp, the latency index of the associated backfill is determined, and the asymmetric associated call detail record data corresponding to each group is obtained.

5. The method according to claim 4, characterized in that, The process involves associating Domain Name System (DNS) call detail records (CDRs) and Hypertext Transfer Security (HTS) call detail records (CTDRs) from the asymmetric association CDR data according to a time window. For each HTS CDR, the associated DNS domain name and alias record fields are then backfilled into the HTS CDR to obtain a deep packet inspection (DPI) CDR synthesis result, including: The asymmetric associated call detail record (CDR) data is extracted according to different protocol types to obtain Domain Name System (DNS) CDRs and Hypertext Transfer Security Protocol (HTTP) CDRs. Based on a time window, the Domain Name System (DNS) call detail records (CDRs) and the Hypertext Transfer Security Protocol (HTTP) call detail records (CDRs) are associated to obtain associated CDRs. Obtain the Domain Name System (DNS) resolution request and Hypertext Transfer Security Protocol (HTTP) call detail record (CDR) request from the asymmetric association call detail record (CDR) data; Based on the Domain Name System (DNS) resolution request and Hypertext Transfer Security Protocol (HTTP) call detail record (CDR) request, the associated CDRs with the same source and destination addresses are backfilled with the DNS resolution domain name to obtain the deep packet inspection (DPI) CDR synthesis result.

6. The method according to claim 5, characterized in that, The process of associating the Domain Name System (DNS) call detail records (CDRs) and the Hypertext Transfer Security Protocol (HTTP) CDRs based on a time window to obtain associated CDRs includes: Data tags are applied to the Domain Name System (DNS) call detail records (CDRs) and the Hypertext Transfer Security Protocol (HTTP) call detail records (HTPCs) to obtain the DNS Resilient Distributed Dataset and the HTTPS Resilient Distributed Dataset. Based on a time window, the DNS elastic distributed dataset and the HTTPS elastic distributed dataset are correlated in the DNS host records to obtain the associated call detail records in the DNS host records.

7. The method according to claim 5, characterized in that, The process of backfilling the DNS resolution domain name for the associated call records with the same source and destination addresses based on the DNS resolution request and the Hypertext Transfer Security Protocol (HTTP) call record request to obtain the deep packet inspection call record synthesis result includes: Based on the Domain Name System (DNS) resolution request and Hypertext Transfer Security Protocol (HTTP) call detail record (CDR) request, calculate the DPI timestamp field of the associated CDR for packets with the same source and destination IP, and calculate the DNS time field in the corresponding DNS CDR log. The minimum value between the DPI timestamp field and the DNS time field is used as the target backfill record; The DNS resolution domain name and alias record fields are backfilled into the target backfill record to determine the HTTPS association backfill result; The deep packet inspection call detail record (CDR) synthesis result is obtained based on the HTTPS association backfilling result.

8. The method according to claim 7, characterized in that, The deep packet inspection call detail record (CDR) synthesis result obtained based on the HTTPS association backfilling result includes: If the HTTPS association backfill result is successful, the successfully associated HTTPS call detail record will be output to the target message queue. If the HTTPS association backfilling result is that the association fails, the failed HTTPS call detail records (CDRs) and DNS call detail records will be output to the target cache, and the HTTPS CDR and DNS CDR association backfilling operation corresponding to the next time window will be executed.

9. A call detail record (CDR) synthesis device, characterized in that, The device includes: The aggregation module is used to aggregate call detail records (CDRs) from all data centers within the target area into the target message queue to obtain aggregated data. The asymmetric association module is used to associate packets belonging to the same call detail record (CDR) in the aggregated data according to preset address rules to obtain asymmetric associated CDR data. The associated backfilling module is used to associate the Domain Name System (DNS) call detail records (CDRs) and Hypertext Transfer Security Protocol (HTTP) call detail records (HTPs) in the asymmetric associated CDR data according to the time window. For each HTP call detail record, the associated DNS domain name and alias record fields are backfilled into the HTP call detail record to obtain the deep packet inspection (DPI) call detail record synthesis result.

10. A call detail record (CDR) synthesis device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the call detail record (CDR) synthesis method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the call detail record (CDR) synthesis method as described in any one of claims 1-8.

12. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the call detail record (CDR) synthesis method as described in any one of claims 1-8.

Images