It is a nice comfort to be able to rely on something
and have it happen.
And so many applications, such as HTTP, and SSH and telnet--
those application layer services use, at the transport layer,
TCP.
And one of the benefits of using TCP
is that it's connection-oriented and reliable.
Meaning, there are going to be sequence numbers
and acknowledgment numbers to validate
that the communications are working between the two
devices.
And one of the terms that I've heard thrown around
is a thing called the Protocol Data Unit, which I just
don't ever imagine using that phrase in a conversation
with a friend.
Instead of calling it a protocol data unit,
we'd simply call it a segment, for example, if we're
talking about data at layer 4.
Or we would call a protocol data unit at layer 3, the network
layer, we call that a packet, or layer 2, we
refer to that protocol data unit as a frame.
And that layer 1, the physical layer,
we're just dealing with individual bits.
So those would be the quote unquote "protocol data units"
at those respective layers.
And as traffic is moved across the network,
various network devices focus on and pay close attention
to various layers.
And so for the purpose of moving a packet, for example,
between one network and another, that
would be a router's function.
And it's focusing on the information at the network
layer inside of each packet.
We also have some devices on our networks called switches.
And one of the advantages of a layer 2 switch
is it has the ability to look at the information at layer 2
in the frames and make forwarding
decisions on a local network based on that information
and frame.
And then we have devices that the physical layer like
a hub, or a physical network adapter card,
or cables that are all considered
to be layer 1 devices because they
don't focus or process on anything higher in the protocol
stack.
I wanted to focus, in this Nugget,
also on the TCP three-way handshake, which
is the magic which allows TCP to do
connection-oriented and reliable communications between itself
and another party.
So when it comes to TCP, setting up
a reliable connection-oriented session between two devices,
it involves three transmissions.
And they refer to it as TCP's three-way handshake.
And to set the stage for this, let's
imagine that Bob is going to be acting as a client,
and that Lois's computer is running an HTTP server
service on her computer.
So we can just imagine that Lois's computer
is acting as a web server.
And the TCP three-way handshake goes like this.
The individual or entity that's initiating it
is going to send over a SYN request.
Now, that's not a SYN request like,
hey, let's go rob somebody.
This is a synchronization request.
And I put a B here to represent that this
is Bob's synchronization request that he is sending over
to Lois's computer.
And in the TCP header, there's going
to be a little flag that marked a little bit that's
on that says, hey, this is a synchronization.
And there's also going to be a little field for a sequence
number.
And let's just imagine that Bob pulled
from the air, the number 951,057,939.
And that's the sequence number Bob's computer chose to use.
And it sends it over to Lois.
Also, as part of that TCP segment,
if Bob was requesting web services,
it would be going to the well-known port
of TCP port number 80.
And if Lois is listening on port 80,
because she's running the web server software,
she can go ahead and respond back to Bob.
So if Bob sent a SYN request, Lois
is going to send an acknowledgment of Bob's SYN
request.
She's going to send back an acknowledgment number that
is going to be the sequence number of Bob plus one.
So the acknowledgment here should be 951, 057,940.
So Lois is simply taking the sequence number she received
an incrementing by one.
And when Bob receives that, he goes, great.
Not only do I know that she's talking to me or the server
talking to me, but for my next sequence number,
I'm going to use that 940.
Because behind the scenes, that's what that really means.
It's the next sequence number that's
expected to come from Bob.
So Bob's a happy client.
He's thinking, great, she wants to talk to me.
However, Lois also, the server in this case,
needs to synchronize her sequence numbers with Bob
the other direction because life is a two-way street.
So as part of that reply, not only
will include the acknowledgment and the acknowledgment number,
but Lois is also going to send her own synchronization
request to Bob.
And let's imagine, for fun, that Lois's computer
running the web server software chose a sequence number as part
of the request of 290,218,379.
So all that information, including the sequence
numbers in the acknowledgment numbers and the ACK and the SYN
flags are all sent back in one message
back to Bob, at which point, Bob needs
to go ahead and acknowledge the synchronization request
that he got from Lois.
So he's going to send a final message back.
So I've got a question for you.
If Lois sent over this sequence number
as part of her SYN request, what would
be the appropriate acknowledgment number that Bob
should send back to Lois?
[MUSIC PLAYING]
And if we consider the logic on the previous one,
the acknowledgment is going to be the initial sequence
number plus 1.
So if Louis's initial sequence number is 290,218,379,
Bob's acknowledgment number to acknowledge
that he received that should be one more,
which would be 290,218,380.
These devices can now send data back and forth.
They can manage their sequence numbers
in acknowledgment numbers to make sure
that all the data that's sent from one party
is acknowledged by the other side.
And that, my friend, is how TCP establishes
reliable communications by using its three-way handshake.
I hope this has been informative for you.
And I'd like to thank you for viewing.