Non dimenticare la latenza quando calcoli le prestazioni della rete

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email × 0 Flares ×

Nel mio lavoro, devo imparare molto su più argomenti di ESSO. Soprattutto nel mercato della virtualizzazione, molte persone sono solitamente ben preparate quando si tratta di infrastrutture, server e storage, ma ho scoperto che il punto più debole è molte volte il networking. Ci sono alcuni argomenti che sono oscuri per molti, come Layer2 vs Layer3, BGP, Spanning Tree, ma c’è un argomento che è davvero importante anche per i ragazzi dell’infrastruttura, eppure è quasi sconosciuto a loro: la latenza.

Che cos’è la latenza?

Veloce come può essere, anche la velocità della luce non è infinita. Ci vuole tempo per un fotone per andare dal punto A al punto B, e per esempio la luce generata dal Sole impiega 8 minuti per raggiungere la Terra. Le nostre reti di computer non sono nemmeno vicine a quella velocità, perché prima di tutto di solito le nostre connessioni non sono fatte con fibra ottica (che alla fine sarebbe veloce come la luce) ma con cavi elettrici e quindi le trasmissioni su questi supporti sono più lente, ma anche perché ci sono molti apparecchi tra sorgente e destinazione che hanno bisogno L’host di origine, gli switch, i router, i firewall, l’host di destinazione; ogni “hop” aggiunge tempo al tempo totale di cui un pacchetto ha bisogno per raggiungere la sua destinazione. Possiamo progettare questa situazione in questo modo:

(fonte: https://stackoverflow.com/questions/8682702/how-to-calculate-packet-time-from-latency-and-bandwidth )

Quindi, detto semplicemente, la latenza è il tempo necessario a un pacchetto per passare dalla sorgente alla destinazione.

In una rete locale è facile applicare una certa approssimazione e dichiarare che il ritardo di elaborazione è 0, e anche che gli switch multipli tra due host non aggiungono latenza aggiuntiva. Dopotutto, quando eseguiamo un comando ping per verificare se un host è connesso, la latenza è sempre “inferiore a 1 ms” :

Per questo motivo, non è raro calcolare la velocità massima di trasferimento semplicemente guardando la larghezza di banda disponibile:

-1 Gb di collegamento ethernet, diviso per 8, mi dà 125 MBps

-10 Gb di collegamento ethernet significa 1250 MBps

e così via. E se la mia larghezza di banda è 125MBps, significa che posso trasferire 125MB ogni secondo.

Perché la latenza è importante?

Perché ignorarlo, insieme ad altri parametri, porta a risultati falsi!

Guarda l’esempio precedente. Anche su una rete locale, dove la latenza è vicina allo zero, ci sono altri parametri che possono influire sulla velocità finale. Uno su tutti: dimensione della finestra TCP. Non ho intenzione di ripetere ciò che è stato già scritto in modo perfetto da altri, quindi se volete saperne di più, leggere questo post di Brad Hedlund. Qual è la fregatura? La velocità di collegamento di cui di solito parliamo è la velocità di collegamento del cavo puro. Ma su di esso, abbiamo bisogno di eseguire più protocolli, uno sopra l’altro, come TCP over IP. TCP divide i dati in pacchetti e la dimensione dei pacchetti è dettata dalla dimensione della finestra TCP: più grande questo valore, più dati possono essere trasferiti in una singola trasmissione. Quindi, un payload è imballato all’interno di un pacchetto, quindi ci sono byte aggiuntivi per ogni pacchetto che nave da trasmettere, anche se non contengono dati (c’è anche un sovraccarico per il frame ethernet sottostante, pensa a tutta la discussione riguardo ai frame Jumbo). Infine, la latenza TCP fa la sua parte, perché posso trasmettere il pacchetto successivo solo una volta che il precedente ha raggiunto la sua destinazione, perché il collegamento è altrimenti occupato a trasferire gli altri pacchetti.

La latenza e la dimensione della finestra diventano fondamentali quando passiamo dalle reti locali alle reti pubbliche. Qui, il valore <1ms scompare e abbiamo valori più alti da tenere in considerazione. Più alta è la latenza, più piccola è la larghezza di banda massima “reale” che vedrò. Facciamo un semplice esempio: un cliente ha 100 Mbps collegamento a Internet, e ha bisogno di trasferire un file da 1 TB al suo fornitore di servizi.

I soliti calcoli teorici sarebbero semplici:

100 Mbps = 12,5 MBps

1 TB = 1000 GB = 1000000 MB

1000000 MB / 12,5 MBps = 80000 secondi = 1333,33 minuti = 22,22 ore o (d:h:m:s): 22 h:13 m:20s

Ma se provi a inviare questo file al tuo provider, NON ci vorrà MAI questo tempo per completarlo, a meno che tu e il tuo fornitore di servizi non siate connessi allo stesso collegamento ethernet; il che significa che non stai usando Internet affatto!

Come calcolare correttamente la velocità di trasferimento

Ho calcolato il valore precedente fino ai secondi esatti usando questo simpatico strumento:

http://wintelguy.com/transfertimecalc.pl

Se lo guardi, tuttavia, vedrai lo stesso” errore di approssimazione ” di cui ho parlato in precedenza: vengono prese in considerazione solo le dimensioni e la larghezza di banda. Nessuna dimensione della finestra e nessuna latenza. Ma il sito web WintelGuy ha strumenti più sorprendenti, e uno è esattamente ciò di cui abbiamo bisogno:

http://wintelguy.com/wanperf.pl

In questo, puoi vedere che ogni parametro importante è elencato e utilizzato per i calcoli. Ripetiamo lo stesso calcolo che abbiamo fatto prima, ma ora con alcune nuove informazioni:

Abbiamo aggiunto una latenza di 40 ms e accettato gli altri due valori predefiniti (perdita di pacchetti e MTU). Non abbiamo alcuna possibilità di cambiare MTU tramite un collegamento Internet, poiché ci sono molti apparecchi tra noi e i nostri fornitori di servizi che non sono sotto il nostro controllo. Questo è uno dei motivi per cui molte Telco offrono ai loro clienti collegamenti privati MPLS invece di collegamenti VPN su Internet pubblico, perché le impostazioni di connessione possono essere controllate e sintonizzate dal provider (beh, c’è anche un po ‘ di lock-in, ma questa è un’altra storia…). Qui, si vede che l’overhead TCP e la latenza stanno già influenzando il throughput massimo reale, che scende a 94.9 MBps. Direi comunque che questa è una situazione davvero buona, e potrebbe essere peggiore: manteniamo ogni altro parametro come prima e aumentiamo la latenza a 150ms:

Il throughput è diminuito a 77,8 Mbps, una perdita del 22% della velocità teorica. E può essere anche peggio: una connessione ADSL, per esempio, ha più di perdita di pacchetti, quindi se continuiamo a 150 ms di latenza, ma si aumenta la perdita di pacchetti di 10 volte, otteniamo questo (ignorare il fatto che nessuna ADSL può andare a 100 Mbps, è fatto per mantenere la stessa velocità in tutti gli esempi):

la perdita di Pacchetti è stato aumentato da 0.0001 (1 perdita di pacchetti per ogni 10000 trasmessa) a 0.001 (1 pacchetto perso per ogni 1000 trasmesso), e questo valore da solo ha ridotto la nostra velocità massima del 75%!!!

Quindi, la prossima volta che vedi la tua nuova linea Internet lucida che non funziona come previsto, prima di incolpare il tuo fornitore di servizi o il software che stai utilizzando per trasferire quei dati, guarda meglio la tua rete. Potresti scoprire che quei 25Mbps sono la velocità più veloce che puoi ottenere.

Write a Comment

Il tuo indirizzo email non sarà pubblicato.