CN108810948B - Method for identifying real flow - Google Patents
Method for identifying real flow Download PDFInfo
- Publication number
- CN108810948B CN108810948B CN201810536667.1A CN201810536667A CN108810948B CN 108810948 B CN108810948 B CN 108810948B CN 201810536667 A CN201810536667 A CN 201810536667A CN 108810948 B CN108810948 B CN 108810948B
- Authority
- CN
- China
- Prior art keywords
- stid
- server
- address
- sip
- terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 24
- PZINFSHCXYXHOY-UHFFFAOYSA-N (2,5-dioxopyrrolidin-1-yl) 5-iodopyridine-3-carboxylate Chemical compound IC1=CN=CC(C(=O)ON2C(CCC2=O)=O)=C1 PZINFSHCXYXHOY-UHFFFAOYSA-N 0.000 description 8
- 101150047375 DID2 gene Proteins 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 101100043229 Oryza sativa subsp. japonica SPL14 gene Proteins 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000007619 statistical method Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/04—Arrangements for maintaining operational condition
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
The invention provides a method for identifying real flow, which comprises the following steps: step S100, receiving a flow authentication request and recording the time T of receiving the flow authentication request, wherein the flow authentication request comprises an STID and an SIP; step S200, if the STID exists in the terminal ID of the operation data of the first server, performing step S300; the first server stores operation data sent by a trusted SDK installed in a plurality of mobile terminals, wherein the operation data comprises a terminal ID of the mobile terminal to which the trusted SDK is installed, an IP address of the mobile terminal when the operation data is sent and generation time; step S300, if the corresponding IP address of the STID in the first server is matched with the SIP and T-T1 is not more than S1, the flow state of the authentication request is set to FS 1; where S1 is a first time threshold, and T1 is a generation time corresponding to the STID and the SIP stored in the first server; step S700, if the traffic status is in the real traffic status list TFS, it is determined that the traffic authentication request is real traffic.
Description
Technical Field
The invention relates to an information processing method, in particular to a method for identifying real flow.
Background
With the development of intelligent terminals, the use of APP has been greatly popularized. Many APPs require to count the flow of users and transmit the flow information to the background equipment of the APP. Traffic information that may occur includes, but is not limited to: the number of times that a specific/new function in the APP is used, the number of times that a specific work in some reading-type APPs is clicked to read or accessed, the number of times that an advertisement embedded in some APPs is clicked or browsed, and the like. More false traffic occurs in the traffic information, that is, the false traffic is disguised as a user using the APP on the terminal by using a malicious traffic refreshing program, and false traffic which is not really generated by the user is produced.
The currently common means for preventing false traffic is mainly a log analysis method, and an anomaly is found from statistical analysis of log data, for example: the ratio of the click volume/the browsing volume is too high or the change with time is large, a large amount of traffic is generated by a plurality of IPs in a centralized manner, and the like. The log analysis method is based on statistical common sense or distribution abnormality to discover false traffic, and has the following disadvantages:
1. the method can be effectively carried out only by accumulating certain flow data, belongs to a posterior mode and provides existing space for false flow;
2. it is impossible to locate a specific one of the real traffic requests, i.e. it is impossible to determine whether a certain traffic request of a specific APP is real traffic or dummy traffic.
The applicant has provided a solution to the above technical problem in chinese patent application CN201711079108, and the present invention seeks to provide another solution to the above technical problem.
Disclosure of Invention
In order to solve the above problems, a first embodiment of the present invention provides a method of authenticating a real traffic, including the steps of:
step S100, receiving a flow authentication request and recording the time T of receiving the flow authentication request, wherein the flow authentication request comprises an STID and an SIP; wherein, STID is the terminal ID of the flow source terminal, SIP is the IP address of the flow source terminal;
step S200, if the STID exists in the terminal ID of the operation data of the first server (e.g., Redis server), performing step S300; the first server stores operation data sent by a trusted SDK installed in a plurality of mobile terminals, wherein the operation data comprises a terminal ID of the mobile terminal to which the trusted SDK is installed, an IP address of the mobile terminal when the operation data is sent and generation time;
step S300, if the corresponding IP address of the STID in the first server is matched with the SIP and T-T1 is not more than S1, the flow state of the authentication request is set to FS 1; where S1 is a first time threshold, and T1 is a generation time corresponding to the STID and the SIP stored in the first server;
step S700, if the traffic status is in the real traffic status list TFS, it is determined that the traffic authentication request is real traffic.
In order to solve the above problems, a second embodiment of the present invention provides a method of discriminating a real traffic, including the steps of:
step S100, receiving a flow authentication request and recording the time T of receiving the flow authentication request, wherein the flow authentication request comprises an STID and an SIP; wherein, STID is the terminal ID of the flow source terminal, SIP is the IP address of the flow source terminal;
step S200, if the STID does not exist in the terminal ID of the operation data of the first server (e.g., implemented as a Redis server), performing step S500; the first server stores operation data sent by a trusted SDK installed to a plurality of mobile terminals, the operation data including a terminal ID of the mobile terminal to which the trusted SDK is installed;
step S500, if the STID exists in a second server (e.g., also implemented as a Redis server), and T-T2 ≦ S3, perform step S600; the second server stores terminal IDs of a plurality of mobile terminals, the latest active time of each terminal ID corresponding to the mobile terminal, and one or more attribution codes; the S3 is a third time threshold, and T2 is the last active time stored in the second server corresponding to the STID;
step S600, if the corresponding attribution code of the STID in the second server matches the corresponding attribution code SIPC of the SIP, setting the flow state of the authentication request to FS 4;
step S700, if the traffic status is in the real traffic status list TFS, it is determined that the traffic authentication request is real traffic.
Drawings
FIG. 1 is a schematic flow chart of the present invention for authenticating true traffic;
FIG. 2 is an exemplary diagram of a first server storage of the present invention;
fig. 3 is an exemplary diagram of a second server storage of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the present invention will be described clearly and completely with reference to the accompanying drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention.
As shown in fig. 1, the present invention provides a method for identifying real traffic, comprising the following steps:
step S100, receiving a flow authentication request and recording the time T of receiving the flow authentication request, wherein the flow authentication request comprises an STID and an SIP; wherein, STID is the terminal ID of the traffic source terminal, and SIP is the IP address of the traffic source terminal. Optionally, the traffic authentication request may also use a non-reversible HASH algorithm such as MD5 to protect information security. According to the present invention, the source terminal is preferably implemented as a mobile terminal, including but not limited to a mobile phone, a tablet computer, and the like, and has an APP installed thereon.
According to the present invention, the traffic authentication request may be a traffic authentication request of the source APP, that is, a traffic request directly sent by the mobile terminal, or a traffic authentication request forwarded by another third party Platform responsible for traffic information, examples of which include, but are not limited to, adx (ad exchange), SSP (session-Side Platform), and the like. Those skilled in the art will understand that any traffic authentication request, as long as it carries the STID, SIP and SAPPID of the originating terminal, is applicable to the technical solution of the present application, and thus will fall into the scope of the present application.
According to the invention, some APPs of the mobile terminal are integrated with the credible SDK, and some APPs are not integrated with the credible SDK. The developer of the trusted SDK may be the same as the developer of the APP, or may be a third party developer different from the developer of the APP. By way of illustration and not limitation, one example of a trusted SDK is the "push SDK" developed by the applicant.
Step S200, if the STID is present in the terminal ID of the operational data of the first server (e.g., implemented as a Redis server), then step S300 is performed according to the first aspect of the present invention. Taking fig. 2 as an example, if the STID is one of IMEI-1, IMEI-2, or IMEI-3, it can be considered that the STID exists in the terminal ID of the operation data of the first server.
As shown in fig. 2, the first server stores operation data transmitted from the trusted SDKs installed to the plurality of mobile terminals, the operation data including the terminal ID of the mobile terminal to which the trusted SDK is installed, the IP address of the mobile terminal at the time of transmission of the operation data, and the generation time. Further, the first server stores the home code and the generation time corresponding to the IP address. The terminal ID is a unique identifier of the terminal, such as an IMEI, an IMSI, a unique android system identifier, and/or a user-defined ID capable of identifying the terminal, and preferably, as shown in fig. 2, the terminal ID is an IMEI of the mobile terminal. Those skilled in the art know that the operation data may be original data (e.g., an operation log) sent by the trusted SDK, may also be data obtained by processing the original data (e.g., the operation log) by any technical means in the prior art, and may also include both the original data and the processed data.
Step S300, if the corresponding IP address of the STID in the first server matches the SIP, and T-T1 is not greater than S1, still taking fig. 2 as an example for explanation, assuming that the STID is IMEI-1 and the SIP is IP-12, it can be considered that the corresponding IP address of the STID in the first server matches the SIP. Then the traffic status of the authentication request is set to FS 1. Where S1 is the first time threshold, preferably, S1 should preferably be no less than the maximum period of time during which the trusted SDK sends the original data (e.g., the log), so that a log of possible SDK transmissions can be received within S1 before the server receives the traffic authentication request. Preferably, S1 is generally 10 to 60 minutes, most preferably 30 minutes. T1 is the generation time corresponding to the STID and the SIP stored in the first server, and in the foregoing example, T1 is T21.
Further, the generation time T1 may take various times. Simply, T1 is the time when the mobile terminal sends the operation log; for another example, T1 is the time when the server receives the operation log, in which case, the mobile terminal is not required to package the log sending time into the operation log, and some network traffic can be saved.
Preferably, the generation time T1 is determined to be Ta-Tb + Tc, where Ta is the log generation time on the mobile terminal, Tb is the log transmission time on the mobile terminal, and Tc is the time when the server receives the operation log. Obviously, Ta and Tb are the time provided by the mobile terminal and Tc is the time provided by the server. The T1 obtained in this way is more accurate, and specifically comprises the following two technical effects:
firstly, the condition that the time for generating the log by the mobile terminal is inconsistent with the time for sending the log is avoided. For example, in some cases, the trusted SDK obtains information of the mobile terminal when the APP is started, and sends the running log to the server only after the APP runs stably for a period of time or before the APP exits. Illustratively, the trusted SDK obtains information about the mobile terminal at 12:00, generates a log of operations, and sends the log of operations to the server at 12:30, at which time there is a possibility of inaccuracy if the server sets the operation time T1 to 12: 30.
Secondly, the condition that the time of the mobile terminal is inconsistent with the time of the server is corrected. The time of the server is generally standard time, but the time of some mobile terminals has time difference with the standard time. For example, when the server time is 12:00, some mobile terminals have a time of 12:05, i.e., 5 minutes faster. Thus, when the time that the mobile terminal encapsulates in the log is "12: 05", the actual standard time is only "12: 00". This time difference can be corrected using a preferred mode of the present invention.
In step S300, the operational data is derived from the raw data (e.g., operational log) that the trusted SDK sent to the server in the near future (within time S1), and thus may be considered trusted. When the SIP is consistent with the IP address in the running data, the SIP is considered to be true and valid for a great probability, rather than the IP address generated falsely by technical means. That is, in general, the flow rate state FS1 is considered to represent the true flow rate.
Further, when the APP is started, the trusted SDK sends the original data (e.g., the running log) to the first server, so that the original data (e.g., the running log) may arrive at the server earlier than the traffic authentication request is triggered, and thus the server may more easily complete the determination in step S300 when receiving the traffic request.
Further, the step S300 of determining that the IP address corresponding to the STID in the first server matches the SIP specifically includes:
alternatively, if IPA ≠ Null and SIP is the only element in IPA, then the corresponding IP address of STID in the first server is determined to match SIP, otherwise it is determined not to match.
Preferably, if the SIP is e-IPA, then the corresponding IP address of the STID in the first server is determined to match the SIP; otherwise, judging the data are not matched. The preferred embodiment fully considers the situation that the IP address of the mobile terminal may reasonably change within the time of S1, for example, changing from an area covered by WIFI to another area covered by WIFI or changing to an area connected by a mobile network, so that the dynamically allocated IP address changes, that is, two or more IP addresses may reasonably appear in the mobile terminal within the time of S1. Therefore, if the SIP is identical to one of the two or more IP addresses, the SIP is considered to be identical to the IP address in the operation data, and the misjudgment rate of the traffic authentication can be reduced compared with the former method.
Wherein the IPA is a set of corresponding IP addresses of the STID in the first server.
Those skilled in the art will appreciate that the present invention is not intended to be limited to the specific method steps to obtain the aforementioned relationship of IPA1 and SIP as long as IPA1 and SIP satisfy the aforementioned relationship, which falls within the scope of the present invention.
According to the present invention, in step S300, if the corresponding IP address of the STID in the first server does not match the SIP, or T-T1 > S1, step S400 is performed;
and S400, if the corresponding attribute codes of the SAC and the STID of the SIP are matched in the corresponding attribute codes of the first server, and T-T1 is less than or equal to S2, setting the flow state to FS 2. Wherein S2 is the second time threshold greater than S1, preferably S2 is generally 8-16 hours, and most preferably 12 hours.
The step S400 of determining the corresponding attribute code matching of the STID in the first server specifically includes:
alternatively, if DID ≠ Null and SAC is the only element in DID, it is determined that SAC and STID match in the corresponding home codes of the first server, otherwise, it is determined that SAC and STID do not match.
Preferably, the other mode is that if the SAC belongs to the DID, the corresponding attribution codes of the SAC and the STID in the first server are judged to be matched, otherwise, the corresponding attribution codes of the SAC and the STID are judged to be not matched; wherein the DID is a set of corresponding home codes of the STID in the first server. The preferred embodiment fully considers the situation that the geographic area corresponding to the IP address of the mobile terminal may reasonably change within the time of S2, for example, the mobile terminal moves from one city to another city, so that the misjudgment rate of the traffic authentication can be reduced compared with the former method.
Further, the mapping relationship between the IP address and the geographic area may be implemented in any manner in the prior art, and the geographic area may be a city (e.g., beijing), or may be a specific area of the city (e.g., a hai lake area or a middle guan village area).
According to the present invention, in step S400, if the corresponding attribute codes of the SIP and the STID do not match in the corresponding attribute codes of the first server, or T-T1 > S2, the traffic status is set to FS 3.
In step S200, if the STID does not exist in the terminal ID of the operation data of the first server (e.g., the Redis server), then according to the second aspect of the present invention, step S500 is performed. It should be noted that the technical terms and technical means used in the second aspect of the present invention are the same as or substantially the same as the technical terms and technical means that can only be used in the first aspect of the present invention, and for the reason of brevity, the applicant does not describe the related technical terms and technical means again.
Step S500, if the STID exists in a second server (e.g., also implemented as a Redis server), and T-T2 ≦ S3, perform step S600; if the STID does not exist at the second server, or T-T2 > S3, then the traffic status of the authentication request is set to FS 5. The second server stores terminal IDs of a plurality of mobile terminals, the latest active time of each terminal ID corresponding to the mobile terminal, and one or more attribution codes; the S3 is a third time threshold, and the third time threshold is 2-6 months, preferably 3 months. The T2 is the last active time stored in the second server corresponding to the STID.
Step S600, if the corresponding attribution code of the STID in the second server matches the corresponding attribution code SIPC of the SIP, setting the flow state of the authentication request to FS 4; conversely, if the corresponding home code of the STID in the second server does not match the home code SIPC corresponding to SIP, the traffic status is set to FS 6.
With the technology similar to the first aspect of the present invention, the determining that the corresponding home code of the STID in the second server matches the home code SIPC corresponding to the SIP in step S600 specifically includes:
alternatively, if the DID2 ≠ Null and the SIPC is the only element in the DID, it is determined that the corresponding home codes of the SIPC and the STID in the second server match, otherwise it is determined that the codes do not match.
Preferably, if the SIPC belongs to the DID2, the corresponding home codes of the SIPC and the STID in the second server are judged to be matched, otherwise, the corresponding home codes are judged to be not matched; where DID2 is the set of corresponding home codes for STIDs in the second server.
According to the first and second aspects of the present invention, the method further comprises step S700.
Step S700, if the traffic status is in the real traffic status list TFS, it is determined that the traffic authentication request is real traffic. The flow state in the TFS is a custom flow state, so that the flexibility of the two methods is improved. For example, when the first aspect of the present invention is used alone, TFS ═ { FS1, FS2} may be defined, and of course, TFS ═ { FS1} or TFS ═ FS1, FS2, FS3} may also be defined; when the second aspect of the present invention is used alone, TFS ═ { FS3} may be defined; when the first and second aspects of the present invention are used in combination, TFS ═ FS1, FS2, FS4 may be defined.
Furthermore, those skilled in the art will appreciate that while the first and second aspects of the present invention are illustrated in FIG. 1, they do not prevent the two aspects of the present invention from being implemented independently, thereby forming two embodiments in parallel, nor does they preclude the use of the two aspects of the present invention in combination, thereby forming a combined independent embodiment.
Furthermore, the invention also provides an updating method of the running data in the first server. Specifically, when the first server receives an operation log sent by the trusted SDK, the operation log is used to update operation data, and the operation log includes a terminal ID, a terminal IP address, and an operation log generation time LT of the mobile terminal where the trusted SDK is located; the updating specifically comprises:
in step S1010, if the terminal ID in the operation log exists in the terminal ID of the operation data, step S1020 is performed.
Step S1020, if the terminal IP address in the operation log exists in the IP address corresponding to the terminal ID of the operation data, obtaining the time IPT corresponding to the IP address and the time SACT corresponding to the attribution code corresponding to the IP address; if LT-IPT > S1, then updating IPT and SACT with LT; otherwise, step S1020 is performed.
In step S1020, if LT-IPT > S2, then SACT is updated with LT.
The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention in any way, and any simple modifications and equivalent variations of the above embodiments according to the technical spirit of the present invention are within the scope of the present invention.
Claims (10)
1. A method of identifying true traffic, comprising the steps of:
step S100, receiving a flow authentication request and recording the time T of receiving the flow authentication request, wherein the flow authentication request comprises an STID and an SIP; wherein, STID is the terminal ID of the flow source terminal, SIP is the IP address of the flow source terminal;
step S200, if the STID exists in the terminal ID of the operation data of the first server, performing step S300; the first server stores operation data sent by a trusted SDK installed in a plurality of mobile terminals, wherein the operation data comprises a terminal ID of the mobile terminal to which the trusted SDK is installed, an IP address of the mobile terminal when the operation data is sent and generation time;
step S300, if the corresponding IP address of the STID in the first server is matched with the SIP and T-T1 is not more than S1, the flow state of the authentication request is set to FS 1; where S1 is a first time threshold, and T1 is a generation time corresponding to the STID and the SIP stored in the first server;
step S700, if the traffic status is in the real traffic status list TFS, it is determined that the traffic authentication request is real traffic.
2. The method for authenticating true traffic according to claim 1, wherein the determining that the IP address corresponding to the STID in the first server matches the SIP in step S300 specifically includes:
if IPA is not equal to Null and SIP is the only element in IPA, then judging that the corresponding IP address of the STID in the first server is matched with the SIP, otherwise, judging that the corresponding IP address is not matched; or,
if the SIP belongs to IPA, judging that the corresponding IP address of the STID in the first server is matched with the SIP; otherwise, judging as mismatching;
wherein the IPA is a set of corresponding IP addresses of the STID in the first server.
3. The method of authenticating true traffic according to claim 1 or 2, wherein the operation data further includes an owner code corresponding to an IP address; in the step S300, if the corresponding IP address of the STID in the first server does not match the SIP, or T-T1 > S1, executing the step S400;
step S400, if the SAC corresponding to the SIP and the STID are matched in the corresponding attribute codes of the first server, and T-T1 is not more than S2, the flow state is set to FS 2; wherein S2 is a second time threshold greater than S1.
4. The method according to claim 3, wherein the determining of the matching of the corresponding attribute codes of the STID in the first server in step S400 specifically includes:
if the DID is not equal to Null and the SAC is the only element in the DID, judging that the corresponding home codes of the SAC and the STID in the first server are matched, otherwise, judging that the SAC and the STID are not matched; or,
if the SAC belongs to the DID, judging that the corresponding attribution codes of the SAC and the STID in the first server are matched, otherwise, judging that the SAC and the STID are not matched; wherein the DID is a set of corresponding home codes of the STID in the first server.
5. The method of claim 3, wherein in step S400, if the corresponding domain code SAC of SIP and the corresponding domain code of STID in the first server do not match, or T-T1 > S2, the traffic status is set to FS 3.
6. The method for authenticating the real traffic as claimed in claim 5, wherein when the first server receives a running log sent by the trusted SDK, the running log is used to update the running data, and the running log includes a terminal ID, a terminal IP address and a running log generation time LT of the mobile terminal where the trusted SDK is located; the updating specifically includes:
step S1010, if the terminal ID in the operation log exists in the terminal ID of the operation data, step S1020 is performed;
step S1020, if the terminal IP address in the operation log exists in the IP address corresponding to the terminal ID of the operation data, obtaining the time IPT corresponding to the IP address and the time SACT corresponding to the attribution code corresponding to the IP address; if LT-IPT > S1, then updating IPT and SACT with LT; otherwise, executing step S1020;
in step S1020, if LT-IPT > S2, then SACT is updated with LT.
7. Method of authenticating a real flow according to claim 1, 2, 4 or 5, wherein the first time threshold is 10-60 minutes.
8. Method of authenticating a real flow according to claim 1, 2, 4 or 5, wherein the second time threshold is 8-16 hours.
9. The method of authenticating true traffic of claim 1, 2, 4 or 5, wherein the mobile terminal ID is the IMEI of the mobile terminal.
10. The method of discriminating true traffic according to claim 1, 2, 4 or 5 wherein the traffic state in the TFS is a custom traffic state.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810536667.1A CN108810948B (en) | 2018-05-29 | 2018-05-29 | Method for identifying real flow |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810536667.1A CN108810948B (en) | 2018-05-29 | 2018-05-29 | Method for identifying real flow |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108810948A CN108810948A (en) | 2018-11-13 |
| CN108810948B true CN108810948B (en) | 2021-03-19 |
Family
ID=64089213
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810536667.1A Active CN108810948B (en) | 2018-05-29 | 2018-05-29 | Method for identifying real flow |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108810948B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112511459B (en) * | 2020-11-23 | 2024-04-26 | 恒安嘉新（北京）科技股份公司 | Traffic identification method and device, electronic equipment and storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1741526A (en) * | 2005-09-05 | 2006-03-01 | 北京启明星辰信息技术有限公司 | Method and system for detecting exception flow of network |
| CN101438255A (en) * | 2004-12-07 | 2009-05-20 | 思科技术公司 | Network and application attack protection based on application layer message inspection |
| CN101577645A (en) * | 2009-06-12 | 2009-11-11 | 北京星网锐捷网络技术有限公司 | Method and device for detecting counterfeit network equipment |
| CN102394868A (en) * | 2011-10-12 | 2012-03-28 | 镇江金钛软件有限公司 | Detection method for DDoS attacked address of dynamic threshold |
| CN102480711A (en) * | 2010-11-30 | 2012-05-30 | 中国电信股份有限公司 | Flow charging method and packet data service node |
| CN107707509A (en) * | 2016-08-08 | 2018-02-16 | 阿里巴巴集团控股有限公司 | Identify and assist in identifying the method, apparatus and system of false flow |
-
2018
- 2018-05-29 CN CN201810536667.1A patent/CN108810948B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101438255A (en) * | 2004-12-07 | 2009-05-20 | 思科技术公司 | Network and application attack protection based on application layer message inspection |
| CN1741526A (en) * | 2005-09-05 | 2006-03-01 | 北京启明星辰信息技术有限公司 | Method and system for detecting exception flow of network |
| CN101577645A (en) * | 2009-06-12 | 2009-11-11 | 北京星网锐捷网络技术有限公司 | Method and device for detecting counterfeit network equipment |
| CN102480711A (en) * | 2010-11-30 | 2012-05-30 | 中国电信股份有限公司 | Flow charging method and packet data service node |
| CN102394868A (en) * | 2011-10-12 | 2012-03-28 | 镇江金钛软件有限公司 | Detection method for DDoS attacked address of dynamic threshold |
| CN107707509A (en) * | 2016-08-08 | 2018-02-16 | 阿里巴巴集团控股有限公司 | Identify and assist in identifying the method, apparatus and system of false flow |
Non-Patent Citations (1)
| Title |
|---|
| 《基于流量预测的传感器网络拒绝服务攻击检测方案》;曹晓梅;《计算机学报》;20071231;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108810948A (en) | 2018-11-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8689277B2 (en) | Method and system for providing location of target device using stateless user information | |
| US7860488B2 (en) | Device detection in mobile networks | |
| CN109479053B (en) | Method and system for node discovery and self-healing of block chain networks | |
| US10757102B2 (en) | Methods, apparatus, and systems for identity authentication | |
| US20180004852A1 (en) | Method and system for facilitating terminal identifiers | |
| CN103765849A (en) | Distributing network identifiers using a hash function | |
| EP3817333B1 (en) | Method and system for processing requests in a consortium blockchain | |
| CN113453213B (en) | Authentication data synchronization method and device | |
| CN109246078B (en) | Data interaction method and server | |
| CN112069169A (en) | Block data storage method and device, electronic equipment and readable storage medium | |
| US20050289095A1 (en) | Method for serving location information access requests | |
| CN108810947B (en) | Server for identifying real flow based on IP address | |
| CN111353136B (en) | Method and device for processing operation request | |
| CN102388640B (en) | Method for identifying mobile telephone | |
| US11599673B2 (en) | Ascertaining network devices used with anonymous identifiers | |
| CN108810948B (en) | Method for identifying real flow | |
| CN109600254B (en) | Method for generating full-link log and related system | |
| CN108768773B (en) | Method for identifying real flow based on IP address | |
| TW201515502A (en) | Automatic detection of a network operator for a mobile network device | |
| CN112583606B (en) | Security verification method, server, terminal and storage medium | |
| CN109348053B (en) | Telephone number mark processing method, server, terminal device and computer readable storage medium | |
| CN113159784A (en) | Method and device for sending verification code, computer equipment and storage medium | |
| CN114117472B (en) | Method and device for sharing data | |
| CN114500746B (en) | Method and system for dynamic configuration of SMS center number | |
| CN115134119B (en) | Method and device for verifying identity of Internet registered user, server and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 310012 Room 418, West District, Building A, 525 Xixi Road, Xihu District, Hangzhou City, Zhejiang Province Applicant after: Daily interactive Co., Ltd Address before: 310012 Room 418, West District, Building A, 525 Xixi Road, Xihu District, Hangzhou City, Zhejiang Province Applicant before: ZHEJIANG MEIRI INTERDYNAMIC NETWORK TECHNOLOGY Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |