Get Bytes Transferred using the Seq, Ack and Len fields

Here’s the scenario. You’re given a Wireshark .pcap file and tasked with finding out how much data has been transferred between the HTTP client and the AWS web server. The HelloWorld.html is 176 Bytes on the MacBook Air and 176 Bytes in the AWS, and we want to confirm that the data transferred is also 176 Bytes, just to make sure there’s no weird shit going on…

MacBook Air

AWS S3 Bucket

Will Wireshark also confirm that we send 176 Bytes from the server to the client?

We have previous threads discussing the 3-way handshake so here we’ll start after the TCP session is established and look at HTTP GET and HTTP GET Response.

The Google Chrome web browser sends an HTTP GET Request with a random TCP source port number and TCP destination port 80 to indicate an HTTP packet. The Sequence (Seq) and Acknowledgement (Ack) numbers are listed as 1. In reality, they are randomized to prevent security vulnerabilities, but Wireshark shows them as 1 for readability purposes. Finally, the Len field indicates that the data payload inside the TCP segment is 474 Bytes. So, the HTTP GET request is 474 Bytes.

The static website is hosted on an AWS S3 bucket, which is an object storage system in AWS. The HTTP GET Response includes TCP source port 80 and destination port 58764. Since the client sends Seq=1 and Len=474, the server replies with an Ack of 475 to indicate that the server expects the next packet from the client to have a sequence number of 475. Finally, the server replies with Len=176, which is the HTTP GET Response payload inside the TCP segment.

Hell Yeah! Len=176 confirms, as expected, that there is no data payload padding or slippage between the client and AWS S3. All Good Bro!