WebSocket è sicuramente il futuro.
Il polling lungo è una soluzione sporca per impedire la creazione di connessioni per ogni richiesta come fa AJAX, ma il polling lungo è stato creato quando WebSocket non esisteva. Ora a causa di WebSocket, il polling lungo sta scomparendo.
WebRTC consente la comunicazione peer-to-peer.
Consiglio di imparare WebSocket .
Confronto:
di diverse tecniche di comunicazione sul web
AJAX - request→ response. Crea una connessione al server, invia intestazioni di richiesta con dati opzionali, ottiene una risposta dal server e chiude la connessione.
Supportato in tutti i principali browser.
Sondaggio lungo - request→ wait→ response. Crea una connessione al server come fa AJAX, ma mantiene aperta una connessione keep-alive per qualche tempo (anche se non molto tempo). Durante la connessione, il client aperto può ricevere dati dal server. Il client deve riconnettersi periodicamente dopo la chiusura della connessione, a causa di timeout o eof dei dati. Sul lato server viene comunque trattato come una richiesta HTTP, come AJAX, tranne per il fatto che la risposta su richiesta avverrà ora o in futuro, definita dalla logica dell'applicazione.
grafico di supporto (completo) | wikipedia
WebSocket - client↔ server. Creare una connessione TCP al server e tenerlo aperto per tutto il tempo necessario. Il server o il client può chiudere facilmente la connessione. Il client passa attraverso un processo di handshake compatibile HTTP. Se riesce, il server e il client possono scambiare dati in entrambe le direzioni in qualsiasi momento. È efficace se l'applicazione richiede uno scambio frequente di dati in entrambi i modi. I WebSocket hanno un frame di dati che include il mascheramento per ogni messaggio inviato dal client al server, quindi i dati vengono semplicemente crittografati.
grafico di supporto (molto buono) | wikipedia
WebRTC - peer↔ peer. Il trasporto per stabilire la comunicazione tra i client ed è indipendente dal trasporto, quindi può usare UDP, TCP o anche livelli più astratti. Questo è generalmente utilizzato per il trasferimento di dati ad alto volume, come lo streaming video / audio, in cui l'affidabilità è secondaria e alcuni frame o la riduzione della progressione della qualità possono essere sacrificati a favore dei tempi di risposta e, almeno, del trasferimento dei dati. Entrambe le parti (peer) possono trasferire i dati tra loro in modo indipendente. Sebbene possa essere utilizzato in modo totalmente indipendente da qualsiasi server centralizzato, richiede comunque un modo per scambiare dati endPoints, dove nella maggior parte dei casi gli sviluppatori utilizzano ancora server centralizzati per "collegare" i peer. Ciò è necessario solo per scambiare dati essenziali per stabilire una connessione, dopo di che non è richiesto un server centralizzato.
grafico di supporto (medio) | wikipedia
Eventi inviati dal server - client← server. Il client stabilisce una connessione persistente ea lungo termine al server. Solo il server può inviare dati a un client. Se il client desidera inviare dati al server, richiederebbe l'uso di un'altra tecnologia / protocollo per farlo. Questo protocollo è compatibile HTTP e semplice da implementare nella maggior parte delle piattaforme lato server. Questo è un protocollo preferibile da utilizzare al posto di Long Polling. grafico di supporto (buono, tranne IE) | wikipedia
vantaggi:
Il vantaggio principale di WebSocket sul lato server è che non è una richiesta HTTP (dopo l'handshake), ma un protocollo di comunicazione basato su messaggi adeguato. Ciò consente di ottenere enormi vantaggi in termini di prestazioni e architettura . Ad esempio, in node.js, è possibile condividere la stessa memoria per connessioni socket diverse, in modo che ciascuna possa accedere alle variabili condivise. Pertanto, non è necessario utilizzare un database come punto di scambio nel mezzo (come con AJAX o Long Polling con un linguaggio come PHP). È possibile archiviare i dati nella RAM o persino ripubblicare immediatamente tra i socket.
Considerazioni sulla sicurezza
Le persone sono spesso preoccupate per la sicurezza di WebSocket. La realtà è che fa poca differenza o addirittura mette WebSocket come opzione migliore. Innanzitutto, con AJAX, vi è una maggiore possibilità di MITM , poiché ogni richiesta è una nuova connessione TCP che attraversa l'infrastruttura Internet. Con WebSocket, una volta connesso, è molto più difficile intercettare nel mezzo, con il mascheramento del frame ulteriormente applicato quando i dati vengono trasmessi da client a server e una compressione aggiuntiva, il che richiede uno sforzo maggiore per sondare i dati. Tutti i protocolli moderni supportano entrambi: HTTP e HTTPS (crittografati).
PS
Ricorda che i WebSocket hanno generalmente un approccio logico molto diverso per la rete , più come i giochi in tempo reale avevano tutto questo tempo e non come gli http.
