Fino ad oggi la Real User Experience era in grado di visualizzare indicatori di performance legati ai soli applicativi che fanno uso del protocollo http/https.
Il nuovo plugin tcp permette di visualizzare KPI anche per tutti gli applicativi che fanno uso del protocollo tcp con un modello client request/server response:
Il plugin riesce quindi ad estrarre informazioni a prescindere dal protocollo applicativo implementato a livello 7 a patto che il modello di comunicazione sia quello atteso, che in effetti è quello utilizzato dalla maggior parte degli applicativi.
Le informazioni qualitative che il plugin è in grado di esportare sono:
KPI | Description |
Client/Server network latency | latenza di rete lato client e lato server |
Application server latency | tempo di elaborazione della richiesta, senza tempi di rete |
Load Time | tempo che intercorre tra l’invio della richiesta alla ricezione completa della risposta |
Application Throughput | velocità di risposta applicativa |
Network Throughput | velocità di trasmissione dati |
Retransmitted – OOO – Fragmented Packets | pacchetti fuori sequenza, ritrasmessi o frammentati |
Receive window close | quante volte il client od il server ha segnalato una situazione di buffer di ricezione pieno e quindi di non essere in grado di elaborare abbastanza velocemente |
Reset | situazioni di reset della connessione a fronte di errore nella comunicazione |
Oltre a questi valori qualitativi della connessione abbiamo anche i dati quantitativi:
KPI | Description |
Bytes | numero di bytes trasmessi da client o server comprensivi degli header dello stack tcp |
Payload bytes | bytes del solo contenuto applicativo della richiesta o risposta |
Packets | numero dei pacchetti inviati da client o server |
Transfer time | tempo di trasmissione dei dati (upload/download time) |
SSL – TLS
Il plugin tcp è in grado di fornire i valori dei kpi di cui sopra anche per le comunicazioni tcp che fanno uso di ssl/tls senza aver per questo bisogno di installare la chiave privata in uso. Questo permette di tracciare le performance di comunicazioni crittate da terze parti, per esempio in cloud.
Per poter raggruppare in un applicativo i flow ssl/tls è necessario conoscere le coppie ip/port del servizio erogato o in alternativa la coppia hostname/port e che il client utilizzi l’estensione tls SNI (service name indicator).
L’estensione SNI è utile nei casi in cui si controlli un servizio cui sono associati molti ip e dove questi ip cambino nel tempo (vedi cloud). Con SNI possiamo riconoscere il servizio di destinazione dall’hostname/alias che il client usa per connettersi e quindi siamo indipendenti dalle variazioni degli ip associati al servizio.
Questo è un esempio della visualizzazione dei dati tcp raggruppati per netgroups: