Really Use The OSI Model (by Tony Fortunato)
Live Demo @ LMTV | Omnipliance WiFi from WildPackets (by Jay Botelho)

Are TCP Keep Alive Messages Bad? (By Chris Greer)

TCP Keep Alive Messages

Not usually. They are just the messenger. It depends on when they happen.

I had this question come in from a client who had a trace file full of black lines and red text. It’s a great question about an event that Wireshark is designed to flag – which makes them appear like horrific errors on the screen.

Naturally, the question arises – if Wireshark is flagging this stuff, is it indicating something bad for my network or application performance?

Let’s examine why these events happen, what they indicate, and how we can use them to determine if there really is a deeper problem in play.

What is a 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.

There are a few others, but those are the big ones to keep an eye on. Others? Comment below - I'm trying to keep these articles short! 

Chris Greer Packet Pioneer Logo

Author Profile - Chris Greer is a Network Analyst for Packet Pioneer. Chris regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. Chris also delivers training and develops technical content for several analysis vendors.
 
Got Network Problems? Contact me
www.packetpioneer.com

Comments