1

I want to attempt to calculate how much data (bytes) I send/receive over the network. I send/receive both TCP and UDP packets, so I need to be able to calculate the size of these packets including their respective headers. I looked at this questions: Size of empty UDP and TCP packet and it lists the minimum size of the header, but is that libel to change? Should I just add the number of bytes I send in the packet, but the size of the minimum header? Also, I know at some point (n bytes) the data would be too big to fit in just one packet.

One other thing, the client is a mobile device, so it may receive over cellular or wifi. I am not sure if there is a difference in the packet size between the two, but I would probably just want to assume what ever is larger.

So my questions are, assuming the data is n bytes long:

1) How big would the TCP packet be, assuming it all fits in one packet?

2) How big would the UDP packet be, assuming it all fits in one packet?

3) Is there an easy way to determine the number of bytes it would take to overrun one packet? For both TCP and UDP.

Community
  • 1
  • 1
Nick Banks
  • 4,298
  • 5
  • 39
  • 65

2 Answers2

2

Lets assume we're only talking about ethernet and IPv4

Look at your interface MTU, which has already subtracted 
    the size of the ethernet headers for the OS I can 
    remember (linux and FreeBSD)

Subtract 20 bytes for a normal IP header (no IP options)

Subtract 20 bytes for a normal TCP header

Or

Subtract 8 bytes for a UDP header

That is how much data you can pack into one IPv4 packet. So, if your TCP data is n bytes long, your total ethernet payload is (n + 20 + 20); your ethernet payload for UDP is (n + 20 + 8).

EDIT FOR QUESTIONS

RE: MTU

Your interface MTU is the largest ethernet payload that your drivers will let you encapsulate onto the wire. I subtract because we're assuming we start from the MTU and work up the encapsulation chain (i.e. eth -> ip -> tcp|udp); you cant send TCP or UDP without an IP header, so that must be accounted for as well..

RE: Calculating application overhead

Theoretical calculations about the overhead your application will generate are fine, but I suggest lab testing if you want meaningful numbers. Usage factors like average data transfer per client session, client hit rate per minute and concurrent clients can make a difference in some (unusual) cases.

Community
  • 1
  • 1
Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
  • Two questions, one: what do you mean by "your interface MTU" and two: why are you subtracting? The goal of this is to calculate exactly how many bytes are sent over the network. All I currently know is that I am putting n bytes of data into a packet (TCP and/or UDP). Also, on the server side I can assume Ethernet, by on the client side, I will have to assume that there is a wireless header on top of that. I know wifi uses 802.11 header, does cellular use something else, assume so? – Nick Banks Apr 17 '11 at 21:50
  • I think you are still misunderstanding my question. I am not asking how much data I can pack into a packet. I am asking how big my packet will be if I start out with n bytes of data to put in it. Keep in mind, I am using Java's socket implementation, and the server is on windows (for now). – Nick Banks Apr 17 '11 at 21:59
  • If it is n bytes long, then add 20 for IP, and 20 for TCP. Either of the books [suggested in this post](http://stackoverflow.com/questions/5467176/what-is-the-explanation-for-many-elements-of-the-tcp-protocol/5467243#5467243) will be very helpful as it seems you are curious about the subject – Mike Pennington Apr 17 '11 at 22:06
  • 1
    @daniel, if you are trying to find an end to end packet size that the path will support, I would suggest investigating whether you can use [TCP path MTU discovery](http://en.wikipedia.org/wiki/Path_MTU_Discovery), and set the IP DF (dont fragment bit) in the IP header. That said, I still dont understand the basic concern about how large the packet will be. The OS should handle these details. – Mike Pennington Apr 17 '11 at 22:21
0

It is sadly not possible to determine this completely. Packets might be split, reassembled etc. by network hardware all along the path to the receiver, so there is no guarantee to calculate the exact number of bytes.

Ethernet defines the frame size with 1500bytes, which makes 1460 bytes remaining if the headers are subtracted. Using jumbo frames up to 9k bytes is usually only supported locally. When the packet reaches the WAN, it will be fragmented.

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
Daniel
  • 27,718
  • 20
  • 89
  • 133
  • I understand this, but assuming I am sending packets with data less than 1K byte, I would like to 'estimate' how much data is used. Also, I would like to err on the side of more used than less. – Nick Banks Apr 17 '11 at 21:54
  • I am sorry there is so much misguided information in this answer... First modern network hardware very rarely splits up IP packets that are 1500 bytes or less... Reassembly in the network is equally rare... Look at [rfc 791](http://www.ietf.org/rfc/rfc791.txt), they very clearly want reassembly at the endpoint, not on routers and firewalls; it can happen, but again a corner case. Finally, I will send you $100 via paypal if you can show me any vendor that supports a 64 KB MTU on their NIC, as well as a corresponding Ethernet switch for it. Perhaps you are confusing the TCP MSS number w MTU. – Mike Pennington Apr 17 '11 at 22:03
  • For both TCP and UDP, and I assume that is just for Ethernet? No accounting for the size of the packet sent over a cellular network or wifi? – Nick Banks Apr 17 '11 at 22:04
  • The 1500 bytes are from the Ethernet spec. I don't know package sizes for other network types. – Daniel Apr 17 '11 at 22:07
  • @daniel, you said jumbo frames can be 64KB... That is incorrect. I dont recall seeing supported ethernet jumbos larger than 20000 bytes. The vast majority of implementations are less than 10000 byte ethernet jumbos. – Mike Pennington Apr 17 '11 at 22:15