0

enter image description here

To my understanding, in packet no.39, the post request actually consists of multiple tcp packets getting sent, and they all get acked once by no.40. The server has received it. Now, the server sends back its response, and this response is segmented into a bunch of TCP packets, no.41, 43, 45 (as described by TCP segment of a reassembled PDU). Packet no.49, is the final TCP packet that the server sends back and the os rebuilds the response in conjunction with packets no 41,43,45, and thus wireshark names packet no.49 the http response.

My question: why then doesn't the post request at packet no.39 also follow this logic and send multiple individual TCP packets to the server and the server send back an ACK for each TCP packet, just as the server sends a bunch of TCP (PSH, ACK) packets containing portions of the http response packet that the client acks for each time? And thus why doesn't wireshark show the multiple individual TCP packets in the post request like it does with the http response.

Thanks

1
  • Presumably because the HTTP Post data can fit into one packet.
    – Ron Trunk
    Aug 5, 2022 at 15:25

1 Answer 1

0

All transactions fit in a single packet (for the virtual 127.0.0.1 loopback interface the MTU is 64 KiB), so there's only just a single packet to show.

The web server PuSHes each segment separately, so there's nothing that the TCP handler can combine into a longer segment (which would reduce overhead, yet increase latency).

1
  • 1
    comment: even if it was not a loopback interface, TCP segmentation offload can also cause such big packets displayed in wireshark. The packet is actually segmented in the network card which happens after wireshark sniffs the packet.
    – Effie
    Aug 10, 2022 at 14:15

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.