The Bush Files: clients, servers and protocols
Posted by the markITeer on July 3, 2007
This post is part of a series of things ‘everybody-assumes-you-know-but-actually-you-don’t-have-a-clue’.
I call them : the Bush Files.
Today : clients, servers and protocols
If you want to understand how the Internet works, why it is you sometimes have to wait for a webpage to appear or why almost every web address starts with ‘http://’, you must learn about the most important thing that makes the web happen: the client-server model.
The first player in the client-server model is the client. A client can be any program that can access the Internet and wants to retrieve information from it. For instance a web browser, who wants to retrieve web pages, or an e-mail client who wants to retrieve email messages. But in order to get the information they want, somebody has to provide it to them. And that’s where our second player enters the stage: the server. A server is any program that can access the Internet and is able to provide information to the clients. There are servers specialized in delivering web pages, other servers know how to deliver email messages and so on.
You could compare this to going shopping: You, the client, want to get e.g. the latest Radiohead cd (rumoured to be released fall 2007!), and the store (aka the server) can give it to you.
There is however one thing still missing in this story: we assume that the client and server can understand each other! What if you would walk into a record store in China asking for your cd in Dutch? It is very important that the client and the server know how to communicate! That’s why different protocols were invented that define how a request and a response have to be created in order for the server to understand what the client is asking for, and for the client to understand the server’s answer.
For the exchange of web-based information (web pages, RSS feeds etc.), the http protocol is used, which stands for HyperText Transfer Protocol. For the exchange of files, FTP (File Transfer Protocol) can be used, and for the exchange of emails SMTP (Simple Mail Transfer Protocol) can be used. Makes sense, doesn’t it? And maybe you recognize this acronyms? If you enter a URL in your web browser, the first thing you have to enter is which protocol your browser should use to get the information you’re looking for e.g. http://markiteer.wordpress.com.
So, let’s recap using some day-to-day examples:
1. I want to view a web page:
First I type in the web address, let’s say https://markiteer.wordpress.com, into the address location bar of my web browser. My web browser, being a typical client, will then connect to the server where this website resides asking for the web page using the http protocol. The server knows this protocol and can deliver the web page back to the client. The client (your web browser) will then render it for me to view it.
2. I want to read an email:
I open my email reader (e.g. Outlook). Being a client, it will contact a mail server asking it for new email messages using the smtp protocol. The mail server understands what the client is asking for and can deliver the new messages. My Outlook will than render the email messages so I can view them.
3. I want to upload a file:
I open my FTP program (eg. CuteFTP, LeechFTP, …). This client will connect to a server I specify to which I want to upload my file. Using the FTP protocol, the client will send the file to the server. The server will understand this and send back a message that it successfully received the file.
That’s all there is to it. And once you’ve got the hang of this easy principle, the working of most Internet-based applications suddenly will become a lot clearer.