CN118075227A - Method for accurately matching domain name and variable domain name and IP - Google Patents

Method for accurately matching domain name and variable domain name and IP Download PDF

Info

Publication number
CN118075227A
CN118075227A CN202410189197.1A CN202410189197A CN118075227A CN 118075227 A CN118075227 A CN 118075227A CN 202410189197 A CN202410189197 A CN 202410189197A CN 118075227 A CN118075227 A CN 118075227A
Authority
CN
China
Prior art keywords
packet
data packet
packets
function
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202410189197.1A
Other languages
Chinese (zh)
Inventor
刘智超
周萌
田鹏
陈金娟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Lenovo Understand Communication Co ltd
Original Assignee
Guangdong Lenovo Understand Communication Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangdong Lenovo Understand Communication Co ltd filed Critical Guangdong Lenovo Understand Communication Co ltd
Priority to CN202410189197.1A priority Critical patent/CN118075227A/en
Publication of CN118075227A publication Critical patent/CN118075227A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/10Mapping addresses of different types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention particularly relates to a method for precisely matching domain names and variable domain names with IP (Internet protocol), which comprises the following steps: monitoring DNS ports of all appointed network ports, and capturing packets by adopting a Libpcap; distinguishing IP/ARP/RARP packets through shift operation; analyzing the IP packet to obtain a slice offset, and calculating the offset to obtain a Protocol upper layer as TCP/UDP/ICMP; the hash algorithm matches questions, answers values under the query region; and acquiring a new IP corresponding relation in the DNS return packet, and giving the new IP corresponding relation to the flow control in real time through the shared memory, and ending the flow. The invention provides a method for accurately matching domain names and maximally covering the relationship between network traffic and IP and CDN (variable IP), and the portability and easy operability of flow control can be improved by adopting a Libpcap library.

Description

Method for accurately matching domain name and variable domain name and IP
Technical Field
The invention particularly relates to a method for precisely matching domain names and variable domain names with IP.
Background
With the arrival of the 5G age of the end user, the flow control can effectively prevent impact on the network caused by a large amount of instantaneous data in the network, and ensure the efficient and stable operation of the user network.
The network flow control of the traditional data link layer and the network layer mainly depends on three reliable protocols: a stop-and-wait protocol (SW), a fallback N frame protocol (GBN), a selective retransmission protocol (SR). With the continuous development of networks, two-layer flow control is not easy to meet the requirement in practice, and is not easy to be disconnected from an application on one hand, and on the other hand, if a multipoint condition exists between a sending party and a receiving party, the flow control also needs to be controlled in a multipoint mode, so that the service is naturally lost to an upper layer. At present, more flow control is performed based on a session layer, a presentation layer and an application layer, basically, the flow control is only controlled on an IP and a port, which is not problematic in a service-based network environment, but NAT hiding public network IP also exists on a terminal, so that NAT traversal technology is widely used, and a distribution network based on a CDN.
Disclosure of Invention
The invention aims to provide a method for precisely matching domain names and variable domain names with IP (Internet protocol) so as to solve the problems in the background technology.
In order to solve the technical problems, the invention provides the following technical scheme:
the method for precisely matching the domain name, the variable domain name and the IP comprises the following steps:
monitoring DNS ports of all appointed network ports, and capturing packets by adopting a Libpcap;
distinguishing IP/ARP/RARP packets through shift operation;
analyzing the IP packet to obtain a slice offset, and calculating the offset to obtain a Protocol upper layer as TCP/UDP/ICMP;
The hash algorithm matches questions, answers values under the query region;
And acquiring a new IP corresponding relation in the DNS return packet, and giving the new IP corresponding relation to the flow control in real time through the shared memory, and ending the flow.
Further, the method further comprises the steps that through identifying the IP aging period in the CDN distribution network, the local DNS secondarily acquires a cache server IP provided by a global load balancer of the CDN network, and the IP header TOS life cycle is modified to be less than 0xFF; and acquiring a new IP corresponding relation in the DNS echo packet, and ending the flow.
Further, the specific step of monitoring all DNS ports of the appointed network port by adopting the Libpcap to grasp packets includes the steps of using the Libpcap to grasp all DNS port data packets of the appointed network port, including opening the network device: the network device is turned on using the pcap_open_live () function, the device name is typically "eth0" or other, the device type is "net80281", the data link layer type is "dlt_en10mb", and the network mask of the network device interface is specified; compiling a filtering strategy: compiling the filtering strategy specified by the user into a filtering program by using a pcap_common () function; setting a filter: applying the filter compiled in the previous step to the network device using the pcap_ setfilter () function; capturing a data packet: capturing a data packet using a pcap_loop () or pcap_dispatch () function; processing the data packet: in the callback function, various processing can be performed on the captured data packet; closing the network device: when the application completes work, the pcap_close () function may be called to close the network device, freeing up resources.
Further, the specific steps of distinguishing the IP/ARP/RARP packets through shift operation are as follows: reading a data packet: firstly, a data packet is required to be read from a network, the data packet is realized by using a pcap_loop () or a pcap_dispatch () function of a libpcap library, and the captured data packet is transferred to a designated callback function for processing; extracting a data packet head: when each data packet is processed, the header information of the data packet needs to be extracted; the header of the IP packet contains version, header length, service type, total length, identifier, flag, sheet offset and time-to-live (TTL) fields, and the header of ARP and RARP packets contains different fields; judging the protocol type: according to the extracted data packet head information, judging which protocol data packet it is; judging the operation type: for ARP and RARP packets, it is also necessary to determine their operation types, where an operation type field of ARP packet is 0x0001 for Request (Reply), 0x0002 for response (Reply), and an operation type field of RARP packet is 0x8035 for Request (Request), and 0x8036 for response (Reply); processing the data packet: different data packets can be processed differently according to the determined protocol type and operation type.
Further, to parse the IP packet and obtain a slice offset, then calculate, according to the offset, that the upper layer of the protocol is TCP, UDP or ICMP, the specific steps are performed: reading an IP packet: firstly, capturing an IP packet from a network, and transmitting the captured IP packet as a parameter of a callback function to a processing function; analyzing the IP packet: in the processing function, the captured IP packet needs to be parsed, and the structure of the IP packet includes version, header length, service type, total length, identifier, flag, slice offset and Time To Live (TTL) fields, and each field of the IP packet may be represented by a structure body; extract tile offset: after the IP packet is analyzed, a slice offset field can be extracted; judging the protocol type: the protocol type can be judged according to the value of the slice offset; processing protocol data: different protocol data can be processed differently according to the determined protocol type.
Compared with the prior art, the invention has the beneficial effects that:
The invention provides a method for accurately matching domain names and maximally covering the relationship between network traffic and IP and CDN (variable IP), and the portability and easy operability of flow control can be improved by adopting a Libpcap library.
Drawings
FIG. 1 is a flow chart of the present invention for precisely matching domain names and variable domain names (CDNs) and IPs;
fig. 2 is a flowchart for identifying an automatic unbinding correspondence relationship in a CDN aging period according to the present invention.
Detailed Description
The technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention, and it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
As shown in fig. 1, the method for precisely matching domain names and variable domain names with IP includes the following steps:
① Monitoring DNS ports of all appointed network ports, and capturing packets by adopting a Libpcap;
② Distinguishing IP/ARP/RARP packets through shift operation;
③ Analyzing the IP packet to obtain a slice offset, and calculating the offset to obtain a Protocol upper layer as TCP/UDP/ICMP;
④ The hash algorithm matches questions, answers equivalents under the query region;
The method comprises the steps that through identifying an IP aging period in a CDN distribution network, a local DNS secondarily obtains a cache server IP provided by a global load balancer of the CDN, and the TOS life cycle of an IP header is modified to be less than 0xFF; and acquiring a new IP corresponding relation in the DNS echo packet, and ending the flow.
The specific step of monitoring DNS ports of all specified network ports by adopting a Libpcap to grasp packets, the step of using the Libpcap to grasp DNS port data packets of all specified network ports comprises the following steps: 1. opening the network device: the network device is turned on using the pcap_open_live () function, the device name is typically "eth0" or other, the device type is "net80281", the data link layer type is "dlt_en10mb", and the network mask of the network device interface is specified. 2. Compiling a filtering strategy: the user-specified filtering policy is compiled into the filter using the pcap_common () function. For example, if only DNS packets are of interest, filtering rules may be used to filter out packets for the UDP port 53. 3. Setting a filter: the filter compiled in the previous step is applied to the network device using the pcap_ setfilter () function so that the grabbed data packet will only include data that complies with the filtering rules. 4. Capturing a data packet: the data packet is captured using a pcap_loop () or pcap_dispatch () function. These functions will process each captured packet according to the specified callback function. If finer control is required, the packets can also be acquired one by one using the pcap_next () or pcap_next_ex () function. 5. Processing the data packet: in the callback function, various processing may be performed on the captured data packet, such as resolving DNS records, analyzing HTTP requests, and the like. 6. Closing the network device: when the application completes work, the pcap_close () function may be called to close the network device, freeing up resources.
The specific steps of distinguishing the IP/ARP/RARP packets through shift operation are as follows: 1. reading a data packet: first, the data packets need to be read from the network. This can be achieved by using the pcap_loop () or pcap_dispatch () function of the libpcap library. These functions pass the captured data packets to the designated callback function for processing. 2. Extracting a data packet head: as each packet is processed, its header information needs to be extracted. The header of an IP packet contains fields for version, header length, type of service, total length, identifier, flag, slice offset, and time-to-live (TTL). The header of ARP and RARP packets then contain different fields. 3. Judging the protocol type: based on the extracted header information, it can be determined which protocol packet it is. The version field of the IP packet indicates whether it is an IPv4 or IPv6 packet. If the version field is 4, it is an IPv4 data packet; if the version field is 6, it is an IPv6 packet. The protocol type field of ARP packet is 0x0806 and the protocol type field of RARP packet is 0x8035.4. Judging the operation type: for ARP and RARP packets, it is also necessary to determine the type of operation. An operation type field of 0x0001 for ARP packets indicates a Request (Request) and 0x0002 for responses (Reply). The operation type field of the RARP packet is 0x8035 for Request and 0x8036 for response. 5. Processing the data packet: different data packets can be processed differently according to the determined protocol type and operation type. For example, for an IP packet, header information thereof may be parsed and an IP address, port number, etc. may be extracted; for ARP and RARP data packets, the hardware address information of the ARP and RARP data packets can be extracted and processed correspondingly. The above is the step of distinguishing IP, ARP and RARP packets by shift operation.
The specific steps are to analyze the IP packet and obtain the slice offset, and then calculate the upper layer of the protocol to be TCP, UDP or ICMP according to the offset: 1. reading an IP packet: first, it is necessary to capture IP packets from the network. This can be achieved by using the pcap_loop () or pcap_dispatch () function of the libpcap library. The captured IP packets pass parameters as callback functions to the processing functions. 2. Analyzing the IP packet: in the processing function, the captured IP packets need to be parsed. The structure of the IP packet includes fields such as version, header length, service type, total length, identifier, flag, slice offset, and time-to-live (TTL). The various fields of the IP packet may be represented using a structure. 3. Extract tile offset: after parsing the IP packet, the slice offset field may be extracted. The tile offset indicates the offset position of the IP datagram in the tile. Based on the offset, it can be determined whether the IP datagram is fragmented and the sequence of the fragments. 4. Judging the protocol type: the protocol type can be determined from the value of the slice offset. In general, if the slice offset is 0, the protocol type is TCP; if the slice offset is 40, the protocol type is UDP; if the slice offset is 8, the protocol type is ICMP. Of course, this is not absolute, as different operating systems or network environments may vary. Therefore, the determination of the protocol type is preferably made in combination with other fields. 5. Processing protocol data: different protocol data can be processed differently according to the determined protocol type. For example, if the protocol type is TCP, TCP header information may be extracted and port numbers, sequence numbers, etc. may be parsed; if the protocol type is UDP, extracting UDP header information and resolving out port number and the like; if the protocol type is ICMP, ICMP header information may be extracted and parsed out of type, code, checksum, etc.
The invention provides a method for accurately matching domain names and maximally covering the relationship between network traffic and IP and CDN (variable IP), and the portability and easy operability of flow control can be improved by adopting a Libpcap library.
Embodiments of the application that require protection include:
the method for precisely matching the domain name, the variable domain name and the IP comprises the following steps:
monitoring DNS ports of all appointed network ports, and capturing packets by adopting a Libpcap;
distinguishing IP/ARP/RARP packets through shift operation;
analyzing the IP packet to obtain a slice offset, and calculating the offset to obtain a Protocol upper layer as TCP/UDP/ICMP;
The hash algorithm matches questions, answers values under the query region;
And acquiring a new IP corresponding relation in the DNS return packet, and giving the new IP corresponding relation to the flow control in real time through the shared memory, and ending the flow.
Preferably, the method further comprises the steps that the local DNS secondarily acquires a cache server IP provided by a global load balancer of the CDN by identifying an IP aging period in the CDN distribution network, and modifies an IP header TOS life cycle &0xFF; and acquiring a new IP corresponding relation in the DNS echo packet, and ending the flow.
Preferably, the specific step of monitoring all DNS ports of the specified network port by adopting the libpcap to grasp packets includes that the network device is opened by using the libpcap to grasp all DNS port data packets of the specified network port: the network device is turned on using the pcap_open_live () function, the device name is typically "eth0" or other, the device type is "net80281", the data link layer type is "dlt_en10mb", and the network mask of the network device interface is specified; compiling a filtering strategy: compiling the filtering strategy specified by the user into a filtering program by using a pcap_common () function; setting a filter: applying the filter compiled in the previous step to the network device using the pcap_ setfilter () function; capturing a data packet: capturing a data packet using a pcap_loop () or pcap_dispatch () function; processing the data packet: in the callback function, various processing can be performed on the captured data packet; closing the network device: when the application completes work, the pcap_close () function may be called to close the network device, freeing up resources.
Preferably, the specific steps of distinguishing the IP/ARP/RARP packets through shift operation are as follows: reading a data packet: firstly, a data packet is required to be read from a network, the data packet is realized by using a pcap_loop () or a pcap_dispatch () function of a libpcap library, and the captured data packet is transferred to a designated callback function for processing; extracting a data packet head: when each data packet is processed, the header information of the data packet needs to be extracted; the header of the IP packet contains version, header length, service type, total length, identifier, flag, sheet offset and time-to-live (TTL) fields, and the header of ARP and RARP packets contains different fields; judging the protocol type: according to the extracted data packet head information, judging which protocol data packet it is; judging the operation type: for ARP and RARP packets, it is also necessary to determine their operation types, where an operation type field of ARP packet is 0x0001 for Request (Reply), 0x0002 for response (Reply), and an operation type field of RARP packet is 0x8035 for Request (Request), and 0x8036 for response (Reply); processing the data packet: different data packets can be processed differently according to the determined protocol type and operation type.
Preferably, to parse the IP packet and obtain a slice offset, then calculate the upper layer of the protocol as TCP, UDP or ICMP according to the offset, the specific steps are performed: reading an IP packet: firstly, capturing an IP packet from a network, and transmitting the captured IP packet as a parameter of a callback function to a processing function; analyzing the IP packet: in the processing function, the captured IP packet needs to be parsed, and the structure of the IP packet includes version, header length, service type, total length, identifier, flag, slice offset and Time To Live (TTL) fields, and each field of the IP packet may be represented by a structure body; extract tile offset: after the IP packet is analyzed, a slice offset field can be extracted; judging the protocol type: the protocol type can be judged according to the value of the slice offset; processing protocol data: different protocol data can be processed differently according to the determined protocol type.
The embodiment of the application also provides a computer device which can comprise terminal equipment or a server, and the data computing program of the method for precisely matching the domain name and the variable domain name with the IP can be configured in the computer device. The computer device is described below.
If the computer device is a terminal device, the embodiment of the application provides a terminal device, taking the terminal device as a mobile phone as an example:
The mobile phone comprises: radio Frequency (RF) circuitry, memory, input unit, display unit, sensors, audio circuitry, wireless fidelity (WIRELESS FIDELITY, wiFi) module, processor, and power supply.
The RF circuit can be used for receiving and transmitting signals in the process of receiving and transmitting information or communication, particularly, after receiving downlink information of the base station, the downlink information is processed by the processor; in addition, the data of the design uplink is sent to the base station. Typically, RF circuitry includes, but is not limited to, antennas, at least one amplifier, transceivers, couplers, low noise amplifiers (Low NoiseAmplifier, abbreviated as LNAs), diplexers, and the like. In addition, the RF circuitry may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to global system for mobile communications (Global System of Mobile communication, GSM for Short), general packet radio service (GENERALPACKET RADIO SERVICE, GPRS for Short), code division multiple access (Code Division Multiple Access, CDMA for Short), wideband code division multiple access (Wideband Code Division Multiple Access, WCDMA for Short), long term evolution (Long Term Evolution, LTE for Short), email, short message service (Short MESSAGING SERVICE, SMS for Short), etc.
The memory may be used to store software programs and modules, and the processor executes the software programs and modules stored in the memory to perform various functional applications and data processing of the handset. The memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required for at least one function, and the like; the storage data area may store data (such as audio data, phonebook, etc.) created according to the use of the handset, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device.
The input unit may be used to receive input numeric or character information and to generate key signal inputs related to user settings and function control of the handset. In particular, the input unit may include a touch panel and other input devices. The touch panel, also referred to as a touch screen, may collect touch operations thereon or thereabout by a user (e.g., operations thereon or thereabout by a user using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a predetermined program. Alternatively, the touch panel may include two parts, a touch detection device and a touch controller. The touch detection device detects the touch azimuth of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor, and can receive and execute commands sent by the processor. In addition, the touch panel may be implemented in various types such as resistive, capacitive, infrared, and surface acoustic wave. The input unit may include other input devices in addition to the touch panel. In particular, other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, mouse, joystick, etc.
The display unit may be used to display information input by a user or information provided to the user and various menus of the mobile phone. The display unit may include a display panel, which may optionally be configured in the form of a liquid crystal display (LiquidCrystal Display, LCD) or an Organic Light-Emitting Diode (OLED) or the like. Further, the touch panel may overlay the display panel, and upon detection of a touch operation thereon or thereabout, the touch panel is transferred to the processor to determine the type of touch event, and the processor then provides a corresponding visual output on the display panel in accordance with the type of touch event. Although in the figures the touch panel and the display panel are shown as two separate components to implement the input and output functions of the cell phone, in some embodiments the touch panel and the display panel may be integrated to implement the input and output functions of the cell phone.
The handset may also include at least one sensor, such as a light sensor, a motion sensor, and other sensors. In particular, the light sensor may include an ambient light sensor that may configure the brightness of the display panel according to the brightness of ambient light, and a proximity sensor that may turn off the display panel and/or backlight when the phone is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the acceleration in all directions (generally three axes), and can detect the gravity and direction when stationary, and can be used for applications of recognizing the gesture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer gesture calibration), vibration recognition related functions (such as pedometer and knocking), and the like; other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc. that may also be configured with the handset are not described in detail herein.
Audio circuitry, speakers, and microphone may provide an audio interface between the user and the handset. The audio circuit can transmit the received electric signal after the audio data conversion to a loudspeaker, and the loudspeaker converts the electric signal into a sound signal to be output; on the other hand, the microphone converts the collected sound signals into electrical signals, which are received by the audio circuit and converted into audio data, which are processed by the audio data output processor and sent via the RF circuit to, for example, another mobile phone, or which are output to a memory for further processing.
WiFi belongs to a short-distance wireless transmission technology, and a mobile phone can help a user to send and receive an email, browse a webpage, access streaming media and the like through a WiFi module, so that wireless broadband Internet access is provided for the user. Although a WiFi module is illustrated, it is understood that it does not belong to the necessary configuration of the handset, and can be omitted entirely as needed within the scope of not changing the essence of the invention.
The processor is a control center of the mobile phone, and is connected with various parts of the whole mobile phone by various interfaces and lines, and executes various functions and processes data of the mobile phone by running or executing software programs and/or modules stored in the memory and calling data stored in the memory, so that the mobile phone is monitored integrally. In the alternative, the processor may include one or more processing units; preferably, the processor may integrate an application processor and a modem processor, wherein the application processor primarily handles operating systems, user interfaces, applications, etc., and the modem processor primarily handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor.
The handset further includes a power source (e.g., a battery) for powering the various components, preferably in logical communication with the processor through a power management system, such that functions such as managing charge, discharge, and power consumption are performed by the power management system.
Although not shown, the mobile phone may further include a camera, a bluetooth module, etc., which will not be described herein.
In this embodiment, the processor included in the terminal device further has the following functions:
and executing a data calculation program of a method for precisely matching the domain name and the variable domain name with the IP.
If the computer device is a server, the embodiments of the present application further provide a server, where the server may have a relatively large difference due to different configurations or performances, and may include one or more central processing units (Central Processing Units, abbreviated as CPU) and a memory (e.g., one or more processors), one or more storage media (e.g., one or more mass storage devices) storing application programs or data. The memory and storage medium may be transitory or persistent. The program stored on the storage medium may include one or more modules, each of which may include a series of instruction operations on the server. Still further, the central processor may be configured to communicate with a storage medium and execute a series of instruction operations on the storage medium on a server.
The server may also include one or more power supplies, one or more wired or wireless network interfaces, one or more input/output interfaces, and/or one or more operating systems, such as Windows Server, mac OS XTM, unixTM, linuxTM, freeBSDTM, and the like.
In addition, the embodiment of the application also provides a storage medium for storing a computer program for executing the method provided by the embodiment.
The embodiments of the present application also provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method provided by the above embodiments.
Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the above method embodiments may be implemented by hardware related to program instructions, where the above program may be stored in a computer readable storage medium, and when the program is executed, the program performs steps including the above method embodiments; and the aforementioned storage medium may be at least one of the following media: read-only Memory (ROM), RAM, magnetic disk or optical disk, etc.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment is mainly described in a different point from other embodiments. In particular, for the apparatus and system embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, with reference to the description of the method embodiments in part. The apparatus and system embodiments described above are merely illustrative, in which elements illustrated as separate elements may or may not be physically separate, and elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. And will be understood and implemented by those of ordinary skill in the art without undue burden.

Claims (5)

1. The method for precisely matching the domain name and the variable domain name with the IP is characterized by comprising the following steps:
monitoring DNS ports of all appointed network ports, and capturing packets by adopting a Libpcap;
distinguishing IP/ARP/RARP packets through shift operation;
analyzing the IP packet to obtain a slice offset, and calculating the offset to obtain a Protocol upper layer as TCP/UDP/ICMP;
The hash algorithm matches questions, answers values under the query region;
And acquiring a new IP corresponding relation in the DNS return packet, and giving the new IP corresponding relation to the flow control in real time through the shared memory, and ending the flow.
2. The method for precisely matching domain names and variable domain names with IPs according to claim 1, further comprising modifying IP header TOS lifecycle &0xFF by identifying IP aging periods in the CDN delivery network, and the local DNS secondarily obtains a cache server IP provided by a global load balancer of the CDN network; and acquiring a new IP corresponding relation in the DNS echo packet, and ending the flow.
3. The method for precisely matching domain names and variable domain names with IP according to claim 1, wherein the specific step of monitoring DNS ports of all specified ports to capture packets by using a libpcap includes the steps of using the libpcap to capture DNS port packets of all specified ports, including opening a network device: the network device is turned on using the pcap_open_live () function, the device name is typically "eth0" or other, the device type is "net80281", the data link layer type is "dlt_en10mb", and the network mask of the network device interface is specified; compiling a filtering strategy: compiling the filtering strategy specified by the user into a filtering program by using a pcap_common () function; setting a filter: applying the filter compiled in the previous step to the network device using the pcap_ setfilter () function; capturing a data packet: capturing a data packet using a pcap_loop () or pcap_dispatch () function; processing the data packet: in the callback function, various processing can be performed on the captured data packet; closing the network device: when the application completes work, the pcap_close () function may be called to close the network device, freeing up resources.
4. The method for precisely matching domain names and variable domain names with IP according to claim 1, wherein the specific steps of distinguishing IP/ARP/RARP packets by shift operation are as follows: reading a data packet: firstly, a data packet is required to be read from a network, the data packet is realized by using a pcap_loop () or a pcap_dispatch () function of a libpcap library, and the captured data packet is transferred to a designated callback function for processing; extracting a data packet head: when each data packet is processed, the header information of the data packet needs to be extracted; the header of the IP packet contains version, header length, service type, total length, identifier, flag, sheet offset and time-to-live (TTL) fields, and the header of ARP and RARP packets contains different fields; judging the protocol type: according to the extracted data packet head information, judging which protocol data packet it is; judging the operation type: for ARP and RARP packets, it is also necessary to determine their operation types, where an operation type field of ARP packet is 0x0001 for Request (Reply), 0x0002 for response (Reply), and an operation type field of RARP packet is 0x8035 for Request (Request), and 0x8036 for response (Reply); processing the data packet: different data packets can be processed differently according to the determined protocol type and operation type.
5. The method for precisely matching domain name and variable domain name with IP according to claim 1, wherein the specific steps of parsing an IP packet and obtaining a slice offset, and then calculating a protocol upper layer as TCP, UDP or ICMP according to the offset are performed: reading an IP packet: firstly, capturing an IP packet from a network, and transmitting the captured IP packet as a parameter of a callback function to a processing function; analyzing the IP packet: in the processing function, the captured IP packet needs to be parsed, and the structure of the IP packet includes version, header length, service type, total length, identifier, flag, slice offset and Time To Live (TTL) fields, and each field of the IP packet may be represented by a structure body; extract tile offset: after the IP packet is analyzed, a slice offset field can be extracted; judging the protocol type: the protocol type can be judged according to the value of the slice offset; processing protocol data: different protocol data can be processed differently according to the determined protocol type.
CN202410189197.1A 2024-02-20 2024-02-20 Method for accurately matching domain name and variable domain name and IP Pending CN118075227A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410189197.1A CN118075227A (en) 2024-02-20 2024-02-20 Method for accurately matching domain name and variable domain name and IP

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410189197.1A CN118075227A (en) 2024-02-20 2024-02-20 Method for accurately matching domain name and variable domain name and IP

Publications (1)

Publication Number Publication Date
CN118075227A true CN118075227A (en) 2024-05-24

Family

ID=91110691

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410189197.1A Pending CN118075227A (en) 2024-02-20 2024-02-20 Method for accurately matching domain name and variable domain name and IP

Country Status (1)

Country Link
CN (1) CN118075227A (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102056235A (en) * 2009-11-09 2011-05-11 华为技术有限公司 Data transmission method, equipment and system
US20200099600A1 (en) * 2018-09-24 2020-03-26 Cybereason, Inc. Correlating network traffic to their OS processes using packet capture libraries and kernel monitoring mechanisms
CN114006956A (en) * 2021-10-29 2022-02-01 杭州迪普信息技术有限公司 Message data analysis method, device and equipment
CN115022278A (en) * 2022-06-02 2022-09-06 上海哔哩哔哩科技有限公司 CDN processing method and system
US20230108054A1 (en) * 2020-06-04 2023-04-06 Huawei Technologies Co., Ltd. Packet forwarding method and apparatus, device, and storage medium

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102056235A (en) * 2009-11-09 2011-05-11 华为技术有限公司 Data transmission method, equipment and system
US20200099600A1 (en) * 2018-09-24 2020-03-26 Cybereason, Inc. Correlating network traffic to their OS processes using packet capture libraries and kernel monitoring mechanisms
US20230108054A1 (en) * 2020-06-04 2023-04-06 Huawei Technologies Co., Ltd. Packet forwarding method and apparatus, device, and storage medium
CN114006956A (en) * 2021-10-29 2022-02-01 杭州迪普信息技术有限公司 Message data analysis method, device and equipment
CN115022278A (en) * 2022-06-02 2022-09-06 上海哔哩哔哩科技有限公司 CDN processing method and system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
你回到了你的家: "libpcap详解", pages 1, Retrieved from the Internet <URL:https://blog.csdn.net/kking_edc/article/details/118942117> *

Similar Documents

Publication Publication Date Title
CN113518085B (en) Data transmission method based on multiple channels and related device
US20150229669A1 (en) Method and device for detecting distributed denial of service attack
CN110716850B (en) Page testing method, device and system and storage medium
CN104133728B (en) Method and device for communication between processes
CN108040091A (en) Data processing method, device and storage medium
CN107135128B (en) Call chain data acquisition method, mobile terminal and computer-readable storage medium
CN108377157B (en) Control method and device of Wi-Fi antenna
CN105959481B (en) A kind of control method and electronic equipment of scene audio
US11973684B2 (en) Link aggregation implementation method and related product
US20150016439A1 (en) Method and system for mobile terminal to access the network through cell phone
CN113950125B (en) Method, device and storage medium for accelerating network in application program
CN108011937A (en) Information push method, server, intelligent terminal and computer-readable recording medium
CN112245907A (en) Game data acceleration method, storage medium, electronic device and system
CN112242972B (en) Network request processing method, device, storage medium and terminal
CN112492340B (en) Live broadcast audio acquisition method, mobile terminal and computer readable storage medium
CN110099428B (en) Wireless fidelity WiFi network access method, device and terminal
CN115884213A (en) Resource scheduling method and device and electronic equipment
CN105025064B (en) Download the method, apparatus and system of file
EP3000219A1 (en) Access to data source via proxy
CN118075227A (en) Method for accurately matching domain name and variable domain name and IP
CN115118636B (en) Method and device for determining network jitter state, electronic equipment and storage medium
CN108075945B (en) Application testing method and device
CN112153154A (en) Data transmission method and related device
JP2023509407A (en) Multicast service processing method, multicast service configuration method, terminal and network equipment
CN113965446B (en) Fault detection method and system for home broadband network and electronic equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination