Revision history [back]

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself. Therefore: Q1) As you're on the server itself, you just don't see ACKs because they haven't come to you and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself. Therefore: Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they haven't come to you and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself. itself.

Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they haven't come to you and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.

Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they haven't come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.

Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they haven't come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.

Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they haven't had not come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

or wiki article

https://en.wikipedia.org/wiki/Large_send_offload

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.

Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they had not come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

or take a look on wiki article

https://en.wikipedia.org/wiki/Large_send_offload

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.

Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they had not come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

or take a look on wiki article

https://en.wikipedia.org/wiki/Large_send_offload

Always consider the point you're capturing on. You trace has strong signs of being captured on the sender itself.

Therefore:

Q1) As you're on the server itself, you just don't see ACKs because they had not come to you at the moment and still are somewhere on the path. It seems the sender has congestion window big enough to transmit packets 16...22 without waiting for an ACK.

Q2) This is because of "TCP segmentation offload". Please watch Paul Offord's cool video to grasp the concept:

https://www.youtube.com/watch?v=anEZGfF4P10

or take a look on wiki articlewikipedia article Large Send Offload.