Connessione persistente HTTP - HTTP persistent connection

Da Wikipedia, l'enciclopedia libera

La connessione HTTP persistente , chiamata anche HTTP keep-alive o HTTP connection reuse , è l'idea di utilizzare una singola connessione TCP per inviare e ricevere più richieste / risposte HTTP , invece di aprire una nuova connessione per ogni singola coppia richiesta / risposta. Il protocollo HTTP / 2 più recente utilizza la stessa idea e la porta oltre per consentire il multiplexing di più richieste / risposte simultanee su una singola connessione.

Operazione

HTTP 1.0

Sotto HTTP 1.0, le connessioni non sono considerate persistenti a meno che non sia inclusa un'intestazione keep-alive, sebbene non ci siano specifiche ufficiali su come funziona keepalive. In sostanza, è stato aggiunto a un protocollo esistente. Se il client supporta keep-alive, aggiunge un'intestazione aggiuntiva alla richiesta:

Connection: keep-alive

Quindi, quando il server riceve questa richiesta e genera una risposta, aggiunge anche un'intestazione alla risposta:

Connection: keep-alive

Successivamente, la connessione non viene interrotta, ma viene invece mantenuta aperta. Quando il client invia un'altra richiesta, utilizza la stessa connessione. Ciò continuerà fino a quando il client o il server non deciderà che la conversazione è terminata e uno di loro interrompe la connessione.

HTTP 1.1

In HTTP 1.1, tutte le connessioni sono considerate persistenti se non diversamente dichiarato. Le connessioni persistenti HTTP non utilizzano messaggi keepalive separati, consentono solo a più richieste di utilizzare una singola connessione. Tuttavia, il timeout di connessione predefinito di Apache httpd 1.3 e 2.0 è di appena 15 secondi e di soli 5 secondi per Apache httpd 2.2 e versioni successive. Il vantaggio di un timeout breve è la capacità di fornire più componenti di una pagina Web rapidamente senza consumare risorse per eseguire più processi o thread del server per troppo tempo.

Keepalive con codifica di trasferimento in blocchi

Keepalive rende difficile per il client determinare dove finisce una risposta e inizia la risposta successiva, in particolare durante l'operazione HTTP pipeline. Questo è un problema serio quando Content-Length non può essere utilizzato a causa dello streaming. Per risolvere questo problema, HTTP 1.1 ha introdotto una codifica di trasferimento in blocchi che definisce un last-chunk bit. Il last-chunk bit viene impostato alla fine di ogni risposta in modo che il client sappia dove inizia la risposta successiva.

Vantaggi

Secondo RFC 7230, sezione 6.4 , "un client dovrebbe limitare il numero di connessioni aperte simultanee che mantiene a un dato server". La versione precedente della specifica HTTP / 1.1 dichiarava valori massimi specifici ma secondo le parole dell'RFC 7230 "questo è stato ritenuto poco pratico per molte applicazioni ... invece ... sii prudente quando si aprono più connessioni". Queste linee guida hanno lo scopo di migliorare i tempi di risposta HTTP ed evitare la congestione. Se il pipeline HTTP è implementato correttamente, non si ottengono vantaggi in termini di prestazioni da connessioni aggiuntive, mentre connessioni aggiuntive possono causare problemi di congestione.

Svantaggi

Se il client non chiude la connessione quando tutti i dati necessari sono stati ricevuti, le risorse necessarie per mantenere la connessione aperta sul server non saranno disponibili per gli altri client. Quanto questo influisce sulla disponibilità del server e per quanto tempo le risorse non sono disponibili dipendono dall'architettura e dalla configurazione del server.

Inoltre può verificarsi una condizione di competizione in cui il client invia una richiesta al server nello stesso momento in cui il server chiude la connessione TCP. Un server dovrebbe inviare un codice di stato 408 Timeout richiesta al client immediatamente prima di chiudere la connessione. Quando un client riceve il codice di stato 408, dopo aver inviato la richiesta, può aprire una nuova connessione al server e inviare nuovamente la richiesta. Non tutti i client rispediranno la richiesta e molti lo faranno solo se la richiesta ha un metodo HTTP idempotente .

Utilizzare nei browser web

Schema di connessione multipla e persistente.

Tutti i browser Web moderni, inclusi Google Chrome , Firefox , Internet Explorer (dalla 4.01), Opera (dalla 4.0) e Safari, utilizzano connessioni persistenti.

Per impostazione predefinita, le versioni 6 e 7 di Internet Explorer utilizzano due connessioni permanenti mentre la versione 8 ne utilizza sei. Le connessioni persistenti scadono dopo 60 secondi di inattività, modificabile tramite il registro di Windows.

In Firefox , il numero di connessioni simultanee può essere personalizzato (per server, per proxy, totale). Le connessioni persistenti scadono dopo 115 secondi (1,92 minuti) di inattività, modificabile tramite la configurazione.

Guarda anche

  • Pipelining HTTP , in base al quale è possibile inviare più richieste senza attendere una risposta
  • HTTP / 2 , che consente il pipelining fuori ordine di richieste e risposte e anche il push predittivo del contenuto prima che sia stato richiesto

Riferimenti

link esterno