TCP MAIN FEATURES AND BEHAVIOUR
AUTHOR: NIR SHAFRIR
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
BASED ON THE FOLLOWING RESOURCES:
The TCP/IP Guide - (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005
tcp-parameters page on (http://www.iana.org/assignments/tcp-parameters)
RFC 793 - Transmission Control Protocol - (http://www.faqs.org/rfcs/rfc793.html)
RFC1323 / RFC2018 / RFC1072 / RFC1693 / RFC1644 / RFC1146 / RFC2385 - (http://www.faqs.org/rfcs)
Wikipedia, the free encyclopedia – (http://en.wikipedia.org/wiki/Transmission_Control_Protocol)
TCP Data Stream Processing and Segment Packaging
Operation Of An Unreliable Protocol
Basic Reliability: Positive Acknowledgment With Retransmission (PAR)
This diagram shows one of the most common simple techniques for ensuring
reliability. Each time a message is sent by Device A, it starts a timer. Device B
sends an acknowledgment back to A when it receives a message so A know it
was successfully transmitted. If a message is lost, the timer goes off and A
retransmits the data. Note that only one message can be outstanding at any
time, making this system rather slow.
Enhanced Positive Acknowledgment With Retransmission (PAR)
This diagram shows two enhancements to the basic PAR scheme. First,
each message now has an identification number; each can be acknowledged
individually, so more than one can be in transit at a given time. Second, device
B regularly communicates to A a send limit parameter, which restricts the
number of messages A can have outstanding at once. B can adjust this
parameter to control the flow of data from A.
Conceptual Division of the TCP Transmission Stream Into Categories
Bytes Sent And Acknowledged: The earliest bytes in the stream will have been sent and acknowledged. These are
basically “accomplished” from the standpoint of the device sending data. For example, let's suppose that 31 bytes of
data have already been send and acknowledged. These would fall into Category #1.
Bytes Sent But Not Yet Acknowledged: These are the bytes that the device has sent but for which it has not yet
received an acknowledgment. The sender cannot consider these “accomplished” until they are acknowledged. Let's say
there are 14 bytes here, in Category #2.
Bytes Not Yet Sent For Which Recipient Is Ready: These are bytes that have not yet been sent, but which the
recipient has room for based on its most recent communication to the sender of how many bytes it is willing to handle
at once. The sender will try to send these immediately (subject to certain algorithmic restrictions we'll explore later).
Suppose there are 6 bytes in Category #3.
Bytes Not Yet Sent For Which Recipient Is Not Ready: These are the bytes further “down the stream” which the
sender is not yet allowed to send because the receiver is not ready. There are 44 bytes in Category #4.
TCP Transmission Stream Categories and Send Window Terminology
The Send Window and Usable Window
The key to the operation of the entire process is the number of bytes that the
recipient is allowing the transmitter to have unacknowledged at one time. This
is called the send window, or often, just the window. The window is what
determines how many bytes the sender is allowed to transmit, and is equal to
the sum of the number of bytes in Category #2 and Category #3. Thus, the
dividing line between the last two categories (bytes not sent that recipient is
ready for and ones it is not ready for) is determined by adding the window to
the byte number of the first unacknowledged byte in the stream. In our example
above, the first unacknowledged byte is #32. The total window size is 20.
Processing Acknowledgments and Sliding the Send Window
When the sending device receives this acknowledgment, it will be able to transfer some
of the bytes from Category #2 to Category #1, since they have now been acknowledged.
When it does so, something interesting will happen. Since five bytes have been
acknowledged, and the window size didn't change, the sender is allowed to send five
more bytes. In effect, the window shifts, or slides, over to the right in the timeline. At the
same time five bytes move from Category #2 to Category #1, five bytes move from
Category #4 to Category #3, creating a new usable window for subsequent transmission.
So, after receipt of the acknowledgment, the groups will look like this
TCP “Three-Way Handshake” Connection Establishment Procedure
This diagram illustrates how a conventional connection is established between a client and server, showing
the three messages sent during the process and how each device transitions from the CLOSED state
through intermediate states until the session is ESTABLISHED.
TCP Simultaneous Open Connection Establishment Procedure
This diagram shows what happens when two devices try to open a connection to each other at the same
time. In this case instead of a three-way handshake, each sends a SYN and receives an ACK. They each
follow the same sequence of states, which differs from both sequences in the normal three-way
handshake.
TCP Connection Termination Procedure (Normal / Simultaneous)
This diagram shows the conventional termination Under certain circumstances both devices may decide
procedure for a TCP session, with one device initiating to terminate a connection simultaneously, or nearly
termination and the other responding. In this case the simultaneously. In this case each sends a FIN and
client initiates; it sends a FIN which is acknowledged before getting an ACK for it, receives the other device’s
by the server. The server waits for the server process FIN. Each acknowledges the other’s FIN and waits for a
to be ready to close and then sends its FIN, which is period of time before closing the connection. Note the
acknowledged by the client. The client waits for a transition through the CLOSING state, which is only
period of time to ensure that its ACK is received, used as part of simultaneous termination
before proceeding to the CLOSED state.
THE TCP PACKET DESCRIPTION
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
Source Port: 16 bits
The source port number.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
Destination Port: 16 bits
The destination port number.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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.
Sequence Number: 32 bits (cont.)
A fundamental notion in the design is that every octet of data sent over a TCP
connection has a sequence number.
Since every octet is sequenced, each of them can be acknowledged.
The acknowledgment mechanism employed is cumulative so that an
acknowledgment of sequence number X indicates that all octets up to but not
including X have been received.
This mechanism allows for straight-forward duplicate detection in the presence
of retransmission.
Numbering of octets within a segment is that the first data octet immediately
following the header is the lowest numbered, and the following octets are
numbered consecutively.
It is essential to remember that the actual sequence number space is finite,
though very large.
This space ranges from 0 to 2^32 - 1. Since the space is finite, all arithmetic
dealing with sequence numbers must be performed modulo 2^32.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
Acknowledgment 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.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
Reserved: 6 bits
Reserved for future use. Must be zero.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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
Control Bits: 6 bits (cont.):
URG: A control bit (urgent), occupying no sequence space, used to indicate
that the receiving user should be notified to do urgent processing as long as
there is data to be consumed with sequence numbers less than the value
indicated in the urgent pointer.
ACK: A control bit (acknowledge) occupying no sequence space, which
indicates that the acknowledgment field of this segment specifies the next
sequence number the sender of this segment is expecting to receive, hence
acknowledging receipt of all previous sequence numbers.
PSH: A control bit (push) occupying no sequence space, indicating that this
segment contains data that must be pushed through to the receiving user.
RST: A control bit (reset), occupying no sequence space, indicating that the
receiver should delete the connection without further interaction. The receiver
can determine, based on the sequence number and acknowledgment fields of
the incoming segment, whether it should honor the reset command or ignore it.
In no case does receipt of a segment containing RST give rise to a RST in
response.
Control Bits: 6 bits (cont.):
SYN: A control bit in the incoming segment, occupying one sequence number,
used at the initiation of a connection, to indicate where the sequence
numbering will start.
FIN: A control bit (finis) occupying one sequence number, which indicates that
the sender will send no more data or control occupying sequence space.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
Checksum: 16 bits (cont.)
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.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
Options: variable (cont.)
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.
Options: variable (cont.)
Kind Length Meaning
0 - End of option list.
1 - No-Operation.
2 4 Maximum Segment Size.
Specific Option Definitions:
End of Option List
Kind=0 00000000
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
Kind=1 00000001
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.
Options: variable (cont.)
Maximum Segment Size:
Kind=2 Length=4 00000010 00000100 max seg size max seg size (cont.)
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.
These are the original options.
The aditional options are listed and discribed here.
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Source Port Destination Port
32 Sequence Number
64 Acknowledgement Number
Flags
96 Data Offset Reserved U A P R S F Window
R C S S Y I
G K H T N N
128 Checksum Urgent Pointer
160 Options (optional)
192 Options (cont.) Padding (to 32)
224
Data
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 MAIN FEATURES AND BEHAVIOUR
THE END
FULL TCP OPTIONS LIST
Kind Length Meaning Kind Length Meaning
0 - End of option list. [RFC793] 13 CC.ECHO [RFC1644]
1 - No-Operation. [RFC793] 14 3 TCP Alternate Checksum Request [RFC1146]
2 4 Maximum Segment Size. [RFC793] 15 N TCP Alternate Checksum Data [RFC1146]
3 3 WSOPT - Window Scale [RFC1323 ] 16 Skeeter [Knowles]
4 2 SACK Permitted [RFC2018 ] 17 Bubba [Knowles]
5 N SACK[RFC2018 ] 18 3 Trailer Checksum Option [Subbu & Monroe]
6 6 Echo (obsoleted by option 8) [RFC1072 ] 19 18 MD5 Signature Option [RFC2385]
7 6 Echo Reply (obsoleted by option 8) [RFC1072 ] 20 SCPS Capabilities [Scott]
8 10 TSOPT - Time Stamp Option [RFC1323 ] 21 Selective Negative Acknowledgements [Scott]
9 2 Partial Order Connection Permitted [RFC1693 ] 22 Record Boundaries [Scott]
10 3 Partial Order Service Profile[RFC1693 ] 23 Corruption experienced [Scott]
11 CC [RFC1644 ] 24 SNAP [Sukonnik]
12 CC.NEW [RFC1644 ] 25 Unassigned (released 12/18/00)
26 TCP Compression Filter [Bellovin]
FULL TCP OPTIONS LIST (cont.)
TCP Window Scale Option (WSopt):
Kind=3 Length=3 bytes 00000011 00000011 Shift.cnt
This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable
window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true
receive-window values by 'shift.cnt' bits for transmission in SEG.WND. The value 'shift.cnt' may be zero (offering to
scale, while applying a scale factor of 1 to the receive window). This option may be sent in an initial segment
(i.e., a segment with the SYN bit on and the ACK bit off). It may also be sent in a segment, but only if a
Window Scale op- tion was received in the initial segment. A Window Scale option in a segment without a SYN
bit should be ignored. The Window field in a SYN (i.e., a or ) segment itself is never scaled.
Sack-Permitted Option:
Kind=4 Length=2 00000100 00000010
This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) the
SACK option once the connection has opened. It MUST NOT be sent on non-SYN segments. TCP Sack-Permitted
TCP SACK Option:
Kind=5 Length=Variable
The SACK option is to be sent by a data receiver to inform the data sender of non-contiguous blocks of data that have
been received and queued. The data receiver awaits the receipt of data (perhaps by means of retransmissions) to fill
the gaps in sequence space between received blocks. When missing segments are received, the data receiver
acknowledges the data normally by advancing the left window edge in the Acknowledgement Number Field of the TCP
header. The SACK option does not change the meaning of the Acknowledgement Number field. This option contains a
list of some of the blocks of contiguous sequence space occupied by data that has been received and queued within
the window.
FULL TCP OPTIONS LIST (cont.)
TCP Echo Option:
Kind=6 Length=6 00000110 00000110 4 bytes of info to be echoed ... ... ...
This option carries four bytes of information that the receiving TCP may send back in a subsequent TCP Echo Reply
option (see below). A TCP may send the TCP Echo option in any segment, but only if a TCP Echo option was received
in a SYN segment for the connection. When the TCP echo option is used for RTT measurement, it will be included in
data segments, and the four information bytes will define the time at which the data segment was transmitted in any
format convenient to the sender.
TCP Echo Reply Option:
Kind=7 Length=6 00000111 00000110 4 bytes of echoed info ... ... ...
A TCP that receives a TCP Echo option containing four information bytes will return these same bytes in a TCP Echo
Reply option. This TCP Echo Reply option must be returned in the next segment (e.g., an ACK segment) that is sent. If
more than one Echo option is received before a reply segment is sent, the TCP must choose only one of the options to
echo, ignoring the others; specifically, it must choose the newest segment with the oldest sequence number. To use the
TCP Echo and Echo Reply options, a TCP must send a TCP Echo option in its own SYN segment and receive a TCP
Echo option in a SYN segment from the other TCP. A TCP that does not implement the TCP Echo or Echo Reply
options must simply ignore any TCP Echo options it receives. However, a TCP should not receive one of these options
in a non-SYN segment unless it included a TCP Echo option in its own SYN segment.
TCP Timestamps Option (TSopt):
Kind=8 Length=10 00001000 00001010 TS Value (TSval) .. .. .. TS Echo Reply (TSecr) .. .. ..
The Timestamps option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current
value of the timestamp clock of the TCP sending the option. The Timestamp Echo Reply field (TSecr) is only valid if the
ACK bit is set in the TCP header; if it is valid, it echos a times- tamp value that was sent by the remote TCP in the
TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be
from the most recent Timestamp option that was received; A TCP may send the Timestamps option (TSopt) in an initial
segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if
it re- ceived a TSopt in the initial segment for the connection.
FULL TCP OPTIONS LIST (cont.)
TCP POC-permitted Option:
Kind=9 Length= 2 00001001 00000010
TCP POC-service-profile Option:
Kind=10 Length=3 00001010 00000011 Start_flag (1bit) | End_flag (1bit) | Filler (6bit)
CC Option:
Kind=11 Length=6 00001011 00000110 Connection Count: SEG.CC .. .. ..
This option may be sent in an initial SYN segment, and it may be sent in other segments if a CC or CC.NEW option has
been received for this incarnation of the connection. Its SEG.CC value is the TCB.CCsend value from the sender's
TCB.
CC.NEW Option
Kind: 12 Length: 6 00001100 00000110 Connection Count: SEG.CC .. .. ..
This option may be sent instead of a CC option in an initial segment (i.e., SYN but not ACK bit), to indicate that
the SEG.CC value may not be larger than the previous value. Its SEG.CC value is the TCB.CCsend value from the
sender's TCB.
CC.ECHO Option
Kind: 13 Length: 6 00001101 00000110 Connection Count: SEG.CC .. .. ..
This option must be sent (in addition to a CC option) in a segment containing both a SYN and an ACK bit, if the initial
SYN segment contained a CC or CC.NEW option. Its SEG.CC value is the SEG.CC value from the initial SYN. A
CC.ECHO option should be sent only in a segment and should be ignored if it is received in any other
segment.
FULL TCP OPTIONS LIST (cont.)
TCP Alternate Checksum Request Option:
Kind=14 Length=3 00001110 00000011 chksum
Here chksum is a number identifying the type of checksum to be used. The currently defined values of chksum are:
0 -- TCP checksum
1 -- 8-bit Fletcher's algorithm
2 -- 16-bit Fletcher's algorithm
3 -- Redundant Checksum Avoidance [Kay]
TCP Alternate Checksum Data Option:
00001111 N DATA ... ... DATA
Kind=15 Length=N
This field is used only when the alternate checksum that is negotiated is longer than 16 bits. These checksums will not
fit in the checksum field of the TCP header and thus at least part of them must be put in an option. Whether the
checksum is split between the checksum field in the TCP header and the option or the entire checksum is placed in the
option is determined on a checksum by checksum basis.