# Keep Alive Questions

## dman777

I have a few questions about the keep alive process in detail for keeing a tcp connection on going.

When a client browser sets a keep alive value that is different than a servers keep alive value, which one trumps the other?

What exactly does a keep alive request do and why does the browser send more than 1 during a session?

If the server has a keep alive period of 300 seconds, why would the browser send a keep alive request if it has already been allotted 300 seconds for that tcp connection?

When a web client requests an object such as a css sheet, does that count as a keep alive request?

----------

## Veldrin

 *Quote:*   

> What exactly does a keep alive request do and why does the browser send more than 1 during a session? 

  It basically sends some tcp data, in order to reset the tcp timeout timer. he amount of tcp keep alives sent depends on the session length and how long the session is idle (no tcp data sent).

In addition, there may be some intermediaries (e.g. firewall) which have a different tcp timeout for some reason (congestion), which forces the end-2-end connection to generate some traffic to keep the connection up.

 *Quote:*   

> If the server has a keep alive period of 300 seconds, why would the browser send a keep alive request if it has already been allotted 300 seconds for that tcp connection? 

  and what if your session is 900 seconds? In that case your browser has to make sure that the session stays open. 

 *Quote:*   

> When a web client requests an object such as a css sheet, does that count as a keep alive request?

  Yes, it does reset the tcp timeout, but it is not a tcp keep alive per se, as a request has been made on layer 7, not on layer 4 (tcp)

I am not sure about he first question, but from a logical point of view, the lower one has to win.

HTH

V.

----------

## AngelKnight

It's worth being careful about this, because with browsers (as in web browsers, or "user agents" as per the HTTP standard) there's an HTTP keepalive mechanism as well.

How it works is:

The connecting client (or "user agent") sends an HTTP/1.1 request that includes a request header "Connection:".  It's usually allowed two values, one of ('keepalive', 'close').  This constitutes a keepalive request on the part of the user agent.

When the HTTP server receives the request, it can elect to refuse a keepalive request, by sending its response including a "Connection: close" header, which signals the client that the server intends to send just one HTTP response on this TCP session, then close it right away.

Or, the HTTP server can decide to send "Connection: keepalive" in the response header, indicating that it chooses to keep the TCP session open with the client in case the client wishes to reuse the session to send another request.

However, the server doesn't indicate how long it intends to keep the session open.  It also has the option to close it at any time.  Compliant HTTP user agents have to deal with this.

----------

