CN114466075B - Request processing method and device, electronic equipment and storage medium - Google Patents

Request processing method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN114466075B
CN114466075B CN202210044412.XA CN202210044412A CN114466075B CN 114466075 B CN114466075 B CN 114466075B CN 202210044412 A CN202210044412 A CN 202210044412A CN 114466075 B CN114466075 B CN 114466075B
Authority
CN
China
Prior art keywords
request message
feature
target data
characteristic
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.)
Active
Application number
CN202210044412.XA
Other languages
Chinese (zh)
Other versions
CN114466075A (en
Inventor
刘颖聪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Shareit Information Technology Co Ltd
Original Assignee
Beijing Shareit Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Shareit Information Technology Co Ltd filed Critical Beijing Shareit Information Technology Co Ltd
Priority to CN202210044412.XA priority Critical patent/CN114466075B/en
Publication of CN114466075A publication Critical patent/CN114466075A/en
Application granted granted Critical
Publication of CN114466075B publication Critical patent/CN114466075B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241Advertisements
    • G06Q30/0277Online advertisement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing 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 embodiment of the disclosure relates to a request processing method and device, an electronic device and a storage medium, wherein the request processing method 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 request message refusing response or not by analyzing the request message; receiving the target data when the request message is not a request message rejecting a response; and refusing to receive the target data when the request message is a request message refusing the response.

Description

Request processing method and device, electronic equipment and storage medium
Technical Field
The disclosure relates to the field of network technologies, and in particular, to a method and a device for processing a request, 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 interception methods in the related art intercept network requests related to advertisements and simultaneously cause the response speed of non-advertisement network requests to be slow, thereby affecting the working efficiency of normal service functions.
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 an embodiment of the present disclosure provides a request processing method, applied to a first device, where 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 request message refusing response or not by analyzing the request message;
Receiving the target data when the request message is not a request message rejecting a response;
And refusing to receive the target data when the request message is a request message refusing the response.
Based on the above scheme, the determining whether the request message is a request message rejecting a response by parsing the request message includes:
And obtaining a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: a uniform resource address;
When the first characteristic matches a second characteristic of a pre-known reject response request message type, the request message is determined to be a reject response request message.
Based on the above scheme, the second feature is recorded in a feature table; the feature table includes: the first device locally stores a first profile and/or a second profile received 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 refused 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 deleting the target data if the target data is the target data refused to be processed.
Based on the above scheme, the determining whether the target data is the target data refused to be processed 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: a uniform resource address;
If the third feature is the same as the first feature, determining that the target data is the target data refused to process when the third feature is matched with a fourth feature which is known in advance and refuses to process the target data type;
and if the third feature is different from the first feature, determining that the target data is the target data refused to be processed when the third feature is matched with the fourth feature and/or the second feature.
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 the response, determining that the request message is not a request message for rejecting the response;
The determining that the request message is a request message for refusal response when the first characteristic matches a second characteristic of a pre-known refusal response request message type includes:
and if the first characteristic is not matched with the fifth characteristic, determining that the request message is a request message of refusal response when the first characteristic is matched with a second characteristic of a type of the request message of refusal response known in advance.
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:
if the first feature does not match the second feature, the first feature is added to the fifth feature.
Based on the above scheme, the feature table is stored in a FIFO queue having a fixed preset capacity.
Based on the above scheme, the method further comprises:
and writing second features in a second feature table corresponding to the application program into the first feature table corresponding to the application program based on the application program corresponding to at least one first feature table contained in the first equipment at intervals of preset time.
A second aspect of an embodiment of the present disclosure provides a request processing apparatus, applied to a first device, the apparatus including:
A first receiving unit configured to receive a request message;
a return 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 analyzing unit is used for determining whether the request message is a request message refusing response or not by analyzing the request message;
A second receiving unit configured to receive the target data when the request message is not a request message rejecting a response; and refusing to receive the target data when the request message is a request message refusing the response.
Based on the above scheme, the parsing unit is specifically configured to:
And obtaining a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: a uniform resource address;
When the first characteristic matches a second characteristic of a pre-known reject response request message type, the request message is determined to be a reject response request message.
Based on the above scheme, the second feature is recorded in a feature table; the feature table includes: the first device locally stores a first profile and/or a second profile received from a second device.
Based on the above scheme, the parsing unit is further configured to:
After receiving the target data, determining whether the target data is the target data refused to be processed or not by analyzing the target data;
The apparatus further comprises:
A processing unit, configured to process the target data if the target data is not the target data that is rejected to be processed; and deleting the target data if the target data is the target data refused to be processed.
Based on the above scheme, 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: a uniform resource address;
If the third feature is the same as the first feature, determining that the target data is the target data refused to process when the third feature is matched with a fourth feature which is known in advance and refuses to process the target data type;
and if the third feature is different from the first feature, determining that the target data is the target data refused to be processed when the third feature is matched with the fourth feature and/or the second feature.
Based on the above scheme, 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 the response, determining that the request message is not a request message for rejecting the response;
the analysis unit is specifically configured to:
and if the first characteristic is not matched with the fifth characteristic, determining that the request message is a request message of refusal response when the first characteristic is matched with a second characteristic of a type of the request message of refusal response known in advance.
Based on the above scheme, the device further comprises:
the first adding unit is used for determining a request message corresponding to target data based on the target data corresponding to the third feature if the third feature is matched with 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 device further comprises:
And 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 above scheme, the feature table is stored in a FIFO queue having a fixed preset capacity.
Based on the above scheme, the device further comprises:
and the updating unit is used for writing the second features in the second feature table corresponding to the application program into the first feature table corresponding to the application program based on the application program corresponding to at least one first feature table contained in the first equipment at intervals of preset time.
A third aspect of an embodiment of the present disclosure provides an electronic device, including:
A memory for storing processor-executable instructions;
a processor connected to the memory;
wherein the processor is configured to perform the request processing method as provided in any of the previous claims.
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, where the computer-executable instructions, when executed by a processor, implement a 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 request message refusing response or not by analyzing the request message; receiving the target data when the request message is not a request message rejecting a response; and refusing to receive the target data when the request message is a request message refusing the response. Thus, 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 stagnation of the sending process of the target data is not required to occur in the process of confirming whether the request message needs to be responded or not. Based on the processing result of the request message, whether the corresponding target data is received or not can be determined, so that the transmission and processing efficiency of the request message which needs to be responded and the target data are improved on the basis of effectively filtering the request message which needs to be refused to respond, such as the 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 diagram of a request processing method shown in an embodiment of the present disclosure;
FIG. 2 is a schematic diagram of a request processing apparatus according to an embodiment of the present disclosure;
fig. 3 is a flow chart illustrating an advertisement interception method according to an embodiment of the present disclosure.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the invention. Rather, they are merely examples of apparatus and methods consistent with aspects of the invention as detailed in the accompanying claims.
As shown in fig. 1, an embodiment of the present disclosure provides a request processing method, applied to a first device, including:
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 request message refusing response or not by analyzing the request message;
s140: receiving the target data when the request message is not a request message rejecting a response;
S150: and refusing to receive the target data when the request message is a request message refusing the response.
In the embodiment of the 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, a computer, etc. 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 the first device or providing the first device with the target data, 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 instructs 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 to instruct transmission of the target data to the request message.
For example, the response message may carry characteristic information such as a uniform resource address (Uniform Resource Locat or, URL) of the sender of the request message 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 (Virtual Private Network, VPN) of the first device, or may also be applied to one or more applications (apps) of the first device, for processing request messages and target data received by the VPN or the one or more apps. The target data may be data for performing processing operations such as display after being received by the first device, for example, data for displaying APP service content, service support or advertisement content.
In one embodiment, the S130 may include:
And determining whether the URL of the request message sender is the URL of the refused response or not by analyzing the request message, and determining that the request message is the request message of the refused response if the URL of the request message sender is the URL of the refused response.
And the first equipment directly returns a response message after receiving the request message to indicate to send the target data, and performs analysis processing on the request message. For example, information such as the URL and/or internet protocol address (Internet Prot ocol Address, IP) of the sender of the get 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 needs to be responded, for example, whether the URL of the sender of the request message is a URL that allows the response or a URL that rejects the response in a blacklist, etc.
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 refused response content, and if the content related to the request message is refused response content, determining that the request message is refused response request message.
For example, the request message may carry some other request parameters in addition to the uniform resource address such as URL. The request parameter may indicate a data content of the target data that the request message requests to be transmitted, and the request parameter may include: data content parameters. The data content parameters may include: an "arc" parameter indicating an article, a parameter indicating Application, or an advertisement content parameter indicating an advertisement, etc.
Here, the determination of whether the request message is a request message rejecting a response may be determined according to a device configuration of the first device according to a request parameter other than URL. For example, if the user used is determined to be a child or an elderly person based on the user identification of the first device, the request message satisfying the preset request content condition is determined to be a request message refusing the response based on the request parameter in the request message. The preset request content condition may include: to at least one of payment request content, privacy information invocation request content, unwanted information push request content, etc.
For example, for a first device used by a child or teenager or an elderly person, a parent or 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 pushing endangering property safety, information safety and/or physical and mental health of the user.
In another embodiment, the first device returns the request message as a reply message directly to the sender of the request message after receiving the request message. For example, an instruction indicating to transmit the target data may be carried in the request message and returned. The first device may copy the request message and return the request message to the sender, and then determine whether the request message is a request message for rejecting the response by parsing the copied request message.
In another embodiment, since the reply message indicates that the sender of the request message sends the target data, determining whether the request message is a request message rejecting the response 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 request message rejecting the response, the first device rejects receiving the corresponding target data. When the request message is not a request message rejecting the response, the first device receives the 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 the validity of the data, e.g., whether the target data needs to be processed or intercepted based on information such as a URL or request parameters to which the target data corresponds.
In this way, the response message is returned directly after the request message is received, and the verification of the request message is performed at the first device side to determine whether the response is required. Therefore, the verification process of the request message does not cause the sending process of the target data to be suspended, so that the receiving and processing efficiency of the target data can be effectively improved. Based on whether the request message needs to be responded or not, whether target data corresponding to the request message is received or not can be determined, so that on the basis of filtering the network request and corresponding data which refuses to respond, the processing speed of the request message and the target data which need to be responded and processed can be greatly improved, and the negative influence on the normal service request in the first equipment is reduced.
In some embodiments, the S130 may include:
And obtaining a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: a uniform resource address;
When the first characteristic matches a second characteristic of a pre-known reject response request message type, the request message is determined to be a reject response request message.
In the embodiment of the present disclosure, the first feature may include a uniform resource address URL, an IP address, or other identification information, etc. The second feature may be a pre-stored URL, IP address, or other identifying information, etc. corresponding to the request message characterizing the rejection of the response by the first device, e.g., the second feature may be recorded in one or more feature tables. After the first feature is obtained through analysis, a feature table and the like where the second feature is located can be called for comparison 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 advertisement request URL list, it may be determined that the request message is a request message rejecting the response, 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 feature may be feature information of a refusal response request message that has been received by the first device, or may be feature information of a refusal response request message that is acquired by the first device from a server or other devices. For example, the first device sets, as the second feature, the URL of the request message sender that has been historically received and determined to reject the response, or the URL of the request message sender that has been determined to reject the target data of the processing, and saves it.
In yet another embodiment, when the first feature matches a second feature of a pre-known type of refusal response request message, it may be included that the first feature is identical to the second feature or that the first feature has a preset association with the second feature. Here, the preset association relationship may include: the similarity degree reaches a preset similarity condition, and/or the content association degree reaches a preset association degree condition, etc.
In yet another embodiment, if it is determined that the first characteristic of the sender of the request message characterizes that there is a certain similarity between the senders of the request message corresponding to the at least one second characteristic, it may be determined that the first characteristic matches the second characteristic.
Therefore, based on comparison and matching with the second feature, whether the first feature belongs to the feature information of the request message requiring refusal response can be verified quickly and accurately, and whether the target data need to be received can be determined more quickly.
In some embodiments, the second feature is recorded in a feature table; the feature table includes: the first device locally stores a first profile and/or a second profile received from a second device.
In an embodiment of the present disclosure, the first device may include one or more feature tables for recording the second feature, where the feature tables may include a first feature table stored locally by the first device, for example, a local advertisement URL list stored locally 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, and so on.
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 acquires, from the second feature table of the server, a 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 have a certain intersection with the second feature recorded in the second feature table. For example, the second features recorded in the first feature table include second features corresponding to the application programs commonly owned by the first device and the second device in the second feature table.
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, retrieving, from each application, the masking advertisement URL information recorded by the application server, and the like.
In one embodiment, when the feature table includes a first feature table and a second feature table, determining that the request message is a request message for a rejection response when the first feature matches a second feature of a pre-known rejection response request message type may include: when the first feature matches the second feature in the first feature table or when the first feature does not match the second feature in the first feature table and matches the second feature in the second feature table, the request message is determined to be 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 so, the request message is determined to be a refused response; if the first feature is not matched with the cloud advertisement URL list, the first feature is compared with the cloud advertisement URL list, and if the first feature is matched with the cloud advertisement URL list, the request message for refusing the response is determined; if there is still no match, it is determined that the request message is not a request message rejecting the response.
Here, the local advertisement URL list may set a certain list length limit, for example, set to record N (e.g., N equals 200, 300, or 500) URLs at most. The cloud advertisement URL list may be obtained by downloading the first device from the cloud server, and may be synchronized to the cloud at regular time.
In another embodiment, the method may further include: and if the first feature is not matched with the second feature in the at least one feature table, recording the first feature in the white list.
Therefore, based on the feature table stored locally and acquired from other devices, the screening and verification accuracy of the first features can be further improved, and the filtering accuracy of the request message for 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 refused 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 said processing said 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 refused to be processed, deleting the target data or shielding the display of the target data.
In the embodiment of the disclosure, since the second features contained in the feature table may be less at the beginning of VPN establishment in the first device, it is still necessary to determine whether the received target data is illegal target data that is rejected.
In one embodiment, determining whether the target data is the target data refused to be processed by parsing the target data may include parsing feature information such as URL of a sender who obtains the target data, determining whether the target data is the target data refused to be processed based on the feature information, or determining whether the target data is the target data refused to be processed based on the data content of the target data obtained by parsing.
Illustratively, the data content of the target data is parsed, and whether the data content contains content which is associated with the corresponding application program to a degree lower than a preset condition or illegal data content such as advertisements is determined. If so, determining the target data as the target data refused to be processed.
In another embodiment, after receiving the target data, if the target data is the target data that is refused to be processed, the first device needs to intercept the target data, for example, delete the target data, prohibit the target data from being displayed, or store the target data in a preset storage location, for example, an advertisement data list.
In yet another embodiment, after receiving the target data, if the target data is not the target data refused to be processed, normal processing operation is performed on the target data, for example, directly performing display operation, or forwarding the target data to the service processing module for subsequent data processing.
In another embodiment, if it is determined that the target data is the target data refused to be processed based on the feature information (e.g., URL) of the target data, the target data is deleted, and the feature information of the target data is recorded in the feature table as the second feature for comparison with the first feature thereof at the next time of receiving the request message.
Therefore, after the first feature of the request message is used for primarily screening whether the target data is received or not, whether the received target data is processed or intercepted is further determined based on analysis of the target data, and therefore the first feature of the request message which needs to be intercepted cannot be accurately filtered due to the fact that the feature table is incomplete is made up better.
In some embodiments, the determining whether the target data is a target data that is rejected for 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: a uniform resource address;
If the third feature is the same as the first feature, determining that the target data is the target data refused to process when the third feature is matched with a fourth feature which is known in advance and refuses to process the target data type;
and if the third feature is different from the first feature, determining that the target data is the target data refused to be processed when the third feature is matched with the fourth feature and/or the second feature.
In the embodiment of the disclosure, the third feature of the sender of the target data may be determined by parsing, and may include feature information such as URL and IP address. Here, since the sender of the request message may send the target data again by itself after receiving the response message, it may also send the target data by another sender. Thus, 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 to which the target data corresponds, 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 aligned with the fourth feature, which may be recorded in the third feature table. For example, the third feature table may be a return interception list for recording URLs of returned target data senders that need interception.
Here, the third feature table may be stored in the local device of the first device together with the first feature table, or may be stored in one storage location together with the first feature table of each application program for each application program.
In one embodiment, when the first feature table is called to compare the first feature with the second feature, if it is determined that the request message is not a request message for rejecting the response, a third feature table stored together with the first feature table is called at a storage location of the first feature table, for comparison after receiving the target data.
In another embodiment, the target data and the request message are characterized as different senders when the third characteristic of the target data is different from the first characteristic of the request message corresponding to the target data. Thus, the third feature is aligned 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 of the refusal process.
In still another embodiment, if the target data is the target data refused to be processed, 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 returned intercept list, the local advertisement URL list, and the cloud advertisement URL list, thereby enabling updating of the returned intercept list and the advertisement URL list.
In another embodiment, the recording of the returned interception list of the fourth feature may be configured to delete the expiration feature information periodically. For example, the storage time of each fourth feature in the returned interception list is recorded, and when the time interval between the storage time and the current time exceeds the preset interval, the corresponding fourth feature is deleted. In this way, timeliness of the fourth feature may be maintained and memory resources occupied by the fourth feature may be reduced.
In an embodiment, the matching of the third feature with the fourth feature may include that the third feature is identical to the fourth feature, or that the third feature has a preset association relationship with the fourth feature. Here, the preset association relationship may include: the similarity degree reaches a preset similarity condition, and/or the content association degree reaches a preset association degree condition, etc.
In yet another embodiment, if the third feature of the target data sender is determined, and the similarity existing between the data senders corresponding to the at least one fourth feature is represented to reach the preset similarity condition, it may be determined that the third feature matches the fourth feature.
Therefore, no matter whether the sender of the target data is changed compared with the sender of the request message, further matching screening can be performed based on the target data, so that the filtering precision of data needing interception such as 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 the response, determining that the request message is not a request message for rejecting the response;
The determining that the request message is a request message for refusal response when the first characteristic matches a second characteristic of a pre-known refusal response request message type includes:
and if the first characteristic is not matched with the fifth characteristic, determining that the request message is a request message of refusal response when the first characteristic is matched with a second characteristic of a type of the request message of refusal response known in advance.
In an embodiment of the present disclosure, the fifth characteristic feature characterizes the request message allowing the response, for example, may be recorded in a request message URL whitelist. And on the basis of the fifth feature in the white list, the first feature is matched and confirmed, so that the frequently received normal service request can be verified more quickly, and the corresponding target data can be confirmed to be received without the need of comparing the subsequent second feature.
In one embodiment, the method may further comprise: if the first feature is not matched with the fifth feature, comparing the first feature with a preset request interception list. The request interception list records a preset sender URL of the request message to be intercepted, and the sender URL 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 feature is matched with the fifth feature, returning a response message to a sender of the request message; if the first feature is not matched with the fifth feature, comparing the first feature with feature 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 comprise: and if the first feature is matched with the fifth feature, returning an empty message to the sender of the request message to prevent the sender from returning the target data.
In yet another embodiment, if the first feature does not match the fifth feature and does not match the feature information in the request intercept list, a reply message is returned to the request message sender and a determination is made as to whether to reject the responsive request message based on a comparison of the first feature and the second feature.
Here, the request interception list may be stored in the local 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 program for the request interception list of each application program.
In one embodiment, when the request interception list is called to perform feature comparison, if the request interception list is determined to be not 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 the first feature table and the second feature table are used for continuing to perform the feature comparison.
Thus, the request message is initially screened based on the fifth feature 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 illegal request message verification and filtering 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 an embodiment of the disclosure, if the third feature matches the fourth feature to indicate that the received target data is refused to be processed, and the first feature of the corresponding request message does not match the second feature, the request message corresponding to the refused target data is not considered as a request message refusing to be responded. Therefore, the corresponding first feature is added to the second feature, the recorded second feature can be updated in time, and the request message corresponding to the first feature can be regarded as the request message of the refusal response, so that the refusal response and the refusal of receiving the target data can be determined earlier compared with the verification of the target data stage, and the feature comparison verification can be conveniently and accurately carried out with high efficiency.
In some embodiments, the method further comprises:
if the first feature does not match the second feature, the first feature is added to the fifth feature.
In an embodiment of the disclosure, if the first feature does not match the second feature, the characterization request message is not a request message rejecting the response, the first feature of the request message may be added to the fifth feature. For example, the first feature is added to a white list for recording the fifth feature, so that the fifth feature is updated in time, further front-end feature comparison results are facilitated, the subsequent comparison process with the second feature can be omitted due to matching of the white list, and further quick verification of normal service requests is better achieved.
In one embodiment, if the first feature matches the second feature, the first feature is added to the request interception list, so that the identification of the request message refusing the response is further preceded, and the efficiency of next request message verification is better accelerated.
In some embodiments, the profile is stored in a first-in first-out FIFO queue having a fixed, preset capacity.
The first-in first-out (First Input First Output, FIFO) queue is used for storing the second features in the feature table, and when the number of the second features stored in the FIFO queue reaches the preset capacity, each new second feature is inserted, one second feature is deleted in turn according to the sequence of the storage moments of the second features in the queue, so that the stored second features are the latest second features with a certain number.
In one embodiment, the preset capacities of the FIFO queues corresponding to the first and second feature tables may be the same, 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 second features in a second feature table corresponding to the application program into the first feature table corresponding to the application program based on the application program corresponding to at least one first feature table contained in the first equipment at intervals of preset time.
In the embodiment of the disclosure, the first feature table in the first device is updated based on the second feature table of the second device every preset time period, 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 feature table corresponding to the application may be acquired from one server or from a server corresponding to each application.
In one embodiment, the second device may include a second feature table of an application program different from the first device, so that the application program corresponding to the first feature table in the first device is first determined, and then the second device is queried for the second feature table corresponding to the application program.
In another embodiment, the writing of the second features in the second feature table of each application program into the corresponding first feature table may be writing the second features newly added in the second feature table in the preset time period into the corresponding first feature table, or may be writing the second features contained in the second feature table and not recorded in the first feature table 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, including:
a first receiving unit 10 for receiving a request message;
A return 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 request message for rejecting a response by parsing the request message;
A second receiving unit 40 for receiving the target data when the request message is not a request message rejecting a response; and refusing to receive the target data when the request message is a request message refusing the response.
In some embodiments, the parsing unit 30 is specifically configured to:
And obtaining a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: a uniform resource address;
When the first characteristic matches a second characteristic of a pre-known reject response request message type, the request message is determined to be a reject response request message.
In some embodiments, the second feature is recorded in a feature table; the feature table includes: the first device locally stores a first profile and/or a second profile received 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 refused to be processed or not by analyzing the target data;
The apparatus further comprises:
A processing unit, configured to process the target data if the target data is not the target data that is rejected to be processed; and deleting the target data if the target data is the target data refused to be processed.
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: a uniform resource address;
If the third feature is the same as the first feature, determining that the target data is the target data refused to process when the third feature is matched with a fourth feature which is known in advance and refuses to process the target data type;
and if the third feature is different from the first feature, determining that the target data is the target data refused to be processed when the third feature is matched with the fourth feature and/or the second feature.
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 the response, determining that the request message is not a request message for rejecting the response;
The parsing unit 30 is specifically configured to:
and if the first characteristic is not matched with the fifth characteristic, determining that the request message is a request message of refusal response when the first characteristic is matched with a second characteristic of a type of the request message of refusal response known in advance.
In some embodiments, the apparatus further comprises:
the first adding unit is used for determining a request message corresponding to target data based on the target data corresponding to the third feature if the third feature is matched with 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:
And 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 profile 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 features in the second feature table corresponding to the application program into the first feature table corresponding to the application program based on the application program corresponding to at least one first feature table contained in the first equipment at intervals of preset time.
A specific example is provided below in connection with any of the above embodiments:
The embodiment of the disclosure provides an advertisement interception method, which comprises the steps of creating a VPN at a mobile phone end, acquiring all network requests through the VPN, directly sending the network requests after copying, comparing copied data with preset conditions, and intercepting returned advertisement data according to comparison results. The scheme can efficiently intercept the advertisement request of the APP in the mobile phone, thereby achieving the purpose of shielding advertisements.
As shown in fig. 3, in the advertisement interception method based on VPN according to the embodiment of the present disclosure, VPN is created at the mobile phone end, so that all network requests of the mobile phone can be obtained.
The transmission process comprises the following steps:
After the network request is obtained, the URL is extracted and it is determined whether the URL is in a network request whitelist (the list is a first-in first-out queue, has a fixed length, e.g. 200; and is only maintained in memory, with a reset being cleared each time the VPN process is restarted). If yes, directly sending a request; if not, it is determined whether it is in the request intercept list.
The request interception list, like the network request whitelist, is also a first-in first-out queue, having a fixed length, e.g., 100; and it is a memory value that clears the reset each time the VPN process is restarted. Intercepting if the URL in the last step exists in the request interception list, and returning false data based on the request; if not, a request is sent, and whether the URL is in the local advertisement list is judged in the interception request thread.
The local advertisement list is the advertisement URL which has been requested by the mobile phone, is maintained in the memory, is stored in a lasting mode, and is provided with a larger length limit, such as 500. If the URL in the last step exists in the local advertisement list, inserting the URL into a request interception list and returning the URL into the interception list; if not, judging whether the cloud advertisement is in the cloud advertisement blacklist.
The cloud advertisement blacklist is an advertisement blacklist stored in a local persistence mode, the cloud advertisement blacklist is synchronized with the cloud end regularly, and if the URL in the last step exists in the cloud advertisement blacklist, the URL is inserted into a request interception list, a return interception list and a local advertisement list; if not, the network whitelist is inserted.
The return process comprises the following steps:
If the return interception list is empty, not performing return interception; otherwise, the data returned by the network and the corresponding URL thereof need to be acquired.
Judging whether the URL is in a returned interception list (the list is only maintained in a memory, and reset can be cleared each time the VPN process is restarted), if so, intercepting and returning false data; if not, the data is returned normally.
Returning to the interception list requires recording the time each datum was stored and after a period of time (e.g., 10 seconds), the expired datum is deleted.
Here, the embodiment of the disclosure achieves a very high level of efficiency by setting the multi-level black-and-white list, and simultaneously maintains the memory occupation and the performance consumption at a low level.
When the VPN process is created and starts to intercept, the network whitelist is gradually filled, an interception list is requested, and an interception list is returned (the local advertisement list is not mentioned for a while). The interception at this time mainly depends on returning an interception list, but the interception is gradually advanced as time goes by, and the returned interception list is gradually emptied, so that the interception list is mainly requested.
The network requests of non-advertisement in the mobile phone are the most, the network whitelist is set to improve the efficiency of the requests, and the frequently occurring requests can finish the whole flow only by one judgment. The request intercept list also functions as well, with the request intercept list being populated. The advertisement request which frequently happens only needs to be judged twice, false data can be returned, and interception is completed.
The network whitelist, request intercept list, return intercept list are maintained only in memory, and the first two lists are limited in length. The APP used by the user in different time periods and different usage scenarios is different, and the triggered network request is also different. To gradually populate and update these lists, only short lists need to be retrieved in order to keep the normal requests and advertisement interception efficient.
The local advertisement list is a subset of the cloud advertisement blacklist, the cloud advertisement blacklist is also arranged to improve the retrieval efficiency, after all, the cloud advertisement blacklist is an advertisement URL extracted from a plurality of APP, the mobile phone possibly only comprises a plurality of APP, and each time the cloud advertisement blacklist is updated, the local advertisement list is updated by taking an intersection with the local advertisement list.
The cloud advertisement blacklist can be extracted from each APP, updated regularly and the mobile phone can be synchronized regularly under the 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 in any of the foregoing technical solutions.
The processor may include various types of storage medium, which are non-transitory computer storage media, capable of continuing to memorize information stored thereon after the electronic device is powered down.
The processor may be connected to the memory via a bus or the like for reading an executable program stored on the memory, e.g. capable of performing one or more of the methods described in the previous 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 applications, executable by the processing component. The application program stored in the memory may include one or more modules each corresponding to a set of instructions. Furthermore, the processing component is configured to execute instructions to perform any of the methods described above as applied to the electronic device, e.g. the methods described in one or more of the foregoing claims.
The electronic device may also include a power supply assembly 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.
Embodiments of the present disclosure provide a non-transitory computer-readable storage medium, which when executed by a processor of a computer, enables the computer to perform the request processing method of one or more of the foregoing 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 adaptations, uses, or adaptations of the disclosure following the general principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within 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 is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (20)

1. A method of request processing, applied to a first device, the method comprising:
receiving a request message; the request message is used for requesting to provide target data for the first device;
After receiving the request message, returning a response message to a sender of the request message; the response message is used for allowing the first device to allow the sender of the request message to send the target data;
Determining whether the request message is a request message refusing response or not by analyzing the request message; the determining whether the request message is a request message refusing response by analyzing the request message comprises the following steps: and obtaining a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: a uniform resource address; when the first characteristic is matched with a second characteristic of a pre-known refusal response request message type, determining that the request message is a refusal response request message;
Receiving the target data when the request message is not a request message rejecting a response;
And refusing to receive the target data when the request message is a request message refusing the response.
2. The method of claim 1, wherein the second feature is recorded in a feature table; the feature table includes: the first device locally stores a first profile and/or a second profile received from a second device.
3. The method according to claim 2, wherein the method further comprises:
After receiving the target data, determining whether the target data is the target data refused 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 deleting the target data if the target data is the target data refused to be processed.
4. A method according to claim 3, wherein said determining whether said target data is a target data refused to be processed by parsing said 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: a uniform resource address;
If the third feature is the same as the first feature, determining that the target data is the target data refused to process when the third feature is matched with a fourth feature which is known in advance and refuses to process the target data type;
and if the third feature is different from the first feature, determining that the target data is the target data refused to be processed when the third feature is matched with the fourth feature and/or the second feature.
5. The method according to claim 4, wherein 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 the response, determining that the request message is not a request message for rejecting the response;
The determining that the request message is a request message for refusal response when the first characteristic matches a second characteristic of a pre-known refusal response request message type includes:
and if the first characteristic is not matched with the fifth characteristic, determining that the request message is a request message of refusal response when the first characteristic is matched with a second characteristic of a type of the request message of refusal response known in advance.
6. The method according to claim 4, wherein 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.
7. The method of claim 5, wherein the method further comprises:
if the first feature does not match the second feature, the first feature is added to the fifth feature.
8. The method of claim 2, wherein the profile is stored in a first-in-first-out FIFO queue having a fixed, predetermined capacity.
9. The method according to claim 2, wherein the method further comprises:
and writing second features in a second feature table corresponding to the application program into the first feature table corresponding to the application program based on the application program corresponding to at least one first feature table contained in the first equipment at intervals of preset time.
10. A request processing apparatus, applied to a first device, the apparatus comprising:
A first receiving unit configured to receive a request message; the request message is used for requesting to provide target data for the first device;
A return 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 allowing the sender of the request message to send the target data by the first device;
the analyzing unit is used for determining whether the request message is a request message refusing response or not by analyzing the request message; the determining whether the request message is a request message refusing response by analyzing the request message comprises the following steps: and obtaining a first characteristic of a sender of the request message by analyzing the request message, wherein the first characteristic at least comprises: a uniform resource address; when the first characteristic is matched with a second characteristic of a pre-known refusal response request message type, determining that the request message is a refusal response request message;
A second receiving unit configured to receive the target data when the request message is not a request message rejecting a response; and refusing to receive the target data when the request message is a request message refusing the response.
11. The apparatus of claim 10, wherein the second characteristic is recorded in a characteristic table; the feature table includes: the first device locally stores a first profile and/or a second profile received from a second device.
12. The apparatus of claim 11, wherein the parsing unit is further configured to:
After receiving the target data, determining whether the target data is the target data refused to be processed or not by analyzing the target data;
The apparatus further comprises:
A processing unit, configured to process the target data if the target data is not the target data that is rejected to be processed; and deleting the target data if the target data is the target data refused to be processed.
13. The apparatus according to claim 12, 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: a uniform resource address;
If the third feature is the same as the first feature, determining that the target data is the target data refused to process when the third feature is matched with a fourth feature which is known in advance and refuses to process the target data type;
and if the third feature is different from the first feature, determining that the target data is the target data refused to be processed when the third feature is matched with the fourth feature and/or the second feature.
14. The apparatus of claim 13, 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 the response, determining that the request message is not a request message for rejecting the response;
the analysis unit is specifically configured to:
and if the first characteristic is not matched with the fifth characteristic, determining that the request message is a request message of refusal response when the first characteristic is matched with a second characteristic of a type of the request message of refusal response known in advance.
15. The apparatus of claim 13, wherein the apparatus further comprises:
the first adding unit is used for determining a request message corresponding to target data based on the target data corresponding to the third feature if the third feature is matched with the fourth feature; and adding the first characteristic of the request message corresponding to the target data to the second characteristic.
16. The apparatus of claim 14, wherein the apparatus further comprises:
And a second adding unit configured to add the first feature to the fifth feature if the first feature does not match the second feature.
17. The apparatus of claim 11, wherein the profile is stored in a first-in-first-out FIFO queue having a fixed, predetermined capacity.
18. The apparatus of claim 11, wherein the apparatus further comprises:
and the updating unit is used for writing the second features in the second feature table corresponding to the application program into the first feature table corresponding to the application program based on the application program corresponding to at least one first feature table contained in the first equipment at intervals of preset time.
19. An electronic device, comprising:
A memory for storing processor-executable instructions;
a processor connected to the memory;
wherein the processor is configured to perform the request processing method as provided in any of claims 1 to 9.
20. 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 9.
CN202210044412.XA 2022-01-14 2022-01-14 Request processing method and device, electronic equipment and storage medium Active CN114466075B (en)

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 CN114466075A (en) 2022-05-10
CN114466075B true 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 (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7082456B2 (en) * 2000-03-17 2006-07-25 Filesx Ltd. Accelerating responses to requests made by users to an internet
US20170024779A1 (en) * 2016-08-12 2017-01-26 Vertamedia LLC Computer-implemented method for online delivery of advertising content

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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
CN114466075A (en) 2022-05-10

Similar Documents

Publication Publication Date Title
CN107679718B (en) List allocation method, apparatus and computer-readable storage medium
WO2017202281A1 (en) Method and device for processing notification bar message
CN111555963B (en) Message pushing method and device, electronic equipment and storage medium
CN109495467B (en) Method and device for updating interception rule and computer readable storage medium
CN108063725B (en) Message pushing method
CN110677492B (en) Access request processing method and device, electronic equipment and storage medium
CN106254528B (en) Resource downloading method and caching device
CN108335079B (en) Conference reservation system, conference reservation message processing method, system and storage medium
CN115004673A (en) Message pushing method and device, electronic equipment and computer readable medium
CN106571942B (en) Configuration data updating method, client and server
CN109688094B (en) Suspicious IP configuration method, device, equipment and storage medium based on network security
CN108768835B (en) Mail analysis method, device, server and storage medium
CN103957306A (en) Method and device for sharing information between communication terminals
CN109246280B (en) Address book cloud processing method and device, computer equipment and readable storage medium
EP2169560A1 (en) E-mail processing apparatus, method of e-mail processing, e-mail processing program and e-mail processing system
CN105491239B (en) The hold-up interception method and device of junk information
CN110891056A (en) HTTPS request authentication method and device, electronic equipment and storage medium
CN110543604A (en) information processing method and device
CN108460042B (en) Page display method, related equipment and system
CN114466075B (en) Request processing method and device, electronic equipment and storage medium
CN103067495B (en) A kind of method of pushed information and device
CN107666431B (en) Bookmark communication message acquisition method and device
CN109842482B (en) Information synchronization method, system and terminal equipment
CN116961918A (en) Token acquisition method and device
US8874646B2 (en) Message managing system, message managing method and recording medium storing program for that method execution

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