CN114466075A - Request processing method and device, electronic equipment and storage medium - Google Patents
Request processing method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN114466075A CN114466075A CN202210044412.XA CN202210044412A CN114466075A CN 114466075 A CN114466075 A CN 114466075A CN 202210044412 A CN202210044412 A CN 202210044412A CN 114466075 A CN114466075 A CN 114466075A
- Authority
- CN
- China
- Prior art keywords
- request message
- characteristic
- target data
- feature
- response
- 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.)
- Granted
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 18
- 230000004044 response Effects 0.000 claims abstract description 91
- 238000012545 processing Methods 0.000 claims description 60
- 238000000034 method Methods 0.000 claims description 50
- 230000008569 process Effects 0.000 claims description 17
- 238000004458 analytical method Methods 0.000 claims description 8
- 238000012795 verification Methods 0.000 description 9
- 230000000903 blocking effect Effects 0.000 description 7
- 238000001914 filtration Methods 0.000 description 5
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000012216 screening Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000004630 mental health Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0277—Online advertisement
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Accounting & Taxation (AREA)
- Development Economics (AREA)
- Strategic Management (AREA)
- Game Theory and Decision Science (AREA)
- Computer Security & Cryptography (AREA)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Marketing (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The disclosed embodiment relates to a request processing method and device, an electronic device and a storage medium, wherein the request processing method is applied to a first device and comprises the following steps: receiving a request message; after receiving the request message, returning a response message to a sender of the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed; determining whether the request message is a response refusal request message by analyzing the request message; receiving the target data when the request message is not a response-refusal request message; denying receipt of the target data when the request message is a response-denying request message.
Description
Technical Field
The present disclosure relates to the field of network technologies, and in particular, to a request processing method and apparatus, an electronic device, and a storage medium.
Background
At present, more advertisements are received in application programs of intelligent equipment such as mobile phones and the like, and the use experience is greatly influenced. Some advertisement blocking methods in the related art can cause the response speed of the non-advertisement network request to be slow while blocking the network request related to the advertisement, thereby affecting the working efficiency of the normal service function.
Disclosure of Invention
The embodiment of the disclosure provides a request processing method and device, electronic equipment and a storage medium.
A first aspect of the embodiments of the present disclosure provides a request processing method, which is applied to a first device, and the method includes:
receiving a request message;
after receiving the request message, returning a response message to a sender of the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed;
determining whether the request message is a response refusal request message by analyzing the request message;
receiving the target data when the request message is not a response-refusal request message;
denying receipt of the target data when the request message is a response-denying request message.
Based on the above solution, the determining whether the request message is a response-refusal request message by parsing the request message includes:
acquiring a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: unifying resource addresses;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type.
Based on the scheme, the second characteristic is recorded in a characteristic table; the feature table includes: the first device stores a first feature table locally and/or receives a second feature table from a second device.
Based on the above scheme, the method further comprises:
after receiving the target data, determining whether the target data is the target data rejected to be processed or not by analyzing the target data;
if the target data is not the target data refused to be processed, processing the target data;
and if the target data is the target data which is rejected to be processed, deleting the target data.
Based on the above scheme, the determining whether the target data is the target data rejected for processing by analyzing the target data includes:
acquiring a third characteristic of a sender of the target data by analyzing the target data; the third feature includes at least: unifying resource addresses;
if the third characteristic is the same as the first characteristic, determining that the target data is the target data rejected for processing when the third characteristic is matched with a fourth characteristic of a previously known target data type rejected for processing;
and if the third characteristic is different from the first characteristic, determining the target data as the target data rejected to be processed when the third characteristic is matched with the fourth characteristic and/or the second characteristic.
Based on the above scheme, the method further comprises:
if the first characteristic is matched with a fifth characteristic of a request message type which is known in advance and allows response, determining that the request message is not a request message which refuses response;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type, comprising:
if the first characteristic is not matched with the fifth characteristic, when the first characteristic is matched with a second characteristic of a pre-known response rejection request message type, determining that the request message is a response rejection request message.
Based on the above scheme, the method further comprises:
if the third feature is matched with the fourth feature, determining a request message corresponding to target data based on the target data corresponding to the third feature;
and adding the first characteristic of the request message corresponding to the target data to the second characteristic.
Based on the above scheme, the method further comprises:
adding the first feature to the fifth feature if the first feature does not match the second feature.
Based on the scheme, the characteristic table is stored in a first-in first-out (FIFO) queue with a fixed preset capacity.
Based on the above scheme, the method further comprises:
and writing the second characteristics in the second characteristic table corresponding to the application program into the first characteristic table corresponding to the application program every preset time length based on the application program corresponding to at least one first characteristic table included in the first equipment.
A second aspect of the embodiments of the present disclosure provides a request processing apparatus, which is applied to a first device, and the apparatus includes:
a first receiving unit for receiving a request message;
a returning unit, configured to return a response message to a sender of the request message after receiving the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed;
the analysis unit is used for determining whether the request message is a response refusing request message or not by analyzing the request message;
a second receiving unit configured to receive the target data when the request message is not a response-refusal request message; denying receipt of the target data when the request message is a response-denying request message.
Based on the foregoing solution, the parsing unit is specifically configured to:
acquiring a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: unifying resource addresses;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type.
Based on the scheme, the second characteristic is recorded in a characteristic table; the feature table includes: the first device stores a first feature table locally and/or receives a second feature table from a second device.
Based on the foregoing solution, the parsing unit is further configured to:
after receiving the target data, determining whether the target data is the target data rejected to be processed or not by analyzing the target data;
the device further comprises:
a processing unit configured to process the target data if the target data is not the target data for which the processing is rejected; and if the target data is the target data which is rejected to be processed, deleting the target data.
Based on the foregoing solution, the parsing unit is specifically configured to:
acquiring a third characteristic of a sender of the target data by analyzing the target data; the third feature includes at least: unifying resource addresses;
if the third characteristic is the same as the first characteristic, determining that the target data is the target data rejected for processing when the third characteristic is matched with a fourth characteristic of a previously known target data type rejected for processing;
and if the third characteristic is different from the first characteristic, determining the target data as the target data rejected to be processed when the third characteristic is matched with the fourth characteristic and/or the second characteristic.
Based on the foregoing solution, the parsing unit is further configured to:
if the first characteristic is matched with a fifth characteristic of a request message type which is known in advance and allows response, determining that the request message is not a request message which refuses response;
the analysis unit is specifically configured to:
if the first characteristic is not matched with the fifth characteristic, when the first characteristic is matched with a second characteristic of a previously known type of a request message for rejecting a response, determining that the request message is a request message for rejecting a response.
Based on the above scheme, the apparatus further comprises:
a first adding unit, configured to determine, based on target data corresponding to the third feature, a request message corresponding to the target data if the third feature matches the fourth feature; and adding the first characteristic of the request message corresponding to the target data to the second characteristic.
Based on the above scheme, the apparatus further comprises:
a second adding unit, configured to add the first feature to the fifth feature if the first feature does not match the second feature.
Based on the scheme, the characteristic table is stored in a first-in first-out (FIFO) queue with a fixed preset capacity.
Based on the above scheme, the apparatus further comprises:
and the updating unit is used for writing the second characteristics in the second characteristic table corresponding to the application program into the first characteristic table corresponding to the application program every preset time length based on the application program corresponding to at least one first characteristic table included in the first device.
A third aspect of the embodiments of the present disclosure provides an electronic device, including:
a memory for storing processor-executable instructions;
a processor coupled to the memory;
wherein the processor is configured to execute the request processing method provided by any of the above technical solutions.
A fourth aspect of the embodiments of the present disclosure provides a non-transitory computer-readable storage medium, where computer-executable instructions are stored in the computer-readable storage medium, and when executed by a processor, the computer-executable instructions implement the request processing method provided in any of the foregoing technical solutions.
The request processing method provided by the embodiment of the disclosure is applied to first equipment and comprises the following steps: receiving a request message; after receiving the request message, returning a response message to a sender of the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed; determining whether the request message is a response refusal request message by analyzing the request message; receiving the target data when the request message is not a response-refusal request message; denying receipt of the target data when the request message is a response-denying request message. Therefore, the response message is directly returned after the request is received, so that the processing process of the request message and the sending process of the target data can be synchronously carried out, and the sending process of the target data is not required to be stopped in the process of confirming whether the request message needs to be responded or not. Whether the corresponding target data is received or not can be determined based on the processing result of the request message, so that the transmission and processing efficiency of the request message needing to be responded and the target data is improved on the basis of effectively filtering the request message needing to be responded, such as an advertisement request.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.
Fig. 1 is a flow chart diagram illustrating a request processing method according to an embodiment of the disclosure;
FIG. 2 is a schematic structural diagram of a request processing apparatus according to an embodiment of the present disclosure;
fig. 3 is a flowchart illustrating an advertisement blocking method according to an embodiment of the disclosure.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.
As shown in fig. 1, an embodiment of the present disclosure provides a request processing method, applied to a first device, where the method includes:
s110: receiving a request message;
s120: after receiving the request message, returning a response message to a sender of the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed;
s130: determining whether the request message is a response refusal request message by analyzing the request message;
s140: receiving the target data when the request message is not a response-refusal request message;
s150: denying receipt of the target data when the request message is a response-denying request message.
In the embodiment of the present disclosure, the first device may be a device for processing the request message and the target data, such as a smart device like a mobile phone or a computer. The request message may be a request from a sender or other device on the network side, such as a network request for requesting access to or providing target data to the first device, etc. The response message is used for representing that the first device allows the sender of the request message to acquire and send the target data, or the sender of the request message indicates the sender of the target data to send the target data.
Here, the response message may be a separate message generated by the first device based on the request message, or may be a response message formed by adding an instruction indicating to transmit the target data to the request message.
For example, the response message may carry characteristic information such as a Uniform Resource address (URL) of the request message sender or a request parameter, where the request parameter may include a data amount and/or a data content parameter of the target data requested to be sent.
The request processing method may be applied to a Virtual Private Network (VPN) of the first device, or may also be applied to one or more Application programs (APPs) of the first device, and is used for processing a request message and target data received by the VPN or the one or more APPs. The target data may be data received by the first device for performing processing operations such as displaying, for example, data for displaying content such as APP business content, service support, or advertisement.
In one embodiment, the S130 may include:
and determining whether the uniform resource address URL of the request message sender is a response-refusing URL or not by analyzing the request message, and if the uniform resource address URL of the request message sender is the response-refusing URL, determining that the request message is the response-refusing request message.
And the first equipment directly returns a response message after receiving the request message to indicate the sending of the target data, and carries out analysis processing on the request message. For example, the information such as the URL and/or Internet protocol Address (IP) of the sender of the request message is parsed to identify the identity of the sender of the request message. Further, the parsed URL may be used to determine whether the request message requires a response, for example, whether the URL of the sender of the request message is a URL allowing a response or a URL rejecting a response in a blacklist.
In some embodiments, the S130 may include: analyzing the request parameters carried by the request message, determining whether the content indicated by the request message is response refusal content, and if the content related to the request message is the response refusal content, determining that the request message is the response refusal request message.
For example, the request message may carry some other request parameters besides the uniform resource address such as the URL. The request parameter may indicate data content of target data requested to be transmitted by the request message, and the request parameter may include: a data content parameter. The data content parameters may include: an "inventory" parameter indicating an article, a parameter indicating an Application "Application," or an advertisement content parameter indicating an advertisement, etc.
Here, determining whether the request message is a response rejection request message according to a request parameter other than the URL may be determined according to a device configuration of the first device. For example, if the user is determined to be a child or an elderly person based on the user identifier of the first device, the request message meeting the preset request content condition is determined to be a response refusal request message based on the request parameter in the request message. The preset request content condition may include: to at least one of payment request contents, private information invocation request contents, harmful information push request contents, and the like.
For example, for a first device used by a child or a young or an old, a parent or a child may perform a relevant input operation on a configuration page, and the first device may generate a relevant configuration after detecting the input operation, so that the first device may not receive some information push which endangers property safety, information safety and/or physical and mental health of the user.
In another embodiment, the first device directly returns the request message as a response message to the sender of the request message after receiving the request message. For example, an instruction indicating to send the target data may be carried in the request message and returned. The first device may copy the request message and return the copied request message to the sender, and then determine whether the request message is a response-refused request message by parsing the copied request message.
In another embodiment, since the response message indicates that the sender of the request message sent the target data, determining whether the request message is a response-denied request message may be used to further determine whether the first device needs to receive the sent target data corresponding to the request message. When the request message is a response-refusal request message, the first device refuses to receive the corresponding target data. When the request message is not a response-refusal request message, the first device receives corresponding target data.
In yet another embodiment, the received target data may be used to directly forward to the data processing module for processing for display at the first device, or may also be used to determine data validity, such as determining whether the target data needs to be processed or intercepted based on information such as a URL or request parameters corresponding to the target data.
In this way, the response message is returned directly after the request message is received, while the verification of the request message is performed on the first device side to determine whether a response is required. Therefore, the verification process for the request message does not cause the transmission process of the target data to be suspended, so that the receiving and processing efficiency of the target data can be effectively improved. Whether the request message needs to be responded or not is verified, whether the target data corresponding to the request message is received or not can be determined, and therefore on the basis of filtering the network request which rejects the response and the corresponding data, the processing speed of the request message and the target data which need to be responded and processed can be greatly improved, and negative effects on normal service requests in the first device are reduced.
In some embodiments, the S130 may include:
acquiring a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: unifying resource addresses;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type.
In the disclosed embodiment, the first feature may include a uniform resource address URL, an IP address, or other identification information, etc. The second characteristic may be a pre-stored URL, IP address or other identification information corresponding to the request message characterizing the rejection of the response by the first device, for example, the second characteristic may be recorded in one or more characteristic tables. After the first feature is obtained through analysis, a feature table where the second feature is located and the like can be called for comparison and verification with the first feature. Here, the feature table may be in the form of an advertisement request feature list or a request feature information blacklist, or the like.
In one embodiment, when the first characteristic matches the second characteristic, for example when the URL of the sender of the request message matches one of the URLs in the list of advertisement request URLs, it may be determined that the request message is a response-denied request message, i.e. the first device does not need to receive its corresponding target data. At this time, the first device refuses to receive the target data.
In another embodiment, the second characteristic may be characteristic information of a request message for rejecting a response that the first device has received, or may be characteristic information of a request message for rejecting a response that the first device acquires from a server or other devices. For example, the first device sets and stores the URL of the request message sender which has been received in history and determined as a reject response, or the URL of the request message sender which is determined as the target data of the reject processing, as the second feature.
In another embodiment, when the first characteristic matches a second characteristic of a previously known reject response request message type, the first characteristic may be the same as the second characteristic, or the first characteristic may be in a preset association with the second characteristic. Here, the preset association relationship may include: the similarity reaches a preset similarity condition, and/or the content association reaches a preset association condition, and the like.
In a further embodiment, it may be determined that the first characteristic matches the second characteristic if the first characteristic of the sender of the request message is determined to characterize a certain similarity between the senders of the request message corresponding to the at least one second characteristic.
Therefore, based on the comparison and matching with the second characteristic, whether the first characteristic belongs to the characteristic information of the request message needing to reject the response can be quickly and accurately verified, and whether the target data needs to be received can be further quickly determined.
In some embodiments, the second characteristic is recorded in a characteristic table; the feature table includes: the first device stores a first feature table locally and/or receives a second feature table from a second device.
In the embodiment of the present disclosure, the first device may include one or more feature tables recording the second features, where the feature tables may include a first feature table locally stored by the first device, for example, a local advertisement URL list locally stored by the first device, and/or include a second feature table acquired by the first device from the second device, for example, a cloud advertisement URL list recorded by the server.
Here, the second feature recorded in the first feature table may be a subset of the second feature recorded in the second feature table, for example, the first device obtains, from the second feature table of the server, the second feature corresponding to the application program owned by the first device side, and adds the second feature to the first feature table.
The second feature recorded in the first feature table may also be a certain intersection with the second feature recorded in the second feature table. For example, the second feature recorded in the first feature table includes a corresponding second feature in the second feature table of the application program commonly owned by the first device and the second device.
In one embodiment, the first feature table and/or the second feature table may be added to the first feature table and/or the second feature table by obtaining, for example, a masked advertisement URL information recorded by the calling application server from each application.
In one embodiment, when the feature table includes a first feature table and a second feature table, determining that the request message is a response-denied request message when the first feature matches a second feature of a pre-known response-denied request message type may include: and when the first characteristic is matched with the second characteristic in the first characteristic table or the first characteristic is not matched with the second characteristic in the first characteristic table and is matched with the second characteristic in the second characteristic table, determining the request message as a request message rejecting the response.
Illustratively, the first characteristic is a URL of a sender of the request message, the first characteristic is compared with a local advertisement URL list, and if the first characteristic is matched with the local advertisement URL list, the request message which refuses the response is determined; if the first characteristics are not matched with the cloud advertisement URL list, the first characteristics are compared with the cloud advertisement URL list, and if the first characteristics are matched with the cloud advertisement URL list, the first characteristics are determined as a request message for rejecting response; if not, determining that the request message is not a response-denied request message.
Here, the native advertisement URL list may set a certain list length limit, such as to record a maximum of N URLs (e.g., N equals 200, 300, or 500). The cloud advertisement URL list can be obtained by downloading the first equipment from a cloud server, and can be synchronized to the cloud at regular time.
In another embodiment, the method may further comprise: and if the first characteristic is not matched with the second characteristic in the at least one characteristic table, recording the first characteristic in a white list.
Therefore, based on the local storage and the feature table acquired from other equipment, the screening and verification accuracy of the first feature can be further improved, and the filtering accuracy of the request message rejecting the response is improved.
In some embodiments, the method further comprises:
after receiving the target data, determining whether the target data is the target data rejected to be processed or not by analyzing the target data;
if the target data is not the target data refused to be processed, processing the target data; wherein the processing the target data includes, but is not limited to: displaying the target data and/or forwarding the target data;
and if the target data is the target data which is rejected to be processed, deleting the target data or shielding the display of the target data.
In the embodiment of the present disclosure, since the VPN is initially established, the second feature included in the feature table may be less, and it is still necessary to determine whether the received target data is illegal target data rejected by parsing.
In one embodiment, determining whether the target data is the target data rejected from processing by parsing the target data may include parsing feature information such as a URL of a sender that obtains the target data, determining whether the target data is the target data rejected from processing based on the feature information, or determining whether the target data is the target data rejected from processing based on data content of the target data obtained by parsing.
Illustratively, the data content of the target data is analyzed, and whether the data content contains the content which is associated with the corresponding application program to a degree lower than a preset condition or contains illegal data content such as advertisements is determined. And if yes, determining the target data as the target data rejected for processing.
In another embodiment, after receiving the target data, if the target data is the target data rejected from processing, the first device needs to perform an interception process on the target data, for example, delete the target data, or prohibit displaying the target data, or store the target data in a preset storage location, for example, an advertisement data list.
In another embodiment, after receiving the target data, if the target data is not the target data rejected from processing, the target data is subjected to normal processing operation, for example, display operation is directly performed on the target data, or the target data is forwarded to the service processing module for subsequent data processing.
In another embodiment, if the target data is determined to be the target data rejected for processing based on the characteristic information (e.g., URL) of the target data, the target data is deleted and the characteristic information of the target data is recorded in the characteristic table as the second characteristic for comparison with the first characteristic when the request message is next received.
Therefore, after whether the received target data is preliminarily screened based on the first characteristic of the request message or not, whether the received target data is processed or intercepted is further determined based on the analysis of the target data, so that the first characteristic that the second characteristic cannot accurately filter the request message to be intercepted due to the incomplete characteristic table is better made up.
In some embodiments, the determining whether the target data is the target data rejected from processing by parsing the target data includes:
acquiring a third characteristic of a sender of the target data by analyzing the target data; the third feature includes at least: unifying resource addresses;
if the third characteristic is the same as the first characteristic, determining that the target data is the target data rejected for processing when the third characteristic is matched with a fourth characteristic of a previously known target data type rejected for processing;
if the third characteristic is different from the first characteristic, when the third characteristic is matched with the fourth characteristic and/or the second characteristic, determining that the target data is the target data rejected to be processed.
In the embodiment of the present disclosure, the third characteristic of the sender of the target data is determined by parsing, and may include characteristic information such as a URL and an IP address. Here, since the sender of the request message may send the target data again by itself after receiving the response message, it is also possible to send the target data by another sender. Therefore, in order to verify the validity of the target data more accurately, further comparison verification is performed based on the third feature of the sender of the target data.
In one embodiment, when the third characteristic of the target data is the same as the first characteristic of the request message corresponding to the target data, for example, the URL of the sender of the target data is the same as the URL of the sender of the request message, the target data and the request message are characterized as the same sender. Therefore, only the third feature is compared and matched with the fourth feature, wherein the fourth feature can be recorded in the third feature table. For example, the third feature table may be a return interception list for recording the URL of the target data sender of the return to be intercepted.
Here, the third feature table may be stored in the first device itself together with the first feature table, or the third feature table of each application may be stored in one storage location together with the first feature table of each application.
In one embodiment, when the first feature table is called to compare the first feature with the second feature, if the request message is determined not to be a response rejection request message, a third feature table stored together with the first feature table is called in a storage location of the first feature table for comparison after the target data is received.
In another embodiment, when the third characteristic of the target data is different from the first characteristic of the request message corresponding to the target data, the target data and the request message are characterized as different senders. Therefore, the third feature is compared and matched with the second feature and the fourth feature respectively. For example, the third feature may be compared with the second feature and the fourth feature recorded in the first feature table, the second feature table, and the third feature table, and if there is a match, the target data is the target data rejected for processing.
In still another embodiment, if the target data is the target data for which the processing is rejected, the third feature of the sender of the target data is recorded as the fourth feature and the second feature. For example, the third feature may be recorded in the return block list, the local advertisement URL list, and the cloud advertisement URL list, so as to update the return block list and the advertisement URL list.
In another embodiment, the return interception list recording the fourth feature may be configured to delete the expired feature information periodically. For example, the storage time of each fourth feature stored in the returned interception list is recorded, and when the time interval between the storage time and the current time exceeds a preset interval, the corresponding fourth feature is deleted. In this way, the timeliness of the fourth feature can be maintained, and the memory resource occupied by the fourth feature can be reduced.
In one embodiment, the matching of the third feature with the fourth feature may include that the third feature is the same as the fourth feature, or that the third feature and the fourth feature have a preset association relationship. Here, the preset association relationship may include: the similarity reaches a preset similarity condition, and/or the content association reaches a preset association condition, and the like.
In another embodiment, if the third characteristic of the target data sender is determined, and the similarity between the data senders corresponding to the at least one fourth characteristic is represented to reach a preset similarity condition, it may be determined that the third characteristic matches the fourth characteristic.
Therefore, whether the sender of the target data is changed compared with the sender of the request message or not, the further matching screening can be carried out based on the target data, and the filtering precision of the data needing to be intercepted, such as the advertisement data, is improved.
In some embodiments, the method further comprises:
if the first characteristic is matched with a fifth characteristic of a request message type which is known in advance and allows response, determining that the request message is not a request message which refuses response;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type, comprising:
if the first characteristic is not matched with the fifth characteristic, when the first characteristic is matched with a second characteristic of a previously known type of a request message for rejecting a response, determining that the request message is a request message for rejecting a response.
In the embodiment of the present disclosure, the fifth feature represents feature information of the request message allowing response, for example, may be recorded in a request message URL white list. And matching and confirming the first characteristic based on the fifth characteristic in the white list, so that the frequently received normal service request can be verified more quickly, and the corresponding target data can be confirmed and received without comparing the subsequent second characteristic.
In one embodiment, the method may further comprise: and if the first characteristic is not matched with the fifth characteristic, comparing the first characteristic with a preset request interception list. The request interception list records a preset sender URL of the request message to be intercepted, and can be used as a request message URL blacklist.
In another embodiment, the returning a response message to the sender of the request message after receiving the request message may include: after receiving the request message, if the first characteristic is matched with the fifth characteristic, returning a response message to a sender of the request message; if the first characteristic is not matched with the fifth characteristic, comparing the first characteristic with characteristic information in a request interception list; and if the first characteristic is not matched with the characteristic information in the request interception list, returning a response message to the sender of the request message.
In yet another embodiment, the method may further include: and if the first characteristic is matched with the fifth characteristic and if the first characteristic is matched with the characteristic information in the request interception list, returning an empty message to a sender of the request message to prevent the sender from returning the target data.
In yet another embodiment, if the first characteristic does not match the fifth characteristic and does not match the characteristic information in the request interception list, a response message is returned to the request message sender, and whether the request message is a request message rejecting the response is determined based on the comparison of the first characteristic and the second characteristic.
Here, the request interception list may be stored in the local device of the first device together with the first feature table and/or the third feature table, or may be stored in one storage location together with the first feature table and/or the third feature table of each application for the request interception list of each application.
In one embodiment, when the request interception list is called to compare the features, if the features are determined not to be matched and a response message is returned, a first feature table stored together with the request interception list is called at a storage position of the request interception list and used for continuing to compare the first feature with the second feature.
Therefore, the request message is preliminarily screened based on the fifth characteristic in the white list, so that the processing speed of the normal service request recorded in the white list is improved, and the influence of the verification and filtering of the illegal request message on the processing efficiency of the normal request message is further reduced.
In some embodiments, the method further comprises:
if the third feature is matched with the fourth feature, determining a request message corresponding to target data based on the target data corresponding to the third feature;
and adding the first characteristic of the request message corresponding to the target data to the second characteristic.
In the embodiment of the present disclosure, if the third feature matches the fourth feature, it indicates that the received target data is the target data rejected for processing, and the first feature of the corresponding request message does not match the second feature, indicating that the request message corresponding to the target data rejected for processing is not considered as a request message rejected for response. Therefore, the corresponding first characteristic is added to the second characteristic, the recorded second characteristic can be updated in time, and the request message corresponding to the first characteristic can be regarded as the request message for rejecting the response, so that the response rejection and the target data rejection can be determined earlier than the verification in the target data stage, and the characteristic comparison verification can be performed more accurately and efficiently.
In some embodiments, the method further comprises:
adding the first feature to the fifth feature if the first feature does not match the second feature.
In an embodiment of the disclosure, if the first characteristic does not match the second characteristic, characterizing that the request message is not a request message rejecting a response, the first characteristic of the request message may be added to the fifth characteristic. For example, the first feature is added to a white list recording a fifth feature, so that the fifth feature is updated in time, the feature comparison result is further advanced, and the white list-based matching can avoid the subsequent comparison process with the second feature, thereby better realizing the rapid verification of the normal service request.
In one embodiment, if the first characteristic matches the second characteristic, the first characteristic is added to the request intercept list, thereby further advancing the identification of the request message that rejects the response, better speeding up the efficiency of the next request message authentication.
In some embodiments, the feature table is stored in a first-in-first-out FIFO queue having a fixed preset capacity.
Here, a First-in First-out (FIFO) queue is used to store the second features in the feature table, and when the number of the second features stored in the FIFO queue reaches a preset capacity, one second feature is sequentially deleted in the sequence of the storage times of the second features in the queue every time a new second feature is inserted, thereby realizing that the stored second features are the latest certain number of second features.
In an embodiment, the FIFO queues corresponding to the first feature table and the second feature table may have the same preset capacity, for example, 500, or may be different.
In another embodiment, the fourth feature and/or the fifth feature may also be recorded in a feature table and stored in a FIFO queue having a fixed capacity.
In some embodiments, the method further comprises:
and writing the second characteristics in the second characteristic table corresponding to the application program into the first characteristic table corresponding to the application program every preset time length based on the application program corresponding to at least one first characteristic table included in the first equipment.
In the embodiment of the present disclosure, the first feature table in the first device is updated based on the second feature table of the second device every preset time, for example, the second feature in the first feature table is updated periodically based on the second feature stored by the server. Here, the second profile table corresponding to the application may be acquired from one server, or may be acquired from a server corresponding to each application.
In one embodiment, the second device may include a second feature table of an application different from the first device, and thus the application corresponding to the first feature table in the first device is determined first, and then the second feature table corresponding to the application is queried in the second device.
In another embodiment, the second features in the second feature table of each application program are respectively written into the corresponding first feature table, where the second features newly added to the second feature table within the preset time duration may be written into the corresponding first feature table, or the second features included in the second feature table and not recorded in the first feature table may be written into the first feature table.
As shown in fig. 2, an embodiment of the present disclosure provides a request processing apparatus, applied to a first device, where the apparatus includes:
a first receiving unit 10, configured to receive a request message;
a returning unit 20, configured to return a response message to a sender of the request message after receiving the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed;
a parsing unit 30, configured to determine whether the request message is a response-refused request message by parsing the request message;
a second receiving unit 40 for receiving the target data when the request message is not a response-refused request message; denying receipt of the target data when the request message is a response-denying request message.
In some embodiments, the parsing unit 30 is specifically configured to:
acquiring a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: unifying resource addresses;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type.
In some embodiments, the second characteristic is recorded in a characteristic table; the feature table includes: the first device stores a first feature table locally and/or receives a second feature table from a second device.
In some embodiments, the parsing unit 30 is further configured to:
after receiving the target data, determining whether the target data is the target data rejected to be processed or not by analyzing the target data;
the device further comprises:
a processing unit configured to process the target data if the target data is not the target data for which the processing is rejected; and if the target data is the target data which is rejected to be processed, deleting the target data.
In some embodiments, the parsing unit 30 is specifically configured to:
acquiring a third characteristic of a sender of the target data by analyzing the target data; the third feature includes at least: unifying resource addresses;
if the third characteristic is the same as the first characteristic, determining that the target data is the target data rejected for processing when the third characteristic is matched with a fourth characteristic of a previously known target data type rejected for processing;
and if the third characteristic is different from the first characteristic, determining the target data as the target data rejected to be processed when the third characteristic is matched with the fourth characteristic and/or the second characteristic.
In some embodiments, the parsing unit 30 is further configured to:
if the first characteristic is matched with a fifth characteristic of a request message type which is known in advance and allows response, determining that the request message is not a request message which refuses response;
the analysis unit 30 is specifically configured to:
if the first characteristic is not matched with the fifth characteristic, when the first characteristic is matched with a second characteristic of a previously known type of a request message for rejecting a response, determining that the request message is a request message for rejecting a response.
In some embodiments, the apparatus further comprises:
a first adding unit, configured to determine, based on target data corresponding to the third feature, a request message corresponding to the target data if the third feature matches the fourth feature; and adding the first characteristic of the request message corresponding to the target data to the second characteristic.
In some embodiments, the apparatus further comprises:
a second adding unit, configured to add the first feature to the fifth feature if the first feature does not match the second feature.
In some embodiments, the feature table is stored in a first-in-first-out FIFO queue having a fixed preset capacity.
In some embodiments, the apparatus further comprises:
and the updating unit is used for writing the second characteristics in the second characteristic table corresponding to the application program into the first characteristic table corresponding to the application program every preset time length based on the application program corresponding to at least one first characteristic table included in the first device.
One specific example is provided below in connection with any of the embodiments described above:
the embodiment of the disclosure provides an advertisement blocking method, which includes creating a VPN at a mobile phone end, acquiring all network requests through the VPN, directly transmitting the network requests after copying, comparing the copied data with preset conditions, and blocking returned advertisement data through comparison results. The scheme can efficiently intercept the advertisement request of the APP in the mobile phone, thereby achieving the purpose of shielding the advertisement.
As shown in fig. 3, in the advertisement blocking method based on VPN according to the embodiment of the present disclosure, a VPN is created at a mobile phone end, so that all network requests of the mobile phone can be obtained.
And (3) a sending process:
after obtaining the network request, extracting the URL therein, and determining whether the URL is in a network request white list (the list is a first-in first-out queue with a fixed length, for example, 200; and is only maintained in the memory, and is cleared and reset every time the VPN process is restarted). If so, directly sending the request; if not, it is determined whether it is in the request intercept list.
The request interception list is also a first-in first-out queue, like the network request white list, and has a fixed length, for example, 100; and it is a memory value that will be cleared and reset each time the VPN process restarts. If the URL in the last step exists in the request interception list, intercepting and returning false data based on the request; if not, sending a request, and judging whether the URL is in the local advertisement list in the interception request thread.
The local advertisement list is an advertisement URL which has been requested by the mobile phone, is maintained in a memory and is stored persistently, and a larger length limit is set, such as 500. Inserting the URL into the request interception list and the return interception list if the URL in the previous step exists in the native advertisement list; if not, whether the advertisement is in the cloud advertisement blacklist is judged.
The cloud advertisement blacklist is an advertisement blacklist persistently stored by the local machine, and is periodically synchronized with the cloud end, and if the URL in the last step exists in the cloud advertisement blacklist, the URL is inserted into the request interception list, the return interception list and the local machine advertisement list; if not, it is inserted into the network white list.
And returning to the process:
if the return interception list is empty, no return interception is performed; otherwise, the data returned by the network and the corresponding URL thereof need to be acquired.
Judging whether the URL is in a return interception list (the list is only maintained in a memory, and a clear reset can be realized every time the VPN process is restarted), if so, intercepting and returning false data; if not, the data is returned normally.
Returning the intercept list requires recording the time each data is stored and after a period of time (e.g., 10 seconds), deleting the expired data.
Here, the embodiment of the present disclosure sets up a multi-level black and white list to achieve a high efficiency, and simultaneously, the memory usage and the performance consumption are maintained at a low level.
When the VPN process is created and starts to intercept, the network white list, the request interception list and the return interception list are gradually filled (the local advertisement list is not mentioned temporarily). The interception at this moment mainly depends on returning the interception list, but as time goes on, the interception is gradually advanced, and the returning interception list is gradually emptied, and the main function is to request the interception list.
The number of non-advertisement network requests in the mobile phone is the largest, the network white list is set to improve the efficiency of the requests, and the frequently-occurring requests can be judged once to finish the whole process. The role of the request intercept list is also the same as the population of the request intercept list. The frequently-occurring advertisement requests can return false data only by judging twice, and interception is completed.
The network white list, request intercept list, return intercept list are maintained only in memory, and the first two lists are of limited length. The APPs used by the user in different time periods and different use scenes are different, and the triggered network requests are also different. These lists are gradually filled and updated so that only short lists need to be retrieved in order to keep normal requests and advertisement blocking efficient.
The local advertisement list is a subset of the cloud advertisement blacklist, the setting of the local advertisement list is also for improving the retrieval efficiency, after all, the cloud advertisement blacklist is the advertisement URL extracted from a plurality of APPs, the mobile phone can only contain a plurality of APPs, and the intersection of the cloud advertisement blacklist and the local advertisement list is taken to update the local advertisement list when the cloud advertisement blacklist is updated every time.
The cloud advertisement blacklist can be extracted from each APP and is updated periodically, and the mobile phone can be synchronized periodically under a wireless network.
An embodiment of the present disclosure provides an electronic device, including:
a memory for storing processor-executable instructions;
a processor connected with the memory;
wherein the processor is configured to execute the request processing method provided by any of the foregoing technical solutions.
The processor may include various types of storage media, which are non-transitory computer storage media capable of continuing to remember the information stored thereon after a power failure of the electronic device.
The processor may be connected to the memory via a bus or the like for reading the executable program stored in the memory, for example, to be able to perform one or more of the methods described in the preceding claims.
An embodiment of the present disclosure provides a structure of an electronic device. The electronic device includes a processing component that further includes one or more processors, and memory resources, represented by memory, for storing instructions, such as application programs, that are executable by the processing component. The application program stored in the memory may include one or more modules that each correspond to a set of instructions. Furthermore, the processing component is configured to execute the instructions to perform any of the methods described above as applied to the electronic device, for example, the methods described in one or more of the preceding claims.
The electronic device may also include a power supply component configured to perform power management of the electronic device, a wired or wireless network interface configured to connect the electronic device to a network, and an input-output (I/O) interface. The electronic device may operate based on an operating system stored in memory, such as Windows Server (TM), Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, or the like.
The disclosed embodiments provide a non-transitory computer-readable storage medium, wherein when instructions in the storage medium are executed by a processor of a computer, the computer is enabled to execute a request processing method according to one or more of the above technical solutions.
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice in the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.
It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.
Claims (22)
1. A request processing method, applied to a first device, the method comprising:
receiving a request message;
after receiving the request message, returning a response message to a sender of the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed;
determining whether the request message is a response refusal request message by analyzing the request message;
receiving the target data when the request message is not a response-refusal request message;
denying receipt of the target data when the request message is a response-denying request message.
2. The method of claim 1, wherein the determining whether the request message is a response-denied request message by parsing the request message comprises:
acquiring a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: unifying resource addresses;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type.
3. The method of claim 2, wherein the second characteristic is recorded in a characteristic table; the feature table includes: the first device stores a first feature table locally and/or receives a second feature table from a second device.
4. The method of claim 3, further comprising:
after receiving the target data, determining whether the target data is the target data rejected to be processed or not by analyzing the target data;
if the target data is not the target data refused to be processed, processing the target data;
and if the target data is the target data which is rejected to be processed, deleting the target data.
5. The method of claim 4, wherein the determining whether the target data is the target data rejected for processing by parsing the target data comprises:
acquiring a third characteristic of a sender of the target data by analyzing the target data; the third feature includes at least: unifying resource addresses;
if the third characteristic is the same as the first characteristic, determining that the target data is the target data rejected for processing when the third characteristic is matched with a fourth characteristic of a previously known target data type rejected for processing;
and if the third characteristic is different from the first characteristic, determining the target data as the target data rejected to be processed when the third characteristic is matched with the fourth characteristic and/or the second characteristic.
6. The method of claim 5, further comprising:
if the first characteristic is matched with a fifth characteristic of a request message type which is known in advance and allows response, determining that the request message is not a request message which refuses response;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type, comprising:
if the first characteristic is not matched with the fifth characteristic, when the first characteristic is matched with a second characteristic of a previously known type of a request message for rejecting a response, determining that the request message is a request message for rejecting a response.
7. The method of claim 5, further comprising:
if the third feature is matched with the fourth feature, determining a request message corresponding to target data based on the target data corresponding to the third feature;
and adding the first characteristic of the request message corresponding to the target data to the second characteristic.
8. The method of claim 6, further comprising:
adding the first feature to the fifth feature if the first feature does not match the second feature.
9. The method of claim 3, wherein the feature table is stored in a first-in-first-out FIFO queue having a fixed preset capacity.
10. The method of claim 3, further comprising:
and writing the second characteristics in the second characteristic table corresponding to the application program into the first characteristic table corresponding to the application program every preset time length based on the application program corresponding to at least one first characteristic table included in the first equipment.
11. A request processing apparatus, applied to a first device, the apparatus comprising:
a first receiving unit for receiving a request message;
a returning unit, configured to return a response message to a sender of the request message after receiving the request message; the response message is used for indicating the sender of the request message to acquire target data to be processed;
the analysis unit is used for determining whether the request message is a response refusing request message or not by analyzing the request message;
a second receiving unit configured to receive the target data when the request message is not a response-refusal request message; denying receipt of the target data when the request message is a response-denying request message.
12. The apparatus according to claim 11, wherein the parsing unit is specifically configured to:
acquiring a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: unifying resource addresses;
determining that the request message is a response-denied request message when the first characteristic matches a second characteristic of a previously known response-denied request message type.
13. The apparatus of claim 12, wherein the second characteristic is recorded in a characteristic table; the feature table includes: the first device stores a first feature table locally and/or receives a second feature table from a second device.
14. The apparatus of claim 13, wherein the parsing unit is further configured to:
after receiving the target data, determining whether the target data is the target data rejected to be processed or not by analyzing the target data;
the device further comprises:
a processing unit configured to process the target data if the target data is not the target data for which the processing is rejected; and if the target data is the target data which is rejected to be processed, deleting the target data.
15. The apparatus according to claim 14, wherein the parsing unit is specifically configured to:
acquiring a third characteristic of a sender of the target data by analyzing the target data; the third feature includes at least: unifying resource addresses;
if the third characteristic is the same as the first characteristic, determining that the target data is the target data rejected for processing when the third characteristic is matched with a fourth characteristic of a previously known target data type rejected for processing;
and if the third characteristic is different from the first characteristic, determining the target data as the target data rejected to be processed when the third characteristic is matched with the fourth characteristic and/or the second characteristic.
16. The apparatus of claim 15, wherein the parsing unit is further configured to:
if the first characteristic is matched with a fifth characteristic of a request message type which is known in advance and allows response, determining that the request message is not a request message which refuses response;
the analysis unit is specifically configured to:
if the first characteristic is not matched with the fifth characteristic, when the first characteristic is matched with a second characteristic of a previously known type of a request message for rejecting a response, determining that the request message is a request message for rejecting a response.
17. The apparatus of claim 15, further comprising:
a first adding unit, configured to determine, based on target data corresponding to the third feature, a request message corresponding to the target data if the third feature matches the fourth feature; and adding the first characteristic of the request message corresponding to the target data to the second characteristic.
18. The apparatus of claim 16, further comprising:
a second adding unit, configured to add the first feature to the fifth feature if the first feature does not match the second feature.
19. The apparatus of claim 13, wherein the feature table is stored in a first-in-first-out (FIFO) queue with a fixed preset capacity.
20. The apparatus of claim 13, further comprising:
and the updating unit is used for writing the second characteristics in the second characteristic table corresponding to the application program into the first characteristic table corresponding to the application program every preset time length based on the application program corresponding to at least one first characteristic table included in the first device.
21. An electronic device, comprising:
a memory for storing processor-executable instructions;
a processor coupled to the memory;
wherein the processor is configured to perform the request processing method as provided in any one of claims 1 to 10.
22. A non-transitory computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, implement the request processing method provided in any one of claims 1 to 10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210044412.XA CN114466075B (en) | 2022-01-14 | 2022-01-14 | Request processing method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210044412.XA CN114466075B (en) | 2022-01-14 | 2022-01-14 | Request processing method and device, electronic equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114466075A true CN114466075A (en) | 2022-05-10 |
| CN114466075B CN114466075B (en) | 2024-04-16 |
Family
ID=81410081
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210044412.XA Active CN114466075B (en) | 2022-01-14 | 2022-01-14 | Request processing method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114466075B (en) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030050974A1 (en) * | 2000-03-17 | 2003-03-13 | Irit Mani-Meitav | Accelerating responses to requests mabe by users to an internet |
| CN1735107A (en) * | 2004-08-03 | 2006-02-15 | 乐金电子(中国)研究开发中心有限公司 | Method for limiting information acceptance in information push service |
| CN1949770A (en) * | 2005-10-14 | 2007-04-18 | 华为技术有限公司 | Method for providing push message and push agent device |
| CN103703484A (en) * | 2013-07-26 | 2014-04-02 | 华为技术有限公司 | Advertising display control method and apparatus |
| US20170024779A1 (en) * | 2016-08-12 | 2017-01-26 | Vertamedia LLC | Computer-implemented method for online delivery of advertising content |
| CN106791066A (en) * | 2016-12-14 | 2017-05-31 | 北京小米移动软件有限公司 | Process method, communication response terminal and the Communications Authorization terminal of communication request |
| CN106888228A (en) * | 2015-12-15 | 2017-06-23 | 中国电信股份有限公司 | Method, conversation controller and the system accelerated for content |
| CN108347374A (en) * | 2018-01-22 | 2018-07-31 | 广州欧赛斯信息科技有限公司 | A kind of information push method, system and device preventing invalid message |
| CN111901354A (en) * | 2020-08-03 | 2020-11-06 | 北京指掌易科技有限公司 | Data processing method and device and electronic terminal |
| CN112087459A (en) * | 2020-09-11 | 2020-12-15 | 杭州安恒信息技术股份有限公司 | Access request detection method, device, equipment and readable storage medium |
-
2022
- 2022-01-14 CN CN202210044412.XA patent/CN114466075B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030050974A1 (en) * | 2000-03-17 | 2003-03-13 | Irit Mani-Meitav | Accelerating responses to requests mabe by users to an internet |
| CN1735107A (en) * | 2004-08-03 | 2006-02-15 | 乐金电子(中国)研究开发中心有限公司 | Method for limiting information acceptance in information push service |
| CN1949770A (en) * | 2005-10-14 | 2007-04-18 | 华为技术有限公司 | Method for providing push message and push agent device |
| CN103703484A (en) * | 2013-07-26 | 2014-04-02 | 华为技术有限公司 | Advertising display control method and apparatus |
| CN106888228A (en) * | 2015-12-15 | 2017-06-23 | 中国电信股份有限公司 | Method, conversation controller and the system accelerated for content |
| US20170024779A1 (en) * | 2016-08-12 | 2017-01-26 | Vertamedia LLC | Computer-implemented method for online delivery of advertising content |
| CN106791066A (en) * | 2016-12-14 | 2017-05-31 | 北京小米移动软件有限公司 | Process method, communication response terminal and the Communications Authorization terminal of communication request |
| CN108347374A (en) * | 2018-01-22 | 2018-07-31 | 广州欧赛斯信息科技有限公司 | A kind of information push method, system and device preventing invalid message |
| CN111901354A (en) * | 2020-08-03 | 2020-11-06 | 北京指掌易科技有限公司 | Data processing method and device and electronic terminal |
| CN112087459A (en) * | 2020-09-11 | 2020-12-15 | 杭州安恒信息技术股份有限公司 | Access request detection method, device, equipment and readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114466075B (en) | 2024-04-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105530175B (en) | Message processing method, device and system | |
| CN107889069B (en) | Short message gateway selection method, device, server and readable storage medium | |
| CN107679718B (en) | List allocation method, apparatus and computer-readable storage medium | |
| CN105847447B (en) | Message pushing method and device | |
| CN102752326B (en) | The method of deal with data, server and system in the time of download file | |
| CN109495467B (en) | Method and device for updating interception rule and computer readable storage medium | |
| CN111756644B (en) | Hot spot current limiting method, system, equipment and storage medium | |
| US9471896B2 (en) | Memo synchronization system, mobile system, and method for synchronizing memo data | |
| CN109842621B (en) | Method and terminal for reducing token storage quantity | |
| CN106254528B (en) | Resource downloading method and caching device | |
| CN105165035B (en) | Have both the multimedia message transmission of text message transmission | |
| CN103888619A (en) | Message processing method and system thereof | |
| CN109726545B (en) | Information display method, equipment, computer readable storage medium and device | |
| CN109688094B (en) | Suspicious IP configuration method, device, equipment and storage medium based on network security | |
| CN109219001B (en) | Short message interception method, device, interception platform and storage medium | |
| CN111338710A (en) | Application program control method and device, electronic equipment and storage medium | |
| CN107015855B (en) | Asynchronous service centralized scheduling method and device supporting time strategy | |
| CN115955332A (en) | Abnormal traffic filtering method and device for authentication system and electronic equipment | |
| CN109978114B (en) | Data processing method, device, server and storage medium | |
| RU2693325C2 (en) | Method and system for detecting actions potentially associated with spamming in account registration | |
| WO2016037489A1 (en) | Method, device and system for monitoring rcs spam messages | |
| US9584537B2 (en) | System and method for detecting mobile cyber incident | |
| CN114466075B (en) | Request processing method and device, electronic equipment and storage medium | |
| US8874646B2 (en) | Message managing system, message managing method and recording medium storing program for that method execution | |
| CN106803830B (en) | Method, device and system for identifying internet access terminal and User Identity Module (UIM) card |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |