Chapter 26

Standard
Client-Server
Protocols

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
 Chapter 26: Outline

26.1 WORLD-WIDE WEB AND HTTP

26.2 FTP

26.3 ELECTRONIC MAIL

26.4 TELNET

26.5 SECURE SHELL (SSH)

26.6 DOMAIN NAME SYSTEM (DNS)

 26-1 WORLD WIDE WEB AND HTTP

In this section, we first introduce

the World Wide Web (abbreviated
WWW or Web). We then discuss
the Hyper-Text Transfer Protocol
(HTTP), the most common client-
server application program used
in relation to the Web.

26.3
 26.26.1 World Wide Web

The idea of the Web was first proposed by Tim

Berners-Lee in 1989 at CERN, the European
Organization for Nuclear Research, to allow several
researchers at different locations throughout
Europe to access each others’ researches. The
commercial Web started in the early 1990s.

26.4
Example 26.1
Assume we need to retrieve a scientific document that
contains one reference to another text file and one reference
to a large image. Figure 26.1 shows the situation.

The main document and the image are stored in two

separate files in the same site (file A and file B); the
referenced text file is stored in another site (file C). Since
we are dealing with three different files, we need three
transactions if we want to see the whole document.

26.5
 Figure 26.1: Example 26.1

26.6
 Figure 26.2: Browser

26.7
Example 26.2
The URL http://www.mhhe.com/compsci/forouzan/
defines the web page related to one of the of the computer in
the McGraw-Hill company (the three letters www are part of
the host name and are added to the commercial host). The
path is compsci/forouzan/, which defines Forouzan’s web
page under the directory compsci (computer science).

26.8
 26.26.2 HyperText Transfer Protocol

The HyperText Transfer Protocol (HTTP) is used to

define how the client-server programs can be written
to retrieve web pages from the Web. An HTTP client
sends a request; an HTTP server returns a response.
The server uses the port number 80; the client uses a
temporary port number. HTTP uses the services of
TCP, which, as discussed before, is a connection-
oriented and reliable protocol.
Non-Persistent Connection: It requires connection
setup again and again for each object to send.
Persistent connection: It does not require connection
26.9 setup again and again.
Example 26.3
Figure 26.3 shows an example of a nonpersistent
connection. The client needs to access a file that contains
one link to an image. The text file and image are located on
the same server. Here we need two connections. For each
connection, TCP requires at least three handshake messages
to establish the connection, but the request can be sent with
the third one. After the connection is established, the object
can be transferred. After receiving an object, another three
handshake messages are needed to terminate the connection,
as we will see in Chapter 23.

26.10
 Figure 26.3: Example 26.3

26.11
Example 26.4
Figure 26.4 shows the same scenario as in Example 26.3,
but using a persistent connection. Only one connection
establishment and connection termination is used, but the
request for the image is sent separately.

26.12
 Figure 26.4: Example 26.4

26.13
 Figure 26.5: Formats of the request and response
messages

26.14
 Table 26.1: Methods

26.15
 Table 26.2: Request Header Names

26.16
 Table 26.3: Response Header Names

26.17
Example 2656
This example retrieves a document (see Figure 26.6). We
use the GET method to retrieve an image with the path
/usr/bin/image26. The request line shows the method
(GET), the URL, and the HTTP version (26.1). The header
has two lines that show that the client can accept images in
the GIF or JPEG format. The request does not have a body.
The response message contains the status line and four lines
of header. The header lines define the date, server, content
encoding (MIME version, which will be described in
electronic mail), and length of the document. The body of
the document follows the header..

26.18
 Figure 26.6: Example 26.5

26.19
Example 26.6
In this example, the client wants to send a web page to be
posted on the server. We use the PUT method. The request
line shows the method (PUT), URL, and HTTP version
(26.1). There are four lines of headers. The request body
contains the web page to be posted. The response message
contains the status line and four lines of headers. The
created document, which is a CGI document, is included as
the body (see Figure 26.7).

26.20
 Figure 26.7: Example 26.6

26.21
Example 26.8
Figure 26.8 shows a scenario in which an electronic store
can benefit from the use of cookies. Assume a shopper
wants to buy a toy from an electronic store named BestToys.
The shopper browser (client) sends a request to the
BestToys server. The server creates an empty shopping cart
(a list) for the client and assigns an ID to the cart (for
example, 12343). The server then sends a response message,
which contains the images of all toys available, with a link
under each toy that selects the toy if it is being clicked. This
response message also includes the Set-Cookie header line
whose value is 12343. The client displays the images and
stores the cookie value in a file named BestToys.

26.23
 Figure 26.8: Example 26.8

26.24
Example 26.9
Figure 26.9 shows an example of a use of a proxy server in a
local network, such as the network on a campus or in a
company. The proxy server is installed in the local network.
When an HTTP request is created by any of the clients
(browsers), the request is first directed to the proxy server If
the proxy server already has the corresponding web page, it
sends the response to the client. Otherwise, the proxy server
acts as a client and sends the request to the web server in the
Internet. When the response is returned, the proxy server
makes a copy and stores it in its cache before sending it to
the requesting client.

26.25
 Figure 26.9: Example of a proxy server

26.26
 26-2 FTP

File Transfer Protocol (FTP) is the

standard protocol provided by
TCP/IP for copying a file from one
host to another. Although
transferring files from one system
to another seems simple and
straightforward, some problems
must be dealt with first.

26.27
Figure 26.10: FTP

Control
connection

Data
connection

26.28
 26.2.1 Two Connections

The two connections in FTP have different lifetimes.

The control connection remains connected during
the entire interactive FTP session. The data
connection is opened and then closed for each file
transfer activity. It opens each time commands that
involve transferring files are used, and it closes
when the file is transferred.

26.29
 Table 26.4: Some FTP
commands

26.30
 Table 26.4 : Some FTP commands (continued)

26.31
 Table 26.5: Some responses in
FTP

26.32
 26.2.3 Data Connection

The data connection uses the well-known port 20 at

the server site. However, the creation of a data
connection is different from the control connection.
The following shows the steps:

1.The client, not the server, issues a passive open

using an ephemeral port.
2.Using the PORT command the client sends this
port number to the server.
3. The server receives the port number and issues
an active open using the well-known port 20 and
the received ephemeral port number.
26.33
 26-3 ELECTRONIC MAIL

Electronic mail (or e-mail) allows

users to exchange messages. The
nature of this application is
different from other applications
discussed so far. This means that
the idea of client/server
programming should be
implemented in another way:
using some intermediate
computers (servers).
26.34
 26.3.1 Architecture

To explain the architecture of e-mail, we give a

common scenario, as shown in Figure 26.12.
Another possibility is the case in which Alice or Bob
is directly connected to the corresponding mail
server, in which LAN or WAN connection is not
required, but this variation in the scenario does not
affect our discussion.

26.35
 Figure 26.12: Common scenario

1 9
2
8

3 7

4 5 6

26.36
 Figure 26.13: Format of an e-mail

26.37
 Figure 26.14: E-mail address

26.38
 Figure 26.15: Protocols used in electronic mail

26.39
 Table 26.6: SMTP
Commands

26.40
 Table 26.7: SMTP responses
(Continued)

26.41
 Table 26.7: SMTP responses
(continued)

26.42
Example 26.12
To show the three mail transfer phases, we show all of the
steps described above using the information depicted in
Figure 26.16. In the figure, we have separated the messages
related to the envelope, header, and body in the data transfer
section. Note that the steps in this figure are repeated two
times in each e-mail transfer: once from the e-mail sender to
the local mail server and once from the local mail server to
the remote mail server. The local mail server, after receiving
the whole e-mail message, may spool it and send it to the
remote mail server at another time.

26.43
 Figure 26.16: Example 26.12

26.44
 Figure 26.17: POP3

26.45
 Figure 26.18: MIME

26.46
 Figure 26.19: MIME header

26.47
 Table 26.8: Data Types and Subtypes in
MIME

26.48
 Table 2.9: Methods for Content-Transfer-
Encoding

26.49
 Figure 26.20: Base64 conversion

26.50
 Table 26.10: Base64 Converting Table

26.51
 Figure 26.21: Quoted-printable

26.52
 26.3.2 E-Mail Security

The protocol discussed in this chapter does not

provide any security provisions per se. However, e-
mail exchanges can be secured using two
application-layer securities designed in particular
for e-mail systems. Two of these protocols, Pretty
Good Privacy (PGP) and Secure/Multipurpose
Internet Mail Extensions (S/MIME), are discussed
in Chapter 32 after we have discussed basic network
security.

26.53
 Figure 26.22: Web-based e-mail, cases I and II

26.54
 26.3.3 Iter. Programming Using TCP

We are now ready to discuss network programming

using the service of TCP, a connection-oriented
service.

26.55
 26-4 TELNET

It is impossible to have a
client/server pair for each type of
service we need; the number of
servers soon becomes
intractable. The idea is not
scalable. The solution is to have a
specific client/server program for
a set of common scenarios, but to
have some generic client/server
programs for the rest.
26.56
 26.4.1 Local versus Remote Logging

We first discuss the concept of local and remote

logging as shown in Figure 26.23.

26.57
 Figure 2.23: Local versus remote logging

26.58
 Figure 26.24: Concept of NVT

26.59
 Table 26.11: Examples of interface
commands

26.60
 26-5 SECURE SHELL (SSH)

Although Secure Shell (SSH) is a

secure application program that
can be used today for several
purposes such as remote logging
and file transfer, it was originally
designed to replace TELNET.
There are two versions of SSH.
The first version, SSH-1, is now
deprecated because of security
flaws in it. In this section, we
26.61
 26.5.1 Components

SSH is an application-layer protocol with three

components, as shown in Figure 26.25.

26.62
 Figure 26.25: Components of SSH

26.63
 26.5.2 Applications

Although SSH is often thought of as a replacement

for TELNET, SSH is, in fact, a general-purpose
protocol that provides a secure connection between a
client and server.

26.64
 Figure 26.26: Port Forwarding

26.65
 Figure 26.27: SSH Packet Format

26.66