C'è un costo del server per l'utilizzo di WebSockets?

Question

Mi sono allontanato dalla mia zona di comfort in PHP/MySQL perché la sintassi/incapsulamento/procedurale può diventare frustrante.

La settimana scorsa, ho iniziato a giocare e ho seguito alcuni tutorial per usare Node.js/Socket.IO per creare un'applicazione di chat live. Fino a questo punto, non ho mai fatto nulla con WebSockets e sembrano davvero interessanti: la comunicazione istantanea tra server e client è fantastica.

Ora, perdona la mia mancanza di comprensione qui, ma HTTP è impostato in modo tale che non si suppone che sia in grado di mantenere le connessioni aperte tra client e server - e la mia comprensione rudimentale di Comet è che obbliga la connessione rimanere aperti non terminando mai il flusso di scrittura e inviando solo byte NUL. Questo suona ... server-intensive.

Come funzionano WebSockets, quindi? Se avessi un paio di centinaia di persone nella mia app di chat in una volta, il server non sarebbe sovraccarico? Quando uso PHP/MySQL su un server, il server elabora solo una richiesta alla volta - e se dovessi usare AJAX e sondare, per esempio, ogni secondo, immagino che si espanderebbe rapidamente come se avessi migliaia di richieste al minuto.

La mia domanda è, scala WebSockets per applicazioni di grandi dimensioni? È pratico senza avere un server veramente a banda larga?

Suppongo che dipenda da: c'è un significativo carico del server/differenza di esperienza utente tra il polling AJAX a intervalli frequenti, Comet e WebSockets?

Grazie!

Answer 1

Ci sono molti siti di buona visione da leggere su come funzionano generalmente i websocket come here e here.

In breve, inizializzano una connessione con un determinato tipo di richiesta HTTP e successivamente sono una connessione bidirezionale TCP diretta tra client e server.

C'è un sovraccarico del server per mantenere un socket aperto per un client, quindi se si prevedevano decine di migliaia di questi in una volta, bisognerebbe assicurarsi che l'infrastruttura del server fosse capace di tale scala. Il carico della CPU sarebbe solo proporzionale al numero di socket occupati in un dato momento poiché un socket inattivo non richiede alcuna CPU.

La libreria Comet tenta di supportare un'interfaccia simile a WebSocket, anche quando non esiste un supporto WebSocket diretto. È qui che gli hack un po 'inefficienti iniziano a presentarsi mentre tenta di simulare un socket TCP bidirezionale mantenendo una connessione HTTP aperta. Se si utilizzano veri WebSocket, questo non è un problema.

Answer 2

Considerando la larghezza di banda, le web socket dovrebbero essere migliori o almeno non considerevolmente peggiori di tutte le soluzioni alternative con Comet o AJAX con polling lungo. Il protocollo websocket consente di inviare solo i dati quando necessario e applica solo il padding minimo (8 - 14 byte, oltre al frame TCP e IP obbligatorio) per ogni messaggio inviato.

È corretto che ogni client attivo abbia una connessione individuale aperta. Pertanto, quando si hanno molte (molte migliaia) di client simultanei, è possibile che si verifichi un limite di connessione del proprio server web, framework o sistema operativo, ma questi limiti sono solitamente configurabili.

Answer 3

Un buon posto per iniziare a conoscere WebSockets e come funziona è here. Le connessioni WebSocket "mai" terminano eccetto in caso di problemi di rete imprevisti o il client o il server decide esplicitamente di terminare la connessione.

Node.js può gestire molte connessioni aperte (a condizione che le impostazioni del descrittore di file del sistema operativo aperto siano sufficientemente elevate), quindi in genere un singolo sistema/thread può portarti molto lontano. Tuttavia, se è necessario scalare oltre un thread, è sempre possibile utilizzare il modulo 'cluster' e/o bilanciamento del carico tra più sistemi se un sistema non è sufficiente.

Se possibile, l'overhead può essere inferiore con WebSockets poiché non si creano e non si eliminano le connessioni, come nel caso di polling lungo o soluzioni simili.