2

enter image description here

-Segment 237, the client (10.xxx) sends a POST request to server (128xxx) with a payload of (TCP Len) 4096.

-Segment 238, the client continue with the transmission with a payload of 1460 (seq 4097-5557)

-239, the server 128.x.x.x acknowledges the receipt of segment 238 with an Ack=1461 (right??)

At this point it seems the Ack for 237 is missing, because the server hasn’t received it (the first 1-4096 bytes of data) yet.

-However, at 243, the server tells the client, the server is actually missing data with sequence number from 1-1460 (these missing data is from segment 237, and not 238??), and sequence number 1461-4097 (partially from 237) has been received.

-244, the server updates the SACK, saying it is missing data with sequence number from 1-1460, and sequence number 1461-5557 has been received (assuming the seq num between 4097-5557 is from segment 238 which the server acknowledged previous in 239).

Am I interrupting this correctly? Please correct me if I am wrong, because I do not see any retransmission of the missing seq num 1-1460 later on in the trace: https://www.cloudshark.org/captures/1a890ba09b92

Any help will be greatly appreciated. Thanks.

Improve this question

1 Answer 1

Reset to default
2

I think you are misinterpreting the initial ACK. That first segment is 4150 bytes long, which is way more than you can fit into most standard segments, and is typically an indication that the host is doing TCP Large Segment Offload, which allows the application layer (including PCap) to think you are sending large segments, but the NIC is actually splitting them into smaller segments compatible with the MSS/MTU limitations.

So here instead of sending one segment with a data size of 4096 bytes, you are probably sending three: two of 1460 bytes, and one of 1176 bytes (or something like that). So frame 238 in this capture is actually the 4th segment actually sent.

The series of ACKs looks bizarre, as if you had out of order packet delivery in this network. It would have seemed more logical if you had first received segment 243 & 244 (you got the segment for bytes 1461 to 5557, so you SACK that) and then the first packet arrived and got ACKed (packet 239), and then at packet 245 everything gets caught up.

I honestly don't see how you can end up with this particular sequence of segments, unless:

  1. There are multiple paths of different latency being taken by packets from the client to the server,

and

  1. There is something which is fiddling with the initial ACK, sending it even though the server hasn't actually received that first segment.

Could there be a WAN optimization device such as a Riverbed somewhere between client and server? They have mechanisms which try to ACK some segments as quickly as possibly in order to accelerate the session's throughput ramp-up.

I may be completely wrong here; that's a really unusual sequence!

Improve this answer
1
  • thanks so much for ur answer. The trace was captured on a win10 machine in a public network, but this unusual sequence is not a one time coincidence. I tried repeating the same post request under the same environment, and the same sequence occurred in exactly the same order.
    – Chloe
    Apr 2, 2016 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.