Chapter 4
Client/Server Applications

File: Steve/Courses/2014/s2/its332/apps.tex, r3468

4.1 Clients, Servers and Addressing

Most network applications, including web browsing, email and file downloads, are implemented as client/server applications. For example, web browsing involves a web browser (client) retrieving web pages from a web server. The client/server model involves the server listening for new connections and the client initiating new connections. (A connection is usually needed each time we perform some operation, e.g. transfer a file, download a web page, send an email). We use IP addresses, as well as ports, to uniquely identify each connection.

4.1.1 Addresses and Ports

We know that IP addresses are used to identify computers on the Internet. This includes clients and servers. When sending data between a client and server, the source and destination IP addresses are carried in the IP datagram (see Figure F.1). These two addresses (source and destination) uniquely identify the connection between these two computers.

But what about different application programs (or processes) running on the computers? If you have one web browser connecting to a web server at www.google.com and a second web browser connected also to www.google.com, then how does your computer know which IP datagrams are destined for which instance of the web browser?

Client/server applications also use port numbers to identify connections between applications. Your first web browser instance uses a different port number than your second web browser instance. So in fact all communications between client/server applications can be uniquely identified by both the source/destination IP addresses and the source/destination port numbers:

For example, connection 1 between browser 1 and web server www.google.com:

Source IP
203.131.209.77
Destination IP
66.249.89.99
Source Port
47984
Destination Port
80

And connection 2 between browser 2 and www.google.com:

Source IP
203.131.209.77
Destination IP
66.249.89.99
Source Port
48032
Destination Port
80

Note that the two connections between the same computers are uniquely identified, because the source ports are different.

While the source and destination IP addresses are carried in an IP datagram header, the source and destination ports are carried in the TCP (or UDP) packet header (see Figures F.2 and F.3). Therefore every packet we send over the Internet has these four addresses. (A fifth identifier, the protocol number is also included in the IP datagram. For example, if TCP is the transport protocol being used, the protocol number field in the IP header has the value 6, representing TCP. For a list of common protocol numbers see Appendix F.2.)

4.1.2 Servers

The common structure of most network server applications is as follows:

  1. The server is idle, listening (or waiting) for connection from clients on a well known port.
  2. When a server receives and accepts a connection request (e.g. TCP SYN), it creates a child process to communicate with the client. The child process exchanges data with the client. When the exchange is finished, the child process is deleted, leaving only the original parent server process.
  3. The server returns to the idle state (step 1).

In this way, a server can typically handle many connections at a time. For example, the www.google.com web server can handle connections from 1000’s of client hosts at a time. An important aspect is a well known port. Since the client initiates the connection, it has to know what is the destination IP address and port number. The client can find the servers IP address through DNS (e.g. www.google.com maps to 66.249.89.99). It knows the port number because most common servers use a well known port number. Some commonly used well known port numbers are listed in Appendix F.2.

4.1.3 Clients

The common structure of most network client applications is as follows:

  1. Send a connection request to a server. The client (in fact, the operating system) chooses an unused port number as the source port, and sends the connection request to the server.
  2. Once connected with the server, the client and server exchange data.

So multiple instances (or processes) of one application can communicate at the same time—they just use different source port numbers.

4.2 Web Browsing

Everyone knows how to use a web browser. But what about a web server? In this lab you will gain basic experience in using Apache Web Server. Apache is free (www.apache.org) and is the most commonly used web server in the Internet.

4.2.1 Server Configuration Files

Apache (and many other Linux servers) are configured via one or more text files. You set the options in the files, and then restart the server, and then the server will run with those options.

The main configuration directory for Apache is:

/etc/apache2/

The main configuration file for Apache is:

/etc/apache2/apache2.conf

You can edit these file if you use sudo and your favourite text editor.

$ cd /etc/apache2 
$ sudo nano apache2.conf

Other important configuration files are in the directories:

/etc/apache2/conf.d/ 
/etc/apache2/sites-available/

In this course we do not try to explain all the details of the apache2.conf file. The default settings are suitable for a basic web server.

An important file specific to the web site is:

/etc/apache2/sites-available/default

This file contains configuration options specific to a site. (You can potentially host multiple sites on the one Apache server). If you look at the contents of the file, you will see towards the bottom it “includes” another file:

/etc/apache2/sites-available/student.conf

This is not normally included in default Apache installs. It has been included for this lab class. If you need to make changes to Apache configuration during the class, it is recommended to do so in student.conf.

The web server documents (e.g. the HTML pages that are available via the server) are stored in a base directory:

/var/www/

By default there is a file called index.html (although it may have been changed/removed my other students).

You can browse to the URL: http://localhost/ to view the web page and test that your server is working.

You can create any files/directories in the /var/www directory which will then be accessible by the web server. (Remember you need to use sudo to write to the /var/www directory).

4.2.2 Controlling the Web Server

You can use the apache2ctl command to start, stop and restart Apache. You must restart Apache if you want any changes in the configuration files to take effect. The commands are:

$ sudo apache2ctl restart 
$ sudo apache2ctl stop 
$ sudo apache2ctl start

If you have made a change to /etc/apache2/apache2.conf, you should restart the web server for that change to take effect.

4.2.3 Creating Web Pages

Basic web pages are written in HTML. In this course we do not explain the format of HTML (maybe you have covered it previously) but you should be able to create a basic web page in HTML using any text editor. With Apache, the web pages are stored in /var/www, and by default, if you browse to a directory (e.g. http://localhost/) then Apache will display the index.html file (if it exists).

You should create a simple HTML test page under the directory /var/www/its332/ called index.html. An example page is:

<html> 
<head> 
<title>Test Page for ITS 332</title> 
</head> 
<body> 
<h1>Test Page for ITS 332</h1> 
<p> 
This is a test page for ITS 332. 
</p> 
</body> 
</html>

4.2.4 Server Logs

Another important file is the log produced by Apache. Apache logs (records) all requests for content on this server. The log is a text file:

/var/log/apache2/access.log

The format of this log file is a space separated file with each line showing details of a single request for a web page on the server. Each line has the following fields:

You should not edit the access.log file. Instead use less or tail to display its contents. less will display the file, page by page:

$ less access.log

The command tail will display the last 10 lines of the file:

$ tail access.log

4.2.5 Basic Authentication

It is common to protect some content on a web server using passwords. There are different methods of achieving this—here we will illustrate a simple (yet not too secure) method.

First you must create a username/password that Apache will use. Apache stores this information in a file. In this lab the file is:

/etc/apache2/passwords

The format of the file is a single line for each user, with the username and hashed value of the password separated by a colon (:). Note that the actual password is not stored: instead a somewhat secure representation of the password is stored.

To add a new user (with username steve) to the passwords file, use the command htpasswd:

$ sudo htpasswd /etc/apache2/passwords steve

You will be prompted for a password for the user steve. Enter it, and then the information will be saved in the passwords file.

If the passwords file does not already exist on your computer, you must use the -c option to force it to be created.

Now you must configure Apache to use a password on a specific directory. This can be achieved by editing the file /etc/apache2/sites-available/student.conf. You need to add commands that inform Apache that access to a particular directory requires a username/password. An example of the code is:

<Directory "/var/www/its332/protected"> 
      AuthType Basic 
      AuthName "RestrictedAccesstoITS332Files" 
      AuthUserFile /etc/apache2/passwords 
      Require user steve 
</Directory>

The above example says only the user with username steve (and corresponding password stored in /etc/apache2/passwords) is allowed to access content in the directory /var/www/its332/protected.

To test that the above configuration works, you should create a file in the directory /var/www/its332/protected. Then restart the web server for the changes to take effect.

4.3 Remote Login

Secure shell (ssh) is a protocol for securely logging in to another computer. It is a replacement for telnet (which was insecure). OpenSSH is a free implementation of a SSH client and server. Both client and server should be installed on the Ubuntu computers.

Secure shell can be run from the command line using:

$ ssh DESTINATION

where DESTINATION is the IP address or domain name of the computer you want to connect to.

Optionally, you can include the USERNAME to log in as (otherwise it will default to the current username in use on the client):

$ ssh DESTINATION -l USERNAME

You will be prompted for the password of that user on the server. (The first time you log in you may also be prompted about unknown authentication—enter Yes to continue).

Once you have logged in, you can run commands on the server. That is, it is the same as if you are using the command line on the server.

You can log out using the exit command.

4.4 Tasks

In the following tasks you should record notes of the main changes made. When performing tests you should capture packets using Wireshark, recording the packet exchange with a message sequence diagram (see Section 1.3.2) as well as important packets captured (see Section 1.3.3).

Task 4.1. Create several example files for your Apache web server to serve. Configure your web server, and then ask a friend to test your web server by accessing the files. Capture the packets and observe the log file.

Task 4.2. Configure authentication for a specific directory on your web server. Test, capture packets and observe the log file.

Task 4.3. Login to another computer in the lab, capture and investigate the data exchanged.