Application Layer Basics

The OSI model and the TCP/IP model

In this module I said we're going to be looking at layers five, six, and seven, although I also said it's the application layer. The reason for the discrepancy is that there are two different models out there.

There's the older OSI model, that a lot of the older protocols will fit into these three separate layers. Perhaps one of the layers is actually setting up the connection between two different applications, where maybe there's some sort of encryption that's happening at a different layer. So there's a reason that it's separated out into the session, presentation, and application layers.

Although with some of our newer protocols, it really is all combined into one layer. The reason for that is that we combine all of the — let's say the encryption — it's just incorporated into the protocol at the application layer itself. So for instance we have HTTP, which operates at layers 5, 6 and 7, or in the OSI model it's in the application layer. But then when it comes to HTTPS, which is a secure form of that, it once again operates all at those three layers, so all at the application layer.

So you'll find a lot of your newer protocols that you'll be working with in that TCP/IP model. Although if there are some older technologies that you're working with, or something that's a little off from what we're used to dealing with with the internet, then you may find some other protocols that fit better into the seven layer system, where session, presentation, and application are all broken out separately.

Back to the OSI model, what we're looking at is layers five, six, and seven, and we've got several examples here for each one. So five, six, and seven are broken down into session, presentation, and application. A lot of the protocols that, once again, we will be working with fall within this layer 7, or in the TCP/IP model actually span across all three of these layers right here.

As we're looking at it, it really all has to deal with getting the data prepped and ready to go, to be sent over. It's transmitting that, so where the applications then are talking between each other. You probably have some sort of client application that's talking to some sort of server application and communicating back and forth. So that's where we are going to be, at layers five, six and seven, going forward with this module.

Peer-to-peer and client-server

One thing to understand is there's a couple of different scenarios here with the relationships.

In this example right here, let's talk about peer-to-peer. Let's say we have a printer now that's hanging off of this machine right here, and this machine is sharing this printer out and all other devices are then accessing it. Really, it's still somewhat of a client server, in that these machines have some sort of client application that's running on them and then accessing some sort of server application that's running on this one that's sharing out this printer. So in essence, there's still a client server relationship, except the difference is when it's peer-to-peer, then that means that these devices are really at the same level.

So this device right here is still a client machine. There are still users that are getting onto this machine and utilizing this machine for their day-to-day workload, but they happen to have a printer that's hanging off of it that's sharing out to some of these other devices. And perhaps maybe this device right here on this end is sharing out a shared folder and providing services to these machines right here.

So the idea behind this is there's not really a server that's dedicated to sharing out files and folders and printers and that type of thing, but instead everybody just kind of shares the workload, and their user machines — people just share out resources on those users' machines. So there are peers sharing to other peers, and that's why it's called peer-to-peer.

Then there are client server relationships. Once again there are client applications that are out there that are trying to get services from a server application that's out there, but there is also the idea behind it that we actually set up a server for the purpose of administering different services, and that's its sole purpose. So no one gets onto this server right here and uses it as a desktop machine. No, instead it's just a server that's handing out different services to these different clients.

Perhaps it's to machines that are on the same network. So this could be like a DHCP server and a DNS server that's handing out services to clients that are on that same network right there. Or perhaps it's a remote network that it's administering these same services to. So there are times when a DHCP server or a DNS server is actually on a separate network, and these machines right here have to reach out to this server in order to get some sort of services from that server.

It's definitely the case — or I should say most often the case — when you have a web server that's hosting out HTTP, then there's a good chance that that's probably on a separate network other than your traditional client machines, or your LANs that have your users that are actually accessing those servers.

Application layer protocols

So what are some different protocols that exist on this application layer? Here's a big long list of them, and you probably recognize a lot of these from when we were talking about the ports, because there are a lot of ports that are associated with these different applications.

As we can see here, there are a lot of different applications for file transfers, which would be the first few examples here. Mail would be the next few examples here. And you're probably very familiar with HTTP and HTTPS, as with web services. DNS for name resolution. Telnet and SSH for remoting into machines. RDP for remoting into machines. DHCP, which we're going to talk a little more in depth about here in a second. Network time protocol. So there are a lot of different protocols here that exist at this layer and really facilitate, or help, users be able to access a lot of different resources. Let's get into some of those different applications and see what they do.

DHCP

First up is DHCP. The reason why I chose DHCP first is because really it's probably the first service that your computer is accessing when it starts up.

The reason for that is there are several things that we need on a computer for it to access the rest of the network. We do need an IP address. We need a subnet mask. Those two things will give it access to the local area network. We also need a gateway for it to access the rest of the world, and we probably are going to use DNS, so that we can access a lot of different resources by name rather than IP address. So there are some things that your computer needs in order to connect to the network.

So enter dynamic host configuration protocol. Dynamic host configuration protocol gives this information to the computer. When a computer connects to the network, somehow it's going to need to get this information. We could statically assign this to the machine, and what that would allow us to do is specify this machine has this IP address, it needs to get to this default gateway to get to the outside world, and it has this as a DNS server. We could statically assign that to that machine, but the problem is, anytime we take that machine to another network and connect it into there, then we would have to manually go and reset all of that, and make sure that we don't have an IP address that's already been handed out.

So in order for us to be more portable and take things around and be able to really manage these machines much easier, we set up DHCP, or dynamic host configuration protocol. That way, when we connect a laptop into this network right here, then it's going to be assigned an address to that network — it's going to be assigned an IP address and a subnet mask and a gateway that's relevant to this local area network. And then when we move it to another network, then it will be assigned according to whatever network that we connected into, provided that they have a DHCP server.

In this example right here, let's say our DHCP server is this 10.40.40.5. This machine connects into the network. It says, "Hey, I need this information," because it has a DHCP client on this laptop right here. And this is a DHCP server, and it says, since I'm a DHCP server, I'm going to give you an IP address and also let you know what the subnet mask is, gateway, and DNS for this local area network right here. Then when I move over to here, let's say that the 172.16.43.4 is then the DHCP server over here, and then it would hand out that information for this local area network over here.

URLs

The next application layer protocol that we're going to be talking about is going to be DNS. But before we do that, I'm going to talk about URLs. A URL is not a protocol. A URL is a way to identify resources that are out there, and so there are some specific ways that we configure URLs and what they look like. An example of a partial URL is www.techknowsurge.com.

We're going to get more into URLs and what the full URL is. We're also going to compare what a URL is compared to a URI. So we're going to get into all of those details, but not quite yet.

For the purpose of this, a URL is a uniform resource locator, and it identifies the resource that we're trying to get to by name. An example is this www.techknowsurge.com.

Typically, when a user is typing into a machine, they don't type in an IP address, unless you're like a system administrator or network administrator or network engineer. Usually most users are typing in names of resources rather than IP addresses to get to those resources.

DNS

Somehow we have to translate those URLs that users are typing into their application, so they can get to a resource. Instead of that URL, the machine is going to get to that location using an IP address. So somehow it needs to translate from the URL to an IP address, and it does that through the domain name system.

The domain name system allows us a way, a mechanism, to translate these URLs into IP addresses, so that we can get to that resource. There's also a lot of other features that come into it. It's not just translating names into IP addresses; there are a few other lookups that it does to get the location of these resources. We're going to talk more about DNS and fill out all of the information about DNS — or not all the information, but a lot of information — later. But for the purpose of this, we're just going to say that the domain name system allows us to translate from a URL to an IP address, so that when we send packets asking for certain resources, we know where to send that.

HTTP and HTTPS

Of course, DNS is used in a lot of different scenarios to get a lot of different resources for a lot of different protocols, but one of the really common ones is HTTP and HTTPS. That allows that machine to go to these different servers that are out there and then get web pages and do a lot of other functionalities.

HTTP and HTTPS is quite capable of doing a lot of different things, but it essentially is to go and get these resources on the web, so that we can get those resources back to our machine. It uses protocols such as HTTP, hypertext transfer protocol, and HTTPS, which is hypertext transfer protocol secure — or HTTPS could be HTTP over SSL. We'll talk about some of the differences of that as well later, but for now, HTTP is just a protocol that allows the transfer of this information back and forth, or allows the transfer of HTML pages back and forth, or allows the transfer of different pages, pictures, and other resources back and forth between a server and a client machine.

Email protocols

Another very popular service out there is obviously email, used to send messages and files back and forth. Email services are — that's not a protocol in itself, but there are multiple protocols that allow this to happen.

One example of that is simple mail transfer protocol, which allows us to send mail. SMTP sends mail. So you have a user here that wants to send mail to another user, and that user may or may not be online. This user might be offline at the time that you send it. So there needs to be some sort of asynchronous communication that happens back and forth, which means that it's not necessarily happening all in real time, and that user is not going to get it right away. They could get it the next time that they get online. That is one of the reasons why there are multiple protocols that are set up with this.

A user will send mail using SMTP and it will go to a server, and then from that server, that server will have to look up and say, "Hey, where is that email going to go to?" because it's going out to some other domain or some other resource that's out there. So it has to do a lookup and figure out what server it needs to send that to, and then it will send that message to that server, once again through SMTP. So SMTP is really the primary way that it's going to send this information out. And there are a couple of protocols that also operate just like SMTP, but in a secure manner.

Then we need some sort of way that, when this user comes back online, how is it going to get that information or download it onto that user's machine or onto that phone? There are a couple of different types of connections. POP version 3 is one of those, or perhaps it makes an IMAP connection. There are advantages and disadvantages to those two protocols. I would say the IMAP is the more popular of the two at this point. These users then will turn on their machine, turn on their email client, and then that email client will go and fetch or grab that information and pull it down to the user. So then the user has access to that email.