I proxy inversi HTTP in genere abilitano HTTP Keep-Alive sul lato client della connessione proxy e non sul lato server?


30

HAProxy ha la capacità di abilitare HTTP keep-alive sul lato client (client <-> HAProxy) ma disabilitarlo sul lato server (HAProxy <-> server).

Alcuni dei nostri clienti si collegano al nostro servizio web via satellite, quindi la latenza è ~ 600ms e penso che abilitando keep-alive, accelererà un po 'le cose. Ho ragione?

Questo è supportato da Nginx? È una funzionalità ampiamente implementata in altri bilanciatori del carico software e hardware? Cos'altro oltre a HAProxy?

Risposte:


43

modifica: la mia risposta copre solo la domanda inedita originale, ovvero se questo genere di cose è tipico nei bilanciatori di carico / proxy inversi. Non sono sicuro che nginx / product X abbia il supporto per questo, il 99,9% della mia esperienza di proxy inverso è con HAproxy.

Corretta. HTTP Keep-Alive sul lato client, ma non sul lato server.

Perché?

Se analizzi alcuni dettagli, puoi vedere rapidamente perché questo è un vantaggio. Per questo esempio, facciamo finta di caricare una pagina www.esempio.com e quella pagina include 3 immagini, img [1-3] .jpg.

Browser che carica una pagina, senza Keep-Alive

  1. Il client stabilisce una connessione TCP a www.example.com sulla porta 80
  2. Il client esegue una richiesta GET HTTP per "/"
  3. Il server invia il contenuto HTML dell'URI "/" (che include tag HTML che fanno riferimento alle 3 immagini)
  4. Il server chiude la connessione TCP
  5. Il client stabilisce una connessione TCP a www.example.com sulla porta 80
  6. Il client esegue una richiesta GET HTTP per "/img1.jpg"
  7. Il server invia l'immagine
  8. Il server chiude la connessione TCP
  9. Il client stabilisce una connessione TCP a www.example.com sulla porta 80
  10. Il client esegue una richiesta GET HTTP per "/img2.jpg"
  11. Il server invia l'immagine
  12. Il server chiude la connessione TCP
  13. Il client stabilisce una connessione TCP a www.example.com sulla porta 80
  14. Il client esegue una richiesta GET HTTP per "/img3.jpg"
  15. Il server invia l'immagine
  16. Il server chiude la connessione TCP

Si noti che ci sono 4 sessioni TCP separate stabilite e quindi chiuse.

Browser che carica una pagina, con Keep-Alive

HTTP Keep-Alive consente a una singola connessione TCP di servire più richieste HTTP, una dopo l'altra.

  1. Il client stabilisce una connessione TCP a www.example.com sulla porta 80
  2. Il client esegue una richiesta GET HTTP per "/" e chiede inoltre al server di rendere questa sessione HTTP Keep-Alive.
  3. Il server invia il contenuto HTML dell'URI "/" (che include tag HTML che fanno riferimento alle 3 immagini)
  4. Il server non chiude la connessione TCP
  5. Il client lo fa e la richiesta HTTP GET per "/img1.jpg"
  6. Il server invia l'immagine
  7. Il client lo fa e la richiesta HTTP GET per "/img2.jpg"
  8. Il server invia l'immagine
  9. Il client lo fa e la richiesta HTTP GET per "/img3.jpg"
  10. Il server invia l'immagine
  11. Il server chiude la connessione TCP se non vengono più ricevute richieste HTTP durante il periodo di timeout HTTP Keep-Alive

Notare che con Keep-Alive viene stabilita e alla fine chiusa solo 1 connessione TCP.

Perché Keep-Alive è meglio?

Per rispondere a questo è necessario capire cosa serve per stabilire una connessione TCP tra un client e un server. Questo si chiama stretta di mano a 3 vie TCP.

  1. Il client invia un pacchetto SYN (chronise)
  2. Il server restituisce un ACK (cronaca) SYN (ora), SYN-ACK
  3. Il client invia un pacchetto ACK (nowledgement)
  4. La connessione TCP è ora considerata attiva sia dal client che dal server

Le reti hanno latenza, quindi ogni passaggio dell'handshake a 3 vie richiede un certo tempo. Diciamo che ci sono 30ms tra client e server, l'invio avanti e indietro di pacchetti IP richiesti per stabilire la connessione TCP significa che ci vogliono 3 x 30ms = 90ms per stabilire una connessione TCP.

Questo potrebbe non sembrare molto, ma se consideriamo che nel nostro esempio originale, dobbiamo stabilire 4 connessioni TCP separate, questo diventa 360ms. Cosa succede se la latenza tra client e server è 100ms anziché 30ms? Quindi le nostre 4 connessioni impiegano 1200 ms per stabilire.

Ancora peggio, una tipica pagina web potrebbe richiedere molto più di 3 semplici immagini per essere caricata, potrebbero esserci più CSS, JavaScript, immagini o altri file che il client deve richiedere. Se la pagina carica altri 30 file e la latenza client-server è 100 ms, quanto tempo impieghiamo a stabilire connessioni TCP?

  1. Per stabilire 1 connessione TCP sono necessari 3 x latenza, ovvero 3 x 100 ms = 300 ms.
  2. Dobbiamo farlo 31 volte, una volta per la pagina e altre 30 volte per ogni altro file a cui fa riferimento la pagina. 31 x 300ms = 9,3 secondi.

9,3 secondi spesi per stabilire connessioni TCP per caricare una pagina Web che fa riferimento ad altri 30 file. E questo non conta nemmeno il tempo impiegato per inviare richieste HTTP e ricevere risposte.

Con HTTP Keep-Alive, è necessario stabilire solo 1 connessione TCP, che richiede 300 ms.

Se HTTP Keep-Alive è così eccezionale, perché non utilizzarlo anche sul lato server?

I proxy inversi HTTP (come HAproxy) sono in genere distribuiti molto vicino ai server back-end per i quali stanno eseguendo il proxy. Nella maggior parte dei casi la latenza tra il proxy inverso e i suoi server back-end sarà inferiore a 1 ms, quindi stabilire una connessione TCP è molto più veloce di quanto non sia tra un client.

Questa è solo la metà del motivo però. Un server HTTP alloca una certa quantità di memoria per ogni connessione client. Con Keep-Alive, manterrà attiva la connessione e, per estensione, manterrà una certa quantità di memoria in uso sul server, fino al raggiungimento del timeout Keep-Alive, che può essere fino a 15 secondi, a seconda della configurazione del server .

Quindi, se consideriamo gli effetti dell'utilizzo di Keep-Alive sul lato server di un proxy inverso HTTP, stiamo aumentando la necessità di memoria, ma poiché la latenza tra il proxy e il server è così bassa, non otteniamo alcun vantaggio reale dal riduzione del tempo impiegato per l'handshake a 3 vie di TCP, quindi in genere è meglio disabilitare Keep-Alive tra il proxy e il server Web in questo scenario.

Dichiarazione di non responsabilità: sì, questa spiegazione non tiene conto del fatto che i browser in genere stabiliscono più connessioni HTTP a un server in parallelo. Tuttavia, esiste un limite al numero di connessioni parallele che un browser stabilirà allo stesso host e in genere è ancora abbastanza piccolo da rendere desiderabile il mantenimento.


5
Complimenti per l'eccellente spiegazione Graeme, non ho mai trascorso abbastanza tempo per una risposta così lunga a chiunque mi chiedesse questo, e sicuramente terrò un link a questo post per servire come una risposta molto chiara ora :-)
Willy Tarreau

2
Ci sarebbe un vantaggio per keepAlive sul lato server se la connessione tra proxy e backend fosse https?
avmohan,

"Un server HTTP alloca una certa quantità di memoria per ogni connessione client" sì, ma ce ne saranno poche (?) Solo una per bilanciamento del carico? Non uno per client su Internet (?)
Raedwald

@Raedwald, se il tuo bilanciamento del carico si limita a stabilire una singola connessione HTTP a ciascun server di backup, avrai un brutto momento. :-)
ThatGraemeGuy

7

Nginx supporta keep-alive su entrambi i lati.


Diresti che keep alive è utile per i backend, se ci fosse latenza tra proxy e backend? Inoltre, cosa consentirebbe un numero ottimale di connessioni keep-alive?
CMCDragonkai,

@CMCDragonkai Se i tuoi back-end si trovano su server dedicati, può essere utile evitare la latenza della connessione che dipende dalla tua rete. Non esiste una media d'oro, il numero ottimale dipende principalmente dalla configurazione, dall'ambiente, dall'applicazione e dal modello di richiesta.
VBart

Spero di trovare un'equazione per risolvere questo!
CMCDragonkai,

2
La domanda, mentre l'ho letta, non sta chiedendo se nginx supporta keep-alive sul monte, ma se nginx supporti la disabilitazione di keep-alive sul lato monte.
user45793
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.