Google presenta alcune modifiche per il protocollo TCP

Google ha presentato nelle scorse ore alcuni aspetti di carattere generale che riguardano una ricerca attualmente in fase di elaborazione presso i laboratori del colosso di Mountain View. L’obiettivo, come spiega Yuchung Cheng – uno degli ingegneri di Google -, è sempre quello di individuare nuovi strumenti che permettano di veicolare più velocemente le pagine web. Il protocollo che si occupa del “trasporto” dei dati, comprese, quindi, tutte le informazioni di più alto livello che vengono trasmesse utilizzando i protocolli HTTP e HTTPS (“livello applicazioni”), è il TCP (“Transmission Control Protocol“).

Gli sforzi dei tecnici di Google si stanno concentrando, come ha spiegato Cheng, su quei meccanismi che possono aiutare nel ridurre la latenza tra client e server ed, in particolare, nel limitare il numero dei round trip ossia degli scambi di pacchetti tra mittente e destinatario che avvengono durante una qualunque comunicazione. Quando vengono trasmessi dei dati usando una connessione TCP, infatti, chi riceve un pacchetto deve informare il mittente sulla sua avvenuta ricezione inviando un riscontro (ACK, ossia acknowledgement). Se trascorre troppo tempo senza che il mittente riceva alcun messaggio ACK, il pacchetto dati viene ritrasmesso. Si rivela quindi di importanza essenziale il RTT (round trip time) ossia il tempo impiegato da un pacchetto per viaggiare da un sistema ad un altro e tornare indietro. Usando connessioni a banda larga, ad alta latenza, i client e i server potrebbero finire con lo spendere più tempo ad aspettare i riscontri che ad indiviare pacchetti dati.

Non appena viene stabilita una connessione, un sistema può inviare inizialmente tre pacchetti prima che si renda necessario attendere l’ACK. Google, secondo quanto dichiarato da Cheng, vuol portare tale valore a dieci pacchetti. Con dieci pacchetti un browser web può tipicamente inviare un’intera richiesta HTTP ad un server prima di doversi fermare per attendere un riscontro.
Google, inoltre, propone di modificare il comportamento del protocollo TCP facendo in modo che alcuni dati possano essere inviati già nel corso della procedura di “negoziazione” iniziale instaurata tra client e server.

Un RTT di 3 secondi, poi, sempre secondo i tecnici di Google, poteva essere appropriato per un paio di decenni fa ma la rete Internet dei giorni nostri richiederebbe un valore ridotto ad un solo secondo. In questo modo, se qualche pacchetto dati andasse perduto, i due attori della comunicazione – client e server – non dovranno più attendere un tempo così lungo prima di procedere ad un nuovo invio.

Da ultimo, Google vorrebbe che fosse impiegato un nuovo algoritmo per regolare il comportamento del protocollo TCP a fronte di eventuali perdite di pacchetti. Il fenomeno del “packet loss“, infatti, potrebbe essere la spia di una rete congestionata: TCP, quindi, reagisce modulando nel tempo la quantità di dati in trasmissione in funzione dello stato di congestione. Per Google, l’approccio sin qui utilizzato per “trattare” il problema della perdita di pacchetti si tramuterebbe in una grossa penalizzazione che renderebbe le connessioni troppo lente per periodi eccessivamente lunghi. L’algoritmo presentato dal colosso di Mountain View, secondo quanto affermato, aiuterebbe molto.

L’analisi di Cheng va ben oltre, però, affrontando una serie di modifiche che, a detta dell’ingegnere, potrebbero garantire un miglior comportamento del TCP sulle reti mobili (ved. questo post sul blog di Google).

E’ sicuramente ancora troppo presto per prevedere una possibile modifica del funzionamento del protocollo TCP: si tratta di una tematica estremamente delicata che, se non affrontata con le dovute cautele, potrebbe avere controindicazioni su vasta scala.

I nuovi studi di Google si affiancano agli sforzi compiuti per mettere a punto il protocollo SPDY, proposto come alternativa per HTTP. Inizialmente integrato solo in Google Chrome, SPDY mira a velocizzare il caricamento delle pagine web riducendo latenza ed aumentando la sicurezza. Il browser Amazon Silk già offre il supporto per SPDY e ben presto anche Firefox 11 potrebbe abbracciarlo.