HTTP: what are the relations between pipelining, keep-alive and Server Sent Events?

Question

I am trying to understand what are the HTTP pipelining and HTTP keep-alive connections, and trying to establish a connection between these two topics and Server Sent events technology.

As far as I understand, HTTP keep-alive connection is the default in HTTP 1.1 way of using TCP when the established once TCP connection is used for sending several HTTP requests one by one. HTTP pipelining is the capability of client to send requests to server while responses to previous requests were not yet received using the same TCP connection, generally not used as a default way in browsers.

My questions:

1) if it is possible to send several requests to server one after one using one TCP connection - how the client can distinguish between the responses? I guess client is using FIFO order of sending responses by server?

2) Why non-idempotent requests such as POST requests shouldn't be pipelined (according to wikipedia)?

3) What about the limitations of the web-server: is the number of possible open TCP connections limited? If yes, then if some number of clients hold keep-alive connections others cannot establish connections, and this can result in a problem, right?

4) Server Sent Events are using the keep-alive connection but, as far as I understand, SSE are not using pipelining. Instead they manage to process several responses to one request, or may be they just send another request when the next response with event arrived. Which guess is correct?

5) One TCP connection means one socket? One socket means one TCP connection? Closing/opening socket means closing/opening TCP connection?

Calysta

Answer 1

1. Yes, FIFO. TCP/IP guarantees delivering data in-order, so responses can't arrive in a different order (if the server/proxy is buggy and sends responses in wrong order then you're totally screwed).

2. I don't recall any reason per HTTP spec. It may be just caution, because pipelining is poorly implemented in some proxies/servers.

3. HTTP spec suggests 2 connections per server, browsers have settled on 6-8 connections per server, but there is no fixed limit. Running out of connections is a real problem for Apache, and for high-load situations it's recommended to disable KeepAlive in Apache and use a proxy (e.g. HAProxy) that can cheaply provide Keep-Alive functionality to clients.
   The benefit of a proxy is that one proxy can distribute connections to several servers (helps scaling), or can modify the traffic (e.g. gzip compress everything even if server-side-software didn't).

4. SSE doesn't rely on Keep-Alive. It's not using multiple responses. It's a single response that takes forever to "download", so pipelining or keep-alive are irrelevant for SSE. The TCP/IP connection cannot return any more responses while SSE response is being sent.
   SSE will keep the server busy as long as the connection is open (so typicall all the time for every user). That's why it's best to use SSE with Node.js/Tornado that can handle hundreds of thousands connections rather than PHP/Apache that is designed for few connections at a time.

5. Sockets are programming interface for TCP/IP connections. Generally yes, one socket is one connection.

Seltzer

Thanks porneL! 1) But what if some response have arrived in wrong order relative to the sent order? 3) What is the benefit of using proxy? it has to establish the same connections with server anyway? 4) So using SSE implies +1 connection thus raising server loading? – Calysta

@Calysta I've expanded my answer – Seltzer