Request processing method and apparatus, computer device, and storage medium

By using a sequence of discrimination rules stored on disk on the server side to quickly detect resource retrieval requests, identify and suppress requests from automated crawlers, the problem of identifying the source of resource retrieval requests is solved, ensuring the effectiveness of content delivery and optimizing server resource configuration.

CN116932849BActive Publication Date: 2026-05-01TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2022-04-01
Publication Date
2026-05-01

AI Technical Summary

Technical Problem

Existing technologies cannot effectively identify whether resource retrieval requests come from real users or automated crawlers, which negatively impacts the effectiveness of content delivery.

Method used

By pre-storing the rule description sequence of the discrimination rules on the server side, the field values ​​of resource fetch requests are quickly detected using disk, the target fetch requests are identified and suppressed, and multimedia resources for real users are returned.

Benefits of technology

Effectively identify and suppress requests from automated crawlers to avoid wasting resources, optimize server resource allocation, and ensure that the delivery effect of content items is not adversely affected.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116932849B_ABST
    Figure CN116932849B_ABST
Patent Text Reader

Abstract

This application discloses a request processing method, apparatus, computer device, and storage medium, belonging to the field of network technology. The method includes: responding to a resource retrieval request associated with a content item, reading a rule description sequence corresponding to at least one discrimination rule from a disk; detecting at least one field value of the resource retrieval request based on the rule description sequence corresponding to each of the at least one discrimination rule, obtaining a request detection result; and returning the multimedia resource associated with the content item only if the request detection result indicates that the resource retrieval request is not the target retrieval request. This application, by returning the corresponding multimedia resource only for resource retrieval requests that are detected as not being the target retrieval request, avoids returning the corresponding multimedia resource for every resource retrieval request, thereby effectively suppressing target retrieval requests and preventing the delivery effect of content items from being adversely affected by target retrieval requests.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a request processing method, apparatus, computer device, and storage medium. Background Technology

[0002] With the development of network technology, websites and clients can now support the placement of content items. For example, video content items can be placed in information streams such as video streams, or in the client's startup screen.

[0003] Currently, there exists an automated web crawler that simulates users to send a large number of seemingly legitimate resource fetch requests, generating numerous invalid fetches or clicks on the content being delivered, causing the content to fail to achieve the expected delivery results. Therefore, there is an urgent need for a method to quickly identify whether resource fetch requests originate from real users or automated web crawlers, enabling accurate identification and suppression of requests initiated by automated web crawlers, thereby ensuring that the delivery effect of content items is not adversely affected. Summary of the Invention

[0004] This application provides a request processing method, apparatus, computer device, and storage medium, which can accurately identify and suppress target fetch requests in resource fetching requests, thus preventing adverse effects on the delivery of content items. The technical solution is as follows:

[0005] On the one hand, a request processing method is provided, which includes:

[0006] In response to a resource fetch request associated with a content item, at least one rule description sequence corresponding to each discrimination rule is read from the disk. The rule description sequence is obtained by parsing the rule description statement of the corresponding discrimination rule. The discrimination rule is used to determine whether the resource fetch request is a target fetch request.

[0007] Based on the rule description sequence corresponding to each of the at least one discrimination rule, at least one field value of the resource fetching request is detected to obtain the request detection result;

[0008] The multimedia resource associated with the content item is returned only if the request detection result indicates that the resource fetch request is not the target fetch request.

[0009] On one hand, a request processing apparatus is provided, the apparatus comprising:

[0010] The reading module is used to read at least one rule description sequence corresponding to each discrimination rule from the disk in response to a resource fetch request associated with a content item. The rule description sequence is obtained by parsing the rule description statement of the corresponding discrimination rule. The discrimination rule is used to determine whether the resource fetch request is a target fetch request.

[0011] The detection module is used to detect at least one field value of the resource fetching request based on the rule description sequence corresponding to each of the at least one discrimination rule, and obtain the request detection result;

[0012] The return module is configured to return the multimedia resource associated with the content item only if the request detection result indicates that the resource fetch request is not the target fetch request.

[0013] In one possible implementation, the detection module includes:

[0014] A scanning unit is configured to scan the rule description sequence of any one of the at least one discrimination rule, wherein the rule description sequence includes at least one descriptive character of the discrimination rule;

[0015] The processing unit is used to process the at least one field value based on the scanned descriptive characters to obtain the detection result of the discrimination rule;

[0016] The determining unit is used to determine the requested detection result based on the detection results of each of the at least one discrimination rule.

[0017] In one possible implementation, the character type of the descriptive character includes data type and operator;

[0018] The processing unit includes:

[0019] Add a sub-unit, used to add the field value corresponding to the data type or the description character to the data stack when the character type of the scanned description character is a data type;

[0020] The processing subunit is used to process the top data of the data stack corresponding to the operator when the character type of the scanned description character is an operator.

[0021] The acquisition subunit is used to acquire the data stored in the data stack as the detection result of the discrimination rule after the processing of the descriptive characters in the rule description sequence is completed.

[0022] In one possible implementation, the added subunit is used for:

[0023] If the data type is a field name, read the field value corresponding to the field name from the resource fetch request and add the field value to the data stack; or,

[0024] If the data type is not a field name, the description character is stored in the variable corresponding to the data type, and the variable is added to the data stack.

[0025] In one possible implementation, the processing subunit is used for:

[0026] Determine the amount of data operated on by the operator;

[0027] Retrieve at least one piece of data that is located at the top of the data stack and meets the specified number of data items;

[0028] The operator is used to process the at least one piece of data, and the processed data is added to the data stack.

[0029] In one possible implementation, the determining unit is used to:

[0030] If the detection result of any discrimination rule indicates that the resource pull request is the target pull request, then the request detection result is determined to be that the resource pull request is the target pull request;

[0031] If the detection results of at least one of the discrimination rules all indicate that the resource fetch request is not the target fetch request, then the request detection result is determined to be that the resource fetch request is not the target fetch request.

[0032] In one possible implementation, the device further includes:

[0033] The word segmentation module is used to segment the rule description statement of any discrimination rule to obtain the original description sequence. The original description sequence is used to characterize the word segmentation in the rule description statement and the character type of the word segmentation.

[0034] The conversion module is used to perform reverse Polish notation on the original description sequence to obtain the rule description sequence of the discrimination rule.

[0035] In one possible implementation, the conversion module is used to:

[0036] Scan the word segments in the original description sequence;

[0037] If the character type of the segmented word is a data type, the segmented word is added to the rule description sequence;

[0038] If the character type of the segmented word is an operator, the segmented word is added to the operator stack;

[0039] If the operator stack is not empty after the original description sequence has been scanned, the operators in the operator stack are added to the rule description sequence.

[0040] In one possible implementation, the conversion module is further configured to:

[0041] If the priority of the operator is higher than the priority of the operator at the top of the operator stack, the word segment is added to the operator stack.

[0042] If the priority of the operator is lower than that of the operator at the top of the stack, the operator at the top of the stack is removed from the operator stack and added to the rule description sequence, and the word segmentation is added to the operator stack.

[0043] On one hand, a computer device is provided, the computer device including one or more processors and one or more memories, the one or more memories storing at least one computer program, the at least one computer program being loaded and executed by the one or more processors to implement the request processing method as described above.

[0044] On one hand, a storage medium is provided that stores at least one computer program, which is loaded and executed by a processor to implement the request processing method described above.

[0045] On one hand, a computer program product or computer program is provided, the computer program product or computer program comprising one or more lines of program code stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the computer device to perform the aforementioned request processing method.

[0046] The beneficial effects of the technical solutions provided in this application include at least the following:

[0047] By utilizing a rule description sequence of discrimination rules pre-stored on the disk, the field values ​​of resource fetch requests are detected to identify resource fetch requests that are not the target fetch requests. The corresponding multimedia resources are only returned to resource fetch requests that are not the target fetch requests. This avoids returning the corresponding multimedia resources to every resource fetch request, effectively suppressing target fetch requests and thus preventing the delivery effect of content items from being adversely affected by target fetch requests. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is a schematic diagram of the implementation environment of a request processing method provided in an embodiment of this application;

[0050] Figure 2 This is a flowchart of a request processing method provided in an embodiment of this application;

[0051] Figure 3 This is a flowchart of a request processing method provided in an embodiment of this application;

[0052] Figure 4 This is a schematic diagram of an information flow advertisement provided in an embodiment of this application;

[0053] Figure 5 This is a schematic diagram of a splash screen advertisement provided in an embodiment of this application;

[0054] Figure 6 This is a schematic diagram illustrating the principle of an anti-ad crawler strategy provided in an embodiment of this application;

[0055] Figure 7 This is a schematic diagram of an operation rule configuration interface provided in an embodiment of this application;

[0056] Figure 8 This is a schematic diagram of the structure of a request processing device provided in an embodiment of this application;

[0057] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0059] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0060] In this application, the term "at least one" means one or more, and "multiple" means two or more, for example, multiple first positions means two or more first positions.

[0061] The term "including at least one of A or B" in this application refers to the following situations: including only A, including only B, and including both A and B.

[0062] The user-related information (including but not limited to user device information, personal information, behavioral information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application, when applied to specific products or technologies using the methods of the embodiments of this application, are all obtained with the user's permission, consent, authorization, or full authorization from all parties, and the collection, use, and processing of related information, data, and signals must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the field values ​​in the content item crawling requests involved in this application are obtained under full authorization.

[0063] The terminology used in the embodiments of this application is explained below:

[0064] IP address (Internet Protocol Address): Also known as an Internet Protocol address. An IP address is a standardized address format provided by the IP protocol, which assigns a logical address to every network and every host on the Internet, thereby masking the differences in physical addresses.

[0065] UA (User Agent): This is a special string header that enables the server to identify the operating system and version, CPU (Central Processing Unit) type, browser and version, browser rendering engine, browser language, and browser plugins used by the requesting terminal. In this embodiment, the resource fetch request will carry a UA field, which contains at least one of the above-mentioned operating system and version, CPU type, browser and version, browser rendering engine, browser language, and browser plugins.

[0066] IMEI (International Mobile Equipment Identity): commonly referred to as the mobile phone serial number or "serial number," it is used to identify each individual mobile communication device, such as a mobile phone, within a mobile phone network.

[0067] Content item: refers to an information item used to carry specific content, which typically refers to a product, service, notice, news, etc. Content items can be presented in various formats, including video, audio, graphics, text, images, and web pages. In this application's embodiments, content items include advertising videos, promotional videos, advertising information, and promotional links.

[0068] Ad crawlers: For ad content items, there exists a program that can automatically send resource fetch requests to simulate the click behavior of real users on the content items. Typically, attackers use ad crawler automatons to run these programs, using automated tools to send a large number of seemingly legitimate resource fetch requests to the server. This generates a large number of invalid clicks on the ad content items, negatively impacting the ad campaign's effectiveness. Specifically, when the click volume of a content item reaches a certain threshold, many clicks come from ad crawler automatons rather than real users, resulting in the campaign's performance failing to meet expectations for the same click volume, significantly wasting and depleting the advertiser's advertising budget.

[0069] Reverse Polish Notation (RPN): Also known as postfix notation. RPN is a method of expression first proposed by Polish logician J. Lukasiewicz in 1929. In RPN, the operands are written first, followed by the operators; in other words, RPN is a postfix notation method that does not use parentheses and strictly follows left-to-right operations.

[0070] A stack is a linear data structure with restricted operations. Insertion and deletion operations are limited to the tail of the list. This tail is called the top of the stack, and the other end (the head of the list) is called the bottom of the stack. Inserting new data into a stack is called pushing, which places the new data on top of the existing data, making it the new top data. Deleting data from a stack is called popping, which removes the top data from the stack and makes its adjacent data the new top data.

[0071] The system architecture of the embodiments of this application will be described below.

[0072] Figure 1 This is a schematic diagram illustrating the implementation environment of a request processing method provided in an embodiment of this application. See also... Figure 1 The implementation environment includes terminal 101 and server 102:

[0073] Terminal 101 is used to provide services related to content items, including: accessing content items such as playing advertising videos, opening advertising web pages, receiving promotional emails, and displaying promotional links, as well as purchasing goods or services related to content items, downloading promotional clients, and delivering promotional information or notifications.

[0074] The terminal 101 has an application installed and running that supports displaying content items. Optionally, the application includes at least one of the following: a browser application, a news application, an audio / video application, a short video application, a live streaming application, an information browsing application, a photo editing application, a camera application, an instant messaging application, a content sharing application, or a social application.

[0075] To illustrate, when a user launches the application on terminal 101, since the advertiser may display a splash screen ad on the launch screen, terminal 101 will send a resource retrieval request to server 102 to retrieve the splash screen ad displayed on the launch screen (equivalent to retrieving the display resources of the splash screen ad). The splash screen ad here is an example of a content item. At this time, the resource retrieval request is used to request the multimedia resources of the content item itself. Furthermore, if the user performs a triggering action (such as clicking) on ​​the splash screen ad in the startup interface, the terminal 101 will send another resource retrieval request to the server 102. This resource retrieval request is used to request other multimedia resources associated with the content item. For example, the multimedia resource is a UI (User Interface) associated with the content item. The UI is also called the landing page, landing page, or guide page of the content item. The UI is provided as a jump interface within the application, or as a webpage that switches to a browser application. Alternatively, the multimedia resource may also include a video associated with the content item. For example, the splash screen ad plays a part of the video, while the multimedia resource refers to the entire video. This application embodiment does not specifically limit this.

[0076] To illustrate, after a user launches the application on terminal 101, an information stream (such as a video stream, feed stream, etc.) is provided in the main interface of the application. The information stream usually includes recommended videos and advertising videos. Therefore, when the application displays the information stream in the main interface, it needs to retrieve not only recommended videos but also advertising videos. The advertising videos here are also an example of content items. For example, terminal 101 sends a resource retrieval request to server 102 to retrieve the advertising videos displayed in the information stream (equivalent to retrieving the video resources of the advertising videos). Optionally, to conserve communication resources, when retrieving advertising videos displayed in the information stream, since the user may not be interested in the advertising video and the terminal 101 cannot predict whether the user will click on the advertising video, the terminal 101 does not need to retrieve all the video resources of the advertising video. It can retrieve only the cover and the first N frames (N≥1, for example, the first 10 frames) of the advertising video. Furthermore, if the user performs a triggering action (such as clicking) on ​​any advertising video in the information stream, the terminal 101 will send another resource retrieval request to the server 102. This resource retrieval request is used to request the retrieval of all video resources of the advertising video.

[0077] Terminal 101 and server 102 are connected via a wired or wireless network.

[0078] Server 102 is a computer device used to provide background services for the aforementioned applications. Server 102 includes at least one of the following: a single server, multiple servers, a cloud computing platform, or a virtualization center. Optionally, server 102 undertakes the primary computing work, and terminal 101 undertakes the secondary computing work; or, server 102 undertakes the secondary computing work, and terminal 101 undertakes the primary computing work; or, terminal 101 and server 102 collaborate to perform computing work using a distributed computing architecture.

[0079] Optionally, server 102 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0080] In some embodiments, taking an advertising scenario as an example, an advertisement is an exemplary description of a content item. The advertiser will place advertisements in some applications. When users use the application program, they can view the advertisements in the UI interface or the startup screen. For example, the advertisement may be an advertising video embedded in the information stream, or a splash screen advertisement displayed in the startup screen, or an advertising pop-up in the interactive interface, etc. The terminal 101 sends a resource retrieval request to the server 102 to request the server to return multimedia resources associated with the content item, i.e., the advertisement. For example, in the advertisement loading stage, the multimedia resources requested by the resource retrieval request refer to the content item to be displayed, i.e., the advertisement to be displayed. Or, for example, in the advertisement interaction stage, the multimedia resources requested by the resource retrieval request refer to the display resources of the UI interface, web page, and other details associated with the content item.

[0081] However, attackers typically use ad crawler automatons to run programs that can automatically trigger resource fetch requests (i.e., ad crawlers) to simulate real user fetching or clicking behavior on ads, creating a large number of invalid fetches or clicks on the displayed ads. Therefore, this application provides a request processing method that can accurately identify on the server 102 side whether the received resource fetch request is triggered by a real user or by an ad crawler automaton. In other words, it can identify whether the resource fetch request is triggered by a real user or by an ad crawler (i.e., a target fetch request) triggered by some automated program, thereby ignoring the identified target fetch requests and only returning the multimedia resources associated with the content item for requests triggered by real users.

[0082] Optionally, terminal 101 refers to one of a plurality of terminals, and the device types of terminal 101 include, but are not limited to: in-vehicle terminal, television, smartphone, smart speaker, smartwatch, tablet computer, smart voice interaction device, smart home appliance, aircraft, e-book reader, MP3 (Moving Picture Experts Group Audio Layer III) player, MP4 (Moving Picture Experts Group Audio Layer IV) player, laptop computer, or desktop computer. The following embodiments use a smartphone as an example.

[0083] Those skilled in the art will understand that the number of terminals 101 described above can be more or less. For example, there may be only one terminal 101, or there may be dozens or hundreds of terminals 101, or even more. This disclosure does not limit the number or type of terminals 101.

[0084] Figure 2 This is a flowchart of a request processing method provided in an embodiment of this application. See also... Figure 2 This embodiment is executed by a computer device. Taking the computer device as a server as an example, this embodiment includes the following steps:

[0085] 201. In response to a resource fetch request associated with a content item, the server reads at least one rule description sequence corresponding to each discrimination rule from the disk. The rule description sequence is obtained by parsing the rule description statement of the corresponding discrimination rule. The discrimination rule is used to determine whether the resource fetch request is the target fetch request.

[0086] The content items involved in this application's embodiments refer to information items used to carry specific content. Specific content includes goods, services, notices, announcements, information, etc. to be exposed. For example, content items are various advertising videos, promotional videos, advertising information, promotional links, announcement messages, search engine search results, marketing emails, etc. Optionally, the presentation form of content items includes video, audio, graphics, text, images, web pages, etc. This application's embodiments do not specifically limit the content items and their presentation forms.

[0087] The resource retrieval request involved in this application embodiment refers to a resource retrieval request associated with a content item. In other words, the resource retrieval request is used to request multimedia resources associated with the content item. The multimedia resources include, but are not limited to: the content item to be displayed (i.e., the display resources of the content item itself), the UI interface associated with the content item (such as a webpage or interactive interface), the video associated with the content item, the audio associated with the content item, the image associated with the content item, the text associated with the content item, etc. The UI interface associated with the content item is also called the landing page, landing page, or guide page of the content item. The UI interface is provided as a jump interface within the application or as a webpage that switches to a browser application. For example, the UI interface is the details page, introduction page, purchase page, etc. of the product or service associated with the content item. This application embodiment does not specifically limit this.

[0088] The discrimination rules involved in this application's embodiments refer to preset rules used to determine whether a resource retrieval request is a target retrieval request. A target retrieval request refers to a resource retrieval request that is not triggered by a real user. For example, a target retrieval request is a resource retrieval request automatically triggered in batches by an automated web crawler. In an advertising scenario, the automated web crawler is provided as an advertising web crawler automaton. In this case, the target retrieval request is a resource retrieval request automatically triggered in batches by the advertising web crawler automaton. In short, the discrimination rules are used to determine whether a resource retrieval request is triggered by a real user or by an automated web crawler. Typically, at least one discrimination rule is used when performing request detection. These discrimination rules are preset on the server side by users (such as operations personnel). For example, the discrimination rules set by operations personnel are also called operations rules.

[0089] In some embodiments, in response to any received request, the server parses the header field of the request. When the header field carries a request identifier for a resource fetch request, it determines that the request is a resource fetch request. Then, in response to any resource fetch request, it reads the rule description sequence corresponding to each of the at least one discrimination rule from the data file on the disk.

[0090] It should be noted that the rule description sequence for any discrimination rule stored in the aforementioned disk data file is generated after the user sets the rule description statement for that discrimination rule. First, the rule description statement is written to the database. Then, the rule description statement stored in the database is parsed and transformed in the background to obtain the corresponding rule description sequence. Finally, the transformed rule description sequence is written to the disk data file for persistent storage. Since database throughput is typically low, directly storing the rule description sequence obtained from the user-set rule description statement after background parsing and transformation into the database, and then having the online access system on the server side read the rule description sequence from the database, would result in the database throughput being insufficient to meet the actual business needs of the online access system when it receives a large number of resource fetch requests simultaneously. Therefore, adding a disk data file as an intermediary can be applied to some high-throughput scenarios to improve the mismatch between database throughput and the throughput requirements of the online access system.

[0091] 202. Based on the rule description sequence corresponding to each of the at least one discrimination rule, the server detects at least one field value of the resource retrieval request and obtains the request detection result.

[0092] In some embodiments, the server parses the resource fetch request and obtains the values ​​of each field of the resource fetch request. Then, it uses the rule description sequence corresponding to each of the at least one discrimination rule obtained in step 201 above to detect at least one field value obtained by parsing, so as to obtain a request detection result. The request detection result is used to indicate whether the resource fetch request detected this time is the target fetch request.

[0093] 203. The server returns the multimedia resource associated with the content item only if the request detection result indicates that the resource fetch request is not the target fetch request.

[0094] In some embodiments, when a request detection result is obtained, the server only returns the multimedia resource associated with the corresponding content item for resource fetch requests that are not the target fetch request; otherwise, for the detected target fetch request, the server ignores or discards the target fetch request and does not return the multimedia resource associated with the corresponding content item.

[0095] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0096] The method provided in this application embodiment uses a rule description sequence of discrimination rules pre-stored in the disk to detect the field values ​​of resource fetch requests, so as to identify resource fetch requests that are not the target fetch requests, and only return the corresponding multimedia resources to resource fetch requests that are not the target fetch requests. This can avoid returning the corresponding multimedia resources to any resource fetch request, effectively suppressing the target fetch requests, thereby avoiding the adverse effects of the target fetch requests on the delivery effect of content items.

[0097] Furthermore, since the detected target fetch requests can be ignored or discarded without returning the corresponding multimedia resources, the waste of server computing resources is avoided, and the server's resource configuration is optimized.

[0098] In the above embodiments, the processing flow of suppressing target fetch requests on the server side was briefly introduced. In the embodiments of this application, the server will detect resource fetch requests and obtain the corresponding request detection results in detail.

[0099] Figure 3 This is a flowchart of a request processing method provided in an embodiment of this application. See also... Figure 3 This embodiment is executed by a computer device. Taking the computer device as a server as an example, this embodiment includes the following steps:

[0100] 301. In response to a resource fetch request associated with a content item, the server reads at least one rule description sequence corresponding to each discrimination rule from the disk. The rule description sequence is obtained by parsing the rule description statement of the corresponding discrimination rule. The discrimination rule is used to determine whether the resource fetch request is the target fetch request.

[0101] In some embodiments, after the user side configures the rule description statements for each of the at least one discrimination rule, the rule description statements for the at least one discrimination rule are written to the database. The server side then generates a rule description sequence corresponding to each of the at least one discrimination rule based on the rule description statements, and stores the rule description sequence for the at least one discrimination rule in a data file on the disk. Subsequently, when the server receives a resource retrieval request associated with a content item from any terminal, it can directly read the rule description sequence for the at least one discrimination rule from the data file on the disk. This allows the online access system for content items to read the rule description sequence from a disk that supports a higher throughput, instead of reading it from a disk with a lower throughput, thus adapting to scenarios with higher throughput. Furthermore, when processing resource retrieval requests in real time, it is not necessary to perform the parsing and conversion process for the rule description statements every time a request is received, further improving the response efficiency for resource retrieval requests.

[0102] In some embodiments, since users may not have a high level of programming language skills when configuring at least one discrimination rule, it is generally supported for users to input rule description statements that are closer to natural language. For example, suppose a discrimination rule is: if the device ID (identification) carried in the resource fetch request is "ABC12345A1BB12313212312312313" and the IP address is "156.7.12.3", it belongs to the target fetch request. Then the rule description statement of the above discrimination rule can be expressed as the following expression:

[0103] IMEI in["ABC12345A1BB12313212312312313"]and IP in["156.7.12.3"]

[0104] However, while the aforementioned rule description statements are easy for users to understand and configure, when applied to the online access system for content items on the server side, the online access system needs to segment the rule description statements based on spaces (i.e., word segmentation), and then scan each segmented substring from left to right character by character. Based on the scan results, semantic understanding of each substring is performed to achieve an overall semantic understanding of the rule description statements. This results in the rule description statements of each discrimination rule not being processed in parallel, but only serially. This makes the parsing and processing time of each discrimination rule description statement very long, greatly reducing the detection efficiency of each resource fetch request. It is not suitable for some high-throughput, low-latency scenarios, because if the detection stage of whether it is the target fetch request takes longer, it will greatly increase the timeout rate of real user resource fetch requests (i.e., resource fetch requests that are not the target fetch requests), thus affecting the experience of real users browsing multimedia resources associated with content items.

[0105] Furthermore, due to the lack of generality among substrings in the rule expressions of natural language, the rule description statements in natural language form can only have their specially designed parsing and processing logic embedded into the program code through "hard coding," rather than forming a general processing logic for the rule description statements. As the number of discrimination rules increases, the processing logic of each discrimination rule's description statement lacks generality, resulting in an increasingly large amount of program code that needs to be maintained, leading to higher maintenance costs. This, in turn, results in increasingly higher development and maintenance manpower costs for the functional module that detects whether a request is for the target.

[0106] In view of this, embodiments of this application provide a preprocessing method for rule description statements of any discrimination rule. Optionally, this preprocessing process is executed before the user completes the configuration of the rule description statement for the discrimination rule and uploads it to the cloud database. That is, the rule description statement configured by the user is already a converted rule description sequence when stored in the cloud database. Alternatively, this preprocessing process is executed after the user completes the configuration of the rule description statement for the discrimination rule and uploads it to the cloud database, and before the data file imported from the cloud database to the disk. That is, after the user uploads the configured rule description statement to the cloud database, the cloud database converts the rule description statement into a rule description sequence and stores it in the data file on the disk. Embodiments of this application do not specifically limit the execution timing of the preprocessing process.

[0107] In some embodiments, during the preprocessing process, for any discrimination rule, the server performs word segmentation on the rule description statement of the discrimination rule to obtain an original description sequence, which is used to characterize the tokens in the rule description statement and the character type of the tokens.

[0108] In some embodiments, the character types of tokens in the rule description statement are defined as follows: character types are divided into two categories: operators and data types. Operators refer to data that do not indicate data themselves but only define the operational relationship between data, while data types refer to the specific type of data that the token is. For example, operators include: Opera_AND (representing "AND"), Opera_OR (representing "OR"), Opera_Eq (representing "equal"), Opera_IN (representing "belongs to"), etc. Data types include: Var (indicating a field name carried in a resource fetch request), Num (indicating a numerical value), Str (indicating a string), Array (indicating a list), etc. It should be noted that the above examples of operators and data types are merely illustrative examples, and this application does not specifically limit the operators and data types.

[0109] Based on the above definition of character types for word segmentation, each rule description statement can be segmented. That is, after segmenting the rule description statement to obtain at least one word, the character type corresponding to each word is determined, and each word and its character type are combined to form a description character. The sequence of each description character is called the original description sequence obtained after word segmentation, also known as the tokenized sequence of the rule description statement.

[0110] The following discrimination rule is used as an example: When the IMEI identifier carried in the resource fetch request is "ABC12345A1BB12313212312312313" and the IP address is "156.7.12.3", the resource fetch request is the target fetch request. The rule description statement for this discrimination rule is as follows:

[0111] IMEI in["ABC12345A1BB12313212312312313"]and IP in["156.7.12.3"]

[0112] After segmenting the above rule statement into words according to spaces, we get 7 words: “IMEI”, “in”, “[“ABC12345A1BB12313212312312313”]”, “and”, “IP”, “in” and “[“156.7.12.3”]”.

[0113] For the above 7 word segments, the character type of each word segment is determined. It can be seen that: the character type of "IMEI" is data type Var (field name is IMEI), the character type of "in" is operator Opera_IN (belongs to relation), the character type of "["ABC12345A1BB12313212312312313"]" is data type Array and the data type of the elements in the Array is Str (a list of string elements), the character type of "and" is operator Opera_AND (logical AND relation), the character type of "IP" is data type Var (character name is IP), the character type of "in" is operator Opera_IN (belongs to relation), and the character type of "["156.7.12.3"]" is data type Array and the data type of the elements in the Array is Str (a list of string elements).

[0114] After determining the character type of each word, the original description sequence corresponding to the above rule description statement, i.e., the tokenized sequence, can be generated:

[0115] [Var(IMEI),Oper_IN,Array(Str("ABC12345A1BB12313212312312313")),Oper_AND,Var(IP),Oper_IN,Array(Str("156.7.12.3"))]

[0116] In the above process, by converting the rule description statement into a raw description sequence, the rule description statement, which is in the form of natural language, can be transformed into a raw description sequence composed of token description characters. This is equivalent to turning a string described in natural language into a sequence composed of a series of self-interpretable token description characters. At this time, the online access system only needs to traverse the raw description sequence from left to right once and combine the semantics of each token description character to obtain the semantic information of the current discrimination rule. This greatly speeds up the server's semantic parsing speed of the discrimination rule.

[0117] In some embodiments, the original description sequence of each discrimination rule is directly used as the rule description sequence to detect resource pull requests and obtain request detection results. Since each token description character in the original description sequence is easy for computer systems to understand and each token description character is self-explanatory, it can simplify the code logic for parsing discrimination rules and reduce the time spent on parsing and understanding discrimination rules.

[0118] In other embodiments, after obtaining the original description sequence, the original description sequence is further transformed using Reverse Polish Notation (RPN) to obtain the rule description sequence of the discrimination rule. This rule description sequence is essentially a reorganization of the original description sequence. That is, the rule description sequence does not add, modify, or delete the token description characters in the original description sequence, but only adjusts the order of the token description characters in the original description sequence (i.e., reorders them), so that the original description sequence is converted into the corresponding RPN expression (i.e., the rule description sequence). This can reduce the time spent parsing and understanding the discrimination rule, and further solve the problem of needing to hard-code the original description sequence. Therefore, by using the rule description sequence after RPN transformation, the problem of hard coding is solved, and serialized processing can be converted into parallel processing, which greatly improves the detection rate of resource fetching requests.

[0119] In some embodiments, during the reverse Polish notation process described above, a priority is determined for each operator, an operator stack and a rule description sequence (i.e., a result token sequence, used to store the original description sequence after reverse Polish notation) are constructed, and then it is ensured that the closer the operator in the operator stack is to the top of the stack during the reverse Polish notation process, the higher its priority.

[0120] Illustratively, assuming the operators include: Opera_AND, Opera_OR, Opera_Eq, and Opera_IN, then the following operation interpretations and precedence are defined for each of these operators:

[0121] 1) Opera_IN: This query retrieves a specified data item from a collection. If the item is found, it returns True; otherwise, it returns False. This is the highest priority query.

[0122] 2) Opera_Eq: This function checks if two data items are equal. It returns True if the two data items are equal and False if the two data items are not equal. It has the highest priority.

[0123] 3) Operate_AND: Represents a logical AND operation, which has the second precedence.

[0124] 4)Oper_OR: Represents the logical "OR" operation, which belongs to the second priority.

[0125] The first priority is higher than the second priority. It should be noted that the above is only an illustrative explanation of how to set the priority of operators, and should not constitute a specific limitation on the types and priority levels of operators.

[0126] Based on the operator priority defined above, the following Reverse Polish Notation (RPN) operation is performed on the original description sequence of any discrimination rule: scan the tokens in the original description sequence. It should be noted that since the RPN itself is a reordering of the token description characters in the original description sequence to meet the requirements of "no parentheses, strict adherence to left-to-right postfix notation, and operation quantity written first and operator written last", the server needs to scan each token in the original sequence from left to right.

[0127] Next, for any scanned word segment (i.e. the current word segment), the character type of the word segment is identified, and corresponding processing is performed according to the different character types. Optionally, if the character type of the word segment is a data type, the word segment is added to the rule description sequence; or, if the character type of the word segment is an operator, the word segment is added to the operator stack.

[0128] In some embodiments, to ensure that the top operator in the operator stack has the highest priority, if the character type of the scanned segment is an operator, the priority of the currently scanned operator needs to be compared with the priority of the top operator to determine whether the top operator should be popped from the stack before the currently scanned operator is pushed onto the stack. In other words, if the priority of the currently scanned operator is higher than the priority of the top operator in the operator stack, or if the operator stack is empty, the segment (i.e., the currently scanned operator) is directly added to the operator stack, and the newly pushed segment is the operator with the highest priority in the stack. If the priority of the operator is lower than the priority of the top operator, the top operator needs to be removed from the operator stack and added to the rule description sequence, and then the segment (i.e., the currently scanned operator) is added to the operator stack. This is equivalent to popping the top operator from the stack and adding it to the rule description sequence before pushing the current segment onto the stack, to avoid the situation where the newly pushed segment has a lower priority than the previous operator.

[0129] After scanning each word in the original description sequence from left to right, if the operator stack is empty, the final rule description sequence can be obtained directly, and the resources occupied by the operator stack can be released. If the operator stack is not empty, at least one operator needs to be popped from the operator stack in sequence, and then added to the rule description sequence in the popping order, until all operators in the operator stack have been popped and added to the rule description sequence, thus obtaining the final rule description sequence and releasing the resources occupied by the operator stack.

[0130] To illustrate, the reverse Polish notation process is explained using the original description sequence corresponding to the above discrimination rule as an example. The original description sequence is represented as follows:

[0131] [Var(IMEI),Oper_IN,Array(Str("ABC12345A1BB12313212312312313")),Oper_AND,Var(IP),Oper_IN,Array(Str("156.7.12.3"))]

[0132] At this point, an operator stack is constructed (initially empty). The original description sequence is scanned from left to right. First, the first segment "Var(IMEI)" is scanned. Since the character type of "Var(IMEI)" is the data type Var, "Var(IMEI)" is added to the rule description sequence, which is represented as [Var(IMEI)]. Next, the second segment "Oper_IN" is scanned. Since the character type of "Oper_IN" is the operator Operator Operator, and the operator stack is empty at this time, "Oper_IN" is pushed directly onto the stack. Then, the third segment "A" is scanned. Since the character type of "Array(Str("ABC12345A1BB12313212312312313"))" is Array, it is added to the rule description sequence. At this point, the rule description sequence is represented as [Var(IMEI),Array(Str("ABC12345A1BB12313212312312313"))". 12313”))]; Next, continue scanning the 4th word segment “Oper_AND”. Since the current operator “Oper_AND” belongs to the second priority, and the operator stack currently only has one operator, namely the top operator “Oper_IN”, which belongs to the first priority, the priority of the current operator “Oper_AND” is lower than the priority of the top operator “Oper_IN”. After popping the top operator “Oper_IN” from the stack, add it to the rule description sequence. At this time, the rule description sequence is represented as [Var(IMEI),Array(Str(“ABC12345A1BB1231321231”))]; Then, continue scanning the 4th word segment “Oper_AND”. Since the current operator “Oper_AND” belongs to the second priority, and the operator stack currently only has one operator, namely the top operator “Oper_IN”, which belongs to the first priority, the priority of the current operator “Oper_AND” is lower than the priority of the top operator “Oper_IN”. After popping the top operator “Oper_IN” from the stack, add it to the rule description sequence. At this time, the rule description sequence is represented as [Var(IMEI),Array(Str(“ABC12345A1BB1231321231”))]; [2312313”)),Oper_IN], and then push the current operator “Oper_AND” onto the stack. At this time, the current operator “Oper_AND” becomes the new top operator of the stack. Next, continue scanning the 5th word “Var(IP)”. Since the character type of “Var(IP)” is data type Var, add “Var(IP)” to the rule description sequence. At this time, the rule description sequence is represented as [Var(IMEI),Array(Str(“ABC12345A1BB12313212312312313”)),Oper_IN,Var(IP)];Next, the 6th segment "Oper_IN" is scanned. Since the current operator "Oper_IN" has the highest priority, and the operator stack currently only has one operator, the top operator "Oper_AND" which has the second highest priority, the current operator "Oper_IN" has a higher priority than the top operator "Oper_AND". Therefore, the current operator "Oper_IN" is pushed onto the stack, and it becomes the new top operator. Next, the 7th segment "Array(Str("156.7.12.3"))" is scanned. Since the character type of "Array(Str("156.7.12.3"))" is Array, it is added to the rule description sequence. The rule description sequence is now complete. This is represented as [Var(IMEI),Array(Str(“ABC12345A1BB12313212312312313”)),Oper_IN,Var(IP),Array(Str(“156.7.12.3”))]; Finally, since all 7 tokens in the original description sequence have been scanned and processed, but the operator stack is not empty at this point, it still includes a top operator “Oper_IN” and a bottom operator “Oper_AND”. According to the stack's "last-in, first-out" property, the top operator “Oper_IN” is popped from the stack and added to the rule description sequence, and then the bottom operator “Oper_AND” (which has become the new top operator after “Oper_IN” is popped from the stack) is popped from the stack and added to the rule description sequence. Obviously, the final rule description sequence is represented as the following Reverse Polish notation:

[0133] [Var(IMEI),Array(Str("ABC12345A1BB12313212312312313")),Oper_IN,Var(IP),Array(Str("156.7.12.3")),Oper_IN,Oper_AND]

[0134] In step 301 above, one possible implementation is provided for obtaining the rule description sequence corresponding to each of at least one discrimination rule. Optionally, the disk itself stores the rule description sequence after reverse Polish notation. Then, the server can directly read the rule description sequence of the at least one discrimination rule to determine the semantic information of the at least one discrimination rule. Optionally, the disk stores the original description sequence of the at least one discrimination rule. Then, after the server reads the original description sequence of the at least one discrimination rule, it performs reverse Polish notation on any original description sequence in real time to obtain the corresponding rule description sequence, and puts the rule description sequence into the detection process in step 302 below.

[0135] 302. For any one of the at least one discrimination rules, the server scans the rule description sequence of the discrimination rule, the rule description sequence including at least one description character of the discrimination rule.

[0136] In some embodiments, for any discrimination rule, after obtaining the rule description sequence of the discrimination rule, the rule description sequence of the discrimination rule is scanned, and then step 303 is performed to determine the detection result of this discrimination rule. After summarizing the detection results of at least one discrimination rule, the final request detection result for the current resource fetch request can be determined. Optionally, when scanning the rule description sequence of any discrimination rule, each description character contained in the rule description sequence is scanned sequentially from left to right.

[0137] 303. Based on the scanned description characters, the server processes at least one field value of the resource fetch request accordingly to obtain the detection result of the discrimination rule.

[0138] In some embodiments, since the character type of the description character includes both data type and operator, data type can specify a specific type of data, while operator can only perform operations on existing data and cannot carry data. Therefore, the server has different processing logic depending on the character type of the description character currently scanned in the rule description sequence.

[0139] In some embodiments, during the detection process of a single discrimination rule, the server stores at least one field value obtained from parsing the resource fetch request in a variable req and initializes a data stack. For example, a data stack of fixed size is constructed (e.g., the size of the data stack is 10, but other values ​​can also be used). This can improve the detection efficiency of whether the resource fetch request is the target fetch request. Furthermore, when the rule description sequence of each discrimination rule is the original description sequence after reverse Polish notation, step 303 can create multiple processes for different discrimination rules to achieve parallel processing without affecting the detection results of different discrimination rules.

[0140] In some embodiments, for any description character (i.e., the current description character) scanned from left to right in the rule description sequence, if the character type of the scanned description character is a data type, the field value corresponding to the data type or the description character is added to the data stack. This is further divided into two cases:

[0141] In the first scenario, if the data type is a field name, the field value corresponding to that field name is read from the resource fetch request, and the field value is added to the data stack. In other words, if the character type of the current description character is data type Var (i.e., field name), then the field value corresponding to that field name needs to be read from the variable req, and then the read field value is pushed onto the data stack. For example, for the description character "Var(IMEI)", Var represents a value that needs to be retrieved from the variable req, while Var(IMEI) represents a value that needs to be retrieved from the variable req. In this case, the field value of the IMEI field is retrieved from the variable req, and the field value of the IMEI field is pushed onto the data stack.

[0142] In the second scenario, if the data type is not a field name, the descriptive character is stored in the variable corresponding to that data type, and the variable is added to the data stack. In other words, if the character type of the current descriptive character is a data type and is not Var (it can be any data type other than Var), then a variable with the same data type as the descriptive character needs to be constructed. For example, for the descriptive character "Array(Str("156.7.12.3")), a string data type needs to be constructed first to store "156.7.12.3", then a list data type needs to be constructed, the string data type above needs to be added to the list data type, and the processed list data (i.e., the variable corresponding to the data type) needs to be pushed onto the data stack.

[0143] In some embodiments, for any description character (i.e. the current description character) scanned from left to right in the rule description sequence, if the character type of the scanned description character is an operator, the top data of the data stack corresponding to the operator is processed. Optionally, since the operator may operate on one or more top data at a time, the server first determines the number of data operated by the operator, then takes out at least one data at the top of the data stack that meets the number of data, and finally uses the operator to process the at least one data and adds the processed data to the data stack.

[0144] Schematic description of the rule sequence after the above reverse Polish notation is completed:

[0145] [Var(IMEI),Array(Str("ABC12345A1BB12313212312312313")),Oper_IN,Var(IP),Array(Str("156.7.12.3")),Oper_IN,Oper_AND]

[0146] For the first descriptor character "Var(IMEI)", since it is a data type and the field name Var, the field value of the IMEI field is retrieved from the variable req and pushed onto the data stack. Next, for the second descriptor character "Array(Str("ABC12345A1BB12313212312312313")), since it is a data type and not the field name Var, "Array(Str("ABC..."))" is directly used. 12345A1BB12313212312312313”))” is pushed onto the data stack; next, for the third descriptor character “Oper_IN”, since it is an operator and the number of data being operated on is 2, the two data items at the top of the data stack, “IMEI field value” and “Array(Str(“ABC12345A1BB12313212312312313”))”, are popped from the stack, and the operator “Oper_IN” is executed on these two data items. The operation indicated by "_IN" is to "search for a specified data in a set, returning True if found, and False if not found". Here, the list "Array(Str("ABC12345A1BB12313212312312313"))" is used as the set, and the "value of the IMEI field" is used as the specified data. Therefore, the "value of the IMEI field" is searched in the list "Array(Str("ABC12345A1BB12313212312312313"))". If the latter is found in the list, it means that the latter can match the corresponding element in the list, so the result True is returned, and the returned result True (i.e., the processed data) is pushed onto the data stack. Conversely, if the latter is not found in the list, it means that the latter cannot match any element in the list, so the result False is returned, and the returned result False (i.e., the processed data) is pushed onto the data stack.

[0147] The server repeats the above operation. Once all the descriptive characters in the rule description sequence have been processed, it means that each descriptive character in the rule description sequence has been scanned and processed from left to right. At this point, there must only be one boolean data that is either True or False left in the data stack. The data stored in the data stack is then retrieved as the detection result of the discrimination rule. For example, when the remaining data in the data stack is True, the detection result of this discrimination rule is determined to be "the current resource fetch request is the target fetch request". When the remaining data in the data stack is False, the detection result of this discrimination rule is determined to be "the current resource fetch request is not the target fetch request".

[0148] In the above process, by using tokenization to process the rule description statements to obtain the original description sequence, and then performing a reverse Polish notation on the original description sequence to obtain the rule description sequence, the rule description sequence output by the preprocessing process is easier for online access systems to understand. This improves the understanding and parsing speed of the discrimination rules corresponding to each rule description sequence, and also makes the subsequent detection logic for resource pull requests more general. This avoids the code size of the functional module for detecting whether it is a target pull request growing rapidly with the increase of discrimination rules, and improves the maintainability of the entire functional module, reducing the R&D manpower cost for development and maintenance.

[0149] 304. The server determines the request detection result of the resource retrieval request based on the detection results of each of the at least one discrimination rule.

[0150] In some embodiments, if the detection result of any discrimination rule indicates that the resource pull request is a target pull request, the detection result of the request is determined to be a target pull request. That is, as long as the resource pull request is detected as a target pull request based on any discrimination rule, it means that the resource pull request is not a request issued by a real user, but an invalid request issued by an automated crawler. Then, proceed to step 305 below and ignore the detected target pull request.

[0151] In some embodiments, if the detection results of at least one discrimination rule indicate that the resource pull request is not the target pull request, the detection result of the request is determined to be that the resource pull request is not the target pull request. That is, only when all discrimination rules indicate that the resource pull request is not the target pull request does it mean that the resource pull request has passed the detection of all discrimination rules. Therefore, the resource pull request is a request issued by a real user. At this time, proceed to step 306 and return the multimedia resource associated with the content item.

[0152] In some embodiments, the number of failed detections indicating that the resource pull request is a target pull request and the number of passed detections indicating that the resource pull request is not a target pull request can also be obtained separately. For example, if the number of failed detections is greater than the number of passed detections, it means that the resource pull request failed the detection under most of the discrimination rules, so it is more likely to be an invalid request issued by an automated crawler. In this case, the request detection result is determined to be that the resource pull request is a target pull request, and the process proceeds to step 305, ignoring the detected target pull request. If the number of failed detections is less than or equal to the number of passed detections, it means that the resource pull request passed the detection under most of the discrimination rules, so it is more likely to be a request issued by a real user. In this case, the request detection result is determined to be that the resource pull request is not a target pull request, and the process proceeds to step 306, returning the multimedia resource associated with the content item.

[0153] In some embodiments, after obtaining the number of failed detections, if the number of failed detections is greater than the discrimination threshold, it means that there are a large number of discrimination rules that failed detections, and the request detection result is determined to be that the resource pull request is a target pull request; or, after obtaining the number of failed detections and the number of passed detections, the sum of the number of failed detections and the number of passed detections is determined, and the proportion of the number of failed detections in the sum is determined. If the proportion is greater than the proportion threshold, it means that the proportion of discrimination rules that failed detections is relatively large, and the request detection result is determined to be that the resource pull request is a target pull request. This application embodiment does not specifically limit the method of determining the request detection result based on the detection results of each discrimination request.

[0154] In steps 302-304 above, a possible implementation is provided in which the server detects at least one field value of the resource fetch request based on the at least one discrimination rule to obtain the detection result of the request. The server can perform serial detection or parallel detection of the at least one field value of the resource fetch request based on different discrimination rules. This application embodiment does not specifically limit this.

[0155] In the above process, when the rule description sequence of each discrimination rule is a sequence obtained by reverse Polish notation, the server can use a general logic to perform corresponding detection operations on different discrimination rules and output the detection results of the corresponding discrimination rules. This enables the system to process the detection logic of multiple discrimination rules in parallel, improving the detection efficiency of whether a resource pull request is the target pull request.

[0156] 305. If the server indicates that the resource fetch request is the target fetch request in the request detection result, the server will ignore the target fetch request.

[0157] In some embodiments, if the detection result indicates that the resource pull request is a target pull request, it means that the resource pull request detected this time is an invalid request triggered by an automated crawler, and thus the target pull request is discarded or ignored. Optionally, for the target pull request identified this time, the values ​​of each field of the target pull request are cached so that operators can update or configure new discrimination rules based on newly added target pull requests, thereby continuously expanding the discrimination rules for target pull requests and continuously optimizing the recognition accuracy of target pull requests.

[0158] 306. If the server returns the multimedia resource associated with the content item if the request detection result indicates that the resource fetch request is not the target fetch request.

[0159] In some embodiments, if the detection result indicates that the resource retrieval request is not the target retrieval request, it means that the resource retrieval request detected this time is a request triggered by a real user. Therefore, the server queries the multimedia resources stored associated with the content item identifier carried in the resource retrieval request and returns the queried multimedia resources, so that the terminal that issued the resource retrieval request can display the received multimedia resources.

[0160] In steps 305-306 above, the server returns the multimedia resource associated with the content item only if the request detection result indicates that the resource retrieval request is not the target retrieval request. Furthermore, for the detected target retrieval request, it can ignore or discard it without returning the corresponding multimedia resource, thereby avoiding the waste of server computing resources and optimizing the server's resource configuration.

[0161] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0162] The method provided in this application embodiment uses a rule description sequence of discrimination rules pre-stored in the disk to detect the field values ​​of resource fetch requests, so as to identify resource fetch requests that are not the target fetch requests, and only return the corresponding multimedia resources to resource fetch requests that are not the target fetch requests. This can avoid returning the corresponding multimedia resources to any resource fetch request, effectively suppressing the target fetch requests, thereby avoiding the adverse effects of the target fetch requests on the delivery effect of content items.

[0163] The above embodiments detail the server-side detection process for any received resource fetch request, enabling accurate identification and suppression of target fetch requests while ensuring that resource fetch requests that are not target requests are not adversely affected. Below, we will use an advertising scenario where the content item is an advertisement as an example to illustrate the request processing method of this application embodiment. Resource fetch requests in an advertising scenario are called advertising fetch requests, while target fetch requests are called advertising crawler requests. Advertising scenarios are a typical high-throughput, low-latency application scenario, requiring not only accurate identification and suppression of advertising crawler requests by the server side but also low processing latency to avoid harming the browsing experience of real users.

[0164] Figure 4 This is a schematic diagram of an information flow advertisement provided in an embodiment of this application, such as... Figure 4As shown, in applications such as news apps and information apps, information streams such as video streams and feeds streams are displayed on the main interface 400. The information stream usually includes information content 401 and advertising videos 402. Therefore, when displaying the information stream, the user's terminal needs to send an advertising retrieval request to the server to retrieve the advertising video 402. In order to save resources, only the cover and the first N (N≥1) frames of the advertising video 402 are retrieved during the information stream display stage. If the user does not click on the advertising video 402, only the cover and play button 403 of the advertising video 402 are displayed on the main interface 400. If the user clicks on the advertising video 402, the user's terminal sends a new advertising retrieval request to the server again to retrieve the full video resources of the advertising video 402.

[0165] Figure 5 This is a schematic diagram of a splash screen advertisement provided in an embodiment of this application, such as... Figure 5 As shown, a splash screen ad 501 is usually displayed on the launch screen 500 of applications such as social applications, audio and video applications, and live streaming applications. The splash screen ad 501, also known as a flash ad, can be an animation, motion effect, short video, GIF, etc. When a user launches the application, the user's terminal sends an ad retrieval request to the server to retrieve the splash screen ad 501. Furthermore, after the user clicks on the splash screen ad 501, the terminal sends a new ad retrieval request to the server to retrieve the web page resource corresponding to the splash screen ad 501. At this time, the user will be redirected to the browser application to display the web page resource. Alternatively, if the application has a built-in browser component, the user will be redirected to the browser application without being redirected to the browser application; the built-in browser component will be launched automatically and the web page resource will be displayed.

[0166] As can be seen, regardless of whether it's in-feed ads, splash screen ads, or other types of ads, there are a large number of requests within the same time period. Therefore, the ad retrieval latency on the user side needs to be controlled at a very low level. This requires the anti-ad crawler module to have very low detection latency and a very fast detection rate for ad retrieval requests. In view of this, when the method provided in this application embodiment is applied to an advertising scenario, it is equivalent to providing a method for suppressing automatic ad crawling based on operational rules. The operational rules are the discrimination rules involved in the above embodiments, which can quickly respond to received ad retrieval requests and accurately identify and suppress some ad crawler requests that have not appeared before. This is of great significance to the advertising scenario because machine learning models usually require at least 7 days of training and debugging before an anti-crawler strategy can be deployed online, while the anti-ad crawler solution in this application embodiment can be deployed and take effect within 1 day.

[0167] Figure 6 This is a schematic diagram illustrating the principle of an anti-ad crawler strategy provided in an embodiment of this application, such as... Figure 6 As shown, the operator configures the rule description statement of the anti-ad crawler operation rules on the terminal and uploads the rule description statement of the operation rules to the cloud database 601. Then, the cloud database 601 performs tokenization and reverse Polish notation on the rule description statement of the operation rules to obtain the rule description sequence of the operation rules. The rule description sequence is written to the data file of disk 602 for persistent storage, so that it can be accessed by the online advertising access system 603. Since users trigger ad retrieval requests through their terminals, and the ad crawler automaton automatically generates a large number of ad crawling requests, both ad retrieval requests and ad crawling requests are sent to the online ad access system 603. The online ad access system 603 reads the rule description sequence of the operation rules from the data file on disk 602, and determines whether the currently received request is an ad crawling request based on the rule description sequence of the operation rules, obtaining a request detection result. For ad crawling requests indicated by the request detection result, no ad retrieval is performed and no ad-related multimedia resources are returned. For ad retrieval requests indicated by the request detection result, the system will retrieve and return ad-related multimedia resources normally.

[0168] Figure 7 This is a schematic diagram of an operation rule configuration interface provided in an embodiment of this application, such as... Figure 7 As shown, the operation rule configuration interface 700 includes: an operation rule name input field 701, used to enter the rule name of this configured operation rule; a site set selection field 702, used to select the sites to which this operation rule applies; a media selection field 703, used to select which type of media application in the selected sites this operation rule applies to; a device ID configuration field 704, used to configure which device IDs are the device IDs of the ad crawler automaton, providing device ID locking for ad crawler automatons under different standards based on different device ID generation standards; and an IP address configuration field 705, used to configure which IP addresses are... The IP address of the ad crawler automaton; UA configuration field 706 is used to configure the UA field value information that ad crawler requests usually carry in the UA field. Through device number configuration field 704, operators can enter the device ID of some known ad crawler automatons, through IP address configuration field 705, they can enter the IP address of some known ad crawler automatons, and through UA configuration field 706, they can enter some known UA field values ​​that are often carried in ad crawler requests, which are equivalent to UA characteristics. This allows for fine-grained configuration of anti-ad crawler operation rules, enabling rapid and accurate identification and suppression of ad crawler requests.

[0169] The method for suppressing ad crawlers based on operational rules provided in this application utilizes disk transfer technology to improve the online loading efficiency of operational rules for anti-ad crawlers. This allows the online ad access system to load the operational rules from the disk in a low-latency, high-throughput manner. Furthermore, the rule description sequence obtained through tokenization and Reverse Polish Notation enables preprocessing of the rule description statements, thereby improving the parsing speed of the anti-crawler module in the online ad access system and enhancing the efficiency of detecting whether ad pull requests are ad crawler requests using operational rules. This reduces detection latency and meets the low-latency requirements of the online ad access system for its anti-crawler module. In addition, the above method has low usage costs, can be executed using CPU hardware (costing only 50% of GPU hardware), and has a fast execution speed, capable of executing over 1000 anti-ad crawler operational rules in parallel within 1 millisecond, fully meeting the low-latency requirements of the online ad access system for its anti-crawler module.

[0170] Figure 8 This is a schematic diagram of the structure of a request processing device provided in an embodiment of this application. Please refer to it. Figure 8 The device includes:

[0171] The reading module 801 is used to read at least one rule description sequence corresponding to each discrimination rule from the disk in response to a resource fetch request associated with a content item. The rule description sequence is obtained by parsing the rule description statement of the corresponding discrimination rule. The discrimination rule is used to determine whether the resource fetch request is the target fetch request.

[0172] The detection module 802 is used to detect at least one field value of the resource retrieval request based on the rule description sequence corresponding to each of the at least one discrimination rule, and obtain the request detection result;

[0173] Return module 803 is used to return the multimedia resource associated with the content item only if the request detection result indicates that the resource fetch request is not the target fetch request.

[0174] The apparatus provided in this application uses a rule description sequence of discrimination rules pre-stored in the disk to detect the field values ​​of resource fetch requests, thereby identifying resource fetch requests that are not the target fetch requests, and returning the corresponding multimedia resources only to resource fetch requests that are not the target fetch requests. This avoids returning the corresponding multimedia resources for any resource fetch request, effectively suppressing target fetch requests, and thus preventing the delivery effect of content items from being adversely affected by target fetch requests.

[0175] In one possible implementation, based on Figure 8The device comprises, wherein the detection module 802 includes:

[0176] A scanning unit is configured to scan the rule description sequence of any one of the at least one discrimination rules, the rule description sequence including at least one descriptive character of the discrimination rule;

[0177] The processing unit is used to process the value of at least one field based on the scanned descriptive characters to obtain the detection result of the discrimination rule;

[0178] The determining unit is used to determine the requested detection result based on the detection results of each of the at least one discrimination rule.

[0179] In one possible implementation, the character type of the descriptive character includes data type and operator;

[0180] based on Figure 8 The device comprises a processing unit including:

[0181] Add a sub-unit, which is used to add the field value corresponding to the data type or the description character to the data stack when the character type of the scanned description character is a data type;

[0182] The processing subunit is used to process the top data of the data stack corresponding to the operator when the character type of the scanned description character is an operator.

[0183] The acquisition sub-unit is used to retrieve the data stored in the data stack as the detection result of the discrimination rule after the processing of the descriptive characters in the rule description sequence is completed.

[0184] In one possible implementation, the added subunit is used for:

[0185] If the data type is a field name, read the field value corresponding to the field name from the resource fetch request and add the field value to the data stack; or,

[0186] If the data type is not a field name, store the description character in the variable corresponding to the data type, and add the variable to the data stack.

[0187] In one possible implementation, the processing subunit is used for:

[0188] Determine the amount of data that the operator operates on;

[0189] Retrieve at least one data item that is at the top of the data stack and meets the specified number of data items;

[0190] Use this operator to process at least one piece of data and add the processed data to the data stack.

[0191] In one possible implementation, the determining unit is used to:

[0192] If the detection result of any discrimination rule indicates that the resource pull request is the target pull request, then the detection result of the request is determined to be that the resource pull request is the target pull request;

[0193] If the detection results of at least one of the discrimination rules indicate that the resource pull request is not the target pull request, then the detection result of the request is determined to be that the resource pull request is not the target pull request.

[0194] In one possible implementation, based on Figure 8 The device comprises:

[0195] The word segmentation module is used to segment the rule description statement of any discrimination rule into words to obtain the original description sequence. The original description sequence is used to characterize the word segmentation in the rule description statement and the character type of the word segmentation.

[0196] The transformation module is used to perform reverse Polish notation transformation on the original description sequence to obtain the rule description sequence of the discrimination rule.

[0197] In one possible implementation, the conversion module is used for:

[0198] Scan the word segments in the original description sequence;

[0199] If the character type of the segment is a data type, add the segment to the rule description sequence;

[0200] If the character type of the segment is an operator, add the segment to the operator stack;

[0201] If the operator stack is not empty after scanning the original description sequence, the operators in the operator stack are added to the rule description sequence.

[0202] In one possible implementation, the conversion module is further configured to:

[0203] If the priority of this operator is higher than the priority of the operator at the top of the operator stack, the token is added to the operator stack.

[0204] If the priority of the operator is lower than that of the operator at the top of the stack, the operator at the top of the stack is removed from the operator stack and added to the rule description sequence, and the word is added to the operator stack.

[0205] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0206] It should be noted that the request processing apparatus provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the request processing apparatus and the request processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the request processing method embodiments, which will not be repeated here.

[0207] Figure 9 This is a schematic diagram of a computer device 900 provided in an embodiment of this application. The computer device 900 can vary significantly due to differences in configuration or performance. The computer device 900 includes one or more Central Processing Units (CPUs) 901 and one or more memories 902. The memories 902 store at least one computer program, which is loaded and executed by the one or more processors 901 to implement the request processing methods provided in the various embodiments described above. Optionally, the computer device 900 also includes wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The computer device 900 also includes other components for implementing device functions, which will not be elaborated here.

[0208] In exemplary embodiments, a computer-readable storage medium is also provided, such as a memory including at least one computer program, which can be executed by a processor in a terminal to perform the request processing methods in the various embodiments described above. For example, the computer-readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0209] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more lines of program code stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the computer device to perform the request processing method described in the above embodiments.

[0210] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. Optionally, the program is stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0211] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A request processing method, characterized in that, The method includes: If the rule description statement of any configured discrimination rule is close to the form of natural language, a preprocessing process is performed on the rule description statement. The discrimination rule is used to determine whether the resource pull request is the target pull request. The processing of any user-configured rule description statement includes: writing it to the database, parsing it to obtain the corresponding rule description sequence, and writing the rule description sequence to the disk; the timing of the preprocessing process is: before writing to the database; or, after writing to the database and before importing to the disk; the preprocessing process is: segmenting the rule description statement to obtain an original description sequence that represents the segmentation in the rule description statement and the character type of the segmentation; using the original description sequence as the rule description sequence; or, performing a reverse Polish notation transformation on the original description sequence to obtain the rule description sequence of the discrimination rule; In response to a resource fetch request associated with a content item, if the disk stores a rule description sequence after reverse Polish notation, then at least one rule description sequence corresponding to each discrimination rule is directly read from the disk. If the disk stores the original description sequence, then after reading the original description sequence from the disk, reverse Polish notation is performed on any original description sequence in real time to obtain at least one rule description sequence corresponding to each discrimination rule. Based on the rule description sequence corresponding to each of the at least one discrimination rule, at least one field value of the resource fetching request is detected to obtain the request detection result; The multimedia resource associated with the content item is returned only if the request detection result indicates that the resource fetch request is not the target fetch request.

2. The method according to claim 1, characterized in that, The step of detecting at least one field value of the resource fetch request based on the rule description sequence corresponding to each of the at least one discrimination rule, and obtaining the request detection result, includes: For any one of the at least one discrimination rule, scan the rule description sequence of the discrimination rule, wherein the rule description sequence includes at least one description character of the discrimination rule; Based on the scanned descriptive characters, the values ​​of the at least one field are processed accordingly to obtain the detection result of the discrimination rule; The requested detection result is determined based on the detection results of each of the at least one discrimination rule.

3. The method according to claim 2, characterized in that, The character type described includes data type and operator; The step of processing the at least one field value based on the scanned descriptive characters to obtain the detection result of the discrimination rule includes: If the character type of the scanned description character is a data type, add the field value corresponding to the data type or the description character to the data stack; If the character type of the scanned description character is an operator, the top data of the data stack corresponding to the operator is processed; After processing the descriptive characters in the rule description sequence, the data stored in the data stack is obtained as the detection result of the discrimination rule.

4. The method according to claim 3, characterized in that, When the character type of the scanned description character is a data type, adding the field value corresponding to the data type or the description character to the data stack includes: If the data type is a field name, read the field value corresponding to the field name from the resource fetch request and add the field value to the data stack; or, If the data type is not a field name, the description character is stored in the variable corresponding to the data type, and the variable is added to the data stack.

5. The method according to claim 3, characterized in that, The processing of the top data of the data stack corresponding to the operator includes: Determine the amount of data operated on by the operator; Retrieve at least one piece of data that is located at the top of the data stack and meets the specified number of data items; The operator is used to process the at least one piece of data, and the processed data is added to the data stack.

6. The method according to claim 2, characterized in that, The determination of the requested detection result based on the detection results of each of the at least one discrimination rule includes: If the detection result of any discrimination rule indicates that the resource pull request is the target pull request, then the request detection result is determined to be that the resource pull request is the target pull request; If the detection results of at least one of the discrimination rules all indicate that the resource fetch request is not the target fetch request, then the request detection result is determined to be that the resource fetch request is not the target fetch request.

7. The method according to claim 1, characterized in that, The step of performing an inverse Polish notation transformation on the original description sequence to obtain the rule description sequence of the discrimination rule includes: Scan the word segments in the original description sequence; If the character type of the segmented word is a data type, the segmented word is added to the rule description sequence; If the character type of the segmented word is an operator, the segmented word is added to the operator stack; If the operator stack is not empty after the original description sequence has been scanned, the operators in the operator stack are added to the rule description sequence.

8. The method according to claim 7, characterized in that, When the character type of the segmented word is an operator, adding the segmented word to the operator stack includes: If the priority of the operator is higher than the priority of the operator at the top of the operator stack, the word segment is added to the operator stack. If the priority of the operator is lower than that of the operator at the top of the stack, the operator at the top of the stack is removed from the operator stack and added to the rule description sequence, and the word segmentation is added to the operator stack.

9. A request processing apparatus, characterized in that, The device includes: Modules used to perform the following steps: If the rule description statement of any configured discrimination rule is a statement close to natural language, perform a preprocessing process on the rule description statement, wherein the discrimination rule is used to determine whether the resource fetch request is the target fetch request; The processing of any user-configured rule description statement includes: writing it to the database, parsing it to obtain the corresponding rule description sequence, and writing the rule description sequence to the disk; the timing of the preprocessing process is: before writing to the database; or, after writing to the database and before importing to the disk; the preprocessing process is: segmenting the rule description statement to obtain an original description sequence that represents the segmentation in the rule description statement and the character type of the segmentation; using the original description sequence as the rule description sequence; or, performing a reverse Polish notation transformation on the original description sequence to obtain the rule description sequence of the discrimination rule; The reading module is used to respond to resource fetching requests associated with content items. If the disk stores a rule description sequence after reverse Polish notation, it directly reads the rule description sequence corresponding to each of the discrimination rules from the disk. If the disk stores the original description sequence, it reads the original description sequence from the disk and performs reverse Polish notation on any original description sequence in real time to obtain the rule description sequence corresponding to each of the discrimination rules. The detection module is used to detect at least one field value of the resource fetching request based on the rule description sequence corresponding to each of the at least one discrimination rule, and obtain the request detection result; The return module is configured to return the multimedia resource associated with the content item only if the request detection result indicates that the resource fetch request is not the target fetch request.

10. The apparatus according to claim 9, characterized in that, The detection module includes: A scanning unit is configured to scan the rule description sequence of any one of the at least one discrimination rule, wherein the rule description sequence includes at least one descriptive character of the discrimination rule; The processing unit is used to process the at least one field value based on the scanned descriptive characters to obtain the detection result of the discrimination rule; The determining unit is used to determine the requested detection result based on the detection results of each of the at least one discrimination rule.

11. The apparatus according to claim 10, characterized in that, The character type described includes data type and operator; The processing unit includes: Add a sub-unit, used to add the field value corresponding to the data type or the description character to the data stack when the character type of the scanned description character is a data type; The processing subunit is used to process the top data of the data stack corresponding to the operator when the character type of the scanned description character is an operator. The acquisition subunit is used to acquire the data stored in the data stack as the detection result of the discrimination rule after the processing of the descriptive characters in the rule description sequence is completed.

12. The apparatus according to claim 11, characterized in that, The added subunit is used for: If the data type is a field name, the field value corresponding to the field name is read from the resource fetch request, and the field value is added to the data stack; or, If the data type is not a field name, the description character is stored in the variable corresponding to the data type, and the variable is added to the data stack.

13. The apparatus according to claim 11, characterized in that, The processing subunit is used for: Determine the amount of data operated on by the operator; Retrieve at least one piece of data that is located at the top of the data stack and meets the specified number of data items; The operator is used to process the at least one piece of data, and the processed data is added to the data stack.

14. The apparatus according to claim 10, characterized in that, The determining unit is used for: If the detection result of any discrimination rule indicates that the resource pull request is the target pull request, then the request detection result is determined to be that the resource pull request is the target pull request; If the detection results of at least one of the discrimination rules all indicate that the resource fetch request is not the target fetch request, then the request detection result is determined to be that the resource fetch request is not the target fetch request.

15. The apparatus according to claim 9, characterized in that, The device also includes a conversion module: Scan the word segments in the original description sequence; If the character type of the segmented word is a data type, the segmented word is added to the rule description sequence; If the character type of the segmented word is an operator, the segmented word is added to the operator stack; If the operator stack is not empty after the original description sequence has been scanned, the operators in the operator stack are added to the rule description sequence.

16. The apparatus according to claim 15, characterized in that, The conversion module is also used for: If the priority of the operator is higher than the priority of the operator at the top of the operator stack, the word segment is added to the operator stack. If the priority of the operator is lower than that of the operator at the top of the stack, the operator at the top of the stack is removed from the operator stack and added to the rule description sequence, and the word segmentation is added to the operator stack.

17. A computer device, characterized in that, The computer device includes one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to implement the request processing method as described in any one of claims 1 to 8.

18. A storage medium, characterized in that, The storage medium stores at least one computer program, which is loaded and executed by a processor to implement the request processing method as described in any one of claims 1 to 8.

19. A computer program product, characterized in that, The computer program product includes at least one computer program, which is loaded and executed by a processor to implement the request processing method as described in any one of claims 1 to 8.

Citation Information

Patent Citations

  • Matching method for resource requests, and device

    CN103914479A

  • Voice quality inspection method and device, server and storage medium

    CN111627461A