From what I read, a "Keepalive Packet" would be a packet without any payload, and with an ACK number. If this is the case, then how can the receiver know that the packet is a Keepalive packet and not an ACK packet? Because as far as I know, this is exactly how an ACK packet may be formatted.

And why does it have to differentiate between a Keepalive Packet and an ACK packet? Because a receiver doesn't send ACKs to an ACK Packet it receives, but it does send an ACK Packet when receiving a Keepalive Packet.

From what I read, a "Keepalive Packet" would be a packet without any payload, and with an ACK number. If this is the case, then how can the receiver know that the packet is a Keepalive packet and not an ACK packet? Because as far as I know, this is exactly how an ACK packet may be formatted.

And why does it have to differentiate between a Keepalive Packet and an ACK packet? Because a receiver doesn't send ACKs to an ACK Packet it receives, but it does send an ACK Packet when receiving a Keepalive Packet.

• network-programming
• tcp
• connection
• controls

Share Follow edited Mar 17 at 17:32 CS Student asked Mar 11 at 8:12 CS StudentCS Student 3588 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

From what I read, a "Keepalive Packet" would be a packet without any payload, and with an ACK number. If this is the case, then how can the receiver know that the packet is a Keepalive packet and not an ACK packet? Because as far as I know, this is exactly how an ACK packet may be formatted.

It's an ACK packet which does not advance the TCP state. No new data has been transferred, so the sequence number being ACK'd did not increase.

TCP keepalive packets come in pairs:

1. First, peer A sends a 1-byte segment which pretends to re-transmit the last byte that was sent by re-using an already sent (and already acknowledged!) sequence number,
   SEQ = SND.NXT minus 1.

   (Like every other 'established' TCP packet, this too has the ACK flag set, but doesn't acknowledge anything new – just like the ordinary case of one peer sending data while the other is quiet.)

2. In return, peer B acknowledges the segment by sending what is effectively a duplicate ACK (a 0-byte segment that ACKs a sequence number that had already been ACK'd before).

   (Peer B discards the segment's data because it has already received and properly ACK'd that seqno before, and already delivered the data to the appropriate socket.)

The Wireshark packet capture program recognizes this as a "TCP Keep-alive" because it tracks TCP flow state across the entire capture; if the same SEQ was already seen in the capture (plus several other conditions met) then the "keep-alive" label is added. (Which means that if you start capturing on an already live TCP connection, the first keep-alive pair will not be recognized as such by Wireshark.)

Similarly, Wireshark recognizes the 2nd packet as a "Keep-alive ACK" if it can reference it to a segment previously recognized as a "Keep-alive" segment. If it couldn't, then the packet would be labelled as merely "Duplicate ACK".