L'header HTTP non farà rimanere aperta la connessione per un lungo periodo? Quindi qual è il vantaggio?come è websocket diverso da http con header header-keep-alive = million
Qualcuno può per favore chiarire per me? Mi sembra di aver perso il concetto, penso.
Al livello TCP/IP sembra uguale: una presa è aperta.
Ma dal punto di vista del browser sono completamente diversi. Il keep-alive è per il browser da riutilizzare per richiedere più contenuti (ad esempio immagini, file CSS, pagina successiva sul sito). WebSockets è per la comunicazione bidirezionale da all'interno del codice dell'applicazione Javascript. Il server può scegliere di inviare contenuti in qualsiasi momento. La tua applicazione JS può inviare dati al server in qualsiasi momento.
Vale anche la pena confrontarlo con SSE (aka EventSource), che consente anche al server di scegliere di inviare contenuto in qualsiasi momento, ma è a senso unico (l'applicazione JS deve ricorrere all'utilizzo di XHR quando è necessario inviare più dati). (Un confronto completo di WebSockets e SSE può diventare molto complesso, quindi non dirò altro qui, tranne per dire che SSE può spesso essere la scelta corretta.)
Confronto anche con Server Push in HTTP/2 (alias SPDY). Questo è per il server per spingere proattivamente i file (immagini, file css, pagina successiva sul sito), ma è di nuovo al livello del browser, non controllato da Javascript.
Quindi stai dicendo che nei contenuti: keep alive server invia i dati solo quando il browser lo richiede. Che richiede continuamente mentre la connessione è aperta mentre nel browser web socket non deve richiedere al server di inviare quando vuole. E puoi richiedere/indicare manualmente al server di inviare se necessario. –
Non penso che il browser "richieda continuamente". (Anche se avessi un ciclo javascript che caricava una nuova immagine ogni secondo, suppongo che sarebbe stato tenuto occupato). Ricorda anche che http/1.1 tipicamente esegue 6 connessioni a un server se c'è molto contenuto da recuperare. (Capisco che la tua domanda è stata teorica, ma i tempi di keep-alive molto lunghi saranno quasi certamente una cattiva idea, nel complesso.) –
Penso di averlo capito, anche in lunghe polling/http ... per comunicare con il server con il client ha bisogno di inviare http req. Il server può anche parlare al cliente. Ma la connessione si interrompe e alla fine deve essere collegata inutilmente. Ma vedo persone che dicono che websocket consente a più clienti di condividere spazio. Come funziona. –
Collegamenti che mi hanno aiutato: http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax ------- http://stackoverflow.com/questions/ 11077857/what-are-long-polling-websockets-server-send-events-sse-and-comet –
"Ad esempio in node.js è possibile condividere la stessa memoria per diverse connessioni socket, in modo che possano accedere a variabili condivise. Quindi non è necessario utilizzare il database come punto di scambio nel mezzo (come con AJAX o Long Polling e, ad esempio, PHP). È possibile memorizzare i dati nella RAM, o anche ripubblicare tra le prese immediatamente. " –
http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax –