Relation between HTTP Keep Alive duration and TCP timeout duration

Question

I am trying to understand the relation between TCP/IP and HTTP timeout values. Are these two timeout values different or same? Most Web servers allow users to set the HTTP K

Answer 1

They're two separate mechanisms; the name is a coincidence.

HTTP keep-alive (also known as persistent connections) is keeping the TCP socket open so that another request can be made without setting up a new connection.

TCP keep-alive is a periodic check to make sure that the connection is still up and functioning. It's often used to assure that a NAT box (e.g., a DSL router) doesn't "forget" the mapping between an internal and external ip/port.

Answer 2

KeepAliveTimeout Directive

Description: Amount of time the server will wait for subsequent requests on a persistent connection Syntax: KeepAliveTimeout seconds Default: KeepAliveTimeout 15 Context: server config, virtual host Status: Core Module: core The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the Timeout directive applies.

Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.

In a name-based virtual host context, the value of the first defined virtual host (the default host) in a set of NameVirtualHost will be used. The other values will be ignored.

TimeOut Directive

Description: Amount of time the server will wait for certain events before failing a request Syntax: TimeOut seconds Default: TimeOut 300 Context: server config, virtual host Status: Core Module: core The TimeOut directive currently defines the amount of time Apache will wait for three things:

The total amount of time it takes to receive a GET request. The amount of time between receipt of TCP packets on a POST or PUT request. The amount of time between ACKs on transmissions of TCP packets in responses. We plan on making these separately configurable at some point down the road. The timer used to default to 1200 before 1.2, but has been lowered to 300 which is still far more than necessary in most situations. It is not set any lower by default because there may still be odd places in the code where the timer is not reset when a packet is sent.

Answer 3

An open TCP socket does not require any communication whatsoever between the two parties (let's call them Alice and Bob) unless actual data is being sent. If Alice has received acknowledgments for all the data she's sent to Bob, there's no way she can distinguish among the following cases:

1. Bob has been unplugged, or is otherwise inaccessible to Alice.
2. Bob has been rebooted, or otherwise forgotten about the open TCP socket he'd established with Alice.
3. Bob is connected to Alice, and knows he has an open connection, but doesn't have anything he wants to say.

If Alice hasn't heard from Bob in awhile and wants to distinguish among the above conditions, she can resend her last byte of data, wrapped in a suitable TCP frame to be recognizable as a retransmission, essentially pretending she hasn't heard the acknowledgment. If Bob is unplugged, she'll hear nothing back, even if she repeatedly sends the packet over a period of many seconds. If Bob has rebooted or forgotten the connection, he will immediately respond saying the connection is invalid. If Bob is happy with the connection and simply has nothing to say, he'll respond with an acknowledgment of the retransmission.

The Timeout indicates how long Alice is willing to wait for a response when she sends a packet which demands a reply. The Keepalive time indicates how much time she should allow to lapse before she retransmits her last bit of data and demands an acknowledgment. If Bob goes missing, the sum of the Keepalive and Timeout values will indicate the worst-case time between Alice receiving her last bit of data and her deciding that Bob is dead.