This is what the TCP rfc says about keep-alive messages:

Implementers MAY include "keep-alives" in their TCP implementations (MAY-5), although this practice is not universally accepted. Some TCP implementations, however, have included a keep-alive mechanism. To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the TCP peer. Such a segment generally contains SEG.SEQ = SND.NXT-1 and may or may not contain one garbage octet of data. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection (MUST-24), and they MUST default to off (MUST-25).

Im confused about the SND.NXT-1, what happens when the server receives a segment with an already acknowledged sequence number?

  • "what happens when the server receives a segment with an already acknowledged sequence number?" It ignores it. That happens when a segment gets delayed enough that it gets resent, then two of the same segment are received. The second is ignored.
    – Ron Maupin
    Jan 14 at 15:11
  • for me they dont get ignored? The packet capture shows a segment with sequence number that has already been acknowledged, and then the server responds with an ACK with the latest ack number it used
    – user86942
    Jan 14 at 15:22
  • They are ignored because the data contained is already in the buffer for the application, and the buffer is not overwritten. The application only gets one copy of the data in duplicate segments.
    – Ron Maupin
    Jan 14 at 15:26
  • so by ignored you meant that the application will not receive it, but the kernel will still send an ACK?
    – user86942
    Jan 14 at 15:44
  • Forget the kernel because host implementations are off-topic here. We can answer questions about the protocol theory, not any specific implementation. Remember that TCP is a transport protocol, and its purpose is to transport application data. When a receiver receives a duplicate segment, it acknowledges it because the previous acknowledgement may have been lost, causing the sender to resend the segment. If the segment contains data, the data are not duplicated to the application. Keepalives (not a required part of the protocol definition) take advantage of this behavior.
    – Ron Maupin
    Jan 14 at 15:59

2 Answers 2


when TCP receives a duplicate segment (as determined by the sequence number), it sends an ACK with the next expected sequence number and then drops the duplicate packet.

Why this generally make sense:

Note, that TCP ACKs can also be lost. The sender cannot distinguish between a lost packet (that it actually has to retransmit) and a lost ACK, so the only thing the sender can do is to retransmit the packet in question anyways. Since the sender retransmits the packet, the receiver, upon receiving this duplicate packet, can assume that the sender did not receive the ACK, so the receiver has to send another ACK for it.

This mechanism is kinda "exploited" for the keep-alive probe.


what happens when the server receives a segment with an already acknowledged sequence number?

Nothing with the connection itself. The purpose of a keep-alive segment is to reset the timeout on the connection partner (and possibly TCP aging on intermediate firewalls).

  • but does the receiver respond to it? The TCP rfc says that an incoming segment with sequence number < RCV.NXT, is not valid? RCV.NXT is the sequence number that the receiver is excepting. Here: datatracker.ietf.org/doc/html/rfc9293#name-sequence-numbers
    – user86942
    Jan 14 at 14:58
  • Generally, there's no response to an ACK. No, without the keep-alive option negotiated, that sequence number is not valid.
    – Zac67
    Jan 14 at 15:15
  • Why does it respond with an ACK then? My client sends a segment with a sequence number that has already been ACKd, and the server ACKs with the latest ack number it used
    – user86942
    Jan 14 at 15:23
  • To refresh the timers in the return path.
    – Ricky
    Jan 14 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.