When wireshark trace taken on the client side it appears to be:
---SYN--->
<-SYN-ACK-
---ACK--->
-HTTPGET->
But when wireshark trace taken for the same traffic on the server side it appears to be:
---SYN--->
<-SYN-ACK-
-HTTPGET->
Where the HTTPGET packet appears to be the ACK for the SYN-ACK since it has the same sequence and ack number as the previous ACK packet.
Same thing happens later on the opposite way:
When wireshark trace taken on the server side it appears to be:
-HTTPGET->
<---ACK---
<-200-OK--
But wireshark trace taken for the same traffic on the client side it appears to be:
-HTTPGET->
<-200-OK--
Where the 200OK appears to be the ACK for the HTTPGET since it has the same sequence and ack number as the previous ACK packet.
So my question is there any known network element that is doing TCP piggy-backing as a man-in-the-middle?
I believe this is causing some issue on both peers as they seems are waiting for the "missing" ACK forever: For instance:
*Duplicate ACK for the 200OK at the server side since it is waiting for the third ACK in the TCP three way handshake (which has been piggybacked into the subsequent HTTPGET).
*Retransmission of HTTPGET at the client side since the original, non-piggybacked ACK for it never arrives.
Here are sample traces: http://goo.gl/7V0pah