Alcune ottime risposte da altri che coprono un sacco di terreno. Ecco un piccolo extra.
L'unico vantaggio di WebSocket rispetto a plug-in come Java Applet, Flash o Silverlight è che i WebSocket sono integrati in modo nativo nei browser e non si basano su plug-in.
Se con questo intendi che puoi utilizzare Java Applet, Flash o Silverlight per stabilire una connessione socket, allora sì, è possibile. Tuttavia non lo vedi troppo spesso distribuito nel mondo reale a causa delle restrizioni.
Ad esempio, gli intermediari possono chiudere quel traffico e lo fanno. Lo standard WebSocket è stato progettato per essere compatibile con l'infrastruttura HTTP esistente e quindi è molto meno incline a essere interferito da intermediari come firewall e proxy.
Inoltre, WebSocket può utilizzare le porte 80 e 443 senza richiedere porte dedicate, ancora una volta grazie al design del protocollo per essere il più compatibile possibile con l'infrastruttura HTTP esistente.
Queste alternative socket (Java, Flash e Silverlight) sono difficili da utilizzare in modo sicuro in un'architettura cross-origin. Pertanto, le persone che spesso tentano di usarli cross-origin tollereranno le insicurezze piuttosto che sforzarsi di farlo in modo sicuro.
Possono anche richiedere l'apertura di ulteriori porte "non standard" (cosa che gli amministratori non amano fare) o file di criteri che devono essere gestiti.
In breve, l'utilizzo di Java, Flash o Silverlight per la connettività socket è abbastanza problematico da non vederlo distribuito troppo spesso in architetture serie. Flash e Java hanno questa capacità probabilmente da almeno 10 anni, eppure non è prevalente.
Lo standard WebSocket è stato in grado di iniziare con un nuovo approccio, tenendo presenti queste restrizioni e, si spera, avendo imparato alcune lezioni da esse.
Alcune implementazioni di WebSocket utilizzano Flash (o forse Silverlight e / o Java) come fallback quando non è possibile stabilire la connettività WebSocket (ad esempio durante l'esecuzione in un vecchio browser o quando un intermediario interferisce).
Sebbene una sorta di strategia di riserva per queste situazioni sia intelligente, persino necessaria, la maggior parte di coloro che utilizzano Flash e altri soffriranno degli svantaggi descritti sopra. Non deve essere necessariamente così: esistono soluzioni alternative per ottenere connessioni sicure con capacità cross-origin utilizzando Flash, Silverlight, ecc., Ma la maggior parte delle implementazioni non lo farà perché non è facile.
Ad esempio, se ti affidi a WebSocket per una connessione cross-origin, funzionerà correttamente. Ma se poi si esegue in un vecchio browser o un firewall / proxy ha interferito e si fa affidamento su Flash, ad esempio, come fallback, sarà difficile eseguire la stessa connessione cross-origin. A meno che non ti interessi della sicurezza, ovviamente.
Ciò significa che è difficile avere un'unica architettura unificata che funzioni per connessioni native e non native, a meno che tu non sia pronto a dedicare un bel po 'di lavoro o ad andare con un framework che lo ha fatto bene. In un'architettura ideale, non noteresti se le connessioni fossero native o meno; le tue impostazioni di sicurezza funzionerebbero in entrambi i casi; le tue impostazioni di clustering funzionerebbero ancora; la pianificazione della capacità sarebbe ancora valida; e così via.
L'unico vantaggio di WebSocket rispetto allo streaming http è che non è necessario fare uno sforzo per "comprendere" e analizzare i dati ricevuti.
Non è semplice come aprire un flusso HTTP e sedersi mentre i dati scorrono per minuti, ore o più. Clienti diversi si comportano in modo diverso e tu devi gestirlo. Ad esempio, alcuni client eseguiranno il buffering dei dati e non li rilasceranno all'applicazione finché non viene raggiunta una certa soglia. Ancora peggio, alcuni non passeranno i dati all'applicazione fino alla chiusura della connessione.
Quindi, se invii più messaggi al client, è possibile che l'applicazione client non riceva i dati fino a quando non sono stati ricevuti 50 messaggi di dati, ad esempio. Non è troppo in tempo reale.
Sebbene lo streaming HTTP possa essere una valida alternativa quando WebSocket non è disponibile, non è una panacea. Ha bisogno di una buona comprensione per funzionare in modo robusto nelle terre selvagge del Web in condizioni reali.
Ci sono altre differenze significative che mi mancano?
C'è un'altra cosa che nessuno ha ancora menzionato, quindi ne parlerò.
Il protocollo WebSocket è stato progettato per essere un livello di trasporto per protocolli di livello superiore. Sebbene sia possibile inviare messaggi JSON o altro direttamente su una connessione WebSocket, può anche trasportare protocolli standard o personalizzati.
Ad esempio, potresti fare AMQP o XMPP su WebSocket, come hanno già fatto le persone. Quindi un client potrebbe ricevere messaggi da un broker AMQP come se fosse connesso direttamente al broker stesso (e in alcuni casi lo è).
Oppure, se hai un server esistente con un protocollo personalizzato, puoi trasportarlo su WebSocket, estendendo così quel server back-end al Web. Spesso un'applicazione esistente che è stata bloccata nell'azienda può ampliare la sua portata utilizzando WebSocket, senza dover modificare alcuna infrastruttura di back-end.
(Naturalmente, vorresti essere in grado di fare tutto ciò in modo sicuro, quindi controlla con il venditore o il provider WebSocket.)
Alcune persone hanno fatto riferimento a WebSocket come TCP per il Web. Perché proprio come il TCP trasporta protocolli di livello superiore, anche WebSocket fa lo stesso, ma in un modo compatibile con l'infrastruttura Web.
Quindi, sebbene sia sempre possibile inviare messaggi JSON (o qualsiasi altra cosa) direttamente su WebSocket, si dovrebbero anche considerare i protocolli esistenti. Perché per molte cose che vuoi fare, probabilmente c'è un protocollo che è già stato pensato per farlo.
Mi dispiace se sto ripetendo o combinando molte delle domande già su SO in un'unica domanda, ma voglio solo dare un senso perfetto a tutte le informazioni disponibili su SO e sul web riguardo a questi concetti.
Questa è stata un'ottima domanda e le risposte sono state tutte molto istruttive!