|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
TCP Protocol
Introduction
Reliability
TCP Headers
TCP Flow Control
TCP protocol is defined in RFC 793. The objective of TCP is to provide a reliable, connection-oriented
delivery service. TCP views data as a stream of bytes, not frames. The unit of transfer
is refered to as a segment. To provide the connection-oriented service, TCP takes
care to ensure reliability, flow control, and connection maintainence.
TCP is suited to the situation when large volume of data are
transmitted between systems possibly across multiple routers. TCP has four main features:
- Virtual circuit connection
- Full-duplex connection
- Unstructured stream orientation
- Buffered transfer
Here are those four features in detail:
- Full-Duplex Connection. TCP connections provide concurrent transfer in both directions. According to
the application, a full-duplex connection consists of two independent streams that
flow in opposite directions. Each segment of data receives is acknowledges with
special ACK packet. The TCP protocol software sends control information
for one stream back to the source in the segments that carry data in the opposite
direction. This process is called piggybacking, and it reduces network traffic.
- Unstructured Stream Orientation. Data originating from the Application layer flows to TCP as a stream of bytes.
This stream of bytes is divided into packets called segments. TCP segments have a leading header section that contains control information
including so called sequence number, source
and destination port numbers, and a data section. The content in the data section
is not read or translated by TCP. TCP then sends the segments to the Internet layer
for encapsulation and delivery.
- Buffered Transfer. Data that comes from the application is a flowing stream. Data can flow fast
or slow. To ensure the efficient flow of data to and from the application, TCP provides
both input and output buffers to regulate the flow of data. The input and output
buffers also allow the application to see TCP as a full-duplex connection.
To ensure reliability, TCP is able to recover from data that is damaged, lost,
duplicated, or delivered out of sequence. In order to do this, TCP assigns a sequence
number to each byte transmitted. The receiving host's TCP must return an ACK for
bytes received within a specified period. If this is not done, the data is retransmitted.
Damaged data is handled by adding a checksum to each segment. If a segment is detected
as damaged by the receiving host's TCP, it will discard the segment. The sender
will resend the segment since the ACK was never sent.
All IP packets have
at least one header, which is known as the IP header; sometimes this
header is also called a Layer 3 or network header. The IP header is
simply a series of bits which have been grouped into fields of a set
size. All IP headers have the same structure; the only difference will
be which bits have been set to "1" to either turn on a field's value or
to represent a binary number within a field. Let's take a closer look at
the fields in an IP header:
| 4 |
8 |
16 |
32 bits |
| Ver. |
IHL |
Type of service |
Total length |
| Identification |
Flags |
Fragment offset |
| Time to live |
Protocol |
Header checksum |
| Source address |
| Destination address |
| Option + Padding |
| Data |
An IP packet has 14 fields and occupy six 32-bit words; let's go through these fields one at a
time.
- Version
This is a 4-bit field that indicates the IP version, written in binary.
For example if you are using IPv4, the bits will be set to 0100; if you
are using IPv6, the bits will be set to 0110.
- IHL or header length This 4-bit field indicates how long the IP packet header is; this value
is used to distinguish which part of the IP packet is the header, and
which part is the actual data. If you take a look at the picture of the
IP packet, you'll notice that it is 32 bits wide. Now take a look at the
length of the packet: the data is not part of the header, the options
are optional, but all other fields are required. This means that the
minimum header length is five 32-bit words, or binary 0101. You'll
sometimes see these words translated into bytes; that is, five words
multiplied by 4 bytes (32 bits divided by 8 bits to make a byte) equals
a header length of 20 bytes. If the options are used, the header length
will be at least six 32-bit words. Since this is a 4-bit field, the
maximum length will be 2 to the power of 4 minus 1, or 15. This
effectively limits the size of an IP header to 60 bytes (15 words
multiplied by 4 bytes).
- Type of Service (sometimes called TOS) flags This field is 8 bits long; the first 3 bits are called precedence bits
and the last 5 bits represent the type of service flags. These flags
were originally created to prioritize which packets should be delivered
and which packets could be dropped if a router became congested. Since
then, other protocols have been invented to prioritize traffic and most
routers ignore these flags even if they have been set.
- Total length; also called packet length or datagram length
This 16-bit field represents the total length of the IP packet, meaning
both the data and the header. The minimum size is 21 bytes (default
header size plus one byte of data). Since this field is 16 bits long,
the maximum packet size is 2 to the power of 16 minus one, or 65,535
bytes. (The minus one represents the illegal length value of 0.)
- Identification. Every IP packet is given an identification number when it is created;
that number is contained within this 16-bit field. It is possible for an
IP packet to be separated into smaller "fragments" before it reaches its
final destination; each fragment still belongs to the original IP
packet, so each fragment will have the same identification number.
- Flags
This field contains three flags as follows:
- reserved flag: must always be 0
- don't fragment flag: if set to 0, this flag is off, meaning you
can fragment the IP packet; if set to 1, this flag is on, meaning
you don't fragment this IP packet
- more fragments flag: if set to 0, there are no more fragments;
if set to 1, there are more fragments of this IP packet yet to
arrive
- Fragment offset. If an IP packet has been fragmented, each fragment will have a value in
this 13-bit field indicating where this fragment's data fits into the
original IP packet. For example, let's pretend an IP packet containing
128 bytes of data was fragmented into two fragments each containing 64
bytes of data. The fragment containing the first 64 bytes of data would
have a fragment offset of 0 as its data belongs at the very beginning of
the original IP packet. The fragment containing the last 64 bytes of
data needs to indicate that its data starts after the first 64 bytes.
Since the number in this field represents an 8-byte multiple, its
fragment offset will be 8 (8 multiplied by 8 = 64 bytes).
- Time to Live (often called TTL)
Whenever an IP packet passes through a router, the router will decrease
the TTL by one; if the TTL ever reaches 0, the packet will be thrown
away under the assumption that it must be undeliverable as it hasn't
been delivered by now. The original TTL value depends upon the operating
system; your FreeBSD system uses a default TTL of 64. Since this is an
8-bit field, the maximum allowable TTL is 255 (2 to the power of 8 minus
1; the minus 1 is for the non-allowable TTL of 0).
- Protocol. This 8-bit value specifies which protocol's data is contained within the
IP packet and gives a good indication of what type of information will
be contained within the data portion of the packet. The protocol numbers
that appear in this field are found in the "/etc/protocols" file on your
FreeBSD system.
- For example, the protocol number 1 represents the ICMP protocol. This
means that this IP packet does not contain any data from an application;
instead, it contains a small amount of ICMP data. We'll be taking an
in-depth look at ICMP and how it affects your firewall in a separate
article.
- A protocol number of 6 indicates the TCP protocol. You may remember
from earlier articles that TCP is a connection-oriented transport. This
IP packet will have an additional header known as a TCP header that will
be located just after the IP header and before the beginning of the
actual data that is being delivered.
- A protocol number of 17 indicates the UDP protocol, which is the
connectionless transport. This IP packet will have a UDP header located
just after the IP header and before the beginning of the data that is
being delivered.
- Header Checksum. Whenever an IP header is created or modified, a CRC (cyclic redundancy
check) is run on the bits contained within the IP header. Basically,
some math (the CRC algorithm) is done which results in an answer known
as the checksum. When the IP packet is received, the same CRC is
repeated on the header; if this results in the same answer (checksum),
all of the bits of the IP header must have arrived in the correct order.
If the CRC results in a different checksum, some of the bits in the
header didn't arrive, meaning the IP packet was somehow damaged during
transit.
- Source Address.
This will be the IP address of the host that sent the IP packet.
- Destination Address. This will be the IP address of the host that is to receive the data
contained within the IP packet.
- Options and Padding. This is the only field in an IP packet which is optional, as all other
fields are mandatory. This field is used to provide special delivery
instructions not covered by the other fields in an IP header. It can
allow for up to 40 bytes worth of extra instructions; these instructions
must be in 32-bit words. If an instruction doesn't quite fill up a
32-bit word, the missing bits will be filled in with "padding" bits.
- Data. The last field in an IP packet is called the data field. This will be
the actual data that is being sent from one host to another. The data
field may start with a Layer 4 header, which will give additional
instructions to the application that will be receiving the data;
alternately, it may be an ICMP header and not contain any user data at
all.
Now that we've
examined what is contained in a Layer 3 (IP)
header, let's move on to the Layer 4 header. A Layer 4 header occurs at
the very beginning of the IP data field and can be either a TCP header
or a UDP header. Let's start with the fields that will be found in a
Layer 4 TCP header:
| 16 |
32 bits |
| Source port |
Destination port |
| Sequence number |
| Acknowledgement number |
| Offset |
Reserved |
U |
A |
P |
R |
S |
F |
Window |
| Checksum |
Urgent pointer |
| Option + Padding |
| Data |
Note that a TCP header is also composed of 32-bit words; like an IP
header, the default size is 20 bytes if the option field is not used.
Let's summarize the fields that are available in a TCP header:
- Source Port This 16-bit number represents the name of the application that sent the
data in the IP packet. On your FreeBSD system, the file
/etc/services lists which applications use which port numbers. There are 65,535 possible port numbers (2
to the power of 16 minus 1).
- Destination Port. This 16-bit number represents the name of the application that is to
receive the data contained within the IP packet. This is one of the
major differences between a Layer 3 and a Layer 4 header: the Layer 3
header contains the IP address of the
computer that is to receive the IP packet; once that packet has been
received, the port address in the Layer 4 header ensures that the data
contained within that IP packet is passed to the correct application on
that computer.
- Sequence Number. TCP is responsible for ensuring that all IP packets sent are actually
received. When an application's data is packaged into IP packets, TCP
will give each IP packet a sequence number. Once all the packets have
arrived at the receiving computer, TCP uses the number in this 32-bit
field to ensure that all of the packets actually arrived and are in the
correct sequence.
- Acknowledgement Number. This number is used by the receiving computer to acknowledge which
packets have successfully arrived. This number will be the sequence
number of the next packet the receiver is ready to receive.
- Header Length or Offset. This is identical in concept to the header length in an IP packet,
except this time it indicates the length of the TCP header.
- Reserved. These 6 bits are unused and are always set to 0.
- Control Flags. TCP uses six control flags with each flag being a unique bit. If the bit
is set to 1, the flag is on; if the bit is set to 0, the flag is off.
The order of the flags is:
- URGent
- ACKnowledgement
- PuSH
- ReSeT
- SYNchronize
- FINish
We'll be seeing these flags again when we run "tcpdump" and when we
take a look at creating packet filter rules.
- Window Size.
Every TCP packet contains this 16-bit value that indicates how many
octets it can receive at once. When IP packets are received, they are
placed in a temporary area of RAM known as a buffer until the receiving
computer has a chance to process them; this value represents how big a
buffer the receiving host has made available for this temporary storage
of IP packets.
- Checksum.
Unlike IP, TCP is responsible for ensuring that the entire IP packet
arrived intact. TCP will run a CRC on the entire IP packet (not just the
header) and place the resulting checksum in this field. When the IP
packet is received, TCP re-runs the CRC on the entire packet to ensure
the checksum is the same.
- Urgent Pointer. If the Urgent flag was set to on, this value will indicate where the
urgent data is located.
- Options and Padding. Like IP options, this field is optional and represents additional
instructions not covered in the other TCP fields. Again, if an option
does not fill up a 32-bit word, it will be filled in with padding bits.
- Data. This will be the actual data being sent and will not include any
additional headers.
Introduction
TCP is more than a basic send-receive-acknowledge-send progression. TCP has sophisticated
algorithms to optimize flow control on both the sender side and the receiver side.
The algorithm that implements flow
control on both the sender side and the receiver side follows what is known as the
sliding window principle.
Receiver-Side Window Advertisements
A TCP window advertisement determines the maximum amount of data that can be
sent before the sender must wait for an acknowledgement from the receiver. By advertising
its window size, the receiver side manages flow control. With window advertisements,
the receiving host continually informs the sending host of how much data it is prepared
to receive.
Each TCP segment from the receiver carries an acknowledgement and a window advertisement.
Each acknowledgement specifies how many bytes have been received, and each window
advertisement specifies how many additional bytes the receiver is prepared to accept.
The size contained in the window advertisements varies over time; therefore, it
is considered a sliding window.
Sender-Side Congestion Window
To avoid network congestion, TCP on the sender side maintains a congestion window.
The congestion window adjusts the amount of data that can be sent according to the
number of segments that were recently lost or acknowledged in transit. Lost segments
are detected if a transmission timeout occurs before an acknowledgement is received.
As acknowledgements begin to be received, TCP doubles the size of the congestion
window. If congestion is detected, the congestion window halves in size. If congestion
continues, the congestion window can be halved multiple times.
Depending upon the severity of the congestion, TCP can use either a slow-start
or congestion-avoidance algorithm to begin to increase the size of the congestion
window. The slow-start algorithm quickly increases window size by doubling it for
each successful transmission. The congestion-avoidance algorithm slowly increases
the window’s size by increasing it only one segment at a time for each successful
transmission.
TCP Large Window
The Solaris implements RFC 1323, which allows larger TCP window advertisement
sizes to enhance performance over high-delay, high-bandwidth networks, such as satellite
networks.
A standard TCP header uses a 16-bit field to report the receiver window size
to the sender. Therefore, the largest window that can be used is 216 or 64 Kbytes.
RFC 1323 introduces a mechanism to increase the window size
to 230 or 1 Gbyte.
Sequence Numbers
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.
Q1. TCP stands for _____________________ ?
A: Transmission Control
Protocol
Q2. TCP is
________ and ____________ ?
a.
connectionless, stateless
b.
connection-orineted, stateless
c.
connection-oriented, stateful
d.
connectionless, stateful
A: C
Q3.
Full Duplex Connection consists of ___ independent streams of data.
Ans: 2
Q4. Receiving
host informs header of how much it is ready to receive. This is called
________________ ?
A: Window Advertisement
Q5.
T/F: There is no way to inform TCP of congestion along the path
A:
True
Q6. What is spoofing?
a.
Where a packets claims its source to be other that what its source really
is.
b.
Same as "denial of service" attacks
c.
Where a machine continually pings another machine
d.
Where certain broadcasts are passed through a router
A:
A
NOTE: There is protection built-in in IPv6 to against spoofing
Q6. Sequence Number in a
TCP header is used for (list all that apply)
a. acknowledgements
b. upper layer
information
c. reordering of the
octets received
d. protocol dependent
information
e. rejecting the
duplicate octets
A:
A,C,E
Q7. What is "keepalive”?
a.
A keepalive is a small, layer-1 bit message that is transmitted by a
network device to
let directly-connected network devices know of its presence.
b. A keepalive is a
small, layer-2 message that is transmitted by a
network device to
let directly-connected network devices know of its presence.
c. A keepalive is a
small, layer-2 message that is transmitted by a
network device to
let it neighbors know of congestion
d. A keepalive is a
small, layer-3 message that is transmitted by a
network device to
let directly-connected network devices know of its presence.
e. A keepalive is a
small, layer-3 message that is transmitted by a
network device to
let it neighbors know of congestion
A:
B
Q8.
What is flow control ?
a.
To keep the transmitting device from transmitting no faster than the
receiving device can receive.
b.
To find the best route to a destination
c.
To determine which machine transmits packets on the wire on a given
instance.
d.
To be able to send a beacon message when congestion occurs.
A:
A
Q9.
Which of the following methods are used as flow control ?
Choose 3
a.
Acknowledgements
b.
Windowing
c.
Traceroute
d.
TTL
e.
Sliding windows
A:
A,B,E
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last Modified:
February 28, 2008