Message processing method and device, storage medium and electronic equipment

Abstract

The invention discloses a message processing method and device, a storage medium and electronic equipment. Relates to the technical field of communication, and the method comprises the following steps: receiving a target request message sent by a source device in a broadcast mode, the target request message carrying a query item for a target device; determining a request type of the target request message; based on the request type, a target processing mode for processing the target request message is determined, and the target processing mode is at least used for indicating whether the target request message continues to be forwarded or not. According to the method and the device, the technical problems of network congestion and excessive redundant data transmission caused by sending broadcast messages to all interfaces of the source equipment and transmitting the broadcast messages to the whole network segment when the source equipment carries out a query request in a broadcast mode in the related technology are solved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a message processing method, device, storage medium and electronic device. Background Art

[0002] In modern network communications, especially in Ethernet environments, it is often necessary to perform some query tasks by broadcasting messages, for example, in scenarios where data packet-based transmission relies on the mapping relationship between Media Access Control (MAC) addresses and Internet Protocol (IP) addresses. In order to achieve this mapping, the Address Resolution Protocol (ARP) is widely used to resolve the IP address of the network layer into the MAC address of the data link layer. The working principle of ARP is that when a device (such as a source device) needs to know the MAC address of another device (such as a target device), if the latter's IP address at the network layer is known but its MAC address at the data link layer is unknown, the source device will send an ARP request message to all its interfaces, sending the ARP request message by broadcasting to inquire about the MAC address of the target device. The message will spread throughout the entire network segment - that is, flooding. This broadcast request will cause a large consumption of network resources under the original mechanism, especially in scenarios with high network density and a large number of devices, which may cause network congestion and excessive redundant data transmission. In addition, the transmission rate of broadcast messages in the air medium is usually low, and they will continue to occupy the air medium. Too many such messages will seriously interfere with the transmission of other messages in the air. Frequent broadcasts not only cause network congestion, but may also cause security risks, such as ARP spoofing attacks.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present invention provide a message processing method, device, storage medium and electronic device to at least solve the technical problem in the related art that when a source device makes a query request by broadcasting, it will send a broadcast message to all its interfaces and spread it throughout the entire network segment, causing network congestion and excessive redundant data transmission.

[0005] According to one aspect of an embodiment of the present invention, there is provided a message processing method, comprising: receiving a target request message sent by a source device via broadcast, wherein the target request message carries a query item for a target device; determining a request type of the target request message; based on the request type, determining a target processing mode for processing the target request message, wherein the target processing mode comprises continuing to forward the target request message or stopping forwarding the target request message.

[0006] Optionally, determining the request type of the target request message includes: obtaining a target IP address from the target request message, wherein the target IP address is the IP address of the target device; detecting whether the target IP address and the query result of the corresponding query item are in a target cache table to obtain a detection result, wherein the target cache table stores multiple IP addresses and the query results of the query items respectively corresponding to the multiple IP addresses; and determining the request type based on the detection result.

[0007] Optionally, determining the request type of the target request message includes: when the detection result indicates that the target IP address is in the target cache table, determining that the request type is a first type request message; or when the detection result indicates that the target IP address is not in the target cache table, determining that the request type is a second type request message.

[0008] Optionally, the target processing method for the target request message is determined based on the request type, including: when the request type is a first-class request message, determining the target processing method as: sending a reply message to the source device, wherein the reply message carries the target IP address and the target query result corresponding to the query item; or when the request type is a second-class request message, determining the target processing method as: continuing to forward the target request message.

[0009] Optionally, when the request type is a first type of message, the method further includes: querying the query result corresponding to the target IP address from the target cache table; and obtaining the target query result based on the query result corresponding to the target IP address.

[0010] Optionally, the method also includes: when the request type is a second-category request message, updating the cumulative number of messages sent by the source device within a predetermined time period, wherein the cumulative number of messages sent is used to indicate the total number of second-category request messages cumulatively sent by the source device via broadcasting within the predetermined time period; when the cumulative number of messages sent is greater than a preset first number, determining a restricted time period for message restriction on the source device; and within the restricted time period, discarding some of the second-category request messages cumulatively sent by the source device via broadcasting.

[0011] Optionally, the method also includes: when the cumulative number of messages sent is greater than a preset second number and less than the preset first number, storing the target IP address and the cumulative number of messages sent accordingly in the first client table; or when the cumulative number of messages sent is greater than the preset first number, storing the target IP address and the restricted time period accordingly in the second client table; when the restricted time period ends, removing the target IP address and the corresponding restricted time period from the second client table.

[0012] Optionally, the method also includes: when it is detected that the target cache table is updated, identifying first update information in the target cache table, wherein the first update information is the IP addresses newly added and / or removed from the target cache table, and the corresponding query results; transmitting the first update information to other proxy devices, wherein the other proxy devices are proxy devices other than the target proxy device in the communication network where the source device is located.

[0013] Optionally, the method also includes: receiving second update information sent by other proxy devices, wherein the second update information includes IP addresses that are newly added and / or removed from the cache table of the other proxy devices, and corresponding query results; based on the second update information, updating the target cache table, wherein the other proxy devices are proxy devices other than the target proxy device in the communication network where the source device is located.

[0014] Optionally, determining the target processing method for the target request message based on the request type includes: obtaining a device type of the source device; and determining the target processing method based on the request type and the device type.

[0015] Optionally, determining the target processing method based on the request type and the device type includes: when the device type is a client device, determining the target processing method based on the request type; or when the device type is a proxy device, determining the target processing method as: continuing to forward the target request message.

[0016] Optionally, the target request message is an ARP request message, and the query item is a MAC address of the target device.

[0017] According to another aspect of an embodiment of the present invention, a message processing device is also provided, including: a message receiving module, used to receive a target request message sent by a source device via broadcast, wherein the target request message carries a query item for a target device; a request type determination module, used to determine the request type of the target request message; a processing method determination module, used to determine a target processing method for processing the target request message based on the request type, wherein the target processing method includes continuing to forward the target request message or stopping forwarding the target request message.

[0018] According to another aspect of an embodiment of the present invention, a communication device is provided, wherein the communication device is used to execute any one of the message processing methods.

[0019] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, wherein the computer-readable storage medium includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the message processing methods.

[0020] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes any one of the message processing methods when running.

[0021] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps of any one of the message processing methods are implemented.

[0022] In an embodiment of the present invention, a target request message sent by a source device in a broadcasting manner is received, wherein the target request message carries a query item for a target device; a request type of the target request message is determined; based on the request type, a target processing method for processing the target request message is determined, wherein the target processing method includes continuing to forward the target request message or stopping forwarding the target request message, thereby achieving the purpose of identifying the request type of the request message, determining whether to continue forwarding the request message, and avoiding frequent forwarding of messages, thereby achieving the technical effect of alleviating network congestion when sending messages and avoiding excessive redundant data transmission, and further solving the technical problem in the related technology that when a source device makes a query request in a broadcasting manner, a broadcast message will be sent to all its interfaces and spread throughout the entire network segment, causing network congestion and excessive redundant data transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0024] Figure 1 It is a schematic diagram of a message processing method according to the prior art;

[0025] Figure 2 is a flow chart of a message processing method according to an embodiment of the present invention;

[0026] Figure 3 is a schematic diagram of an optional communication network framework according to an embodiment of the present invention;

[0027] Figure 4 is a flow chart of an optional message processing method according to an embodiment of the present invention;

[0028] Figure 5 It is a schematic diagram of a message processing device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] First, to facilitate understanding of the embodiments of the present invention, some terms or nouns involved in the present invention are explained below:

[0032] Media Access Control (MAC) address refers to the physical address used to uniquely identify a network device at the data link layer (the second layer of the Open Systems Interconnection (OSI) model). It is the hardware address of the device's Network Interface Controller (NIC), usually set by the manufacturer of the network device at the factory, and is theoretically unique worldwide. The MAC address is used for direct data transmission in a Local Area Network (LAN) environment. When a data packet is transmitted in a physical network, it is used to determine which specific network interface the data packet should be sent to.

[0033] Address Resolution Protocol (ARP) is a communication protocol in computer networks, which is used to resolve the IP address of the network layer into the physical address (usually MAC address) of the data link layer.

[0034] Aging time refers to the time after which an entry in the cache is considered outdated and can be replaced.

[0035] MAC address, literally translated as media access control address, is a unique network identifier burned into the network card by the network equipment manufacturer when it is produced. In the Open Systems Interconnection (OSI) model, the third layer, the network layer, is responsible for the IP address, and the second layer, the data link layer, is responsible for the MAC address.

[0036] User interface refers to the physical interface on a switch or router that is connected to the user client via wired or wireless means.

[0037] Main access point: an access point that plays a control and management role in the network, such as a cross-segment routing node that accesses the Internet in a Mesh network.

[0038] Domain Name System (DNS) query refers to the process in which a client sends a request to a DNS server to obtain the IP address corresponding to a specific domain name.

[0039] Dynamic Host Configuration Protocol (DHCP) request refers to the process in which the client sends a request to the DHCP server to obtain network configuration information such as IP address, subnet mask, default gateway, etc. The DHCP server usually assigns an available IP address to the client so that the client can successfully connect to the network.

[0040] In modern network communications, especially in Ethernet environments, it is usually necessary to perform some query tasks by broadcasting messages, for example, in scenarios where data packet-based transmission depends on the mapping relationship between MAC addresses and IP addresses. In order to achieve this mapping, ARP is widely used to resolve the IP address of the network layer to the MAC address of the data link layer. The working principle of ARP is that when a device (such as a source device) needs to know the MAC address of another device (such as a target device), if the latter's IP address at the network layer is known but its MAC address at the data link layer is unknown, the source device will send an ARP request message to all its interfaces, sending the ARP request message by broadcasting to inquire about the MAC address of the target device. Figure 1 It is a schematic diagram of a message processing method according to the prior art, such as Figure 1 As shown, a client device (such as Figure 1 A large number of ARP request messages are sent (upper left in the middle). The original mechanism will forward a large number of ARP broadcast packets. The number increases with the number of client devices. In extreme cases, the air channel is full and other wireless client devices cannot work properly. It can be seen that the request message sent based on the message sending method in the relevant technology will spread throughout the entire network segment, that is, flooding. This broadcast request will cause a large consumption of network resources under the original mechanism, especially in scenarios with high network density and a large number of devices. It may cause network congestion and excessive redundant data transmission. In addition, the transmission rate of broadcast messages in the air medium is usually low, and it will continue to occupy the air medium. Too many such messages will seriously interfere with the transmission of other messages in the air. Frequent broadcasts not only cause network congestion, but also may cause security risks, such as ARP spoofing attacks.

[0041] In order to solve the above problems, some solutions have been proposed in the relevant technologies, such as the Proxy Address Resolution Protocol (Proxy ARP) technology, which uses a specific device to act as a proxy. The proxy device will respond to the source device with "its own MAC and the IP address of the target device" (a kind of benign deception), and respond to the source device with a false (but legal) MAC address, so that it believes that the proxy device is the target device. The above method is usually used to achieve ARP communication across network segments and virtual local area networks (VLANs). However, although this technology can achieve communication across network segments or VLANs, it fails to fundamentally reduce the network burden caused by the broadcast of ARP request messages, and even in some cases it will increase additional communication traffic, because the source device will believe that the proxy device is the target device, and continue to send ARP request messages to the proxy device to maintain its neighbor table cache, further increasing the occupation of network resources.

[0042] In addition, as the complexity of network devices increases, the network may contain multiple types of devices, from traditional personal computers (PCs) and servers to Internet of Things (IoT) devices and dedicated devices for network management. Different device types have different requirements and communication modes for the network. How to intelligently process ARP requests according to device types and request types to avoid excessive consumption of network resources while ensuring network security and stability has become a technical problem that needs to be solved urgently.

[0043] In response to the above problems, an embodiment of the present invention provides a method embodiment of message processing. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0044] Figure 2 is a flow chart of a message processing method according to an embodiment of the present invention. Figure 2 As shown, the method comprises the following steps:

[0045] Step S102, receiving a target request message sent by a source device in a broadcasting manner, wherein the target request message carries a query item for a target device;

[0046] As an optional embodiment, the execution subject of the method of this embodiment can be a target proxy device in the communication network where the source device is located. The target proxy device can be a router or a gateway device with routing function. The target proxy device can be any proxy device in the communication network, can be a main access point in the communication network, or can be other nodes except the main access point. The source device can be a client device or a proxy device. The types of the above client devices can be various, for example, it can be a mobile terminal with certain computing capabilities, or a fixed computer device with identification capabilities, etc.

[0047] In step S102 of the present application, the target request message sent by the source device in a broadcast manner carries a query item for the target device, which can be used for network discovery or addressing, etc. The sending of the broadcast request message enables the source device to send a request to all devices in the network without knowing the exact location or status of the target device, thereby discovering and locating the target device. In addition, in large networks or high-density network environments, broadcast messages may cause network congestion, especially in wireless networks, where broadcast messages will occupy valuable wireless channel resources. The query items obtained can be used for subsequent analysis and to determine whether to continue forwarding the request message, which can reduce the number of forwarding broadcast messages, thereby alleviating network congestion and improving overall network performance.

[0048] In an optional embodiment, the target request message is an ARP request message, and the query item is a MAC address of the target device.

[0049] Optionally, by clarifying that the target request message is an ARP request message, the application scope of this embodiment is limited to communication scenarios in an Ethernet environment, especially network management related to MAC address and IP address mapping. When the query item is determined to be the MAC address of the target device and the corresponding target request message is an ARP request message, the target proxy device can identify and query the MAC address of the target device. Specifically, the ARP request message is usually used to query the MAC address of the target device for subsequent data packet transmission. By directly processing the ARP request and providing the MAC address of the target device as the query result, network congestion caused by broadcast queries can be avoided to reduce unnecessary network communications and improve network communication and transmission efficiency. By optimizing the processing of ARP request messages, network resources, including bandwidth and processing power, can be effectively saved. Avoiding network-wide broadcasts and reducing redundant data packet transmissions allows network resources to be more efficiently utilized for other network communication needs. In addition, processing ARP request messages and providing the MAC address of the target device is the basis for ensuring connectivity between network devices. By applying the method of this embodiment to the scenario of sending ARP requests by broadcasting and querying the MAC address of the target device, it helps to quickly establish and maintain the adjacency relationship between devices in the communication network, ensuring that data packets can be accurately sent from the source device to the target device.

[0050] Step S104, determining the request type of the target request message;

[0051] In step S104 of the present application, determining the request type of the target request message is the first step for the network device to make intelligent decisions. Different request types may require different processing methods, such as ARP requests, domain name system (DNS Query, DNS) queries, Dynamic Host Configuration Protocol (Dynamic Host Configuration Protoco, DHCP) requests, etc., all of which have their own specific processing procedures and response mechanisms. By identifying the message type, the target proxy device can call the corresponding processing strategy to avoid using a general or mismatched response method, thereby improving processing efficiency and accuracy. In addition, since network resources (such as bandwidth and processing power) are limited, correctly identifying the message type helps to optimize resource allocation. For example, for ARP requests, if the MAC address of the target device is already in the local cache, then responding directly in unicast mode can avoid unnecessary broadcasts and save bandwidth resources; for DNS queries, if there are records in the local DNS cache, they can also be returned directly, thereby reducing requests to external DNS servers and reducing network burden.

[0052] In an optional embodiment, determining the request type of a target request message includes: obtaining a target IP address from the target request message, wherein the target IP address is the IP address of a target device; detecting whether the target IP address and a query result of a corresponding query item are in a target cache table to obtain a detection result, wherein the target cache table stores multiple IP addresses and query results of query items corresponding to the multiple IP addresses; and determining the request type based on the detection result.

[0053] Optionally, by obtaining the target IP address from the target request message, the target proxy device can quickly locate the requested target, especially for ARP requests. This step can help the target proxy device quickly find the MAC address information of the target device, thereby speeding up the response speed and improving network efficiency. By detecting whether the target IP address exists in the target cache table, the cache table stores the previously requested information, such as the correspondence between the IP address and the query result (such as the MAC address, or the DNS query result). If the target IP address is in the cache table, it means that the target proxy device can immediately find the relevant information without broadcasting or querying again, thereby saving network resources and processing time. If the target IP address is in the cache table, the target proxy device can be sure that it can directly respond to the request without broadcasting. The above method can not only reduce the number of broadcast messages and avoid the generation of broadcast storms, but also reduce redundant traffic in the communication network, reduce delays and network congestion, and improve bandwidth utilization.

[0054] Optionally, the multiple IP addresses stored in the target cache table may include IP addresses corresponding to multiple client devices, and other proxy devices except the target proxy device; or may include both IP addresses corresponding to multiple client devices and IP addresses corresponding to all proxy devices in the communication network where the source device is located. That is, the IP address held by the target proxy device itself may be stored in the target cache table, or may be stored independently outside the target cache table.

[0055] Optionally, in a scenario where an ARP request is sent by broadcasting to query the MAC address of the target device, the target cache table may be an ARP cache table, and the corresponding query result may be a MAC address. The ARP cache table is used to store multiple IP addresses and MAC addresses corresponding to the multiple IP addresses.

[0056] In an optional embodiment, determining the request type of the target request message includes: when the detection result indicates that the target IP address is in the target cache table, determining the request type is a first type request message; or when the detection result indicates that the target IP address is not in the target cache table, determining the request type is a second type request message.

[0057] Optionally, by classifying the request message into the first type of request message and the second type of request message according to the detection result, the target proxy device is allowed to adopt different processing strategies according to the cache status. For the first type of request message, since the target IP address already exists in the target cache table, the corresponding query result (such as MAC address) can be directly obtained from the cache table, so as to respond to the request in a fast and efficient unicast manner, avoiding the waste of broadcast resources. For the second type of request message, since the target IP address is not in the target cache table, it is necessary to further search through broadcast or other methods. This differentiated processing helps to optimize the use of network resources. In the above method, the processing speed of the first type of request message is faster, because the information can be read directly from the cache without broadcasting query in the network, which can not only speed up network communication, but also improve the perception speed of the user end and enhance the overall network performance; by identifying and quickly responding to the first type of request message, the number of broadcast messages can be effectively reduced, especially in a high-density network environment, avoiding the generation of broadcast storms, and maintaining the stability and efficiency of the network. By classifying the request message into the first type of request message and the second type of request message, the devices in the communication network can better adapt to these changes and ensure the scalability and flexibility of the network.

[0058] Optionally, in the scenario where an ARP request is sent by broadcasting to query the MAC address of the target device, the second type of request message can be understood as an unknown ARP request message, that is, if the IP address requested by the ARP request broadcast packet (i.e., ARP request message) of a node (i.e., a proxy device) is neither the IP address held by the node itself nor the corresponding entry can be found in the ARP cache table of this node, then this ARP request message is called an unknown ARP request for the node. The first type of request message can be understood as other ARP messages other than unknown ARP request messages, for example, request messages that can be found in the ARP cache table. It should be noted that in the original mechanism of sending an ARP request by broadcasting to query the MAC address of the target device, the proxy device will forward any ARP request received. This embodiment can effectively reduce the number of broadcast messages by clearly distinguishing between two different types of request types and the corresponding message processing methods, especially in a high-density network environment, to avoid the generation of broadcast storms and maintain the stability and efficiency of the network.

[0059] Step S106, based on the request type, determining a target processing mode for processing the target request message, wherein the target processing mode includes continuing to forward the target request message or stopping to forward the target request message.

[0060] In step S106 of the present application, by adopting different processing methods for different types of request messages, the target proxy device can intelligently manage network traffic and improve network efficiency. For example, for ARP requests, if the MAC address of the target device is already in the local ARP cache table of the target proxy device, the target proxy device can choose to respond directly instead of broadcast forwarding; for DNS queries, if there are results in the local DNS cache table, they can also be returned directly, thereby avoiding additional queries to the DNS server. In a local area network, if broadcast messages are blindly forwarded, broadcast storms will occur, that is, a large number of broadcast messages are transmitted in the network at the same time, seriously consuming network resources and even paralyzing the network. By deciding whether to continue forwarding according to the request type, the propagation of broadcast messages can be effectively reduced, the generation of broadcast storms can be prevented, and the stability and efficiency of the network can be maintained. In addition, since network resources are limited, including bandwidth, processing power, and storage space, etc. Determining the processing method based on the request type can optimize the allocation of resources, ensure that key messages or services are given priority, and non-critical or repeated requests are reasonably controlled to avoid waste of resources. After classifying the request type, the target proxy device can quickly locate the corresponding processing flow, such as searching for response information from the local cache, or directly forwarding the request message to the next-hop device that can handle it, thereby reducing latency and improving the network's response speed.

[0061] In an optional embodiment, based on the request type, a target processing method for processing the target request message is determined, including: when the request type is a first-class request message, the target processing method is determined as: sending a reply message to the source device, wherein the reply message carries the target IP address and the target query result corresponding to the query item; or when the request type is a second-class request message, the target processing method is determined as: continuing to forward the target request message.

[0062] Optionally, the direct response strategy for the first type of request message can quickly and accurately send a reply message to the source device, including the target IP address and the target query result corresponding to the query item. This means that if the requested target information exists in the cache of the target proxy device, this information will be used directly to respond without further broadcasting the query, thereby improving the accuracy and speed of the response. For the second type of request message, the request message will continue to be forwarded, aiming to find other network devices or systems that can provide the target query result. This strategy can not only maintain the connectivity and information sharing capabilities of the network, but also ensure that even if the required information is not in the local cache, it can be obtained through the network. This distinction in processing methods helps to efficiently utilize network resources. The direct response to the first type of request message can reduce the waste of resources caused by broadcasting, while the continued forwarding of the second type of request message occurs only when necessary, thereby ensuring the on-demand allocation of resources and avoiding a large number of redundant link forwardings that continue to occupy too many network resources and cause network congestion.

[0063] Optionally, in the scenario where an ARP request is sent by broadcasting to query the MAC address of the target device, if the target request message is a first-class request message (i.e., a known ARP message), the target proxy device can construct a reply message including the MAC and IP addresses of the target device and feed it back to the source device instead of forwarding the request message. The above method can allow the source device to obtain the correct routing entry while avoiding a large number of redundant link forwardings that continue to occupy too many network resources. The ARP request message only passes through a link between the source device and the proxy device, thereby fully reducing the ARP broadcast message transmission pressure that increases with the number of client devices in the intranet.

[0064] In an optional embodiment, when the request type is a first type of message, the method further includes: querying a query result corresponding to the target IP address from the target cache table; and obtaining a target query result based on the query result corresponding to the target IP address.

[0065] Optionally, by directly querying the query result corresponding to the target IP address from the target cache table, the network device can quickly locate the required information, thereby avoiding the extra time required to broadcast or send the query message again, thereby significantly speeding up the response speed and reducing network latency. Directly querying the cache table and returning the result can also avoid unnecessary network broadcasts or forwarding, reduce redundant traffic in the network, optimize the use of network bandwidth, and also reduce the processing burden of network devices and save computing resources. The target cache table stores the previously successful query results, so the query results extracted from the target cache table are usually the latest and most accurate. This ensures that the information carried in the reply message is the most reliable information currently required by the source device, improving the stability of the network and the reliability of the service. The above method can avoid broadcasting the request message to the entire network, reduce the opportunity for information exposure to unauthorized devices or potential attackers, and enhance the security of the network. At the same time, the target cache table can also be designed with security mechanisms such as access control and data encryption to further protect the query results from malicious access. The query mechanism of the cache table can simplify the management of the first type of request messages, avoid frequent broadcast or query operations, reduce the complexity of monitoring and management of network performance, and also reduce the dependence on network device configuration, making network management more efficient.

[0066] In an optional embodiment, the method also includes: when the request type is a second-category request message, updating the cumulative number of messages sent by the source device within a predetermined time period, wherein the cumulative number of messages sent is used to indicate the total number of second-category request messages cumulatively sent by the source device through broadcasting within the predetermined time period; when the cumulative number of messages sent is greater than a preset first number, determining a restricted time period for message restriction on the source device; within the restricted time period, discarding some of the second-category request messages cumulatively sent by the source device through broadcasting.

[0067] Optionally, the predetermined period is a period of predetermined length before the target message is sent. The limited period can be measured by an aging time indicator, which is used to indicate the time when an entry in the cache is considered outdated and can be replaced.

[0068] Optionally, for a source device that sends too many second-class request messages within a period of time, a limited period of message restriction can be set for it, and the request messages sent by the source device within the limited period will not be forwarded. For example, if the source device sends more than 20 unknown ARP request messages within one second, a certain proportion of the part of the queue that exceeds the starting number (such as 20) will not be forwarded (such as 80%) and will be directly discarded.

[0069] In the above manner, by monitoring and limiting the number of second-class request messages sent by the source device within a predetermined period of time, the target proxy device can effectively prevent the generation of broadcast storms. Broadcast storms are caused by a large number of broadcast messages being repeatedly transmitted in the local area network, resulting in a large amount of network bandwidth being occupied, affecting normal communication. Implementing message restrictions can avoid excessive consumption of network resources and maintain network stability and efficiency. The second-class request message needs to find the target device through broadcasting, which will occupy network resources. By limiting the number of broadcast requests from the source device within a specific time window, network resources can be reasonably allocated, ensuring the priority of other network services and message transmission, and improving overall network performance. An abnormally high frequency of broadcast request message transmission may indicate that the source device may have been attacked or there is malicious behavior. By monitoring the cumulative number of transmissions and setting limits, the network device can identify potential security threats in a timely manner, and prevent the further spread of attacks by limiting message transmission, thereby enhancing network security. In addition, the network device will consume its computing resources when processing a large number of broadcast requests. Implementing a message restriction strategy can reduce the processing burden of the device, avoid response delays or service interruptions caused by resource overload, and ensure the stable operation of devices in the communication network. In addition, by setting a predetermined time period and a preset first number to control the density of broadcast traffic in the network, the management of broadcast messages can be simplified, thereby more finely controlling network resources, responding to abnormal traffic in the network, and improving the efficiency of network management.

[0070] As an optional embodiment, determining a restricted time period for message restriction on a source device includes: determining a duration for message restriction on the source device based on the cumulative number of messages sent by the source device within a predetermined time period, and determining a restricted time period for message restriction on the source device based on the restricted duration. That is, based on the cumulative number of messages sent by the source device within a predetermined time period, an aging time corresponding to the original device is determined. The above method can dynamically determine the restricted time period based on the cumulative number of messages sent by the source device. For example, for source devices with a large cumulative number of messages sent, a longer restricted time period is set; for source devices with a small cumulative number of messages sent, a shorter restricted time period can be set, thereby achieving flexible setting of the restricted time period and improving the flexibility of message restriction.

[0071] In an optional embodiment, the method also includes: when the cumulative number of messages sent is greater than a preset second number and less than a preset first number, the target IP address and the cumulative number of messages sent are stored in the first client table accordingly; or when the cumulative number of messages sent is greater than the preset first number, the target IP address and the restricted time period are stored in the second client table accordingly.

[0072] Optionally, when the cumulative number of sent messages is between the preset second number and the preset first number, it is recorded in the first client table, which can be used to detect early signs of abnormal behavior. For example, a client suddenly starts to send a large number of ARP requests for unknown IPs, which may be due to configuration errors, software failures or attacks. As an early warning system, the first client table can help network administrators discover and respond to these abnormal behaviors in a timely manner. When the cumulative number of sent messages exceeds the preset first number, the source device will be marked as an object to be restricted, and its information will be stored in the second client table. The network device will discard some of the second type of request messages from the source device within the restricted period, thereby protecting network resources from excessive consumption, avoiding network congestion, and ensuring network stability and response time. By setting two different thresholds (the preset second number and the preset first number), different levels of flow control can be implemented. The lower threshold is used for early warning and slight flow restrictions, while the higher threshold is used for stricter control. The above method can effectively balance the relationship between network monitoring and resource utilization, and by limiting the message sending of abnormal client devices, reduce noise traffic in the network, and improve the performance of the overall network, thereby improving the network experience of all users.

[0073] Optionally, in the scenario of sending ARP requests by broadcasting and querying the MAC address of the target device, the client device that sends too many unknown ARP request messages is marked, and a client table is maintained to record the MAC address and the number of times the client device that sends the unknown ARP request is sent, wherein the abnormal client table is used to record the MAC address and the number of times the client device that sends the unknown ARP request is sent; a suspicious client table is maintained to record the MAC address and aging time of the client device that counts too much in the client table, and for suspicious clients, their more unknown ARP requests will be ignored, wherein the suspicious client table records the MAC address and aging time of the client that counts too much in the client table, for example, if a client device sends 100 unknown ARP requests in one second, it will undoubtedly be recorded as an entry in the suspicious client table. For suspicious client devices, their more unknown ARP requests will be ignored, for example, assuming that a client device that has been marked as suspicious sends more than 20 unknown ARP request messages in one second, a certain proportion of the part of the queue that exceeds the starting number (such as 20) will not be forwarded (such as 80%).

[0074] In an optional embodiment, the method further includes: when the restriction period ends, removing the target IP address and the corresponding restriction period from the second client table.

[0075] Optionally, the setting of the restriction period is a temporary measure to cope with sudden high broadcast traffic in the network and prevent broadcast storms or excessive resource consumption. When the restriction period ends, the target IP address and the corresponding restriction period are removed from the second client table, which means that the target proxy device will no longer impose additional restrictions on the specific requests of these clients, thereby restoring the normal service of the client device and ensuring the flexibility and accessibility of the communication network. The cleanup operation after the restriction period ends can reflect that the target proxy device can automatically adjust the resource allocation strategy according to the real-time network status, avoid the impact of long-term restrictions on normal network communication, and maintain the rationality and efficiency of resource allocation. In addition, storing unnecessary restriction information for a long time will occupy the storage resources of the network device and affect the operating efficiency of the proxy device. Regularly cleaning up the restriction information that is no longer needed can free up storage space, optimize the resource management of the device, reduce the storage burden, and improve the processing capacity and response speed of the proxy device. The setting of the restriction period temporarily adjusts the use of network resources to cope with abnormal traffic. The cleanup operation can ensure that the restriction will not be continued indefinitely, avoid unfair treatment of specific users or devices, and maintain the fairness of the network environment.

[0076] In an optional embodiment, the method further includes: upon detecting that an update to the target cache table occurs, identifying first update information in the target cache table, wherein the first update information is an IP address that is newly added and / or removed from the target cache table, and a corresponding query result; transmitting the first update information to other proxy devices, wherein the other proxy devices are proxy devices other than the target proxy device in the communication network where the source device is located.

[0077] Optionally, when an IP address and its corresponding query result are added or deleted from the target cache table, the proxy device will identify these first update information and transmit them to other proxy devices in the same communication network to ensure that the cache tables of all proxy devices are consistent. By synchronizing cache update information between proxy devices, the frequency of source devices sending broadcast queries (such as ARP broadcast queries) can be reduced. For example, when a source device needs to query the MAC address corresponding to a certain IP address, it can directly search from the local ARP cache table, thereby providing the latest and most accurate information without broadcasting queries across the entire network, thereby reducing network bandwidth usage and improving response speed. Update information shared between proxy devices can reduce repeated queries, avoid redundant traffic in the network, and ensure the effective use of network resources. Automatic identification and dissemination of cache table update information can also reduce the burden on network administrators, without the need to manually update or verify the cache information of each proxy device. This makes network management more automated, thereby improving management efficiency and network maintainability.

[0078] Optionally, in the scenario where an ARP request is sent by broadcasting to query the MAC address of the target device, the proxy device that actively performs the synchronization task (such as the target proxy device, which can be a node connected to the Internet) will regularly check its own ARP cache table at a certain period (for example, 30 seconds), remove duplicates, sort and then record. If it is not completely consistent with the last record, all the entries after deduplication and sorting can be transmitted to other proxy devices in the same subnet at one time as the first update information. Each entry carries an add / delete mark to notify other proxy devices to add or delete related entries, where an IP address and its corresponding query result (such as a MAC address) are regarded as an entry. After a long period of time (for example, 8 minutes) without synchronization, an unconditional synchronization can be performed. After receiving the first update information, the proxy device that is executed with the synchronization task will check the add / delete mark and IP of each entry in turn to decide whether to add / update the entry or delete the entry. For newly added / updated synchronized entries, the entry reachability will not be actively verified for a period of time (for example, 10 minutes). This time is higher than the maximum unsynchronized time of the proxy device that performs the synchronization task. This mechanism can ensure that the synchronized entries will not introduce ARP request packets to maintain the entry cache during their continued existence and when they are notified of additions and deletions.

[0079] In an optional embodiment, the method further includes: receiving second update information sent by other proxy devices, wherein the second update information includes IP addresses that are newly added and / or removed from the cache table of the other proxy devices, and corresponding query results; based on the second update information, updating the target cache table, wherein the other proxy devices are proxy devices other than the target proxy device in the communication network where the source device is located.

[0080] Optionally, by receiving and integrating cache update information from other proxy devices, the target proxy device can ensure the global consistency of its cache table. This means that all proxy devices have the same understanding of the mapping between query results (such as MAC addresses) and IP addresses in the network, thereby preventing routing errors or packet loss caused by inconsistent cache information, thereby enhancing the stability of the network. The cache update mechanism between proxy devices can significantly reduce the number of ARP queries. Once the cache of a proxy device is updated, it will send the update information to other proxy devices, so that when other proxy devices receive the same ARP request, they can directly obtain information from the updated local cache table without broadcasting the query again, thereby saving network bandwidth and improving network efficiency. When the query results (such as MAC addresses) corresponding to the IP addresses in the corresponding cache tables of other proxy devices change, all proxy devices can adjust the cache information in time through the propagation of the second update information to avoid communication based on erroneous or outdated information. This helps to defend against security threats such as ARP spoofing and protect the integrity and reliability of network communications. In addition, the cache update mechanism can reduce repeated ARP broadcasts in the network, reduce the traffic of the entire network, and avoid the need for each proxy device to independently maintain a complete and up-to-date cache table, saving storage resources and computing resources, and achieving efficient use of network resources.

[0081] In an optional embodiment, based on the request type, determining a target processing method for processing the target request message includes: obtaining a device type of the source device; and determining the target processing method based on the request type and the device type.

[0082] Optionally, by obtaining the device type of the source device, the network device can more accurately understand the source and nature of the request. The device type can be divided based on the client device and the proxy device. For example, by querying the user's interface, it is determined whether the source device is a client device or a proxy device. Based on the request type and device type, the target proxy device can customize the target processing method. By identifying the device type, the network device can allocate resources more intelligently and prioritize requests from key devices, thereby improving the overall efficiency and response speed of the network.

[0083] In an optional embodiment, the target processing method is determined based on the request type and the device type, including: when the device type is a client device, the target processing method is determined based on the request type; or when the device type is a proxy device, the target processing method is determined as: continue to forward the target request message.

[0084] Optionally, when the source device is identified as a client device, the target proxy device determines the best processing method according to the specific type of the request (known ARP request or unknown ARP request). For known ARP requests issued by client devices, the target proxy device may directly perform proxy responses to avoid broadcasting; for unknown ARP requests, the suspicious marking function may be applied to reduce potential network resource consumption. This helps to improve the network access efficiency and response speed of client devices, and also reduces the burden of network broadcasting. If the source device is identified as a proxy device, the target proxy device will determine the target processing method to continue forwarding the target request message. Proxy devices usually play the role of forwarding and management in the network, so ensuring that their requests are forwarded normally is crucial to maintaining the normal operation of the network. This processing method can ensure that the requests of the proxy device can be correctly processed by other network nodes and maintain the connectivity and stability of the network. Determining the processing method based on the device type and the request type can dynamically allocate and optimize resources. The requests of client devices may focus more on efficiency and speed, while the requests of proxy devices need to ensure their integrity and accessibility. This dynamic adjustment helps to efficiently utilize network resources, avoid resource waste, and improve the overall performance of the network.

[0085] Through the above steps S102 to S106, the purpose of identifying the request type of the request message and determining whether to continue forwarding the request message can be achieved to avoid frequent forwarding of the message, thereby achieving the technical effect of alleviating network congestion when sending messages and avoiding excessive redundant data transmission, and further solving the technical problem in the related technology that when the source device makes a query request by broadcasting, it will send a broadcast message to all its interfaces and spread it throughout the entire network segment, causing network congestion and excessive redundant data transmission.

[0086] Based on the above embodiments and optional embodiments, the present invention proposes an optional implementation mode: Figure 3 is a schematic diagram of an optional communication network framework according to an embodiment of the present invention, Figure 4 is a flowchart of an optional message processing method according to an embodiment of the present invention, which can be applied to Figure 3 In the communication network framework shown in the figure, the source device is connected to the proxy device (ie, the routing engine (RE)), and the proxy device is used as the execution subject to execute Figure 4 The message processing method shown includes:

[0087] S1, the proxy device of the intranet receives the ARP request message sent by the source device through broadcasting, and detects whether the interface corresponding to the ARP request comes from the client device interface. If so, step S2 is executed, otherwise, the ARP request message is forwarded continuously;

[0088] S2, detecting whether the ARP request message is used to query the IP address corresponding to the main access point in the communication network, if so, continue to forward the ARP request message, otherwise, execute step S3;

[0089] S3, detect whether the ARP request message is used to query the IP address of the proxy device itself, or to query the IP address in the ARP cache table; if it indicates that the ARP request message is a known ARP request message, set a proxy tag for the ARP request message and execute step S4; otherwise, it indicates that the ARP request message is an unknown ARP request message, and execute step S5.

[0090] S4, in order to protect network resources, for known ARP request messages, the proxy reply will be directly constructed with the IP and MAC information of the target device, instead of forwarding the request, to prevent frequent ARP requests between client devices from continuously occupying too many network resources;

[0091] S5, marking the client device that sends too many unknown ARP request packets, maintaining a client table, recording the MAC address of the client device that sends the unknown ARP request and the number of times it sends, wherein the abnormal client table is used to record the MAC address of the client device that sends the unknown ARP request and the number of times it sends;

[0092] S6, by maintaining the client table, setting a corresponding discarding policy to determine whether to continue forwarding the ARP request message or directly discard the message, specifically:

[0093] S61, maintain a suspicious client table, record the MAC addresses and aging time of client devices that are counted too much in the client table, and ignore the large number of unknown ARP requests of suspicious client devices. The suspicious client table records the MAC addresses and aging time of clients that are counted too much in the client table. For example, if a client device sends 100 unknown ARP requests in one second, it will undoubtedly be recorded as an entry in the suspicious client table.

[0094] S62, for suspicious client devices, their larger number of unknown ARP requests will be ignored. For example, assuming that a client device that has been marked as suspicious sends more than 20 unknown ARP request messages within one second, a certain proportion (such as 80%) of the part of the queue that exceeds the starting number (such as 20) will not be forwarded.

[0095] S63, if there are multiple nodes (i.e., multiple proxy devices) in the broadcast domain, then the ARP cache table can be synchronized between the nodes according to a certain strategy. This solves the problem that when a device needs to know the MAC address of another device, it will send an ARP request to all its interfaces by broadcasting, resulting in network congestion and excessive redundant data transmission. Specifically, it includes:

[0096] In a communication network, a proxy device that actively performs synchronization tasks (e.g., a node connected to the Internet) will regularly check its own ARP cache table at a certain period (e.g., 30 seconds), remove duplicates, sort, and then record. If it is not completely consistent with the last record, all the entries after removal and sorting will be transmitted to other nodes (i.e., other proxy devices) in the same subnet at one time. Each entry carries an add / delete mark to notify other nodes to add or delete related entries. After a long period of non-synchronization (e.g., 8 minutes), an unconditional synchronization can be performed.

[0097] After receiving the first update information, the proxy device that is executed with the synchronization task will check the add / delete mark and IP of each entry in turn to decide whether to add / update or delete the entry. For newly added / updated synchronized entries, the accessibility of the entry will not be actively verified for a period of time (for example, 10 minutes), which is higher than the maximum unsynchronized time of the proxy device that executes the synchronization task. This mechanism can ensure that the synchronized entries will not introduce ARP request packets to maintain the entry cache during their continued existence and when they are notified of additions and deletions.

[0098] It should be noted that there are a large number of ARP requests in the intranet. For known ARP requests, this embodiment can directly give unicast replies on the proxy device without broadcasting throughout the intranet, reducing the occupancy of the channel medium and allowing client devices in the communication network (such as wireless IoT devices) to work better. In the related technology, a client device sends a large number of ARP request packets, and the original mechanism will forward a large number of ARP broadcast packets. The number increases with the number of clients. In extreme cases, the air channel is full and other wireless clients cannot work normally. Based on the solution of this embodiment, known ARP requests are directly replied without broadcasting throughout the intranet, and unknown ARP requests enter the suspicious judgment mechanism (such as Figure 3 Other wireless clients can work normally; when a suspicious message source suddenly sends a large number of ARP requests, it can be marked and then the sudden resource consumption can be greatly reduced by appropriately discarding the ARP requests of unknown IPs; on wired and wireless links, the risk of network congestion caused by unknown / redundant / surging ARP requests is greatly reduced.

[0099] In this embodiment, a communication device is also provided, characterized in that the communication device is used to execute any one of the above-mentioned message processing methods.

[0100] Optionally, the communication device may be any proxy device in the communication network, and the proxy device may be a router or a gateway device with a routing function.

[0101] In this embodiment, a message processing device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the terms "module" and "device" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0102] According to an embodiment of the present invention, a device embodiment for implementing the above-mentioned message processing method is also provided. Figure 5 is a structural diagram of a message processing device according to an embodiment of the present invention. Figure 5 As shown, the message processing device includes: a message receiving module 500, a request type determination module 502, and a processing method determination module 504, wherein:

[0103] The message receiving module 500 is used to receive a target request message sent by a source device in a broadcasting manner, wherein the target request message carries a query item for a destination device;

[0104] A request type determination module 502, connected to the message receiving module 500, for determining the request type of the target request message;

[0105] The processing mode determination module 504 is connected to the request type determination module 502, and is used to determine the target processing mode for processing the target request message based on the request type, wherein the target processing mode includes continuing to forward the target request message or stopping forwarding the target request message.

[0106] In an embodiment of the present invention, a message receiving module 500 is provided to receive a target request message sent by a source device in a broadcasting manner, wherein the target request message carries a query item for a destination device; a request type determination module 502 is connected to the message receiving module 500 and is used to determine the request type of the target request message; a processing method determination module 504 is connected to the request type determination module 502 and is used to determine a target processing method for processing the target request message based on the request type, wherein the target processing method includes continuing to forward the target request message or stopping forwarding the target request message. This can achieve the purpose of identifying the request type of the request message, determining whether to continue forwarding the request message, and avoiding frequent forwarding of messages, thereby achieving the technical effect of alleviating network congestion when sending messages and avoiding excessive redundant data transmission, thereby solving the technical problem in the related technology that when a source device makes a query request in a broadcasting manner, a broadcast message will be sent to all its interfaces and spread throughout the entire network segment, resulting in network congestion and excessive redundant data transmission.

[0107] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0108] It should be noted that the message receiving module 500, the request type determination module 502, and the processing mode determination module 504 correspond to steps S102 to S106 in the embodiment, and the examples and application scenarios implemented by the modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. It should be noted that the modules as part of the device can be run in a computer terminal.

[0109] It should be noted that the optional or preferred implementation of this embodiment can refer to the relevant description in the embodiment, which will not be repeated here.

[0110] The above-mentioned message processing device may also include a processor and a memory. The above-mentioned message receiving module 500, request type determination module 502, processing method determination module 504, etc. are all stored in the memory as program modules, and the processor executes the above-mentioned program modules stored in the memory to realize corresponding functions.

[0111] According to an embodiment of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned message processing methods.

[0112] According to an embodiment of the present invention, an electronic device is provided, comprising: a memory storing an executable program; and a processor for running the program, wherein when the program is run, any one of the above-mentioned message processing methods is executed.

[0113] According to an embodiment of the present invention, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps of any one of the above-mentioned message processing methods are implemented.

[0114] The above sequence of the embodiments of the present invention is for description only and does not represent the superiority or inferiority of the embodiments.

[0115] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the above modules can be a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, modules or indirect coupling or communication connection of modules, which can be electrical or other forms.

[0117] The modules described above as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple modules. Some or all of the modules may be selected according to actual needs to achieve the objectives of the present embodiment.

[0118] In addition, each functional module in each embodiment of the present invention may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of software functional modules.

[0119] If the above-mentioned integrated module is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a non-volatile storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the various embodiments of the present invention. The aforementioned non-volatile storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0120] The above are only preferred embodiments of the present invention. It should be pointed out that, for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A message processing method, characterized in that: include: Receiving a target request message sent by a source device in a broadcasting manner, wherein the target request message carries a query item for a target device; Determining a request type of the target request message; Based on the request type, a target processing mode for processing the target request message is determined, wherein the target processing mode includes continuing to forward the target request message or stopping forwarding the target request message.

2. The method according to claim 1, characterized in that The determining the request type of the target request message includes: Acquire a target IP address from the target request message, wherein the target IP address is the IP address of the target device; Detecting whether the target IP address and the query result corresponding to the query item are in the target cache table to obtain a detection result, wherein the target cache table stores multiple IP addresses and the query results of the query items corresponding to the multiple IP addresses respectively; Based on the detection result, the request type is determined.

3. The method according to claim 2, characterized in that The determining the request type of the target request message includes: If the detection result indicates that the target IP address is in the target cache table, determining that the request type is a first type request message; or When the detection result indicates that the target IP address is not in the target cache table, it is determined that the request type is a second type request message.

4. The method according to claim 3, characterized in that The determining, based on the request type, a target processing mode for processing the target request message includes: In the case where the request type is a first type request message, determining the target processing mode is: sending a reply message to the source device, wherein the reply message carries the target IP address and the target query result corresponding to the query item; or When the request type is a second type request message, the target processing mode is determined as: continue to forward the target request message.

5. The method according to claim 3, characterized in that: The method further comprises: In the case where the request type is a second-type request message, updating the cumulative number of messages sent by the source device within a predetermined period of time, wherein the cumulative number of messages sent is used to indicate the total number of second-type request messages cumulatively sent by the source device by broadcasting within the predetermined period of time; When the cumulative number of sent messages is greater than a preset first number, determining a restriction period for performing message restriction on the source device; Within the limited time period, some request messages of the second type of request messages accumulatively sent by the source device in a broadcasting manner are discarded.

6. The method according to claim 5, characterized in that The method further comprises: When the cumulative number of sent messages is greater than the preset second number and less than the preset first number, the target IP address and the cumulative number of sent messages are correspondingly stored in the first client table; or When the cumulative number of sent messages is greater than the preset first number, the target IP address and the restricted time period are stored in the second client table accordingly; When the restriction period ends, the target IP address and the corresponding restriction period are removed from the second client table.

7. The method according to claim 2, characterized in that The method further comprises: In the case where it is detected that the target cache table is updated, identifying first update information in the target cache table, wherein the first update information is an IP address that is newly added and / or removed from the target cache table, and a corresponding query result; The first update information is transmitted to other proxy devices, wherein the other proxy devices are proxy devices other than the target proxy device in the communication network where the source device is located.

8. The method according to claim 2, characterized in that: The method further comprises: Receiving second update information sent by other proxy devices, wherein the second update information includes IP addresses that are newly added and / or removed from the cache table of the other proxy devices, and corresponding query results; Based on the second update information, the target cache table is updated, wherein the other proxy devices are proxy devices other than the target proxy device in the communication network where the source device is located.

9. The method according to claim 1, characterized in that: The determining, based on the request type, a target processing mode for processing the target request message includes: Obtaining a device type of the source device; The target processing mode is determined based on the request type and the device type.

10. The method according to claim 9, characterized in that The determining the target processing mode based on the request type and the device type includes: In the case where the device type is a client device, determining the target processing mode based on the request type; or In the case where the device type is a proxy device, the target processing mode is determined as: continuing to forward the target request message.

11. The method according to any one of claims 1 to 10, characterized in that The target request message is an ARP request message, and the query item is the MAC address of the target device.

12. A message processing device, characterized in that: include: A message receiving module, configured to receive a target request message sent by a source device in a broadcasting manner, wherein the target request message carries a query item for a target device; A request type determination module, used to determine the request type of the target request message; A processing mode determination module is used to determine a target processing mode for processing the target request message based on the request type, wherein the target processing mode includes continuing to forward the target request message or stopping forwarding the target request message.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the computer-readable storage medium is located is controlled to execute the message processing method according to any one of claims 1 to 11.

14. An electronic device, characterized in that: include: A memory storing an executable program; A processor is used to run the program, wherein the program executes the message processing method described in any one of claims 1 to 11 when running.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the message processing method according to any one of claims 1 to 11 are implemented.

Images