Http is stateless protocol and Keepalive option

HTTP is a a stateless protocol; to simply put it we send request to web server, server responds back and forgets. ie the connection is closed after the request/response pair. All future request are new requests for the server, which means that the underlying TCP connection is established with every request.

This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests.

Ref : http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Refer to "How HTTP Protocal Work" for additional information

Keep Alive

=======

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.
Not reliable

HTTP is a stateless protocol - this means that every request is independent of every other. Keep alive doesn’t change that. Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that the connection is being closed. So keepalive is something you should not write your application to rely upon.



Reference Links

http://en.wikipedia.org/wiki/HTTP_persistent_connection

http://www.prismnet.com/~maus/HttpKeepAlive.html

http://bpraveen.wordpress.com/2010/05/31/http-keep-alive-option-in-iis/



Additional Points

How HTTP Protocal Work
======================
http://computer.howstuffworks.com/web-server.htm
http://www.tutorialspoint.com/http/what_is_http.htm

Get vs Post

So, when should one method be used instead of the other? Well, the POST method is used to submit data from a form that should be sent in only once, such as signing up for a newsletter or entering address information. The GET method is useful for storing data in the URL so that after submitting the data, someone could bookmark the resulting URL and return to it later, saving all the settings. In fact, it's possible to combine both methods in one form:
POST data is sent in the page body
When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method
As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL and POST should be used.
reference : http://www.cs.tut.fi/~jkorpela/forms/methods.html