When we receive an ACK from a TCP peer and the ACK acknowledges data that we have not sent yet, RFC 793 indicates that we should respond with an ACK indicating our current sequence number and acknowledgment number.
When we receive an ACK for data we have not yet sent, this likely indicates either a spoofed packet or an unsynchronized connection. In the latter case, RFC 793 provides some examples of how sending an ACK can help the remote side determine the connection is unsynchronized, leading it to close the connection. So, it probably makes sense to continue to send ACKs in this case.
However, these ACKs often will *not* be useful. And, in some extreme cases, we can even end up in a cyclical pattern of connections that continually fail at a high rate. Bug 184680 documents one such case which involves sessions opened with a SYN cookie.
Therefore, it makes sense to send these responses, but with a rate limit. This will provide us with the benefit of occasionally helping to quickly clean up an unsynchronized connection, but will also provide some protection against the case where sending a ACK merely feeds a cycle of failing connections (or, in any case, is not helpful).
PR: 184680