I have an embedded device connecting to a server (on AWS Application ELB if that matters). Both the server and the client are instructed to close the connection after one request. I noticed that the client took a long time to close the connection even after receiving back the HTTP response from the server. I know it uses a low-powered network with high latency but I still wanted to check if there was something else going on, so I took a tcp dump from both sides.
The screenshot shows the trace from client side. Concentrating at the connection close sequence:
- At packet 13 the client sends an empty FIN packet. There is high network latency so it doesn't get immediately the response back but a retransmission instead (packet 14).
- The client sends another FIN (packet 15) with incremented seq (!!!).
- It happens again at packet 17 with further incremented seq (!!!).
If I understand correctly the TCP state machine this is not a valid behavior. If packet 15 and 17 were retransmissions, they should have been sent with the same exact numbers. In fact, the server never acknowledges the incremented seq numbers.
If necessary I can provide also a screenshot of the dump from server side, but it just shows the same packets in a different order, there is no packet loss.
Note: packet 16 shows relative seq num = 1 but the absolute raw value is correct and the same as packet 14.
