Packet #06 client sends 445 bytes
Packet #07 server acks 445 bytes (immediate ack, application hasn't read the data yet)
Packet #08 client sends 9 bytes (Nagle disabled at the client)
Packet #09 is the server sending 506 bytes
Packet #10 is the server sending a window_update (the appl now has read 445 bytes from #6)
Packet #11 is the client acking packet #9 (ack# 507) (immediate ack
Packet #12 is the server acking 9 bytes from packet 8, application hasn't read the data yet) Packet #13 is the second ack for packet # 9
So wireshark is right in telling you that frame 13 is a duplicate ack.
Why the (Linux) client sends an immediate ack to an empty ack from the server I don't know. I think the scenario is caused by both TCP stacks sending immediate (not delaying) acknowledgements.
Modification:
I would say the trace is showing how disabling Nagle and delayed_ACK might cause some unwanted packets to flow over the wire.
answered 26 Sep '14, 08:50
mrEEde
3.9k●15●22●70
accept rate: 20%
Hi mrEEde,do you think that seq no. of packet #10 is right(seq 1),i think it should be 507 and then in packet#12 seq no. comes back to normal 507.
Well spotted, Kishan!
The seq# of packet 10 indicates that it was created earlier by TCP (between packet 7 and 8). All those packets are traced in a very short timeframe of less than 100 µs so when the capture point cuts them the outbound packets are out_of_order already.