High speed packet search method and apparatus
The high-speed packet search method and device address the inefficiencies in existing network detection and response technologies by using specialized databases and tables to rapidly search for packets meeting specific criteria, thereby enhancing cyber threat response times.
Patent Information
- Application Number
- JP2024554191
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-04-04
- Filing Date
- 2023-04-03
- Publication Date
- 2025-04-15
- Estimated Expiration
- 2043-04-03
AI Technical Summary
Existing network detection and response technologies with full packet analysis infrastructure face significant challenges in efficiently searching for packets that meet specific search conditions within large datasets, leading to prolonged times for recognizing and responding to cyber threats.
A high-speed packet search method and device that generates specialized data for search conditions and stores it in a database, enabling rapid packet searches by utilizing specialized databases, meta tables, IP index tables, LPM tables, conversion tables, and hash tables to reduce comparison numbers and enhance search speed.
This solution enables high-speed searching of packets that meet specific criteria, significantly reducing the time required for security managers to recognize and respond to cyber attacks, thereby enhancing network security and efficiency.
Smart Images

Figure 2025510605000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to a method and apparatus for high-speed packet search, and more particularly, to a method and apparatus for high-speed search for packets matching a search condition in an environment where a full-packet analysis-based network detection and response technology is applied. [Background technology]
[0002] Network Detection and Response, based on full packet collection and analysis, is a technology that can detect and respond to threats by quickly collecting and analyzing all packets entering and leaving a company's network.
[0003] With network detection and response technology based on full packet collection and analysis, it is possible to not only analyze abnormal behavior by internal employees of a company, but also to analyze security threats that may occur in the services operated by the company.
[0004] Despite these advantages, it still takes a considerable amount of time to search for a desired packet from a large amount of data, such as a full packet. Summary of the Invention [Problem to be solved by the invention]
[0005] The problem to be solved by the present disclosure is to provide a high-speed packet search method and device capable of quickly searching for packets that meet search conditions from a large amount of data, namely full packets.
[0006] The problems to be solved by the present disclosure are not limited to those mentioned above, and other problems not mentioned will be clearly understood by those skilled in the art from the following description. [Means for solving the problem]
[0007] In order to solve the above-mentioned problems, a high-speed packet search method according to one embodiment of the present disclosure is a method for quickly searching for packets that match search criteria from packets collected on a network, the method including: generating data specialized for the search criteria and storing the data in a database; and searching for packets that match the input search criteria based on the stored data.
[0008] In order to solve the above-mentioned problems, a high-speed packet device according to one embodiment of the present disclosure includes one or more processors; and one or more memories configured to store instructions that cause the one or more processors to perform operations, the operations including generating data specialized to the search criteria and storing the data in a database in order to quickly search for packets matching the search criteria from among packets collected on a network; and searching for packets matching the input search criteria based on the stored data.
[0009] Further details of the embodiments are included in the detailed description and the drawings. Effect of the Invention
[0010] According to an embodiment of the present disclosure, packets that meet search criteria can be quickly searched for from a large amount of data, i.e., full packets, thereby reducing the time it takes for a company's security administrator to recognize and respond to a cyber attack.
[0011] The effects of the present disclosure are not limited to those mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the following description. [Brief description of the drawings]
[0012] [Figure 1] 1 is a diagram illustrating a configuration of a high-speed packet search device according to an embodiment of the present disclosure. [Diagram 2]1 is a diagram illustrating a meta table according to an embodiment of the present disclosure. [Diagram 3] 1 is a diagram illustrating a meta description table according to an embodiment of the present disclosure. [Figure 4] 1 is a diagram illustrating an IP index table according to an embodiment of the present disclosure. [Diagram 5] 5 is a diagram for explaining a search process using the IP index table of FIG. 4; [Figure 6] 1 is a diagram illustrating an LPM table according to an embodiment of the present disclosure. [Figure 7] 1 is a diagram illustrating a translation table including URLs and constantized values of the URLs, according to an embodiment of the present disclosure. [Figure 8] 1 illustrates a hash table according to an embodiment of the present disclosure. [Figure 9] 4 is a flowchart illustrating a fast packet search method according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0013] The advantages and features of the present disclosure, and the methods for achieving them, will become clear with reference to the following detailed description of the embodiments together with the accompanying drawings. However, the present disclosure is not limited to the embodiments set forth below, and may be embodied in various different forms. However, the embodiments are provided to complete the disclosure and to fully inform those skilled in the art of the invention to which the disclosure pertains, and the present disclosure is defined only by the scope of the claims.
[0014] Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used in the sense commonly understood by those having ordinary skill in the art to which this disclosure belongs. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless clearly and specifically defined.
[0015] The terms used in the present specification are for the purpose of describing the embodiments and are not intended to limit the present disclosure. In the present specification, the singular form includes the plural form unless otherwise specified in the text. The words "comprises" and / or "comprising" used in the specification do not exclude the presence or addition of one or more other components in addition to the components mentioned.
[0016] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings, in which the same reference numerals denote the same elements.
[0017] FIG. 1 is a diagram illustrating a configuration of a high-speed packet search device 100 according to an embodiment of the present disclosure.
[0018] The high-speed packet search device 100 according to the embodiment of the present disclosure uses a database specialized for packet search functions instead of a relational database management system (RDBMS) with various functions. In particular, the database is specialized for search conditions such as IP (Internet Protocol) and URL among various search conditions such as IP, port, URL, application, and file.
[0019] Referring to FIG. 1, the high-speed packet search device 100 includes a meta table generation unit 110, a meta description table generation unit 120, an IP index table generation unit 130, an LPM table generation unit 140, a conversion table generation unit 150, a hash table generation unit 160, a database 170 and a control unit 180.
[0020] 1, the meta table generator 110, the meta description table generator 120, and the IP index table generator 130 can operate as a first search engine. When IPs less than a reference number are input as a search condition, the first search engine generates data required for high-speed search for packets corresponding to the input IPs and stores the data in the database 170.
[0021] 1, the meta table generator 110 and the LPM table generator 140 can operate as a second search engine. When a large number of IP lists exceeding a reference number are input as search conditions, the second search engine generates data required to quickly determine whether the IP of a packet collected from the network is included in the input IP list, and stores the data in the database 170.
[0022] 1, the conversion table generator 150 and the hash table generator 160 can operate as a third search engine. When a URL is input as a search condition, the third search engine generates data required for quickly searching for a packet corresponding to the input URL and stores the data in a database.
[0023] The control unit 180 determines the type and / or number of search criteria input. For example, it determines whether the input search criteria is IP or URL. If the input search criteria is IP, it determines whether IPs less than a reference number have been input or whether a large IP list has been input. Based on the result of this determination, the control unit 180 can select data to be used for the search from data stored in the database 170.
[0024] The components shown in FIG. 1 will now be described in more detail.
[0025] The meta table generator 110 sorts the collected packets based on the IP address to generate a meta table as shown in FIG. 2. Referring to FIG. 2, it can be seen that the IP addresses are sorted in ascending order, and that the sorted IP addresses are assigned a primary index, which is a number indicating the position in the meta table. It can also be seen that the same IP address appears multiple times since the meta table sorts all the collected packets based on the IP address. Hereinafter, for convenience of explanation, a group consisting of the same IP address will be referred to as a "same IP section."
[0026] The meta description table generating unit 120 extracts the first IP located in each identical IP section of the meta table and the primary index of the IP, and generates a meta description table as shown in Fig. 3. Referring to Fig. 3, it can be seen that the first IP extracted in each identical IP section is sorted based on the primary index. It can also be seen that the sorted IPs are assigned a secondary index, which is a number indicating the position in the meta description table.
[0027] The IP index table generator 130 generates an IP index table based on the meta description table, as shown in Fig. 4. The IP index table is used to quickly search for a secondary index in the meta description table in relation to the IP to be searched.
[0028] Before specifically explaining the IP index table with reference to Figure 4, we will briefly explain IP. IP is divided into IPv4 and IPv6 systems. In the IPv4 system, an IP is displayed as a three-digit number divided into four sections. Each section is called an octet, and is processed internally as 32 bits (8 bits per section). For example, 192.168.123.123 is displayed as 11000000.10101000.1111011.1111011.
[0029] IP is divided into A, B, C, D, and E classes according to bandwidth. Class A is used in large network environments, where the 8 bits in the first division indicate the network ID, and the 24 bits in the second and fourth divisions indicate the host ID. Class B is used in medium-sized network environments, where the 16 bits in the first and second divisions indicate the network ID, and the 16 bits in the third and second divisions indicate the host ID. Class C is used in small network environments, where the 24 bits in the first and third divisions indicate the network ID, and the 8 bits in the fourth division indicate the host ID. Class D is used for multicasting. Class E is a class reserved for research / development or future use, and is not used for general purposes. The IPv4 class classification described above is shown in Table 1.
[0030] [Table 1]
[0031] Referring to Figure 4, the basic unit of the IP index table is composed of four fields. Specifically, the basic unit is configured to include a class field, a value field, an index field, and a jump field, and such basic units are gathered to form the IP index table. Each basic unit can be assigned a tertiary index, which is a number indicating its position in the IP index table.
[0032] In the class field, an index indicating the position of an IP octet is recorded. That is, an index indicating the position of each segment is recorded. For example, in the case of C class, the first to third segments out of the four segments indicate a network ID. Therefore, an index is required to distinguish the first to third segments. According to an embodiment, the index for the first segment may be set to "0", the index for the second segment may be set to "1", and the index for the third segment may be set to "2". In other words, it may be understood that Octet 1=0, Octet 2=1, and Octet 3=2.
[0033] The value field records the value of the separator that corresponds to the index of the class field. For example, if the class field is set to 0, the value field records the value of the first separator of the IP. If the class field is set to 1, the value field records the value of the second separator of the IP.
[0034] The index field records a secondary index related to the value recorded in the value field in the secondary index of the meta description table. If there is no related secondary index, the index field may record '0'.
[0035] The jump field records the tertiary index of the base unit that records the next value to be compared if the value recorded in the value field does not match the value of the IP to be searched.
[0036] 4 illustrates a case where each basic unit is vertically aligned, the basic units may be horizontally aligned or arranged in a matrix form. The generated IP index table may be stored in the database 170.
[0037] FIG. 5 is a diagram illustrating a process of searching for a specific IP using the IP index table illustrated in FIG.
[0038] Referring to FIG. 5, it can be seen that the basic units of the IP index table exemplified in FIG. 4 are arranged horizontally, and that some of the basic units are divided in a stepped manner.
[0039] Assume that an IP address of 1.2.1.1 is entered as a search criterion. In this case, the base unit with a tertiary index of "0" in the IP index table is referenced first. When interpreting the values recorded in the class field and value field of the corresponding base unit in the IP index table, it is "whether the value of the first delimiter is 1." Since the value of the first delimiter in the IP entered as a search criterion is "1," it matches the value "1" recorded in the value field. However, it can be seen that "0" is recorded in the index field of the referenced base unit. This means that there is no secondary index in the meta description table. Therefore, the base unit with the next tertiary index assigned is referenced. In other words, the base unit with a tertiary index of "1" is referenced.
[0040] When interpreting the values recorded in the class field and value field of the referenced base unit, the question is "is the value of the second delimiter 1?" The value of the second delimiter in the IP entered as the search criteria is "2", which does not match the value "1" recorded in the value field. When the values do not match like this, check the jump field of the referenced base unit. You can see that "4" is recorded in the jump field. This means that the base unit with the tertiary index of "2" and the base unit with the tertiary index of "3" must be skipped and a jump must be made to the base unit with the tertiary index of "4". As a result, the base unit with the tertiary index of "4" is referenced.
[0041] When interpreting the values recorded in the class field and value field of the referenced base unit, the question is "Is the value of the second delimiter 2?" Since the value of the second delimiter in the IP entered as the search criteria is "2", it matches the value "2" recorded in the value field. However, it can be seen that "0" is recorded in the index field of the referenced base unit. This means that there is no secondary index in the meta description table. Therefore, the base unit assigned the next sequential tertiary index is referenced. In other words, the base unit with a tertiary index of "5" is referenced.
[0042] When interpreting the values recorded in the class field and value field of the referenced base unit, the question is "is the value of the third delimiter 1?" Since the value of the third delimiter in the IP entered as a search condition is "1", this matches the value "1" recorded in the value field. However, it can be seen that "30" is recorded in the index field of the referenced base unit. In this way, if there is a value recorded in the index field, that value is obtained.
[0043] Then, a secondary index that is the same as the value "30" obtained from the index field is searched for in the meta description table. As a result, a primary index corresponding to the secondary index is obtained. Referring to FIG. 3, it can be seen that the secondary index "30" corresponds to the primary index "200". Once the primary index is obtained, an IP address corresponding to the obtained primary index can be searched for in the pre-stored meta table.
[0044] According to the above-mentioned method, it is possible to approach a section in which the desired data exists within a maximum of 765 (=255+255+255) times. Specifically, it is possible to approach a section in which the desired data exists within 4 to 765 times.
[0045] Referring again to FIG. 1, the LPM table generator 140 converts an IP list with a reference number or more into an LPM (Longest Prefix Matching) table. An LPM table has 256 cells arranged horizontally. Hereinafter, the 256 cells arranged horizontally are referred to as a "reference row". The 256 cells included in the reference row are assigned indexes from 0 to 255 (hereinafter, referred to as "horizontal index"). Each cell can have one of the values 0 and 1. Specifically, among the cells in the reference row, a cell having a horizontal index equal to the value of the first division of an IP included in the IP list is set to a value of "1". For example, assume that the IP list includes the following IPs:
[0046] 192.168.10.232
[0047] 193.168.10.232
[0048] In this case, the values of the first delimiter are 192 and 193. Therefore, among the cells in the base row, the values of the cell with horizontal index "192" and the cell with horizontal index "193" may each be set to 1. The values of all remaining cells may be set to 0.
[0049] Rows containing the same number of cells as the reference row are arranged one after another at the bottom of the reference row. The cells arranged vertically are assigned an index corresponding to the range of values of the first division, an index corresponding to the range of values of the second division, and an index corresponding to the range of values of the third division, in that order (hereinafter referred to as "vertical index"). If an IP included in the IP list corresponds to class C, the range of values of the first division is 192 to 223. The range of values of the second division and the third division are 0 to 255, respectively. Therefore, the cells arranged vertically are assigned a vertical index of 192 to 223 corresponding to the range of values of the first division, a vertical index of 0 to 255 corresponding to the range of values of the second division, and a vertical index of 0 to 255 corresponding to the range of values of the third division, in that order.
[0050] For example, if the IP list contains only the IP "192.168.10.232", an LPM table as shown in FIG. 6 is generated. Since the value of the first division of the IP is 192, the value of the cell with the horizontal index of 192 in the cells of the reference row is set to 1 (cells with a value of 1 are displayed in a different hue than cells with a value of 0). When the value of the first division is 192, the value of the second division is 168, so the row with the vertical index of 192 in the vertical index corresponding to the range of values of the first division is selected, and the value of the cell with the horizontal index of 168 in the cells belonging to the selected row is set to 1. When the value of the second division is 168, the value of the third division is 10, so the row with the vertical index of 168 in the vertical index corresponding to the range of values of the second division is selected, and the value of the cell with the horizontal index of 10 in the cells belonging to the selected row is set to 1. Also, when the value of the third separator is 10, the value of the fourth separator is 232, so the row with a vertical index of 10 among the vertical indexes corresponding to the range of values of the third separator is selected, and the value of the cell belonging to the selected row with a horizontal index of 232 is set to 1.
[0051] After the LPM table is created in this manner, if the IP of the actually collected packet is '192.168.10.232', the process of checking the IP of the collected packet against the IP list will be explained as follows.
[0052] First, a query is made for the value of the first division of the IP. Since the value of the cell with horizontal index 192 in the reference row of the LPM table is 1, it is determined that the value of the first division exists in the LPM table. Therefore, a query is made for the value of the second division. Since the value of the cell with vertical index 192 and horizontal index 168 in the vertical index corresponding to the range of values of the first division in the LPM table is 1, it is determined that the value of the second division exists in the LPM table. Therefore, a query is made for the value of the third division. Since the value of the cell with vertical index 168 and horizontal index 10 in the vertical index corresponding to the range of values of the second division in the LPM table is 1, it is determined that the value of the third division exists in the LPM table. Therefore, a query is made for the value of the fourth division. Since the value of the cell with vertical index 10 and horizontal index 232 in the vertical index corresponding to the range of values of the third division in the LPM table is 1, it is determined that the value of the fourth division exists in the LPM table. In this way, whether or not the corresponding IP is included in the IP list can be determined through a total of four comparison processes, so the number of comparisons can be significantly reduced compared to the conventional method. Specifically, if the number of IPs acquired from the collected packets is n and the black IP list previously held by the company is m, n×m comparisons must be performed in the conventional method. However, by using the LPM table according to the embodiment of the present disclosure, only a minimum of n×1 to a maximum of n×4 comparisons need to be performed, so the number of comparisons can be significantly reduced. And the search speed is improved by the amount of the reduction in the number of comparisons.
[0053] Referring back to FIG. 1, the conversion table generator 150 converts the URLs of collected packets into constantized values. A URL has a text format with no specified length, and converting such a URL into a constantized value means assigning an ID to the URL. Here, the ID may mean a primary key (PK). An example of a conversion table including URLs and constantized values of the URLs is shown in FIG. 7.
[0054] The hash table generating unit 160 generates a hash table of a reference size based on a constantized value. The reference size may be, for example, 65536. However, the reference size is not limited to the illustrated example, and may be smaller or larger than the illustrated example. For convenience of explanation, the following description will be given using an example where the reference size is 65536.
[0055] FIG. 8 is a diagram illustrating a hash table according to an embodiment of the present disclosure.
[0056] Referring to Fig. 8, the hash table includes a hash index and an accumulation value. The hash index is determined as the remainder when the URL ID is divided by 65536. Therefore, the hash index ranges from 0 to 65535. IDs with the same hash index are recorded in order in the corresponding hash index.
[0057] The cumulative value is the cumulative number of IDs recorded in the hash index, in order. For example, it can be seen that a total of 3 IDs are recorded in hash index 0, a total of 4 IDs are recorded in hash index 1, and a total of 2 IDs are recorded in hash index 2. In this case, the cumulative value for hash index 1 is 3+4=7. And the cumulative value for hash index 2 is 7+2=9.
[0058] Such cumulative values can be used to narrow the search range. For example, let's say the URL "naver.com" is entered as a search criterion. Referring to Figure 7, the ID for the URL "naver.com" is 2, so the hash index is also "2". In Figure 8, it can be seen that the cumulative value for hash index 2 is 9, and the previous cumulative value was 7. This means that search results can be obtained with two accesses from the previous cumulative value (7) to the corresponding cumulative value (9), meaning that results can be obtained by searching only metadata from the 7th to 9th accesses.
[0059] FIG. 9 is a flow chart illustrating a fast packet search method according to an embodiment of the present disclosure.
[0060] First, data specialized for search conditions is generated and stored in the database 170 (S910). Here, examples of search conditions include IP and URL. In the case of IP, IPs less than a reference number may be used as the search conditions, or an IP list with a reference number or more may be used as the search conditions. For example, a black IP list containing more than a million IP addresses secured in advance by a company may be used as the search conditions. Examples of data specialized for IP searches with less than a reference number include meta tables, meta description tables, and IP index tables. Examples of data specialized for IP list searches include LPM tables. Examples of data specialized for URL searches include URLs and conversion tables containing constantized values of URLs, and hash tables.
[0061] Thereafter, a packet that matches the input search criteria is searched for based on the data stored in the database (S920).
[0062] In step S920, if the search criteria input is less than the reference number of IPs, an IP index table, a meta description table, and a meta table may be selected from the data stored in the database 170. The value of each delimiter of the IP input as the search criteria is compared with the value determined by the class field and value field of the basic unit of the IP index table. If the comparison shows that the two values match, the secondary index and the primary index are searched in the meta description table using the value of the index field of the basic unit. If the comparison shows that the two values do not match, a jump is made to the basic unit indicated by the value of the jump field of the basic unit. By using the value of the jump field in this way, the number of comparisons is reduced, and the search speed is increased accordingly.
[0063] In step S920, if the input search criteria is a large number of IP lists, an LPM table may be selected from the data stored in the database. Then, the values of each division of the large number of IP lists are compared with the values of each cell of the LPM table. If it is determined during the comparison that the values of each division of the IP list are not recorded in the LPM table, the comparison process is immediately stopped.
[0064] In step S920, if the input search criteria is a URL, a conversion table and a hash table stored in a database may be selected. By referring to the conversion table, an ID corresponding to the URL input as the search criteria is searched for. Thereafter, when the remainder is calculated when the searched ID is divided by 65536, a hash index having the same value as the calculated value and a corresponding accumulation value may be obtained from the hash table.
[0065] The embodiments of the present disclosure have been described above. In the above description, components constituting the high-speed packet search device illustrated in FIG. 1 may be embodied as modules. The module refers to software or hardware components such as a Field Programmable Gate Array (FPGA) or an on-demand semiconductor (Application Specific Integrated Circuit, ASIC), and the module performs a certain function. However, the module is not limited to software or hardware. The module may be configured to be in an addressable storage medium and to execute one or more processors.
[0066] Thus, by way of example, modules include components such as software components, object oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided for in the components and modules may be combined into fewer components and modules or further separated into additional components and modules.
[0067] Meanwhile, the disclosed embodiments may be embodied in the form of a recording medium storing instructions executable by a computer. The instructions may be stored in the form of program code, which, when executed by a processor, may generate program modules to perform the operations of the disclosed embodiments. The recording medium may be embodied in a computer-readable recording medium.
[0068] The computer-readable recording medium includes all kinds of recording media in which instructions that can be decoded by a computer are stored, such as read only memory (ROM), random access memory (RAM), magnetic tape, magnetic disk, flash memory 200, optical data storage device, etc.
[0069] The computer-readable recording medium may also be provided in the form of a non-transitory storage medium. Here, the term "non-transitory storage medium" simply means a tangible device that does not include a signal (e.g., electromagnetic waves), and this term does not distinguish between data being stored semi-permanently in the storage medium and data being stored temporarily. For example, the "non-transitory storage medium" may include a buffer in which data is temporarily stored.
[0070] According to an embodiment, the methods according to the various embodiments disclosed herein may be provided in a computer program product. The computer program product may be traded between sellers and buyers as a commodity. The computer program product may be distributed in the form of a machine-readable recording medium (e.g., compact disc read only memory (CD-ROM)), or may be distributed through an application store (e.g., Play Store™), directly between two user devices (e.g., smartphones), or distributed online (e.g., downloaded or uploaded). In the case of online distribution, at least a portion of the computer program product (e.g., a downloadable app) may be at least temporarily stored or temporarily generated in a machine-readable recording medium, such as the memory of a manufacturer's server, an application store server, or an intermediate server.
[0071] The embodiments of the present disclosure have been described above with reference to the accompanying drawings. Those skilled in the art will understand that the present disclosure can be embodied in other specific forms without changing the technical idea or essential features of the present disclosure. Therefore, the embodiments described above should be understood to be illustrative and not restrictive in all respects. [Industrial Applicability]
[0072] The above-described high-speed packet search method and apparatus can be applied to full-packet analysis-based network detection and response technology fields.
Claims
1. A method for quickly searching for packets that meet search criteria among packets collected from a network, comprising: generating data specific to the search criteria and storing the data in a database; and A high-speed packet search method comprising: searching for a packet that matches the input search condition based on the stored data.
2. The storing step includes: sorting the packets collected from the network based on IP addresses, and assigning primary indexes to the sorted packets to generate a meta table; extracting a first IP located for each same IP section of the meta table and the first index of the first IP located, and assigning a second index to the extracted IP to generate a meta description table; and 2. The method of claim 1, further comprising: generating an IP index table for quickly accessing a secondary index related to an IP input as the search criteria among secondary indexes of the meta description table.
3. The IP index table includes a plurality of basic units, The basic unit includes a class field, a value field, an index field, and a jump field, 3. The method of claim 2, wherein a plurality of said basic units are assigned a tertiary index.
4. The class field records an index indicating the position of each delimiter of the IP included in the meta description table, A delimiter value corresponding to an index of the class field is recorded in the value field, In the index field, a secondary index associated with a value recorded in the value field among secondary indexes of the meta description table is recorded; 4. The high-speed packet search method of claim 3, wherein the jump field records a tertiary index of the basic unit in which a value to be compared next is recorded when the value recorded in the value field does not match the IP value input as the search condition.
5. The searching step includes: A step of comparing the value of each delimiter of the IP input as the search criteria with values determined by a class field and a value field of a basic unit of the IP index table; searching for a secondary index in the meta description table using the value of an index field of the base unit if the two values match as a result of the comparison; 5. The method of claim 4, further comprising the step of jumping to a basic unit indicated by a value of a jump field of said basic unit if the comparison result shows that the two values do not match.
6. The storing step includes: generating a meta table by sorting packets collected from the network based on IP addresses; and 2. The method of claim 1, further comprising the step of: generating a Longest Prefix Matching (LPM) table for a pre-allocated IP list.
7. The LPM table is a reference row including 256 cells arranged along a horizontal direction; and a plurality of rows including the same number of cells as the reference row and arranged vertically along the lower end of the reference row; Cells in said reference row are assigned horizontal indices; 7. The high-speed packet search method of claim 6, wherein the cells arranged along the vertical direction are assigned in order an index corresponding to the range of the first delimiter value of the IPs included in the IP list, an index corresponding to the range of the second delimiter value, and an index corresponding to the range of the third delimiter value.
8. The searching step includes: comparing the values of each delimiter of the IP list input as the search criteria with the values of each cell of the LPM table; and 8. The method of claim 7, further comprising the step of: suspending comparison if the values of each delimiter of the input IP list are not recorded in the LPM table.
9. The storing step includes: sorting packets collected from the network based on URLs, and assigning IDs to the sorted URLs, the IDs being constant values of the URLs; generating a hash table in which the remainder obtained by dividing the ID by a reference size is used as a hash index; recording the IDs having the same hash index in the corresponding hash index of the hash table in order; and 2. The method of claim 1, further comprising the step of: recording a cumulative value for the number of IDs recorded in the hash index.
10. The processor: generating data specific to the search criteria and storing the data in a database in order to quickly search for packets that meet the search criteria among packets collected from a network; and A computer-readable storage medium comprising instructions configured to execute a search for packets that meet the input search criteria based on the stored data.
11. one or more processors; and one or more memories configured to store instructions that cause the one or more processors to perform operations; The above-mentioned work is generating data specific to the search criteria and storing the data in a database in order to quickly search for packets that meet the search criteria among packets collected from a network; and searching for packets that meet the input search criteria based on the stored data.
Citation Information
Patent Citations
Address retrieval circuit
JP1999143888A
Routing information retrieving device and computer readable recording medium having routing information retrieval control data recorded thereon
JP2002016638A
Information collecting device, information collecting method and program
JP2003271670A
Data processing method, data query method in database, corresponding device, and data query device
JP2014010828A
Receiving packet storage apparatus for improving data search performance based on whole packet storage and method therefor
KR101837935B1