[MUSIC PLAYING] We took a look at doing
a three-way handshake. I want to remind
you how that works. And we'll look at one
with a protocol analyzer if you want to. So this may be enough. So this host wants
to talk to that host. The very first thing it does,
if I typed in Telnet to that IP address, or to that name, what
would be the first thing that happens? So I'm sitting here and I
say, "Telnet space bubba.com." What's the first
thing that happens? DNS. DNS. Fantastic. Then, after that we have
an IP address, we then, because we're using
Telnet, says, "Oh, TCP." And TCP says, "I need to set
up a three-way handshake." It creates a source port. And it goes the well-known port
on the far side for Telnet, which is 23. And it sends its
own SYN request. That's like me saying,
"Robert, do you want to talk?" So that's the SYN. We acknowledge that, the server
acknowledges it back to us, and says, "Hey, while
I'm at it, because this is a bidirectional
channel we're setting up, I'm also going to send you my
own synchronization request." Meaning, OK, I acknowledge
you want to talk to me, I'm game with that. And, by the way, do you
want to talk with me? So, SYN request here. SYN request and
acknowledgement sent back to the client, that
guy who started it. So we have to do,
finally, is recognize that we acknowledge the SYN
request, and we're good to go. It's a three-way handshake. The numbers are funky, though. Can I point out
the funky numbers? Now, do you need to know
this for certification? Absolutely. In the real world, if you're
troubleshooting at this level, you're way beyond CCNA. Fair enough. That's absolutely how it works. So, the guys in TAC who are
digging deep into something might have to find out what's
happening with an application. But, if I send a
sequence number of 100, I will receive an
acknowledgement back of 101. And these usually
refer to bytes. So, if I send 1 byte of data
with sequence number 100, basically, this client will
receive it and say, "OK, I'm ready to receive 101." It's like pay it forward. So, if I say "SYN 100,"
he'll send ACK 101, and my next sequence
number will be 101. So that's just from
that part of the story. From his sequence number,
he sent sequence number 300, so the acknowledgment that'll
come back will be 301. It's interesting. It's not natural
for a human being to say, "OK, I
totally get that." But the concept is, Robert
sends me up to 1,000 bytes. He sends sequence
number 0, for example. He sends me 1,000
bytes, I'm going to send him an acknowledgement
saying "1,001." Which is his cue is, "OK, great. I can pick up right
at 1,001 and send him my next chunk of data." So it always increments by one? No. In real data? In real data, it never
increments by one? How does it decide how
much to increment by? By the byte count. So, in the slides,
they use a window size of like 1, just an example. And, when we bring up a
live protocol analyzer, I'll show you. But, if I'm sending
10 million bytes, I'm going to send maybe
a sequence number of 1. I'll send you 1,000 bytes. You'll send me
acknowledgement 1,001. And I'll pick up at
1,001 in that big-- But when you get the
acknowledgement back, it's always one more than-- Yes. OK. That's what I was-- The acknowledgment is
going to be whatever your sequence was plus 1. Thank you for helping me get
that, to clarify your question. It'll always be
the next number up. Flow control. Here's an idea. Just an idea. Let's say that you have
a session established with TCP with the server. And you're having a great time. Data's going back and
forth and back and forth. And the sender, which
is usually the server, sends three chunks of data. And then, you're not
ready to process them. Maybe your computer is busy,
you can't handle it, whatever. Instead of sending an
acknowledgement saying, "Oh, yeah, send
the next piece," I can send an acknowledgement
that says "Oh, wait. Even though I got
1,000 bytes of data, I need you to start
at 500 again." And so it can send
an acknowledgment that says 501 instead of 1,001. And that will train this
guy to say, "Oh, OK. I'm going to go ahead and
resend starting at 501, and I may not send
as many next time, because something happened bad. And so I can shrink what's
called the window size. So, instead of sending
three chunks of data and then waiting for
acknowledgement-- didn't work out too well. OK, let me send two. And, if that doesn't work,
maybe I'll send one." So it's self-throttling
if the network isn't working quite right or a
PC isn't working quite right. Would we get any
of this with UDP? There is no mechanism
in UDP to even have a clue about the sequencing. It's all based on TCP. [MUSIC PLAYING]
