|
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-2009 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).
Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
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
- In no way this site is associated with or endorse cybersquatters
using
the term "softpanorama" with other main or country domains (e.g. softpanorama.com) with
bad faith intent to profit from the goodwill belonging to
someone else.
Last Modified:
August 14, 2009