It is not enabled by OS, but by applicaiton level. Failed to response KEEP ALIVE packet will result windows RST
http://msdn.microsoft.com/en-us/library/aa925764.aspx
A TCP keep-alive packet is simply an ACK with the sequence number set to one less than the current sequence number for the connection. A host receiving one of these ACKs will respond with an ACK for the current sequence number. Keep-alives can be used to verify that the computer at the remote end of a connection is still available. TCP keep-alives can be sent once every KeepAliveTime (defaults to 7,200,000 milliseconds or 2 hours), if no other data or higher-level keep-alives have been carried over the TCP connection. If there is no response to a keep-alive, it is repeated once every KeepAliveInterval seconds. KeepAliveInterval defaults to 1 second. NetBT connections, such as those used by many parts of the Microsoft networking functionality, send NetBIOS keep-alives more frequently, so usually no TCP keep-alives will be sent on a NetBIOS connection. TCP keep-alives are disabled by default, but Windows Sockets applications can use the SetSockOpt function to enable them.
How to view wireshark KEEP ALIVE and TCP window packet http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers
Known TCP problem
http://tools.ietf.org/html/rfc2525#section-2.9
Description
The retransmission timeout is used to determine when a packet has
been dropped in the network. When this timeout has expired
without the arrival of an ACK, the segment is retransmitted. Each
time a segment is retransmitted, the timeout is adjusted according
to an exponential backoff algorithm, doubling each time. If a TCP
fails to receive an ACK after numerous attempts at retransmitting
the same segment, it terminates the connection. A TCP that fails
to double its retransmission timeout upon repeated timeouts is
said to exhibit “Failure to back off retransmission timeout”.
Significance
Backing off the retransmission timer is a cornerstone of network
stability in the presence of congestion. Consequently, this bug
can have severe adverse affects in congested networks. It also
affects TCP reliability in congested networks, as discussed in the
next section.
Implications
It is possible for the network connection between two TCP peers to
become congested or to exhibit packet loss at the time that a
retransmission is sent on a connection. If the retransmission
mechanism does not allow sufficient time before dropping
are hardcoded to 10 and could not be adjusted via the registry.
d) Some special considerations
=> Even if TCP KeepaliveTime and TCPKeepAliveInterval registry keys are set to a specific value (TCPIP driver uses the deafult values even if we don’t set these registry keys from the registry), TCPIP driver won’t start sending TCP Keepalives until Keepalives are enabled via various methods at upper layers (layers above TCPIP driver).
=> Native Socket applications can enable TCP keepalives by using anyone of the following methods:
– setsockopt() with SO_KEEPALIVE option – WSAIoctl() with SIO_KEEPALIVE_VALS option (it’s also possible to change Keepalive timers with this API call dynamically on a per-socket basis)
http://blogs.msdn.com/b/sql_protocols/archive/2006/03/09/546852.aspx
In Windows, as well as many other operating systems, TCP/IP Keep-Alive is not enabled by default. By enabling this, SQL Server can, in a timely manner, detect “orphaned connection” and free up valuable resource associated with each connection, including its session context, locks, kernel TCP buffers and etc., which sometime can become very expensive for a SQL Server running heavy transactions. The major drawbacks, among many others, are (1) Keep-Alive consumes bandwidth on a perfect idle connection; (2) It causes good connection to break during transient network failures. So configuring the keep-alive values too small is not recommended.
The following KB about orphaned connection/session for SQL Server 2000 shares valuable insight on how to configure Keep-Alive for named pipe connections.