Jozsef Kadlecsik wrote:
If the data packet sent by the server is valid, the client should send an
ACK and not a RST packet. If the data packet is invalid, the client should
send an ACK again and not a RST.
Actually, unless I'm misunderstanding, RFC1122 section 4.2.2.13 seems to
allow what the client is doing:
A host MAY implement a "half-duplex" TCP close sequence, so
that an application that has called CLOSE cannot continue to
read data from the connection. If such a host issues a
CLOSE call while received data is still pending in TCP, or
if new data is received after CLOSE is called, its TCP
SHOULD send a RST to show that data was lost.
So in this case, the client app closed the connection even though there
was data from the server that hadn't been delivered, and the client's
TCP stack replied with a RST as described above.
If the server receives the RST packet (and it's valid) it should never
ever send unsent data but destroy the connection.
That's what I would have thought, but packet dumps are showing
otherwise. On a standard Debian 2.6.24 kernel it keeps retrying the
un-acked packet for more than a minute despite the RST, as shown at the
end of:
http://tigertech.net/20080703.tcpdump.server.txt
Are you sure that a normal kernel doesn't do this? Maybe it's a Debian
bug? If you have access to a fairly busy Web server, you can see if
yours is doing it with:
egrep 'ESTABLISHED.+port=(80|443).+UNREPLIED' /proc/net/ip_conntrack
Under normal circumstances, there should be none of these, but all our
Web servers have thousands (from many hundreds of different client IPs).
Disable picking up connections and you get rid of those stale connections:
# echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
Thanks! That's exactly what I was looking for, and I really appreciate it.
(I also had the idea of changing nf_conntrack_tcp_timeout_close to be
120, like nf_conntrack_tcp_timeout_fin_wait, which would hopefully cause
conntrack to remember the first closed connection for long enough that
it doesn't think the retransmitted outbound packet is new.)
--
Robert L Mathews, Tiger Technologies
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
