QUIC: il nuovo protocollo di Google per velocizzare internet

QUIC: il nuovo protocollo di Google per velocizzare internet

Fra i tanti progetti di Google troviamo QUIC, un nuovo protocollo di trasferimento dati attraverso UDP, che consente latenze minime con i server che abbiamo già visitato

di pubblicata il , alle 14:31 nel canale Web
Google
 

Chi usa Chrome ha già avuto modo di sperimentare QUIC, anche se probabilmente non se n'è mai accorto. Google ha riportato in settimana che già circa la metà delle richieste ai servizi proprietari che provengono da Chrome sono adesso servite attraverso il nuovo protocollo. QUIC sta per Quick UDP Internet Connection, e il suo obiettivo è quello di prendere il meglio del protocollo TCP e unirlo al più rapido ed efficace UDP.

UDP è il protocollo spesso preferito dai videogiochi per le sue basse latenze, tuttavia per via della probabile perdita di pacchetti non è utilizzato altrettanto spesso per il caricamento delle pagine web. È decisamente più leggero di TCP, soprattutto perché utilizza meno servizi per la correzione degli errori. Questo significa che client e server non monitorano costantemente la presenza di eventuali pacchetti persi.

Ed è proprio per questo che UDP è preferito soprattutto sui giochi, dove si ha bisogno soprattutto di una comunicazione a bassa latenza e meno complessa possibile. Durante un'adrenalinica sessione di un videogioco, se si è compiuto un determinato movimento non ricevuto da un server, è inutile perdere decimi di secondo o addirittura secondi per cercare di inviarlo nuovamente; è invece più conveniente inviare un nuovo dato relativo al movimento successivo.

È chiaro che ad oggi il protocollo UDP non è consigliabile per il caricamento delle pagine web, in quanto la potenziale perdita dei pacchetti potrebbe non garantire il download di tutti i dati presenti. Con QUIC, tuttavia, Google vuole correggere tale problematica ed offrire le feature migliori di UDP e TCP in un unico protocollo, e con i più avanzati strumenti per la sicurezza. L'immagine che riportiamo di seguito spiega al meglio gli obiettivi di QUIC.

Google QUIC
Fonte: Google

Su una connessione TCP sicura (con TLS), il browser deve eseguire più passaggi affinché possa garantire al server il diritto per l'invio dei pacchetti di dati. Con QUIC, almeno secondo quanto riportato da Google, il browser può iniziare a "dialogare" con il server senza alcuna latenza, a patto che i due sistemi abbiano comunicato precedentemente. QUIC non è l'unico progetto che Google ha in ballo per l'ottimizzazione della velocità di caricamento delle pagine.

Il suo SPDY è già alla base del nuovo standard HTTP/2, ma a differenza di QUIC si basa ancora sul più lento protocollo TCP. Quest'ultimo, tuttavia, è solitamente gestito dal sistema operativo in uso, e Google non ha la possibilità di effettuare modifiche consistenti: "QUIC ci permette di testare e sperimentare nuove idee, e di ottenere i risultati sin da subito", spiega il team alla base del protocollo, che spera nell'integrazione delle sue caratteristiche sui protocolli TCP e TLS integrati nei sistemi operativi.

Google sostiene che QUIC riesca a velocizzare il processo di caricamento della pagina di Google Ricerche del 3%, ma è probabile che su altri siti più pesanti e meno ottimizzati i vantaggi siano più consistenti. Grazie ad alcune delle nuove feature di QUIC, come "congestion control" e "loss recover over UDP", gli utenti di YouTube potrebbero verificare il 30% di rebuffer in meno, mentre ulteriori vantaggi potrebbero essere riscontrati da chi si collega con connessioni lente.

QUIC ad oggi è solo un esperimento integrato su Chrome, ma potrebbe ben presto divenire uno standard de facto. Del resto anche SPDY era stato integrato in un primo momento in forma prototipale su Chrome ed utilizzato sui servizi web del colosso, per poi venire proposto come base di HTTP/2. I piani di Google sono quelli di proporre HTTP2-over-QUIC alla IETF nel prossimo futuro, in modo che diventi un nuovo Internet standard per rendere la rete molto più efficiente rispetto ad oggi.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

13 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
cignox120 Aprile 2015, 14:58 #1
3% sulla pagina delle ricerche. WOW!

Sarebbe interessante avere una stima sul miglioramento ottenibile per pagine molto complesse come quelle che ci sono oggigiorno...

D'altronde, per quanto funzionale si sia dimostrato tcp (e ip etc), sono comunque tecnologie che hanno ere geologiche alle spalle, tecnologicamente parlando...
zappy20 Aprile 2015, 15:16 #2
e ora google si mette pure a modificare i protocolli di rete per guadagnare un misero 3%?!? o forse per rendere internet googlenet?
wal7er20 Aprile 2015, 15:35 #3
Goolge si può permettere anche di modificare i protocolli, in ogni caso li deve proporre come standard allo IETF che li può bocciare se non vanno bene come standard appunto.
LMCH20 Aprile 2015, 15:58 #4
Originariamente inviato da: zappy
e ora google si mette pure a modificare i protocolli di rete per guadagnare un misero 3%?!? o forse per rendere internet googlenet?


QUIC al momento è già implementato a livello di applicazione senza bisogno di mettere mano ai S.O.
Non altera i protocolli di rete esistenti, viene proposto come nuovo standard coesistente con essi (come coesistono tutti i vari standard basati su TCP ed UDP).

Per quanto riguarda la velocità quel 3% di velocità in più è riferito alla pagina principale
del motore di ricerca Google (molto "leggera" rispetto alle pagine obese di certi siti ed ottimizzata per caricarsi rapidamente con i "vecchi protocolli".
La cosa da notare semmai è quel 30% di riduzione dei rebuffer quando si usa YouTube.

Inoltre i vantaggi principali di QUIC si notano quando si ha una connessione a bassa velocità o satura di traffico (e considerato come siamo messi qui in Italia, mi sa che da noi la differenza si noterà molto di più rispetto ad altri paesi).
floc20 Aprile 2015, 17:50 #5
ci mancavano solo i talebani contro google adesso... Vien da pensare che non si leggano gli articoli
AlPaBo20 Aprile 2015, 17:58 #6
Originariamente inviato da: LMCH
QUIC al momento è già implementato a livello di applicazione senza bisogno di mettere mano ai S.O.
Non altera i protocolli di rete esistenti, viene proposto come nuovo standard coesistente con essi (come coesistono tutti i vari standard basati su TCP ed UDP).

Per quanto riguarda la velocità quel 3% di velocità in più è riferito alla pagina principale
del motore di ricerca Google (molto "leggera" rispetto alle pagine obese di certi siti ed ottimizzata per caricarsi rapidamente con i "vecchi protocolli".
La cosa da notare semmai è quel 30% di riduzione dei rebuffer quando si usa YouTube.

Inoltre i vantaggi principali di QUIC si notano quando si ha una connessione a bassa velocità o satura di traffico (e considerato come siamo messi qui in Italia, mi sa che da noi la differenza si noterà molto di più rispetto ad altri paesi).

Se sostituisce TCP e UDP non è a livello applicativo, ma a livello di trasporto. Una implementazione corretta dovrebbe, a mio parere, essere fatta attraverso il sistema di gestione dello stack dei protocolli, normalmente fatto dal sistema operativo. Qui sembra che Chrome si sostituisca ad alcune funzioni del SO: lecito ma criticabile.

E' del tutto corretta l'affermazione di wal7er: "Goolge si può permettere anche di modificare i protocolli, in ogni caso li deve proporre come standard allo IETF che li può bocciare se non vanno bene come standard appunto."

Quello che sembra incredibile è l'affermazione fatta nell'articolo, secondo il quale "potrebbe ben presto divenire uno standard de facto": parlare di standard de facto per un protocollo è insensato ed è assolutamente contrario allo spirito di Internet e ai meccanismi che ne hanno permesso la diffusione.
danylo20 Aprile 2015, 18:51 #7
Per velocizzare internet basterebbe togliere la pubblicita' (incluso le javascript di Google AdSense).

GTKM20 Aprile 2015, 19:36 #8
Originariamente inviato da: floc
ci mancavano solo i talebani contro google adesso... Vien da pensare che non si leggano gli articoli


In realtà, è proprio leggendo gli articoli che sale la preoccupazione:
"QUIC ad oggi è solo un esperimento integrato su Chrome, ma potrebbe ben presto divenire uno standard de facto."

Standard de facto? Stiamo parlando di un protocollo di comunicazione, non di un word processor; viene il dubbio che qualcuno non conosca i meccanismi che stanno dietro la Rete.

Google, come gli altri, può proporre nuovi protocolli, ma affinché diventino standard (QUIC si colloca nello strato di trasporto, e le sue funzionalità devono essere implementate nello stack di rete del O.S., non certo in un browser, chiariamo anche questo) c'è un percorso preciso.
ilmazz20 Aprile 2015, 23:30 #9
Originariamente inviato da: wal7er
Goolge si può permettere anche di modificare i protocolli, in ogni caso li deve proporre come standard allo IETF che li può bocciare se non vanno bene come standard appunto.


stesso pensiero
LMCH21 Aprile 2015, 02:06 #10
Originariamente inviato da: AlPaBo
Se sostituisce TCP e UDP non è a livello applicativo, ma a livello di trasporto.


QUIC non sostituisce ne TCP e neppure UDP.
Anzi, è "costruito sopra" UDP (come del resto ad esempio HTTP è "costruito sopra TCP".
Per questo lo hanno implementato a livello applicativo su Chrome.

In pratica QUIC sta ad HTTP come TFTP sta ad FTP.

FTP è "costruito sopra" TCP
mentre il più leggero (a livello di traffico) TFTP è "costruito sopra" UDP.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^