The Application Layer : Process-to-Process Communication
During this tutorial, we have gone through the first four layers of the OSI Model and discussed each of them separately in a dedicated chapter. Now, in this chapter, we will skip two layers and go ahead directly to the application layer.
Now before we can proceed to the next and top-most layer, let’s first have a few words about the session and presentation layers.
Session and Presentation Layers
In our first chapter, when we talked about the roles of each layer of the OSI model, we said that :
- The session layer is responsible for keeping the state of a connection between two applications.
- The presentation layer is responsible for converting data to the correct format that is acceptable and understandable by the application.
You are probably wondering why these two layers don’t get to have a chapter of their own. The answer is that, in real life, they do not provide any networking service, and all their responsibilities are directly undertaken by the application.
Furthermore, these two layers add no header. The data that the application layer provides is directly encapsulated by the transport layer.
So let’s go ahead and move on to our last layer.
As its name implies, the Application layer is what allows applications to communicate. This is the nearest layer to the end user, and therefore most of the protocols that it uses are more familiar to us than those of other layers.
Contrary to what we’ve seen so far with the other layers, this layer does not have one or two protocols. It has as much protocols as there are applications.
We will only address the most common application protocols in this chapter.
HTTP (HyperText Transfer Protocol) is the main protocol that allows the sending and receiving of web pages. It operates on the port number 80, and uses TCP as its transport layer protocol.
HTTP is not secure for navigating, especially if you are sending sensitive data like a password or credit card information. This is because HTTP sends data in clear-text, so anyone who is eavesdropping can access this data.
One secure alternative is using the HTTPS (HTTP Secure) protocol. HTTPS adds encryption to the data before it is transmitted. This way, if a person intercepts this data, they wouldn’t be able to make sense of it.
You should always confirm that you are using HTTPS when you need to send sensitive information.
For example, in most web browsers, when you connect using HTTPS, you should see a lock next to the address bar. This means that the connection is secure.
FTP (File Transfer Protocol) allows for sharing files between computers. It uses port 21 and operates over TCP protocol.
FTP will normally require a username and password when trying to connect to a distant computer. Once connected, files can then be sent and retrieved easily.
Just like HTTP, FTP does not provide encryption and transfer files in clear-text. Therefore, it should not be used for sharing sensitive files.
One good alternative is using SFTP. This protocol is more secure in that it encrypts the communication which prevent eavesdroppers from intercepting it.
Telnet and SSH
Telnet is a protocol that was commonly used for accessing a command line interface of a remote computer.
The command line is an interface that allows you to type in commands and execute them. This is how it looks like in Windows.
With telnet, you can provide your username and password, and then access the command line interface as if you were physically in front of the remote computer.
Telnet is not used a lot nowadays due to its lack of security. Just like HTTP and FTP, telnet does not encrypt communications. It is therefore not recommended anymore.
SSH (Secure SHell) provides a better, more secure alternative. It adds encryption to the transmitted data and allows for a secure remote access even if it was over unsecured networks.
SMTP (Simple Mail Transfer Protocol) is the protocol that is most commonly used by mail services to transmit and receive emails between servers. It operates over TCP and uses port 25.
Of course there are other protocols that we did not cover here. Don’t worry, we will address most of them in future chapters. For now, just remember the protocols that we have learned in this chapter, and remember which ones are safe to use and which ones are not.
If you’ve made it so far, then good job! You have completed the first part of this tutorial. In the next part, we will address more intermediate concepts related to computer networks. So if you still have some difficulties in understanding some of the concepts we discussed so far, then you should take your time to re-read and revise the parts that are causing you problems. Remember that you can always contact me if you need further clarifications.
Now if you are comfortable with the basics, then I’ll see you in the next part.