When I email something or download a program, or do anything else over a network, where in the segment is the actual content? If I am emailing a 20KB word document, and the maximum data field size in a segment is 1500 bytes, does that mean it takes about 14 segments to mail my document wherever it is going?

I get, I think, the OSI model and I have a decent grasp of the IP protocol. I think I understand the concept of header wrapping of each successive layer in the protocol stack. What I can't get a definitive answer to is where does the actual content go in a TCP segment? Is that the datagram?

Maybe the fact I am asking proves I have no clue...

Many thanks.


The data comes at offset 160 if no option-headers are present, and further down (multiples of 32) if IP option headers are present. The data portion continues to the end of the packet. A packet can be variable size due to differing MTu settings along the path, so the exact number of packets a portion of higher-protocol data gets carved into depends.

The 'datagram' is the size of the IP header + data.

You are incorrect in the maximum data field size being 1500b. That's the size of the entire packet including headers. The data-field size is variable based on header length, as I described above.

  • So would I be correct in saying the word document in my example gets split up however many times is required and the actual text from that document goes into that data field starting at offset 160 or later? My confusion centers on not being clear on if the 'data' that get encapsulated at each successive layer are referring to protocol 'data' (PDU's) or the actual stuff people send each other and read. My apologies if I am not making sense. I am trying to understand the practical implementation of all this. Separating the abstraction, if you will. – packetloss Mar 24 '12 at 3:15
  • @packetloss Since we're talking layer 3 here, it's (in your case) SMTP data in each packet, which is likely the base64 representation of the binary file itself. – sysadmin1138 Mar 24 '12 at 3:39
  • I think that answers my question. Now I think I have more questions... – packetloss Mar 24 '12 at 4:07

The content gets broken up into chunks and put into the "data" portion of the packets. The offsets for that data section were mentioned in another answer.

This is worth a read: http://en.wikipedia.org/wiki/TCP_packet#TCP_segment_structure

TCP/IP is pretty complicated; witness: http://www.tcpipguide.com/free/t_toc.htm

Here's a pretty good representation of the data portion of packets, which I found on http://concept51.co.uk/in_how_networks.html : a tcp/ip packet

  • Perhaps this is where I am missing something. The encapsulation that occurs in the diagram you attached is for the PDU's, correct? My apologies for the confusion but isn't this just 'data' for the various protocols? And not the actual text in the word document I am sending in the example? I have read the wikipedia article and sentences like: 'The Option-Kind field indicates the type of option, and is the only field that is not optional' do not shed light on this. – packetloss Mar 24 '12 at 3:07
  • The data of the 20K word document gets broken up into chunks and each chunk is put into the data portion of a packet - the green portion in the above diagram. For the packets involved in sending your word document, that green data portion isn't for anything else other than the chunks comprising your word document - the "payload" being transmitted. – pbr Apr 8 '12 at 22:25

Please see RFC 793 (http://www.ietf.org/rfc/rfc793.txt).

The actual "data" (i.e., your document) is contained in the TCP segment (after the TCP header) of the packet. The size of the data in the packet is determined by the TCP Maximum Segment Size (MSS).

I suggest downloading a tool like Wireshark (http://www.wireshark.org) and capturing the network traffic as you send your file. Wireshark will interpret the packets for you (you can even right click on one of the packets which contain data from your file and select 'Follow TCP Stream').

You will also be able to look at each successive packet header which is decoded and explained for you by Wireshark. That should give you a much better idea as to what's happening when you sent data via TCP.


Your Answer

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.