Websocket è una specifica che fa parte di HTML5 ed ha lo scopo di definire un’interfaccia standard per la comunicazione bidirezionale tra un client web e un server.
Benvenuti nel primo di una serie di articoli che hanno lo scopo di introdurre tale tecnologia, raccontare la storia che ha portato alla sua definizione e proporre degli esempi pratici sul suo utilizzo illustrando alcuni framework e server che la supportano.
Secondo la specifica W3C, ancora peraltro in versione draft, il websocket è una interfaccia Javascript che definisce una connessione via socket full-duplex attraverso la quale possono essere inviati messaggi dal client web al server e viceversa. In pratica questo standard tenta di sintetizzare e semplificare le tecnologie fin qui usate per ottenere in qualche modo una messaggistica bidirezionale tra pagina web e server, ottenuta finora sfruttando tecnologie come Ajax e Comet.
Un po’ di storia…
Websocket entra a far parte di HTML5 nel 2007 (noto allora come TCP connection) per opera di Ian Hickson, attualmente in Google e membro del Web Hypertext Application Technology Working Group (WHATWG). Per approfondire il suo profilo e la sua biografia puoi leggere l’articolo su wikipedia. Nel 2008 prende il nome attuale e le API sono tuttora gestite da Ian come draft W3C (The websocket API), mentre il protocollo è l’RFC 6455 mantenuto da Ian Fette, sempre in Google.
Websocket in due parole
L’API Websocket permette di aprire una connessione verso un server tramite il protocollo websocket (ws o wss nel caso di comunicazione protetta). La connessione rimane attiva per tutta la durata della sessione. E’ inoltre una comunicazione full-duplex, cioè permette il passaggio di messaggi sia dal client al server che viceversa, dal server al client.
Rispetto alle alternative precedenti (come Comet, che vedremo velocemente dopo, o il plugin Flash) è un meccanismo molto più efficiente in quanto non ha l’overhead di dover interrogare ogni tanto il server per avere aggiornamenti sui dati o la latenza e la pesantezza del protocollo http.
Da un interessante articolo di Peter Lubbers & Frank Greco della Kaasing Corporation in cui vengono illustrati i risultati di performance in un confronto tra una soluzione “tradizionale” Comet e di una con websocket su un’applicazione web realtime, si evince che con websocket si ottiene rispetto al traffico http un risparmio da 500:1 a addirittura 1000:1 (a seconda degli header http coinvolti) e una riduzione di un fattore 3:1 nella latenza. Ovviamente questi risultati dimostrano come la tecnologia websocket comporta un’evoluzione significativa, quasi una rivoluzione, nella scalabilità delle applicazioni web real-time.
HTML5 websocket determina un drammatico miglioramento rispetto alle “vecchie tecniche” per simulare una connessione full-duplex in una pagina web a tal punto che Ian Hickson avrebbe pronunciato le seguenti parole (traduzione libera): “La riduzione di kilobyte di dati a 2 byte e la latenza da 150ms a 50ms è molto più che un fatto marginale. Infatti questi due elementi da soli sono sufficienti per considerare i Websocket molto interessanti per Google stessa”.
Prima c’era Comet
Come spesso accade nel mondo informatico, il termine Comet non rappresenta una tecnologia specifica, ma racchiude una serie di tecnologie già note, utilizzate per ottenere un nuovo modello di applicazione web: secondo questo nuovo modello l’applicazione web ottiene con il server una connessione di lunga durata attraverso la quale non solo l’applicativo manda informazioni al server, ma il server manda informazioni aggiornate all’applicativo, senza che quest’ultimo li richiami esplicitamente, cioè senza un’esplicita richiesta in seguito a qualche input dell’utente.
Il termine Comet è stato coniato da Alex Russell nel post del suo blog del 3 marzo 2006: Comet: Low Latency Data for the Browser; con tale termine Alex voleva indicare una nuova generazione di applicazioni e servizi caratterizzati da una trasmissione dati innovativa che non aveva a che vedere né con quella classica di richiesta di una pagina del browser ad un server, né con Ajax; trasmissione dati in particolare dal server al client web caratterizzata da una bassissima latenza. Esempio di tali servizi erano (e sono tuttora) Jot Live, Meebo e l’integrazione di Google Talk in GMail.
Altri nomi con cui è chiamato Comet sono: Ajax Push, Reverse Ajax, Tow-way-web, HTTP Streaming e HTTP Server push.
Poiché i browser e i protocolli HTTP non sono nati con l’idea di implementare tecniche Comet, sono state appunto utilizzate diverse tecniche per ottenere questo risultato. Queste tecniche possono essere raggruppate in due grandi categorie: Streaming e Long Polling.
Nel primo caso, Streaming, l’applicazione web apre una connessione persistente col server Comet, che invia, quando li ha, nuovi dati sotto varie forme, ad esempio javascript, che vengono ogni volta eseguite dal browser. L’implementazione di questa tecnica può avvenire o con l’uso di IFrame la cui sorgente risponde aggiungendo via via nuovi eventi Comet, o con l’oggetto XmlHttpRequest.
Il caso del Long Polling invece fa uso esclusivamente dell’oggetto XmlHttpRequest e consiste nell’effettuare lato client una richiesta al server Comet; la richiesta rimane attiva finchè il server non ha un evento da notificare al client. In tal caso l’evento è ricevuto dal client come risposta e il client, dopo aver elaborato la risposta, effettua una nuova chiamata in attesa del prossimo evento, e così via.
Esempi di Comet server sono StreamHub o Orbited.
Nel prossimo articolo vedremo più da vicino le websocket API e il protocollo ws e wss.
Riferimenti
The websocket API, http://www.w3.org/TR/websockets
The websocket Protocol (RFC 6455), http://datatracker.ietf.org/doc/rfc6455/
HTML5 Web Sockets: A Quantum Leap in Scalability for the Web, http://websocket.org/quantum.html
Comet programming, http://en.wikipedia.org/wiki/Comet_(programming)
Comet: Low Latency Data for the Browser, http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser