HTTP 1.1's connection keep-alive feature allows the TCP
connection between a browser and a Web server to remain open
throughout multiple HTTP requests and responses. This
significantly improves the overall performance of
browser-server communication.

Http operates on what is called a request-response 
paradigm. This means that a _client_ generates a request 
for information, and passes it to the server, which answers 
it. In the original implementation of HTTP, each request 
created a new socket connection to the server, sent the 
request, then read from that connection to get the response.

This approach had one big advantage - it was simple. Simple 
to describe, simple to understand, and simple to code. It 
also had one big disadvantage - it was slow. So, keep-alive 
connections were invented for HTTP. 

HTTP/1.0
Under HTTP 1.0, there is no official specification for how 
keepalive operates. It was, in essence, tacked on to an 
existing protocol. If the browser supports keep-alive, it 
adds an additional header to the request: 

Connection: Keep-Alive

Then, when the server receives this request and generates a 
response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is 
instead kept open. When the client sends another request, 
it uses the same connection. This will continue until 
either the client or the server decides that the 
conversation is over, and one of them drops the connection.

HTTP/1.1
Under HTTP 1.1, the official keepalive method is different. 
All connections are kept alive, unless stated otherwise 
with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning 
because of this.

Additionally, an optional Keep-Alive: header is described, 
but is so underspecified as to be meaningless. Avoid it.