Qual è lo svantaggio dell'uso di websocket/socket.io dove andrà ajax?

Question

Domande simili sono già state fatte prima e sono tutti giunti alla conclusione che AJAX non diventerà obsoleto. Ma in che modo ajax è meglio delle websocket?

Con socket.io, è facile ricorrere al flash o al polling lungo, quindi la compatibilità del browser sembra essere un problema.

Web socket sono bidirezionali. Dove ajax avrebbe effettuato una richiesta asincrona, il client websocket avrebbe inviato un messaggio al server. I parametri POST/GET possono essere codificati in JSON.

Quindi cosa c'è di sbagliato nell'usare 100% web socket? Se ogni visitatore mantiene una connessione websocket persistente al server, sarebbe più dispendioso che fare alcune richieste ajax durante la sessione di visita?

Answer 1

Non c'è niente di "sbagliato" in proposito.

L'unica differenza è principalmente leggibilità. Il vantaggio principale di Ajax è che ti consente uno sviluppo rapido perché la maggior parte delle funzionalità è scritta per te.

C'è un grande vantaggio nel non dover reinventare la ruota ogni volta che si desidera aprire una presa.

Answer 2

Penso che prima o poi i framework basati su Websocket cominceranno a non solo per la scrittura di chat in tempo reale come parti di app Web, ma anche come framework web standalone. Una volta creata la connessione permanente, può essere utilizzata per ricevere tutti i tipi di materiale, incluse le parti dell'interfaccia utente dell'applicazione Web, che vengono ora fornite ad esempio tramite richieste AJAX. Questo approccio può danneggiare la SEO in qualche modo, sebbene possa ridurre la quantità di traffico e il carico generato da richieste asincrone che include intestazioni HTTP ridondanti.

Tuttavia dubito che i websocket sostituiranno o comprometteranno AJAX perché ci sono numerosi scenari in cui le connessioni permanenti sono inutili o indesiderate. Ad esempio le applicazioni di mashup che utilizzano servizi basati su REST a scopo singolo (una tantum) che non devono necessariamente essere connessi in modo permanente con i client.

Answer 3

Penso che sarebbe più dispendioso. Per ogni client connesso è necessario un qualche tipo di oggetto/funzione/codice/qualsiasi cosa sul server abbinato a quel client. Un gestore di socket o un descrittore di file o comunque il server è configurato per gestire le connessioni.

Con AJAX non è necessario un mapping 1: 1 della risorsa lato server al client. Il numero di clienti può scalare in modo meno dipendente rispetto alle risorse lato server. Anche node.js ha i suoi limiti su quante connessioni può gestire e tenere aperto.

L'altra cosa da considerare è che alcune risposte AJAX possono anche essere memorizzate nella cache. Mentre si scala, è possibile aggiungere una cache HTTP per ridurre il carico da richieste AJAX frequenti.

Answer 4

Personalmente, penso che i websocket verranno utilizzati sempre più nelle applicazioni Web anziché in AJAX. Non sono adatti ai siti web in cui la memorizzazione nella cache e il SEO sono di maggiore preoccupazione, ma faranno miracoli per le applicazioni web.

Progetti come DNode e socketstream aiutano a rimuovere la complessità e consentono la semplice codifica in stile RPC. Questo significa che il tuo codice client chiama semplicemente una funzione sul server, passando qualsiasi dato a quella funzione che desidera. E il server può chiamare una funzione sul client e passare anche i dati. Non hai bisogno di preoccuparti delle cose grosse del TCP.

Inoltre, si verificano molti sovraccarichi con le chiamate AJAX. Ad esempio, è necessario stabilire una connessione e le intestazioni HTTP (cookie, ecc.) Vengono passate ad ogni richiesta. Le Websocket eliminano molto di questo. Alcuni dicono che le ragnatele sono più dispendiose e forse hanno ragione. Ma non sono convinto che la differenza sia davvero così sostanziale.

Ho risposto ad un'altra domanda correlata in dettaglio, inclusi molti collegamenti a risorse correlate. Si potrebbe verificare out:

websocket api to replace rest api?

Answer 5

WS: // connessioni hanno molto meno overhead di richieste "Ajax".

Answer 6

Risposta breve
Mantenere un websocket attiva ha un costo, sia per il client e il server, se l'Ajax avrà un costo solo una volta, a seconda di quello che stai facendo con esso.

lungo risposta
WebSockets sono spesso frainteso a causa di tutto questo "Ehi, utilizzare Ajax, che farà!". No, Websockets non sostituisce Ajax. Possono potenzialmente essere applicati agli stessi campi, ma ci sono casi in cui l'uso di Websocket è assurdo.

Facciamo un semplice esempio: una pagina dinamica che carica i dati dopo che la pagina è stata caricata sul lato client. È semplice, effettua una chiamata Ajax. Abbiamo solo bisogno di una direzione, dal server al client. Il cliente chiederà questi dati, il server li invierà al client, fatto. Perché dovresti implementare websocket per tale compito? Non è necessario che la connessione sia sempre aperta, non è necessario che il client chieda costantemente al server, non è necessario che il server comunichi il client. La connessione rimarrà aperta, sprecherà risorse, perché per mantenere aperta una connessione è necessario controllarla costantemente.

Ora per un'applicazione di chat le cose sono completamente diverse. È necessario che il client venga avvisato dal server invece di forzare il client a chiedere al server ogni x secondi o millisecondi se qualcosa è nuovo. Non avrebbe senso

Per capire meglio, vedere come due persone. Uno dei due è il server, l'over è il client. Ajax è come inviare una lettera. Il client invia una lettera, il server risponde con un'altra lettera. Il fatto è che, per un'applicazione di chat la conversazione sarebbe stato così:
"Hey Server, ha qualcosa per me
- No.
- Ehi Server, ha qualcosa per me
- No.
?? - Ehi Server, ho qualcosa per me?
- Sì, eccolo. "
Il server non può effettivamente inviare una lettera al client, se il client non ha mai chiesto una risposta. È un enorme spreco di risorse. Perché per ogni richiesta Ajax, anche se è memorizzata nella cache, è necessario eseguire un'operazione sul lato server.

Ora il caso ho discusso in precedenza con i dati caricati con Ajax. Immagina che il client sia al telefono con il server. Mantenere attiva la connessione ha un costo. Costa elettricità e devi pagare il tuo operatore. Ora, perché dovresti chiamare qualcuno e tenerlo al telefono per un'ora, se vuoi che quella persona ti dica 3 parole? Manda una dannata lettera

In conclusione Websockets non è un sostituto totale per Ajax!
A volte è necessario necessario Ajax in cui l'utilizzo di Websocket è assurdo.

Edit: Il caso SSE
che la tecnologia non viene utilizzata molto ampiamente, ma può essere utile. Come dice il nome, gli eventi inviati dal server sono una spinta unidirezionale dal server al client. Il client non richiede nulla, il server invia solo i dati.

In breve:
- unidirezionale dal client: Ajax
- unidirezionale dal server: SSE
- bidirezionale: WebSockets

Answer 7

Come altre persone hanno detto, mantenendo aperta la connessione può essere eccessivo in alcuni scenari dove non hai bisogno di notifiche da server a client, o la richiesta da client a server avviene con bassa frequenza.

Un altro svantaggio è che Websockets è un protocollo di basso livello, che non offre funzionalità aggiuntive a TCP una volta eseguito l'handshake iniziale. Quindi, quando si implementa un paradigma richiesta-risposta su websocket, probabilmente mancherete le funzioni che HTTP (una famiglia di protocolli molto matura ed estesa) offre, come cache (client e cache condivise), convalida (richieste condizionali), sicurezza e idempotence (con implicazioni su come si comporta l'agente), intervallo di richieste, tipi di contenuto, codici di stato, ...

Cioè, si riducono le dimensioni dei messaggi ad un costo.

Quindi la mia scelta è AJAX per la richiesta-risposta, WebSockets per il server spingere e ad alta frequenza di messaggistica a bassa latenza

Answer 8

Se si desidera che la connessione al server aperto e se il polling continuo al server ci sarà poi andare per i socket altrimenti sei a posto con Ajax.

Analogia semplice: Ajax fa domande (richieste) a server e server fornisce risposte (risposte) a queste domande. Ora se vuoi fare domande continue allora ajax non funzionerà, ha un grande overhead che richiederà risorse ad entrambe le estremità.