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 PDFInfo
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 238000012544 monitoring process Methods 0.000 claims abstract description 9
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 5
- 230000006870 function Effects 0.000 claims description 60
- 238000012545 processing Methods 0.000 claims description 33
- 238000001914 filtration Methods 0.000 claims description 10
- 230000004044 response Effects 0.000 claims description 8
- 230000032683 aging Effects 0.000 claims description 5
- 238000004891 communication Methods 0.000 description 6
- 238000001514 detection method Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000004590 computer program Methods 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000005236 sound signal Effects 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000005484 gravity Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000010897 surface acoustic wave method Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network 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
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.
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)
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 |
-
2024
- 2024-02-20 CN CN202410189197.1A patent/CN118075227A/en active Pending
Patent Citations (5)
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)
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 |