CCNA – 4 – Applications




Describe common networked applications including web applications

Every time you turn on a computer, you are presented with applications. These applications run on your local machine (mostly). They use the protocols, and transport mechanisms we discuss at CCNA level to interact with servers, or other applications across the network, or Internet. Facebook gets referred to as an application, but from our point of view it’s not.

An application is a process that runs on the local machine. In a lot of cases the Application, and the protocol that the application uses to access it’s information are so closely tied, that they get confused.

So an application is a process that runs on our computer, and we are interested in the ones that talk over the network? What’s the most obvious of these? A Web browser. You are probably using one to read this. FireFox, Chrome, IE, Safari, they all allow you to type (or click) a URL and have a web page displayed in front of you. How this web page gets to you is a long, convoluted process that moves right the way down and up the TCP/IP model, probably multiple times, with multiple computers involved. So, where do we start. Well, how about with that URL?

This is the very first introduction to this series that I wrote way back in March. Let’s break it down. Starting at the beginning, we have “HTTP” This stands for Hyper Text Transport Protocol. The Protocol the World Wide Web is built upon. HTTP defines a set of commands to enable a client to request documents from a server.

“” is ideally the machine name that we want to access the file from.

The rest is the path to the file.

So what does our web browser do with that? Well, first it need to know how to contact the server to get the file from, so it need to find the IP address of, for this it uses the DNS protocol. With the IP address in hand, the machine sends a HTTP get request to the server for the file path. The server responds, hopefully with the file, and the Browser reads the file. Usually the file will point to other files, on the same or different servers, images, fonts etc etc. These are also requested in the same fashion, until the page is loaded.

So, how can this vary? Well, obviously the computer name, and file path will vary on a case by case basis. But also the HTTP can become HTTPs, where the s implies the use of SSL (Secure Socket Layer) to encrypt the requests between the computer and the server. This is done to ensure no snooping on the network.

Many browsers also support ftp:// which stands for File Transport Protocol. There are standalone FTP applications, such as FileZilla, which specialise in using ftp to transfer files to you local machine, but it is such a useful thing to o for larger files, that many browsers include the ability too.

Other common applications are NTP Clients, used to set the time on the local computer, and DHCP Clients, used to set up the computer’s initial IP address and other settings.

What is important to note is that these applications are simply using the protocols defined in the TCP/IP model and in RFCs to achieve some aim. The applications do not define the protocols, and are not restricted to just one protocol.



    • Mick on May 17, 2012 at 1:54 am

    This has nothing to do with this post, rather an older one that I can’t comment on because it’s too old I’m guessing.

    Just though I’d pass on my appreciation for the “Rebuilding your Service Console network” article/guide. I’ve used this about a half a dozen times over the course of 2+ years now and it’s always fixed the particular problem I had in regards to config concerns. So thanks is somewhat overdue.


  1. Ahhh Mick, now you’ve got me all excited and then disapointed!

    It’s true though, that *was* a good post.


Comments have been disabled.

%d bloggers like this: