With previously talked about the OSI model, but did you know that
it's not the only model out there? Its competition
is the TCP/IP model. In this video we're going to learn about this model
and see its perspective on the network.
If you haven't seen the OSI video yet,
now is the time to go back and check it out.
As we discussed there, a model is a set of layers
that describe how network hardware and software work together.
The goal behind the OSI model
was to allow different protocols and vendors to work together.
The idea was to build protocols directly
based on this model. But we don't see a lot of them today.
The main reason is that the protocols from the competition,
the TCP/IP model, gained more popularity.
The TCP/IP
framework was originally developed by the US Department of Defense.
Later, various universities and other parties got involved.
This led to rapid development, which is probably why
it has been more successful than OSI a practical sense.
Now we have protocols like TCP, UDP
and IP which align directly to this framework.
Another reason this framework has been so successful
is that it's willing to use existing protocols like Ethernet
if they already exist. It doesn't try to reinvent the wheel.
Any protocol that is created as part of the framework
is defined in an RFC document.
Maybe you haven't come across these yet.
RFC means request for comments
and is a very technical explanation of how the protocol or concept works.
Some of these have
been around for decades and are still used today
as these documents are available to everyone.
Any vendor can create hardware and software using these specifications.
They'll all work together.
Right now we're looking at RFC 1122, which is the original description
of the TCP/IP model released way back in 1989.
Now let's take a look at the TCP/IP
model a little closer.
Just like OSI.
This model is made up of several layers.
You can also see that there are two TCP/IP models
which I've listened to here as original and current
The original model had four layers
and was defined in RFC 1122, which we looked at earlier.
The revised model splits the bottom layer
into two separate layers, which we'll talk about soon.
The fantastic thing about the current version of the TCP/IP model
is that it lines up well with OSI
You can see that the session, presentation
and application are all rolled into a single application layer.
Personally, I prefer this.
I like to think of this entire area as the application
rather than trying to break it out like OSI does.
I also personally think
that we can break these models into two main areas.
The top half is the application and their processes. In the application layer,
we're talking about protocols like HTTP for web browsing, SMTP
and IMAP for mail delivery, and FTP for file transfers.
These applications create processes which listen on particular ports.
That's the job of the transport layer, which uses the TCP and UDP protocols.
We'll dig deeper into those very soon too.
the bottom half
focuses on getting the data from one host to the other.
The network layer uses the Internet protocol or IP
you should be pretty
familiar with this from the last two videos.
The physical and data-link layers move the data from device to device
that is across switches, access points, routers, and other network equipment.
Ethernet is a very common protocol here,
and on this we can see that the new version has broken
the original link layer into the data-link link and physical layers.
In the old days, there weren't very many different physical connection options
Now we have Ethernet, Wi-Fi, fiber optic cables, and so many more.
While it originally didn't make a lot of sense to break up the physical connections
from the data delivery, now we really have to.
and that's why we now have two layers here instead of one
Now into some more detail starting at the top, the application layer.
This layer defines
the communications between applications on two hosts.
This doesn't define how the applications work, of course.
Instead, it describes on how the applications use the network.
More examples here include SSH, Telnet
and RDP for Remote Administration.
But we're just going to focus on HTTP as an example,
because even if you don't know it, you're already familiar with it.
We start with the applications.
These are the web browser
on the client side and the web server software on the server side.
HTTP is a protocol that the applications use to communicate
if the browser wants to get a web page from the server.
It will send an HTTP request. Just like OSI, the request passes down
three layers on one side and back up through the layers at the other side.
Logically, one layer talks to the corresponding layer on the other side.
The server will go through the same process to respond
with the requested web page.
The transport layer creates and maintains
conversations between application processes on hosts.
This is where TCP and UDP protocols come in.
We haven't discussed these a whole lot yet.
But put simply, they use port numbers to track sessions.
Let's continue using HTTP as our example.
The web server may have a process listening on Port 80
when the client prepares its HTTP request.
It will add a TCP header.
We saw headers previously in the OSI video as well.
The TCP header contains,
among many other things, port 80 as the destination.
It will also choose a port to send the request from
after the header has been added.
We call this entire piece of data a segment
when the server responds.
Port 80 is now the source, and the client's port is the destination.
The combination of port numbers, along with IP addresses enables systems
to have more than one session open at a time and to track them.
Without this, you couldn't have multiple tabs open in your browser,
for example.
There's a whole lot more to TCP, and we haven't even mentioned UDP yet.
So we'll have a look at them in a bit more detail in the next video.
Now back to IP addresses.
We've covered them along with routing and submitting in detail in the last video.
When the transport layer is done, the data is passed to the network layer
where he's broken into packets which are manageable chunks of data.
We may end up with a single packet or many packets.
It all depends on how much data there is to transfer
the point of this layer is to make sure
that data from one host can find its way to another host.
And to do that, an IP header containing the source and destination
IP is added to every packet.
The path from one host to another may cross many networks.
Packets need a router to pass from one network to another.
That's why it's called routing.
When the packets arrive, the host strips the IP headers off
and reassembles the packets into the original data.
Before it's passed back to the transport layer.
Other network layer protocols you should be aware of
are ICMP and ARP, but IP is enough for us right now.
So we'll discuss the other two another time.
Now it's time to quickly check that you've been following along.
Let's say that you have
two hosts on two different networks and they need to communicate.
What device makes this possible?
And as usual, the answers are on the website.
The data link layer is responsible for delivery of traffic
on a single network segment or LAN
in TCP/IP terms.
This means delivery within a single subnet.
Common protocols here are Ethernet and point to point protocol.
Ethernet is very common, so we'll use that as our example.
An address called a MAC Address is assigned to every device.
Other protocols will use some form of addressing as well
to add these addresses.
We add another header.
In the case of Ethernet, a trailer is added as well.
This entire piece of data is called a frame.
If the two
hosts are in the same subnet, then delivery is simple.
One host just sends to another,
but if they are in different subnets, we need a router.
That means that the destination MAC
will be the MAC of the router itself.
When the frame reaches the router, the router works out where it needs
to send the packet by looking at the destination IP in the IP header.
It then sets its own MAC is the source, and the next device as the destination.
If there are several routers in the path,
the MAC addresses in the frame will be rewritten several times along the way.
What are the names of each piece of data,
We're they're encapsulated in TCP,
IP, and Ethernet?
The physical layer is exactly what the name suggests.
It's responsible for physically transmitting and receiving data.
There are many ways this can be done.
Electrical radio and light signals are the options that come to mind.
In any case, the data is encoded and the bits are transmitted over the medium.
This will likely happen a few times along the path, like copper from workstation
to a switch fibre between switches, and copper through to the destination.
Let's check now how much you've learned.
How many headers and trailers
will the original HTTP request be encapsulated in,
by the time it reaches the physical layer?
What are the primary differences
between the OSI and TCP/IP models?
What are common
protocols that are used at the datalink, network,
and transport layers?
If you are studying for the CCNA
exam, have a look at the official study guide.
I'll include a Link in description for you
in the next video.
We're going to have a look at TCP and UDP.
I hope you like this video.
Please let me know what you think in the comments.