|
Connection
Oriented
What this basically means is that
a connection is established between the two hosts or
rather, the two computers, before any data is
transferred. When the term "connection
is established" is used,
this means that both computers know about each other and
have agreed on the exchange of data. This is also where
the famous 3-way handshake happens. You will find the
SYN
and
ACK bits in the Code bits
field which are used to perform the 3-way handshake.
Thanks to the 3-way handshake, TCP is connection
oriented.
The following diagram explains the procedure of the
3-way handshake:
STEP 1:
Host A
sends the initial packet to
Host B.
This packet has the
"SYN"
bit enabled.
Host B
receives the packet and sees the
"SYN"
bit which has a value of "1" (in binary, this means ON)
so it knows that Host A
is trying to establish a
connection with it.
STEP 2:
Assuming
Host B
has enough resources, it sends a
packet back to Host A
and with the
"SYN
and ACK"
bits enabled (1). The
SYN
that Host B
sends, at this step, means 'I want
to synchronise with you' and the
ACK
means 'I acknowledge your previous
SYN
request'.
STEP 3:
So... after all that,
Host A
sends another packet to
Host B
and with the
"ACK"
bit set (1), it effectively tells
Host B
'Yes, I acknowledge your previous
request'.
Once the 3-way handshake is
complete, the connection is
established (virtual
circuit) and the data transfer begins.
Flow Control
Flow control is used to control the data flow between
the connection. If for any reason one of the two hosts
are unable to keep up with the data transfer, it is able
to send special signals to the other end, asking it to
either stop or slow down so it can keep up.
For example, if
Host B
was a webserver from which people
could download games, then obviously
Host A
is not going to be the only
computer downloading from this webserver, so
Host B
must regulate the data flow to
every computer downloading from it. This means it might
turn to Host A
and tell it to wait for a while
until more resources are available because it has
another 20 users trying to download at the same time.
Below is a diagram that illustrates a simple flow
control session between two hosts. At this point, we
only need to understand the concept of flow control:
Generally speaking, when a machine receives a flood of
data too quickly for it to process, it stores it in a
memory section called a buffer. This buffering
action solves the problem only if the data bursts are
small and don't last long.
However, if the data burst
continues it will eventually exhaust the memory of the
receiving end and that will result in the arriving data
being discarded. So in this situation the receiving end
will simply issue a "Not
ready" or "Stop"
indicator to the sender, or source of the flood. After
the receiver processes the data it has in its memory, it
sends out a "Ready"
or "Go"
transport indicator and the sending machine receives the
"Go"
indicator and resumes its transmission.
Windowing
Data throughput, or transfer
efficiency, would be low if the transmitting machine had
to wait for an acknowledgment after sending each packet
of data (the correct term is segment as we will
see on the next page). Because there is time available
after the sender transmits the data segment and before
it finishes processing acknowledgments from the
receiving machine, the sender uses the break to transmit
more data. If we wanted to briefly define
Windowing
we could do so by stating that it is the number of data
segments the transmitting machine is allowed to send
without receiving an acknowledgment for them.
Windowing
controls how much information is
transferred from one end to the other. While some
protocols quantify information by observing the number
of packets, TCP/IP measures it by counting the number of
bytes.
Let's explain what is happening in the above diagram.
Host B
is sending data to
Host A,
using a window size equal to one. This means that
Host B
is expecting an
"ACK"
for each data segment it sends to
Host A.
Once the first data segment is sent,
Host A
receives it and sends an
"ACK 2"
to Host B.
You might be wondering why
"ACK 2" and not just
"ACK"?
The "ACK
2" is translated by
Host B
to say: 'I acknowledge
(ACK)
the packet you just sent me and I am ready to receive
the second (2)
segment'. So
Host B
gets the second data segment ready
and sends it off to Host A,
expecting an "ACK 3"
response from
Host A
so it can send the third data
segment for which, as the picture shows, it receives the
"ACK 3".
However, if it received an
"ACK 2"
again, this would mean something
went wrong with the previous transmission and
Host B
will retransmit the lost segment. We will see how this
works in the Acknowledgments section later on. Let's now
try a different Window size to get a better
understanding.. let's say 3!
Keep in mind the way the
"ACK's"
work, otherwise you might find the
following example a bit confusing. If you can't
understand it, read the previous example again where the
Window size was equal to one.
In the above example, we have a
window size equal to 3, which means that
Host B
can send 3 data segments to
Host A
before expecting an
"ACK"
back. Host B
sends the first 3 segments (Send
1, Send 2 and Send 3), Host
A receives them all in good
condition and then sends the
"ACK 4"
to
Host B. This means that
Host A
acknowledged the 3 data segments
Host B
sent and awaits the next data
segments which, in this case, would be 4, 5 and 6.
Acknowledgments
Reliable data delivery ensures the
integrity of a stream of data sent from one machine to
the other through a fully functional data link. This
guarantees the data won't be duplicated or lost. The
method that achieves this is known as
positive acknowledgment with
retransmission. This
technique requires a receiving machine to communicate
with the transmitting source by sending an
acknowledgment message back to the sender when it
receives data. The sender documents each segment it
sends and waits for this acknowledgment before sending
the next segment. When it sends a segment, the
transmitting machine starts a timer and retransmits if
it expires before an acknowledgment is returned from the
receiving end.
This figure shows how the
Acknowledgments work. If you examine the diagram closely
you will see the window size of this transfer which is
equal to 3. At first,
Host B
sends 3 data segments to
Host A
and they are received in perfect
condition so, based on what we learned,
Host A
sends an
"ACK 4"
acknowledging the 3 data segments and requesting the
next 3 data segments which will be 4, 5, 6. As a result,
Host B
sends data segments 4, 5, 6 but 5
gets lost somewhere along the way and
Host A
doesn't receive it so, after a bit
of waiting, it realises that 5 got lost and sends an
"ACK 5"
to Host B,
indicating that it would like data
segment 5 retransmitted. Now you see why this method is
called "positive
acknowledgment with retransmission".
At this point
Host B
sends data segment 5 and waits for
Host A
to send an "ACK"
so it can continue sending the
rest of the data. Host A receives the 5th data segment
and sends "ACK 7"
which means 'I received the previous data segment, now
please send me the next 3'. The next step is not shown
on the diagram but it would be Host B sending data
segments 7, 8 and 9.
More Overhead
As you can see, there is quite a neat mechanism under
the TCP hood that enables data to be transferred error
free. All the features the protocol supports come at a
price, and this is the overhead associated with TCP.
When we talk about overhead, we
are referring to all the different fields contained
within the TCP header and error checking that takes
place to ensure no portion of the data is corrupt. While
for most this is a fair trade off, some people simply
can't spare the extra processing power, bandwidth and
increased time the TCP transactions require, for this
reason we have the alternative UDP protocol, which you
can read about in the
UDP protocol section.
At this point our quick overview of the TCP has reached
its conclusion. From the next page onwards, we start to
dive in deeper, so take a deep breath and jump right
into it!
|
