Application Layer
The top layer of TCP/IP is the Application Layer. This includes all processes that use
Transport Layer protocols to deliver data to the Internet Layer. There are many application
protocols and new protocols are frequently added. The most widely known and implemented
Application Layer protocols are:
Most of the application level protocols in TCP/IP are implemented as 7-bit ASCII stream conversations. This means that the communication that takes place across the network is formatted using upper and lower case alphabetic characters, numeric digits, and standard punctuation. This was partly done because, historically, as a packet of information passed across the Internet there was no predicting what type of system it would pass through. 7-bit ASCII was chosen as a coding scheme that almost any computer or piece of equipment would be able to handle. Any information that is not actually 7-bit ASCII is first converted to ASCII, then transmitted across the network, and converted back to its original form at the destination. To really understand the rest of the reasons behind why application protocols are simple text converstations it is important to understand a little of the history of TCP/IP, the Internet, and UNIX. The Internet and TCP/IP originally grew up on networks of UNIX computer systems. On a classic UNIX system there was one central computer system with a number of "Dumb", text display terminals connected to it. A user on one of the terminals typed in text commands to run programs, which displayed text as output. One of the first real network applications allowed a user on one UNIX computer to communicate across a connection to a remote UNIX computer and run programs as if directly connected to the remote system. This type of connection used Network Terminal Protocol, which is now commonly called Telnet. The local system that the user is connected to is called the client, and the remote computer is called the server. This was one of the original Client-Server applications. When a user wanted to communicate from their computer to a remote system, they would Telnet to the remote and run a program on the remote system. For example, if they wanted to send mail to someone on a remote computer, they could Telnet to the remote system, run the mail receiving program, and type in a message to a particular user. If they wanted to send a file from computer to computer, they would Telnet to the remote system, start a Receive program running, then drop back to the local computer and start a Send program to transmit the file. Eventually there were certain programs that were left running all the time on the server computers, E-Mail, File Transfer, and other common applications, so that a remote user did not have to log onto the remote system and start them each time they wanted to use them. These programs were left running in the background, using only a small amount of resources, while they waited to be contacted. These are what is known in the UNIX world as Daemons, and in the Windows world as Services. Just so that people could find the correct Daemon to talk to, each common or well known program was given a specific Port on the computer that it listened to while it was waiting for someone to contact it. Programmers, being the basically lazy people they are, grew tired of all the Telnetting from system to system. They began writing programs to do the Telnetting about for them. These programs at first were barely more than a modified Telnet program that followed a script to talk to a remote server. But these client applications grew in complexity and sophistication, becoming much more popular than the manual method of Telnetting around and typing in long text messages. Eventually there were mostly computers talking to computers, but the conversations were still the original text messages developed when it was people doing the conversing. Now, the above description is not exactly the order of events, or exactly the way it all happened, but it does give a rough idea of how the application protocols ended up the way they are. The important thing to remember is that most application protocols are text conversations that can be manually operated using a Telnet client program. The text conversation aspect of application level protocols comes in very handy when setting up, testing, and troubleshoooting TCP/IP applications. It is usually possible, and often quite easy, to use a simple Telnet client to contact a remote TCP/IP application and send it commands and test data. For example, if you are having trouble sending an E-Mail message to a particular person, it is quite easy to Telnet directly to the recipients mail server and manually compose a message for delivery. Then the responses of the remote system to each step of the procedure can be observed. This usually makes it much easier to identify where and how a problem is occuring. One downside of the text conversation aspect of TCP/IP application level protocols is that it is fairly easy to eavesdrop on a conversation or to write a program to generate the correct text messages so that one program can impersonate another. There have been many solutions developed to address this problem. Pretty Good Privacy (PGP) is a publicly available application that encrypts text messages before they are passed across unsecure channels, then unencrypts them at the destination. Secure Hyper Text Transfer Protocol (SHTTP) and the Secure Sockets Layer (SSL) are designed to verify the identities of computer systems at both ends of a World Wide Web conversation and to encrypt information in transit between them. These are just a few of a broad range of available applications that address the security issues. Secure communications across TCP/IP is a broad topic and is beyond the scope of this technical reference. Usually it is best to approach it on an application by application basis, or as an individual solution such as a Firewall system. |