Relation between HTTP Keep Alive duration and TCP timeout duration

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 Keep Alive timeout value through some configuration. How is this value used by the Web servers? is this value just set on the underlying TCP/IP socket i.e is the HTTP Keep Alive timeout and TCP/IP Keep Alive Timeout same? or are they treated differently?

My understanding is (maybe incorrect): The Web server uses the default timeout on the underlying TCP socket (i.e. indefinite) regardless of the configured HTTP Keep Alive timeout and creates a Worker thread that counts down the specified HTTP timeout interval. When the Worker thread hits zero, it closes the connection.

EDIT: My question is about the relation or difference between the two timeout durations i.e. what will happen when HTTP keep-alive timeout duration and the timeout on the Socket (SO_TIMEOUT) which the Web server uses is different? should I even worry about these two being same or not?

HTTP Keep Alive and TCP keep alive

How is HTTP Keep Alive implemented? Does it internally use TCP Keep Alive? If not, how does the server detect if the client is dead or alive?

http keep-alive timeout on server

Does the Go server have an http keep-alive default timeout value? How do you set a custom keep-alive timeout? Is the server’s ReadTimeout related to the keep-alive timeout at all? or you need to set t

HTTP keep-alive timeout

Can I specify the HTTP timeout or does the server impose a value? For example, if I do: telnet 80 Trying X.X.X.X… Connected to Escape character is ‘^]’. GET /

Managing server’s HTTP keep-alive timeout with Netty

I am running an application server using the Play! Framework, which uses Netty for the actual IO heavy lifting. The HTTP connections have keep-alive turned on (which is the default for HTTP 1.1), and

Netty http keep-alive timeout on second read

I am writing a webgame server using netty and intend to use keep-alive to have more performance. If I use CachedThreadPool for boss and worker executor the server work fine for both keep-alive and non

Rails: saving duration between “events”

Long story short, each time a user views a resource, an Event model object is created. Each event has a duration column. How can I best save the duration between each event? class Event belongs_to :se

TCP transfer duration

I have two applications communicating via TCP sockets. First one receives and the second sends. First app: start=clock(); recv(); end=clock(); when i run the application, (end-start) is 150-200 msecs

HTTP Keep-Alive Header

HTTP/1.1 servers default to the Keep-Alive setting of the Connection header. Why then do most browsers include Connection: Keep-Alive in their requests even when they know that the target server suppo

Set a test timeout duration with PHPUnit

I have some test cases that can go into an infinite loop upon failure. Is there a built-in way to set a test timeout duration with PHPUnit? If not, what would be the most unobtrusive way of adding thi

What’s the difference between keep_alive and persistent option for HTTP request?

Can someone explain us the difference in behaviour between the following parameters : keep_alive parameter in Zend_Http_Client class ? and persistent in Zend_Http_Client_Adapter_Socket class ? I’d lik


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.

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.

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.