TCP KEEP ALIVE

Before TCP can transfer data to another system, it first has to establish a socket, or connection, with the peer. In order to do this, it will fire off a TCP handshake (SYN – SYN/ACK – ACK). If successful, the connection will now be available to transmit data. While this is only a three packet exchange, it does represent some overhead, and does cost a roundtrip delay to set up.

Once the connection is established, a timer is started on each TCP stack that will eventually time out the connection. This means that if a socket is not in use for a specified amount of time, if the stack is configured to do so, it will send a TCP Keep Alive. This timer is a configurable setting and varies depending on the system.  

The sending station is trying to see if the remote peer is dead, if the connection is still open and in use, or may just need to keep the connection open instead of suffering another handshake overhead. If the target does not respond, the sender may send several Keep Alives before finally sending a TCP reset to kill the socket. This is a good thing, since we don't want open/unused TCP connections staying open and hogging resources forever. 

What does a TCP Keep Alive indicate?

The purpose of these packets is to – as indicated by the name – keep the TCP connection alive. There are several reasons for this.

Common reasons for Keep Alives

1. A station is waiting for a response from a server, and the response time exceeds the Keep Alive time.
2. There are no requests for the client to send to the server, but the client expects more soon, so it doesn’t want to kill the connection (common in multi-tier server environments)
3. The connection partner has gone offline and is no longer responding to requests or Keep Alives.
4. The connection is simply no longer in use and neither side of the connection has properly shut it down yet (FIN or RST)

When should I be concerned?

If a TCP keep alive happens at the end of a data dump when no client request is outstanding, there is no major issue. The ones to watch for happen after a client has requested data and is waiting for the server to respond. This indicates that the application response time is so long that it exceeds the TCP timer and should be investigated. Also, if these occur at the end of a connection and the server never sends a Keep Alive Ack, this may mean that the network path is down or that the server is offline/too busy.

Which is the TCP keep alive packet how to identify:

A TCP Keep-Alive is sent with a Seq No one less than the sequence number the receiver is expecting. Because the receiver has already ACKd the Seq No of the Keep-Alive (because that Seq No was in the range of an earlier segment), it just ACKs it again and discards the segment (packet). Example as below

 

[courtesy: http://www.lovemytool.com/blog/2014/11/are-tcp-keep-alive-messages-bad-by-chris-greer.html]