HTTP: quali sono le relazioni tra pipelining, keep-alive e Server Sent Events?

Question

Sto cercando di capire quali sono la pipeline HTTP e le connessioni keep-alive HTTP e stiamo cercando di stabilire una connessione tra questi due argomenti e la tecnologia degli eventi Server Sent.

Per quanto ho capito, HTTP keep-alive collegamento è il default in HTTP 1.1 modo di usare il protocollo TCP quando la stabilita una volta connessione TCP viene utilizzato per l'invio di diverse richieste HTTP uno per uno. Il pipelining HTTP è la capacità del client di inviare richieste al server mentre le risposte a richieste precedenti non sono state ancora ricevute utilizzando la stessa connessione TCP, generalmente non utilizzata come impostazione predefinita nei browser.

Le mie domande:

1) se è possibile inviare diverse richieste al server uno dopo l'altro utilizzando una connessione TCP - come il client in grado di distinguere tra le risposte? Suppongo che il client stia utilizzando l'ordine FIFO di invio delle risposte dal server?

2) Perché le richieste non identi che come le richieste POST non devono essere pipeline (secondo wikipedia)?

3) Quali sono i limiti del server Web: il numero di connessioni TCP aperte possibili è limitato? Se sì, allora se un certo numero di client ha connessioni keep-alive, altri non possono stabilire connessioni e questo può causare un problema, giusto?

4) Gli eventi inviati dal server utilizzano la connessione keep-alive ma, per quanto ho capito, SSE non utilizza il pipelining. Invece riescono a elaborare diverse risposte a una richiesta, oppure potrebbero semplicemente inviare un'altra richiesta quando è arrivata la risposta successiva con l'evento. Quale ipotesi è corretta?

5) Una connessione TCP significa una presa? Un socket significa una connessione TCP? Presa di chiusura/apertura significa chiusura/apertura della connessione TCP?

Answer 1

1. Sì, FIFO. TCP/IP garantisce la consegna dei dati in ordine, quindi le risposte non possono arrivare in un ordine diverso (se il server/proxy è bacato e invia le risposte in un ordine errato, allora sei completamente fregato).

2. Non ricordo alcun motivo per specifica HTTP. Potrebbe essere solo cautela, perché il pipelining è scarsamente implementato in alcuni proxy/server.

3. Le specifiche HTTP indicano 2 connessioni per server, i browser si sono stabiliti su 6-8 connessioni per server, ma non esiste un limite fisso. L'esaurimento delle connessioni è un problema reale per Apache e in situazioni di carico elevato è consigliabile disabilitare KeepAlive in Apache e utilizzare un proxy (ad esempio HAProxy) che possa fornire a basso costo funzionalità Keep-alive ai client.
   Il vantaggio di un proxy è che un proxy può distribuire connessioni a diversi server (aiuta il ridimensionamento) o può modificare il traffico (ad esempio, gzip comprime tutto anche se il software lato server non lo ha fatto).

4. SSE non si basa su Keep-Alive. Non sta usando più risposte. È una singola risposta che richiede sempre un "download", quindi il pipelining o keep-alive sono irrilevanti per SSE. La connessione TCP/IP non può restituire più risposte mentre viene inviata la risposta SSE.
   SSE manterrà il server occupato fino a quando la connessione è aperta (in modo tipografico tutto il tempo per ogni utente). Ecco perché è meglio utilizzare SSE con Node.js/Tornado in grado di gestire centinaia di migliaia di connessioni anziché PHP/Apache progettato per poche connessioni alla volta.

5. I socket sono un'interfaccia di programmazione per connessioni TCP/IP. Generalmente sì, un socket è una connessione.