Webspace Sponsored by:
Version 0.0.0 @ 03:55/08.07.2000
Decomposition of a TCP Packet
0....... |
8....... |
16...... |
24...... |
(<--------32-bits-wide-------->) |
The above is an example of an TCP Header. Rows 1 through 5 are commonly used, and when options are included in the header, then rows 1 through 6 or more depending upon how many 32-bit option words are used by special options. The payload contained is the encapsulated data from the upper layer. For example, a Synthesis request from a client to a server to create a connection and session.
Description of fields listed in above TCP header starting from left to right, top to bottom.
- Source Port [SP] (16 bits): When a connection is attempted, or being conducted, this specifies what port the local machine is waiting to listen for responses from the destination machine.
- Destination Port [DP] (16 bits): When a user desires to connect up to a service on a remote machine, the Application Layer program specifies what port initial connections should use. When not as part of an initial connection, this specifies what port number is going to be used for the remote machine as a packet is being sent out to its destination.
- Sequence Number [SN] (32 bits): In a sliding window protocol like TCP, the sequence number allows both TCP stacks to know what packets have been received and which ones have not. Say for instance I get mail messages 1,2,3,5,6,7,8,9, and 10 from you when I know you are sending 10 messages. If you numbered each of your messages, I can look through and see that I do not have message number 4, and I can tell you to send me another copy of that. The sequence number works very much like this, as well as to allow for a little security so that other users cannot easily break into the middle of your connection and continue where you left off.
Predictable sequence numbers for certain implementations of TCP/IP stacks has led to some security problems with attacks geared to anything from blind Denial of Service, to taking over connections in use by other users that have authenticated themselves. This discussion is beyond the scope of this paper, but plenty of other talented coders and researchers have published a great deal of work on this topic.
Once there is a communication session over TCP set up between two machines, the sequence number increases are directly proportional to the number of data bytes that are transmitted.
- Acknowledgment Number [TL] (32 bits): This works by acknowledging the sequence number as sent by the remote host. The local host's Acknowledgement Number is a reference to the remote machine's Sequence number, and the local machine's sequence number is related to the remote machine's acknowledgement number.
- Header Length [HL] (4 bits): Just as the TCP Header Length, this one also is a measure of the length of the header in 32-bit sized words.
- Reserved (6 bits): This is reserved but I was not able to find out the specific purposes for its reservation. It could be a to aid in the identification of a packet when other things are mangled, but this is just theory.
- Urgent flag [URG] (1 bit): This specifies that the Urgent point included in this packet is valid.
- Acknowledgement flag [ACK] (1 bit): This specifies that the portion of the header that has the acknowledgement number is is valid.
- Push flag [PSH] (1 bit): This tells the TCP/IP stack that this should be pushed up to the Application Layer program that needs, or requires it as soon as time allows.
- Reset flag [RST] (1 bit): This is used to reset the connection.
- Synthesis flag [SYN] (1 bit): This is to Synchronize sequence numbers with acknowledgement numbers for both hosts, sometimes referred to synthesis of a connection. The former reference is more common, while the latter is more rare.
- Finish Flag [FIN] (1 bit): This is to specify that a connection is finished according to the side that sent the packet with the FIN flag set.
- Window size [WS] (16 bits): This specifies how many bytes may be received on the receiving side before being halted from sliding any further and receiving any more bytes as a result of a packet at the beginning of the sliding window not having been acknowledged or received.
- TCP Checksum [TCPCS] (16 bits):This is a checksum that covers the header and data portion of a TCP packet to allow the receiving host to verify the integrity of an incoming TCP packet.
- Urgent Pointer [UP] (16 bits): this allows for a section of data as specified by the Urgent pointer to be passed up by the receiving host quickly.
- Options (Variable bits if used): Seldom ever used.
- Data (Variable bits): As you might expect, this is the payload, or data portion of an TCP packet. The payload may be any number of application layer protocols. The most common are HTTP, Telnet, SSH, FTP, but other popular protocols also use TCP.
This ends the brief preview of an TCP packet.
- Comments and/or suggestions for this?: Email me at: dugan@passwall.com
- Attempts have been made to make the tables appear as they should for LYNX users by forcing a common field width for fields being used by padding them with other printable characters. This is meant to allow for LYNX users to see the tables much like the Netscape and other web browser worlds might show them. However, from personal experience, some versions of LYNX still manage to munge the tables, making them use up several pages. It seems to be a problem with how earlier versions of LYNX dealt with tables, but the problem has not been entirely isolated.
- Some have asked why this collection of on-line documents is so lacking of graphic content. To them I answer: faster downloads. Many of these pages are smaller than some pictures on many commercial web sites. You do not come here to look at my pictures. You come here to read content. Also, LYNX users benefit from this, and by using ALL text, people with ADA issues are able to use speech recognition software on the text to hear the words.
- Copyright (C) 1999, 2000, 2001, 2002 by Michael Egan: All rights reserved.
- A Special License: No part of this document may be used for profit without the consent of the author Michael Egan in writing. Content may be duplicated for retransmission for non-profit purposes as long as the copyright and license remain included in their entirety. The content is provided "as-is" and I take no responsibility on the content's truthfulness or consistency. Errors may exist in these documents, but acting upon these errors is left up to the reader to verify by a third party that will take responsibility for fact verification. When notified of errors or inconsistencies, attempts will be made to rectify the errors.
- In plan English this is meant to do many things: This copyright is meant to exist so that others may not profit from this work as published in paper form, or by duplicating the content to place advertisements over it and generate income. It is also meant to exist to prevent people from publishing this work as their own and receiving profit from this process on research they did not perform. It is not meant to stop a professor from running off copies to use in their classes for their students. It is also not meant to stop the student from printing up copies for their own education. How depressing it would be to find your work published in book form without your permission, or compensation. Another reason for this Copyright is to limit the effect of the mistakes I have made within this document before I was able to complete it. It would be even sadder to notice my mistakes in print and criticized before I could resolve them. Eventually, after I finish this work, I may retain copyright, but eliminate the license.