JP3602711B2 - Traffic monitoring device - Google Patents

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a traffic monitoring device useful for performance analysis between networks such as the Internet.
[0002]
[Prior art]
With the spread of the Internet, performance analysis of the Internet has become an important issue, such as the temporal change of traffic flowing through a specific line.
[0003]
In order to perform such a performance analysis, it is necessary to monitor traffic flowing through a line for a long time and generate various types of statistical information based on the monitoring.
[0004]
On the other hand, with an increase in traffic, the backbone line of the Internet has been sped up by using an ATM (Asynchronous Transfer Mode) line or the like.
[0005]
However, if a packet flowing on the line is used without processing, the data amount increases in proportion to time. Therefore, when monitoring traffic on a high-speed network such as an ATM line for a long time, the amount of traffic data becomes extremely large. Therefore, a large-capacity storage device and a high-speed processing device are required.
[0006]
[Problems to be solved by the invention]
Therefore, an object of the present invention is to provide a traffic monitoring device which compresses and accumulates traffic data in a form as close as possible to a packet flowing on a line.
[0007]
[Means for Solving the Problems]
The invention according to claim 1, which solves the above-mentioned problem, comprises: a packet acquisition unit that extracts a packet from an inter-network line and extracts a header portion including at least an IP header of the extracted packet; A combination of the packet ID on the packet originating side and the network ID on the destination side of the packet extracted by the packet acquisition means from the contents (hereinafter referred to as the originating and terminating NID) is checked, and data on the traffic on the line (hereinafter, referred to as the terminating and terminating NID) for each originating and terminating NID. Traffic data) is recorded in a preset format, and the traffic data having the same type of outgoing and incoming NIDs is collectively stored at regular time intervals .
As the traffic data, information related to an IP protocol (hereinafter, referred to as IP information), information related to a TCP protocol (hereinafter, referred to as TCP information), information related to a UDP protocol (hereinafter, referred to as UDP information), and information related to an application protocol (hereinafter, referred to) , And application protocol information).
When the TCP information is used as the traffic data, the TCP information is divided into TCP information that is not related to a connection and TCP information that is related to a connection,
TCP information concerning the connection, using the connection management table for managing the TCP connection, a traffic monitoring device status information in consideration of the TCP communication procedure wherein the Rukoto identified.
[0013]
The invention according to claim 2 is the traffic monitoring device, wherein the IP information includes at least the total number of IP packets and the total number of bytes of IP packets.
[0015]
The invention according to claim 3 is the traffic monitoring device, wherein the TCP information not related to the connection includes at least a total number of TCP segments and a total number of bytes of TCP segments.
[0016]
The invention according to claim 4 and 5, viewed contains information about at least the number of connections as the TCP information on the connection, also, TCP connection establishment success number, TCP connection establishment failure number, TCP connection establishment mean time, TCP connection duration Mean Time a traffic monitoring device according to claim including Mukoto at least one of the average data transfer amount for each TCP connection bidirectional.
[0018]
The invention according to claim 6 is the traffic monitoring device, wherein the application protocol information includes at least one of information on an HTTP protocol, information on an FTP protocol, and information on an SMTP protocol.
[0019]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described.
[0020]
(Design policy for truck monitoring equipment)
In designing the truck monitoring device according to the embodiment of the present invention, the following policy was established.
(1) Every fixed time (for example, every 10 minutes). The statistical information of each protocol such as IP, TCP, HTTP, FTP, and SMTP (Simple Mail Transfer Protocol) is generated, and its temporal change can be analyzed. These pieces of information are generated for each destination network ID and each application. TCP also targets information that takes communication procedures into account, such as the connection establishment time and the number of retransmissions.
(2) An IP packet flowing on an ATM line of the Internet is acquired, and a traffic amount for a certain period of time is accumulated as traffic data. Statistical information is generated based on this data.
(3) Assuming that traffic data for several months is accumulated, a data structure that can compress past data is adopted.
[0021]
(function)
In particular, the traffic monitoring device has a function of generating the following statistical information.
[0022]
For IP information,
(1) The total number of packets and the total number of bytes flowing through the ATM line (2) The number of packets and the number of bytes for each originating / departing network ID (3) The number of packets and the number of bytes for each type of higher-level protocol
[0023]
For TCP information,
(1) Number of established connections (2) Average connection time of connection (3) Average number of retransmitted packets per connection (4) Average number of retransmitted bytes per connection
[0024]
The HTTP information is a frequently accessed site name or the like.
[0025]
(Device configuration)
This traffic monitoring device was mainly configured by a computer using a CPU and software as shown in FIG. However, one computer or two or more computers are used according to their capabilities. .
[0026]
The traffic monitoring device 1 shown in FIG. 1 is connected to a 155 Mbps first ATM line 11 and a second ATM line 12, and is configured to acquire a bidirectional packet flowing thereover.
[0027]
As shown in FIG. 1, the traffic monitoring device 1 includes a packet acquisition module (packet acquisition means) 2 implemented in a UNIX kernel by software, and a traffic data accumulation module (traffic data accumulation means) executed as a user program. 3) In addition to the above, the statistical information processing module 4 which performs data aggregation and screen display is configured.
[0028]
Further, the traffic monitoring device 1 includes an ATM board 5 for connecting to a first ATM line 11 and an ATM board 6 for connecting to a second ATM line 12. In FIG. 1, reference numerals 13 and 14 denote ATM routers or ATM switches of each network connected to the ATM line.
[0029]
(For each module)
The packet acquisition module 2 captures an IP packet, extracts a header part such as IP, TCP, and HTTP, and notifies the traffic data storage module 3 of the header.
[0030]
The traffic data storage module 3 creates traffic data at regular intervals based on the notified packet information, compresses the data, and stores it.
[0031]
FIG. 4 shows a format example of the traffic data. For example, in the traffic data, the outgoing / incoming network ID (outgoing / incoming NID: outgoing NID and incoming NID) and the outgoing / incoming port (well-known port: outgoing port number and incoming port number) captured within a fixed time are the same. It is created for a certain IP packet and holds information for creating the aforementioned statistical information.
[0032]
As described above, by compressing and storing information corresponding to a plurality of IP packets transferred within a fixed time, the amount of data to be stored can be reduced as compared with a case where header portions are individually identified. At the same time, for past records, data can be compressed by increasing the time interval of generation of statistical information.
[0033]
The statistical information processing module 4 performs totalization of accumulated traffic data and screen display. As a result, detailed statistical information such as the total number of bytes of data received by FTP for a certain network ID in the past month and the distribution of the number of times a certain FTP server failed to establish a TCP connection for one week is generated. can do.
[0034]
By compressing, processing, and accumulating the packet information, the traffic monitoring device 1 can be operated for a long time corresponding to the high-speed Internet.
[0035]
(Example of traffic monitoring device 1)
Hereinafter, a specific embodiment of the traffic monitoring device 1 will be described with reference to FIGS.
[0036]
(Details of packet acquisition module 2)
First, referring to FIG. 2, a detailed packet acquisition processing procedure of the packet acquisition module 2 will be described below.
[0037]
The packet acquisition module 2 monitors the ATM lines 11 and 12 through the ATM boards 5 and 6, and extracts packets flowing therefrom from the ATM lines 11 and 12 (see step S1 in FIG. 2).
[0038]
Next, the packet acquisition module 2 extracts only the header portion from the acquired packet (see step S2). Specifically, a higher-level protocol of IP (Internet Protocol) is checked from the header part of the packet. If the upper layer protocol is other than TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), only the IP header is extracted. If the upper layer protocol is TCP or UDP, the upper layer application protocol is checked from the TCP or UDP port number, the format is analyzed for each application protocol, and the application protocol header is extracted.
[0039]
The packet acquisition module 2 passes the IP header and the application protocol header portion extracted as described above to the traffic data storage module 3 (see step S3).
[0040]
(Details of the traffic data storage module 3)
Next, referring to FIG. 3, a detailed traffic data storage procedure of the traffic data storage module 3 will be described below.
[0041]
The traffic data storage module 3 constantly monitors whether or not a predetermined time for compressing data has elapsed (see step S4 in FIG. 3).
[0042]
If the fixed time has not elapsed, it is checked whether there is data (IP header or application protocol header) passed from the packet acquisition module 2 during that time (see step S5).
[0043]
If data has been passed from the packet acquisition module 2, it is checked whether or not traffic data corresponding to the data already exists, and the ID of the traffic data is acquired (see step S6). More specifically, the corresponding traffic data is detected by examining the outgoing / incoming NID (outgoing / incoming network ID) and the outgoing / incoming port number of the packet extracted by the packet acquiring module 2 from the header portion passed from the packet acquiring module 2, and detecting the corresponding traffic data. To get. If there is no corresponding traffic data, it is created with a new ID.
[0044]
The format of the traffic data is created for IP packets having the same outgoing / incoming NID and incoming / outgoing port. Generally, as shown by reference numeral 7 in FIG. 4, IP information, TCP information or UDP information, and HTTP Four types of information, information, are to be recorded.
[0045]
First, the traffic data storage module 3 records IP information (see step S7).
[0046]
As the details of the IP information, the following information (1) to (6) is stored.
(1) Total number of IP packets (2) Total number of bytes of IP packets (3) Distribution of packet length (4) IP fragmentation (IP fragmentation when the size exceeds the maximum transfer unit when encapsulating IP datagrams) (5) Total number of IP packets for each protocol ID (6) Total number of bytes for IP packets for each protocol ID
Next, from the header portion passed from the packet acquisition module 2, the upper protocol of the IP is TCP, UDP, or the other (ICMP (Internet Control Message Protocol) or IGMP (Internet Group Management Protocol: Internet Group Management Protocol)). Protocol)), and a separate process is performed for each case as described below (see step S8).
[0048]
When the upper protocol of the IP is TCP, first, TCP information not relating to the connection is recorded (see step S9).
[0049]
As the details of the TCP information not related to the connection, the following information (1) to (8) is stored. Here, bidirectional means to distinguish between transmission from the server side (the side that identifies an application by a port number) and transmission from the client side. The TCP segment types are classified into eight types: SYN, SYN + ACK, DT (data segment), ACK, FIN (with data), FIN (no data), RST, and other abnormal types.
(1) Total number of TCP segments (bidirectional)
(2) Total number of bytes in TCP segment (bidirectional)
(3) Total number of TCP segments including MSS (Maximum Segment Size) option (bidirectional)
(4) Total number of TCP segments including WSF (Window Scale Factor) option (bidirectional)
(5) TCP segment total number including time stamp (Time Stamp) option (bidirectional)
(6) Number of retransmitted TCP segments (7) Total number of TCP segments by type (bidirectional)
(8) Total number of bytes in TCP segment by type (bidirectional)
[0050]
Next, the traffic data storage module 3 acquires the ID of the TCP connection (see step S10). In detail, the traffic data storage module 3 has a connection management table and a state transition function, and extracts the incoming / outgoing IP address and the incoming / outgoing port number from the TCP / IP header of the extracted packet, thereby obtaining the TCP / IP of the packet. The connection is identified, and the ID of the TCP connection is acquired from the list in the connection management table. If the identified TCP connection is not in the list of the connection management table, the TCP connection is added to the connection management table, newly created, and its ID is acquired.
[0051]
Then, the traffic data storage module 3 changes the state and updates the connection management table (see step S11). Specifically, the state transition is performed by giving the TCP header of the extracted packet as an input to the previously acquired TCP connection. As the TCP status, five types of CLOSED (no connection), SYN_SENT (transmitted SYN), ESTABLISHED (during data transfer), INIT_FIN_SENT (transmitted FIN), and RES_FIN_SENT (received FIN) are identified. I have.
[0052]
Next, the traffic data storage module 3 stores TCP information related to the connection (see step S12). Specifically, the TCP information obtained in the previous state transition is stored.
[0053]
It is assumed that the following information (1) to (6) is accumulated as the TCP information relating to the connection. Again, bidirectional means to distinguish between transmission from the server and transmission from the client.
(1) Number of TCP connection establishment successes (2) Number of TCP connection establishment failures (3) TCP connection establishment average time (4) TCP connection duration average time (5) Average data transfer amount for each TCP connection (bidirectional)
(6) Throughput per TCP connection (bidirectional)
[0054]
Next, the traffic data storage module 3 checks the upper protocol (application protocol) of TCP (see step S13). Specifically, an application protocol is identified from a port number, and information unique to the application is analyzed.
[0055]
Then, information specific to the application is stored for each application protocol on the TCP (see step S14). For example, if the upper application protocol is HTTP (Hyper Text Transfer Protocol), the number of accesses for each site is stored.
[0056]
After the application-specific information on the TCP is accumulated, the process returns to the process of monitoring the elapse of a predetermined time (step S4).
[0057]
On the other hand, when the upper protocol is UDP in the determination of the upper protocol of the IP (step S8), the UDP information is accumulated (see step S15).
[0058]
The following information (1) and (2) is stored as UDP information.
(1) Total number of UDP datagrams (bidirectional)
(2) Total number of bytes of UDP datagram (bidirectional)
[0059]
Further, the traffic data storage module 3 identifies the application protocol on the UDP from the port number, analyzes the application-specific information, and stores the obtained application-specific information (see step S16).
[0060]
After accumulating the application-specific information on the UDP, the process returns to the elapse of a predetermined time monitoring process (step S4).
[0061]
If the upper protocol is neither TCP nor UDP in the determination of the upper protocol of the IP (step S8), the process returns to the process of monitoring the elapse of a certain time (step S4).
[0062]
Then, when a certain time to be compressed has elapsed, the past traffic data is compressed and converted into coarse-grained traffic data (see step S17).
[0063]
As compression, the originating and terminating NIDs combine traffic data of the same type, the originating and terminating NID and the higher-level protocol (which may be an application protocol) group together traffic data of the same type, and the upper-level protocol (application protocol). Can be achieved by collectively storing traffic data of the same type.
[0064]
The traffic data compressed collectively for each type may be compressed for a longer period of time, and further collectively compressed for each type, and accumulated, so that traffic data having a coarser granularity may be compressed. Of course, if necessary, the time interval may be lengthened in any number of steps, and the data may be compressed one after another into coarse-grained traffic data.
[0065]
In the above description, the traffic monitoring device 1 is connected to an ATM line in the Internet. However, the traffic monitoring device 1 may be connected to a line other than the ATM line. May be.
[0066]
【The invention's effect】
As described above, according to the present invention, traffic data can be compressed and stored in a form as close as possible to a packet flowing on a line between networks. Therefore, traffic monitoring can be operated for a long time corresponding to the high-speed Internet or the like.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration example of a traffic monitoring device according to an embodiment of the present invention.
FIG. 2 is a diagram illustrating an example of a processing procedure of a packet acquisition unit.
FIG. 3 is a diagram showing an example of a processing procedure of a traffic data storage unit.
FIG. 4 is a diagram showing a format example of traffic data.
[Explanation of symbols]
1 traffic monitoring device 2 packet acquisition module (packet acquisition means)
3 Traffic data storage module (traffic data storage means)
4 Statistics information processing module 5, 6 ATM line 7 Traffic data format 11, 12 ATM board 13, 14 ATM router or ATM switch

Claims (6)

Packet acquisition means for extracting a packet from an inter-network line and extracting a header portion including at least an IP header of the extracted packet;
From the contents of the header portion extracted by the packet acquisition unit, the combination of the packet transmission side network ID and the packet reception side network ID of the packet extracted by the packet acquisition unit (hereinafter referred to as the transmission / reception NID) is examined. Traffic data storage means for recording data relating to traffic on the line (hereinafter referred to as traffic data) in a preset format, and collectively storing traffic data having the same type of outgoing and incoming NIDs at regular time intervals; ,
As the traffic data, information relating to the IP protocol (hereinafter, referred to as IP information), information relating to the TCP protocol (hereinafter, referred to as TCP information), information relating to the UDP protocol (hereinafter, referred to as UDP information), and information relating to the application protocol (hereinafter, referred to) , And application protocol information).
When the TCP information is used as the traffic data, the TCP information is distinguished into TCP information related to no connection and TCP information related to a connection ,
TCP information on the connection, using the connection management table for managing the TCP connection, TCP state identified Rukoto features and to belt Rahikku monitoring device information in consideration of the communication procedure. The traffic monitoring device according to claim 1, wherein the IP information includes at least a total number of IP packets and a total number of bytes of the IP packets. The traffic monitoring device according to claim 1 or 2 , wherein the TCP information not related to the connection includes at least a total number of TCP segments and a total number of bytes of TCP segments. Traffic monitoring device according to any one of claims 1 to 3, characterized in that it comprises information about at least the number of connections as the TCP information about the connection. The TCP information on the connection includes at least one of a TCP connection establishment success number, a TCP connection establishment failure number, a TCP connection establishment average time, a TCP connection duration average time, and an average data transfer amount for each bidirectional TCP connection. The traffic monitoring device according to claim 1, wherein: Examples application protocol information, traffic monitoring device according to any one of claims 1 to 5, characterized in that it comprises information about the HTTP protocol, at least one of information about the information and SMTP protocols for FTP protocol.

Images