SPDY, Google vuole velocizzare il web eliminando HTTP

Mike Belshe e Roberto Peon di Google stanno lavorando al progetto SPDY (”speedy”) per migliorare le prestazione delle pagine web.

Per mostrare la pagina di un sito moderno è necessario trasferire parecchie risorse come css, js ed immagini. Quando è stato sviluppato HTTP non c’era questa necessità e quest’ultimo non la gestisce nel modo migliore possibile.

SPDY utilizza una connessione singola, criptata e compressa per tutte le richieste. Le richieste, le risposte ed i dati sono inviati all’interno di frame anziché essere gestite in maniera sequenziale e questo rende possibile ottenere i file piccoli in attesa che quello più grande finisca.

PUBBLICITÀ

Secondo Google questo protocollo è in grado di migliorare le prestazioni del web di circa il 50%. L’obbligatorietà di una connessione criptata però porterà più carico ai processori e potrebbe incrementare il numero, già troppo grande, di persone che non si preoccupano della correttezza dei certificati. Inoltre, le prestazioni sulle periferiche embedded sarebbero sicuramente rallentate.

Per ora non ci sono prese di posizione da parte di IETF sulla questione, ma sappiamo che l’organizzazione preferisce sempre creare una nuova versione di un protocollo compatibile con la precedente consentendo un aggiornamento senza problemi tra i due.

La proposta di Google, invece, spezzerebbe la rete in due parti: Quella che dispone del supporto e quella senza. Se, invece, SPDY fosse da intendere come un protocollo dove sperimentare nuove funzionalità per un ipotetico e compatibile all’indietro HTTP 2.0 non ci sarebbe nulla di male.

Speriamo che questa proposta provochi un dibattito serio su come far evolvere l’attuale HTTP e dia l’avvio ad un working group IETF.

Foto | atzu
Via | ArsTechnica

(1 Voti | Media: 5 su 5)

9 commenti

Articoli simili

Tsung, multi-protocol distributed load testing tool del 21 mar 2010

Kexi, l'alternativa open source a Microsoft Access del 20 mar 2010

Morevna Project, un anime libero del 20 mar 2010

Unknown Horizons del 20 mar 2010

OpenGameArt, un sito per immagini libere da usare nei giochi del 20 mar 2010

Argomenti Simili

android, android 2.0, android2, ietf

Gallerie Correlate

• 
  gOS 2.0

Commenti dei lettori

• 

  expo

  15 nov 2009 - 15:02 - #1

  0 punti

  

  Buoni i propositi di Google ma sono pienamente d’accordo con la retro compatibilità, sono dell’idea che se possibile bisogna sempre evitare cambiamenti drastici.
  Attualmente sono tanti i protocolli applicativi che andrebbero rivisti sulla base dell’attuale evoluzione di internet. A dirla tutta bisognerebbe rivedere tutto lo stack di protocolli TCP/IP ma meglio poco che niente.

• vopr

  15 nov 2009 - 15:13 - #2

  0 punti

  

  Perchè non sviluppare o migliorare un protocollo di livello 4? Così che tutti gli applicativi possano trarne beneficio e non solo quelli che utilizzano l’http. Visto che in futuro verrà adottato l’ipv6 se ne poteva approfittare per aggiornare anche i protocolli di trasporto sui nuovi dispositivi

• CRV§ADER//KY

  15 nov 2009 - 15:20 - #3

  0 punti

  

  Mi sembra una fesseria; avere una connessione sola porta grandi benefici in termini di performance ma è già fatto da SMTP e crittografia e compressione sono già implementati da HTTP/HTTPS base… perché non spingono invece su HTTP over SMTP?

• CRV§ADER//KY

  15 nov 2009 - 15:21 - #4

  0 punti

  

  *volevo dire SCTP

• franz1789

  15 nov 2009 - 16:07 - #5

  0 punti

  

  Sono d’accordo con Google. Forse un po’ drastico abbandonare http, sarebbe meglio integrare tutto in una nuova versione di http retrocompatibile, ma si rende davvero necessario al giorno d’oggi accelerare i tempi di internet. Tanto noi non ne sentiremo la differenza, con il governo che blocca i finanziamenti all’adsl… Così nel 2012 in corea del sud avranno 1Gbit/s e noi avremo paesi in cui ancora al massimo arriva la 56k…

• 

  giovanni-santostefano

  15 nov 2009 - 16:39 - #6

  0 punti

  

  Per me il protocollo HTTP andrebbe bene così com’è se fosse utilizzato per quello cui è stato progettato ovvero gestire la comunicazione con il server web per caricare pagine “di presentazione” HTML

  Il fatto che oggi il web sia utilizzato intensivamente per sviluppare applicazioni con forte interattività non mi ha mai convinto… in quanto IMHO e solo e fortemente IMHO sta abusando dei sistemi che sono stati progettati per tutt’altro.
  Mi riferisco al mio modo di vedere estremamente complesso lo sviluppo di una applicazione web rispetto allo stesso sistema client server sviluppato in un qualsiasi altro linguaggio (Per capirci… se ho intenzione di sviluppare un office orientato al cloud in java o C++ penso che riuscirei a progettare un software più pulito ed espandibile che se devo crearlo in php+ (HTML+javascript) ).

  Non andando oltre in questo discorso che meriterebbe sicuramente spiegazioni più accurate sul mio modo di vedere la cosa, ritengo comunque che debbano essere sviluppati totalmente nuovi protocolli per ospitare le nuove caratteristiche dell’interattività della rete internet piuttosto che reimpastare il web.

  Insomma ben venga una ottimizzazione del web ma nel mio modo utopico di vedere la rete (nonostante ritengo che il cloud computing sia il male) vorrei tanto un web alleggerito di tutti i *fronzoli ajax, flash e javascript ed una piattaforma progettata da zero per integrare tutte quelle funzionalità che posso permettere uno sviluppo ponderato di applicazioni cloud.

  Gio

  * Il sistema ajax in se è un’ottima cosa… ma non se ne deve abusare… come di javascript per finire in un web obeso!

• 

  groucho_nt

  15 nov 2009 - 18:29 - #7

  1 punto

  

  Al di la delle tecnologie utilizzate, è innegabile che il web fatto di pagine semi-statiche è un retaggio del passato, che non interessa più a nessuno. Utilizzare il browser come client di presentazione per applicazioni client-server è una esigenza sentita ogni giorno di più. Il vantaggio di questa soluzione è che non serve installare nulla sui client, basta una postazione connessa alla rete (pc o smartphone) con un browser di ultima generazione. Il protocollo HTTP nonostante AJAX e motori JavaScript sempre più performanti alla lunga va comunque stretto. Vorrei vedere nel concreto di che cosa si tratta la proposta di Google prima di pronunciarmi a favore o contro. La retrocompatibilità è un falso problema: si tratterà solo di avere browser in grado di “parlare” protocolli differenti (già ora succede tra, ad esempio tra http:// https:// e ftp://).

• IvanDM

  15 nov 2009 - 20:29 - #8

  2 punti

  

  Se vi foste presi la briga di leggere “the actual documentation” avreste trovato informazioni piu’ preciso: SPDY puo’ essere configurato ANCHE per funzionare HTTP over SPDY. Quindi e’ anche retrocompatibile, volendo.

• 

  aska

  16 nov 2009 - 10:02 - #9

  0 punti

  

  Ho letto la documentazione. Promette bene :)