Ports are an important addition to network communication. But if that
were all the transport layer did, the application layer would be
left to cope with some common problems. Given the terrific complexity
and scale of the internet, it's no surprise that packets occasionally get
lost or delivered out of order. It sure would be nice
to have some kind of acknowledgment that the packet got through, that
way we could resend the packet if necessary and achieve more
reliable communication. And for larger messages that need to be broken up
into lots of smaller packets, it would be nice to
have some kind of numbering system so that if they arrived
out of order, they can be re-assembled. Moreover, we would like
to know if we are overwhelming the recipient with too many
packets too fast, or if we are causing congestion on
some link in the route, so that we can be a
good citizen and slow down. All of this functionality is provided
by the transmission control protocol, or TCP inside the transport layer.
TCP doesn't just start off firing packets towards some
destination without warning. The conversation begins and ends with a
polite handshake to mark the beginning and end of
an exchange. Once the connection is established, data can go
both ways from initial data to recipient and visa
versa. Let's take a look at an example. I'll use
some unrealistically small numbers to keep things simple. And
I'll rename the initiator G T and the recipient udacity.
At this point, the connection is pretty much symmetric. So
the vocabulary for the handshake becomes confusing. GT issues a
request and sets a push flag, meaning send me your
data, then Udacity begins transmission back. Great, but what if
one of the packets is dropped, that is to say
they don't make it across the internet? In our example,
let's suppose that the first packet doesn't make it. We
would like a way to detect the situation. Here's TCP solution.
After the initial handshake, packet or segments as they
are called in TCP parlance, indicate how much data
the other side should have received already, and also
how much data the sender has received. The former is
called the sequence number, and the later the acknowledgement
number. During the handshake both of these numbers get incremented
by one. In this scenario, TCP will be able
to detect the dropped packet, because the next message thinks
that nine bites is the amount that should have
been received. But in reality GT has only received
the initial acknowledgement. You might think that GT would
send the packet saying, could you resend that please. But
actually the system works by positive acknowledgements instead of
request or re-transmission. If the packet had gone through,
the traffic should have looks like this. So even
though GT doesn't really have anything to say to Udacity,
he should have been sending empty acknowledge packets to
Udacity, indicating that the packets were received. To make an
analogy to human conversation, this is like saying uh-huh periodically
to let the other person know you are listening. Going
back to the case where the first packet is
dropped, we now see that upon receiving the second packet,
GT would see that a packed has been dropped, and
simply won't acknowledge the first one or the later one.
After enough time has passed, Udacity will notice
that it hasn't received an acknowledgment for that first
packet and will re-transmit it. When GT receives the
re-transmitted package, he can now send an acknowledgment for
both packets, saying that he has received 17
bytes worth of data. Together, this system of acknowledgments
and sequence numbers helps achieve the first two goals.
I'll have to refer you to a networking class
for a more complete discussion of the third goal, but I
do want to briefly discuss the idea of window size. In this
example, udacity has sometimes sent out a packet before it receives
an acknowledgement of a previous one. This is typical for TCP
And how much one side is allowed to get ahead of
himself in the conversation is controlled by a window size parameter.
A good way to visualize this, is by drawing the data
that needs to be sent as a long bar and then
dividing it into the packets that actually get
sent. We have the packets that have been sent
and acknowledged, the ones that have been sent
but haven't been acknowledged yet, and the unsent packets.
This middle part, representing the packets sent out
but not acknowledged, represent the window. And as the,
during transmission, the window will slide across to the
right. The window size puts a limit on how
a wide this window can get. If the window is too
small, then it can slow the connection down as the sender
has to stop and wait for an acknowledgement for every packet.
If the window size is too big, then there's a risk that
it will over flaw the buffers of the recipient, or of
one of the hops along the way resulting in packet loss.
So it's important to get the window size right. You can
explore other aspects of TCP's flow and congestion control by following the
links in the instructor notes.