TCP Header
This is the TCP Header Format. The basic TCP header is 20 bytes in length. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
Source Port: 16 bitsThe source port number.
Destination Port: 16 bits
The destination port number.
Sequence Number: 32 bits
The sequence number of the first data octet in this segment
(except when SYN is present). If SYN is present the sequence
number is the initial sequence number (ISN) and the first
data octet is ISN+1.
Acknowledgement Number: 32 bits
If the ACK control bit is set this field contains the value of
the next sequence number the sender of the segment is expecting
to receive. Once a connection is established this is always
sent.
Data Offset: 4 bits The number of 32 bit words in the TCP Header. This indicates
where the data begins. The TCP header (even one including
options) is an integral number of 32 bits long.
Reserved: 6 bits
Reserved for future use. Must be zero.Control Bits: 6 bits (from left to right):
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Window: 16 bits
The number of data octets beginning with the one indicated
in the acknowledgment field which the sender of this segment
is willing to accept.
Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header and text. If a
segment contains an odd number of header and text octets to be
checksummed, the last octet is padded on the right with zeros to
form a 16 bit word for checksum purposes. The pad is not
transmitted as part of the segment. While computing the
checksum, the checksum field itself is replaced with zeros.
The checksum also covers a 96 bit pseudo header conceptually
prefixed to the TCP header. This pseudo header contains the
Source Address, the Destination Address, the Protocol, and TCP
length. This gives the TCP protection against misrouted segments.
This information is carried in the Internet Protocol and is
transferred across the TCP/Network interface in the arguments or
results of calls by the TCP on the IP.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
The TCP Length is the TCP header length plus the data length
in octets (this is not an explicitly transmitted quantity,
but is computed), and it does not count the 12 octets of the
pseudo header.
Urgent Pointer: 16 bits This field communicates the current value of the urgent
pointer as a positive offset from the sequence number in this
segment.
The urgent pointer points to the sequence number of the octet
following the urgent data. This field is only be interpreted
in segments with the URG control bit set.
Options: variable
Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option:
Case 1: A single octet of option-kind.
Case 2: An octet of option-kind, an octet of option-length,
and the actual option-data octets.
The option-length counts the two octets of option-kind and
option-length as well as the option-data octets.
Note that the list of options may be shorter than the data offset
field might imply. The content of the header beyond the
End-of-Option option must be header padding (i.e., zero).
A TCP must implement all options.
Currently defined options include (kind indicated in octal):
Kind Length Meaning
---- ------ -------
0 - End of option list.
1 - No-Operation.
2 4 Maximum Segment Size.
Specific Option Definitions
End of Option List
+--------+
|00000000|
+--------+
Kind=0
This option code indicates the end of the option list. This
might not coincide with the end of the TCP header according
to the Data Offset field. This is used at the end of all
options, not the end of each option, and need only be used
if the end of the options would not otherwise coincide with
the end of the TCP header.
No-Operation
+--------+
|00000001|
+--------+
Kind=1
This option code may be used between options, for example,
to align the beginning of a subsequent option on a word
boundary. There is no guarantee that senders will use this
option, so receivers must be prepared to process options
even if they do not begin on a word boundary.
Maximum Segment Size
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field must only be sent in the initial connection
request (i.e., in segments with the SYN control bit set).
If this option is not used, any segment size is allowed.
Padding: variable
The TCP header padding is used to ensure that the TCP
header ends and data begins on a 32 bit boundary. The
padding is composed of zeros.
TCP Overhead
As TCP is a connection-oriented protocol, this adds to the complexity and processing overhead of the protocol, these aspects include:
Connection establishment using the 3 Way Handshake, this involves a number of messages passing between the connection initiator and the connection responder prior to any data flowing between the two endpoints.
Acknowledgment of packets as they are received by the far end, adding to the message flow between the endpoints and thus the protocol load.
Checksum and Sequence number calculations - again a burden on a general purpose CPU to perform.
Sliding window calculations for packet acknowledgement and congestion control.
Connection termination.
TOE
TCP Offload Engine (TOE) is a technology used in network interface cards to offload processing of the entire TCP/IP stack to the network controller. It is primarily used with high-speed network interfaces, such as gigabit Ethernet and 10 gigabit Ethernet, where processing overhead of the network stack becomes significant.
TSO
TCP segmentation offloading (TSO) - reduce CPU overhead of TCP/IP on fast networks. the CPU can hand the NIC a block of data and a TCP header template, and then have the NIC produce a stream of TCP packets without requiring the CPU to touch the data at all. When large chunks of data are to be sent over a computer network, they need to be first broken down to smaller segments that can pass through all the network elements like routers and switches between the source and destination computers. This process is referred to as segmentation.
Segmentation is often done by the TCP protocol in the host computer. Offloading this work to the network card is called TCP segmentation offloading. With some intelligence in the NIC, the host CPU can hand over the 64 KB of data to the NIC in a single buffer, the NIC can break that buffer down into smaller segments of 1448 bytes, add the TCP, IP, and data link layer protocol headers -- according to a template provided by the host's TCP/IP stack -- to each segment, and send the resulting frames over the network. This significantly reduces the work done by the CPU.
First Created: 4 May 2007
No comments:
Post a Comment