File Transfer: FTP: Chapter 2

116 CHAPTER 2 • APPLICATION LAYER
We see that in response to the conditional GET, the Web server still sends a response
message but does not include the requested object in the response message. Including
the requested object would only waste bandwidth and increase user-perceived response
time, particularly if the object is large. Note that this last response message has 304
Not Modified in the status line, which tells the cache that it can go ahead and for-
ward its (the proxy cache’s) cached copy of the object to the requesting browser.
This ends our discussion of HTTP, the first Internet protocol (an application-layer
protocol) that we’ve studied in detail. We’ve seen the format of HTTP messages and
the actions taken by the Web client and server as these messages are sent and received.
We’ve also studied a bit of the Web’s application infrastructure, including caches, cook-
ies, and back-end databases, all of which are tied in some way to the HTTP protocol.
2.3 File Transfer: FTP

In a typical FTP session, the user is sitting in front of one host (the local host)
and wants to transfer files to or from a remote host. In order for the user to
access the remote account, the user must provide a user identification and a pass-
word. After providing this authorization information, the user can transfer files
from the local file system to the remote file system and vice versa. As shown in
Figure 2.14, the user interacts with FTP through an FTP user agent. The user first
provides the hostname of the remote host, causing the FTP client process in the
local host to establish a TCP connection with the FTP server process in the
remote host. The user then provides the user identification and password, which
are sent over the TCP connection as part of FTP commands. Once the server has
authorized the user, the user copies one or more files stored in the local file sys-
tem into the remote file system (or vice versa).
FTP user FTP File transfer FTP

interface client server
User
or host
Local file Remote file

system system
Figure 2.14 FTP moves files between local and remote file systems
2.3 • FILE TRANSFER: FTP 117
TCP control connection port 21
TCP data connection port 20

FTP FTP
client server
Figure 2.15 Control and data connections
HTTP and FTP are both file transfer protocols and have many common charac-
teristics; for example, they both run on top of TCP. However, the two application-layer
protocols have some important differences. The most striking difference is that FTP
uses two parallel TCP connections to transfer a file, a control connection and a data
connection. The control connection is used for sending control information between
the two hosts—information such as user identification, password, commands to
change remote directory, and commands to “put” and “get” files. The data connection
is used to actually send a file. Because FTP uses a separate control connection, FTP is
said to send its control information out-of-band. HTTP, as you recall, sends request
and response header lines into the same TCP connection that carries the transferred
file itself. For this reason, HTTP is said to send its control information in-band. In the
next section, we’ll see that SMTP, the main protocol for electronic mail, also sends
control information in-band. The FTP control and data connections are illustrated in
Figure 2.15.
When a user starts an FTP session with a remote host, the client side of FTP
(user) first initiates a control TCP connection with the server side (remote host) on
server port number 21. The client side of FTP sends the user identification and
password over this control connection. The client side of FTP also sends, over the
control connection, commands to change the remote directory. When the server
side receives a command for a file transfer over the control connection (either to,
or from, the remote host), the server side initiates a TCP data connection to the
client side. FTP sends exactly one file over the data connection and then closes the
data connection. If, during the same session, the user wants to transfer another file,
FTP opens another data connection. Thus, with FTP, the control connection
remains open throughout the duration of the user session, but a new data connec-
tion is created for each file transferred within a session (that is, the data connec-
tions are non-persistent).
Throughout a session, the FTP server must maintain state about the user. In par-
ticular, the server must associate the control connection with a specific user account,
and the server must keep track of the user’s current directory as the user wanders
about the remote directory tree. Keeping track of this state information for each
ongoing user session significantly constrains the total number of sessions that FTP
can maintain simultaneously. Recall that HTTP, on the other hand, is stateless—it
does not have to keep track of any user state.
118 CHAPTER 2 • APPLICATION LAYER
2.3.1 FTP Commands and Replies

We end this section with a brief discussion of some of the more common FTP com-
mands and replies. The commands, from client to server, and replies, from server to
client, are sent across the control connection in 7-bit ASCII format. Thus, like HTTP
commands, FTP commands are readable by people. In order to delineate successive
commands, a carriage return and line feed end each command. Each command con-
sists of four uppercase ASCII characters, some with optional arguments. Some of
the more common commands are given below:
• USER username: Used to send the user identification to the server.

• PASS password: Used to send the user password to the server.
• LIST: Used to ask the server to send back a list of all the files in the current
remote directory. The list of files is sent over a (new and non-persistent) data
connection rather than the control TCP connection.
• RETR filename: Used to retrieve (that is, get) a file from the current direc-
tory of the remote host. This command causes the remote host to initiate a data
connection and to send the requested file over the data connection.
• STOR filename: Used to store (that is, put) a file into the current directory
of the remote host.
There is typically a one-to-one correspondence between the command that the

user issues and the FTP command sent across the control connection. Each com-
mand is followed by a reply, sent from server to client. The replies are three-digit
numbers, with an optional message following the number. This is similar in struc-
ture to the status code and phrase in the status line of the HTTP response message.
Some typical replies, along with their possible messages, are as follows:
• 331 Username OK, password required

• 125 Data connection already open; transfer starting
• 425 Can’t open data connection
• 452 Error writing file
Readers who are interested in learning about the other FTP commands and replies
are encouraged to read RFC 959.
2.4 Electronic Mail in the Internet

Electronic mail has been around since the beginning of the Internet. It was the most
popular application when the Internet was in its infancy [Segaller 1998], and has

File Transfer: FTP: Chapter 2

Uploaded by

Copyright:

Available Formats

File Transfer: FTP: Chapter 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

File Transfer: FTP: Chapter 2

Uploaded by

Copyright:

Available Formats

116 CHAPTER 2 • APPLICATION LAYER

2.3 File Transfer: FTP

FTP user FTP File transfer FTP

Local file Remote file

TCP control connection port 21

TCP data connection port 20

Figure 2.15 Control and data connections

2.3.1 FTP Commands and Replies

• USER username: Used to send the user identification to the server.

There is typically a one-to-one correspondence between the command that the

• 331 Username OK, password required

2.4 Electronic Mail in the Internet

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.