Il presente articolo è stato tradotto automaticamente.

Cutting Edge

La potenza dei WebSocket

Dino Esposito

 

Il World Wide Web corrente non è progettato per essere un mezzo in tempo reale.Applicazioni Web danno l'impressione di continuo si sentono attraverso soluzioni di polling classico implementato tramite AJAX o forse richieste di lungo-polling quando effettivamente implementati da librerie ad hoc come SignalR e la cometa. Per le esigenze della maggior parte delle applicazione­cationi, di polling sono una buona soluzione, anche se potrebbe soffrire di latenza client-server e client-server. In questo articolo sarà a scoprire una nuova alternativa chiamata WebSockets.

La crescente integrazione tra Web e applicazioni mobili con i social media sta abbassando la soglia di tollerabile ritardo nell'interazione client/server. Quando si aggiorna il tuo status di Facebook, si desidera che le informazioni siano immediatamente disponibili ai tuoi amici. Allo stesso modo, quando qualcuno piace uno dei tuoi post, si desidera ricevere notifica immediatamente. Oggi, tutte queste caratteristiche sono reali, e questo è solo uno dei motivi per l'adozione a livello mondiale di Facebook e per l'esplosione del fenomeno dei social network. Così alla fine, c'è una significativa richiesta da parte degli sviluppatori di soluzioni e strumenti per l'implementazione di comunicazione in tempo reale sul Web.

Per raggiungere una connettività senza ritardi tra client e server Web è necessario oltrepassare il protocollo HTTP. Questo è proprio ciò che fornisce il protocollo WebSocket. Attualmente non esiste un Internet Engineering Task Force standard per il protocollo WebSocket; può leggere su di esso a bit.ly/va6qSS. Una API standard per attuare il protocollo è essere formalizzato il World Wide Web Consortium (W3C) per i browser per sostenerlo (vedere bit.ly/h1IsjB). La specifica è in stato di "Candidato raccomandazione".

Il protocollo WebSocket

Il nuovo protocollo WebSocket mira a superare un limite strutturale del protocollo HTTP che lo rende inefficiente per applicazioni Web ospitate nei browser di rimanere connesso al server tramite una connessione persistente. Il protocollo WebSocket consente la comunicazione bidirezionale tra applicazioni Web e server Web su un singolo socket TCP. In altri termini, il protocollo rende possibile per un'applicazione Web, ospitata in un browser rimanere in contatto con un endpoint Web tutto il tempo mentre incorrere in spese minime, come pressione sul consumo server, memoria e risorse. L'effetto netto è che i dati e le notifiche possono andare e venire tra browser e server Web con nessun ritardo e non c'è bisogno di organizzare per ulteriori richieste. Enfatico come può sembrare, il protocollo WebSocket apre un nuovo mondo di possibilità per gli sviluppatori e rende basate sul polling trucchi e quadri una cosa del passato. Beh, non esattamente.

Utilizzando WebSockets oggi

Il supporto per il protocollo WebSocket browser migliorerà rapidamente, ma solo le ultime versioni dei browser sosterrà WebSockets, naturalmente. Gli utenti che di solito non aggiorni loro browser regolarmente (o non sono autorizzati a eseguire l'aggiornamento da rigorose politiche aziendali) saranno lasciati alle spalle.

Questo significa che gli sviluppatori non possono abbandonare solo codice basato su AJAX polling o lungo polling basato su soluzioni. A questo proposito, esso è rilevante notare che SignalR — imminente Microsoft framework per zero-lag messaggistica tra browser e server Web — fa un lavoro fantastico di astrarre una connessione persistente, passare automaticamente a WebSockets dove supportati e l'uso di polling lungo in qualsiasi altri casi. Ho coperto SignalR in colonne di recente e ancora una volta vi invito a provarlo più presto se non avete fatto ancora. SignalR ha tutto per essere una libreria vincente e uno strumento per ogni sviluppatore e qualsiasi applicazione Web.

Che supporta WebSockets oggi?

Figura 1 fornisce un breve riassunto del sostegno per WebSockets che più diffusi browser forniscono al momento.

Figura 1 Browser il supporto per WebSockets

Browser	Supporto WebSockets
Internet Explorer	WebSockets sarà supportato in Internet Explorer 10. Metropolitana applicazioni scritte utilizzando JavaScript e HTML5 sosterrà WebSockets pure.
Firefox	WebSockets sono supportati a partire dalla versione 6 del browser rilasciato in metà-2011. Qualche sostegno molto precoce è stato offerto in versione 4 e poi abbandonato nella versione 5.
Colore	WebSockets sono supportati a partire dalla versione 14, che venne pubblicato nel settembre 2011.
Opera	Supporto per WebSockets è stata rimossa nella versione 11.
Safari	Supporta una versione precedente del protocollo WebSocket.

Con l'eccezione di Firefox, è possibile controllare a livello di codice per il supporto di WebSockets guardando la finestra.Oggetto WebSocket. Attualmente, per Firefox, si dovrebbe controllare l'oggetto MozWebSocket. Dovrebbe essere notato che più funzionalità relative ai HTML5 può essere controllata in browser per mezzo di una biblioteca specializzata, come Modernizr (modernizr.com). In particolare, ecco il codice JavaScript che è necessario scrivere se hai collegato alla libreria Modernizr alla tua pagina:

if (Modernizr.websockets)
{
  ...
}

Modernizr è probabilmente una scelta eccellente oggi se si desidera iniziare a utilizzare un'implementazione WebSocket perché vi offre polyfills — codice che calcia in automaticamente se una determinata caratteristica non è supportata sul browser corrente.

Alla fine, WebSockets sono una caratteristica estremamente convincente con supporto non uniforme oggi attraverso i fornitori. Microsoft, tuttavia, in senso lato supporta WebSockets attraverso i prossimi 10 di Internet Explorer e anche IIS, ASP.NET, Windows Communication Foundation (WCF) e Windows Runtime (WinRT). Si noti, però, che nessun API standard ufficiale esiste ancora, così i primi aiuti sono un grande segno di interesse. Il meglio che puoi fare oggi è utilizzare WebSockets attraverso un certo livello di astrazione. Modernizr è un'opzione possibile, se si vuole stare vicino al metallo e scrivere il proprio codice che apre e chiude WebSockets. SignalR è una soluzione migliore se siete alla ricerca di un quadro che collega in modo trasparente un browser e un endpoint Web in maniera persistente, con senza fronzoli e senza bisogno di conoscere molti dettagli sottostanti.

Uno sguardo al protocollo WebSocket

Il protocollo WebSocket per la comunicazione bidirezionale è necessario che l'applicazione client e server sono consapevoli i dettagli del protocollo. Questo significa che avete bisogno di una pagina Web conforme a WebSocket che rimette in un endpoint conforme a WebSocket.

Un'interazione WebSocket inizia con una stretta di mano in cui le due parti (browser e il server) reciprocamente confermano l'intenzione di comunicare attraverso una connessione permanente. Successivamente, un mazzo di pacchetti di messaggi vengono inviati su TCP in entrambe le direzioni. Figura 2 delinea come funziona il protocollo WebSocket.

Nella figura 2 dello Schema di protocollo WebSocket

Si noti che, oltre a ciò che è in Figura 2, quando la connessione viene chiusa, entrambi gli endpoint scambiano una cornice stretta in modo pulito chiudere la connessione. La stretta di mano iniziale è costituito da una semplice richiesta HTTP che il client invia al server Web. La richiesta è un HTTP GET configurato come una richiesta di aggiornamento:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com

Nel HTTP, la richiesta di un client con l'intestazione Upgrade indica l'intenzione del client per richiedere che il server di passare a un altro protocollo. Con il protocollo WebSocket, la richiesta al server di aggiornamento contiene una chiave univoca che il server restituirà straziata come la prova che ha accettato la richiesta di aggiornamento. Questa è una dimostrazione pratica di mostrare che il server comprende il protocollo WebSocket. Ecco un campione in risposta a una richiesta di stretta di mano:

HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Un codice di stato di successo è sempre 101, e qualsiasi altro codice di stato verrà interpretata come un rifiuto di eseguire l'aggiornamento al protocollo WebSocket. Il server concatena la chiave ricevuta con una stringa GUID fissa e calcola un hash di stringa risultante. Il valore hash viene poi codificato in Base64 e restituito al client tramite l'intestazione Sec-WebSocket-Accept.

Il client può inviare anche altre intestazioni quali Sec-WebSocket -­protocollo al fine di indicare quali subprotocols è felice di impiegare. Un subprotocol è un protocollo a livello applicazione costruito sulla cima di WebSocket protocollo di base. Se il server comprende alcuni della subprotocols suggerito, esso uno pick up e invia il suo nome al client tramite l'intestazione stessa.

Dopo la stretta di mano, il client e il server può liberamente inviare messaggi tramite il protocollo WebSocket. Il payload inizia con un opcode che indica l'operazione eseguita. Uno di questi codici operativi — specificamente 0x8 — indica la richiesta di chiudere la sessione. Si noti che WebSocket messaggi in modo asincrono andare così una richiesta di invio non necessariamente ricevuta una risposta immediata, come in HTTP. Con il protocollo WebSocket, è meglio pensare in termini di messaggi generali andando da client a server o viceversa e dimenticando il modello classico richiesta/risposta http.

L'URL tipico per un endpoint WebSocket assume la forma seguente:

var myWebSocket =
    new WebSocket("ws://www.websocket.org");

Utilizzare il prefisso di protocollo wss se si vuole andare su una connessione secure socket (connessioni protette generalmente avrà più successo quando intermediari sono presenti). Infine, il protocollo WebSocket riconosce e affronta il problema della comunicazione cross-origine. Un client WebSocket generalmente — ma non sempre — consente l'invio di richieste agli endpoint situato su qualsiasi dominio. Ma è il server di WebSocket che deciderà se accettare o rifiutare la richiesta di stretta di mano.

Un'occhiata alla WebSocket API

Come già accennato, il W3C è attualmente standardizzando un'API per il protocollo WebSocket e browser stanno recuperando con le varie bozze appena sono disponibili. Dovreste sapere qualsiasi codice che funziona oggi potrebbe non funzionare su tutti i browser e, più importante, non è nemmeno garantito per lavorare su stesso browser quando una nuova release colpisce il mercato. In ogni caso, una volta che avete alcuni WebSocket codice di lavoro hai praticamente finito, come eventuali modifiche che potrebbero essere richiesti in futuro sarà probabilmente solo piccole modifiche.

Se volete sperimentare con il protocollo WebSocket si può visitare websocket.org con un browser che supporta il protocollo. Ad esempio, è possibile utilizzare un'anteprima di Internet Explorer 10 o una versione recente di Google Chrome. Figura 3 mostra la stretta di mano, come rilevato dalla violinista.

Figura 3 reale Handshaking tra Browser e Server

Non sorprendentemente, la versione corrente del violinista (versione 2.3. x) solo catturerà il traffico HTTP. Tuttavia, una nuova versione del violinista che si occupa di traffico WebSocket è attualmente in versione beta.

L'API WebSocket è abbastanza semplice. Sul lato del browser, è necessario creare un'istanza della classe WebSocket browser. Questa classe espone un mucchio di eventi interessanti per il quale si desidera avere gestori corretto:

var wsUri = " ws://echo.websocket.org/";
websocket = new WebSocket(wsUri);
websocket.onopen = function(evt) { onOpen(evt) };
websocket.onmessage = function(evt) { onMessage(evt) };
websocket.onclose = function(evt) { onClose(evt) };
websocket.onerror = function(evt) { onError(evt) };

L'evento SuApertura viene generato quando viene stabilita la connessione. Ogni volta che il client riceve un messaggio dal server, viene generato l'evento onmessage. Il onclose viene attivato quando la connessione è stata chiusa. Infine, onerror viene generato ogni volta che si verifica un errore.

Per inviare un messaggio al server, tutto quello che dovete fare è effettuare una chiamata a inviare il metodo, come illustrato di seguito:

var message = "Cutting Edge test: " +
  new Date().toString();
websocket.send(message);

Figura 4 mostra una pagina di esempio è un adattamento dell'esempio riportato eco sul sito Web websocket.org. In questo esempio il server appena riecheggia il messaggio ricevuto al client.

Figura 4 il protocollo WebSocket in azione

Se siete interessati a WebSocket programmazione per Internet Explorer 10, vedere bit.ly/GNYWFh.

Il lato Server del WebSockets

In questo articolo focalizzato soprattutto sul lato client del protocollo WebSocket. Dovrebbe essere chiaro che per poter utilizzare un client WebSocket, bisogno di un server compatibile con WebSocket corretto che capisce le richieste e può rispondere in modo appropriato. Quadri per la creazione di un server di WebSocket hanno iniziato a comparire. Ad esempio, è possibile provare Socket.IO per Java e node. js (socket.io). Se stai cercando qualche Microsoft.NET roba Framework, date un'occhiata a "Web Socket Server" da The Project codice a bit.ly/lc0rjt. Inoltre, il supporto Microsoft server per WebSockets è disponibile in IIS, ASP.NET e WCF. È possibile fare riferimento al video Channel 9, "Real-Time Web Apps con WebSockets da costruzione Using IIS, ASP.NET e WCF,"per maggiori dettagli (bit.ly/rnYaw5).

A fette di pane, acqua calda e WebSockets

Come molti hanno detto, WebSockets sono l'invenzione più utile a fette di pane e acqua calda. Dopo che hai fatto senso di WebSockets chiedo solo come il mondo del software potrebbe aver prosperato senza di loro. WebSockets sono utili in un certo numero di applicazioni, ma non per solo tutte le applicazioni. Tutte le applicazioni dove la messaggistica immediata è la chiave sono uno scenario potenziale dove si può considerare seriamente costruendo un server WebSocket e un sacco di clienti — Web, mobile o addirittura desktop. Videogiochi e mangimi vivere le applicazioni sono altri campi dell'industria che andrà a beneficio immensamente dal protocollo WebSocket. Sì, WebSockets sono sicuramente il migliore dopo l'acqua calda!

Dino Esposito   è l'autore di "programmazione ASP.NET 4 "(Microsoft Press, 2011) e"programmazione ASP.NET MVC 3 "(Microsoft Press, 2010) e coautore di"Microsoft.NET: Architettura delle applicazioni per l'impresa"(Microsoft Press, 2008). Con sede in Italia, Esposito è un oratore frequenti a eventi del settore in tutto il mondo. Seguirlo su Twitter a twitter.com/despos.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Levi Broderick e Brian Raymor