ITRM20110437A1 - Metodo per l?analisi ?near real time? di elevate quantità di traffico dati su suite di protocolli tcp/ip, e relativo apparato. - Google Patents

Description

Metodo per l'analisi "near reai time" di elevate quantità di traffico dati su suite di protocolli TCP/IP, e relativo apparato

La presente invenzione riguarda un metodo per l'analisi "near reai time" di elevate quantità di traffico dati su suite di protocolli TCP/IP, e relativo apparato.

Più precisamente, la presente invenzione riguarda un metodo per l'analisi "near reai time" del traffico di rete che suddivide il traffico inviandolo a due o più core di un processore multi-core. L'invenzione riguarda altresì un sistema che implementa il metodo secondo l'invenzione.

La diffusione e la crescita inarrestabile di Internet ha, nel corso degli anni, promosso una sempre maggiore specializzazione delle aree della comunicazione e tecnologia dell'informazione ("Information Technology & Communication", ITC). Il software, 1'hardware e i sistemi di telecomunicazione sono normalmente e necessariamente componenti integrate e tutte cooperanti tra loro. Ma, a causa della crescente complessità, sempre più isolate come singoli pezzi del puzzle contribuendo ad ampliare un gap sempre più definito tra loro.

D'altro canto, un qualsiasi cliente di un qualsiasi sistema informativo ha la necessità di vedere soddisfatte le sue richieste indipendentemente dalla complessità del sistema che le sta erogando.

Per contenere la complessità dei nuovi sistemi, si è diffusa, a corredo delle applicazioni, la presenza di strumenti di monitoraggio e controllo convenzionali di tipo applicativo, funzionamento e manutenzione. Tali strumenti hanno la caratteristica di offrire efficaci soluzioni per il controllo applicativo e gestionale, ma hanno, purtroppo, il limite della eccessiva specializzazione. È oggi, infatti, assolutamente normale disporre di una piattaforma di monitore applicativo a corredo della piattaforma di sviluppo scelta così come accade nel dominio del networking, dotarsi di piattaforme (indipendente dal fornitore) per la gestione di rete (tra le principali: TIVOLI, HPOpenview) che assicurano ai clienti finali il controllo capillare di tutti gli apparati della propria rete. Questo va inteso nel senso che gli attuali sistemi informativi hanno tutti gli strumenti di analisi necessari per capire il funzionamento dei singoli blocchi applicativi.

Va considerato, tuttavia, che parallelamente alla spinta sempre maggiore del libero mercato dove tutte le organizzazioni, in concorrenza tra loro, si trovano ad affrontare la complessa sfida della conformità tra i requisiti regolatori provenienti dalle istituzioni governative e la tutela dei propri asset e dei relativi titoli di proprietà intellettuale, l'innovazione costringe tutti gli addetti ai lavori a trovare sempre nuove soluzioni con cui migliorare i propri posizionamenti. E allora, più esplicitamente, come si risponde alla seguente domanda: "è veramente esaustiva la conoscenza che oggi è possibile avere circa che cosa succede all'interno del proprio sistema informativo e come comunicano tra di loro i vari processi aziendali?".

Secondo fonti autorevoli (Gartner Group), in tutti i sistemi informativi esiste un'area grigia circa pari al 20%, che sfugge sistematicamente a tutti i controlli, soprattutto a causa del tremendo tasso di obsolescenza del software.

I software dei principali operatori del settore (IBM, Oracle, BEA, Tibco, Microsoft) e dei principali operatori del settore comunicazione (Cisco, 3com, ecc.) utilizzano soluzioni e piattaforme proprietarie per i problemi di analisi e individuazione di problema efficacissimi ma non integrati tra loro demandando agli esperti di integrazione di sistema l'onere di questo aspetto all'interno del dominio applicativo.

Se, per esempio, si desidera misurare l'indice di performance ("Key Performance Index", KPI) applicativo o l'indice di qualità del servizio QoS ("Quality of Service") di una semplice applicazione web, ad oggi, la metodologia adottata, comporta un elenco di attività di misura definite ed eseguite in ambito, esclusivamente, applicativo.

Questo approccio, però, si sta dimostrando inefficace per diversi motivi, il più importante dei quali è sicuramente il tasso di obsolescenza delle applicazioni e, quindi, la conseguente incapacità di congelare sistemi di misura efficaci per il controllo degli indicatori di performance nel solo dominio applicativo e quindi l'inefficacia dell'utilizzo di soluzioni tradizionali.

Nell'ambito di questo problema generale, se ne pone uno più specifico della velocizzazione dell'analisi dei dati, ovvero dell'aumento della quantità dei dati trattabili per unità di tempo.

La soluzione di questo specifico problema è necessaria per risolvere il problema più generale. Del resto, non esiste in letteratura una soluzione affidabile al riguardo, perché se una suddivisione deve essere fatta del traffico in entrata, essa non può essere arbitraria, in quanto il traffico va ricostruito integralmente a valle.

Scopo della presente invenzione è quello di fornire un metodo di indagine, non intrusiva ed indipendente dalle infrastrutture applicative, del traffico di rete nei sistemi informatici e di telecomunicazioni .

Forma ulteriore scopo della presente invenzione un sistema informatico che implementa il metodo scopo della presente invenzione.

E' oggetto della presente invenzione un metodo per l'analisi "near reai time" di elevate quantità di traffico dati di rete su suite di protocolli TCP/IP, contenenti coppie di richieste e risposte tra un server ed un client, il traffico dati consistendo globalmente di un flusso di pacchetti di dati, caratterizzato dal fatto di eseguire le seguenti fasi:

A. leggere i campi della suite di protocolli TCP/IP di detto flusso di pacchetti di dati;

B. identificare, tra i campi della fase A, per ciascuna richiesta effettuata dal client una stringa binaria costituita dal numero di source port oppure dall'indirizzo IP del client stesso; C. suddividere detto flusso di pacchetti di dati in un numero intero positivo pari Q di sotto-flussi di pacchetti di grandezza simile, raggruppando i pacchetti a cui è associato lo stesso valore di detta stringa binaria;

D. analizzare i Q sotto-flussi su corrispondenti Q unità elettroniche di elaborazione.

Preferibilmente secondo l'invenzione, dette Q unità elettroniche di elaborazione corrispondono a altrettanti core di una CPU multi-core.

Preferibilmente secondo l'invenzione, nella fase E si suddivide il flusso di pacchetti di dati in due sotto-flussi a cui corrispondono rispettivamente valori pari e valori dispari di detta stringa binaria.

Preferibilmente secondo l'invenzione, nel caso di suddivisione del flusso di pacchetti di dati in Q=4 sotto-flussi, si suddivide il traffico sui valori 00/01/10/11 degli ultimi due bit di detta stringa binaria.

Preferibilmente secondo l'invenzione, detto traffico di dati di rete è ottenuto tramite sniffing, e successivamente alla fase D si esegue la seguente ulteriore fase:

E. ricostruire detto flusso di pacchetti di dati a partire dai Q sotto-flussi analizzati.

Preferibilmente secondo l'invenzione, prima della fase C si effettua un filtro dei dati che seleziona solo le informazioni di interesse per l'analisi della fase D.

Preferibilmente secondo l'invenzione, detta fase A utilizza uno sniffer per la cattura di pacchetti di dati scambiati tra applicativi che girano su dispositivi (10) di detti client e server, tramite una libreria Pcap.

Preferibilmente secondo l'invenzione, la fase D comprende le seguenti sottofasi:

D_1. analizzare i pacchetti di dati in base a regole predeterminate, tale analisi fungendo da primo filtro per estrarre i dati del dominio applicativo di interesse;

D_2. catalogare i dati per tipologia a seconda del protocollo richiesto dall'utente;

D_3. estrarre da detti pacchetti di dati in ciascuna categoria i parametri e le informazioni necessarie per l'analisi della funzionalità di risposta di applicativi che girano al livello dei dispositivi (10) e comunicano dall'esterno verso l'interno e dall'interno verso l'interno, tra cui:

- indirizzo IP Sorgente;

- indirizzo IP Destinazione;

- ritardo di risposta in millisecondi;

- Sequence Number;

- Acknowledgement number;

- URL;

- codice http, nel caso di comunicazione verso l'esterno;

D_4. scrivere i dati estratti in una apposita base di dati .

Le regole di cui alla fase D_2 per la determinazione di possibili errori o problemi vengono determinate di volta in volta con chi utilizza effettivamente il metodo, infatti non esistono soglie oggettive entro le quali si deve trovare un'applicazione, ma vengono definite in base alle specifiche tecniche di progettazione. Per esempio, un utente può scegliere di controllare un'applicazione in base ai tempi di risposta del server, ma questo tipo di filtro sarà configurato in maniera diversa rispetto al cliente finale, e potrebbe non interessare ad altri clienti .

Preferibilmente secondo l'invenzione, si esegue una ulteriore successiva fase F di visualizzazione dei dati scritti nella base di dati.

Preferibilmente secondo l'invenzione, si calcola, nella fase D_3, un "Key Performance Indicator" attraverso il quale monitorare il funzionamento dell'applicazione che ha generato la risposta, detto KPI essendo scritto ugualmente in detta base di dati.

Come per le regole legate al filtro delle informazioni, anche nel caso dei KPI essi vengono valutati insieme al cliente, riallacciandosi all'esempio legato ai tempi di risposta. Il KPI potrà essere scelto dal cliente in base ad una serie di soglie come il superamento di un certo numero di risposte con tempi alti. In questo caso, sulla pagina principale dell'interfaccia web apparirà un'icona che avvisa il personale preposto circa un possibile problema o rallentamento.

E' ulteriore oggetto della presente invenzione un sistema per l'analisi del traffico di rete utilizzante il protocollo TCP/IP, caratterizzato dal fatto di comprendere:

- uno o più dispositivi connessi alla rete e generanti traffico di dati;

- un router e un commutatore interposti tra detto uno o più dispositivi e la rete;

- uno sniffer per la cattura dei pacchetti di dati dal traffico dati, collegato a detto commutatore; - un dispositivo di analisi dati, che analizza i pacchetti catturati,

detto dispositivo di analisi dati comprendendo una pluralità di CPU core e mezzi a codice atti ad eseguire il metodo oggetto della presente invenzione.

Preferibilmente secondo l'invenzione, se detto commutatore non ha la funzionalità di mirror port o spam port, si ricorre all'uso dei "tap" collegati tra commutatore e sniffer.

L'invenzione verrà ora descritta a titolo illustrativo ma non limitativo, con particolare riferimento ai disegni delle figure allegate, in cui: - la figura 1 mostra la visualizzazione a strati del funzionamento del metodo secondo l'invenzione;

- la figura 2 mostra uno schema a blocchi di una possibile configurazione del sistema secondo 1'invenzione;

- la figura 3 è una rappresentazione schematica del processo di analisi secondo l'invenzione;

la figura 4 mostra un flusso logico di dati suddiviso secondo l'invenzione;

la figura 5 mostra la differenza tra le risorse richieste per l'elaborazione a flusso singolo e a due flussi, a parità di hardware "quadcore";

la figura 6 mostra l'andamento del tempo di calcolo in funzione del numero di pacchetti analizzati, per la soluzione a flusso singolo e quella a due flussi, rispetto alla "soglia critica" di pacchetti di traffico effettivamente elaborabili in un'unità di tempo;

— la figura 7 mostra un diagramma illustrativo di un esempio specifico di funzionamento dell'invenzione .

II metodo generale di diagnostica

Il metodo secondo l'invenzione ha l'obiettivo di colmare il vuoto lasciato dalle soluzioni tradizionali a partire dall'analisi del flusso dati, ricostruendo le varie sessioni applicative in modo da sostenere l'algoritmo di definizione dell'indice di qualità, sia esso KPI che QoS.

In buona sostanza ciò che accade è aver spostato l'obiettivo dal contesto applicativo a quello del servizio avendo a disposizione uno strumento capace di comportarsi come un cliente dell'applicazione a partire dalla conoscenza delle risposte che il server applicativo dà alle richieste dei Client.

In questo modo e senza impatti sull'architettura applicativa, si risolve il problema della elaborazione degli indicatori di performance indipendentemente dal tasso di obsolescenza dell'applicazione.

II protocollo TCP/IP

Il traffico dati, nella rete, è organizzato su diversi livelli. Il modello attualmente in uso dalla maggior parte delle applicazioni in esecuzione su Internet è il TCP/IP. La pila (o "stack") di protocolli TCP/IP è composta da 4 livelli :

I. elaboratore centrale-rete,

II . rete,

III . trasporto,

IV. applicazione.

Lo strato elaboratore centrale-rete è utilizzato per trasportare bit tra i due capi di un canale fisico. Il livello di rete è utilizzato per instradare i pacchetti. Il livello di trasporto è usato per gestire il flusso di comunicazione "da estremità a estremità" (o "end-t o-end" ) ed il controllo degli errori. Il livello applicazione ha come scopo quello di rendere il traffico utile per il funzionamento degli applicativi in esecuzione sui nodi della rete.

Ogni strato ha i suoi protocolli ad esso associati .

Relativamente allo strato elaboratore centralerete, lo standard attualmente predominante è Ethernet (IEEE 802.3) . L'intestazione (header) Ethernet consiste di indirizzi sorgente e destinazione (ciascuno di 48 bit), un codice di tipo ("type code"), dati, ed infine un "CRC checksum".

Incapsulati all'interno della sezione dati della trama ci sono le informazioni relative agli altri protocolli.

Lo strato rete è dominato dal protocollo IP. Ci sono due versioni di IP attualmente in uso, IPv4 e IPv6. Mentre Ipv6 si appresta ad essere il nuovo standard, la maggior parte delle applicazioni fa uso di Ipv4. Un header Ipv4 consiste di 13 campi differenti per un totale di 196 bit.

Per gli scopi di questo documento, solo 3 di questi campi saranno presi in considerazione.

Gli indirizzi indicati sono:

I. sorgente,

II. destinazione (32 bit ciascuno),

III. l'indicatore di protocollo di 8 bit.

Come si può osservare, gli indirizzi di questo strato sono da end-to-end, diversamente dagli indirizzi Ethernet che sono point-to-point.

Il successivo strato nella pila TCP/IP è il livello di trasporto. A differenza dei primi due strati, ci sono numerosi protocolli al livello trasporto. Il TCP è quello che sarà preso in considerazione per la presente invenzione.

Questo protocollo gestisce il controllo di flusso end-to-end e di errore. La sua funzione è quella di assicurare che i dati trasmessi dal mittente siano ricevuti in ordine e senza errori dal destinatario.

In cima alla pila di protocolli c'è il livello applicazione .

Il protocollo di livello applicazione, che è di interesse, in questa descrizione, per l'attività di intercettazione passiva o "sniffing" è HTTP: "Hyper Text Transfer Protocol". La prima versione, la 0.9, dell'HTTP risale alla fine degli anni '80 e costituiva, insieme con 1'HTML e URL il nucleo base della "World Wide Web Global Information Initiative" portata avanti da Sir Tim Berners Lee al CERN di Ginevra per la condivisione delle informazioni (documenti e articoli scientifici) tra la comunità dei fisici delle alte energie .

L 'HTTP opera attraverso un meccanismo richiesta/risposta: il client invia un messaggio di richiesta ed il server restituisce la risposta. Nell'uso comune il client corrisponde al browser ed il server al sito web. Vi sono perciò due tipi di messaggi HTTP: messaggi richiesta e messaggi risposta.

Lo sniffer

Gli sniffer, meglio conosciuti come analizzatori di protocollo, possono essere utilizzati per una moltitudine di scopi.

Uno sniffer è un'applicazione che accede a basso livello ai dati che transitano su una scheda di rete prima che questi vengano manipolati dallo stack di protocolli; questa operazione viene detta cattura o sniffing .

Per qualunque proposito essi vengano utilizzati, due componenti che uno sniffer di rete deve possedere sono un "tap" e un filtro.

Il tap è un meccanismo che permette allo sniffer di ricevere tutto il traffico in transito su una scheda di rete ("Network Interface Card", NIC). Questo è possibile attraverso l'attivazione del cosiddetto "Promiscuous Mode" della NIC in questione. Il Promiscuous Mode è una modalità di funzionamento in cui la scheda di rete ignora il campo destinazione di un header Ethernet e accetta tutto il traffico in transito. Senza la sua attivazione, una NIC accetterà solo il traffico che è diretto verso di essa, cioè unità Ethernet che abbiano il suo indirizzo fisico nel campo destinazione.

Che si tratti di Sistema Operativo Windows o Unix, l'attivazione del Promiscuous Mode è possibile solo attraverso l'utilizzo di librerie per la cattura di pacchetti (PCAP).

PCAP, inizialmente sviluppato per sistemi operativi di tipo Unix (e.g. BSD) è oggi disponibile anche per i sistemi Windows e il suo nome è cambiato in WINPCAP.

Prima di analizzare ulteriormente il funzionamento di uno sniffer è necessario prendere in considerazione la posizione che il computer, su cui è in esecuzione il programma di sniffing, deve occupare affinché sia in grado di intercettare il traffico; esso infatti deve trovarsi collegato ad un HUB che si trovi su uno strato a metà tra i nodi di interesse e la rete esterna oppure si deve trovare presso un commutatore che effettui il la replicazione o "mirroring" di una porta attraverso cui transitano i dati tra un client ed un server. Questo principio è illustrato in figura 2.

Il grosso del lavoro svolto da un sistema come WinPcap è relativo all'interfacciamento con la scheda di rete tramite il driver che la governa, l'estrazione del traffico che circola sulla rete, la scrematura ( "filtering") dei dati ottenuti in base alle specifiche dell'utente, tutte operazioni che non sono permesse ad una normale applicazione. Questo è il motivo per cui è necessario appoggiarsi ad un driver di periferica, il quale rappresenta un'estensione dei servizi offerti dal nucleo del sistema operativo (kernel).

Inoltre, la cattura dei pacchetti e la loro consegna alle applicazioni è da effettuare con molta attenzione se si vogliono ottenere delle buone prestazioni .

La prima operazione eseguita dal NPF è il filtraggio; al fine di evitare copie superflue e risparmiare spazio sul buffer, questa operazione viene, normalmente, eseguita all'inizio della catena di manipolazioni del pacchetto. Il filtro è creato dall'utente tramite un compilatore fornito da WinPcap. Esso consiste in un predicato espresso secondo la logica proposizionale, ossia in un set di condizioni concatenate da opportuni operatori booleani.

Il NPF è realizzato utilizzando l'interfaccia "NDIS" ("Network Driver Interface Specif ication") che rappresenta lo standard per la comunicazione tra una scheda di rete e il driver che implementa il protocollo. La funzione principale di NDIS è quella di operare da "wrapper" per permettere ai driver di protocollo di inviare e ricevere pacchetti sul network senza preoccuparsi della natura dell 'hardware o della particolare versione di Win32.

Il NPF è quindi implementato come driver di protocollo e, sebbene questa scelta non sia orientata alla performance, essa garantisce una considerevole indipendenza dal sottolivello MAC e il completo accesso al traffico dei dati grezzi.

Facendo riferimento alla figura 1, il metodo secondo l'invenzione è in grado di analizzare i pacchetti catturati tramite le librerie WinPcap o altra Pcap (il primo livello dal basso in figura rappresenta i driver della scheda di rete presenti sul sistema operativo, il secondo livello è la parte relativa alla cattura dei pacchetti ed è qui che agisce WinPcap) .

I pacchetti vengono quindi analizzati (terzo livello della pila in figura) in base a regole predeterminate. L'analisi è in realtà un primo filtro del dato per estrarre i dati del dominio applicativo interesse .

Tali dati filtrati vengono inviati allo strato successivo (quarto strato in figura 1) che li cataloga per tipologia a seconda del protocollo richiesto dall'utente finale del sistema secondo l'invenzione. Si estraggono qui dai dati in ciascuna categoria i parametri e le informazioni necessarie per l'analisi della funzionalità di risposta di applicativi che girano al livello dei dispositivi 10 e comunicano dall'esterno verso l'interno e dall'interno verso l'interno. Ad esempio, se il sistema rileva il passaggio di una richiesta, aspetta poi il passaggio della relativa risposta, quindi analizza il contenuto di entrambi al fine di costruire un KPI ("Key Performance Indicator") attraverso il quale monitorare il funzionamento dell'applicazione che ha generato la risposta.

I dati catalogati vengono allora inviati al livello successivo (quinto strato in figura 1) per la scrittura di tali dati in un database.

L'ultimo strato in figura riguarda la visualizzazione dei dati.

Facendo ora riferimento alla figura 2, si illustra di seguito un esempio di architettura del sistema 100 secondo l'invenzione. Vari apparati 10 connessi alla rete 50 generano traffico di dati. Tra gli apparati 10 e la rete 50 viene interposto un classico router 40 e un commutatore 20 (se tale commutatore non ha la funzionalità di mirror port o spam port, allora si ricorre all'uso dei tap di cui sopra collegati tra commutatore e sniffer). A tale commutatore 20 viene collegato uno sniffer 30 per la cattura dei pacchetti di cui sopra.

I pacchetti vengono poi analizzati come sopra da un dispositivo 60 e visualizzati su un dispositivo 70.

Facendo riferimento ora alla figura 3, si descrive in maggiore dettaglio il processo di estrazione dati secondo l'invenzione.

Un pacchetto dati 80 estratto dallo sniffer 30 è diviso per indirizzo IP o Vlan, ed il sistema si trova di fronte ad una stringa come la sottostante:

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) | (esempio richiesta)

148542(MS); 192. 168.0.4 (IPSORG);192. 168.0.1 (IP_DEST) ; 9827399004 (SEQ); 256 7543325 (ACK); HTTP: 404(CODICE HTTP) | (esempio risposta)

Da questa stringa il software cattura una serie di informazioni come:

- IP Sorgente

- IP Destinazione

- Millisecondi

- Sequence Number

- Acknowledgement number

- URL

- Codice http

Si deve innanzitutto dividere il traffico in richieste e in risposte.

Le richieste partono dal client verso il server, quindi in questo caso l'IP sorgente sarà il client che effettua la richiesta e l'IP Destinazione quello del server su cui si trovano i dati richiesti, il tempo in millisecondi determina il ritardo con cui si registra la risposta del server dal momento in cui arriva la richiesta del client. Il "Sequence Number" è un numero sequenziale generato durante la transazione per ricostruire i dati alla fine della trasmissione, mentre 1' "acknowledgement" è un codice di conferma inviato dalla macchina di destinazione per dire che il pacchetto precedente è arrivato con successo.

Nelle risposte i dati sono gli stessi (invertendo la posizione di client e server) con in più l'informazione inerente il codice http che è stato risposto alla URL richiesta.

In tal modo, si hanno tutte le informazioni necessarie per l'analisi della funzionalità degli applicativi che girano sui dispositivi 10 e della funzionalità della loro connessione al server.

La soluzione secondo l'invenzione è in grado di garantire:

- un unico punto per l'acquisizione delle informazioni;

- un elevato tasso di acquisizione (>= 500 Mbit/s) con aggregazione di canale.

Il monitoraggio in tempo reale dei KPI applicativi:

- QoS ("Quality of Services"),

- "trouble Ticketing Time Through" (il sistema è grado di avvisare il personale preposto al controllo dei sistemi informatici in tempo quasi reale (un minuto di ritardo), in modo da diminuire il numero di chiamate da parte degli utenti finali che fruiscono dell'applicazione),

- la capacità di auto-riparazione;

- la completa e non-intrusiva integrazione con tutti i processi aziendali esistenti;

- il 100% di scalabilità e continuità commerciale.

Bilanciamento interno

Lo scopo del presente documento è quello di descrivere la soluzione tecnica denominata "bilanciamento interno" utilizzata nella componente software "Sniffer" del sistema integrato di diagnostica secondo l'invenzione.

La componente Sniffer ha lo scopo di raccogliere il traffico di rete filtrando i dati che non sono di interesse per l'analisi del traffico. Lo Sniffer, componente essenziale del sistema integrato secondo l'invenzione, necessita di alcune soluzioni (qui di seguito descritte) per sostenere le elevate quantità di traffico di rete da trattare.

Occorre ridurre la soglia di criticità della componente Sniffer senza incidere sul processo di analisi dei dati delle altre componenti del sistema integrato secondo l'invenzione, avvalendosi dell'architettura parallela dell'hardware su cui il sistema integrato viene installato.

Questo viene realizzato suddividendo l'output in più flussi logici ("bilanciamento"). A tale suddivisione corrisponderà, a parità di hardware, una soglia critica più alta, ossia la possibilità di analizzare e filtrare quantità di traffico di rete più elevate mantenendo la caratteristica di "near reai time".

Data la natura "near reai time", è indispensabile che ogni trattamento addizionale dei dati (bilanciamento e anonimizzazione) debba concludersi in tempi costanti e brevi, per evitare l'accumulo di ritardi nel processo di cattura del traffico di rete con conseguente perdita di pacchetti.

Il sistema integrato dell'invenzione è progettato per elaborare in "near reai time" elevate quantità di traffico, nell'ordine di migliaia di request/response al secondo, utilizzando, su dispositivi di elevata potenza di calcolo, una soluzione software di calcolo parallelo (detta anche "bilanciamento interno").

Per "near reai time" si intende che i dati relativi ad un minuto di traffico diventano consultabili entro il termine del minuto immediatamente successivo, pertanto l'elaborazione dei dati — che per x pacchetti richiede tempi dell'ordine di 0(x log x) — avviene entro i 60 secondi successivi alla disponibilità dei pacchetti estratti dal traffico di rete.

II bilanciamento interno avviene suddividendo il traffico dei pacchetti catturati sulla rete in due o più flussi che abbiano pressappoco lo stesso volume (caratteristica indispensabile per l'efficienza del bilanciamento) e che possano essere elaborati in parallelo, in modo trasparente rispetto al processo di analisi.

La suddivisione del traffico in flussi paralleli consente di allontanare la soglia critica di elaborazione in proporzione al numero stesso di flussi effettivamente elaborati in parallelo, sfruttando appieno le caratteristiche "multi-core" del dispositivo utilizzato .

La suddivisione in flussi può avvenire in due modi: in base alla "sessione" indicata nei pacchetti di traffico (ossia sul numero indicato come source port della richiesta effettuata dal Client), oppure sull'indirizzo IP del client stesso (il tipo di suddivisione va specificato, insieme al numero di flussi, nella configurazione della componente software Sniffer) .

Nel primo caso avviene direttamente sulla "sessione" dei pacchetti di traffico (ossia sulla source port della richiesta del client) poiché all'interno dei pacchetti è l'unico valore ad essere ragionevolmente assumibile come equidistribuito (pseudo-randomico ), mentre all'interno di una richiesta (per esempio "GET di una pagina" e relativa risposta) resta costante.

A causa dell 'equidistribuzione delle source port, la divisione in flussi può avvenire indipendentemente dalla quantità di traffico circolante e senza necessitare di particolari risorse di calcolo. Ad esempio, nel caso di due flussi, è possibile dividere il traffico in "sessioni pari" e "sessioni dispari"; oppure, nel caso di quattro flussi, si può suddividere il traffico secondo i due bit meno significativi della "sessione" (sui valori 00/01/10/11 degli ultimi due bit) . L'implementazione non può utilizzare altri campi che, benché considerabili come equidistribuit i, variano all'interno di uno stesso flusso di pacchetti (per esempio il Sequence e 1 'Acknowledgement number) .

Nella seconda tipologia di configurazione viene invece preso in considerazione uno degli ottetti dell'indirizzo IP al posto del numero di "sessione", in modo che i flussi di pacchetti vengano divisi per "client"; questa eventualità è però efficiente solo quando sia preventivamente stimabile una ragionevole equidistribuzione degli indirizzi IP e del traffico medio dei singoli Client, altrimenti il "bilanciamento" avverrà in maniera assai poco efficiente .

La scelta di queste due possibilità è stata fatta sulla base di esperimenti condotti dalla Richiedente, che hanno mostrato una equidistribuzione dei valori delle stringhe binarie utilizzate, mentre gli stessi esperimenti hanno mostrato una distribuzione non randomica di tutte le altre stringhe binarie associate ai protocolli TCP/IP in tipici flussi di dati.

I processi di analisi utilizzeranno dunque due o più sorgenti di input (file di input), producendo autonomamente risultati che verranno successivamente aggregati per essere registrati all'interno del database utilizzato per la consultazione delle statistiche .

In entrambi i casi, ogni flusso di dati è garantito contenere tutti i pacchetti di traffico di una stessa richiesta.

La riaggregazione dei dati elaborati avviene secondo la tecnica nota.

Esempio specifico di realizzazione

Facendo riferimento alla figura 7, consideriamo il seguente traffico rilevato il 31 gennaio 2011 dalle 10:33 alle 10:36. Il flusso contiene:

* 10:33 — 4228 richieste totali di tipo "GET" totali, 3991 risposte totali di tipo "HTTP"

* 10:34 — 30547 tipo "GET", 29576 risposte tipo "HTTP" * 10:35 — 33309 tipo "GET", 32240 tipo "HTTP"

* 10:36 — 33213 tipo "GET", 31857 tipo "HTTP"

L'analisi di questo breve campione traffico vedrebbe dunque un picco stimabile attorno alle 33000 richieste/risposte al minuto.

La suddivisione in due flussi elaborati in parallelo permette di abbattere il picco.

* 10:33 2221 2007 richieste tipo "GET", 2040 2051 risposte tipo "HTTP"

* 10:34 15901 14646 tipo GET", 15160 14416 tipo "HTTP"

* 10:35 — 17402 15907 tipo "GET", 16594 15646 tipo "HTTP"

* 10:36 -- 17383 15830 tipo "GET", 16364 15493 tipo "HTTP"

I singoli flussi sono relativi agli indirizzi IP dei terminali, per cui se per esempio consideriamo un pacchetto di traffico tra le 2221 "GET" censite nel primo flusso del minuto 10:33, abbiamo la certezza che tutto il traffico generato dallo stesso terminale (fino alla successiva "autenticazione" o timeout) continuerà ad appartenere al primo dei due flussi.

Con il metodo di suddivisione del traffico secondo l'invenzione si ha la possibilità di analizzare un flusso molto grande di dati con mezzi semplici in modo veloce ed affidabile.

In quel che precede sono state descritte le preferite forme di realizzazione e sono state suggerite delle varianti della presente invenzione, ma è da intendersi che gli esperti del ramo potranno apportare modificazioni e cambiamenti senza con ciò uscire dal relativo ambito di protezione, come definito dalle rivendicazioni allegate.

Claims (12)

1. RIVENDICAZIONI 1) Metodo per l'analisi "near reai time" di elevate quantità di traffico dati di rete su suite di protocolli TCP/IP, contenenti coppie di richieste e risposte tra un server ed un client, il traffico dati consistendo globalmente di un flusso di pacchetti di dati, caratterizzato dal fatto di eseguire le seguenti fasi: A. leggere i campi della suite di protocolli TCP/IP di detto flusso di pacchetti di dati; B. identificare, tra i campi della fase A, per ciascuna richiesta effettuata dal client, una stringa binaria costituita dal numero di source port oppure dall'indirizzo IP del client stesso; C. suddividere detto flusso di pacchetti di dati in un numero intero positivo pari Q di sotto-flussi di pacchetti di grandezza simile, raggruppando i pacchetti a cui è associato lo stesso valore di detta stringa binaria; D. analizzare i Q sotto-flussi su corrispondenti Q unità elettroniche di elaborazione.
2. 2) Metodo secondo la rivendicazione 1, caratterizzato dal fatto che dette Q unità elettroniche di elaborazione corrispondono a altrettanti core di una CPU multi-core.
3. 3) Metodo secondo la rivendicazione 1 o 2, caratterizzato dal fatto che nella fase E si suddivide il flusso di pacchetti di dati in due sotto-flussi a cui corrispondono rispettivamente valori pari e valori dispari di detta stringa binaria.
4. 4) Metodo secondo la rivendicazione 1 o 2, caratterizzato dal fatto che, nel caso di suddivisione del flusso di pacchetti di dati in Q=4 sotto-flussi, si suddivide il traffico sui valori 00/01/10/11 degli ultimi due bit di detta stringa binaria.
5. 5) Metodo secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che detto traffico di dati di rete è ottenuto tramite sniffing, e successivamente alla fase D si esegue la seguente ulteriore fase: E. ricostruire detto flusso di pacchetti di dati a partire dai Q sotto-flussi analizzati.
6. 6) Metodo secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che prima della fase C si effettua un filtro dei dati che seleziona solo le informazioni di interesse per l'analisi della fase D.
7. 7) Metodo secondo una qualsiasi delle rivendicazioni da 1 a 6, caratterizzato dal fatto che detta fase A utilizza uno sniffer (30) per la cattura di pacchetti di dati scambiati tra applicativi che girano su dispositivi (10) di detti client e server (50), tramite una libreria Pcap.
8. 8) Metodo secondo la una qualsiasi delle rivendicazioni da 1 a 7, caratterizzato dal fatto che la fase D comprende le seguenti sottofasi: D_1. analizzare i pacchetti di dati in base a regole predeterminate, tale analisi fungendo da primo filtro per estrarre i dati del dominio applicativo di interesse; D_2. catalogare i dati per tipologia a seconda del protocollo richiesto dall'utente; D_3. estrarre da detti pacchetti di dati in ciascuna categoria i parametri e le informazioni necessarie per l'analisi della funzionalità di risposta di applicativi che girano al livello dei dispositivi (10) e comunicano dall'esterno verso l'interno e dall'interno verso l'interno, tra cui: - indirizzo IP Sorgente; - indirizzo IP Destinazione; - ritardo di risposta in millisecondi; - Sequence Number; - Acknowledgement number; - URL; - codice http, nel caso di comunicazione verso l'esterno; D_4. scrivere i dati estratti in una apposita base di dati.
9. 9) Metodo secondo una qualsiasi delle rivendicazioni 7 o 8, caratterizzato dal fatto di eseguire una ulteriore successiva fase F di visualizzazione dei dati scritti nella base di dati.
10. 10) Metodo secondo una qualsiasi delle rivendicazioni da 7 a 9, caratterizzato dal fatto di calcolare, nella fase D_3, un "Key Performance Indicator" attraverso il quale monitorare il funzionamento dell'applicazione che ha generato la risposta, detto KPI essendo scritto ugualmente in detta base di dati.
11. 11) Sistema (100) per l'analisi del traffico di rete utilizzante il protocollo TCP/IP, caratterizzato dal fatto di comprendere: - uno o più dispositivi (10) connessi alla rete (50) e generanti traffico di dati; - un router (40) e un commutatore (20) interposti tra detto uno o più dispositivi (10) e la rete (50); - uno sniffer (30) per la cattura dei pacchetti di dati dal traffico dati, collegato a detto commutatore (20); - un dispositivo (60) di analisi dati, che analizza i pacchetti catturati, detto dispositivo di analisi dati comprendendo una pluralità di CPU core e mezzi a codice atti ad eseguire il metodo secondo una qualsiasi delle rivendicazioni da 1 a 10.
12. 12) Sistema secondo la rivendicazione 11, caratterizzato dal fatto che, se detto commutatore (20) non ha la funzionalità di mirror port o spam port, si ricorre all'uso dei "tap" collegati tra commutatore (20) e sniffer (30).