Calculate the number of bytes sent in a tcp session

1) Open the capture file and use filters to left only tcp packets from sender - you can use following string "ip.src=X.X.X.X&&tcp.len>0" where X.X.X.X your server(sender) ip address

2) Save filtered file: save as -> check checkbox "Displayed" -> save

3) Check the size of resulting Wireshark file

If you are interested in only in clear payload size, than

4) Open resulting file

5) Check the total number of frames in it (just scroll down the file and check values in the first column)

6) Calculate total size of headers - multiply number of frames in capture by 54 (14 byte Ether header + 20 byte Ip header + 20 byte TCP header)**

7) Subtract from the total size of resulting file total size of headers the result will be payload size

** If captured packets contain MPLS headers, vlan tags, gre headers or any other additional headers add them to calculation of total size of headers.

Apply a display filter to show only packets from the sender, for example "ip.src==192.168.1.1". If there is more than one TCP conversation in the trace, add the stream index to the display filter so that you're seeing only packets from the sender on the conversation of interest, so something like: "ip.src==192.168.1.1 and tcp.stream==5".

To see total bytes transmitted, bring up the Summary dialog (Statistics > Summary). Near the bottom, read the value for "Bytes" in the "Displayed" column. This is the total number of bytes transferred. It includes the Ethernet, IP, and TCP headers, and also the Ethernet Frame Check Sequence, if it is present in the trace. Not all systems pass the Frame Check Sequence to Wireshark, so it is often not present in the trace.

If you want to know only how many data bytes were transmitted, not including Ethernet, IP, or TCP headers, then make sure Wireshark's TCP preference "Relative sequence numbers" is enabled. (This is the default.) Go to the very last packet from the sender and see what the sequence number is. This is the total number of data bytes transferred.

When "Relative sequence numbers" is enabled, Wireshark makes the relative initial sequence number 0, regardless of what the actual absolute initial sequence number really is. The sender increments the sequence number by 1 for every byte of data transmitted, so the final sequence number is equal to the amount of data sent. (Ok, subtract one byte for the phantom byte during connection establishment if you want to be really accurate.)

Note that the sequence number is a finite number, so if enough data is transferred, eventually the sequence number will wrap around. This technnique assumes that the sequence number has not wrapped, which is usually true. The sequence number is a 32-bit number, so it takes 4 GB of data transfer before the sequence number wraps.

I'd just open Statistics -> Conversations, find the TCP conversation and read either Bytes A->B or the other way around, depending on what you're interested in. Of course that does includes all header overhead, so if you need data bytes, check Jim's answer.