Computer Communications and Networks: FTP, SMTP (Comparison With HTTP), POP3, DNS-The Internet's Directory Service
Computer Communications and Networks: FTP, SMTP (Comparison With HTTP), POP3, DNS-The Internet's Directory Service
Communications and
Networks
FTP, SMTP(Comparison with HTTP), POP3, DNS—The Internet’s
Directory Service
(week 5)
By
Hafiz Aamir Hafeez
File Transfer: FTP
In a 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 password.
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.
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.
File Transfer:
FTP
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 system into the remote file system (or vice versa).
File Transfer: FTP
HTTP and FTP are both file transfer protocols and have many common characteristics; 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.
File Transfer: FTP
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 connection is created for each file transferred within a session (that is,
the data connections are non-persistent).
Throughout a session, the FTP server must maintain state about the user.
FTP Commands and Replies
SMTP, the heart of Internet electronic mail. SMTP transfers messages from
senders’ mail servers to the recipients mail servers. Although SMTP has
numerous wonderful qualities, as evidenced by its ubiquity in the Internet, it is
nevertheless a legacy technology that possesses certain archaic characteristics.
For example, it restricts the body (not just the headers) of all mail messages to
simple 7-bit ASCII. This restriction made sense in the early 1980s when
transmission capacity was scarce and no one was e-mailing large attachments
or large image, audio, or video files. But today, in the multimedia era, the 7-bit
ASCII restriction is a bit of a pain—it requires binary multimedia data to be
encoded to ASCII before being sent over SMTP; and it requires the
corresponding ASCII message to be decoded back to binary after SMTP
transport.
SMTP
To illustrate the basic operation of SMTP, let’s walk through a common scenario. Suppose Alice
wants to send Bob a simple ASCII message.
1. Alice invokes her user agent for e-mail, provides Bob’s e-mail address (for example,
[email protected]), composes a message, and instructs the user agent to send the message.
2. Alice’s user agent sends the message to her mail server, where it is placed in a message queue.
3. The client side of SMTP, running on Alice’s mail server, sees the message in the message queue. It
opens a TCP connection to an SMTP server, running on Bob’s mail server.
4. After some initial SMTP handshaking, the SMTP client sends Alice’s message into the TCP
connection.
5. At Bob’s mail server, the server side of SMTP receives the message. Bob’s mail server then places
the message in Bob’s mailbox.
6. Bob invokes his user agent to read the message at his convenience.
SMTP
POP3 is an extremely simple mail access protocol. It is short and quite readable. Because the
protocol is so simple, its functionality is rather limited.
POP3 begins when the user agent (the client) opens a TCP connection to the mail server (the
server). With the TCP connection established,
POP3 progresses through three phases: authorization, transaction, and update.
During the first phase, authorization, the user agent sends a username and a password (in
the clear) to authenticate the user.
During the second phase, transaction, the user agent retrieves messages; also during this
phase, the user agent can mark messages for deletion, remove deletion marks, and obtain
mail statistics.
The third phase, update, occurs after the client has issued the quit command, ending the
POP3 session; at this time, the mail server deletes the messages that were marked for
deletion.
POP3
In a POP3 transaction, the user agent issues commands, and the server responds to each
command with a reply. There are two possible responses: +OK (sometimes followed by server-
to-client data), used by the server to indicate that the previous command was fine; and -ERR,
used by the server to indicate that something was wrong with the previous command.
The authorization phase has two principal commands: user <username> and pass <password>.
To illustrate these two commands, we suggest that you Telnet directly into a POP3 server, and
issue these commands. Suppose that Mail Server is the name of your mail server. You will see
something like:
telnet mail Server 110
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged on
If you misspell a command, the POP3 server will reply with an -ERR message.
DNS—The Internet’s Directory Service
Just as humans can be identified in many ways, so too can Internet hosts. One identifier for a
host is its hostname. Hostnames—such as cnn.com, www.yahoo. com, —are mnemonic and
are therefore appreciated by humans. However, hostnames provide little, if any, information
about the location within the Internet of the host. (A hostname such as www.eurecom.fr,
which ends with the country code .fr, tells us that the host is probably in France, but doesn’t
say much more.)
Furthermore, because hostnames can consist of variable length alphanumeric characters, they
would be difficult to process by routers. For these reasons, hosts are also identified by so-called
IP addresses.
An IP address consists of four bytes and has a rigid hierarchical structure. An IP address looks
like 121.7.106.83, where each period separates one of the bytes expressed in decimal notation
from 0 to 255. An IP address is hierarchical because as we scan the address from left to right,
we obtain more and more specific information about where the host is located in the Internet.
Services Provided by DNS
We have just seen that there are two ways to identify a host—by a hostname and by an
IP address. People prefer the more mnemonic hostname identifier, while routers prefer
fixed-length.
In order to reconcile these preferences, we need a directory service that translates
hostnames to IP addresses. This is the main task of the Internet’s domain name system
(DNS).
DNS is commonly employed by other application-layer protocols—including HTTP, SMTP,
and FTP—to translate user-supplied hostnames to IP addresses. As an example, consider
what happens when a browser (that is, an HTTP client), running on some user’s host,
requests the URL www.someschool.edu/ index.html. In order for the user’s host to be
able to send an HTTP request message to the Web server www.someschool.edu, the
user’s host must first obtain the IP address of www.someschool.edu.
Services Provided by DNS
This is done as follows.
The same user machine runs the client side of the DNS application.
The browser extracts the hostname, www.someschool.edu, from the URL
passes the hostname to the client side of the DNS application.
The DNS client sends a query containing the hostname to a DNS server.
The DNS client eventually receives a reply, which includes the IP address
for the hostname.
Once the browser receives the IP address from DNS, it can initiate a TCP
connection to the HTTP server process located at port 80 at that IP
address.
Services Provided by DNS
DNS provides a few other important services in addition to translating hostnames to IP
addresses:
Host aliasing.
Mail server aliasing.
Load distribution.
Host aliasing. A host with a complicated hostname can have one or more alias
names. For example, a hostname such as relay1.west-coast.enterprise. com could
have, say, two aliases such as enterprise.com and www.enterprise.com. In this case,
the hostname relay1.westcoast. enterprise.com is said to be a canonical hostname.
Alias hostnames, when present, are typically more mnemonic than canonical
hostnames. DNS can be invoked by an application to obtain the canonical hostname
for a supplied alias hostname as well as the IP address of the host.
Services Provided by DNS
Mail server aliasing. For obvious reasons, it is highly desirable that e-mail addresses be
mnemonic. For example, if Bob has an account with Hotmail, Bob’s e-mail address might
be as simple as [email protected]. However, the hostname of the Hotmail mail server is
more complicated and much less mnemonic than simply hotmail.com (for example, the
canonical hostname might be something like relay1.west-coast.hotmail.com).
Load distribution. DNS is also used to perform load distribution among replicated
servers, such as replicated Web servers. Busy sites, such as cnn.com, are replicated over
multiple servers, with each server running on a different end system and each having a
different IP address. For replicated Web servers, a set of IP addresses is thus associated
with one canonical hostname. The DNS database contains this set of IP addresses.
When clients make a DNS query for a name mapped to a set of addresses, the server
responds with the entire set of IP addresses, but rotates the ordering of the addresses
within each reply.
Overview of How DNS Works:
Suppose that some application (such as a Web browser or a mail reader) running
in a user’s host needs to translate a hostname to an IP address. The application
will invoke the client side of DNS, specifying the hostname that needs to be
translated. (On many UNIX-based machines, gethostbyname() is the function call
that an application calls in order to perform the translation.)
DNS in the user’s host then takes over, sending a query message into the
network. All DNS query and reply messages are sent within UDP datagrams to
port 53. After a delay, ranging from milliseconds to seconds, DNS in the user’s
host receives a DNS reply message that provides the desired mapping. This
mapping is then passed to the invoking application. Thus, from the perspective
of the invoking application in the user’s host, DNS is a black box providing a
simple, straightforward translation service.
Overview of How DNS Works:
A simple design for DNS would have one DNS server that contains all the
mappings. In this centralized design, clients simply direct all queries to the
single DNS server, and the DNS server responds directly to the querying
clients. Although the simplicity of this design is attractive, it is inappropriate
for today’s Internet, with its vast (and growing) number of hosts. The
problems with a centralized design include:
A single point of failure. If the DNS server crashes, so does the entire
Internet!
Traffic volume. A single DNS server would have to handle all DNS queries
(for all the HTTP requests and e-mail messages generated from hundreds
of millions of hosts).
Overview of How DNS Works:
Distant centralized database. A single DNS server cannot be “close to” all
the querying clients. If we put the single DNS server in New York City,
then all queries from Australia must travel to the other side of the globe,
perhaps over slow and congested links. This can lead to significant delays.
Maintenance. The single DNS server would have to keep records for all
Internet hosts. Not only would this centralized database be huge, but it
would have to be updated frequently to account for every new host.
In summary, a centralized database in a single DNS server simply doesn’t
scale. Consequently, the DNS is distributed by design. In fact, the DNS is a
wonderful example of how a distributed database can be implemented in
the Internet.
Reading Assignment
A Distributed, Hierarchical Database
Three classes of DNS servers
Root DNS servers.
Top-level domain (TLD) servers.
Authoritative DNS servers.
Local DNS servers
Recursive queries and Iterative queries in DNS
DNS Cashing
DNS Records and Messages
DNS Records and Messages:
The DNS servers that together implement the DNS distributed database
store resource records (RRs), including RRs that provide hostname-to-
IP address mappings. Each DNS reply message carries one or more
resource records.
A resource record is a four-tuple that contains the following fields:
(Name, Value, Type, TTL)
TTL is the time to live of the resource record; it determines when a
resource should be removed from a cache. In the example records
given below, we ignore the TTL field. The meaning of Name and Value
depend on Type:
DNS Records and Messages:
If Type=A, then Name is a hostname and Value is the IP address for
the hostname. Thus, a Type A record provides the standard
hostname-to-IP address mapping. As an example, (relay1.bar.foo.com,
145.37.93.126, A) is a Type A record.
If Type=NS, then Name is a domain (such as foo.com) and Value is the
hostname of an authoritative DNS server that knows how to obtain
the IP addresses for hosts in the domain. This record is used to route
DNS queries further along in the query chain. As an example,
(foo.com, dns.foo.com, NS) is a Type NS record.
DNS Records and Messages:
If Type=CNAME, then Value is a canonical hostname for the alias hostname
Name. This record can provide querying hosts the canonical name for a
hostname. As an example, (foo.com, relay1.bar.foo.com, CNAME) is a CNAME
record.
If Type=MX, then Value is the canonical name of a mail server that has an alias
hostname Name. As an example, (foo.com, mail.bar.foo.com, MX) is an MX
record.
MX records allow the hostnames of mail servers to have simple aliases. Note that by using
the MX record, a company can have the same aliased name for its mail server and for one
of its other servers (such as its Web server).
To obtain the canonical name for the mail server, a DNS client would query for an MX
record; to obtain the canonical name for the other server, the DNS client would query for
the CNAME record.
DNS Messages
DNS query and reply messages. These are the only two kinds of DNS messages.
Furthermore, both query and reply messages have the same format, as shown in
Figure.
The semantics of the various fields in a DNS message are as follows:
The first 12 bytes is the header section, which has a number of fields. The first field
is a 16-bit number that identifies the query. This identifier is copied into the reply
message to a query, allowing the client to match received replies with sent queries
There are a number of flags in the flag field. A 1-bit query/reply flag indicate
whether the message is a query (0) or a reply (1). A1-bit authoritative flag is set in
a reply message when a DNS server is an authoritative server for a queried name.
A 1-bit recursion-desired flag is set when a client (host or DNS server) desires that
the DNS server perform recursion when it doesn’t have the record. A 1-bit
recursion available field is set in a reply if the DNS server supports recursion.
DNS Messages
In the header, there are also four number-of fields. These fields indicate the
number of occurrences of the four types of data sections that follow the header.
The question section contains information about the query that is being made.
This section includes (1) a name field that contains the name that is being
queried, and (2) a type field that indicates the type of question being asked
about the name—for example, a host address associated with a name (Type A)
or the mail server for a name (Type MX).
In a reply from a DNS server, the answer section contains the resource records
for the name that was originally queried. Recall that in each resource record
there is the Type (for example, A, NS, CNAME, and MX), the Value, and the TTL
A reply can return multiple RRs in the answer, since a hostname can have
multiple IP addresses (for example, for replicated Web servers, as discussed
earlier in this section).
DNS Messages
The authority section contains
records of other authoritative
servers.
The additional section contains
other helpful records. For
example, the answer field in a
reply to an MX query contains a
resource record providing the
canonical hostname of a mail
server. The additional section
contains a Type A record
providing the IP address for the
canonical hostname of the mail
server.