KR102537370B1 - Real-time packet analysis method and apparatus for mass network monitoring - Google Patents

Abstract

One aspect of the present invention discloses a real-time packet analysis method for monitoring a large-capacity network in a packet analysis module. The method includes collecting a plurality of packets to be analyzed (the plurality of packets include packets transmitted and received between a first entity and a second entity, at least one of the first entity and the second entity) One includes a computing device or an application instance running on the computing device), analyzes the collected plurality of packets in transaction units, and generates a transaction block (TR Block: TRansaction Block) in units of a predetermined time (Here, the transaction block is a data block in which information on network performance for at least one transaction processed during the predetermined time is generated in a transaction unit) and the generated transaction block is transferred to an analysis information collection device in real time. It includes sending.

Description

Real-time packet analysis method and apparatus for mass network monitoring

The present invention relates to a packet analysis method, and more particularly, to a method of providing a packet analysis result to support real-time monitoring of a large capacity network.

A network generally includes a variety of devices having communication links and communication capabilities connected to the communication links. Here, devices related to the network include computers, peripheral devices, routers, storage devices, and various electrical appliances having communication interfaces with a processor. As used herein, the term "device" typically includes logic devices or other devices having functionality and the ability to process and exchange data, and may include home devices as well as general purpose computers.

Traditional network systems include client devices used by users and various server devices associated with web sites. In general, in order to use a web site, a client device requests access to a server having a specific IP address and accesses it after waiting time. In this case, when a plurality of client devices are flocked by a plurality of users to access the server at a specific time point, performance of a network service associated with the server may be degraded due to a bottleneck. When a service performance or quality problem occurs, the user increases the waiting time due to delay, resulting in a decrease in service utilization rate, which leads to a decrease in productivity and sales. In addition, an increase in IT operating costs may occur, and a server operator and/or a manager of a related business may encounter an unfavorable result of a decrease in corporate competitiveness.

Therefore, it is necessary to quickly identify the cause of the performance degradation and respond to it as quickly as possible. However, there is no appropriate service to clearly identify the cause of such performance degradation, and therefore, an appropriate response cannot be made. That is, there is a problem in that a golden time for performance improvement is missed. In particular, it is more difficult to process data in real time in an environment where large amounts of data are handled.

Additionally, in a cloud environment, since a plurality of servers and/or a plurality of instances performing server roles operate in conjunction with each other, it is difficult to determine performance degradation in a specific part. In addition, since cloud service providers do not easily agree to provide related information through a separate device that monitors it, it is very difficult to monitor network performance of individual servers and/or individual instances in real time.

An object according to an aspect of the present invention for solving the above problems is to provide a real-time packet analysis method for monitoring the performance of a network service that handles large amounts of data and efficiently integrated management thereof.

According to one aspect of the present invention for achieving the above object, a real-time packet analysis method for monitoring a large-capacity network in a packet analysis module includes the steps of collecting a plurality of packets to be analyzed (the plurality of packets are first including packets transmitted and received between an entity and a second entity, at least one of the first entity and the second entity including a computing device or an application instance running on the computing device), wherein the Analyzing a plurality of collected packets in transaction units to generate a TRansaction Block (TR Block) in units of a predetermined time (here, the transaction block is a function of network performance for at least one transaction processed for the predetermined period of time) It is a data block in which information about is generated in transaction units) and transmitting the generated transaction block to an analysis information collection device in real time.

The transaction block includes (i) transaction list (TR List) information including one set of element information of each transaction included in the at least one transaction, and (ii) a list of texts associated with the transaction list information. It may include text list information and (iii) statistical information of network performance indicators for the predetermined period of time.

The set of element information is composed of essential element information of a plurality of categories related to a transaction and includes at least one element information of an individual category, wherein the element information of the plurality of categories includes: (i) the first entity and the element information of the first entity; IP address and port information of the second entity, (ii) time information related to the transaction, (iii) information related to session request and response packets related to the transaction, (iv) real-time data transfer rate information of the session related to the transaction, and (v) ) may include transaction status and result information.

The time information related to the transaction includes transaction start and end time information, transaction RTT (Round Trip Time) information, request transmission time (request time) information, response latency information, and response data transmission time (response time) information. can include

The set of element information further includes a uniform resource locator (url) requested by the first entity or the second entity, information on a domain among the urls, and response header content type information (MIME), The url information, the domain information, and the response header content type information may be expressed as a hash value.

The hash value is matched with one of a plurality of texts included in the text list, and the hash value is composed of a plurality of texts to prevent collision with each other.

When element information currently included in the transaction list is replaced with candidate element information, it may be replaced with candidate element information within the same classification.

The predetermined time ranges from 8 seconds to 12 seconds, and the statistical information is a statistical value of a server-side data transmission speed, a statistical value of a response waiting time, and information about transaction requests and responses in at least one transaction during the predetermined time period. It can include statistics of time and amount of data.

The statistical information may further include information on a total value of HTTP errors generated in at least one transaction for the predetermined time period.

The set of element information for each transaction has a size of 100 to 120 bytes, the transaction list includes information on 10000 or less transactions, and the transaction list is generated with a size of 0.8 to 1.2 MiB. can

The text list includes a hash value and can be created with a size of less than 1 MiB by compression.

The statistical information may be generated in a size of less than 500 bytes.

The transaction block may be generated with a size of less than 2.2 MB as a whole.

The packet analysis module may be embedded in the application instance in the form of an agent.

The transaction block may be generated in units of the predetermined time and provided to the analysis information collection device in real time using HTTP (Hypertext Transfer Protocol).

The packet analysis module includes a first mode, which is a unified analysis mode in which overall packet analysis is performed by the packet analysis module alone, and a second mode, which is a dualized analysis mode in which some of the overall packet analysis is performed by dispersing with the analysis information collection device. Packets are analyzed by selecting one of the two modes, and the analysis result of the first mode may have a greater amount than the analysis result of the second mode.

Selection of one of the first mode and the second mode may be determined by the number of monitoring target servers.

According to another aspect of the present invention for achieving the above object, a packet analysis apparatus for performing real-time packet analysis for monitoring a large-capacity network is a packet collection unit for collecting a plurality of packets to be analyzed (the plurality of packets are Includes packets transmitted and received between a first entity and a second entity, wherein at least one of the first entity and the second entity includes a computing device or an application instance running on the computing device); A transaction block generation unit for analyzing the collected plurality of packets in units of transactions and generating a TRansaction Block (TR Block) in units of a predetermined time (where the transaction block is at least one transaction processed for the predetermined period of time). It is a data block that generates information about network performance in transaction units) and an analysis information providing unit that transmits the generated transaction block to an analysis information collecting device in real time.

According to another aspect of the present invention for achieving the above object, a packet analysis system for performing real-time packet analysis for monitoring a large-capacity network includes a plurality of packets to be analyzed - the plurality of packets are a first entity ) and a second entity, wherein at least one of the first entity and the second entity includes a computing device or an application instance running on the computing device, including packets transmitted and received between them, TRansaction Block (TR Block) in a first time unit by analyzing in a transaction unit - The transaction block is data generating information on network performance in a transaction unit for at least one transaction processed during the first time A packet analysis device that generates a block and transmits the generated transaction block to the analysis information collection device in real time and an analysis information collection device that receives the transaction block, performs additional performance analysis, and stores it in a repository. can include

The additional performance analysis may include calculating a network performance indicator in units of a second time, and the second time may be longer than the first time.

The analysis information collection device may specify the first time, which is a time unit to be processed from statistical information included in the transaction block, and element information included in a transaction list included in the transaction block, and notify the packet analysis device. there is.

According to the real-time packet analysis apparatus and method for monitoring a large-capacity network of the present invention, there is an effect of preemptively responding to network performance problems in a network environment (including a cloud environment) in which large-capacity packets are transmitted and received.

1 is a conceptual diagram showing a system to which a real-time packet analysis method for monitoring a large capacity network according to an embodiment of the present invention is applied;
2 is a conceptual diagram showing a cloud environment to which a real-time packet analysis method for monitoring a large capacity network according to another embodiment of the present invention is applied;
3 is a conceptual diagram showing a system to which a real-time packet analysis method for monitoring a large capacity network according to another embodiment of the present invention is applied;
4 is a detailed block diagram showing the configuration of a packet analysis module according to an embodiment of the present invention in detail;
5 is a conceptual diagram specifically showing the configuration of a transaction block generated by the packet analysis module of FIG. 4;
6 is a table specifically showing the configuration of detailed element information of a transaction list in the transaction block of FIG. 5;
7 and 8 are conceptual diagrams showing network RTT (Round Trip Time) indicators between a user and a server calculated by a packet analysis module according to an embodiment of the present invention;
9 is a conceptual diagram showing a delay index calculated by a packet analysis module according to an embodiment of the present invention;
10 is a conceptual diagram showing an indicator of the number of sessions waiting for a server response calculated by a packet analysis module according to an embodiment of the present invention;
11 is a conceptual diagram showing CPS/TPS (Connection Per Second/Transaction Per Second) indicators calculated by a packet analysis module according to an embodiment of the present invention;
12 is a table specifically showing the configuration of a text list in the transaction block of FIG. 5;
13 is a table specifically showing the configuration of statistical information in the transaction block of FIG. 5;
14 is a detailed block diagram for specifically explaining the configuration of an analysis information collection device that collects analysis information from a packet analysis module.

Since the present invention can make various changes and have various embodiments, specific embodiments are illustrated in the drawings and described in detail.

However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

Terms such as first and second may be used to describe various components, but the components should not be limited by the terms. These terms are only used for the purpose of distinguishing one component from another. For example, a first element may be termed a second element, and similarly, a second element may be termed a first element, without departing from the scope of the present invention. The terms and/or include any combination of a plurality of related recited items or any of a plurality of related recited items.

It is understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, but other elements may exist in the middle. It should be. On the other hand, when an element is referred to as “directly connected” or “directly connected” to another element, it should be understood that no other element exists in the middle.

Terms used in this application are only used to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this application, the terms "include" or "have" are intended to designate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, but one or more other features It should be understood that the presence or addition of numbers, steps, operations, components, parts, or combinations thereof is not precluded.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related art, and unless explicitly defined in the present application, they should not be interpreted in an ideal or excessively formal meaning. don't

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in more detail. In order to facilitate overall understanding in the description of the present invention, the same reference numerals are used for the same components in the drawings, and redundant descriptions of the same components are omitted.

1 is a conceptual diagram illustrating a system to which a real-time packet analysis method for monitoring a large capacity network according to an embodiment of the present invention is applied. As shown in FIG. 1, a system according to an embodiment of the present invention includes client terminals 110-1 to 110-N, a network 120, a server terminal 130-1 to 130-N, and a packet analysis module. (140-1 to 140-N) and the analysis information collection device 150.

Referring to FIG. 1 , client terminals 110 - 1 to 110 -N access a specific web site and/or web application through a network 120 . At this time, access may be made through a url (Uniform Resource Locator) associated with the web site and/or web application. When connected to the above url, it communicates with the server stages (130-1 to 130-N) that execute the operation at the corresponding address. The client terminals 110-1 to 110-N access a specific web page through a web browser and request execution of a desired page or application. The request may include not only static content such as an HTML document, but also multimedia content such as video and audio, and/or execution of other applications.

According to an embodiment of the present invention, the client terminals 110-1 to 110-N are arbitrary devices that are operated by users and include communication functions (including Internet access and web browser execution functions) and data processing functions. can include The client terminals 110-1 to 110-N include a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, fixed or mobile. Subscriber Unit, Subscriber Station (SS), Cellular Telephone, Wireless Device, Wireless Communication Device, Wireless Transmit/Receive Unit (WTRU), Mobile Node, Mobile, Mobile Station , personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, consumer electronic device (CE), or other terms. Various embodiments of the client terminals 110-1 to 110-N include a cellular phone, a smart phone with a wireless communication function, a personal digital assistant (PDA) with a wireless communication function, a wireless modem, a portable computer with a wireless communication function, A photographing device such as a digital camera having a wireless communication function, a gaming device having a wireless communication function, a music storage and playback home appliance having a wireless communication function, and an Internet home appliance capable of wireless Internet access and browsing, as well as integrating combinations of such functions. It may include portable units or terminals that are being used, but are not limited thereto.

Each of the client terminals 110-1 to 110-N may include a user interface including input means such as a mouse and keyboard for receiving user input and output means such as a display unit. The user interface may include a graphical user interface (GUI) for providing information to a user. It also includes a communication interface for the user to interact with the networked devices.

Network 120 includes wired and/or wireless networks. Network 120 may include the Internet. The network 120 uses a serial bus that provides a physical layer (medium) to transmit and receive data between variously connected client terminals 110-1 to 110-N and server terminals 130-1 to 130-N. can include Here, the serial bus may include a 1394 serial bus. This may support both time-multiplexed audio/video (A/V) streams and standard IP (Internet Protocol) communication (eg, IETF REC 2734), but is not necessarily limited thereto. . Network 120 may also include non-1394 networks (eg, Ethernet, etc.). Network 120 may also include a home network. Each of the client terminals 110-1 to 110-N may communicate with one or more server devices 130-1 to 130-N in the network 120.

Server stages 130-1 to 130-N respond to user requests by using network 120 resources to provide services to users. This includes the return of information (data). It also includes the performance of a function (e.g., a mechanical function) and return of state, the return of data stream and state, the acceptance of data stream and return of state, or the storage of state for various actions. Server stages 130-1 to 130-N may include custom, built-in, and control programs to implement control of their own hardware.

The server stages 130-1 to 130-N may be associated with a specific web site and/or web application, and perform operations and data management related to work performed in each web site and/or web application. The server nodes 130-1 to 130-N may interact with the client terminals 110-1 to 110-N and other servers 130-1 to 130-N. Exemplary services may include MPEG sourcing/sinking and display services.

Server stages 130-1 to 130-N provide interface data (e.g., HTML, XML, Java, JavaScript, GIF, JPEG, MPEG, graphic information as a file or any other format used for its intended purpose). In certain embodiments, each of the servers 130-1 through 130-N may process information such as one or more Hypertext Markup Language (HTML) that provides command and control of the device. Server stages 130-1 to 130-N use Internet standards to represent HTML pages using a browser technique.

According to an embodiment of the present invention, the server stages 130-1 to 130-N include a web server 130-1, an app server 130-2: an APP server, and a database server 130-N: a DB server. can include However, the server side does not necessarily have to consist of only a combination of three servers. It is effective that only the web server 130-1 exists and the app server 130-2 and database server 130-N do not exist, or it is possible to configure only one app server 130-2, and other Server combinations of various types and tiers are also possible. Each server constituting the server stages 130-1 to 130-N will be described later.

The server stages 130-1 to 130-N may be formed as a group of a plurality of servers for processing large-capacity packets. In some cases, this may be configured in the form of a large-scale server farm with more than about 1000 servers. Since the number of packets transmitted and received in such a large group of servers is too large, it is difficult to analyze all packets with one packet analysis device. In this case, a method of performing analysis through sampling may be considered, but the analysis result through sampling has a problem in that the reliability of the analysis result is determined according to the unit of sampling, and the cause of the problem is determined after the problem occurs. There is also a problem that there is a limit to tracking.

Meanwhile, devices of the client terminals 110-1 to 110-N and the server terminals 130-1 to 130-N may transmit and receive packets through the network 120. In this specification, they may be referred to as one object or entity without being divided into a server and a client.

The packet analysis devices 140-1 to 140-N analyze packets transmitted and received between a plurality of servers and/or clients constituting the server ends 130-1 to 130-N, and the analysis results are analyzed by an analysis information collection device ( 150) is provided. In particular, in order to analyze all of the packets from a fairly large number of servers 130-1 to 130-N, the packet analysis devices 140-1 to 140-N corresponding to each server are individually 130-1 to 130-N) to perform primary packet collection and analysis, and provide the results to the analysis information collection device 150 for secondary final analysis. desirable. That is, it is desirable to perform real-time analysis by dualizing the analysis.

In this embodiment, the packet analysis devices 140-1 to 140-N are configured in terms of software and may form one functional block in the server device. Since it is not a separate hardware device, it can be called a packet analysis module or module. The packet analysis modules 140-1 to 140-N are embedded to efficiently perform real-time analysis in the server stages 130-1 to 130-N that process large amounts of data. A 1:1 correspondence relationship between the server and the module is suitable, but a 1:many relationship is also possible. For example, one packet analysis module may correspond to two or more servers, and vice versa.

In order to analyze a plurality of packets transmitted and received in a large-capacity network in real time, the embedded modules (140-1 to 140-N) provide the first analysis result of the packet to the analysis information collection device 150, and the first With the analysis result, the analysis information collection device 150 secondarily performs higher-level analysis and responds to user requests. In this sense, the packet analysis modules 140-1 to 140-N may be referred to as primary analysis devices, and the analysis information collection device 150 may be referred to as secondary analysis devices. In order to efficiently share analysis results between the two parties, it is necessary to divide the entire analysis process. And, it is desirable to share the contents so that a complete analysis can be made as a whole. The analysis information collection device 150 shares the primary packet analysis method and analysis process in the module. In addition, in order to efficiently process related tasks such as transmission and reception of primary analysis results and data storage, it is desirable to synchronize with each other. That is, the overall packet analysis is divided between the packet analysis modules 140-1 to 140-N and the analysis information collection device 150, but it is possible to analyze the packets by distributing the analysis without overlapping as much as possible. desirable.

The packet analysis modules 140-1 to 140-N perform primary analysis on packets exchanged with clients or other servers for individual servers into which they have been inserted, and provide them to the analysis information collection device 150. . The analysis information collection device 150 collects the individual transaction blocks 142 generated by the primary analysis and performs additional analysis and applications (filtering, warning, browsing, etc.) according to the analysis results.

The packet analysis modules 140-1 to 140-N may directly collect and analyze packets, or may analyze mirrored packets by mirroring them. Even if it is described as a mirrored packet, it is obvious to those skilled in the art that directly collected packets can be used and vice versa.

The packet analysis modules 140-1 to 140-N perform network analysis based on various pieces of information included in mirrored packets (eg, source ID, destination ID, and time information). Various indicators representing service performance can be calculated in real time. Calculation of indicators may be performed in units of transactions. About 30 indicators can be calculated. The modules 140-1 to 140-N form data blocks and provide them to the analysis information collection device 150. This block of data may be referred to as a transaction block 142 .

As described above, the packet analysis modules 140-1 to 140-N may be used in an environment where real-time is important. The modules 140-1 to 140-N primarily analyze packets in transaction units and provide the analyzed information to the analysis information collection device 150. At this time, the modules 140-1 to 140-N may collect packets for a predetermined period of time (eg, 10 seconds, 20 seconds, etc.) and analyze header information included in the collected packets. . Then, the transaction block 142 is generated by analyzing the packet header information in units of transactions. The transaction block 142 includes information on one or a plurality of transactions. The one or more transactions may be transactions that can be processed within 10 seconds. It is obvious that the part described as 10 seconds in this specification can be interpreted by replacing it with any other predetermined time set by user setting. For example, it may be replaced with times such as 1 second, 2 seconds, 5 seconds, 8 seconds, 10 seconds, 15 seconds, 20 seconds, and 30 seconds. However, it may be efficient to perform the analysis in units of 8 to 12 seconds. More preferably, it is good to analyze every 10 seconds.

The transaction block 142 includes information about transactions for 10 seconds. That is, a transaction that can be processed within 10 seconds is analyzed and transmitted to the analysis information collection device 150 . The modules 140-1 to 140-N generate these transaction blocks 142 at regular time intervals (eg, 10 seconds) and provide them to the analysis information collection device 150. In other words, it is called real-time, but real-time here can be interpreted as "quasi-real-time", and in fact, it can be seen that data (packets) are collected in units of 10 seconds, and blocks are generated based on the analysis and transmitted to other devices. can

About 30 pieces of information may be included in the transaction block 142 . This includes IP and port information of the transmitting entity (either the client terminal or server-side servers) and the receiving-side entity (also either the client terminal or server-side servers), and time information related to the transaction. , information related to transaction request and response packets, real-time data transfer rate information of a session related to a transaction, transaction status information, and transaction result information. This detailed information will be described in more detail with reference to FIG. 5 .

The transaction block 142 is preferably created in an appropriate size in order to perform data processing in a line that does not burden the device and to ensure minimum real-time performance accordingly. Its size is preferably less than 2.2 MB. These sizes and specifications need to be treated very seriously when considering the correlation between the guarantee of real-time and the diversity of packet analysis information (accuracy of network monitoring accordingly). Although more than 100 performance indicators can be extracted through packet analysis, the transaction block 142 is provided to the device 150 after relatively simplifying the provided information, considering the conditions of large-capacity network and real-time analysis. It comes with basic statistics (including, for example, data transfer rates, delays, and errors related statistics for transactions lasting about 10 seconds). In one example, the transaction block 142 may include information about about 10,000 transactions. In one transaction, the calculated indicator may include some indicators considered essential among 120 types of detailed information (candidate element information).

Meanwhile, the transaction block 142 may be provided to the analysis information collection device 150 in units of a predetermined time (eg, 8 to 12 seconds, more preferably 10 seconds) using HTTP (Hypertext Transfer Protocol). there is.

The analysis information collection device 150 is a device that receives the transaction block 142 provided in real time. The analysis information collection device 150 may be implemented as a separate device that additionally performs analysis information. In some cases, it may be implemented as a user-side terminal device that receives transaction block 142 information through the network 120 like the general client terminals 110-1 to 110-N. In addition, the analysis information collection device 150 additionally analyzes the transaction block 142 secondly, and then provides the corresponding information to the terminals 110-1 to 110-N of the user, providing users with network performance and security. It can also act as a device that provides related information.

The analysis information collection device 150 secondarily calculates an index related to network performance based on the transaction block 142, and determines whether there are problems such as speed delay, waiting delay, traffic excess, and error occurrence in a section. It can be judged for each specific section of the stage and visualized so that the operator or manager can check the judgment result. Here, the operator or manager includes a network operator or network manager. Through this, the error section is quickly identified, and based on this, a response to the error section can be quickly made.

In another embodiment, there may be a system in which only the packet analysis modules 140-1 to 140-N exist without the analysis information collection device 150. In this case, an analysis result in the form of a transaction block 142 may be provided.

Meanwhile, the packet analysis modules 140-1 to 140-N and the analysis information collection device 150 can track access from malicious users (related to security issues) with the packet analysis results, and respond to them in real time. to make it possible to

The server stages 130-1 to 130-N will be described in more detail. The web server 130-1 is a server that provides requested content to web clients. The web server 130-1 may provide images such as static HTML, JPEG, or GIF to a web browser through an HTTP protocol. In some cases, the web server 130-1 may also embed a container capable of operating an internal application.

The app server 130-2 may also be called a web application server (WAS) server, and represents a middleware software server that provides transaction processing and management and an application execution environment in a client/server environment. Typically, the server end (130-1 to 130-N) can be built as a three-tier web computing environment of a web server, application server, and database. At this time, the app server 130-2 is an application in a client/server environment. It acts like a server. The app server 130-2 provides an application execution environment and a database access function, manages transactions, performs business logic for processing tasks, and performs application linkage between different types of systems.

According to an embodiment of the present invention, effective distribution can be induced through functional classification of the web server 130-1 and the WAS 130-2. Static data can be structurally processed by the web server 130-1 in the front, and dynamic data can be processed by the WAS 130-2 in the back. For example, with respect to a user's request, static data such as HTML, JavaScript files, CSS, images, etc. are placed and processed in the front web server 130-1 to prevent the service request from passing to the WAS 130-2. In addition, by handing over the web application service to the WAS 130-2 located behind it, the WAS 130-2 can focus on performing the web application. A method of processing what is to be processed by the web server 130-1 and what is to be handed over to the WAS 130-2 can be processed through the configuration of the web server 130-1. The web server 130-1 handles whether to transfer specific extensions or directory tasks to the WAS 130-2.

The database server 130-N is a storage in which various data handled by the web server 130-1 and/or the app server 130-2 are stored. The database server 130-N may store a huge amount of data related to the work processed by the web server 130-1 and/or the app server 130-2, depending on the nature of the website or web application. there is. This may include personal information, organization information, and data related to various contents (eg, multimedia contents).

2 is a conceptual diagram illustrating a cloud environment to which a real-time packet analysis method for network monitoring according to another embodiment of the present invention is applied.

Referring to FIG. 2 , the packet analysis module 220 may operate in a cloud environment. A plurality of app instances 210 may exist in the cloud environment. One app instance 210 may be a functional block that performs one or more services. It may be a software program for the execution of one or more functions or features or services. Alternatively, the app instance 210 is used by a specific customer (or subscriber, end-user, terminal or server, etc.) by a virtual machine, processor, or computing device ( 210) may be associated with a process or task that executes a program. This may be a concept corresponding to a virtual network function-instance (VNF-I) in a network function virtualization (NFV) environment. In some cases, an instance may be interpreted as a concept corresponding to the entity described above. An app instance 210 may be referred to as an instance. Meanwhile, in one example, a plurality of instances 210 may be connected to form one service chain.

The packet analysis module 220 according to an embodiment of the present invention may be inserted into one instance 210 in the form of an agent and analyze packets transmitted and received by the instance 210 . Packets include packets transmitted and received between the corresponding instance and clients and packets transmitted and received with other instances. The packet analysis module 220 may generate a transaction block by analyzing the packets in units of a predetermined time, and then provide the transaction block to the external analysis information collecting device 232 .

According to an embodiment of the present invention, the packet analysis module 220 is composed of a plurality of packets and can process packets of about 1000 instances 210 . At this time, the correspondence relationship between the instance 210 and the packet analysis module 220 is preferably 1:1, but 2:1, 3:1 or more to 1, and/or 1:2, 1:3, 1: You may have multiple relationships. This can be made to correspond on a service chain basis. These multiple packet analysis modules 220 can process up to 1 million TPS (Transaction Per Second). That is, an average of 1000 TPS per instance 210 can be processed. That is, it can be processed with 1M TPS.

Also, all transactions occurring in all instances 210 may be processed. More specifically, it can process information related to HTTP, information related to the WAS server, and/or SQL (Structured Query Language). The packet analysis module 220 may target packet analysis of each instance 210 in a large-capacity network in a cloud environment in real time. Therefore, in order to ensure real-time, as described above in FIG. 1, packets are collected in units of a certain time, and packet analysis results are derived in units of transactions, but basic statistics are provided to the analysis information collection device 230 It is desirable to operate in the form Accordingly, a plurality (about 1000) of packet analysis modules 220 may process about 10000 transactions in 8 to 12 second units (more preferably, 10 second units). At this time, each packet analysis module 220 performs synchronization and provides the transaction block to the analysis information collection device 230 at intervals of 10 seconds. That is, for stability of traffic flow, different packet analysis modules 220 may be synchronized to sequentially transmit 10-second transaction blocks at predetermined times (different times). In some cases, transaction blocks may be transmitted simultaneously in a synchronized state.

Meanwhile, as described above, when a plurality of instances 210 constitute one service chain, at least one of the packet analysis modules 220 inserted in the instances 210 constituting the service chain is a corresponding service chain. A transaction block can be created by analyzing packets transmitted and received. At this time, it is possible to analyze transactions in service chain units as well as in instance units. In addition, if it is recognized through the packet analysis result that the plurality of instances 210 operate as one service chain, some or only one of the plurality of packet analysis modules 220 associated with the plurality of instances 210 are represented. As a service chain unit, packet analysis can be performed. At this time, since the individual instances 210 operate in units of service chains and simultaneously operate individually, packet analysis for the individual instances 210 can also be performed.

The analysis information collection device 230 is implemented as one device and may include a plurality of modules 232 , 234 , 236 , and 238 . The analysis information collection device 230 may include a collection module 232 , an indexing module 234 , a warning module 236 and a browsing module 238 . Transaction block data generated by packet analysis modules 220 is collected by collection module 232 . The collection module 232 receives the transaction block and stores it as a temporary file, sorts it, and stores it in the mass storage 240 (repository). The storage 240 includes cloud file storage (mass storage). For example, it can be implemented with storage such as Amazon EFS (Elastic File System), EFS IA, Google Cloud, Microsoft Azure, etc.

When data is stored in the storage 240, the indexing module 234 indexes the data stored in the storage 240 using an offset. The alert module 236 executes an alert state machine on the stored or filtered data to generate an alert signal as appropriate. The browsing module 238 may perform a basic search through an indexing field in response to a user search input and perform an additional search using a filtering field. Through this, the final search result for user input is sorted and output. This will be described in more detail with reference to FIG. 14 .

Meanwhile, the analysis information collection device 230 may be implemented as a plurality of devices by being implemented as an individual device in units of modules.

3 is a conceptual diagram illustrating a system to which a real-time packet analysis method for network monitoring according to another embodiment of the present invention is applied.

Referring to FIG. 3 , the packet analysis device 340 may be connected to a switch (not shown) and obtain mirroring of all packets provided to the servers 330-1 to 330-2 through the switch. In this case, packet mirroring may be performed in a switch. The switch copies the packet provided to the servers 330-1 to 330-2, sets the port connected to the packet analysis device 340 as a destination port, and provides the packet to the packet analysis device 340. can do. In this case, the corresponding port may be designated and provided for analysis purposes.

The packet analysis device 340 is between the network 320 and the web server 330-1, between the web server 330-1 and the app server 330-2, and between the app server 330-2 and the database server. It can be placed in at least one. The packet analysis device 340 is between the network 320 and the web server 330-1, between the web server 330-1 and the app server 330-2, and between the app server 330-2 and the database server. The performance of the network service is diagnosed for each section based on packets transmitted and received between two entities connected to at least one switching device (not shown) or mirrored packets.

According to the above embodiment of the present invention, since mirrored packets can be generated by copying packets that are actually transmitted and received (actually used user traffic), there is no need to create separate artificial test packets for performance diagnosis of network services. does not exist. In particular, the packet analysis device 340 can monitor all packets, not some packets sampled through this method.

According to the embodiment of FIG. 3 , the packet analysis device 340 and the analysis information collection device 350 may be implemented as hardware connected to the switching device. Accordingly, it may not be required to install an agent that substantially imposes a load on the server ends 330-1 to 330-2. In this case, a burden such as slowing down the working speed of the server stages 330-1 to 330-2 is not applied.

The packet analysis device 340 generates a transaction block 342 based on the contents of the primary packet analysis and provides it to the analysis information collection device 350 . At this time, the network performance for each section can be grasped using the packet analyzer 340 disposed in different sections.

4 is a detailed block diagram showing the configuration of a packet analysis module according to an embodiment of the present invention in detail. As shown in FIG. 4 , the packet analysis module according to an embodiment of the present invention may include a packet receiving unit 410 , a transaction block generating unit 420 and an analysis information transmitting unit 430 .

Referring to FIG. 4 , the packet receiving unit 410 collects packets transmitted and received by a specific device or a specific instance. The packet receiving unit 410 may be implemented in software or may be provided in the form of a port in hardware. The packet receiver 410 provides the received packet to the transaction block generator 420 .

The transaction block generating unit 420 analyzes the packets collected in real time by the packet receiving unit 410 in units of transactions to calculate a performance indicator, generates text information, associates it with the performance indicator information using a hash value, and based on this After generating brief statistics related to performance indicators for a unit period, a transaction block is generated by combining the performance indicator information and the statistical information. That is, the transaction block generator 420 includes a transaction list including performance indicator information, a text list listing texts associated with the transaction list, and a transaction block including 10-second statistical information that is statistical information on 10-second transactions. generate

The transaction block generator 420 may analyze headers of collected packets. Through this, it can be distinguished whether it is an HTTP packet, a packet related to a DB, or a packet related to TCP. Through this, you can check to which server the request information such as "GET/web address/HTTP/1.1" was sent. The transaction block generator 420 parses and parses the packet header information. In the above embodiment, "GET" becomes a request message, and "web address" indicates a web address associated with the request. In addition, "HTTP/1.1" means HTTP 1.1 version, and language information (eg, ko-kr) associated with the packet may also be checked and stored. In addition to GET, request methods such as POST, HEAD, PUT, and DELETE may be transmitted depending on circumstances.

The transaction block generating unit 420 assigns an index to each packet, and based on the assigned index, determines which packet it is, whether the corresponding packet is an HTTP-based request packet, or a response packet to it. At this time, a comparative analysis with information obtained from packets received in the past is also performed. That is, if there is a request packet obtained from the first entity, there may be a response packet thereafter from the second entity. At this time, at least two packets in time series, packets transmitted and received from the first entity and the second entity It is possible to analyze the establishment of a session and the flow of transactions therein by grasping the relationship.

In addition, the transaction block generator 420 may parse which browser was used by the client terminal related to the device to be analyzed or the instance to be analyzed, information related to the HOST, previous url address information, and browser support language information. At this time, it is possible to analyze what type of header (general header, request header, or entity header) the header is, and parse information indicating the boundary between the header and the payload.

Then, the transaction block generating unit 420 may analyze the url (Uniform Resource Locator) (or URI (uniform resource identifier)), source IP (Source_ip), destination IP (Dest_ip), and time information of the collected packets. . Here, if you check the url value, you can see which address the packet is being redirected to, such as "https://www.google.co.kr/?gws_rd=ssl". In addition, the source IP may indicate the IP address of the client terminal, and the destination IP may indicate the IP of the server associated with the final destination site of the request. In the case of a response packet, opposite information may be indicated. Time information may be provided in a timestamp format. In addition, length information (length) of the entire packet may be checked.

The transaction block generation unit 420 includes packet analysis algorithms corresponding to various protocols such as HTTP, IP, UDP, TCP, and DNS, and adaptively generates url and source IP from packets according to each protocol. , destination IP and time information can be extracted and used for analysis.

Based on the packet-related information extracted through the secondary analysis, a transaction block is created by calculating about 30 sets of performance indicator information per transaction. The 30 pieces of performance indicator information included in the transaction block are composed of items considered essential among the performance indicator information of 120 elements. This may be pre-selected. However, this may be variable through user settings. Extraction or selection of about 30 or so items considered essential among these 120 or so candidate element performance indicators may be considered very important in processing large packets. About 30 element performance indicators included in the transaction block will be described in detail with reference to FIG. 6 . Here, we introduce about 120 performance indicators that can be included in the transaction block.

The transaction block generator 420 analyzes and processes about 1000 transactions per second. Since it is generated in about 10 second units, 10000 transactions can be analyzed and processed in 10 seconds. Assuming that these packet analysis modules are attached to 1000 instances, about 10 million transactions can be processed in units of 10 seconds and provided to the secondary collection device, the analysis information collection device.

The transaction block generating unit 420 allows information to be described in text among the calculated performance indicators to be separately managed in a text list. That is, a text list is created separately, and the two are associated so that a specific text in the text list is mapped to a specific performance index of a transaction list composed of a combination of performance indicators. In this case, a hash value may be used.

The transaction block generating unit 420 calculates a basic statistical value based on the calculated set of performance indicators (about 30 performance indicators). That is, a 10-second average or 10-second snapshot information is calculated to generate a statistics list. Then, the transaction block generator 420 synthesizes the calculated performance indicator information, text list, and basic statistical values to generate a 10-second transaction block.

The analysis information transmission unit 430 provides the transaction block and/or other information generated by the transaction block generation unit 430 to the analysis information collecting device. More specifically, it is provided as a collection module of an analysis information collection device.

On the other hand, in an embodiment of the present invention, the packet analysis module divides the first mode, which is a unified analysis mode that performs analysis performed by the analysis information collection device, and part of the analysis information collection device and analysis process to perform dual analysis It can operate selectively with the second mode. That is, the unified analysis mode (first mode) may be a mode for calculating all 120 network performance indicators. The dual analysis mode (second mode) is a distributed execution mode that interworks with the analysis information collection device, and calculates only about 30 essential performance indicators and provides them to the analysis information collection device in the form of a transaction block. At this time, selection of this mode may be adaptively determined according to the following parameters. Parameters that determine this include at least one of the number of packets/byte per unit time, traffic speed, delay time, number of waits, and number of monitoring target servers. That is, a parameter value as a standard is set in advance, and when a situation exceeding the standard parameter value occurs, the first mode is changed to the second mode, and while operating in the second mode, a network having a value lower than the standard parameter value again When the state is detected, it may be controlled to change to the first mode. For example, assuming that the reference value of the network monitoring target server (or instance) is 100, and monitoring of less than 100 servers is performed, the device operates in the first mode and then the management target server monitors 100 servers. If passed, the second mode can be operated.

FIG. 5 is a conceptual diagram specifically illustrating the configuration of a transaction block generated by the packet analysis module of FIG. 4 . As shown in FIG. 5 , a 10-second transaction block generated from a packet analysis module attached to one app instance may include 10-second statistical information, text list, and transaction list information.

Referring to FIG. 5 , the transaction list includes detailed information on transactions in units of 10 seconds. This may include information on up to 10,000 transactions. For one transaction, about 30 element information, that is, performance indicator information may be included. This is about 30 pieces of information that are considered essential among 120 candidate performance indicators, and can be called a set of element information. This may be preset by user setting. The element information for one transaction may have a size of 100 to 120 Bytes, and the 10-second transaction list is preferably generated with a size of about 0.8 to 1.2 MiB as a whole. More preferably, it is good to have a size of 1.07 MiB or less.

The text list is a list of text information of the transaction list. The text includes information such as url, domain, content type, and DB query statement. This can be linked with information (performance indicator) of any one element of the transaction list through a hash value. A text list is created with a size of 2 MiB or less, and can be created with a size of less than 1 MiB through compression.

Statistical information in units of 10 seconds includes average performance indicator information for 10 seconds or snapshot information in units of 10 seconds. This may include about 30 pieces of statistical information, and may have a size of about 300 to 500 bytes. More preferably, it may have a size of 380 to 416 bytes.

When the 10-second statistical information, text list information, and transaction list information included in the transaction block are merged, it is preferable to have a size of 1.8 MB to 2.2 MB as a whole, more preferably 1.9 MB to 2.07 MB. Hereinafter, the configuration of each of the information in the transaction list, the information in the text list, and the 10-second statistical information will be described in more detail.

FIG. 6 is a table specifically showing the configuration of detailed transaction information in the transaction block of FIG. 5 .

Referring to FIG. 6 , a transaction list included in a transaction block includes detailed information (element information) on one transaction. This includes client_ip, server_ip, client_port, and server_port information. This represents client IP information, server IP information, client port information, and server port information, respectively. In this case, the client_ip and server_ip information may have a size of 4 bytes by using a string as a unit (eg, 222.103.141.187). The client_port and server_port information may have a size of 2 bytes by using a number as a unit (eg, 1254 or 80).

Next, the transaction block may include receive_time information as information about the packet reception time. It may have a size of 4 bytes.

Next, the transaction list may include information related to the start and end of a transaction. This may include start_usec information, end_usec information, and fin_usec. This is based on the source ip, destination ip and time information of the packet, the same source (e.g., client) and destination (e.g., server) give a request packet within a certain time period and receive all related data. can be obtained by analyzing Each of these may have a size of 4 bytes.

The start_usec information may be a time when a transaction is completed and started (eg, 2012-07-18 22:33:06.288370). end_usec information indicates the transaction end time in units of milliseconds. fin_usec information represents the complete end time of a transaction in units of one millionth of a second.

In relation to transaction start and end, candidate element information that may be included in the transaction list includes start_time information, end_time information, and fin_time information. The start_time information indicates the transaction start time (year month day hour minute second: eg 2012-07-18 22:33:06). The start_usec information described above may be combined with the start_time to become a completion time (eg, 2012-07-18 22:33:06.288370). end_time information represents the transaction end time. That is, it indicates the end of data (the time when the last response data of the transaction was received). For example, it can be expressed as 2012-07-18 22:33:12. The fin_time information represents the time when a transaction is completely terminated, such as when a next transaction comes after a transaction ends, a transaction completes (receives fin), or ends due to a timeout. For example, it can be expressed as 2012-07-18 22:35:23. Candidate element information may be included in the transaction list instead of or additionally to element information set to be included in the transaction list at a specific point in time according to a user's setting or network state change. That is, when the number of packets per unit time increases by more than the reference parameter value, start_time information may be included in the transaction list instead of start_usec information. Substitution of candidate elements takes into account the classification of transaction detailed information (eg, transaction start/end time information classification, transaction latency information classification, session response/request packet classification, transaction status/result classification, etc.) in the same classification. It is desirable to make it happen. In another example, in a state where start_usec information is included, start_time information may be additionally included in the transaction list.

Next, the transaction block may include RTT information, request time information, and response and request time information (including delay information) related to response delay time. This can be expressed as tran_client_rtt, tran_req_time, tran_latency and tran_rsp_time. Each of these pieces of information may have a size of 4 bytes.

Here, tran_client_rtt information represents the real-time RTT of a client in a corresponding transaction. tran_req_time is information about request transmission time, indicating the time from when a plurality of requests from the client to the server start to be transmitted to the time when the request reaches the server.

The tran_latency information indicates transaction response latency. This represents the waiting time from when the client sends the request to receiving the first data from the server. It is in units of one millionth of a second. For example, it may have a value of 76328. tran_rsp_time is a transaction response time and represents the transmission time of response data. That is, it indicates the time when the server transmits the response data. Again, units of one millionth of a second are used.

Hereinafter, a method of calculating an RTT value, a request transmission time value, a response waiting time value, and a response data transmission time value will be described in more detail using FIGS. 7 to 9 .

7 and 8 are conceptual diagrams illustrating a network RTT (Round Trip Time) indicator between a user and a server calculated by a packet analysis module according to an embodiment of the present invention.

Referring to FIG. 7 , the packet analysis module calculates round-trip arrival time (RTT) information of a packet on a network between a user and a server. When the packet analysis module operates in the form of an agent to an instance, an attached instance may correspond to a server. A packet analysis module is assumed to be between the client and the server. Assuming a basic synchronization scenario, the first client transmits a synchronization signal (SYN), the server receives it, the server transmits a synchronization signal and a response signal (ACK) together in response to the received synchronization signal, and the client sends the server A response signal (ACK) may be transmitted in response to a signal from. The transmission and reception of these three signals can be called a 3-way handshake.

In this signal transmission scenario, since the packet analysis module is located between the client and the server, the packet arrives at the packet analysis module at time T1, which is earlier than the time when a synchronization signal (SYN) arrives at the actual server from the client. And, the synchronization signal and the response signal from the server arrive at the packet analysis module at a time T2 earlier than the arrival time of the client. Finally, the response signal (ACK) from the client arrives at the packet analysis module at time T3 earlier than the arrival time from the server.

In this relationship, the packet analysis module may secure T1 to T3 time information in relation to the three packet transmission/reception points, and set the RTT value shifted from the arrival time in the server to a point in time earlier by a certain time to “T3-T1”. can be calculated using This may be referred to as network RTT.

Referring to FIG. 8 , the network RTT may be further subdivided, and RTT in the server and RTT in the client may be separately calculated. RTT (sRTT) at the server represents the delay time at the server for one packet, which can be calculated using “T2-T1”.

In addition, the RTT (cRTT) at the client can be calculated using “T3-T2” as the RTT at the client.

The packet analysis module according to an embodiment of the present invention calculates and stores the three RTTs, network RTT, server RTT, and/or client RTT for each transaction in real time. The client RTT is included in the transaction list as the tran_client_rtt index, and the server RTT is used to calculate statistical information in 10 second units for the server_rtt index.

9 is a conceptual diagram illustrating a delay index calculated by a packet analysis module according to an embodiment of the present invention.

Referring to FIG. 9 , the packet analysis module may calculate various delay indexes. As described above, it is assumed that the packet analysis module exists between the client and the server, the client transmits a plurality of request packets to the server, and the server transmits a plurality of response packets to the client in response to the plurality of requests. do.

The packet analysis module determines the T1 time when the first client request packet arrives, the T2 time when the last client request packet arrives, the T3 time when the first response packet arrives from the server, and the T4 time when the last response packet arrives from the server. can be obtained through the arrival time of the mirrored packet.

At this time, among the delay indicators, request transmission time (request time) information represents a time from when a plurality of requests from a client to a server start to be transmitted and a corresponding request reaches the server. In this regard, the packet analysis module may know the time at which the first request packet departs from the client based on the time point T1 through a value obtained by dividing the cRTT by half. In addition, the time when the last request packet arrived at the actual server can be known through the value obtained by dividing the sRTT by half. Through this arithmetic analysis, it can be calculated using "request time = cRTT/2 + (T2-T1) + sRTT/2", and since the sRTT value is generally a very small value, cRTT/2 + (T2- It is calculated as a value close to the value of T1). The request transmission time value is an index called tran_req_time, and is included as one piece of information in the transaction list, and the sum of request transmission times for 10 seconds is also included in the 10-second statistical information.

Next, the response latency (latency) represents the response delay time until the server receives the content or data associated with the request from the url associated with the client's request. That is, the server assumes that data is transmitted to the client as soon as it is received, and indicates the time until the server receives the first data related to the request from the url. This is eventually calculated by subtracting the sRTT value from (T2-T3). Here, since the sRTT value may be a negligibly small value, “T2-T3” may be the response waiting time. Response latency information is an index called tran_latency and is included as one piece of information in the transaction list, and the sum of response latency, minimum and maximum values may be included in 10-second statistical information.

Next, response data transmission time (response time) represents the time required for the server to transmit content related to the request to the client. This is calculated using the equation of "response time = sRTT/2 + (T4-T3) + cRTT/2". Considering that sRTT is a very small value, it is almost identical to the value of (T4-T3) + cRTT/2. The response data transmission time value is an indicator called tran_rsp_time, and is included as one piece of information in the transaction list, and the sum of response data transmission times for 10 seconds is included in the 10-second statistical information.

If the used time is calculated from the time the client sends the request to the time it receives the entire response data related to the request, it is the sum of the request transmission time, response waiting time, and response data transmission time. It is calculated using time = (T4-T1) + cRTT". The usage time can also function as candidate element information included in the transaction list.

Returning to FIG. 6 again, following client_ip, server_ip, client_port, server_port, receive_time, start_user, end_usec, fin_usec, tran_client_rtt, tran_req_time, tran_latency, and tran_rsp_time, the transaction list may include session_req_pkts information and session_rsp_pkts information. This indicates the number of data packets requesting a transaction and the number of response packets. Each of these may have a size of 4 bytes.

The session_req_pkts information represents the number of transaction request data packets, which is calculated based on the number of packets sent as request data by a specific client. It is in units of numbers.

The session_rsp_pkts information indicates the number of transaction response packets and is calculated based on the number of response data packets sent from a specific server to the client. number as a unit.

Additionally, session_pps information may be included in the transaction list. The session_pps information represents the real-time PPS of a session, and is calculated based on the PPS of a currently connected session. Unit is number. It is also desirable to have a size of 4 bytes.

In another example, as an index related to the pps speed of a session related to a transaction, sess_max_pps information may be considered as a candidate. The sess_max_pps information indicates the maximum PPS of a session, and is calculated based on the maximum PPS during a period in which the corresponding session is to be used. Unit is number.

Next, content_len information may be included in the transaction list. This, content_len, information indicates the content length of the response header, and indicates the length of content included in the response HTTP header sent by the server. For example, it may mean "a byte of /jsp/front/search/include/akc.jsp". The unit is a string, and the size is preferably 4 bytes.

Next, the transaction list may include state information and result information. Each of these may have a size of 1 Byte.

More specifically, state information represents a transaction state. This can be expressed as 7 numbers, as follows.

Transaction Status Code (Code)

1 - session_finish : initial state

2 - 3whs_syn_sent : Client sent syn during 3 handshake

3 - 3whs_syn_received : Client received syn/ack during 3 handshake

4 - 3whs_ack_received : Server received ack during 3 handshake

5 - session_connected : Session is connected

6 - session_request : A state in which the client has made a request

7 - session_response : Server has responded

Next, the transaction result is included in the list with the information name "result". This can be expressed as a number of 10, as follows.

transaction result code

1 - trans_finish : A transaction is finished

2 - client_finish : The session is terminated by the client (Finish-FIN is sent)

3 - server_finish : The session is terminated by the server (Finish-FIN is sent)

4 - client_reset : The session is terminated by the client (Reset-RST is sent)

5 - server_reset : The session is terminated by the server (Reset-RST is sent)

6 - client_timeout : The client terminated due to Timeout while sending a request.

7 - server_timeout : The server terminated due to timeout while sending a response

8 - session_error : HTTP session error

9 - req_parser_error : HTTP Request Header error

10 - rsp_parser_error : HTTP Response Header error

Next, method information may be included in the transaction list. This may have a size of 1 Byte. The method information is a type of request method (POST, GET, HEAD, PUT ...) and indicates the type of request method requested by the client. Unit is string.

Additionally, response_code_number information may be included in the transaction list. response_code_number information is a response result and is represented as an HTTP status code. For example, it can be expressed as one of "200, 304, 404, 500..." as the Response Status Code that the server responded. Unit is string. Also, it is good to have the size of 1 Byte.

Next, as additional information related to transaction requests and responses following session_req_pkts and session_rsp_pkts, session_req_bytes information and session_rsp_bytes information may be included in the transaction list. Here, the session_req_bytes information represents bytes of request data of a transaction, and is calculated based on the amount of bytes sent as request data by a specific client. Unit is byte. The session_rsp_bytes information represents bytes of transaction response data, and is calculated based on the amount of bytes sent as response data by a specific server. Unit is byte. These indicators may have a size of 8 bytes.

As session speed information related to a transaction, session_bps information following session_pps may be included in the transaction list. The session_bps information represents the real-time BPS of a session and is calculated based on the BPS (Bit Per Second) of the currently connected session. Unit is number. It may have a size of 8 bytes.

Finally, element information associated with the text list may be created at the end of the transaction list. This includes domain information, url information and mime information. It can be created as a hash value. These may have a size of 8 bytes.

Domain information represents information related to the domain among the urls requested by the client. It is based on strings. For example, information such as "www.lgmobile.co.kr" is indicated. Such text is recorded in text, and hash value of 8 bytes is displayed here.

The url information is the url requested by the client and indicates information such as "/jsp/front/search/include/akc.jsp".

The mime information represents a response header content type. For example, it may be one of text/html and the like. This is the content type information included in the response HTTP header sent by the server.

Looking at the transaction list as a whole, it includes: client_ip, server_ip, client_port, server_port, receive_time, start_user, end_usec, fin_usec, tran_client_rtt, tran_req_time, tran_latency, and tran_rsp_time, session_req_pkts, session_Rsp_pkts, session_pps, content_len, state, result, method, response_code_number, A total of 26 pieces of information such as session_req_bytes, session_rsp_bytes, session_bps, domain, url, and mime information can be included. That is, 26 pieces of information per one transaction are primarily generated by the transaction block generator as essential information for monitoring the transaction. And, it is appropriate that the size is 112 bytes. However, about 20 to 30 pieces of information may be used as a transaction list by adding or subtracting candidate element information through user settings.

Candidate element information that can be included in the future transaction list includes transaction_number information indicating the transaction number generated after the session is established, start_time, end_time, fin_time, used_time, and fin_used_time information indicating the usage time until the complete end of the transaction. can be included In addition, users information indicating the number of real-time users (based on client IP) of the url, max_users information indicating the maximum number of users of the url during the time the url is being used, sessions information indicating the number of real-time sessions of the url, and Candidate element information includes max_sessions information indicating the maximum number of sessions of the corresponding url during the time it is being used, wait information indicating the number of real-time waits of the corresponding url, and max_wait information indicating the maximum number of sessions waiting for response of the corresponding url during the time the url is being used. can be considered as Here, wait represents the number of sessions waiting for a response. This will be described in more detail with reference to FIG. 10 .

On the other hand, ups information indicating the real-time UPS (User Per Second) of the corresponding url, max_ups information indicating the Max UPS of the corresponding url, cps information indicating the real-time CPS (Connection Per Second) of the corresponding url, max_cps indicating the Max CPS of the corresponding url Information, tps information indicating real-time TPS (Transaction Per Second) of the corresponding url, max_tps information indicating Max TPS of the corresponding url, and idle information indicating idle of the corresponding url may also be considered as candidate element information. A method of calculating CPS, TPS, etc. related to network speed will be described in detail with reference to FIG. 11 below.

Also, as information related to the response header, referrers information, agent information indicating an agent included in the request HTTP header sent by the client, and cookie information indicating information related to the cookie included in the request HTTP header sent by the client are also considered candidate element information. It can be.

In addition, as information related to the network service of a specific server, server_countrys indicates the number of real-time countries of the server, server_max_countrys indicates the number of Max Countries of the server, and server_error indicates the number of real-time errors (400 and 500 response codes) of the server. , server_user indicating the number of real-time users of the server (based on Client IP), server_max_user indicating the maximum number of users on the server, server_sessions indicating the number of real-time sessions on the server, server_max_sessions indicating the maximum number of sessions on the server, and As indicators related to speeds, server_bps, server_max_bps, server_pps, server_max_pps, server_rtt, server_max_rtt, server_ups, server_max_ups, server_cps, server_max_cps, server_tps, server_max_tps, server_hps, server_max_hps, server_wait, server_max_wait, and server_idle information are considered as element information to be included in the transaction list. It can be. However, since a lot of information related to the server side is included in the 10-second statistical information, it is not necessary to display it redundantly in the transaction list.

server_error information indicates the number of real-time errors (400, 500 response codes) of the corresponding server. For example, 203.247.157.199 may indicate the number of user errors and/or server errors from 400 to 599 among Response Status Codes responded by the server.

server_sessions Indicates the number of real-time sessions on the server. server_max_sessions information indicates the maximum number of sessions for the server. The server_bps information represents the real-time BPS of the corresponding server. The server_max_bps information indicates the Max BPS of the server. The server_pps information indicates the real-time PPS of the corresponding server. The server_max_pps information indicates the Max PPS of the server.

server_rtt information indicates the real-time RTT of the corresponding server. The server_max_rtt information represents the Max RTT of the corresponding server, and for example, this may be resolved as “maximum average RTT of the 203.247.157.199 server”. The unit of server_rtt information and server_max_rtt information is micro sec. In particular, server_rtt can be used to calculate 10-second statistical information.

server_ups information indicates the real-time UPS of the corresponding server. This can represent "real-time UPS of server 203.247.157.199", which means that about 1 user is connecting to server 203.247.157.199 per second.

The server_max_ups information indicates the Max UPS of the server.

The server_cps information indicates a real-time CPS of a corresponding server, and may indicate, for example, “real-time CPS of a server 203.247.157.199”. This means that about 15 sessions per second are connected to the 203.247.157.199 server.

The server_max_cps information indicates the Max CPS of the server.

The server_tps information indicates the real-time TPS of the corresponding server, and may indicate, for example, “real-time TPS of the 203.247.157.199 server”. This indicates that about 79 transactions per second are occurring in the 203.247.157.199 server.

The server_max_tps information indicates the Max TPS of the server.

The server_hps information indicates the real-time HPS (Hit Per Second: the number of urls requested per second) of the server. For example, it may indicate “real-time HPS of server 203.247.157.199”. This means that about 79 urls are being requested per second to the 203.247.157.199 server.

The server_max_hps information indicates the Max HPS of the server.

server_wait information indicates the number of waits of the corresponding server. For example, "the number of real-time waits of the 203.247.157.199 server" may be indicated. This can indicate that 46 sessions among 206 sessions are currently waiting for a response in the 203.247.157.199 server.

server_max_wait information indicates the number of Max Waits for the server.

server_idle information indicates the idle time of the corresponding server. For example, it may indicate "the time when there was no request to the 203.247.157.199 server". If the server has many visitors, Idle becomes short, and if there are few visitors, Idle becomes long. The unit is micro sec.

Additionally, as information related to the network service of a specific client, client_country_code indicating the country code (KR ..) of the client, client_error indicating the number of real-time errors of the client, client_servers indicating the number of real-time server connections of the client, maximum number of simultaneous servers of the client client_max_servers indicating the number, client_sessions indicating the number of real-time sessions of a client, and client_max_sessions indicating the maximum number of sessions of a client may be considered as element information candidates to be included in the transaction list. In addition, client_bps, client_max_bps, client_pps, client_max_pps, client_max_rtt, client_sps, client_max_sps, client_cps, client_max_cps, client_tps, client_max_tps, client_hps, client_max_hps, client_wait, client_max_wait, and client_idle information may be additionally considered as client-side speed-related information.

Finally, candidate element information that can be considered to be included in the transaction list includes org, city_id, isp_id, os_id, browser_id, mobile_id, and telcom_id information. Here, the org information represents the organization of IP-based clients. For example, "organization of 222.103.141.187 Client" may represent Korea Telecom. city_id information may represent the city code of an IP-based client. For example, "222.103.141.187 Client's City" may represent Seoul. isp_id information represents the ISP Code of an IP-based client. For example, "222.103.141.187 Client's ISP" may represent Korea Telecom. os_id information indicates the client's OS Code of the client. Through this, it is possible to check information on whether the corresponding client uses Win XP, iOS, or Android as the OS. browser_id represents the browser code of the client. Through this, information on whether the corresponding client uses explorer, chrome, or MSIE9 as a web browser can be checked. mobile_id information indicates the mobile code of the client. This is the device identification information of the client, and indicates whether it is a Samsung, Pantech, or Apple device. The telcom_id information indicates the TelCom Code of the client. This indicates information about whether the client's carrier is SKT, KT, or LGT.

10 is a conceptual diagram illustrating an indicator of the number of sessions waiting for a server response calculated by a packet analysis module according to an embodiment of the present invention.

Referring to FIG. 10 , since a server processes at least one request from a plurality of clients, one server also processes a plurality of sessions in relation to the requests. At this time, if the processing time in the server becomes longer, the waiting time in the client becomes longer, which requires patience from the user of the client device. Therefore, information on the number of sessions waiting for a response in the server has a very important meaning.

The number of sessions waiting for response is calculated as the number of sessions remaining after subtracting the session in which actual response data is transmitted to the client through processing in the server among a plurality of sessions associated with the request. For example, when only one session is answered for three sessions, the number of waiting sessions, wait = 3-1 = 2, is calculated. That is, since the packet analysis module exists between the client and the server and can secure all packets transmitted and received between the two, the number of waiting sessions currently being processed in the server can be clearly identified.

Whether or not processing of a specific request is completed in the server can be confirmed based on whether a response packet to a request for a specific url is transmitted to the client based on the source IP and the destination IP. In the case of a response packet, it can be identified by checking whether or not a destination ip and a source ip are included in the request packet, while being associated with the specific url shown in the request packet.

11 is a conceptual diagram illustrating CPS/TPS (Connection Per Second/Transaction Per Second) indicators calculated by a packet analysis module according to an embodiment of the present invention.

Referring to FIG. 11, one transaction includes at least one request between a client and a server and at least one response data packet according to the at least one request. In the embodiment of FIG. 11, three response data packets form one transaction for one GET request, which does not necessarily have a 1:3 relationship, and the number of request packets is greater, and the response data packet corresponds to the corresponding request packet. It is okay for data packets to have fewer relationships.

These transactions also have important implications in relation to the speed and delay of network services. Accordingly, the packet mirroring device calculates the number of newly attempted transactions per second. This is called TPS. In addition, the number of connections between a specific client and a specific server, which can be called a connection, calculates the number of newly attempted connections per second. This is called CPS.

In addition, UPS (User Per Second) information indicating the number of users connected per second and BPS information indicating the amount of data transmitted/received per second through a specific client, specific server, or specific session are also calculated periodically. PPS information indicating the number of packets transmitted and received per second, HPS information indicating the number of urls requested per second, and SPS (Server Per Second) information indicating the number of servers connected per second are also periodically calculated.

FIG. 12 is a table showing the configuration of a text list in the transaction block of FIG. 5 in detail.

Referring to FIG. 12 , the text list may include text information corresponding to domain information, url information, and mime information. A hash function is applied to one text to generate an index value of a specific value. The generated index value may be created by connecting the H-1 hash value and the H-2 hash value to prevent collision. That is, the first text may be generated by connecting the H- _{1_TEXT1} hash value and the H- _{2_TEXT1} hash value. It is associated with specific information in the transaction list. For example, the first text may be associated with domain information, the second text with url information, and the third text with mime information.

At this time, the 8-byte value generated as domain information in the transaction list is also displayed as a hash value indicating the same index. However, in order to prevent collision with information entered later, the values of the two lists are matched by using the H-1 hash value and the H-2 hash value as a linked list to prevent collision between them.

FIG. 13 is a table specifically showing the configuration of statistical information in the transaction block of FIG. 5 .

Referring to FIG. 13 , a transaction block includes statistical information indicating a statistical value of packet analysis for a certain period of time (eg, 10 seconds). Statistical information may include about 30 statistical information. Some use detailed information about transactions in the transaction list as statistical information, and from transaction detailed information, the average value (mean), maximum value (max), minimum value (min), median value (median), and total value (sum) Some use the same calculation. Alternatively, although not included in the transaction list, candidate element information or a value calculated from candidate element information may be included.

Looking at the calculated value included in the statistical information in more detail, the statistical information may include server IP information (server_ip) of 4 bytes, statistics completion time information (stats_time) of 4 bytes, and domain information (domain) of 8 bytes. there is.

The server_ip information includes the IP information of the server related to the transaction for 10 seconds. The stats_time information includes information about the completion time of the corresponding statistics. This can be expressed as a whole 9-digit integer excluding the 0 at the end of mmddhhmms0. For example, statistics from 19:38:0 to 9 seconds on May 21 are stored as 052119381. If the last digit is 0, it indicates accumulated statistics for 1 minute, 10 minutes, etc., not 10 second statistics. The domain information includes domain information related to 10 transactions.

Next, the 10-second statistical information may include the following information representing the transaction state of the server related to the corresponding transaction. This includes server_user information, server_sessions information, server_session_c information, server_session_error information, and server_transactions information, and the above information is displayed as a sum of the index values of transactions for 10 seconds. Preferably, each of the pieces of information has a size of 8 bytes.

More specifically, the server_user information represents the sum of the number of real-time users (based on Client IP) of at least one server related to transactions for 10 seconds. The server_sessions information represents the sum of real-time sessions of at least one server related to transactions for 10 seconds. The server_session_c information indicates the cumulative value of server sessions related to transactions for 10 seconds. This has a value that is reset at a certain point in time. As the server_session described above is the number of sessions for 10 seconds, it cannot be disconnected every 10 seconds. Therefore, since the actual number of sessions of the server cannot be determined by the cumulative value of server_session, it is desirable to maintain the value of server_session_c in a certain unit of time.

Next, server_session_error information represents the sum of the number of real-time errors (response codes of 400 and 500) of at least one server related to transactions for 10 seconds. And, server_transactions information represents the sum of the number of transactions of at least one server related to transactions for 10 seconds. Multiple transactions can be gathered to form one session.

Next, the 10-second statistical information may include statistical information related to the transmission speed of packets used for transactions of servers related to the transaction. This includes server_bps information, server_req_bps information, server_rsp_bps information, server_pps information, server_ups information, server_cps information, server_tps information, server_hps information, server_rtt information, server_wait information, and server_syn_wait information, which are the above indicators of transactions for 10 seconds. It is expressed as the sum of the values (sum), the minimum value (min) and the maximum value (max). Preferably, each of the pieces of information has a size of 24 bytes. That is, the sum value, the minimum value, and the maximum value may each have a size of 8 bytes.

More specifically, the server_bps information represents the sum, minimum and maximum values of real-time bps of at least one server associated with transactions for 10 seconds. The server_req_bps information indicates a sum of bps values, a minimum value, and a maximum value of packets associated with a request of at least one server associated with transactions for 10 seconds. That is, through this, the speed of the client side can be inferred.

The server_rsp_bps information indicates a sum of bps values, a minimum value, and a maximum value of packets associated with a response to a request of at least one server associated with transactions for 10 seconds. Through this, the speed of the server side can be inferred. The server_pps information represents the sum, minimum, and maximum values of real-time pps of at least one server associated with transactions for 10 seconds. The server_ups information indicates a sum of real-time ups, a minimum value, and a maximum value of at least one server associated with transactions for 10 seconds. The server_cps information represents the sum, minimum and maximum values of real-time cps of a corresponding server of at least one server related to transactions for 10 seconds. The server_tps information represents the sum, minimum and maximum values of real-time tps of at least one server associated with transactions for 10 seconds. The server_hps information represents the sum, minimum, and maximum values of real-time hps of at least one server associated with transactions for 10 seconds. The server_rtt information represents the sum of real-time RTT values of at least one server related to transactions for 10 seconds, minimum value, and maximum value. Next, the server_wait information indicates the sum of the wait numbers of at least one server associated with transactions for 10 seconds, a minimum value, and a maximum value. It is calculated as the number of sessions for which a response has not been completed after a request.

And, the server_syn_wait information represents the sum, minimum and maximum values of wait numbers of sync packets (syn) delivered to or from at least one server related to transactions for 10 seconds. Depending on the session, a state in which synchronization (syn) or fin is not completed may occur at the time of writing the 10-second statistics, so this field is created to compensate for this.

Next, the 10-second statistical information includes information related to the idle time of the server related to the transaction. This is expressed as a server_idle index, and is calculated as a sum of server_idle indexes. It is desirable to have a size of 8 bytes. More specifically, it indicates the idle time of at least one server related to transactions for 10 seconds. That is, it indicates the time when there is no request to the corresponding server(s), and the sum of these times is displayed in the statistical value. The unit is preferably micro sec.

Next, the 10-second statistical information may include information about HTTP response codes appearing in corresponding transactions. This represents an error response code. This includes rsp_400 information, rsp_500 information, rsp_300 information, and rsp_200 information, and the above information is displayed as a sum of the number of specific errors in transactions for 10 seconds. Preferably, each of the pieces of information has a size of 8 bytes.

More specifically, the rsp_400 information represents the sum of the number of occurrences of 400 errors in transactions for 10 seconds. That is, it represents the sum of the number of bad requests. The rsp_500 information represents the sum of the number of occurrences of 500 errors in transactions for 10 seconds. That is, it represents the sum of the number of internal server errors indicating that the web server was unable to fulfill the request. The rsp_300 information represents the sum of the number of occurrences of 300 errors (Multiple Choices) requesting recently moved data in transactions for 10 seconds. The rsp_200 information represents the sum of the number of occurrences of 200 responses transmitted successfully without errors in transactions for 10 seconds.

Next, in the 10-second statistical information, it is about the response waiting time in the url related to the transaction, and indicates the total value, minimum value, and maximum value of real-time response waiting time in a specific web page. It is desirable to have a size of 24 bytes.

Finally, the 10-second statistical information includes request transmission time (tran_req_time), response data transmission time (tran_rsp_time) related to the transaction, req_byte indicating the amount of request data, and rsp_byte value indicating the amount of response data. . It is preferable to express this as a sum value, and each may have a size of 8 Bytes.

More specifically, the request transmission time (tran_req_time) information is calculated from a request transmission time of request data (eg, requests from a client to a server) related to a transaction for 10 seconds to a time value at which the request reaches the server. This may be calculated as the sum of request transmission time values of at least one request.

Response data transmission time (tran_rsp_time) information is the transmission time of response data related to a transaction for 10 seconds, indicating the time required for the server to transmit contents related to the request to the client. This may be calculated as the sum of transmission times of at least one response. A more specific calculation method will be described with reference to FIG. 9 . The req_byte information represents the amount of data sent as a request in transactions for 10 seconds in bytes, and can be calculated as the sum of the amount of request packets. In addition, rsp_byte information represents data sent as a response in transactions for 10 seconds in bytes, and can be calculated as the sum of the amounts of response packets.

Additionally, in addition to the 10-second statistics, maximum and average values (max, avg) for 1 minute, 10 minutes, 1 hour, and 1 day states may also be included in the transaction block of the corresponding time and provided to the analysis information collection device.

14 is a detailed block diagram for specifically explaining the configuration of an analysis information collection device that collects analysis information from a packet analysis module. As shown in FIG. 14, the analysis information collection apparatus according to an embodiment of the present invention includes a receiver, a local file system (local F/S), a storage unit, a repository, an indexing module, a browsing module, It may include an alert module and user interface.

Referring to FIG. 14 , the collection module may include a receiver, a local file system, and a storage unit. And, it can be linked with the repository.

First, a receiver of a collection module may receive transaction blocks and other information from a plurality of packet analysis modules using an HTTP protocol (in particular, HTTP3). Here, other information includes actual packets. The receiver sets the file name as the reception time of the transaction block or the reception time of the packet related to the transaction block based on the received transaction block information and stores it as a temporary file in the local file system. The storage unit sorts the 10-second transaction blocks of the same time zone, which are stored as temporary files through the receiver, by the reception time, creates a directory by 1 minute unit, and stores them in the repository. A 10 second delay can be stored for alignment. At this time, each directory is stored with an 8-digit year, month, and day index (yyyymmdd) and a 4-digit index of the received hour and minute (hhmm). The collection module calculates statistics by 1 minute and 10 minutes and stores them together. That is, 10-second statistics (which can be obtained from a transaction block), 1-minute statistics, 10-minute statistics, etc. are analyzed, and the analyzed statistical results are stored in each directory. In other words, each directory stores 60 10-second stats, 10 1-minute stats, and 1 10-minute stat. The indexing module individually attaches an index for search to such statistical information. At this time, statistics for 1 hour may be stored in the 00 minute directory, and similarly, 1 day repository analysis results may be stored together with 0000 minutes. The 1-minute statistics, 10-minute statistics, 1-hour statistics, and 1-day statistics may store statistical values of the same or similar information as the statistical information of the transaction block. That is, at least one of an average value, a summed value, a minimum value, a maximum value, and a median value of a specific performance index may be calculated and stored.

The indexing module includes a Time Index, an IP or MAC address index (sIP(mac) Index), a Text Index, a State Index, and a Result Index. ) and response code index (Rsp. Code Index) can be attached to each transaction in the 1-minute directory.

Through this, it is possible to perform an efficient search according to user input in the browsing module. That is, the basic search is to be searched by indexing field. The indexing field includes at least one of a time index and an IP/MAC index among the indexes described above.

Then, additional searches are made through the filtering fields. Filtering fields include response code index, status index and result index. Secondary filtering may be performed through response latency, additional conditions other than that, and/or search terms for clear specific log searches.

Meanwhile, the analysis information collection device and the packet analysis module perform monitoring by exchanging information with each other as one monitoring system. At this time, information related to the operation of the transaction list and statistical information may be exchanged. For example, a first method including 26 element information, a second method including 20 element information, and a third method including 30 or more element information are set in the transaction list, and the information included therein After sharing the list of , it can operate in the form of sharing the currently used method. At this time, the analysis information collection device may determine which method to use according to the number of currently monitored servers (or instances) and guide the packet analysis module. The packet analysis module generates a transaction block according to the decision of the analysis information collection device in a suitable manner. Moreover, statistical information can be operated as well. In the basic method, the transaction block generated by the packet analysis module generates statistics in units of 10 seconds, and the analysis information collection device generates statistics in units of 1 minute, 10 minutes, 1 hour, and furthermore, 1 day. However, the analysis information collection device may determine and command to perform the distribution in a different way. For example, the packet analysis module may calculate statistics by 10 seconds and units of 1 minute, and the analysis information collection device may calculate only statistics by units of 10 minutes, 1 hour, and 1 day. Alternatively, the packet analysis module may calculate statistics by 10 seconds, 1 minute, and 10 minutes, and the analysis information collecting device may calculate only statistics by 1 hour and 1 day.

The system or apparatus described above may be implemented as hardware components, software components, and/or a combination of hardware components and software components. For example, systems, devices and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable array (FPA) ), programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions. A processing device may run an operating system (OS) and one or more software applications running on the operating system. A processing device may also access, store, manipulate, process, and generate data in response to execution of software. For convenience of understanding, there are cases in which one processing device is used, but those skilled in the art will understand that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it can include. For example, a processing device may include a plurality of processors or a processor and a controller. Other processing configurations are also possible, such as parallel processors.

Software may include a computer program, code, instructions, or a combination of one or more of the foregoing, which configures a processing device to operate as desired or processes independently or collectively. The device can be commanded. Software and/or data may be any tangible machine, component, physical device, virtual equipment, computer storage medium or device, intended to be interpreted by or provide instructions or data to a processing device. , or may be permanently or temporarily embodied in a transmitted signal wave. Software may be distributed on networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer readable media.

The method according to the embodiments may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. Program commands recorded on the medium may be specially designed and configured for the embodiment or may be known and usable to those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. - includes hardware devices specially configured to store and execute program instructions, such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter, as well as machine language codes such as those produced by a compiler. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described with limited examples and drawings, those skilled in the art can make various modifications and variations from the above description. For example, the described techniques may be performed in an order different from the method described, and/or components of the described system, structure, device, circuit, etc. may be combined or combined in a different form than the method described, or other components may be used. Or even if it is replaced or substituted by equivalents, appropriate results can be achieved.

Therefore, other implementations, other embodiments, and equivalents of the claims are within the scope of the following claims.

Claims (21)

In the real-time packet analysis method for monitoring a large-capacity network in a packet analysis module,
Collecting a plurality of packets to be analyzed, the plurality of packets including packets transmitted and received between a first entity and a second entity, wherein at least one of the first entity and the second entity is a computing device or an application instance running on the computing device;
Analyzing the collected plurality of packets in transaction units to generate a TRansaction Block (TR Block) in units of a predetermined time, wherein the transaction block is a network information for at least one transaction processed for the predetermined period of time. It is a data block in which performance information is generated in units of transactions; and
Transmitting the generated transaction block to an analysis information collection device in real time,
The large-capacity network includes a cloud network,
The first entity and the third entity, which individually include the packet analysis module, are application instance-based entities included in a server end of the cloud network,
The second entity is an entity not included in the server side of the cloud network,
The first entity is synchronized with a third entity constituting the server side of the cloud network to provide a transaction block to the analysis information collection device at the predetermined time interval,
The transaction block includes (i) transaction list (TR List) information including one set of element information of each transaction included in the at least one transaction, and (ii) a list of texts associated with the transaction list information. Includes text list information and (iii) statistical information of network performance indicators for the predetermined time period;
The set of element information is composed of essential element information of a plurality of categories related to a transaction and includes at least one element information of an individual category,
Element information of the plurality of classifications,
(i) IP address and port information of the first entity and the second entity;
(ii) time information related to the transaction;
(iii) information related to session request and response packets related to the transaction;
(iv) real-time data transfer rate information of the session associated with the transaction; and
(v) contain transaction status and result information;
The transaction block is generated in a size of less than 2.2 MB as a whole, a real-time packet analysis method for monitoring a large-capacity network. delete delete According to claim 1,
The time information related to the transaction includes transaction start and end time information, transaction RTT (Round Trip Time) information, request transmission time (request time) information, response latency information, and response data transmission time (response time) information. Including, real-time packet analysis method for monitoring large-capacity network. According to claim 1,
The set of element information further includes a uniform resource locator (url) requested by the first entity or the second entity, domain information (domain), and response header content type information (MIME) among the urls,
The url information, the domain information, and the response header content type information are expressed as a hash value, a real-time packet analysis method for monitoring a large-capacity network. According to claim 5,
The hash value matches one of a plurality of texts included in the text list,
The hash value is composed of a plurality of pieces to prevent collisions with each other, a real-time packet analysis method for monitoring a large-capacity network. According to claim 1,
When element information currently included in the transaction list is replaced with candidate element information, it is replaced with candidate element information within the same classification. According to claim 1,
The predetermined time is 8 seconds to 12 seconds,
The statistical information includes a statistical value of a server-side data transfer rate, a statistical value of a response waiting time, and a statistical value of time and data amount for transaction request and response in at least one transaction during the predetermined time period. A real-time packet analysis method for monitoring high-capacity networks. According to claim 8,
The statistical information further includes information on the total value of HTTP errors generated in at least one transaction for the predetermined time period, real-time packet analysis method for monitoring a large-capacity network. According to claim 1,
One set of element information for each transaction has a size of 100 to 120 bytes,
The transaction list includes information about 10000 or less transactions,
The transaction list is generated in a size of 0.8 to 1.2 MiB, a real-time packet analysis method for monitoring a large-capacity network. According to claim 10,
The text list includes hash values,
A real-time packet analysis method for monitoring large-capacity networks generated by compression to a size of less than 1 MiB. According to claim 1,
The statistical information is generated in a size of less than 500 bytes, a real-time packet analysis method for monitoring a large-capacity network. delete According to claim 1,
The packet analysis module is embedded in the application instance in the form of an agent, a real-time packet analysis method for monitoring a large-capacity network. According to claim 1,
The real-time packet analysis method for monitoring a large-capacity network, wherein the transaction block is generated in units of the predetermined time and provided to the analysis information collection device in real time using HTTP (Hypertext Transfer Protocol). The method of claim 1, wherein the packet analysis module,
One of the first mode, which is a unified analysis mode in which the entire packet analysis is performed by the packet analysis module alone, and the second mode, which is a dualized analysis mode in which some of the overall packet analysis is performed in a distributed manner with the analysis information collection device. select and analyze the packet,
The real-time packet analysis method for monitoring a large-capacity network, wherein the analysis result of the first mode has a larger amount than the analysis result of the second mode. 17. The method of claim 16,
The real-time packet analysis method for monitoring a large-capacity network, wherein selection of one of the first mode and the second mode is determined by the number of monitoring target servers. A packet analysis apparatus for performing real-time packet analysis for monitoring of a large-capacity network,
A packet collecting unit that collects a plurality of packets to be analyzed, the plurality of packets including packets transmitted and received between a first entity and a second entity, at least one of the first entity and the second entity Comprising a computing device or an application instance running on the computing device;
A transaction block generation unit that analyzes the collected packets in units of transactions and generates a TRansaction Block (TR Block) in units of a predetermined time, wherein the transaction block includes at least one transaction processed for the predetermined period of time. It is a data block that generates information on network performance for , in units of transactions; and
Including an analysis information providing unit for transmitting the generated transaction block to an analysis information collection device in real time,
The large-capacity network includes a cloud network,
The first entity and the third entity are application instance-based entities included in the server side of the cloud network,
The packet analysis device is individually included in each of the first entity and the third entity,
The second entity is an entity not included in the server side of the cloud network,
The first entity is synchronized with a third entity constituting the server side of the cloud network to provide a transaction block to the analysis information collection device at the predetermined time interval,
The transaction block includes (i) transaction list (TR List) information including one set of element information of each transaction included in the at least one transaction, and (ii) a list of texts associated with the transaction list information. Includes text list information and (iii) statistical information of network performance indicators for the predetermined time period;
The set of element information is composed of essential element information of a plurality of categories related to a transaction and includes at least one element information of an individual category,
Element information of the plurality of classifications,
(i) IP address and port information of the first entity and the second entity;
(ii) time information related to the transaction;
(iii) information related to session request and response packets related to the transaction;
(iv) real-time data transfer rate information of the session associated with the transaction; and
(v) contain transaction status and result information;
The packet analysis apparatus for performing real-time packet analysis for monitoring a large-capacity network, wherein the transaction block is generated in a size of less than 2.2 MB as a whole. In a packet analysis system for performing real-time packet analysis for monitoring of a large-capacity network,
A plurality of packets to be analyzed - the plurality of packets are a first entity and a second entity - at least one of the first entity and the second entity is a computing device or an application instance ( application instance) - including packets transmitted and received between them - is collected, analyzed in units of transactions, and a transaction block (TR Block: TRansaction Block) in units of a first time unit - the transaction block is processed during the first time a packet analyzer for generating information about network performance of at least one transaction, which is a data block generated in transaction units, and transmitting the generated transaction block to an analysis information collection device in real time; and
Including an analysis information collection device for receiving the transaction block, performing additional performance analysis, and storing it in a repository,
The large-capacity network includes a cloud network,
The first entity and the third entity are application instance-based entities included in the server side of the cloud network,
The packet analysis device is individually included in each of the first entity and the third entity,
The second entity is an entity not included in the server side of the cloud network,
The first entity is synchronized with a third entity constituting the server side of the cloud network and provides a transaction block to the analysis information collection device at regular time intervals,
The transaction block includes (i) transaction list (TR List) information including one set of element information of each transaction included in the at least one transaction, and (ii) a list of texts associated with the transaction list information. Includes text list information and (iii) statistical information of network performance indicators for the predetermined time period;
The set of element information is composed of essential element information of a plurality of categories related to a transaction and includes at least one element information of an individual category,
Element information of the plurality of classifications,
(i) IP address and port information of the first entity and the second entity;
(ii) time information related to the transaction;
(iii) information related to session request and response packets related to the transaction;
(iv) real-time data transfer rate information of the session associated with the transaction; and
(v) contain transaction status and result information;
The packet analysis system for performing real-time packet analysis for large-capacity network monitoring, wherein the transaction block is generated in a size of less than 2.2 MB as a whole. According to claim 19,
The additional performance analysis includes calculating a network performance indicator of a second time unit,
The second time is a time longer than the first time, a packet analysis system for performing real-time packet analysis for monitoring a large-capacity network. According to claim 19,
The analysis information collection device specifies the first time, which is a time unit to be processed in the statistical information included in the transaction block, and element information included in the transaction list included in the transaction block, and notifies the packet analysis device. A packet analysis system that performs real-time packet analysis for high volume network monitoring.

Images