First and foremost: I'm not actually a network or system engineer so apologies in advance if I'm asking any noob questions. I'm currently experiencing erratic behaviour from a web server that I'm using. It has been working for several years without any issues but since a couple of days we are getting (at random points in time) socket reconnect errors. When tracing this through Wireshark, I see that the SYN-handshake seems to be performed well, the HTTP GET gets an ACK packet, but then the server sends an RST, ACK packet, causing the session to be ended abruptly. At other times though, this doesn't give any issues and the server proceeds to transfer data.
So my question would be: is there any way I can find out wat the cause for the RST ACK packet was? Is it send by the TCP/IP stack at the server? Or can it be triggered by the web server application itself? Or can it be triggered by network devices in the middle, even though the source and destination address in the packets seem to only refer to the client and server? Any help would be greatly appreciated. asked 01 Apr '16, 01:05  PLombaer |
I was able to obtain a similar trace at server side, and it shows the same behaviour, so it doesn't look like packets are being dropped.
One Answer:
Usually this kind of behavior happens if the application on the server doesn't want to talk to the client IP (which the application only gets notified about after the handshake). It's not the TCP stack itself that sends the RST, it's doing it because the application closed the socket. See also https://blog.packet-foo.com/2014/01/tcp-server-slamming-the-door/ for some thoughts about a similar case. answered 01 Apr '16, 01:11  Jasper ♦♦ |
Hello Jasper, thanks for your reply. In the example you've shown, the refusal of the ftp server application seems to be based on blacklisted/whitelisted ip addresses. Is a connection refusal (at this level) always based on one of the tcp/ip protocol characteristics? Or could it be based on anything which the application decides to reset the connection for?
it can be anything that makes the application close the socket. So it can be a blacklist/whitelist of any kind (usually IP based), or maybe an internal problem that forces it to abort serving the page (but you'd normally see a 5xx error for those).
I've also seen web frameworks not being able to deal with a high amount of concurrent sessions, either for performance reasons or license issues. Those are problems that usually show up after the application has run fine for a while (sometimes months) and the concurrent sessions increasing over time until they start to fail when more and more users are added.