Tip:
Highlight text to annotate it
X
How Applications Speak - TCP and UDP, Part 2.
We're going to pick up right where we left off in the last nugget,
which is we had just finished talking about TCP and UDP and going through Wireshark
and all its glory showing captures of communication with these two protocols, which were immensely
valuable. Now I want to get back to some of the core
principles, which is the common port numbers where we left off and then completing the
end-to-end communication story. So, we put all these pieces together and wrap
up what I would call the network foundations. And it's pretty hard for me after that last
nugget to kind of jump into the ports because it just kind of bridges where that
last nugget was at. So, bear with me for a second.
So, remember that we have a computer, alright speaking to a server
that is going to provide some service. Now this server could be running web serving
software. It could be running email serving software.
It could be running Microsoft Exchange or maybe some kind of Linux based email service.
It could be running an FTP site where it's sharing files.
It could be running all three of them at the same time.
The point of this is when we're using a protocol, namely these are all TCP based protocols,
when we're using a protocol to contact it we need
to specify which service we're looking for. And behind the scenes are web browsers fill
that in for us. So, when we open a web browser, and actually
I've already opened this Wikipedia page right here.
But when I got to Wikipedia.org it automatically knows I'm going to use port 80.
As a matter of fact I have this thought. I want to open up the Wireshark capture from
the last nugget and you can see behind the scenes the computer's
doing all this. Okay destination port is port 80 or http.
The source port is 49885. So, every single time you establish the sessions,
so I've got this going we'll say to the web services, so we'll have TCP port
80, it's always going to come from some source port that Windows just makes
up. This is the dynamic port number.
So, it's usually going to be in the upper port numbers because all
of the well known ports are here at the bottom. Now I do know both protocols do have 65,535
ports that are available for use that are distinct, meaning it's not like you
know the TCP ports and UDP ports overlap. Port 53 on this side is different than port
53 on this side. They're two different-- of course,
I would choose to circle the one that-- you're like no it's not.
It's DNS. Well one's a DNS server, one's a DNS client used for--
it's called zone transfers and stuff like that.
But for instance, over here port 80 is not http.
You know it's something else on the UDP side. So, they are distinct 65,000 ports.
Up to port 1023 is actually considered well known
and that's why I pulled up that Wikipedia page.
I put some common ports here on the screen, but no-- I mean this is just [Sound effects]
and it's like just this giant list of ports. Like you know you can see right there that
it's port 25 that's used for SMTP. That is an official standard.
Like that is documented. It's RFC standards based, but you also see
you know we've got this winds, which is a Microsoft service, which is unofficial.
They run it on port 42, but they didn't create some kind of RFC standards
because WINS is Microsoft proprietary. So, you can down this list.
I mean you find-- I think they even have, let me just do a find Warcraft.
Yea, look at this. TCP port 3723 used by Diablo Warcraft, StarCraft
you know. I mean this is a cumulative list of well known
services that are out there and you find all kinds of stuff.
Microsoft Ants for crying out loud made the list.
So, you've got all of these different ports that based on-- let's say I'm running Microsoft
Ants, which I'm really curious to see what that
is now and I may just pause the video and go do that.
It's going to go into the Microsoft Ants server, whatever that server does
and manage the ants I suppose on port 4001; that's the well known port for the Microsoft
Ants game. Come on you wanted me to click it right.
A free, free multi-- oh I'm there. So, we've got these common TCP ports.
Now, the reason I put these in a nice little bubble on the screen is these are ones
that you will want to know, of course, if you're certifying,
but for the real world in a huge way. The reason knowing these is so valuable is
because it allows you to respond to needs at hand without running to a book or you know
trying to remember things. I mean and trust me, you'll see these so often
that you'll-- I mean you'll get it again and again, but
of course, if you're studying for a certification, well boonk, bounce your head against the screen,
memorize those guys. So, the reason this is good you know it's
kind of like okay why is it good to know these? Well remember, we've got all kinds of routers
and these devices in between. It's very easy to turn a router into a firewall.
Let's say, let's say you know what, I'm like you know what my organization or productivity
is low because I walk around and I see people surfing
the web all day long. I'm done with that.
I'm going to immediately-- and this is all it takes I'm going
to immediately block port 80 and port 443. Now, just go into this driver and say do not
allow anybody except me, of course, to use port 80 or 443 to communicate on the
web and bam. You just killed all internet access for your
organization. It's all-- I should say all web surfing access.
Internet is a broad term, but you know let's say I don't want emails to go out,
block SMTP, simple mail transfer protocol. FTP, file transfer protocol, allow the-- you
know take the opposite approach. You know I'm taking the negative side and
maybe it's the positive side. You know what, we're going to be running our
own email server inside of our organization. And the internet is going to start sending
us emails. Well I need to allow .25 inbound to-- do you
see the point? Like knowing these ports is huge, not only
for just day to day use, but if you're a firewall admin that's a big
part of what you do. So, as such, and let me just hit what these
are: File transfer protocol, send and receive files,
SSH secure shell; that's essentially secure Tellnet, a way of accessing our Cisco devices
and managing them securely, among many other things you can do with SSH.
We have Tellnet, which is the unsecure way of managing your different devices.
We have SMTP, which is simple mail transfer protocol, email.
DNS server, now on the TCP side this is used when you have to DNS servers and he's
like I know everything about ants.com. I have all those records and I want to replicate
those to you so you know about ants.com as well.
That's the DNS server side, port 53. You got http, enough said.
POP3 is an email client. So, if I'm sitting here on this PC I can say
I want to go download my email from a POP3 server.
Now I have it in the list because it's- it's common, but it's not as common,
but port 143 is actually IMAP, IMAP4. Another way of email clients working, POP3
says I'm going to download all of these onto my computer and most of the time delete
them from the server. So, it's all on my computer.
If you're an Outlook *** that's where you create your PST files in Outlook.
IMAP4 says I'm going to get my email, but I'm going to leave it on the server.
As a matter of fact, I'm just going to be eyes looking at the server,
just tell me what email is on there. So, IMAP4 is a little better because you put
your faith in the server staying online and not crashing and not your own PC.
Whereas POP3 if you lose your PC you lose all your email.
So, that's just a bonus side note. And then we have, of course, 443 HTTPS secure
web surfing. On the UDP side we have a DNS client.
We saw that tons in the last nugget, used for all those DNS lookups and then we have
port 69, which is used for trivial file transfer protocol.
That is used all the time with, I'll say Cisco but any network equipment vender or IP telephony
device. Essentially the difference between these two,
besides the one running on UDP and one running TCP is this one is secure,
secure in the sense that that there's a username, there's a password.
You have to log in. A lot of time you can restrict your permissions
and all that. This one, no login required.
You just kind of send and receive files. That's real easy, so you can-- you know what
I'll talk more about TFTP plenty, because we'll be using it later on in this
series. But like firmware updates for Cisco devices,
configure-- you know saving a configuration file that's
all done using TFTP. The last thing I want to do in this network
foundations section is put all of these pieces together.
I mean the last four nuggets have really been dissecting and looking
at all the different layers of the OSI model and the depth of functionality
that they have, the IP protocol and all of that.
So, I just want to take these puzzle pieces and assemble this landscape with them and
say, okay here's how they all fit together.
So, first off I want to mention that I redrew this network diagram
with a little more real world. You might recognize this one from one of the
previous nuggets, but previously I had you know IP address,
subnet mask, gateway. IP address, subnet mask, gateway.
It just was really cluttered. That's actually not normal for a network diagram
to do that, although you could. But what is normal is for people to just say
okay, this is the 172.30.100 network, like up to this first router, because the
router ends the network, right. Is 172.30.100.0/24, now that's classy subnet
mask, so this represents the network. This represents the host and then you can
see all of the other ones, you know what networks these are, every single
interface of the router represents a new network.
And then they'll put the IP addresses on the devices.
They'll say this guy is actually .100. This guy is .1.
You know he's the default gateway and you know I'll flip colors.
On this network he's maybe .1. On this network and he's .2 and over on this
network we have .1 of 172.30.1 and then this server here is, let's just make
him .70 is his IP address. So, this is our landscape, right.
Now here's the scenario. This computer opens a web browser and types
in http://172.30.50.70, which is this web server over here.
Now, I'm taking DNS out of the picture. You know we're typing in the IP address manually
instead of typing in www.something and letting DNS get involved, because they're
just-- there'd be too much to talk about if we did
that. So, we hit the enter key on our keyboard,
what happens. Actually you know what if you are feeling
like a stud or studette pause right there, pull out a piece of paper and write just a
list of steps. Here's exactly what happens Jeremy when that
happens and then unpause and come back, okay. So, if you paused welcome back.
If not, here we go. So, we've got this, we've got this computer
right here going to this web browser. First thing it does is go wait a sec, that
is not on my network. I'm looking at my network 172.30.100 that
is 172.30.50, ehh not me. So, I know that I can't send an ARP message
and just you know talk to that guy via a broadcast. I have to send an ARP message and it's for
my default gateway, this .1. So, it sends an ARP which is a broadcast message,
goes to everybody that's attached to that switch.
They all ignore it except for the router who says op,
that's me and what you're looking for is my MAC address.
Now let's give these guys some quick MAC address information and let me flip to a red.
So, his MAC address is 1111. He's 2222, I know, I know.
They're 12 characters but that's a lot of writing.
So, we're just plugging in MAC addresses all the way across the network.
Okay, so this guy comes back and says hey, my MAC address is actually 2222
and that's what you need to assemble your packet.
So, this guy says okay, I'm going to assemble a packet.
Now, here's the trick question, what's he sending?
Well remember, first time he's trying to talk to this guy what's he going to send?
HTTP, it's going to be a TCP based protocol and before we can do anything we have to shake
his hand. We have to do a three-way handshake.
So, what's in this packet? SYN, synchronization bit that's going to say
here's what sequence number I'm going to start at and tell the other side I want to start
a session with you. Now, he starts encapsulating that packet.
He says okay transport layer information, this is going to be 2A,
we'll say from a source TCP port of 5511. Now, where did that come from?
Well, windows makes it up, dynamically generated source port just for the session.
The destination port, however, is well known, so I'll have destination TCP port of what
do you think, 80. He's using HTTP right?
So, now the computer, Windows is ready to receive back on port 55511
and he's sending to a destination port of 80.
So, from there we have the source IP address where we're coming from, 172.30.50 no wait
a second. No, not .50, 100.
I'm staring at the URL there, .100.100, that's. So, 100 100, that's-- so our IP address is
our source IP. Then we've got our destination IP of 172.30.50.70,
that's where we're going. So, we're building this packet.
We're encapsulating it. We've got all the overhead needed to get to
the other side of the network. Two more things that need to be added on there,
one is going to be the source MAC, which in our case is 1111 and then finally
the destination MAC, which in our case is 2222.
What it's saying is I'm going to use this route.
I'm going to go to that router in order to reach this destination IP address of 50.70.
Now something I wouldn't expect you to know and I haven't spoken about until now,
but when you get down to this level of the data link you're actually creating something
technically called frame. We'll talk about that in just a second.
Because the very, very last thing it does before it's going to put this on the wire
and send electric signals is it sticks a piece of information at the end of this packet.
Some people call it the FCS. Some people call it the CRC; it's the same
thing. It's the frame check sequence or cyclical
redundancy check. Think of it this way, the hardware of the
network card, almost every network card, can do this built
in. They've got chips to do it, but it has like
a little hashing blender. It's a mathematical formula where it takes
that whole packet, throws in the blender and goes [Sound effects] and spits out this
little-- it's called a hash. It's like a you know we'll say a 32 character
you know 115AB9C, this giant hash that's blending all this together
in a mathematical formula that it generates and it takes that hash and
puts it right at the end of the packet. The packet goes all the way to the end of
the other side and before the server even processes
and looks at that packet, it takes all this information right here,
throws it in the blender, hits the same puree button.
They've got the same mathematical formula [Sound effects] and spits out this answer
right here, which it then compares to the frame check
sequence sitting at the very end. If they match, he goes great.
This is a good packet. If they don't match the server immediately
drops it because he says this is, this is not a good
packet. Either there's a malicious person that's gotten
in the middle of me and this person and modified some data inside of there or
more likely, there is just some kind of electromagnetic interference that went
by a fluorescent flickering light and it scrambled the packet or somebody's
chair rolled over the cable at just the wrong time,
you know one of those kind of things. So, it'll discard the packet.
So, this guy will send the message again, that's TCP.
So, that's what the frame check sequence is. And let me add one more, one more piece of
information. I said you know I've been talking about this
like a frame check with sequence, a frame. There is actually technical language that
people use for data at the bottom four layers. You know up here is those top application
layers, you know session, presentation application.
Those-- that all happens in the computer. We don't care about that.
But down here we have physical data link, network and transport,
technically speaking you're supposed to call data different things as it passes
through each layer. At the transport layer you call it a segment.
Like if you're talking about data being encapsulated, you say oh yea,
we have some segments being created or down here at the network layer,
that's where you call it a packet. At the data link layer, you call it thinking
it, but saying data link, a frame. And the reason-- and I mean you look at it
and you go oh, I can see the reason it got that name, because I stick information on
the front and end of the packet, thus the name frame,
ah. And then down here at the very bottom we have
the physical layer, where we have BITS getting involved.
So, that's where we're saying I'm sending BITS on the wire.
So, technically if you're a purest and I haven't met many, you would say okay well,
we've got frames going around the network or you know if we're talking
about physical infrastructure, well okay, well the BITS are being corrupted by you know,
well that's how you're supposed to refer to things.
However, everybody nowadays calls everything a packet,
just because it's really easy and you don't have to think.
So, I do the same thing. So, everything going across the network is
a packet, but technically you're supposed to say
as the switch receives the frame. Did I say it was sent?
Okay, the device sends it right. So, as the switch receives the frame, because
it's a layer two device, it looks at the source MAC address and I'll
say here's a bonus piece that we'll talk about later.
If it has never heard of the source MAC address 1111 before, it learns out and that how it--
it goes oh, I didn't know that, 1111 is actually on port 5, great.
I'm now a little smarter. And then it goes okay destination MAC address,
2222, it goes oh, well I learned about that. That's on port 9 over here, so I'm just going
to switch that right over to this router at and I'll say almost all switches nowadays
are wire speed. So, there's no, no delay at all coming into
that switch. So, the router receives it.
The router looks at it and goes oh great, I've got mail.
You've got mail. He looks at it and he goes that's my MAC address.
So he looks a little further and he goes oh, it's not going to me it's going through me.
It's going to 172.30.50.70, which is not me so I am going to look at my routing table.
And in the routing table he's looking for a route to 172.30.50, not 70 at 0/24.
Because routers don't really know abut hosts. I mean they can, but you don't want them to.
They know how to reach networks, so in its routing table he's going to say oh, I remember,
to get to the 172.30.50 network, that's this guy over here, I need to go to where, 10.5.1.2.
That's this guy, now wait a sec, wait. Whoa, how did he know that.
Well, because somebody had previously taken this series and had configured him to know
that. They put him in the static router or something
and configure that device to know, because it won't know it by default.
You have to, that's your job as a Cisco person is to configure it.
So, it's going to go okay, well to get to that IP address, which is him,
to get to that IP address I'm going to tear off [Sound effects] the old source
and destination MAC address and replace it. Now the new source is going to be 3333.
The new destination is going to be 4444, right. But if it had to send an ARP message to figure
out who that is because he just knows the IP address, he would
do that. However, most routers will have all that information
cached. It'll have done it before at some point.
So, it then puts that packet, it puts the frame into BITS on the wire and then sends
it over here to the router who receives it, has
the same immediate reaction, oh great, I've got mail because this is my MAC address.
And he looks an he goes, oh that's not me. That's actually something connected to my
land. That's fantastic.
So he's going to send an ARP message if he doesn't know already to try
and find the MAC address for this guy. This guy responds back and says I'm 6666.
He then fills in the new, again crosses out the old, strips it off
and puts the new information on there. It's coming from 5555, going to 6666 and he
just received a SYN. Again, and I know we've done similar diagrams
with less pieces like this before, but I have to say it again.
We were doing Wireshark captures of this and seeing this all happen in what,
like end-to-end it would get there and back and .1, .2 second time frames.
I mean it's just crazy how fast all of this happens in between.
So, this guy realizes, oh you want to talk to me.
This is the first message of a three-way handshake. I see that your sequence number is going to
begin at, it does-- I know in the last nugget it was 0, we saw
that in Wireshark, but it's not always that way.
Let's say in the SYN message he said my starting sequence number is going to be 1000.
I'll start sending from byte or number 1000. So this guy comes back and he'll generate,
you want to remember a SYNACK. He's going to generate a SYNAC and it'll say,
okay well I'm going to start sending data to you.
I'll start from the number 500 and its internal Windows figures all that out
of whatever sequence number he'll start from. And I'm going to send an acknowledgement that
I received your starting point of 1000, so what's the acknowledgement going to be,
1001. It's always one more than the SYN.
Oh heavens, if I were to break it down every single time,
same process right all the way back through. This guy says okay, I've got the SYNACK, he
does it one more time. He sends an ACK back Jack, with the ACK number
being 501, like I've received your SYN at 500.
I know where you're going to start sending from.
Now, let's start sending now after all of this I've filled a screen full of information.
Now, he sends a request, the data instead of a SYN.
It would now actually be an HTTP most likely, would be a GET message for HTTP
like give me your webpage, whatever default webpage
that you're looking for unless you specified. I said I want index.htm or something like
that. Then it would have httpget index, you know
.htm. So, that would be the actual data, same thing
all the way back here and then sending back as data begins to transmit Window sizes for
TCP are increasing. Are you feeling this?
Really, I mean seriously, like I just reached the end of this and right now,
I know someone out there is like, oh I get it.
That, makes total sense. Now if it doesn't and you're like [Sound effects]
no worries, it's great. Rewind, you know but I know just all those
pieces that we've talked about in the last four nuggets came together
right there. So, that is the complete end-to-end story
of network communication. What did we see and what do I want you to
do with it? Well, we kind of put the lid on network foundations,
seeing the common port numbers that you want to know and I would definitely
commit those, especially the TCP ones to memory and then we completed the end-to-end communication
story, putting all layers one through four together in that big communication.
So, what do I want you to do with it? Well, number one memorize those port numbers.
You'll need them for the exam and for the real world.
Second, is use Netstat. Use that Netstat utility that I've been showing
you a number of times to find out if you have a virus.
[Laughter] I haven't said that until now. Like really, go in and close everything down
on your computer and type in Netstat and press enter.
If you see like 50 or 100 different sessions that are open
on there, that's not good, usually. That means something that's running
in the background may be sending spam from your computer.
It's a BOT, you're infected. It's trying to attack or scan other devices.
Now, I'm not saying that if you see a bunch of stuff there you're absolutely infected.
I mean people have all kinds of stuff. I mean you got Dropbox running in the background.
You got Pandora playing music. You know all that could be, could be on this
list, but I mean seriously that's a quick way.
That's what I do whenever you know somebody's like my computer's running slow.
First thing I do is open that [Inaudible] and see if there's some kind of weird,
weird stuff going on behind the scenes. Next thing I'd recommend you do, write it
all down. If you haven't been taking notes, rewind back
to that end-to-end story and create your own little network diagram
or even better yet envision it yourself. You know go to a website on the internet,
stare at it for a minute and then say, okay I'm going to draw up on paper how the
communication for my house, I mean use your IP address.
Use your ISP. You know fill in all the gaps of your own
picture of how you communicated that website. Then explain it all to a friend.
That's absolutely the best way to learn something if you can get somebody to sit down.
Usually a spouse works well or a pet. Then Wireshark, if you didn't do that in the
last nugget go to the last page of the internet. Remember I showed that to you?
Go to the last page of the internet, real simple webpage and just capture
that Wireshark data and analyze it. I hope this has been informative for you and
I'd like to thank you for viewing.