Protocollo WebSockets vs HTTP

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

per esempio (argomenti degli amanti di websocket):

HTML5 Web Sockets 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: richiede lo streaming del corpo (lo stai usando mentre carichi file di grandi dimensioni) e lo streaming del corpo della risposta.

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

Perché questi 2 byte non includono il sovraccarico di tcp e sotto i protocolli TCP?

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

Questa è l’intestazione http ~ 48 byte.

codifica http chunked – http://ru.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, l’overhead per ogni chunk non è grande.

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

Domanda:

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

1) Perché il protocollo WebSockets è migliore?

WebSockets è migliore per le situazioni che implicano comunicazioni a bassa latenza, specialmente per bassa latenza, per messaggi client-server. Per i dati da server a client, è ansible ottenere una latenza piuttosto bassa utilizzando connessioni di lunga durata e trasferimento chunked. Tuttavia, questo non aiuta con la latenza tra client e server che richiede una nuova connessione da stabilire per ogni messaggio client-server.

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

Richiesta di esempio (2800 byte compresi i dati dei cookie, 490 byte senza dati dei 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 

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

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

Ci sono degli sforzi per riprogettare il protocollo HTTP per ottenere prestazioni migliori e bassa latenza come SPDY , HTTP 2.0 e QUIC . Ciò migliorerà la situazione per le normali richieste HTTP, ma è probabile che WebSockets e / o WebRTC DataChannel abbiano 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 WebSockets in ogni modo).

Aggiornamento :

Ecco un quadro per pensare ai protocolli web:

  • TCP : livello basso, bidirezionale, full-duplex e garantito per il trasporto degli ordini. Nessun supporto browser (tranne tramite plugin / 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 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 (OPZIONI, 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 implementato, quindi questo limita enormemente l’utilità di HTTP 1.1 per risolvere la latenza tra browser e server.
  • Long-poll : una sorta di “hack” per 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 tipo MIME text/event-stream . L’API del browser (che è abbastanza simile all’API WebSocket) è chiamata API EventSource.
  • Comet / server push : questo è un termine generico che include sia lo streaming long-poll che HTTP. Le librerie di Comet di solito supportano più tecniche per cercare di massimizzare il supporto cross-browser e cross-server.
  • WebSockets : un TCP integrato di trasporto che utilizza un handshake di aggiornamento HTTP. A differenza del TCP, che è un trasporto di streaming, WebSockets è un trasporto basato su messaggi: i messaggi sono delimitati sul filo e vengono riassemblati completamente prima della consegna all’applicazione. Le connessioni WebSocket sono bidirezionali, full-duplex e longevi. Dopo la richiesta / risposta iniziale di handshake, non vi è alcuna semantica transazionale e c’è pochissimo overhead del messaggio. 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 framing (con frame con prefisso di lunghezza) e specifica un modo per sovrapporre coppie di richiesta / risposta HTTP sul nuovo livello di framing. Le intestazioni possono essere compresse e nuove intestazioni possono essere inviate dopo aver stabilito la connessione. Esistono implementazioni del mondo reale di SPDY in browser e server.
  • HTTP 2.0 : ha obiettivi simili a SPDY: riduce la latenza e l’overhead HTTP preservando la semantica HTTP. La bozza attuale deriva da SPDY e definisce un handshake di aggiornamento e un frame dei dati molto simile allo standard WebSocket per l’handshake e il framing. Una proposta di bozza HTTP 2.0 alternativa (httpbis-speed-mobility) utilizza effettivamente WebSockets per il livello di trasporto e aggiunge il multiplexing SPDY e il mapping HTTP come un’estensione WebSocket (le estensioni WebSocket sono negoziate durante l’handshake).
  • WebRTC / CU-WebRTC : proposte per consentire la connettività peer-to-peer tra browser. Ciò potrebbe consentire una comunicazione di latenza media e massima inferiore poiché il trasporto sottostante è SDP / datagramma anziché TCP. Ciò consente la consegna fuori ordine di pacchetti / messaggi che evita il problema TCP dei picchi di latenza causati da pacchetti interrotti 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. In superficie, QUIC è molto simile a TCP + TLS + SPDY implementato su UDP. QUIC fornisce multiplexing e controllo di stream equivalenti a HTTP / 2, sicurezza equivalente a TLS e semantica della connessione, affidabilità e controllo della congestione equivalenti a TCP. Poiché il protocollo TCP è implementato nei kernel del sistema operativo e nel firmware di middlebox, è quasi imansible apportare modifiche significative al protocollo TCP. Tuttavia, poiché QUIC è costruito su UDP, non presenta tali limiti. QUIC è progettato e ottimizzato per la semantica HTTP / 2.

Riferimenti :

  • HTTP :
    • Pagina HTTP di Wikipedia
    • W3C Elenco di bozze / protocolli relativi a HTTP
    • Elenco di Bozze IETF HTTP / 1.1 e HTTP / 2.0
  • Evento inviato dal server :
    • Raccomandazione W3C Server-Sent Events / EventSource Candidate
    • W3C Server-Sent Events / EventSource Draft
  • WebSocket :
    • Protocollo WebSockets IETF RFC 6455
    • Errata WebSocket IETF RFC 6455
  • SPDY :
    • Draft IETF SPDY
  • HTTP 2.0 :
    • IETF HTTP 2.0 httpbis-http2 Draft
    • Draft HTTPbis-speed-mobility HTTP 2.0 IETF
    • Draft IETF httpbis-network-friendly – una proposta più recente relativa a HTTP 2.0
  • WebRTC :
    • Bozza API W3C WebRTC
    • Elenco di Bozze WebRTC IETF
    • Bozza di panoramica IETF WebRTC
    • IETF WebRTC DataChannel Draft
    • Pagina iniziale della proposta di Microsoft CU-WebRTC
  • QUIC :
    • QUIC Chrominum Project
    • Draft IETF QUIC

Sembra che tu pensi che WebSocket sia una sostituzione per HTTP. Non è. È un’estensione.

Il caso d’uso principale di WebSockets sono le 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 WebSockets, l’unico metodo con cui le applicazioni Javascript interagivano con un server era attraverso XmlHttpRequest . Ma questi hanno un grande svantaggio: il server non può inviare dati se il client non lo ha richiesto esplicitamente.

Ma la nuova funzionalità WebSocket consente al server di inviare dati quando lo desidera. Ciò consente di implementare giochi basati su browser con una latenza molto inferiore e senza dover utilizzare brutti hack come i plug-in AJAX long-polling o browser.

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

In un commento ad un’altra risposta hai suggerito di trasmettere in streaming in modo asincrono la richiesta del client e il corpo della risposta.

In realtà, 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 (Aggiornamento: websocket) indica al server di iniziare a comunicare in questa modalità asincrona. Le prime bozze del protocollo WebSocket non erano molto più di questo e qualche handshaking per garantire che il server capisse che il client desidera comunicare in modo asincrono. Ma poi si è realizzato 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ò è stato necessario rendere il traffico WebSocket diverso da qualsiasi normale traffico HTTP. Ecco perché le chiavi di mascheratura sono state introdotte nella versione finale del protocollo .

Per il TL; DR, qui ci sono 2 centesimi e una versione più semplice per le tue domande:

  1. WebSockets offre questi vantaggi su HTTP:

    • Connessione stateful persistente per la durata della connessione
    • Bassa latenza: in prossimità della comunicazione in tempo reale tra server / client, a causa dell’assenza di costi aggiuntivi per il ripristino delle connessioni per ogni richiesta, come richiesto da HTTP.
    • Full duplex: sia il server che il client possono inviare / ricevere simultaneamente
  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. Oltre alla condivisione delle porte per motivi legacy (penetrazione firewall / proxy), non c’è molto terreno comune per combinarle in un unico protocollo.

Perché il protocollo Websockets è migliore?

Non penso che possiamo confrontarli fianco a fianco come chi è meglio. Questo non sarà un confronto equo semplicemente perché stanno risolvendo due problemi diversi . Le loro esigenze sono diverse. Sarà come paragonare le mele alle arance. Sono diversi.

HTTP è un protocollo richiesta-risposta. Il client (browser) vuole qualcosa, il server lo dà. Questo è. Se il client di dati desiderato è grande, il server potrebbe inviare dati in streaming per invalidare i problemi di buffer indesiderati. Qui il principale requisito o problema è come effettuare la richiesta dai client e come rispondere alle risorse (hybertext) che richiedono. È qui che l’HTTP splende.

In HTTP, solo la richiesta del cliente. Il server risponde solo

WebSocket non è un protocollo di richiesta-risposta in cui solo il cliente può richiedere. È un socket (molto simile al socket TCP). Significa che una volta aperta la connessione, entrambi i lati possono inviare dati fino a quando non viene chiusa la connessione TCP. È proprio come una presa normale. 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 oltre 80 e 433 utilizzate da HTTP. Anche proxy e intermediari saranno problematici. Per rendere il protocollo più facile da implementare su infrastrutture esistenti, websocket utilizza l’handshake HTTP per l’aggiornamento. Ciò significa che quando la prima connessione si aprirà, il client ha inviato una richiesta HTTP per dire al server che dice “Quella non è richiesta HTTP, per favore aggiorna 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 dei protocolli HTTP è stato applicato più.

Quindi la mia risposta è Nessuno dei due è migliore l’uno dell’altro. Sono completamente diversi.

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

Bene possiamo fare tutto sotto il nome chiamato HTTP pure. 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 si fa cenno di richiedere il supporto di un browser web come client. La maggior parte delle limitazioni del semplice HTTP sopra riportato presuppone che si stia lavorando con le implementazioni di browser / JS.

Il protocollo HTTP è pienamente in grado di comunicare full-duplex; è legale che un client esegua un POST con trasferimento di codifica chunked e un server per restituire una risposta con un corpo con codifica chunked. Ciò rimuoverà l’overhead dell’header solo al momento dell’avvio.

Quindi, se tutto quello che stai cercando è full-duplex, controlla sia client che server, e non sei interessato a cornici / funzionalità extra di websocket, allora direi che l’HTTP è un approccio più semplice con latenza / CPU inferiore (anche se la latenza in realtà differirebbe in microsecondi o meno solo per entrambi).

Polling HTTP

Il polling HTTP è il processo di ricerca del server da parte del cliente in intervalli di tempo predefiniti per recuperare informazioni aggiornate se disponibili. Nel polling HTTP, il client invia una richiesta a un server. Quindi il server risponde con nuovi messaggi. Se non ci sono nuovi messaggi disponibili, il server risponde con un formato vuoto o prestabilito. Questo stream viene ripetuto dall’intervallo di polling configurato. Il polling HTTP genera un sovraccarico significativo della rete nel sistema in quanto richiede la ripetizione delle intestazioni in ogni richiesta.

Pertanto, il polling HTTP si comporta relativamente bene, se la frequenza di ricezione degli aggiornamenti è fissa. Se la frequenza di ricezione dell’aggiornamento è alta o la ricevuta dell’aggiornamento è casuale o non prevedibile, il polling HTTP può comportare un sovraccarico della comunicazione. Quindi, lo svantaggio principale del polling HTTP è l’invio di numerose richieste non necessarie al server anche se non ci sono nuovi aggiornamenti da recuperare.

Polling lungo HTTP

Il polling lungo HTTP è una variante della tecnica di polling definita per superare gli svantaggi sopra menzionati del sondaggio semplice. È definito per gestire in modo efficiente la trasmissione dei dati tra il server e il client. La differenza del polling lungo è che, non invia immediatamente una risposta vuota, quando non ci sono nuovi messaggi. Anziché, il server attende un nuovo messaggio per rispondere o la richiesta è scaduta. Ciò offre una soluzione più efficiente al polling, soprattutto quando nel sistema sono presenti meno nuovi messaggi, riducendo il numero di richieste dei client. Di nuovo, se i timeout delle connessioni appaiono oltre la risposta, il polling lungo HTTP non è molto vantaggioso. Di conseguenza, il polling lungo HTTP non ha risolto tutti gli svantaggi visualizzati dal polling HTTP.

WebSockets

Il protocollo WebSockets è stato introdotto come estensione, per migliorare la comunicazione client-server con diverse aggiunte di valore. In tempo reale lo scambio di dati, WebSockets funziona bene con meno spese generali di comunicazione, fornendo una comunicazione efficiente e di stato tra client e server. Il protocollo WebSockets consente di mantenere connessioni socket TCP a lungo termine tra client e server. Ancora più importante, i socket Web consentono di inviare i messaggi istantaneamente con un sovraccarico trascurabile al sistema, in tempo reale, bidirezionale e full duplex. WebSockets esibisce una caratteristica unica di attraversare firewall e proxy. È in grado di rilevare la presenza del server proxy e imposta automaticamente un tunnel per passare attraverso il proxy. Soprattutto i browser Web possono sfruttare il vantaggio della modalità full duplex per inviare dati in entrambe le direzioni contemporaneamente. Inoltre, i WebSocket forniscono una significativa riduzione della congestione della rete e dei costi generali rispetto a un normale sistema duplex che mantiene due connessioni con il polling, operando pensando a un singolo socket sul web.

Con le funzionalità avanzate del protocollo WebSockets, è spesso adatto a framework di applicazioni di rete per fornire maggiore coerenza, consentendo una scalabilità enorme su piattaforms in tempo reale. Inoltre, sta emergendo come un protocollo molto affidabile, altamente performante, in tempo reale, pronto e promettente per la comunicazione inter-nodo, rendendolo una metodologia affidabile per la gestione dei cluster.

Riferimenti http://www.devdummy.com/2017/12/http-polling-http-long-polling.html