All language subtitles for 06 - Cisco Foundations - How Applications Speak - TCP and UDP-eng

>> While we are nearing the
end of our Cisco Foundations

or more specifically network foundations, as in
how devices communicate on the network today.

At this point, I'm going to
say we are good at layer two.

We understand the data link layer.

We understand MAC addresses, physical
addresses burned into the network cards

of the different devices and how that
interacts with layer three, the IP layer,

and IP addressing basics fundamental and
communication, how the art protocol resolves,

I mean all of that stuff we've
talked about the previous nuggets.

So, now I'm going to move up to layer four.

TCP and UDP, the last really network relevant
layer that we're going to focus on in here.

We're going to see where these two fit into this
puzzle of network communication and it's going

to bring up a whole bunch of port numbers.

So, I'll give you some common
ones that you'll want to know,

not only for certification purposes
if that's your direction, but also,

I mean you use this all the
time in the real world.

And then, we'll complete the end-to-end
communication story where we started looking at,

you know, from this host to this
host, what are all the factors that go

in to making pockets transmit
successfully across the wire.

Oh, my goodness, I totally forgot to
mention that we're going to start learning

about Wireshark in this nugget
which-- it's awesome!

You're going to really see a lot.

That's what this little icon is right here.

I know some of you might have heard
of it before I go and, "Oh, no.

Really?" This tool is amazing for helping
you not only troubleshoot networking,

network issues, but to learn networking.

I mean when you look at it,
initially it's overwhelming.

There's no doubt about it.

But when you see just the
basics of how to use it,

it's like okay, I think I can really get this.

As a matter of fact, Wireshark has
always, you know, it's always been one

of the tools I've had but I rarely use that.

I mean, Wireshark was like, okay,
everything is down, last resort,

what's going on, let's get out Wireshark.

And then I got a book.

I'm-- I've got in my bookshelf right here.

Pull it off.

It's "Wireshark Network Analysis"
by Laura Chappell.

It's a big, big fat book.

And just this-- it's a free utility.

And I-- let me-- I'm going to flip a hand.

I'm flipping at the preface
here, table of contents.

All right.

This is what she said and this is her preface.

"Wireshark is a," and she puts it in
all capitals, "FIRST RESPONDER tool

that should be employed immediately
when the cries of the network is slow

or I think my network is infected
echo through the company halls."

And, when I read that, remember
reading that years ago, and I go,

[inaudible], it's not a first responder tool.

This is like the last responder tool, but
seriously that's one of those statements

that have just stuck in my head and over
these last few years, I've started using it.

It's not-- it's still not my first
responder tool, but I've used it a lot more--

with a lot more immediacy than I have in the
past and it really has saved a lot of times.

So, I want to get you guys
familiar with that right away.

So, what are TCP and UDP?

They are the primary transport protocols used
today, meaning transport layer of the OSI model.

We've got our applications trying
to communicate data up here, right?

In our internet explorer, our [laughs]--
what other online games, whatever--

what other applications that people
use now a days, instant messengers,

all those kinds of things are
sending their data down here.

It reaches the transport layer and
you might remember from the OSI model,

this is where it's going to
choose the reliability, you know,

it's going to be reliable or unreliable.

And then it also assigns the port numbers to
start separating the different applications

so the operating system can
distinctly understand

which traffic goes to which application.

Now, there are a lot of transport protocols.

Again, I'll remind you, the OSI
model is a standard of standards.

The transport layer is just a shell but inside
of there, there's all kinds of standards

like TCP is one of them, UDP is
another, ICMP is yet another,

ESP that's used for VPN connections,
and things like that.

Even-- you'll start seeing protocols
like OSPF and EIGRP, I mean all these--

all of these kind of squeeze right into
that green box known as the transport layer.

But when we're talking about programs, talking
across the network, they primarily use one

of two protocols, UDP, that's
our unreliable version.

It's saying, "I hope it gets there," or
TCP, that's the "I know it got there."

That's the reliable version of this.

So UDP is the user datagram protocol.

TCP, transmission control protocol.

That's what they stand for.

And that they combine together with,
you know, the subprotocols below,

that's why TCP/IP got it's name is
it's not really that's the protocol,

it's the suite of protocol.

The most common being TCP and IP combined
together to make network communication happen.

So, first of, let's get into UDP.

And I talked one more time about the OSI model,
I got it in a little, little bit of this like,

why would you want to send something
unreliable like, "I hope it gets there"?

Well, the first thing to understand is
that there is a cost to reliability.

In order to say, "I know it got there,"
there's a lot of setup that takes place.

The first thing that happens is
something known as the 3 way handshake,

and I'll explain that in just a
moment, but essentially the two devices

that are talking together have to
establish a session between each other,

make sure that, "Okay, we agree to talk, okay.

That's good."

Okay. That's a little time right there and
a little time to establish that session.

Then every single packet that get sent or
every stream of communication that gets sent,

I'm going to just write something up here.

It's my reminder.

[Laughs] Every stream of things that
get sent between these things has

to get an acknowledgment
back saying, "I got it."

Again, more overhead, more delay where some
things just may not need that sort of thing.

I want to give you-- now, I gave you the
example back in the OSI model of things

that do not need reliable
communications being like voice over IP

where I have an IP phone talking to an IP phone.

You know, there's a stream of data going between
the two, if something is dropped, it's gone.

There's no use in retransmitting it at a
later time because it's real time traffic.

Same thing with video over IP.

But, there's also some other data
applications out there that use UDP as well.

I want to give you one that you use
every single day and that is DNS.

DNS, the domain name service,
translates names to IP addresses,

because remember in the OSI
model, it's not-- we--

at this network layer, we can't
squeeze in www.google.com.

It deals with IP, the IP protocol.

So, we have to have some kind of
system that takes these friendly names

like I put wireshark.org, I'm going to show
that to you in a moment, or cbtnuggets.com

and translates it to what
IP address is really there.

DNS, at least the client version of
it that we use everyday, uses UDP.

So, let's check this out.

I'm going to bring up Wireshark.

Now, I want to give you a
little basics of this program.

Wireshark will be flat overwhelming
if you just open it up and say,

"Okay, let's see what's happening."

If you've never done this before, I
mean people get scared, they back of.

They'll like, "Aah, I don't
want to use that again."

But, let me give you the basics which will
really get you started and I tell you what,

if somebody would have sat down with me in my
early days of networking and just said, "Hey,

Jeremy, let's just sit down for a second.

Let me give you a 5-minute tutorial of
this tool that will change your life."

You know, I would have been
like, "Great, thanks."

You know, just, you know, the fear of
it is what held me back for so long.

But, this is Wireshark 1.82.

It is free.

You go to wireshark.org and just
go to their little download page

and they'll automatically
detect your operating system.

You can put it on there, it's good.

So, once you get Wireshark installed, it's just
literally a next, next finish sort of install.

This is what pops up.

Now, the key icon you want to go to is
this list available capture interfaces.

And, trust me, this is a massive utility.

There's a lot to it.

I just want to get you the core that will
get you started in doing what you need to do.

So, I click on this.

And right here, I can see the
interfaces that are on my computer.

Now, I see this sun which, if you remember
I had it when I went to my control panel,

and did my network status, look to my adaptor,

I had this little virtual box host only that's
installed by the virtual box application.

It's a little virtual machine thing.

It's developed by Oracle,
Sun Oracle, they merge.

And so, that's what this little adaptor is and
I can look, that's why I always go to this view.

I'm like, "Okay, not much happening there"
'cause if I'm looking here trying to start,

you know, pick one, you can start it from here
but if I don't, I don't know which one it is.

You know, I want to see,
where's the traffic happening?

So, I go, "Okay."

Well, it looks like this is where
there's some communication happening,

so I'm going to click check
on this and do start.

What I'm going to start seeing is the
communication that's going across the network

and this is where a lot of people
go, "Ooh, aah, what's going on?"

You know, they're not too sure what to do.

So, right now, this is-- not much is
going on, 29 packets are happening.

I can see Spanning Tree Protocol running
in the background, some other, you know,

just normal network traffic
discovering and communicating with things

that are going on in the network.

Now, as soon as I open a web browser
and let me move this to the side

so you can see, and let's just go to msn.com.

And look at that.

I mean, we went from like 29, 30, 50 and
all the way up, you know, msn.com came up

and now we're at packet number 1095, you know.

All of these things are going
on and what just happened?

We just had a ton of network communication that
comprised 1,200 or 1,280 individual packets.

So, that's where people go "Huh!

It's overwhelming."

How do-- you know, how do I now sift

through 1,200 individual packets
to really see what's going on.

We'll, I'll explain that in just a moment
but let's look at the matter at hand.

I want to talk about DNS.

DNS resolves names to IP
addresses and I'm going to show you

that this is using UDP as
it's protocol to do it.

Now, the first thing that's
happening is I'm like "Aah!

This is just-- it's too much,
I want to put a filter on."

Let me show you one of the handiest
filters that you will likely use.

It is coming up here, you click in this
little filter box and you'll find, I mean,

you can build your own, you can click on this
and it let's you, you know, click through

and kind of-- almost like that's a gooey base
like if I just want to see the UDP traffic

or the TCP traffic, I can do that but I'm
just going to go in here and just say ip.addr,

IP address equals 4.2.2.2, enter.

Now, what is that?

Actually, you know what, I'm
going to even change that further.

Let me go 4.2.2.3, enter,
blanks it out completely.

What that does is say, only show me
the traffic that is going to 4.2.2.3.

Getting that so far?

So, right now, how much traffic is going there?

Nothing. Because nothing is actually accessing
that IP address so my display is nice and empty.

So now, I'm going to use
DNS to do a little testing.

I'm going to open a command prompt in
windows, start, you can browse to it,

accessories all that, or just type in start run
CMD and bring this to the middle of the screen.

And, show you first of, when I
do IP config forward slash all,

I have in my list my DNS servers,

shows the primary DNS server my
computer is using is 4.2.2.2.

The secondary is 4.2.2.3.

Now, how did those get there?

Well, that was through DHCP.

When DHCP gives me an IP address, it can also
assign me DNS servers, the default, gateway,

all that kind of stuff, and so this
is the DNS server I was assigned.

Now, since this is the primary, remember when I
was looking at Wireshark, when I set the filter

to say 4.2.2.2, oh, okay, my capture is
still going so it's getting obnoxiously big.

But-- so let me-- I'm going to stop the
capture because we've got enough data.

I can see all of these little DNS queries
but this is kind of-- it's too much.

I want to do a little demonstration version,

so I'm going to filter this
down and just see 4.2.2.3.

Now, I stopped the capture so nothing-- oh
[laughs] I suppose I should start the capture.

I was just thinking-- so
nothing new is coming in.

So, I'm going to start the capture
and let's say-- let's begin this.

It's going to ask me, "Do you
want to delete the old capture?"

Once I click save, it would say, "Hey,
do you want to delete the old one?"

Absolutely.

I'm, you know, I don't need the old one.

So, I'm looking-- I'm capturing traffic just for
4.2.2.3, that's the filter of what I'm seeing.

I'm going to open my command prompt and
show you a handy utility called nslookup.

What this is, is a utility that
allows you too ask questions of DNS,

so what it's doing is this is coming
up and say, "Okay, well, right now.

You can ask a question of 4.2.2.2.

And, I would say, "Okay.

Well, I want to see who is www.cbtnuggets.com."

And, 4.2.2.2 comes back and says, "Well,
actually, they have two IP addresses associated

with them, this one and this one."

Well, which one am I going to use.

Well, the way it works is it's
going to do a round robin.

Maybe the first time I'm going to use this
one, the second time I'm going to use this one.

And, the name is kind of gives
me a little clue right here.

It says, web balancer.

I'm going, "Okay."

So, this is some kind of load balancing.

You know, maybe CBT Nuggets has
enough traffic that they say,

"I don't want just one web server.

I want to kind of balance that
between a couple web servers."

I mean we see that again
if I type in google.com.

And, I mean, "Hello, Google."

They're definitely trying to
balance that load 'cause obviously,

how many people use Google everyday.

So now, what I'm going to do, I
was asking questions of 4.2.2.2.

I'm going to change them.

I'm going to do server equals 4.2.2.3.

And so, I'm changing the-- wait a second.

Server? I don't know why but equals [inaudible].

Server space 4.2.2.3 which now
sets my DNS server to this address.

Now, watch what happens.

I'm going to do-- I want to
do a lookup for what's that--

a small website that would've be--
oh, I have a blog, tekcert.com.

I blog with another guy out there, comes back
and says, "Aha, tekcert.com is this IP address."

But now, did you see behind the
scene is like, Wireshark is like,

"I saw something happened right there."

So, what happens is this
guy went out and said, "Hey,

I want to find out what is the IP
address for tekcert.com.home.local?"

[laughs] What the-- you know,
where did that come from?

I typed in tekcert.com and the only way I
would know this is if I was using Wireshark

and it went out and said, "Well, actually, I
want to ask the server, you know the DNS server,

I want to find out who tekcert.com.home.local
is."

Now, why on earth did it do that?

Well, when you dig a little bit
deeper, let me go back here in my--

create a second command prompt,
and I do an IP config slash all,

one of the things that you can do with DNS
is assign computers, a default DNS suffix.

Suffix, where does that go?

At the end right?

So, that would allow somebody, for instance if I
assign the home.local suffix, it allows somebody

to say, "I want to ping," you know, maybe
the server and hit enter and it's going

to automatically try to ping server.home.local,
maybe that's my local DNS domain that I have

for my house or something like that.

So immediately, when I tried to ping tag or look
up tekcert.com, it came back and it was like,

"Well, I'm going to try and
look up tekcert.com.home.local."

Now, before we go on.

You can even see the reply right here.

It's saying, "There's no such thing.

I don't know of a tekcert.com.home.local,"
is the DNS server's reply.

But, let's dig a little bit deeper
because Wireshark actually breaks

down communication in the
layers of the OSI model.

At the very, very, very bottom is, you
know, essentially as physical as it can get.

It's saying, "Hey, this is
how big the data was."

This is, you know, how many bytes
were actually sent on the wire.

I mean think of this top
one as the physical layer.

Then, we come right here to the data link layer.

Now, what do we expect to see there?

Mac addresses.

And sure enough I see that I
have the source MAC address--

this is my computer right here
and, you know, let's prove it.

I mean, let's make sure we're
doing what's real here.

I'll do IP config forward slash
all and come up and look again.

And, I look at my MAC address C8-C0, you
know, and the last four digits 6C-32.

I'm looking over her right there and
sure enough, C8-60, so I go, "Okay".

Well, I was the source, this is me.

And then, I went to the destination of--

I actually have a little Cisco
firewall that runs my location here.

And, it says, "Okay.

Well, I sent it to this MAC
address as the destination."

Ahh, you see-- so, wow, this
is really, really good, right?

So, it starts putting reality to a lot of the
discussions we've had up 'till now on, okay,

it's got the MAC addresses in there.

Then it says, "Okay, well, what IP address is?"

Where-- so, layer one, layer two, layer three.

IP addresses were actually coming from
the source of this, that's my computer,

destination of this, the two DNS server.

And now we come to the point that started
this entire discussion, the UDP protocol.

DNS actually uses UDP.

Look at it, User Datagram Protocol, UDP.

This is layer one, two, three, and four.

It's saying, "I'm coming from the source port,
60353, going to the destination port, 53."

Okay, stop right there.

What that says to me is that my
computer contacted this DNS server.

[Inaudible] .72 is the last octet.

This is 4.2.2.3 is that DNS server and it
went to a destination port of UDP port 53.

Oh, three is a little odd there.

Okay, 53, and it came from
a source port of 60353.

Now this is a well known, I'll
put W/K, well-known port for DNS.

As in all the DNS servers in the world respond
on port UDP 53, that's where they expect

to receive request for and all the computers in
the world by default will ask questions directed

at UDP port 53 of their DNS server.

Now, Windows generated a dynamic port.

This is a not a well-known port at all, this
is considered my source port saying, "Hey,

my question is coming from
the source port 60353."

So when this guy replies back and says,"
I have no idea what you're talking about.

There is no such thing as tekcert.home.local."

Excuse me.

He's actually going to be coming from source
of port 53 going to destination of 60353.

But Windows expected that.

They'd expected to get a
response back on that source port

and that's actually one of
the reasons why DNS uses UDP.

This is kind of a stimulus response
sort of thing to where I'm going to say,

"I want to know who tekcert-- but
I'll just put tk.com really is,"

and the DNS server will say,
"Okay, here's your answer."

Now that's all the communication that
really goes on between them is, what's this,

here's your answer, what's this, here's your
answer, what's this, here's your answer.

It would just be a waste of time to say,
"Okay, let's build a session between us.

You know, are you okay talking?"

The other one is like, "Yes.

Let's build this."

And I'm getting into the 3 way
handshake, you know, building a session.

Okay. Now I want to know what is the name or
IP address of tekcert.com and then, you know,

send the acknowledgment that
you got my question.

He is like, "Okay, got it.

I got your question and here's the answer."

It's like, good grief.

Why do you need all that overhead just
to get the answer of who is tekcert.com?"

So, with DNS, it's geared in such a way
that you say, "Hey, who's tekcert.com?"

And if your computer doesn't get an answer
back, it's configured to say, "Well,

I hope they got there but I don't think it
got there 'cause I didn't get an answer back.

Well let me ask again."

And so it will keep trying to ask because
maybe the packet did get dropped somewhere

between here in California
during that communication.

So, that's the idea of those port numbers.

Now let's go back to Wireshark and
look at this communication as a whole.

So it's saying, "Okay, who
is tekcert.com.home.local?"

This guy comes back and it's like, no
such thing, I don't know who that is.

Now notice, it's asking for an
A record, a DNS that's alias,

that's the normal record that people ask for.

So, it's like, no such thing.

So it comes and say, "Okay, well let's try this.

I would like an AAAA record."

He's saying, "If I'm looking
for this kind of record

for tekcert.com.home.local,
do you know who that is now?"

And he's like, "No, still no such name."

So okay, what's the difference here versus here?

Well, this is looking for the IPv4
address of tekcert.com.home.local.

AAAA record is actually an IPv6 address.

So it's saying, "Okay, that didn't go so well.

Maybe he's on TCP/IP version 6 because
since Windows XP Service Pack 3,

all the Windows operating
systems have had IPv6 enabled

by default so they-- they're balance today.

He's like, "No, still no such thing."

So then he comes back and he's like, "Okay, well
then, do you have an IP address for tekcert.com?

How about just tekcert.com?"

He comes back and he goes, "Actually, I do."

And we can expand that out and we can
find out, "Oh well, here is the query,

tekcert.com and here is the answer.

Tekcert.com came back and this is
the IP address that I received."

Wow, do you see how this
can be really, really handy?

If, I mean, think about it.

Let's say we're sitting here and
you type in, you know, whatever.

You know, you're looking something up and
it comes back and he's like no response

or request timed out or, you
know, something like that.

And let's just put Bob.com.

And, you know, it fills that.

We've got all, you know, tries again
Bob.com and we get this answer back.

But what, you know, what if
it never got the answer back?

It just said, you know, request
timed out, request timed out.

And you're like, "What's going on?"

I mean, without this tool in the
background, you have no idea.

I mean, this tool is what-- oh,
it's looking for Bob.com.home.local,

it's not supposed to do that,
why is it doing that?

So that's why Wireshark is really handy.

So, bring that back around.

That's the basics of Wireshark.

Again, without this filter, it's
going to be just plain overwhelming,

but if you can filter it down and start
to really look and analyze these packets,

you can get quite a bit out of it.

So let me clear off this slate and get back
to the topic at hand which is TCP and UDP.

TCP I think we've got, it's just--
it's a wing it protocol, all right?

You kind of chop the packet, you hope it gets
there and if a response comes back, great.

You know, that's how it works.

TCP is the, "I know it got there" protocol.

The way that it does that is by using initially
a 3 way handshake to establish the session

and then it uses acknowledgments to make
sure that every single packet was received.

Now, let me break that down into the
fundamentals of how this protocol really works.

When I have a computer here,
and I say, "I want to go to--

let's just say I want to surf the
web and go to cbtnuggets.com."

That will be our example.

HTTP is a TCP-based protocol.

It uses-- it says, "I want to have
reliability otherwise web pages might show up."

You know, things missing off of them
and all that now, and that may happen

but it's not TCPs fault, it's--
somebody made a bad web page.

But TCP make sure that all of your
traffic gets between these two.

Now, when this guy starts, here's how it works.

He will send-- when he realize, okay, I've got
the IP address 'cause I looked it up via DNS.

The IP address of CBT Nuggets, let's just use
some reality here, cbtnuggets.com., there we go.

Is-- let's just grab this first one,

18472 so I'll just go 1184.72 dot dot
dot, you know, that's the IP address.

He's going to send the very first packet
will be what's called a SYN packet saying,

"Hey CBT Nuggets, I would like
to start a discussion with you."

Are you-- essentially, let me put in
plain English and then I'll get technical.

"Are you okay with that?"

CBT Nuggets says, "Yes, I am okay with that."

SYN ACK. That means, I'm sending a
synchronization bit, if you will.

I'm saying, yes, I would
like to start talking to you,

which is what these do, and
I'm acknowledging yours.

I'm saying, "I got yours" that's the
acknowledgment "And here's mine."

So, this guy replies back with one final ACK.

What do you think that's there for?

I got that.

I got the SYN message from you.

So I'm acknowledging that we're good and
that is what they call a TCP 3 way handshake.

Every single time you start a session,
it's going to do that with the destination.

A matter of fact let's--
I am all about Wireshark.

Let's prove it to ourselves, right?

Let's stop this capture, I'm
just going to close this guy.

Continue without saving.

Okay. Let's clear the filter off
and let's just start to capture.

We'll just go to one website so it should
be pretty easy to pull out, click on start.

I'm going to go to cbtnuggets.com.

Enter, boom, stop the capture.

I got a whole bunch of data, 400 some packets
that were sent to generate CBT Nuggets website.

Let's go all the way back to the
beginning up here where it all happened.

Notice that right here my-- now, now you might
say, "Well I don't see any DNS, you know,

question for who is cbtnuggets.com, I see, you
know, Wireshark weaseled its way in there."

But, you know, what's happened is
my computer cached the DNS response.

It remembers who CBT Nuggets is
because I've gone there before.

Now, those caches will eventually
time out but they'll get there.

Now, look right here.

So, we have Google, we're talking
to Google and you might say, "Well,

what's all this stuff happening?"

Well, whenever you type, you know, I'm using
Google Chrome and I don't know if you've notice

but when you start typing you're like,
Jeremy, it's starting to, you know,

figure out who will the, you know, who is--

it's filling in all of this
data, so we're able to see.

You know, oh, okay it's filling this in.

So every single time, Google
is going, "Okay, well,

let's find out who Jeremy
Cioara is and you click on it.

That's-- it's kind of weird
[laughs], I'm looking myself up.

But, you know, who is Jeremy Cioara?

It's constantly going back and forth with Google
saying, "Okay, he typed an I, he typed an O,

he typed an A, you know,
as it fills out the names.

So that's what this little shindig was.

Now, here's the meat of it.

I come down right and I see, okay this is a
TCP-based message, three of them to be exact.

Notice, SYN, SYN ACK, ACK, 3 way handshake,
SYN, SYN ACK, ACK, SYN, SYN ACK, ACK.

Now, I want to go down a little
further because I'm noticing here--

notice the source and destination.

It came from this server
going to this one, right?

SYN, SYN ACK, ACK and I go down a little bit
more and all of a sudden, I see another one.

It's like, wait second, SYN, SYN ACK, ACK.

And so there's more than one.

I go down and all of a sudden, I see
it looking up all the stuff, it's like,

"I'm looking up some analytics, I'm
looking up cloudfront.net, Facebook.com."

What on earth is going on?

And all of a sudden I see all these-- okay,
SYN within, SYN within, SYN within, SYN within.

All of these are SYNs and then I
started, you know, look at these SYNs.

It's starting all of the sessions
with all these different servers

and then they all start coming back,
SYN ACK, SYN ACK, SYN ACK, SYN ACK.

And then, you know, it's kind of like that
we get this big merge of ACK, ACK, ACK.

You know, it's kind of a--
what on earth is going on?

I just went to CBT Nuggets and all of a sudden,
I've got all of these sessions starting.

Well, you remember, I think that I
talked about this in the previous Nugget

but this web page is a framework of web pages.

When you come here, there's something
on here that deals with Facebook.

Ahh, there we go.

They've got a little follow us on
Facebook link, maybe that's it.

And they've got a little
link to Twitter or something

that it pulled from Twitter and built this.

So this web page is dynamic,
it's always changing,

it's pulling from all these different servers.

So when I come to cbtnuggets.com, I'm actually,
you know, these pictures, these videos,

everything is pulling from all these different
servers, so that's why I see just getting shot

into this world of SYN and SYN
ACKs but just get back to the base

of it all, that's where it started.

SYN, SYN ACK, ACK.

So there's got to be more
to it than that, right?

You know, there is.

SYN, SYN ACK, and ACK introduce
something known as sequence numbers.

So here's the concept.

I wrote it up here so I wouldn't forget,

but I didn't forget even though I
erased it, called TCP Windowing.

TCP Windowing is the key to network efficiency.

So, here's the concept of
windowing and window sizes.

Some people call it sliding windows
if you ever hear that before.

Let's say I have a really big
file, it's 1.0 gigabytes in size,

and I want to send that over to the server.

Well, when-- I don't know if
you've ever seen this in Windows,

if you've ever copied a really big file and you
copy across and pops up that little, you know,

copying time estimate window and
it initially starts off and it's

like your time estimate is two days
five hours, and you're like, "What,

you know, well that's not right!"

And then Windows is like, "No, no, no, no, no.

Just kidding, let me back of.

Actually, it's going to be one day three hours."

And you're like, "What?"

You know, and then, no, no, no, no, have
you-- you know what I'm talking about?

And [inaudible] says like, "No, just kidding
your time estimate is really 32 minutes."

And you're like, "Okay, that's
a little more of a result."

And then, I mean, it takes like 30
seconds before it's final like, okay,

really it's going to take 10
minutes to copy that file.

[Laughs] Okay, it's like, okay what happened
between Windows popping up and saying it's two

and half days to copy this file
all the way down to 10 minutes?

Well that's where TCP Windowing
kick in and took effect.

Essentially when your computer starts to
send that file, this file has actually broken

up the normal packet size for Ethernet,
it's actually 1,500 bytes, 1,500 bytes,

that's very small especially when you're
considering I'm sending 1 gigabyte of data.

So, a little 1,500-byte, that's, you
know, think of this as 1 kilobyte

and you remember there is a
thousand 24 K and a megabyte

and there's a thousand 24
megabytes and a gigabyte.

So, I mean, you're going to send
thousands and thousands and thousands

of these packets to compress this.

So, it sends one packet over there.

This guy comes back and it's like, "Okay, great.

I got your packet."

The very, very first packet of this
1.0-gigabyte file transfer, I got it ACK.

Now Windows looks at that and it's like, "Wow.

Okay." If I'm going to send one packet at a time
and then sit there and wait for the other size--

other side to come back and
say, "Okay, I got it.

It's going to take two and a
half days to transmit this file."

So the computer goes, "Okay.

Well let's-- let's try this.

How about instead of sending one packet,
I send you four packets at a time."

So it takes four of these 1,500 byte packets
of the 1 gigabyte file, sends them over there

and the server comes back and
he's like, "Okay, I got it.

I got all four of those packets."

And the guy-- the Windows is like, "Okay, great.

That's better.

If I can send four packets at a time
then I bet you that I can get this done

in like a day and a half, right."

It reduces it dramatically because
we're being much more efficient.

So, what's happening over that,
you know, first 30 seconds

or so of that file transfer is it just
keeps trying to send more and more and more

and more and more and more and more.

It's like, "Okay.

I'm going to try and send
you 100 packets at a time."

Sends them a 100 of these 1,500-byte
packets, ACK, I got all 100 of them.

Does that make sense?

So, that's the concept known as TCP window
sizes or some people call it sliding windows

because the windows starts
small, it slides bigger.

But if there's drafts, like let's say, I
send a 100 packets and I lost two of them,

then my computer is going to go, "Whoa, whoa,
whoa, whoa, whoa," you know, we're loosing data,

I've got to pull back and only send a smaller,

so the window size slides smaller
and you see the copy time go up.

So, that is the essence of how computers
know how much they're able to send

or how much bandwidth they can consume and
they're going to try and consume all of it.

And computers are bandwidth hungry monsters,
they will try and consume all of the bandwidth

that they can on the way to that server
until they finally start dropping packets.

And they go, "Okay, that's how much I
can send it once before I, you know,

I've reached the congestion
point of the network."

So, how do-- what-- how did this, this Window--

Windowing concept and sending more than
one packet at a time fit into this and it--

where we started with this 3 way handshake.

Well, when we do a 3 way handshake, what
we're really exchanging is sequence numbers

of my packet numbers are going to start here
and then keep incrementing as I send you data.

So, let's look back at Wireshark,
get some examples of this.

So, right here, we've got our 3 way handshake.

We've got SYN, SYN ACK, ACK.

So that's the very first one that we do.

So let's break this open.

We'll look at the TCP data and it says, "Oh,
this guy is a flag, it's a SYN" but I want you--

and you can, I mean, you can dig deep and
say, "Oh, okay, well it's actually this bit,"

and that, I mean, yeah, for
now, it's a SYN, right?

But if you look three above that, it says, "Hey,

we're going to be starting
from sequence number zero."

That's it, that's was-- so I'm going
to-- that's my beginning where--

that's where my counter begins essentially.

Now this comes back and says,
"Well, here's your SYN ACK," right?

And what this says is, "I'm going to
be starting from sequence number two."

That's great.

"And by the way, I'm sending it ACK for one."

What does that mean?

So, I-- and so, again, let's look,
this is my computer saying, "Hi SYN.

I'm going to be starting
from sequence number zero."

This is them, see them, this is CBT Nuggets
you're applying back that it's saying, "Okay.

I'm going to start from sequence
number zero, that's my SYN too

but I'm also going to send you an ACK of one."

Well the way the ACK works is it's always
going to be one more than your sequence number.

So when I said, "Hey SYN, I'm going
to be starting from number zero."

He comes back and in his ACK he
says, "I'm going to acknowledge one."

And what that says to the computer is, "I've
received your zero and the next sequence

that I'm expecting from you is one."

Does that make sense?

And then, and then, and then, I'm like
[laughs], "Oh, oh, oh, and then look at this."

And then, when I click it on
here, it goes, "Okay, great.

I'm going to send an ACK back of one as well."

So, what we've done is we say, "Okay,
I started with sequence number zero.

Is that good?"

And he goes, "Absolutely.

I'm going to start from sequence number zero

and I'm acknowledging your sequence
number zero by giving you an ACK of one."

Then I come back and say, "Okay,
ACK of one because I'm a--

I don't know why I put it aligned to that,

because I'm acknowledging
your sequence number zero

that you gave me and now let's start talking."

Isn't there a lot?

That's a lot-- whoa.

That's a lot to just say,
"Okay, let's now start talking."

But then, when you start getting it
to the data, let's see if I can dig

and then find some good data transfer here.

I got your standard encrypted
packets going through there.

It's so [laughs], it's funny because going to
CBT Nuggets home page, there's so much pointers

on there that-- and there's
encrypted data, HTTPS,

you know, stuff flying all over the place.

But right here and that's, I'll describe this.

Right in the middle of this, this is
actually using TLS which is encrypted data.

This is CBT Nuggets sending me some
data saying-- and they're saying, "Hey,

this is my sequence number and
I am acknowledging the last one

that you gave me which was 1639."

So you kind of go back and forth, it's
just, you know, finding the stream.

So this guy is saying, "Okay.

I'm-- yeah, we're getting
the encryption handshake."

So, okay, here we go.

I'm sending some data.

So I send some data right
here, sequence number 348.

I move on sequence number 401.

I move on sequence number 462.

So, you're sending data and every time-- now, if
I want to see-- well, here is the actual data,

it's SSL which is all nice and encrypted.

Here's the data that's being sent.

It's all encrypted mosh going
to CBT Nuggets website,

but all of that stuff has sequence numbers.

So, essentially, let me boil it back down on
the slide 'cause it's a little less complex

and busting that Wireshark.

I've got, you know, let's say three
1,500-byte packets to send, right?

So let's say I started with SYN zero, I send
three 1,500-byte packets to the other side,

and it will come through and, you know,
first one will say, "Hey, I'm some data.

I'm sequence number 1,500.

The second one will come through and say, "Okay.

Well, I'm sequence number 3,000."

And third one comes through and you see where
this is going, "I'm sequence number 4,500."

The sequence numbers are-- they are
essentially a mathematical addition

of all of the data that's being sent.

In that way when this-- these
two get dropped, you know,

maybe this one made it through,
these two were dropped.

All of a sudden this guy
goes, "Whoa, wait a sec.

I missed sequence numbers, you know, we'll
say 4,000 through 6593 or whatever, you know,

whatever those sequence numbers are."

So, he's going to be like,
"Whoa, I did not receive those."

He goes, "Oh, well let me resend
those sequence numbers to you."

That-- this is how TCP keeps it
all working is by, you know, again,

those acknowledgments coming back.

If you received them all,
he'll send acknowledgment

for one plus, whatever the last sequence.

So let's say, the last sequence
number to get in was 4,500.

He's going to send an acknowledgment for 4501--
1 and then the transmission continues on.

[Laughs] It's like, right there, I took
breath and I took a step back and I'm like,

"How do you see anything on the screen anymore."

It builds on itself so hopefully you've--

you didn't look away throughout 'cause otherwise
it's just a mess of lines going back and forth.

But, wow, I mean, if you take that and put
it all together and you are on your way--

well on your way to becoming a network
Ninja, not only understanding how TCP works,

the 3 way handshake, the acknowledgment,
back and forth process, but also now,

starting to look inside of
Wireshark and been like, "Oh, oh, oh,

I see the 3 way handshake right there.

I get it."

You know, and then I started seeing that, I get
referred to all these other servers, you know,

because there're the DNS queries.

And then, I started sessions with all those,
that's all these SYN packets, I mean, wow!

That's a ton of info that you can say that,
I mean, it's rare to find somebody who's able

to do that level of knowledge
in the network world.

I have found that there is a big difference
between the amount of time I think it's going

to take to talk about something and
then the actual amount of time it does.

It's all a Wireshark, I'm
telling you, bringing that tool

into this, I mean, the sky is the limit.

But boy, do I want to-- what
I'm going to do is I'm going

to break this into two different pieces.

So, this will be our part one and then I'll
wrap up these other two items in part two.

But what did we talk about and then
what do I want you to do with it?

Two, well, we talked about a lot.

We talked about UDP and,
you know, its simplicity.

And then we got into TCP just looking
at, you know, what is this is protocol

or how does it communicate so, you know, in a
stable way using sessions with the other side.

We saw the TCP 3 way handshake, we saw sequence
numbers, we saw a DNS lookups, we saw Wireshark,

I mean [inaudible], you know, the list goes on.

And I mean, this was just a packed Nuggets.

So, here's what I want you to do with it.

I want you to really take the time

to start getting a depth behind
your knowledge of UDP and TCP.

What I want you to do is go download Wireshark.

Go to wireshark.org, it's a freebie.

Download that and install it on your laptop
or desktop or whatever device that you have.

And I want you to go to a simple website.

A matter of fact, somebody emailed
this too me a long time ago.

What was it called, the last
page of the internet.

[Laughs] That it's and it's just some
guy and he's been around for a long time.

The last page you cre-- the guy who
created a website that just says,

"You have reached the last page of the internet.

Hope you enjoyed your browsing.

Go outside."

So, beautifully, simple web page to
where we won't get the confusion behind.

And won't say confusion but the complexity
behind going to big websites like CBT Nuggets

and seeing 50 different servers
popped into our conversation.

So grab Wireshark.

I want you to capture the DNS lookup.

Create a filter, find out
what your DNS server is.

Create a filter that allows you to see the
DNS lookup and then one that allows you

to see the communication between you and
that last page of the internet web server.

They'll be nice and simple so you don't
have a ton of stuffs to read through.

Also, realized that I showed you-- I mean,
one 1,000th of the possibilities of Wireshark.

You can create complex filters like I could
say this and IP address equal, you know,

or I could use and or IP address
at and equals such and such.

I mean, you can start building numbers
where you just capture a certain port number

or I should say filters where you
just capture certain port numbers.

There're a lot of possibilities.

I mean, play around with
this, start tinkering around.

And really, I would say, add some depth to your
knowledge and then jump into the next Nugget

where we'll talk about the port
numbers and then fit it all together

with that end-to-end communication story.

I hope this has been informative for you
and I'd like to thank you for viewing.