Protocollo WebSocket vs HTTP

Ci sono molti blog e discussioni su websocket e HTTP, e molti sviluppatori e siti sostengono fortemente i websocket, ma ancora non riesco a capire il perché.

per esempio (argomenti degli amanti del websocket):

HTML5 Web Socket rappresenta la prossima evoluzione delle comunicazioni Web: un canale di comunicazione bidirezionale full duplex che opera attraverso un singolo socket sul Web. ( http://www.websocket.org/quantum.html )

HTTP supporta lo streaming: richiedi lo streaming del corpo (lo stai usando durante il caricamento di file di grandi dimensioni) e lo streaming del corpo di risposta.

Durante la connessione con WebSocket, client e server scambiano dati per frame pari a 2 byte ciascuno, rispetto a 8 chilogrammi di intestazione http quando si esegue il polling continuo.

Perché quei 2 byte non includono l'overhead dei protocolli tcp e under tcp?

GET /about.html HTTP/1.1
Host: example.org

Questa è un'intestazione http di ~ 48 byte.

codifica http chunked - https://en.wikipedia.org/wiki/Chunked_transfer_encoding :

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

• Quindi, il sovraccarico per ogni pezzo non è grande.

Inoltre, entrambi i protocolli funzionano su TCP, quindi tutti i problemi TCP con connessioni long-life sono ancora presenti.

Domande:

1. Perché il protocollo WebSocket è migliore?
2. Perché è stato implementato invece di aggiornare il protocollo http?

1) Perché il protocollo WebSocket è migliore?

WebSocket è migliore per situazioni che implicano comunicazioni a bassa latenza, in particolare per bassa latenza per i messaggi da client a server. Per i dati da server a client è possibile ottenere una latenza piuttosto bassa utilizzando connessioni a lungo termine e trasferimento in blocchi. Tuttavia, ciò non aiuta con la latenza client-server che richiede la creazione di una nuova connessione per ciascun messaggio client-server.

L'handshake HTTP a 48 byte non è realistico per le connessioni del browser HTTP nel mondo reale in cui spesso ci sono diversi kilobyte di dati inviati come parte della richiesta (in entrambe le direzioni) inclusi molti header e dati di cookie. Ecco un esempio di una richiesta / risposta all'utilizzo di Chrome:

Richiesta di esempio (2800 byte inclusi i dati sui cookie, 490 byte senza i dati sui cookie):

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

Risposta di esempio (355 byte):

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

Entrambi HTTP e WebSocket hanno handshake di connessione iniziali di dimensioni equivalenti, ma con una connessione WebSocket l'handshake iniziale viene eseguito una volta e quindi i messaggi piccoli hanno solo 6 byte di overhead (2 per l'intestazione e 4 per il valore della maschera). Il sovraccarico di latenza non dipende dalle dimensioni delle intestazioni, ma dalla logica per analizzare / gestire / archiviare quelle intestazioni. Inoltre, la latenza della configurazione della connessione TCP è probabilmente un fattore maggiore della dimensione o del tempo di elaborazione per ciascuna richiesta.

2) Perché è stato implementato invece di aggiornare il protocollo HTTP?

Ci sono sforzi per riprogettare il protocollo HTTP per ottenere prestazioni migliori e una latenza inferiore come SPDY , HTTP 2.0 e QUIC . Ciò migliorerà la situazione per le normali richieste HTTP, ma è probabile che WebSocket e / o WebRTC DataChannel avranno ancora una latenza inferiore per il trasferimento dei dati da client a server rispetto al protocollo HTTP (o verrà utilizzato in una modalità che assomiglia molto a WebSocket in ogni modo).

Aggiornamento :

Ecco un framework per pensare ai protocolli Web:

• TCP : livello di trasporto ordini basso livello, bidirezionale, full duplex e garantito. Nessun supporto browser (tranne tramite plug-in / Flash).
• HTTP 1.0 : protocollo di trasporto richiesta-risposta stratificato su TCP. Il client effettua una richiesta completa, il server fornisce una risposta completa e quindi la connessione viene chiusa. I metodi di richiesta (GET, POST, HEAD) hanno un significato transazionale specifico per le risorse sul server.
• HTTP 1.1 : mantiene la natura richiesta-risposta di HTTP 1.0, ma consente alla connessione di rimanere aperta per più richieste complete / risposte complete (una risposta per richiesta). Ha ancora le intestazioni complete nella richiesta e nella risposta ma la connessione viene riutilizzata e non chiusa. HTTP 1.1 ha anche aggiunto alcuni metodi di richiesta aggiuntivi (OPTIONS, PUT, DELETE, TRACE, CONNECT) che hanno anche significati transazionali specifici. Tuttavia, come notato nell'introduzione alla proposta di bozza HTTP 2.0, il pipelining HTTP 1.1 non è ampiamente distribuito, quindi questo limita notevolmente l'utilità di HTTP 1.1 per risolvere la latenza tra browser e server.
• Long-poll : una sorta di "hack" su HTTP (1.0 o 1.1) in cui il server non risponde immediatamente (o risponde solo parzialmente con le intestazioni) alla richiesta del client. Dopo una risposta del server, il client invia immediatamente una nuova richiesta (utilizzando la stessa connessione se su HTTP 1.1).
• Streaming HTTP : una varietà di tecniche (risposta multipart / chunked) che consentono al server di inviare più di una risposta a una singola richiesta client. Il W3C sta standardizzando questo come Eventi inviati dal server usando un text/event-streamtipo MIME. L'API del browser (che è abbastanza simile all'API WebSocket) è chiamata API EventSource.
• Cometa / push del server : questo è un termine generico che include sia lo streaming a lungo termine che lo streaming HTTP. Le librerie di comete di solito supportano più tecniche per cercare di massimizzare il supporto tra browser e tra server.
• WebSocket : un livello TCP di trasporto integrato che utilizza una stretta di mano di aggiornamento compatibile con HTTP. A differenza di TCP, che è un trasporto in streaming, WebSocket è un trasporto basato su messaggi: i messaggi vengono delimitati sul filo e vengono riassemblati per intero prima della consegna all'applicazione. Le connessioni WebSocket sono bidirezionali, full duplex e di lunga durata. Dopo la richiesta / risposta iniziale di handshake, non vi è alcuna semantica transazionale e l'overhead per messaggio è molto limitato. Il client e il server possono inviare messaggi in qualsiasi momento e devono gestire la ricezione dei messaggi in modo asincrono.
• SPDY : una proposta avviata da Google per estendere HTTP utilizzando un protocollo wire più efficiente ma mantenendo tutta la semantica HTTP (richiesta / risposta, cookie, codifica). SPDY introduce un nuovo formato di frame (con frame prefissati in lunghezza) e specifica un modo per sovrapporre le coppie richiesta / risposta HTTP sul nuovo layer di frame. Le intestazioni possono essere compresse e le nuove intestazioni possono essere inviate dopo aver stabilito la connessione. Esistono implementazioni reali di SPDY in browser e server.
• HTTP 2.0 : ha obiettivi simili a SPDY: ridurre la latenza e le spese generali HTTP preservando la semantica HTTP. La bozza corrente è derivata da SPDY e definisce un handshake di aggiornamento e un frame di dati che è molto simile allo standard WebSocket per handshake e frame. Una proposta di bozza HTTP 2.0 alternativa (httpbis-speed-mobility) utilizza effettivamente WebSocket per il livello di trasporto e aggiunge il multiplexing SPDY e il mapping HTTP come estensione WebSocket (le estensioni WebSocket vengono negoziate durante l'handshake).
• WebRTC / CU-WebRTC : proposte per consentire la connettività peer-to-peer tra i browser. Ciò può consentire comunicazioni con latenza media e massima inferiori poiché il trasporto sottostante è SDP / datagramma anziché TCP. Ciò consente la consegna fuori pacchetto di pacchetti / messaggi, evitando il problema TCP di picchi di latenza causati da pacchetti persi che ritardano la consegna di tutti i pacchetti successivi (per garantire la consegna in ordine).
• QUIC : è un protocollo sperimentale volto a ridurre la latenza del web rispetto a quella del TCP. A prima vista, QUIC è molto simile a TCP + TLS + SPDY implementato su UDP. QUIC fornisce multiplexing e controllo del flusso equivalenti a HTTP / 2, sicurezza equivalente a TLS e semantica della connessione, affidabilità e controllo della congestione equivalenti a TCP. Poiché TCP è implementato nei kernel del sistema operativo e nel firmware middlebox, apportare modifiche significative a TCP è quasi impossibile. Tuttavia, poiché QUIC è costruito su UDP, non presenta tali limiti. QUIC è progettato e ottimizzato per la semantica HTTP / 2.

Riferimenti :

• HTTP :
  • Pagina HTTP Wikipedia
  • Elenco W3C di bozze / protocolli relativi all'HTTP
  • Elenco di bozze IETF HTTP / 1.1 e HTTP / 2.0
• Evento inviato dal server :
  • Raccomandazione del candidato W3C Server Send Events / EventSource
  • Bozze eventi / eventi del server inviati da W3C
• WebSocket :
  • Protocollo IETF RFC 6455 WebSocket
  • Errata IETF RFC 6455 WebSocket
• SPDY :
  • Bozza IETF SPDY
• HTTP 2.0 :
  • Bozza IETF HTTP 2.0 httpbis-http2
  • Draft IETF HTTP 2.0 httpbis-speed-mobility
  • Bozza IETF httpbis-network-friendly - una vecchia proposta relativa a HTTP 2.0
• WebRTC :
  • Bozza dell'API WebRTC del W3C
  • Elenco dei progetti IETF WebRTC
  • Bozza della panoramica di IETF WebRTC
  • Bozza di IETF WebRTC DataChannel
  • Pagina iniziale della proposta Microsoft CU-WebRTC
• QUIC :
  • Progetto QUIC Chrominum
  • Bozza IETF QUIC

Sembra supporre che WebSocket sia un sostituto di HTTP. Non è. È un'estensione.

Il principale caso d'uso di WebSocket sono applicazioni Javascript che vengono eseguite nel browser Web e ricevono dati in tempo reale da un server. I giochi sono un buon esempio.

Prima di WebSocket, l'unico metodo per le applicazioni Javascript di interagire con un server era attraverso XmlHttpRequest. Ma questi hanno uno svantaggio principale: il server non può inviare dati a meno che il client non lo abbia esplicitamente richiesto.

Ma la nuova funzionalità WebSocket consente al server di inviare dati ogni volta che lo desidera. Ciò consente di implementare giochi basati su browser con una latenza molto più bassa e senza dover usare brutti hack come AJAX a polling lungo o plugin del browser.

Quindi perché non utilizzare il normale HTTP con richieste e risposte in streaming

In un commento a un'altra risposta, hai suggerito di eseguire lo streaming asincrono della richiesta client e del corpo della risposta.

In effetti, i WebSocket sono fondamentalmente quello. Un tentativo di aprire una connessione WebSocket dal client sembra inizialmente una richiesta HTTP, ma una direttiva speciale nell'intestazione (Upgrade: websocket) dice al server di iniziare a comunicare in questa modalità asincrona. Le prime bozze del protocollo WebSocket non erano molto più di questo e alcuni handshaking per garantire che il server comprendesse effettivamente che il client voleva comunicare in modo asincrono. Ma poi si è capito che i server proxy sarebbero stati confusi da questo, perché sono abituati al solito modello di richiesta / risposta di HTTP. È stato scoperto un potenziale scenario di attacco contro i server proxy. Per evitare ciò, era necessario rendere il traffico WebSocket diverso da qualsiasi normale traffico HTTP. Ecco perché sono state introdotte le chiavi di mascheramentola versione finale del protocollo .

Un'API REST regolare utilizza HTTP come protocollo sottostante per la comunicazione, che segue il paradigma di richiesta e risposta, il che significa che la comunicazione coinvolge il client che richiede alcuni dati o risorse da un server e il server risponde a quel client. Tuttavia, HTTP è un protocollo senza stato, quindi ogni ciclo di richiesta-risposta finirà per dover ripetere le informazioni di intestazione e metadati. Ciò comporta latenza aggiuntiva in caso di cicli di richiesta-risposta ripetuti frequentemente.

Con WebSocket, sebbene la comunicazione inizi ancora come stretta di mano HTTP iniziale, si tratta di ulteriori aggiornamenti per seguire il protocollo WebSockets (ovvero se sia il server che il client sono conformi al protocollo poiché non tutte le entità supportano il protocollo WebSocket).

Ora con WebSocket, è possibile stabilire una connessione full duplex e permanente tra il client e un server. Ciò significa che a differenza di una richiesta e una risposta, la connessione rimane aperta fino a quando l'applicazione è in esecuzione (ovvero è persistente) e, poiché è full duplex, è possibile una comunicazione simultanea bidirezionale, cioè ora il server è in grado di avviare una comunicazione e "spingere" alcuni dati al client quando diventano disponibili nuovi dati (a cui il cliente è interessato).

Il protocollo WebSocket è stateful e consente di implementare il modello di messaggistica Publish-Subscription (o Pub / Sub) che è il concetto principale utilizzato nelle tecnologie in tempo reale in cui è possibile ottenere nuovi aggiornamenti sotto forma di push del server senza il il cliente deve richiedere (aggiornare la pagina) più volte. Esempi di tali applicazioni sono il monitoraggio della posizione di Uber car, le notifiche push, l'aggiornamento dei prezzi di borsa in tempo reale, chat, giochi multiplayer, strumenti di collaborazione online in diretta, ecc.

Puoi consultare un articolo di approfondimento su Websocket che spiega la storia di questo protocollo, come è nato, a cosa serve e come puoi implementarlo da solo.

Ecco un video di una presentazione che ho fatto su WebSocket e su come sono diversi dall'uso delle normali API REST: standardizzazione e sfruttamento dell'aumento esponenziale dello streaming di dati

Per TL; DR, ecco 2 centesimi e una versione più semplice per le tue domande:

1. WebSocket offre questi vantaggi su HTTP:

   • Connessione con stato permanente per tutta la durata della connessione
   • Bassa latenza: comunicazione quasi in tempo reale tra server / client a causa del sovraccarico di ristabilire le connessioni per ogni richiesta come richiede HTTP.
   • Full duplex: sia il server che il client possono inviare / ricevere contemporaneamente

2. WebSocket e protocollo HTTP sono stati progettati per risolvere diversi problemi, IE WebSocket è stato progettato per migliorare la comunicazione bidirezionale mentre HTTP è stato progettato per essere senza stato, distribuito utilizzando un modello di richiesta / risposta. A parte la condivisione delle porte per motivi legacy (penetrazione di firewall / proxy), non esiste un terreno comune per combinarle in un protocollo.

Perché il protocollo WebSocket è migliore?

Non penso che possiamo confrontarli fianco a fianco come chi è il migliore. Non sarà un confronto equo semplicemente perché stanno risolvendo due diversi problemi . I loro requisiti sono diversi. Sarà come confrontare le mele con le arance. Sono diversi.

HTTP è un protocollo di richiesta-risposta. Il client (browser) vuole qualcosa, il server lo dà. Questo è. Se il client di dati desidera è di grandi dimensioni, il server potrebbe inviare dati di streaming per annullare problemi di buffer indesiderati. Qui il requisito o il problema principale è come fare la richiesta dai clienti e come rispondere alle risorse (hybertext) che richiedono. È qui che brillano HTTP.

In HTTP, solo richiesta client. Il server risponde solo.

WebSocket non è un protocollo di richiesta-risposta in cui solo il client può richiedere. È un socket (molto simile al socket TCP). Significa che una volta aperta la connessione, entrambe le parti possono inviare i dati fino alla chiusura della connessione TCP sottolineata. È proprio come un normale socket. L'unica differenza con il socket TCP è che websocket può essere utilizzato nel web. Nel web, abbiamo molte restrizioni per un socket normale. La maggior parte dei firewall bloccherà altre porte diverse da 80 e 433 utilizzate da HTTP. Anche i proxy e gli intermediari saranno problematici, quindi per rendere il protocollo più facile da implementare nelle infrastrutture esistenti, il websocket utilizza l'handshake HTTP per l'aggiornamento. Ciò significa che quando si aprirà la prima connessione, il client invierà una richiesta HTTP per dire al server "Questa non è una richiesta HTTP, si prega di aggiornare al protocollo websocket".

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Una volta che il server ha compreso la richiesta e aggiornato al protocollo websocket, nessuno del protocollo HTTP è stato più applicato.

Quindi la mia risposta è che nessuno dei due è migliore dell'altro. Sono completamente diversi.

Perché è stato implementato invece di aggiornare il protocollo http?

Bene, possiamo anche fare tutto con il nome HTTP . Ma dovremmo? Se sono due cose diverse, preferirò due nomi diversi. Così fanno Hickson e Michael Carter .

Le altre risposte non sembrano toccare un aspetto chiave qui, e cioè non fai menzione della necessità di supportare un browser web come client. La maggior parte delle limitazioni del semplice HTTP di cui sopra presuppongono che si debba lavorare con le implementazioni del browser / JS.

Il protocollo HTTP è pienamente in grado di comunicare full duplex; è legale che un client esegua un POST con trasferimento di codifica in blocchi e un server per restituire una risposta con un corpo di codifica in blocchi. Ciò eliminerebbe l'overhead dell'intestazione solo al momento dell'inizializzazione.

Quindi, se tutto ciò che stai cercando è full-duplex, controlla sia il client che il server e non sei interessato a ulteriori frame / funzionalità dei websocket, allora direi che HTTP è un approccio più semplice con latenza / CPU inferiori (sebbene la latenza differirebbe davvero solo in microsecondi o meno per entrambi).