Original subtitles

>> 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.