ITRM20110436A1 - METHOD OF MONITORING TIME OF DOWNLOAD CLIENT SIDE OF AN HTML PAGE, AND RELATED MONITORING SYSTEM. - Google Patents

Description

Method for monitoring the client-side download time of an HTML page, and related monitoring system

The present invention relates to a client-side download time monitoring method of an HTML page, and related monitoring system.

More precisely, the present invention relates to a method for analyzing network traffic using the TCP / IP protocol, in which the client-side download time of an HTML page is measured. The invention also relates to a system which implements the method according to the invention.

The spread and unstoppable growth of the Internet has, over the years, promoted an ever greater specialization of the areas of communication and information technology ("Information Technology & Communication", ITC). The software, the hardware and the telecommunication systems are normally and necessarily integrated components and all cooperating with each other. But, due to increasing complexity, they are increasingly isolated as individual pieces of the puzzle helping to widen an increasingly defined gap between them.

On the other hand, any customer of any information system needs to have his requests satisfied regardless of the complexity of the system that is providing them.

To contain the complexity of the new systems, the presence of conventional monitoring and control instruments of application, operation and maintenance has become widespread. These tools have the characteristic of offering effective solutions for application and management control, but unfortunately they have the limit of excessive specialization. Today, in fact, it is absolutely normal to have an application monitor platform accompanying the chosen development platform as it happens in the networking domain, to equip oneself with platforms (independent of the supplier) for network management (among the main ones: TIVOLI, HPOpenview ) which ensure to end customers the capillary control of all the devices of their network. This must be understood in the sense that current information systems have all the analysis tools necessary to understand the functioning of the individual application blocks.

It should be considered, however, that parallel to the ever-increasing thrust of the free market where all organizations, in competition with each other, are faced with the complex challenge of compliance between the regulatory requirements coming from government institutions and the protection of their own assets and related intellectual property titles, innovation forces all professionals to always find new solutions with which to improve their rankings. And then, more explicitly, how do you answer the following question: "is the knowledge that today it is possible to have about what happens within one's information system and how the various business processes communicate with each other really exhaustive?".

According to authoritative sources (Gartner Group), in all information systems there is a gray area equal to about 20%, which systematically escapes all controls, mainly due to the tremendous rate of software obsolescence.

The software of the main operators in the sector (IBM, Oracle, BEA, Tibco, Microsoft) and of the main operators in the communication sector (Cisco, 3com, etc.) use proprietary solutions and platforms for analysis and problem identification problems that are very effective but not integrated with each other, leaving the burden of this aspect within the application domain to system integration experts.

If, for example, you want to measure the application performance index ("Key Performance Index", KPI) or the QoS service quality index ("Quality of Service") of a simple web application, to date, the methodology adopted, involves a list of measurement activities defined and carried out exclusively in the application area.

This approach, however, is proving to be ineffective for several reasons, the most important of which is certainly the rate of application obsolescence and, therefore, the consequent inability to freeze effective measurement systems for controlling performance indicators in the application domain alone. and therefore the ineffectiveness of using traditional solutions.

As part of this general problem, a more specific problem arises than the measurement of the download time of an HTML page from the Client side.

The solution of this specific problem is necessary to solve the more general problem. Moreover, the definition of the download time of an HTML page exists in the literature (see Figure 1), but there is no methodology to calculate it.

The object of the present invention is to provide a client-side download time monitoring method of an HTML page, which solves the problems and overcomes the drawbacks of the prior art.

A further specific object of the present invention is a client-side download time monitoring system of an HTML page which implements the method which is the object of the invention.

The object of the present invention is a method for calculating the loading time of a web page in network traffic using the TCP / IP protocol suite, using a sniffer for capturing data packets exchanged between applications running on client devices and a server, the method being characterized by the fact of capturing said data packets through a Pcap library, continuously generating and updating a traffic file whose rows or columns correspond to the individual data packets captured, and by executing the following next steps:

A. for each row or column of said traffic file, decide if the data packet is related to an http request, or an http response, or a raw packet, continuously building a hash table and a page file related to the http requests , according to the following sub-phases: Al. in the case of an http request, a corresponding key-value pair is defined within said hash table, in which the key is the acknowledgment of the get and the value contains the sequence, the referer and the IP of said data packet ;

A2. in the case of an http response, find the correspondence between a get in said hash table and the http of the response by looking for the acknowledge value of the get that is identical to the sequence value of the response http, and:

A2a. if the match is found, the corresponding row or column of the hash table will be modified by adding in the corresponding value one or more parameters contained in the data packet of the http response, including at least the nextseq, and saving the packets of data identified in phases Al and A2;

A3. in the case of a raw data packet, search for the correspondence between one of the elements of the hash table and the raw data packet by equating the value of nextseq in said hash table and the sequence value of the raw data packet, and:

A3a. if the match is found, modifying the element found in the hash table by adding one or more data of the raw data packet, including at least the nextseq, and saving said found element on said a page file;

A3b. if the end-chunk character is found, the found element of the hash table referred to in step A3a is saved on said page file and then removed from the same hash table;

B. Once phase A has been carried out for one or more rows or columns of the traffic file, until the collection of TCP / IP data packets relating to an http request in said page file is identified and isolated, calculate the loading time of the web page corresponding to said http request by performing the following steps:

Bl. insert in a user session map, whose rows or columns consist of a key-value pair, a row or column in which the key is the client's IP and the referer of said http request, and the value is a subset the collection of data packets in said page file which have the same IP as the client and referer, containing the first and last packet in time;

B2. after a predefined timeout, calculating the page time simply as the difference between the times of said last and said first packet;

the rows or columns of said user session map corresponding to as many web pages.

Preferably according to the invention, the page loading time with relative page references are saved in a file to be subsequently loaded on a DBMS.

Preferably according to the invention, in step B1, said subset coincides with the collection of the data packets.

A further specific object of the present invention is a system for analyzing network traffic using the suite of TCP / IP protocols, characterized in that it comprises:

- one or more devices connected to the network and generating data traffic;

- a router and a switch interposed between said one or more devices and the network;

- a sniffer for capturing the data packets from the data traffic, connected to said switch; - a data analysis device, which analyzes the captured packets,

said data analysis device comprising code means suitable for carrying out the method object of the invention.

Preferably according to the invention, said switch does not have the functionality of mirror port or spam port, the use of the "taps" connected between switch and sniffer is used.

The invention will now be described for illustrative but not limitative purposes with particular reference to the drawings of the attached figures, in which: - figure 1 shows the layered display of the operation of the method according to the invention;

Figure 2 shows a block diagram of a possible configuration of the system according to the invention;

Figure 3 is a schematic representation of the analysis process according to the invention.

Figure 4 shows a download time measurement diagram according to the prior art; Figure 5 shows a block diagram of the system according to the present invention;

Figure 6 shows a mixed block and flow diagram illustrating the method and the system according to the invention;

Figure 7 shows a flow chart illustrating the method according to the invention;

Figure 8 shows a further flow diagram illustrating the method according to the invention;

Figure 9 shows the data of a specific example of operation of the method according to the invention; Figure 10 shows further data of a specific example of operation of the method according to the invention;

Figure 11 shows further data of a specific example of operation of the method according to the invention;

- figure 12 shows the final aggregate data relating to the specific example of operation of figures 9-11.

The general method of diagnostics

The general diagnostic method according to the invention aims to fill the gap left by traditional solutions starting from the analysis of the data flow, reconstructing the various application sessions in order to support the algorithm for defining the quality index, be it KPI or QoS.

Basically, what happens is having shifted the objective from the application context to that of the service by having a tool capable of behaving like a client of the application starting from the knowledge of the answers that the application server gives to client requests.

In this way, and without impacting the application architecture, the problem of processing performance indicators is solved regardless of the application obsolescence rate.

The TCP / IP protocol

Data traffic in the network is organized on different levels. The model currently used by most applications running on the Internet is TCP / IP. The stack (or "stack") of TCP / IP protocols consists of 4 levels:

I. central computer-network,

II. net

III. transport,

IV. application.

The central processor-network layer is used to carry bits between the two ends of a physical channel. The network layer is used to route packets. The transport layer is used to handle "end-to-end" (or "end-t or-end") communication flow and error control. The application layer has the purpose of making the traffic useful for the operation of the applications running on the network nodes.

Each layer has its own protocols associated with it.

Regarding the central processor layer, the currently predominant standard is Ethernet (IEEE 802.3). The Ethernet header consists of source and destination addresses (each of 48 bits), a type code, data, and finally a "CRC checksum".

Encapsulated within the data section of the frame are information relating to the other protocols.

The network layer is dominated by the IP protocol. There are two versions of IP currently in use, IPv4 and IPv6. While Ipv6 is set to be the new standard, most applications make use of Ipv4. An Ipv4 header consists of 13 different fields for a total of 196 bits.

For the purposes of the general problem dealt with here, only 3 of these fields will be considered. The addresses indicated are:

I. source,

II. destination (32 bits each),

III. the 8-bit protocol flag.

As can be seen, the addresses of this layer are end-to-end, unlike Ethernet addresses which are point-to-point.

The next layer in the TCP / IP stack is the transport layer. Unlike the first two layers, there are numerous protocols at the transport layer. TCP is what will be considered for the present invention.

This protocol handles end-to-end flow control and error control. Its function is to ensure that the data transmitted by the sender is received in order and without errors by the recipient. At the top of the protocol stack is the application layer.

The application layer protocol, which is of interest, in this description, for passive interception or "sniffing" activity is HTTP: "Hyper Text Transfer Protocol". The first version, 0.9, of HTTP dates back to the late 1980s and constituted, together with HTML and URL, the core of the "World Wide Web Global Information Initiative" carried out by Sir Tim Berners Lee at CERN of Geneva for the sharing of information (documents and scientific articles) among the community of high energy physicists.

HTTP operates through a request / response mechanism: the client sends a request message and the server returns the response. In common use, the client corresponds to the browser and the server to the website. There are therefore two types of HTTP messages: request messages and response messages.

The sniffer

Sniffers, better known as protocol analyzers, can be used for a multitude of purposes.

A sniffer is an application that low-level accesses data passing through a network card before it is manipulated by the protocol stack; this is called capture or sniff fing.

For whatever purpose they are used, two components a network sniffer must have are a "tap" and a filter.

The tap is a mechanism that allows the sniffer to receive all traffic in transit on a network card ("Network Interface Card", NIC). This is possible by activating the so-called "Promiscuous Mode" of the NIC in question. Promiscuous Mode is a mode of operation in which the network card ignores the destination field of an Ethernet header and accepts all traffic in transit. Without its activation, a NIC will only accept traffic that is directed towards it, ie Ethernet units that have its physical address in the destination field.

Whether it is a Windows or Unix Operating System, the activation of Promiscuous Mode is possible only through the use of libraries for packet capture (PCAP).

PCAP, initially developed for Unix-like operating systems (e.g. BSD) is now also available for Windows systems and its name has changed to WINPCAP.

Before further analyzing the functioning of a sniffer it is necessary to take into consideration the position that the computer, on which the sniffing program is running, must occupy in order to be able to intercept the traffic. In fact, it must be connected to a HUB that is located on a layer halfway between the nodes of interest and the external network or it must be located at a switch that performs the replication or "mirroring" of a port through which data transit between a client and a server. This principle is illustrated in Figure 2 '.

The bulk of the work done by a system such as WinPcap is related to interfacing with the network card through the driver that governs it, the extraction of the traffic that circulates on the network, the filtering of the data obtained on the basis of user-specific, all operations that are not allowed to a normal application. This is why it is necessary to rely on a device driver, which represents an extension of the services offered by the core of the operating system (kernel).

Furthermore, the capture of packets and their delivery to applications must be done very carefully if good performance is to be achieved.

The first operation performed by the NPF is filtering; in order to avoid unnecessary copies and save space on the buffer, this operation is normally performed at the beginning of the packet manipulation chain. The filter is created by the user through a compiler provided by WinPcap. It consists of a predicate expressed according to propositional logic, that is, in a set of conditions linked by suitable Boolean operators.

The NPF is made using the "NDIS" interface ("Network Driver Interface Specification") which represents the standard for communication between a network card and the driver that implements the protocol. The main function of NDIS is to act as a "wrapper" to allow protocol drivers to send and receive packets over the network without worrying about the nature of the hardware or the particular version of Win32.

The NPF is therefore implemented as a protocol driver and, although this choice is not performance oriented, it guarantees considerable independence from the MAC sublayer and full access to raw data traffic.

Referring to figure 1 ', the method according to the invention is able to analyze the packets captured through the WinPcap or other Pcap libraries (the first level from the bottom in the figure represents the network card drivers present on the operating system, the second level is the packet capture part and this is where WinPcap works).

The packets are then analyzed (third level of the stack in the figure) on the basis of predetermined rules. The analysis is actually a first data filter to extract the data of the application domain of interest.

These filtered data are sent to the next layer (fourth layer in Figure 1) which catalogs them by type according to the protocol requested by the end user of the system according to the invention. Here, the parameters and information necessary for the analysis of the response functionality of applications running at the level of the devices 10 and communicating from the outside to the inside and from the inside to the inside are extracted from the data in each category. For example, if the system detects the passage of a request, it then waits for the passage of the relative response, then analyzes the content of both in order to build a KPI ("Key Performance Indicator") through which to monitor the operation of the application that generated the response.

The cataloged data is then sent to the next level (fifth layer in figure 1) for writing such data into a database.

The last layer in the figure concerns the visualization of the data.

With reference now to Figure 2 ', an example of architecture of the system 100 according to the invention is illustrated below. Various apparatuses 10 connected to the network 50 generate data traffic. Between the devices 10 and the network 50 a classic router 40 and a switch 20 are interposed (if this switch does not have the function of mirror port or spam port, then the above taps connected between switch and sniffer are used) . A sniffer 30 is connected to this switch 20 for capturing the above packets.

The packets are then analyzed as above by a device 60 and displayed on a device 70.

Referring now to Figure 3, the data extraction process according to the invention is described in greater detail.

A data packet 80 extracted from sniffer 30 is divided by IP or Vlan address, and the system is faced with a string like the one below:

148394 (MS); 192. 168.0.1 (IPSORG); 192 .168.0.4 (IP_DEST); 2567543324 (SEQ); 9827397927 (ACK); GET: google .it / open / inde x.html (URL) | (example request)

148542 (MS); 192.168.0.4 (IPSORG); 192. 168.0.1 (IP_DEST); 9827399004 (SEQ); 256 7543325 (ACK); HTTP: 404 (HTTP CODE) | (example answer)

From this string the software captures a series of information such as:

- Source IP

- Destination IP

- Milliseconds

- Sequence Number

- Acknowledgment number

- URL

- Http code

You must first divide the traffic into requests and responses.

The requests depart from the client to the server, so in this case the source IP will be the client making the request and the Destination IP that of the server on which the requested data are located, the time in milliseconds determines the delay with which records the server response from the moment the client request arrives. The "Sequence Number" is a sequential number generated during the transaction to reconstruct the data at the end of the transmission, while the "acknowledgment" is a confirmation code sent by the destination machine to say that the previous packet has arrived successfully.

In the replies the data are the same (inverting the position of client and server) with the additional information concerning the http code that was replied to the requested URL.

In this way, all the information necessary for analyzing the functionality of the applications running on the devices 10 and the functionality of their connection to the server is available.

The solution according to the invention is able to guarantee:

- a single point for the acquisition of information;

- a high acquisition rate (> = 500 Mbit / s) with channel aggregation.

Real-time monitoring of application KPIs:

- QoS ("Quality of Services"),

- "trouble Ticketing Time Through" (the system is able to notify the staff responsible for controlling the computer systems in near real time (one minute delay), in order to reduce the number of calls from end users who use the application),

- the ability to self-repair;

- complete and non-intrusive integration with all existing business processes;

- 100% scalability and business continuity.

Measurement of download time

The more specific method according to the invention has the purpose of monitoring the download time on the client side of a complex HTML page, less than the network latency time, for data transmitted in clear text.

By page download time we mean the time elapsed from the moment the HTTP request starts from the browser to when the browser gives the end message. Any requests originating from within the page (such as ajax requests or animations) are calculated separately.

It is thus possible to monitor and archive HTTP traffic in transit for the analysis of workloads on the monitored portal or on a generic HTTP domain.

Referring to figure 4, the monitored parameters are analyzed in detail and how to intervene in the download time detection procedure.

When a user requests a WEB page, he implicitly requests a set of URLs, which consist of the page properly requested and all the elements included in it such as: images, frames, videos, etc.

According to the invention, the detected time starts from the moment of the request by the client up to the moment in which the last packet arrives containing an "HTTP RESPONSE" relative to the page in question. The detection of page time does not take into account any HTTP requests that originate from the page asynchronously, such as requests relating to ajax components. These requests are detected autonomously.

The ultimate purpose is to provide the network operator with a tool external to the interview that allows its constant monitoring and archiving of the same in order to trace any malfunctions and / or failure to provide services. The method according to the invention is configured in order to provide the following functionalities:

- integration with a LAN for the interception of a data flow on TCP / IP in HTTP application protocol (data in clear text);

- interception and subsequent saving of the same data flow;

- syntactic analysis ("parsing") of the data flow saved on file in order to analyze and reconstruct the data of interest;

- saving data of interest on RDBMS;

- consultation of the collected data via WEB interface with password protected access and user profiling.

The architecture of the method according to the invention and of the related processing module provides that the processing is preferably carried out by a proprietary system made mainly in C / C ++ in a Linux environment; a relational database such as ORACLE or Postegresql is preferably used for data storage.

The processing module according to the invention will interface for example within a VLAN for the interception of a data flow, this TCP / IP flow will be suitably redirected by a dedicated network device (switch, dispatcher, tap, span port ) on an Ethernet interface of the PROBE or PROBES participating in the process (with PROBE we mean a device dedicated to a specific task defined in the architecture according to the invention).

With regard to the technologies for interception of packets in transit on the network, a C software module will preferably be used which makes use of the functions provided by the PCAP library. The syntactic analysis of the packages is preferably carried out by means of a program in C ++ and the storage of the information on the RDBMS is carried out by means of a LOADER written entirely in JAVA language. Data management within the RDBMS is preferably carried out through PLSQL (Oracle) - PLPGSQL (Postgresql) procedures that use advanced archiving concepts typical of the data warehouse methodology. Access to the data and their presentation preferably takes place via a WEB interface created in PHP: information security is preserved thanks to access through authentication and through the profiling of the authenticated user. The functionalities of the method according to the present invention can be integrated within an integrated web diagnostics platform.

Referring now to figure 2 ("deployment diagram"), it is possible first of all to identify the object of monitoring: in our case it is a portal that contains WEB applications. The network traffic directed / generated on this portal must be made accessible, through appropriate replication mechanisms / apparatuses, to the appliance dedicated to sniffing TCP / IP packets (PROBE).

The method according to the invention comprises the use of the following hardware / software components.

First of all, a PROBE is used: it contains means for carrying out the sniffing process and the parsering and saving process of the data of interest (preferably, the first is in C while the second in C ++). The data transfer on the db is preferably done through a JAVA jar.

A software module called "EVENT COLLECTOR" is used: it contains the RDBMS with the database of the integrated platform according to the invention. In the database, data retention techniques are implemented that allow you to save aggregate and detailed data, allowing you to define the desired storage time for the latter.

Finally, a WEB SERVER is used, which contains the presentation component with which it is possible to access the functions of the aforementioned integrated diagnostic platform.

The software relating to the method according to the invention can be installed directly on the EVENT COLLECTOR machine, even if, for reasons of efficiency, installation on the PROBE is preferred as in figure 5.

To describe the general process of HTTP CRONO PAGE, reference is now made to the diagram in figure 6. From the architecture shown, the process that undergoes the information when it arrives inside the system can be deduced. The actors that can be identified are 3:

- PROBE;

- EVENT COLLECTOR; And

WEB SERVER.

Referring to figure 7, the operation of the INTERPRETER block installed on the PROBE, which calculates the download time, is now illustrated in detail. This algorithm has its foundation in the Referer field, which is a field of the HTTP header. The Referer is the URL of the previous HTTP request.

The interpreter works on three basic steps:

- Reconstruction of the single http request;

- Collection of all requests divided by IP Client and Referer (identifying the previous request); subsequently, for each single collection, the first and last packet sent is taken, which thus turns out to be the time elapsed for the page download;

- Dumping of a data file which will then be loaded on the database.

The algorithm shown in figure 7 is performed for each pcap type file captured by the network. The .pcap file is sent at predefined time intervals (for example every 60 seconds): therefore the program according to the invention will be activated by an event generator when the file arrives and the activity shown in the diagram will begin.

The .pcap file is opened and for each line you decide:

- If it is an http request (get / post, see appendix);

- If it is an http response;

- If it's a raw package.

In the first case, a new element is defined inside a hash table type container (for the definition of hash table or "map" see the page http: //it.wikipedia.org/wiki/Hash_table). The element will have a key-value pair that will have as its initial key the acknowledgment of the get and as its value the parameters contained in the package: sequence, acnnowledge, port srg, mac_server, current milsec, uri, host, referer.

In the second case it will be a question of finding the correspondence between the get (elements inserted in the map) and the response http (current packet) through the get acknowledgment and the response http sequence, in short the get acknowledgment must be equal to the sequence of the response http. If the match is found, the map element (the get) will be modified by adding the parameters contained in the response packet http: content type, content length (total size in bytes of the requested object), packet length (size in bytes of the packet current (TCP / IP))), nextseq (the next valid sequence for aggregation), bytes of data that make up the object. In this case the element is saved on a new .txt file which will then be processed in the next step of the algorithm.

In the third case we will search for the correspondence between one of the map elements and the current raw package through the nextseq values of the first (map element) and sequence of the second (current raw package). If the match is found, the map element will be modified by adding the data of the current raw package: bytes of data that make up the requested object, packet len, nextseq, also in this case the element is saved on the .txt file processed in the next step of the algorithm.

If the endchunk character (which indicates the end of the sequence of data making up the object) is found in the response http or in the raw package, the element is saved on the processing .txt file and then removed from the map.

Once the sessions have been reconstructed, that is, having identified and isolated the sequence of tcp / ip packets relating to a single http request, it is described with reference to Figure 8 how the page time is calculated from all of these.

The diagram shows that the activity consists of two actions.

The first is to reconstruct the User Session Map which has as key <ip of the Client, referer> of the page while the value is the collection of packages that have the same <ip of the Client, referer> (for performance reasons they can be stored only the first and last pack of the collection).

The second is, for each completed collection - and the invention considers it completed if a predefined timeout has passed - calculate the page time simply as the difference between the last and the first packet sent. The timeout may depend on the configuration of the monitored host platform or a customer specification. If the timeout is not yet exceeded, the collection is stored and analyzed in the next time interval: this is because the page may still be downloading.

A third phase is included in the previous diagram and involves saving the calculated page times with the relative references (eg IPClient, download start time, page size, etc.) in a file to be subsequently uploaded to the DBMS.

Specific example of realization

An example of calculation carried out with the method of the invention is reported below.

The page whose download time was measured is the home page of Google <®> Italy. The information received in a normal data capture session is a set of records identical to those presented here but, obviously, with different values.

According to the invention, this sequence of records recognizes an http request of the get / post type (not reported here as it is well known in the literature). Once the previously defined packet has been identified (we have seen that in the traffic flow a packet that has the parameters of an HTTP request is isolated and from this packet the analysis according to the invention begins; the parameters to recognize a request HTTP are the port, standard 80, and the paying load or "payload" that begins with GET, POST or other less frequent indexes but known in the literature), the record of figure 9 has been isolated.

Now we go to search in the captured packet sequence the one whose sequence will have the value Sequence + PacketSize = 1314709076 + 1430 = 1314710506. This will be the next packet in the data transmission. The package in question is shown as an element in the table in Figure 10.

This type of activity is recursively repeated until the end-chunk signal is found which indicates the end of the data transmission relating to the request. In this way it is possible to isolate the single http request that is defined as "atomic" within a complex page.

Once all these sets have been reconstructed, they are discriminated by IP address and by referer: in this way we will have a set of all the sequences that have both these parameters equal. This set is presented in the table of figure 11. The figure shows all the HTTP requests that concur to form the page in question. The column highlighted in yellow is the one that represents the arrival time of the individual packets (time in which the packet is captured) in milliseconds while the components of the page can be seen in the last column.

Figure 12 shows the aggregate information which will then be saved on the database. Also in yellow is the download time (in milliseconds) of the page which is thus saved on the database and will then be available to the end user through the WEB interface of the integrated system of the invention.

The benefits that can be obtained from the system according to the invention are manifold, the following aspects are emphasized here:

- "near real time" monitoring of Client requests on a WEB portal;

- measurement of the time it takes each HTTP page to be downloaded on the Client side;

- saving of the data trend with a time window defined at the request of the user;

- provision of useful data to a user-oriented and integrated reporting system e.g. in a web diagnostics portal.

The method can be used within a complex information system in order to monitor and archive its global status.

In the foregoing, the preferred embodiments have been described and variants of the present invention have been suggested, but it is to be understood that those skilled in the art will be able to make modifications and changes without thereby departing from the relative scope of protection, as defined by the claims attached.

Claims (5)

CLAIMS 1. Method for calculating the loading time of a web page in network traffic using the TCP / IP protocol suite, using a sniffer (30) to capture data packets exchanged between applications running on devices ( 10) client and a server (50), the method being characterized by the fact of capturing said data packets through a Pcap library, continuously generating and updating a traffic file whose rows or columns correspond to the individual data packets captured, and by '' execution of the following successive phases: A. for each row or column of said traffic file, decide if the data packet is related to an http request, or an http response, or a raw packet, continuously building a hash table and a page file related to the http requests , according to the following sub-phases: Al. in the case of http request, a corresponding key-value pair is defined within said hash table, in which the key is the get acknowledgment and the value contains the sequence, the referer and the IP of said data packet; A2. in the case of an http response, find the correspondence between a get in said hash table and the http of the response by looking for the acknowledge value of the get that is identical to the sequence value of the response http, and: A2a. if the match is found, the corresponding row or column of the hash table will be modified by adding in the corresponding value one or more parameters contained in the data packet of the http response, including at least the nextseq, and saving the packets of data identified in phases Al and A2; A3. in the case of a raw data packet, search for the correspondence between one of the elements of the hash table and the raw data packet by equating the value of nextseq in said hash table and the sequence value of the raw data packet, and: A3a. if the match is found, modifying the element found in the hash table by adding one or more data of the raw data packet, including at least the nextseq, and saving said found element on said a page file; A3b. if the end-chunk character is found, the found element of the hash table referred to in step A3a is saved on said page file and then removed from the same hash table; B. Once phase A has been carried out for one or more rows or columns of the traffic file, until the collection of TCP / IP data packets relating to an http request in said page file is identified and isolated, calculate the loading time of the web page corresponding to said http request by performing the following steps: Bl. insert in a user session map, whose rows or columns consist of a key-value pair, a row or column in which the key is the client's IP and the referer of said http request, and the value is a subset the collection of data packets in said page file which have the same IP as the client and referer, containing the first and last packet in time; B2. after a predefined timeout, calculating the page time simply as the difference between the times of said last and said first packet; the rows or columns of said user session map corresponding to as many web pages. Method according to claim 1, characterized in that the page loading time with relative page references are saved in a file to be subsequently loaded on a DBMS. 3. Method according to claim 2, characterized in that in step B1, said subset coincides with the collection of data packets. 4. System (100) for analyzing network traffic using the TCP / IP protocol suite, characterized by the fact that it includes: - one or more devices (10) connected to the network (50) and generating data traffic; a router (40) and a switch (20) interposed between said one or more devices (10) and the network (50); - a sniffer (30) for capturing the data packets from the data traffic, connected to said switch (20); - a data analysis device (60), which analyzes the captured packets, said data analysis device comprising code means suitable for carrying out the method according to any one of claims 1 to 3. 5. System according to claim 4, characterized by the fact that, if said switch (20) does not have the functionality of mirror port or spam port, the "tap" connected between switch (20) and sniffer (30) is used .