I thought it'd be fun for us to take a look using Wireshark
at the actual three-way handshake in process by TCP.
And so to do that, here I've got a computer
with some packet captures.
We'll open that up, and let's open up a packet capture that
include some HTTP traffic.
And we'll focus here on packet number one.
And even before we start expanding
the details of the transport layer right here,
take a look over here in the info column.
Here, it's actually showing us the initial packet
is a synchronization request.
Then it's showing us that there is a SYN-ACK--
that's a response back--
which includes the acknowledgment
of the previous SYN request and the SYN request of its own.
And then the third element, which
is the final acknowledgment.
So this is a perfect overview of a three-way handshake.
We have a synchronization request,
we have a SYN-ACK, and then a final ACK.
So let's focus on the very first segment in our TCP
three-way handshake.
And we'll expand the TCP information here.
We'll also expand the flags.
So as part of the TCP information-- in this segment,
it has the source port where it's coming from,
the destination well-known port of 80,
and it's also showing us a relative sequence number.
And it's currently set to a relative sequence number of 0
because this is our first message
in the three-way handshake.
But you know what I'd like to do?
Let's do this.
Let's right click, and I'm going to go in here
in Wireshark to Protocol Preferences, and let's go ahead
and I want to turn off the relative sequence numbers.
That way, we can see the actual real numbers and not
just the relationship to where they
are in the three-way handshake.
So we'll go ahead and take off relative sequence numbers.
Then we can see the full numbers.
So a few things we can notice.
In the flags, in this TCP header,
that little bit representing the synchronization flag,
is set to an on.
And that's how the receiving side,
who receives this segment of data,
realizes that it's a SYN request.
Also as part of this TCP header information,
we have a sequence number, which is 951,057,939.
And at the moment, there is no acknowledgment number
because this is our first of our three-way handshake.
So I've got a question for you--
if this is the initial sequence number that's
being offered, if the other side sends an acknowledgment,
what would the acknowledgment number be?
And you're saying, Keith, I got this.
The acknowledgment number is going
to be the sequence number plus 1 during the three-way handshake.
And that would be absolutely correct.
So in the next packet for the acknowledgment,
we would expect to see these last three numbers as a 940,
with all the previous numbers being the same.
So let's take a look at the next segment, which
is the response, and that's right here in entry number two.
So with that selected and the TCP information being expanded,
the source port is 80.
It's coming from the server, going to the destination
port of 3372--
that's the one the client used initially
when it started a three-way handshake, as
far as a port number.
And now as we take a look at the acknowledgment number.
Look at this.
As we look at that number, that's
the initial sequence number from the other computer plus 1.
So it's 951,057,940.
The sequence number sent from the other side ended in 939,
so we're upping it by one to 940 during the three-way handshake.
And we'll also notice that the acknowledgment bit is on,
which indicates that this segment of data
includes an acknowledgment.
And there's the acknowledgment number.
The other item that's also very important
about the second message in our three-way handshake
is that the server wants to synchronize with the other side
as well.
So what the server is doing, the server has also
set the synchronization bit to on, indicating,
hey, there's a synchronization request here.
And the server is also including its own sequence number, which
in this capture is 290,218,379.
So the question I have for you, once again, is,
if the other side sends an acknowledgment,
what would the acknowledgment be coming back
from the other side?
And now having looked at it a few times,
you might say, well during the three-way handshake,
we're going to take the sequence number
and the acknowledgment number is going
to be that sequence number plus 1.
And you'd be absolutely right, and we don't have
to go too far to verify that.
Let's go down to our third message here.
In this header, there is a bit in the on position regarding
acknowledgment, indicating that this TCP information includes
an acknowledgment.
And if you dig a look at the acknowledgment number,
it is this one right here, which is 290,218,380,
which is perfect because the sequence number we got
from the other side was 379.
So by incrementing the other sides by one and sending it
back during this three-way handshake, the other side--
the server, in this case--
is going to know, great, my sequence numbers
are now synchronized with the other party.
And now, going forward, they can use acknowledgments
and sequence numbers to verify that all the data was
successfully delivered in either direction
by using the connection oriented features,
including three-way handshakes and sequence numbers
and acknowledgments courtesy of the TCP transport protocol.
I hope this has been informative for you,
and I'd like to thank you for viewing.