lunedì 28 giugno 2010

Google propone una modifica al protocollo TCP per aumentare la velocità della rete!

..in principio fu Arpanet. La prima “rete” , nata in America nel lontano 1969, che collegò circa 70 macchine tra di loro. Successivamente, nel 1982, fu Internet. E TCP/IP. Poi, nel 1991, fu il World Wide Web direttamente dal CERN di Ginevra. Da allora ad oggi Internet è praticamente in tutte le nostre case e su tutti i posti di lavoro, e da poche centinaia di utenti siamo diventati poco meno di un miliardo, su Internet è possibile trovare davvero di tutto… le cose sono cambiate, è vero, ma tutta l’architettura sottostante è rimasta pressochè invariata: dal 1982 lo standard TCP/IP, su cui si appoggia praticamente tutta Internet, è rimasto invariato. Almeno fino ad ora.
Nel 1998 nasce Google da due pazzi statunitensi fusi per la matematica, cresce nel corso degli anni, e dire che è diventato un organo di tutto rispetto è assolutamente riduttivo… nel Giugno del 2010 Google propone una modifica al protocollo TCP/IP. No, non sto scherzando, tramite alcuni calcoli ed argutissime osservazioni, lo staff di Google ha dimostrato che con una modifica nello strato di trasporto dell’architettura ISO/OSI la velocità di collegamento delle attuali connessioni potrebbe aumentare fino a toccare vette del 20%. Sembra fantascienza, eppure è così. Proporre di rivoluzionare qualcosa di così longevo fa quasi accapponare la pelle.

Tenterò di essere chiara nella mia spiegazione ma, visto l’argomento trattato, vi avviso che è impresa davvero ardua: ce la metterò tutta.

Sappiate, per inciso, che i messaggi in rete attraversano 7 strati (o 4, dipende dall’astrazione che vorrete usare) e che, una volta partiti dal mittente, scendono dallo strato più alto a quello più basso, per poi “attraversare la rete fisica” e risalire seguendo esattamente il percorso inverso alla volta del destinatario.

Il protocollo TCP, presente nello strato di trasporto dell’architettura di Internet, è il meccanismo che domina la stragrande maggioranza delle comunicazioni in rete. TCP è un protocollo best-effort, termine che lascia intendere una cosa del tipo “faccio come meglio posso per permetterti di fare ciò che devi fare, ma non ti assicuro la riuscita della cosa” . Per questa ragione, il protocollo TCP è strapieno di meccanismi di controllo e di parametri che li dominano: essendo best-effort, e non essendovi una procedura fissa per le varie comunicazioni, c’è bisogno in qualche modo di evitare la potenziale perdita di dati.

Voglio però presentarvi quattro parametri in particolare:

1. la finestra di congestione (CWnd), gestita dal destinatario del messaggio che viaggia in rete, che definisce esattamente quanti bit di dati il nostro destinatario può ricevere prima di comunicare al mittente “ok, ho ricevuto i dati, puoi continuare a spedire (chiameremo questo tipo di messaggio ACK)“
2. la finestra di ricezione (RWnd), gestita questa volta dal mittente del messaggio, che definisce esattamente la quantità di bit che il destinatario può ancora ricevere prima di consegnare il tutto allo strato superiore e spedire un ACK
3. la latenza, che definisce esattamente la quantità di tempo per cui il messaggio, una volta partito dal mittente, resta in rete prima di raggiungere il destinatario
4. il Round Trip Time (RTT), che invece definisce quanto tempo un pacchetto di dati impiega per viaggiare dal mittente al destinatario e tornare indietro (in pratica, indica il tempo che va dalla spedizione da parte del mittente del pacchetto di richiesta e la ricezione del pacchetto di risposta che dovrà arrivare dal destinatario)

Ora, saputo per sommi capi cosa significano le quattro paroline magiche, addentriamoci in ciò che Google vorrebbe combinare (che tratterò per sommi capi, vi lascio il link al pdf originale per un ulteriore riferimento).

La dimensione della finestra di congestione iniziale all’instaurarsi di una connessione è la stessa dal 2002, e siccome la banda delle nostre connessioni attuali è di gran lunga più veloce di ciò che, all’epoca, passava in convento, Google ha pensato bene di quadruplicarla. La motivazione è la seguente: una delle modalità di instaurazione di una connessione client/server è quella di cosiddetto avvio lento (o slow start), meccanismo che aumenta pian pianino le dimensioni della finestra di congestione finchè non si assiste ad un’effettiva perdita di dati. Ora, siccome il rate dei nostri collegamenti ad internet è altissimo (io, ad esempio, ho Fastweb su fibra) e i dati dovrebbero viaggiare come un fulmine, i 4KB iniziali (la dimensione fissa della finestra di congestione) non bastano più, e i browser attuali, per ottenere la velocità desiderata, sono costretti ad instaurare più connessioni al server (circa sei) contemporaneamente, con conseguente spreco di banda (nonchè aumento della probabilità di perdita di dati), per la procedura di avvio lento. Da Google, con una serie di calcoli, hanno dedotto che aumentando a 16KB la dimensione della finestra di congestione iniziale si potrebbe avere un aumento della velocità dei nostri collegamenti che sfiora il 10%. Infatti, con una finestra di congestione più grande, automaticamente diminuirebbe l‘RTT dei pacchetti che viaggiano in rete, e di conseguenza anche la loro latenza: la formula (che non sto qui a spiegarvi completamente) che domina il valore della latenza ha un termine FinestraDiCongestioneIniziale come divisore e un termine RTT come fattore: aumentando il primo e diminuendo il secondo, chiaramente diminuirà anche il valore della latenza.

http://img571.imageshack.us/img571/3167/f093978ef393497ba394d66.png

Tutto ciò, ci dicono da Google, per perseguire quattro obiettivi fondamentali:

1. Diminuire la latenza dei pacchetti (e vi ho già spiegato perchè questo succede)
2.
Essere al passo con i tempi, riuscendo perfettamente a gestire la crescita delle dimensioni delle pagine web (perchè, si sa, pesano sempre di più al giorno d’oggi…)
3. Completare con successo lo scambio dati, senza perdite eccessive e sprechi di banda
4. Gestire al meglio la congestione di rete, rendendo più rapido il recupero dei pacchetti persi (credetemi sulla parola, non è il caso di spiegare il perchè, ma una finestra di congestione più grande permette di recuperare più dati persi durante un solo RTT)

http://img121.imageshack.us/img121/1170/f45ce6433e10495b80eb87f.png

http://img29.imageshack.us/img29/6374/c9f146187c60452e93bb04a.png

Geniale, non ci sono altre parole per descrivere tutto ciò. Il fatto è che la sola modifica delle dimensioni standard della finestra di congestione di TCP potrebbe portare a una serie di problemi… dovrebbero essere riscritti diversi algoritmi per diversi meccanismi che dominano la comunicazione in rete, e ciò sarebbe davvero un totale macello, vista la quantità di utenti che – ad oggi – utilizza Internet… per cui la mia domanda è: riusciranno anche a trovare un modo, qualora la proposta dovesse essere accettata, di ridurre al minimo i disagi iniziali che questa potrebbe portare?

Aspettando che arrivi questa risposta, e se la curiosità dovesse impadronirsi di voi, potrete ammazzare il tempo leggendo il PDF originale che contiene tutte le informazioni sul caso, di cui vi lascio il link in basso.
http://code.google.com/intl/it-IT/speed/articles/tcp_initcwnd_paper.pdf


FONTE http://www.chimerarevo.com

Nessun commento:

Posta un commento