Have you ever wondered how computers actually talk?
maybe you're someone studying for a computer certification,
or someone who just wants to know how things work.
In simple, clear and concise English,
this tutorial will show you exactly how.
In my example, I have two friends:
Please say "hello" to John
and Sarah.
Now because they live in different time zones,
the only real way they can keep in touch,
is by digital communication.
This tutorial will show you the real
nuts and bolts of how computer traffic flows.
You'll learn how the email
leaves John's computer
and a few seconds later
arrives on Sarah's computer.
How is this possible?
When it used to be weeks
or sometimes even months
to get information across these distances.
Let me introduce you to
Open Systems Interconnection standard.
Commonly referred to as OSI
or the OSI Model.
So what is this OSI Model?
Firstly, I'll tell you what it is not.
There isn't a button
or setting called the OSI.
You can't go and make any changes in the settings app
or control panel.
It's a framework
to which companies around the world agree to.
What I mean by a framework is:
let's say I design a new plug,
and my plug has three pins.
Each of the pins are a
specific length and shape.
Now all plug companies around the world
agree that this is a brilliant plug design
and it becomes the industry standard for power plugs;
and of course all the companies that
make the power sockets
change their designs to fit my plug.
It doesn't matter what device you attach the plug to,
power should flow as intended.
We now have a framework for a power plug.
So in essence, the OSI Model
is a standardised architecture,
which defined the network communication.
It was developed in 1984
by the International Organization for Standardization,
also known as ISO.
If you want to find out why
the organisation's initials are ISO
and not IOS,
please direct your questions directly to them.
The OSI Model was designed to allow
cross-platform communication.
Meaning Apple, Linux or Windows, possibly others
can all talk to each other.
They just need to connect to the top layer
of the OSI,
using the relevant application programming interface
for their Operating System.
This is known as the API.
So without further delay
let's look at the OSI Model.
The layers are always in this order
and counting from the bottom up.
Layer one is the Physical Layer
and proceeding up to layer seven,
which is the Application Layer.
This is useful when troubleshooting problems.
You may hear references to the problem
being at layer eight
but we won't go there.
A good way of remembering this order
is to use a system like this:
"Please"
"Please" "Do"
"Please" "Do" "Not"
"Please" "Do" "Not" "Throw"
"Please" "Do" "Not" "Throw" "Sausage"
"Please" "Do" "Not" "Throw" "Sausage" "Pizza"
"Please" "Do" "Not" "Throw" "Sausage" "Pizza" "Away"
Let's take a look at the Application Layer.
When we say the "Application Layer",
this is not the application itself.
Think of this layer as a socket
for the network aware
application to plug into.
And by saying "Network Aware"
I mean something like Firefox,
Internet Explorer,
Microsoft Outlook,
or FileZilla just to name a few.
Applications like Microsoft Notepad
do not care about the network,
so would not communicate with the Application Layer.
Let's move down to the Presentation Layer.
The Presentation Layer ensures
that parsing communications
are in the appropriate form:
Is the data the correct data format?
such as HTML, HTTP.
Is the data compatible with the
Operating System of the host?
Is the data payload
encapsulated correctly for transmission?
Is the data encrypted correctly?
Let's open the Session Layer.
A session is a persistent logical thinking
of two application processes.
The primary job of the Session Layer
is to provide the means necessary
to set-up, manage and end TCP sessions.
Session Layer software products
are more of a set of tools
rather than specific protocols.
These session layer tools are normally
provided to higher layer protocols
through command sets often called
application program interfaces or API's
Common API's include NetBIOS,
TCP/IP sockets
and Remote Procedure Calls or RPC's
They allow an application to accomplish
certain high-level communications
over the network easily
by using a standardised set of services.
Now for the real magic to start.
Let's open the Transport Layer.
We're going to need a bit more room for this,
so let's just clear all this out of the way.
I'll draw up a simple diagram.
Here's my computer.
And my computer is connected to a switch.
The switch is connected to a router.
Now for the folks at home,
your switch and router is probably combined
into a single unit, provided by your
internet service provider.
But my router is connected directly to the internet,
and when it gets to the other end,
there will be another router.
This router will also be connected to a switch.
And finally, let's connect this switch
to our destination server.
This web-server is hosting Amazon.com.
It is the Transport Layer which defines how data is sent.
For example: here's a packet of data.
I'll come on to why it's called a packet later in the video,
but for now, just go with me on this.
The first question is:
Do I want to send reliably
or unreliably?
I know some of you are saying
"That's pretty obvious, of course I want to send it reliably",
but that's not always the case.
Let's match these up to some protocols
and you'll see why.
Reliably is TCP,
which is an abbreviation of
Transmission Control Protocol.
And unreliably is UDP,
which is an abbreviation of User Datagram Protocol.
What reliably means
is that we're going to do a three-way handshake
before we begin our transmission
to make sure our data can get there.
Our PC is going to send a request
to synchronise with the web-server.
This is called a "Syn".
The web-server will then confirm to say:
"Yes, I got that packet".
This is called a "Syn/Ack",
which means synchronisation acknowledgement.
My PC will then send the final handshake
back to the web-server.
This is called an "Ack",
which is an acknowledgement
that our PC can hear the web-server
loud and clear.
Now the three-way handshake is established
and the transmission of the data can begin.
Remember this three-way handshake
happens with every packet which is sent.
TCP is great for file transfer or backups.
But what about voice over IP
or streaming TV?
What if there's a blip on the voice call
or a corrupt pixel in the corner of the TV?
You can't stop the transmission
and resend the lost packet.
It's too late.
This is where UDP comes into play.
Where TCP is the
"I know it got there",
UDP is the
"I hope it got there".
UDP is sent without the three-way handshake
like a broadcast.
In addition to TCP and UDP,
the Transport Layer also manages
Application Separation,
which determines what ports
communicate with what applications.
To be precise, there are 65,536 ports available,
which are split into three categories:
Port zero through 1023 are considered
to be well-known ports.
You cannot change these
or use these for your own applications
other than what they are intended for.
They are sacred and considered to be set in stone.
Ports 1024 through to 49,151
are registered for specific applications.
And finally,
ports 49,152 through to 65,535
are dynamic ports,
which can be used for your applications.
Here's a list of the really well-known ports,
which should be committed to memory,
especially if you are
pursuing a career in computer networks.
But not only do we need to know,
which port to send the data to,
the return in traffic also needs to know
which window to send the reply to.
For example, if you have Firefox running
with multiple tabs open,
you want the data to
be returned to the correct tab.
This is done with TCP session ports,
not to be confused with the Session Layer.
When I open up Internet Explorer or Firefox,
these source ports are dynamically generated.
You'll notice that windows
very kindly makes it user friendly.
Instead of saying
port 443 or 80, it says port HTTPS.
But what we're interested in,
is the session port
After my IP address,
there's the session port.
You can find this information
just by typing Netstat
in the command window.
This command may very well be different
for non window operating systems.
You'll need to consult with Google on that, I'm afraid.
Let's move down to the Network Layer.
The Network Layer is responsible
for the logical addressing.
Today, everything is now IP,
but it wasn't always like that.
For those, who can remember the games like
Doom, Quake or Wolfenstein,
these games used IPX/SPX
and it was so easy to set up.
And the same for NetBEUI or Apple Talk.
But these have all since been deprecated
and IP is now ruling the world.
Now let's bring back our diagram.
When we're talking about logical addressing,
we mean IP addresses.
We have our IP address
and we have the website IP address.
Now when you type in the website IP address,
the computer does not instinctively know
how to get to the website.
It needs to find a route.
This brings us down to the Data Link Layer.
This bit causes a lot of confusion with addressing
as you're about to see.
Let's jump back to our diagram.
We've already established that
at the network layer,
we say that using the logical address
is the final destination
of where we want our data to go.
Let's say we want to buy a book from Amazon for £57,
so £57 is the data payload
and the destination IP address is this ...
The trouble is we don't know how to get there yet.
We know the web-server is not on our local network.
So we need to go to our default gateway,
which is the router.
He will be able to point us in the right direction.
Here's the confusion:
There are two types of addresses.
The first type of address is the physical address,
which is called the Media Access Control,
but it's usually referred to as a MAC address.
It's worth noting that different companies display them differently
For example Microsoft display a MAC address
like this: 32-64-C9-24-ED-5D.
Whereas Cisco will display the same MAC address
like this: 3264:C924:ED5D.
It's exactly the same it's just displayed different.
These MAC addresses are for the network interface
of every network device on the local area network.
The same as: the place where you live
has a unique name or number
to your road or street.
Likewise each network interface on every network device
should have a unique MAC address,
which was hard-coded into its chipset
when manufactured.
The second type of address,
which we've already covered in the Network Layer,
is the logical address or the IP address,
which is for the entire journey end to end
and does not change.
We refer to these as "Source IP" and "Destination IP".
Now both addresses play the part as the source IP
and both play the part of the destination IP,
depending on which way the traffic is going.
Think of yourself as the packet
going along this journey.
At this point you have the MAC address of the PC
as your source MAC address,
because it's the address you are leaving.
The way-point in front of you
which is router one,
is your destination MAC address
because it's the address you are heading towards.
But when you, as the packet,
pass through router one,
the MAC address information
is replaced with new data.
The MAC address of router one,
which you are now leaving,
becomes the new source mac address.
And because you are now heading towards router two,
this becomes the new destination MAC address
and the process is repeated
at every router along the way.
As you pass through router two,
the MAC address information is replaced,
router two becomes the source MAC address,
and finally the web-server
becomes the destination MAC address.
And then you've got the return journey.
Let me explain in more detail.
Now we want to send £57 reliably
to our web-server.
So the £57 is the payload.
The reliability is TCP.
The destination port is 443,
which is HTTPS.
It has a dynamically assigned source port,
we have our IP address
and the destination IP address.
We have the source MAC address of the PC
and finally
we have the destination MAC address
of "Router 1".
Now all this information is encapsulated
into a packet and sent.
While I remember,
let's just bring back our OSI Model.
When the data is at the Transport Layer,
it's called a Segment.
When the data gets to the Network Layer,
it's called a Packet.
and at the Data Link Layer,
it's called a Frame.
And finally,
when it gets to the Physical Layer,
it's called BITs.
But these days
everybody just calls it a Packet.
So back to the Packet.
As I said, all this information is encapsulated
into a packet and sent.
Once it gets to the first router,
the packet is analysed.
And a router is designed
to block local traffic,
so in this case
it's the source and destination MAC addresses.
So those are striped from the packet.
The exiting interface of the router
becomes the new source MAC address.
And the destination MAC address
is the next router.
The packet is then encapsulated again
and passed on to the next router.
Once again,
It's inspected
and any local traffic
is stripped from the packet.
Same as before
the MAC addresses are replaced,
the packet is then encapsulated
and sent to the switch
for delivery to the web-server.
Because it now knows
that it's on the same network.
After passing the packet up through
the OSI layers
the data is delivered.
Now we're down to the Physical Layer,
which is the network card
and the network cables.
I hope this has been informative
and thank you for watching.
If you like this tutorial
give us a thumbs up and subscribe.