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?

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.

Nginx supporta keep-alive su entrambi i lati.

• lato client: http://nginx.org/r/keepalive_timeout
• lato backend: http://nginx.org/r/keepalive