HTTP Response Timeout Error: Background and Network Setup
Users reported a recurring HTTP response timeout error where the client application failed to receive the last packet of the server’s response, causing a connection timeout. Although the server successfully sent all data along with a FIN/ACK, the client acknowledged the data but never responded with a FIN/ACK or RST to close the connection. This unusual behavior raises the question: what circumstances would lead a client to ignore a FIN packet?
The example is taken from the Wireshark official Q&A forum
Analyzing the HTTP Response Timeout Error
This user probably did some research on this issue and directly put up three data packets for analysis, including the packet capture when the client fails, the packet capture when the client succeeds, and the packet capture when the server fails . He is definitely an IT person. In this case, if the data packets are not too complicated, the comparison method may be able to get the result.
Packet capture when the client fails
Directly going to the connection termination stage mentioned by the user, the server 10.22.193.39 sent FIN/ACK (with PSH) in frame 67, Seq 61321 + Len 403 + FIN 1 = NextSeq 61725, but the client 10.196.131.236 only ACKed the data before 61724 (length 403) in frame 68, obviously ignoring the server’s FIN. Because in the subsequent frame 69, the client 10.196.131.236 did not send any data, nor did it send FIN/ACK, but only sent an ACK for window update, further proving that the client ignored the server’s FIN. After that, the server entered the retransmission stage of the FIN packet, and the client continued to ignore the FIN, constantly generating TCP Dup ACK errors. Finally, after trying to retransmit 5 times, the server directly RST this connection.
Packet capture when the server fails
The packet capture results on the server side are completely consistent with the results and analysis on the client side, corresponding to frames 24, 35, 36, and subsequent retransmissions, RST connections, etc.
Packet capture when the client is normal
Comparing the captured packets with those in normal situations, it is indeed much cleaner at first glance. The server 192.168.116.160 sent the same FIN/ACK in frame 64, Seq 61321 + Len 402 + FIN 1 = NextSeq 61724, and the client 172.19.206.213 ACKed the data before 61724 in frame 69, including the confirmation of the FIN 1 byte. The client also sent an ACK for the window update, and then directly closed the connection with RST.
The difference between the server and client IPs is due to the user’s random anonymization of the data packets.
Summary of the problem
Based on the above analysis, the conclusion is clear that the problem is on the client side, because the client ignores or disregards the FIN on the server side, resulting in the final RST connection. Wireshark can detect many network problems, but it may not tell you what caused these problems. The final cause is also known from the user’s reply that the Web reputation of the client’s antivirus program Trend Micro Officescan is the cause of the problem.
In some fault scenarios, problems from security application software still exist to a greater or lesser extent. If a data packet shows abnormal behavior, you can try to shut down the security application software and observe the phenomenon through elimination.