The Protocols

Index

Introduction

With TCP/IP alone (or UDP/IP) you can already send plain text data over the Net, but that's not enough for many tasks. If you want to send mails or download files, you need something like an extended command syntax that is standardized so servers understand the requests and clients understand the replies of the servers. Those additional protocols usually sit on top of TCP/IP, although they can sit on top of ever other protocol that is able to transfer text commands between two PCs.

The basic idea of those protocols are that human friendly commands (it could also be binary commands, but usually they are text commands that every human being can understand and identify their meaning) are sent to the server and the server replies with a number (that's useful for clients) and a human friendly answer (that defers from server to server).

E.g. you send "listgroup" to a NNTP server and the server replies with "240 List of groups follow", where 240 is the control number for clients and the rest is for human beings. Most of the protocols are enough human friendly, that you can use them, although you don't even have a client for that task. You only need a Telnet client that can connected to any port of a PC via Internet, sends whatever you type on your keyboard over this connection and displays every answer it receives from this connection on your screen. Of course a client for the protocol is easier to use ^_-

All those protocols also work via UDP, but the little speed gain is paid by additional transfer errors. You wouldn't appreciate it if your e-mails arrive with transfer errors, right? So unless you manually change the defaults, TCP will be used. Only NFS was designed to use UDP, but it can of course nowadays run over TCP. The standard port is the port number that your client will use unless you specified another port and it's the number you would have to enter in your Telnet client if you want to operate a server without another client.

() Back to Top ()

FTP

Name: File Transfer Protocol
Task: Managing files on another PC via Internet connection.
Standard port: 21
URLs: ftp://

If you connect to a FTP server, you must first perform a login, meaning you send your user name and password to that server. If you are not aware of any name, most servers allow anonymous login ('anonymous' as name and your e-mail address as password). Most FTP clients will automatically perform an anonymous login unless you entered a user name and password before connecting.

Once you are connected, you can obtain a list of all files and folder in the current directory of the server (what is usually not the main directory, it's a sub-directory that was created for FTP access). You can browse through that list and enter sub-directories just like on your local HD. FTP has also commands for creating new sub-directories, renaming files/folders, deleting files/folders, changing access rights of files you own and even copying or moving files to another directory on the server (it is copied directly without being first downloaded to your PC!).

But FTP can also transfer files. You can upload files to the server and download files to your local PC via FTP. FTP creates a second connection for transferring files, called "binary connection", while the connection that you client uses to send commands is called the "control connection". Using two connections has the advantage that you can still receive replies to commands over one connection while transferring files over the other one.

The reason why you must perform a login after connect is to determine your rights. Not every user is allowed to perform every disc operation on every server. E.g. as anonymous users you may only be allowed to access/enter certain directories, you won't have write permission to some directories and you won't be allowed to delete, rename, move or copy files in any directory. Other limits could be that only 5 anonymous users are allowed to connect at the same time (= maximum user limit), they are only allowed to stay connected for 30 minutes (=connection time limit), they have up-/download limits or they are only allowed to download if they uploaded files before, called a ratio (e.g. 1:3, meaning for every MB you upload, you are allowed to download 3 MB).

Other users may be allowed to access other directories and even perform actions like renaming files; e.g. on your webhost, you are allowed to perform every file operation you like as long as it happens within your own webpage directory or a sub-directory of it. This will only work if you login with your account name and password, as anonymous user you won't have those permissions. The administrator may have an account with full access rights, so he can manage his own FTP server at home from any PC in the whole world. When you disconnect from the server, the session is closed again. Owners of FTP servers can ban certain users or ISPs by not allowing sessions to their IP addresses.

A good FTP client for Windows is CuteFTP, it looks like your Windows Explorer and you can perform most commands like renaming by right-clicking a file or up-/download via drag'n drop. Your WEB browser can access FTP servers as well (try ftp://ftp.microsoft.com for example), but you have no control when it opens/close a session, what can be a problem with ratio servers (e.g. you upload stuff and your browser closes the connection, now when it connects again to download files, the FTP server will treat you like a new user), but for getting software via an anonymous account it's usually good enough.

FTP allows resuming, meaning you can start a download where you last time stopped. Therefor your client only needs to tell the server how far you already downloaded the file last time and then the received data is attached to the already existing file on your HD if you didn't delete it. Unfortunately some clients (e.g. many browsers) don't support that, real FTP clients always support it.

() Back to Top ()

HTTP

Name: Hyper Text Transfer Protocol
Task: Downloading files from an Internet server.
Standard port: 80
URLs: http://

As the task tells you, HTTP also can transfer files like FTP, the difference is that it doesn't support all the other file managing functions. HTTP mainly is for transferring files between two PCs, while most of the time it's used for downloading only (because the uploading ability of HTTP is very poor). It was developed for transferring Hyper Text files (HTML files) from a WWW server to your browser. HTML clients are named "WWW browsers".

HTTP uses quick sessions, that's why you usually don't have to perform a login (unless files are password protected). Every time you request a HTTP request is sent to the server and in case the file was found, you will get an reply, where the file data is immediately attached to the end of this reply (you don't have to initiate the transfer separately, you'll get your file with the server's reply). If it wasn't found, you only get an error message as reply.

After such a request/reply transfer the session is considered to be over. Unless you immediately request a second file, the connection will get closed. HTTP version 1.0 only supports to download one file per quick session, HTTP 1.1 allows you to download multiple files before the session is closed again (the server has an internal limit for that case). If your server doesn't support HTTP 1.1, your client needs to open a new quick session for every file transfer, that will waste some time and it makes HTTP rather slow compared to FTP. Most annoying is that when you access password protected files, HTTP must transfer the user name/password again for every quick session.

HTTP is a lot simpler than FTP, what means it's easy to implement for programmers and uses less system resources on PCs than FTP. HTTP is optimized for downloading files, but you can also upload files with it and delete files on the server, as well as transferring form data to a server (e.g. e-mail forms on webpages). You can not copy files to another directory on a server, rename files, change access rights of files or create new directories. Most browsers only support download of files and transmission of form data, only Netscape seems to make use of the other two functions (uploading files and deleting files on request).

Many webhosts allow you to also upload files via a webpage interface, but in this case the upload isn't done with the HTTP upload functions, the file data is transferred with the functions for transmitting form data and an application on the server will receive this data and store it to disc.

As far as I know, HTTP 1.0 doesn't support resuming (start broken downloads where the connection was lost), but HTTP 1.1 does support it. Most browsers usually won't allow you to resume HTTP downloads, Opera does. In any other case, use a download manager like GetRight (very good application for downloading files of HTTP *and* FTP servers).

The big advantage of HTTP compared to FTP is the ability to create data on the fly. Not every webpage you get from a server as reply to your request really exists on the server's HD. Sometimes the URL you entered doesn't point to a HTML file, but to an executable file. In that case the server will execute this file and whatever this application would print out to the screen is sent to you as reply. Those applications are written to print out HTML data on the screen so your browser can display the data well formatted.

An example are search engines:
Not every possible search result can be saved on those servers as single webpage. When you search for certain keywords the server will browse a database, filter out all entries that apply and the result is formatted as HTML page which is then sent to you as reply. With FTP you can only access data that is already present on the server's HD.

A little tip:
Some pages offer you both, HTTP and FTP links for downloading files. Many users take the HTTP link and I don't know why. Not only FTP is usually more reliable when downloading bigger files and faster when downloading multiple smaller files, but because the number of simultaneous users is limited, those servers are often not that overloaded and offer you a lot better overall transfer speed. Therefor you might not be able to connect at all if too many people are currently trying to download a file.

() Back to Top ()

SMTP

Name: Simple Mail Transfer Protocol
Task: Seding e-mails to a mailbox.
Standard port: 25
URLs: mailto:

SMTP servers are the postmen of the Internet. They will forward your mails to the mailbox of the recipient(s). Theoretically you could connect to every SMTP server on the Net because they can forward mails between each other, but usually only two servers will allow you to connect for sending a mail to john.doe@company.com, those are:

1. The SMTP server of your ISP, as it will identify you as customer and customers are always allowed to send mails.
    
2. The SMTP server of John Doe (=company.com), as although you aren't one of their customers, the person you entered as recipient is one of their customers and people trying to reach one of their customers are allowed to use the server as well.

All other servers will refuse to route your mail traffic and that's okay, after all they have nothing to do with the mail (neither recipient nor sender is one of their customers). As you would always need to use a different SMTP server depending on your recipient and as you could never send a mail to two recipient at once who are not customers of the same ISP, you will usually use method 1 for sending mails. Method 2 is only useful to find out immediately during sending, if a mailbox does really exist or not, because the company.com can tell you at once if John Doe has a mailbox with that name on this server or not, your local server can't.

Once you transmitted your full mail to your local server (SMTP server of your ISP), it will connect to the server of the recipient and forward your mail. In case the server now replies that this customer doesn't exist, your SMTP server will send you the error message of the other SMTP server via mail (to the address you have in your Reply-To line and if it doesn't exist to the one in your From line) and the mail in question is attached to this error-message (in case you haven't saved it and to know what mail it was).

Sometimes the other SMTP server may also tell your SMTP server that the mailbox is full (mailboxes have a space limit, they can't store infinite mail), in that case you might not get an error at once. Often your local SMTP server will retry to send the mail every 6 hours (e.g. up to 8 times = 2 days) in the hope the user might meanwhile have emptied his mailbox. Only after 24-48h it will give up and send an error-message to you.

SMTP knows three types of recipient:

• TO - Recipients: Those will get the mail at first (you can put there multiple e-mail addresses separated by comma).
   
• CC - Recipients: Carbon Copy recipient receive the mail later on as copy (you can also put multiple recipients here)
   
• BCC - Recipients: Blind Carbon Copy recipients will also receive a copy, but they won't be shown as recipients, meaning neither TO-, nor CC-Recipients know about those BCC-recipients, they don't show up in the header. You can place multiple e-mail addresses in this line as well, but even the other BCC- recipients will not see any address except their own one there.

Every current e-mail client uses SMTP to send e-mails, no real alternative is planned for the future. The protocol is really simple, but it offers you anything you need to send e-mails on the Internet. An extension to it would allow users to identify with username and password, e.g. to send e-mails via the SMTP server of your ISP although you currently use another ISP for dial-up and thus don't have the correct IP address to access it without identification. But only very few servers support this extension and in most cases it's not necessary as you saw above, after all you could you the SMTP server of your recipient if you have no other that you could use instead.

() Back to Top ()

POP3

Name: Post Office Protocol version 3
Task: Fetching mail from your mailbox.
Standard port: 110
URLs: n/a

Your mail is in your mailbox, but how do you get it out again? No problem thanks to POP3. Before POP3 allows you to access a mailbox, you need to send a user name (to find out which mailbox you try to access) and a password (to assure that you really are the person you claim to be). POP3 is a simple protocol, you could call it the HTTP protocol for e-mails.

POP3 can't provide your client with many information, it can tell you how many mails are in your box and how much space every mail uses. Additionally the server can tell you the sender of those mails and their subject-lines, but that's not mandatory, only some servers will do that. The only two important commands are for reprieving mails (the mail will be sent to the client) and deleting mails (it will be removed off the mailbox).

Most POP3 clients will make transactions like that: Identification with user name and password, listing the available mails, downloading all available mails, deleting all available mails. You can choose to not delete them (they will stay in your mailbox), but if you choose that option, the mail will be downloaded every time you check your mailbox again, since most clients can't decide if a mail is new in the box or had already be downloaded.

Every decent mail client supports POP3, every decent mail server supports it as well. Most of the time POP3 will be the protocol of your choice for fetching your mails.

() Back to Top ()

IMAP4

Name: Internet Message Access Protocol version 4
Task: Accessing e-mails directly on the server.
Standard port: 143
URL: n/a

While POP3 is a bit like HTTP, IMAP4 is more like FTP. It's more powerful than POP3 as it allows you to:

• create folders directly on the server and manage them.
   
• getting all important header information of a mail (sender, subject, size, data, etc.) without downloading the whole mail.
   
• managing mails like local files on your HD, e.g. move them per drag'n drop between your server directories or downloading them into a local directory.
   
• apply filter functions directly on the server, mails must be downloaded only for reading.
   
• saving disc space on your HD by leaving mails on the server, until you delete them.

Where are the disadvantages of IMAP4?

• Not all clients support it, neither do all servers.
   
• It's more complicated to use, many options you must consider, like how much folders on the server, how much local ones, when to store on server, when to store locally, etc.
   
• If you don't store mails locally after your first download, they must travel over the Net again in the future for every time you view them. This is a security problem, since POP3 mails will only travel once over the Net, giving attackers less chances to sniff it. It's also a bandwidth problem for very big mails.

The question is: You can choose between POP3 and IMAP4, which one shall you use?

If the mail client is somewhere outside on the Net, meaning it's slow (bandwidth and server resources are limit and hundreds of users must share them), the mails pass various servers on the way to you (many unauthorized people might be able to read it) and your server space for mails is very limited (10 MB or less) ===> Take POP3. Explanation: You need to transfer mails only once, since once you have them on your local HD, speed is no problem anymore. It also passes all those servers only once, giving attackers smaller chances to catch it. And last but not least, your mailbox will regularly be cleared to make space for new mails.

If the server is in your local network (e.g. a local mail server of your company, university, home network, etc.) ===> Take IMAP4. Explanation: You don't have to deal with space issues (some have up to 100 MB mail space), mails must only travel over local PCs and there are hopefully not as many attackers in your local network as on the Internet, and in a local 10 MBit/s network (or faster), neither bandwidth is really no problem, nor will you have that many people in your local network that you must be afraid the server will suffer by too heavy load.

() Back to Top ()

NNTP

Name: Network News Transfer Protocol
Task: Accessing Usenet servers.
Standard port: 119
URLs: news:

To learn more about Usenet, take a look at my page about it. A Usenet server stores public messages for you, with NNTP you can download a list of available messages inside a Newsgroup, header data about those messages or the messages themselves. You can also send new message to a Newsgroup.

While you need to protocols for mails, sending (SMTP) and receiving (POP3/IMAP4), NNTP will do both for you. The protocol is simple and limited, but most servers support extensions to it (adding additional commands to the basic ones) making it quite powerful. All Usenet servers support NNTP and every Usenet client will use it as standard protocol. Without extensions it's as simple as POP3, with extensions it's as powerful as IMAP4, but it never knows local directories, you always must download all stuff to your local HD.

Sending new posts (Usenet message) is done with a single command (even simpler than sending mails) and all important data is inside the header of the post. There's not more left to say about this protocol, but if you want to learn more about it (and about the meaning of the available header lines), take a look at my Usenet page. In many ways it's similar to the headers of e-mails, e.g. it also has CC and BCC in case you want send copies of your public posts to some people via e-mail (see SMTP protocol) and it also uses a from line and reply-to line to identify the sender and his/her e-mail address.

() Back to Top ()

Telnet

Name: Telnet
Task: Console access via a network.
Standard port: 27
URL: telnet://

Actually Telnet is not what I would call a protocol, but it often gets mentioned as protocol. It's rather a service than a protocol. Once you connected to another PC, everything you enter gets sent to this PC and is treated as if you had entered it through the local keyboard of this PC. Just like everything that the PC would print out on the screen is sent to you. IOW you can start applications on a Telnet server and operate them from your home PC.

Unfortunately that only works with text applications. As replacement to Telnet, people often use SSH (see below), since all transfer are encrypted automatically. Together with SSH's port forwarding and the XServer protocol (which all Unix/Linux OSes support, but there are also XServers for Windows) you can also run graphical applications on a server in a similar way like Telnet.

() Back to Top ()

IRC

Name: Internet Relay Chat
Task: Realtime chat over the Internet.
Standard port: Usually 6667, but also 6665-6670 and 7000
URL: irc://

IRC is a simple protocol that allows you to create chat channels or join already existing channels and then take part in realtime discussions inside those channels. Therefor it supports certain commands to the server to perform certain tasks, just like any other protocol as well. Chat channels are virtual rooms that have a specific name and a specific topic (the topic can be changed every time).

The person who creates such a room becomes operator of the room. S/he can kick out unwanted users or even ban whole ISPs, change the topic of the room or assign operator status to another user. If the operator leaves a room without assigning operator status to a new user, the server will simply select a new operator. If everyone leaves a room, the room stops existing.

Unlike Usenet, there's not one IRC net, there are several ones and every one always consists of several servers. To be able to talk with your friends, you must all access an IRC server that is in the same network that they are using, but it doesn't need to be the same server. Within one network, servers exchange messages, but messages are NOT exchanged between the individual networks. Every network has own ideas about how to handle problems and most networks are resulting of one network where people couldn't agree upon a single solution (so they split the net into two sub-nets).

Some IRC networks have nick server and channel server. Nick server are used to register your nick name (so other people can't use it even when you are not online) and channel servers can be used to register a channel (so it keeps existing even if nobody uses it and as you are registered as owner, you'll always get operator status if you join your own channel). The names and channels will stay registered for a few weeks and if nobody uses them within that time, they are erased again.

IRC knows a system named DCC (Direct Contact Chat), where your chat messages travel directly between you and another person without passing the network, nobody can read them as they'll never show up within a chat channel. DCC is also good to talk to people during netsplits. A netsplit happens if one IRC server must go off-line and the net is temporarily split into two subnets. When that happens, messages you are sending only show up at servers that are part of your subnet. DCC will of course still work, it's a private chat-room of two people and unlike ICQ, it's NOT server dependend (it will even work if the whole IRC net breaks down).

Another very interesting feature is that people while they are connected to the IRC network can transfer files between each other. The file transfer is done via DCC, meaning your file won't travel through the whole network, it'll be sent directly to the recipient. In the meantime you can chat with the recipient using DCC or chat on a chat channel of your choice. You can make a DCC connection to everyone connected to the IRC network, even if this person hasn't joined any channel so far. At the moment where you are connected, you are in the "root" channel and people can always check if you are online.

You see, IRC can do everything that ICQ can do for you, with the difference that it is a lot older than ICQ, using an established protocol and isn't owned by a single company. Once you found out that you can automate process in IRC using "bots", you will discover the real power of this data exchange method. A good IRC client for Windows is mIRC, it's very easy to use (you can do everything via menus, instead of typing commands) and offers you lot's of additional functions that other clients won't offer you.

() Back to Top ()

NFS

Name: Network File System
Task: Accessing harddisks on an Internet as if they were local harddisks.
Standard port: 2049
URL: n/a

Early versions of it only used the UDP protocol, which means the error correction was done by NFS itself, today TCP is used for it as well. NFS is similar to FTP, but it's even more powerful than FTP. You can access a HD on any PC on the Net just like your local HD, including all features that the file system allows. It's often used within a company to access server drives from clients as if those were local ones.

In case of Unix system you can mount the remote HD into your directory tree, in case of Windows, you can make the remote drive look like a local one (e.g. R:). The possibilities are endless and if you have to manage a remote drive on some server, there is no easier way of doing it.

The main problem of NFS is security! Without a good (and fast!) encryption, everyone can read every file you send over the Net. That's not different with FTP (or any other protocol), but while many people don't send important files via FTP, they treat NFS drives like local drives and forget that their data is sent unprotected over a huge network. NFS itself supports a secure authorization (not every user should be able to access your remote drive), but it doesn't support any encryption methods. To make NFS secure, you'll need an extra protocol just like for all the other protocols mentioned on this page.

() Back to Top ()

SSL

Name: Security Socket Layer
Task: Making standard protocols secure.
Standard port: n/a
URL: n/a

SSL is a protocol for accessing any service that usually is accessed by another protocol (e.g. FTP, HTTP, POP3, NNTP, NFS, etc.), but over a secure connection. Let me tell you how SSL works:

1. The client connects to the server and requests a SSL connection for a specific service.
    
2. The server sends a public RSA key to the client that the client can use to
    
   • identify the server by checking if this key has a valid certificate and by comparing the key with a globally stored copy on a key server (in case such a server exists).
      
   • to send encrypted blocks to the server, since whatever is encrypted by a public RSA key (minimum 512 Bit, the more the better; often 2048 Bit and above), only the private RSA key can decrypt it again, and the server never gives its private key away, so only itself can decrypt the blocks.
      
3. If the client trusts the server because the certificate is valid and/or the key was found on a global key server, it creates a "session key" (128 Bit), that's a very large random number used for encryption of the session. This session key is then encrypted with the public RSA key of the server (so only the server can read it) and sent to the server.
    
4. The server decrypts this session key with its private RSA key and from now on, all blocks send to the client are encrypted with the session key and the other way round.

Question that people usually ask are:

• Why is a session key created, why not using the RSA key?
  
  First you should consider that, with the RSA key I can send blocks securely to the server, but how can the server securely reply to me? As we both know the session key (and as we are the ONLY parties who know it, since I transferred it encrypted), it can be used for encryption/decryption into both directions.
  And second, RSA encryption is VERY slow because it uses very large keys. The session key is no RSA key, it is used with a encryption method like IDEA, Triple-DES, RC4 or similar, a semmetric encryption method (the key for encryption and decryption is the same, unlike RSA where there is one key for encryption (public one) and one for decryption (private one)). After all the encryption shall not dramatically slow down the connection or eat up too much CPU resources.
   
  
• Why is the session key so small? Only 128 Bit, isn't this less secure than the long RSA key?
  
  No, it isn't! Symmetric encryption (one key systems) needs a lot smaller keys than asymmetric one (public/private key systems). A 128 Bit symmetric key (used with a encryption method like IDEA) is a lot stronger than a 2048 Bit RSA key! Because of US export restriction, some countries were forced to only use a 40 Bit session keys and those are still a lot more secure than a tiny 512 Bit RSA key. Meanwhile all countries can use 128 Bit session keys and all companies use at least 1024 Bit RSA, most of them 2048 Bit.
   
• Which symmetric encryption method is used, as you mentioned several ones?
  
  The server tells the client which algorithms it supports (RC4, IDEA, Blowfish, Twofish, DES, Triple-DES, Cast or other) and the client will choose the one it likes most. Not every server supports every encryption method, just not every client supports every one of them, but since they all at least support IDEA and Triple-DES, those two can always be used if the others are not supported. For the future, new methods that support longer keys (256 Bit) are planned, for even higher security.

The usage of SSL isn't limited. Many people know it from their browser when ordering online via credit card (a small lock or a key is displayed in the status bar when opening such a side). Since it's here important that your data is transferred secure, the pages uses HTTP over SSL, also known as SHTTP. Some servers allow you enter "shttp://" into your browser to make a secure connection right from the start, even when transferring no important data. Before you send data over the Internet like your credit card number or bank account, always make sure that you are on a secure page that uses SHTTP for transport. In any other case, you should never enter such data into a form on a webpage as everyone can read this data when being sent unprotected.

Sure, the chances that an attacker will watch your connection exactly in that second is very small, but it's not impossible and some people already had to recognize this as they one day found out that their bank account was suddenly empty! So be careful.

Some e-mail clients use SSL as well to give you secure access to your POP3/IMAP4 mailbox (meaning you password isn't transferred unencrypted, neither are your mails) and some Usenet clients allow you to read news via SSL, also to protect your password and to avoid anyone can read what you are downloading from the Usenet. It especially makes sense to use SSL for NFS, as it's quite easy to make NFS a secure protocol with SSL.

IF you haven't already recognized it on your own, SSL always needs another protocol sitting on top like HTTP, NFS, NNTP or POP3. That's because the only task of SSL is making a secure connection, once the data is transferred securely to the server, it is decrypted passed to the normal server applications that will handle this data as usual. The session key only is valid for one session, if you open a new one, a new key is created. Further the session key will be replaced after some time (usually after one hour) or after a certain transfer volume (usually after one GB).

Cracking a 128 Bit session key or a 2048 Bit RSA is possible, but would take several years and an equipment, that the standard Internet hacker certainly can't afford. SSL is still no official standardized protocol, but I'm sure it's on the best way to become one, it has already been proposed to the IETF (Internet Engineering Task Force).

() Back to Top ()

SSH

Name: Secure Shell Host
Task: Secure connections between two PCs.
Standard port: 22
URL: n/a

SSH is basically working like SSL, but it's not really the same. The authentication and the encryption works like described for SSL. Unlike SSL that sits between a standard protocol and the server applications (it's an additionally "layer" between those two), SSH is an own service that is most often used to replace Telnet.

Even though SSH doesn't need any additional protocol sitting on top (in case you use it like Telnet), it still can be used together with other protocols. It supports something called "port forwarding", which means you can send (e.g.) FTP data to a server using SSH and the SSH server application will then forward the data to the FTP server application locally (that's secure as it happens within the server), while the reply of the server will be forwarded to you via SSH again.

That way you can access a FTP server securely thanks to SSH. While a server must support SSL for every service it offers (HTTP, FTP, News, E-mail, etc.) if you want to access all of them securely, it's enough if it supports SSH connections in general and thanks to port forwarding you can use all services securely via your SSH connection.

But while it might be easier for providers to install SSH instead of SSL (they just setup a SSH server, the HTTP/FTP/Mail server application doesn't have to be updated or replaced with a new one, like in case of SSL), it's more difficulty for users who now are forced to install a SSH client on their system. In case of SSL most browsers and mail clients already support SSL (even some news clients) and thus SSL is easier to use for customers.

Nevertheless, there's something you can do with SSH that can't be done with SSL: running remote graphic applications on a server. This works via the XServer protocol (part of every Unix/Linux system, also available for Windows) and the port forwarding ability of SSH.

Other Protocols

There are plenty of other protocols (for accessing databases, for transferring files, etc.) , and it would take endless to explain them all, so I limited myself to the most important ones. Those are protocols that you should know and that will be very useful for your in your daily Internet life. A PC should have at least one client for everyone of those protocols installed and most operating systems already ship with a majority of clients for the protocols mentioned above. Maybe one day some of the protocols will be replaced by new ones, but most of then had been used for several years now and even if their possibilities are limited once a while; for what they were created they are simply the best ones we have!

() Back to Top ()

If your browser doesn't support frames, click here to return to project index.

If you miss the navigation frame to your left, click here to get it back.

Last edited 31.03.2001 by TGOS