Many times, my server is responding the way described is this question title (some other times stuff work just fine).
My topology is something (simplified) like this (I'm not the network admin):
According to Apache stats there are still free workers/threads to receive requests and CPU/RAM usage is quite normal.
Please take a look at the following image (from a tcpdump capture on one of web servers & open in Wireshark) and provide some ideas about what the issue might be (I've struggled with this for several weeks now)
Capture file uploaded here: https://www.cloudshark.org/captures/4a87072e66c5
asked 08 Nov '16, 14:05
edited 11 Nov '16, 07:30
There are a couple of things out-of-the-ordinary me in this trace:
Retransmission of the SYN/ACK
Long delay before first HTTP request
Wrong ACK number on HTTP request
Next troubleshooting steps could be:
answered 11 Nov '16, 03:18
As the SEQ of the TCP/RST does not seem to match the SEQ and ACK of the 3-way-handshake, I would like to see the real tracefile to look at the SEQ and ACK of the http request. I would also like to look at the IP TTL to see whether an intermediate device might be sending the TCP/RST and I would like to look at the ip.id to help in the analysis. In short, no good analysis could be done (at least not by me) just based on the screenshot. Too much important information is missing...
answered 09 Nov '16, 08:12
It looks like the server connection is never opened. That's why the server is sending those resets.
In Frame 71, the server sends it's SYN-ACK, but then resends it, according to the screenshot you provided, in Frame 73. But it also looks like the server did get the ACK from the client, according to the capture.
Was this capture taken directly on a specific web server?
What's going on with the SYN-ACK being resent and the ACK not being acknowledged by the server suggests that the capture was taken outside of the web server farm, likely on the FW or LB.
And there seems to be some retransmissions as well.
So if the capture was not taken on a specific web server and there are retransmissions, it's likely that Frame 72 is never received by any server, and is actually dropped, but you just don't see it. Therefore, when the client sends it's HTTP GET, the server doesn't OK it because the connection's not opened yet. That's why in Frame 80, the server resends the SYN-ACK in another attempt to open the connection.
So I would verify that you're capturing data from a specific web server, if you can, and also look into those retransmissions. What causing that? Since you're not the network admin, this is something you can probably bring up with that person.
As Jaap mentioned, a capture you can share would help to take a better look at this, but I think that's what is happening here.
answered 09 Nov '16, 07:41