views:

216

answers:

3

"keep-alive" its there in HTTP. Some says it good should be used, but i am unable to get to any conclusion. So please provide your input/answer/views so i can get some ground for this,

  1. What it does?
  2. Scenario where it should and should not be done?
  3. How it can make AJAX application better ?
  4. Risks DO's and DONT's if any?

    Thank you all for inputs.

A: 
  1. It keeps the TCP socket to the client open, so you have not reestablish connection to send another HTTP request;
  2. Keep-alive improves http performance when there are many requests in a row. It should not been used however if the requests are rare (server normally closes connection if there are no more requests coming from a client during some period of time).
  3. Well, if your AJAX application sends a lot of requests to the server keep-alives improve its performance.
  4. There is a risk of sockets depletion on server side, so server has rights to interrupt even keep-alive connections.
Archie
+3  A: 

First off if your connection to the server is using HTTP/1.1 then you are most likely already using "keep-alive".

What is it? Logically HTTP is a connectionless protocol. That is each request/response to the server creates a new connection, does its business and drops the connection. However in HTTP/1.1 the default behaviour is to keep the connection open for use by subsequent requests to the server. The "keep-alive" header was added to HTTP/1.0 to allow this behaviour to be opted into, in HTTP/1.1 the server needs to opt-out by closing the connection itself and/or sending a "connection-close" header in response.

Why is it beneficial? Creating a connection especially one that needs to be authenticated can take some time. By re-using an existing connection the setup and authentication effort is much reduced.

How can it make your AJAX app better? You are probably already benefitting from it.

What are the risks? When making a connection through a shared appliance which may make a connection to the server in the clients behalf it is possible for other clients to re-use the connection, however that also makes it possible for other clients to use a connection that the server has authenticated for a different user.

AnthonyWJones
It "makes it possible for other clients to use a connection that the server has authenticated for a different user" -- I don't understand that one. HTTP is stateless, so whether multiple clients are using the same TCP connection surely doesn't matter?
Christopher
HTTP is "logically" stateless but a connection is not. In most cases the connection is anonymous and doesn't carry state of any significance. However authentication is often done at the connection level (for example NTLM on IIS) where once a connection has been established multiple requests will share the same authenticated state of the connection.
AnthonyWJones
A: 

Really it boils down to questions of performance and resource.

Using a high(er) keep alive reduces latency on requests. This is particularly an issue if you are running over SSL where there additional handshakes to establish a connection.

OTOH, this will mean that there additional server processes.threads sitting idle, waiting for a subsequent request or the keep-alive to expire. This can hog memory and therefore slow down your server.

So you really need to play around and see what's acceptable in terms in browser performance vs server load.

Authentication (basic/digest/session based) is not relevant - it is the request which is authenticated - not the socket connection.

Note that the last time I did a fresh Apache install it came with a default setting of 5 seconds for the keep alive. This is ridiculously long for a non-ajax site.

C.

symcbean