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.


New contributor
JohnDoeyyy is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • Presumably because the HTTP Post data can fit into one packet.
    – Ron Trunk
    2 days ago

1 Answer 1


All transactions fit in a single packet (for the virtual 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).

Your Answer

JohnDoeyyy is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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