Lecture 9:

Application layer

Reading Chapter 7
Computer networks, Tanenbaum

1
Contents
 Application layer
 Fundamental concepts
 Case study: HTTP, Mail, FTP…

2
Fundamental concepts

3
Application layer in OSI model
Application Protocols communication
between parties of the
(HTTP, Mail, …) application
Transport Transmission data between application
(UDP, TCP …)

Network
(IP, ICMP…)

Datalink
(Ethernet, ADSL…)

Physical
(bits…)
4
 Application and service?
MUSIC ONLINE
VoIP
GAME CHAT VoD
ON LINE e-Office
SMS e-BANK
MAIL
E-learning
WEB
YOUTUBE
VIDEO
CONFERENCE FTP
EBAY
GOOGLE SKYPE
Social
networks SSH

NEWS E-COMMERCE GRID

BITTORENT
5
e-Goverment
Application and application
protocol
 Application protocol application
transport
network
 Define communication rule data link
physical
 Use service of transport layer
(TCP/UDP…)
 Application:
 Is a process on the internet.
They communicate to each other
by exchanging messages.
 Runs on end systems
 Use application protocol for application
providing service transport
network
 Example of data link
physical
application
application/protocol: transport
network
 Web (HTTP) data link
physical
 Mail (SMTP/POP/IMAP) …
6
Components of an application
 Application software is compose of
 User interface:
 Interfacing with users,
 e.g. Web browser (Firefox, IE), mail reader(Thunderbird,
Outlook,..)
 Implement one part of application protocol
 Server program:
 Cung cấp dịch vụ cho người sử dụng

 Application process: the application software

running on an OS

7
Communication between application
processes
 Socket: an interface between application process and
transport layer
 Processes use services provided by transport layer to exchange
information
 Socket is identified by port number and IP address

application application
socket controlled by
process process app developer

transport transport
network network controlled
link by OS
link Network
physical physical

Image from: “Computer Networking: A Top

Down Approach”, Jim Kurose
8
Communication between processes
 Client process: send requests
 Server process: response requests
 Standard model: 1 server – many clients
 Clients need to know server address: IP
address and port number
wait for result handles
client response
request response
server
wait handle wait
request
9
Application architecture
 Client-server
 P2P
 Hybrid

10
 Client-server
 Two kind of components:
client client and server
 Client
 Client sends requests for service
client to server
 Clients do not contact directly to
each other
 Server
client
Server  Always online waiting for service
requests from clients
 There may be backup servers
for assuring high availability in
failures
client
 e.g. Web, Mail, …
11
 Pure Peer-to-peer architecture
Peer Peer
 No center server, only
peers as components
 Peers have equal role in
the system
Peer
Peer  Any two peers can
communicate directly to
each other but only
when both are online.
 Peer does not need to
be online all the time
Peer Peer
 E.g. Gnutella, Bittorent
12
Hybrid architecture
 A center server for user
Client
management, indexing
for search purpose.
 Clients communicate
directly to each other
Server after authentication
process with server.
 E.g. Skype (before 2016)
 Skype server manage user
lists, authentification
Client Client  After authentification users
communicate directly to
each other
P2P Comm. 13

Client-Server Comm.
Domain name service

14
Introduction
 Domain name: identifier on application layer for network node
 Internet management should be centralised
 International: ICANN
 Vietnam: VNNIC
 DNS(Domain Name System): the Internet's system for
mapping alphabetic names to numeric Internet Protocol (IP)
addresses
 Address resolution
 Users/ Clients use domain name to access services
 Computers and network devices cannot use domain name but IP
address
 How to translate domain name to IP address and reverse?
15
 Example of address resolution
• Computers use IP
I want to access
• Users use DN www.soict.hust.edu.vn

User

Need address resolution

Please access to
202.191.56.65

Domain Name
Server

Web server
202.191.56.65
16
DNS Server system
 Root server
 Answer local DNS servers
 Manage zone and decentralize the management to lower-level
servers
 There are 13 root servers (http://www.root-servers.org)

17

Image from : Wikipedia

DNS Server system (cont.)
 Top Level Domain servers
 Manage domain level 1
 Authoritative DNS servers
 Manage lower-level domains
 Servers of organisations: ISP
 Not belong to DNS hierarchy
 Local server: for private network of institutes
 Not belong to DNS hierarchy

18
Address resolution
 Self-resolution
 File HOST:
 Windows: C:\WINDOWS\system32\drivers\etc\
 Linux: /etc/hosts
 Application cache
 DNS service: client/server
 Application protocol: DNS
 Use UDP/TCP with the port 53
 Recursive Query
 Interactive Query
19
DNS Message
 DNS Query and DNS Reply:
Identification Flags
same format
#Question #Answer RRs
 Identification
 Response must have the same #Authority #Additional
identification of the request RRs RRs

 Flags: control flags QUESTION

 #Question: number of domain ANSWER

names requested AUTHORITY
 QUESTION: requested
ADDITIONAL
domain names

20
DNS Message
 #Answer RRs: Number of Identification Flags
answered records
#Question #Answer RRs
 ANSWER: Answered records
#Authority #Additional
 # Authority RRs: Number of RRs RRs
records that servers are
QUESTION
authorized
ANSWER
 AUTHORITY: Records of
authorized servers AUTHORITY
 #Additional RRs: Number of ADDITIONAL
additional records
 ADDITIONAL: additional
records
21
 Example: dig linux.com
; <> DiG 9.9.2-P1 <> linux.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2,
ADDITIONAL: 3
;; QUESTION SECTION: TTL: timing in cache
;linux.com. IN A
;; ANSWER SECTION:
linux.com. 1786 IN A 140.211.167.51
linux.com. 1786 IN A 140.211.167.50
;; AUTHORITY SECTION:
linux.com. 86386 IN NS ns1.linux-foundation.org.
linux.com. 86386 IN NS ns2.linux-foundation.org.
;; ADDITIONAL SECTION:
ns1.linux-foundation.org. 261 IN A 140.211.169.10
ns2.linux-foundation.org. 262 IN A 140.211.169.11

22
 Example: dig linux.com
; <> DiG 9.9.2-P1 <> linux.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2,
ADDITIONAL: 3
;; QUESTION SECTION: Names of DNS servers answered the request
;linux.com. IN A If ANSWER is empty, DNS Resolver sends
;; ANSWER SECTION: the request to these DNS servers
linux.com. 1786 IN A 140.211.167.51
linux.com. 1786 IN A 140.211.167.50
;; AUTHORITY SECTION:
linux.com. 86386 IN NS ns1.linux-foundation.org.
linux.com. 86386 IN NS ns2.linux-foundation.org.
;; ADDITIONAL SECTION:
ns1.linux-foundation.org. 261 IN A 140.211.169.10
ns2.linux-foundation.org. 262 IN A 140.211.169.11

23
 Example : dig linux.com
; <> DiG 9.9.2-P1 <> linux.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2,
ADDITIONAL: 3
;; QUESTION SECTION: IP address of DNS servers.
;linux.com. IN A Information will be stored in cache
;; ANSWER SECTION:
linux.com. 1786 IN A 140.211.167.51
linux.com. 1786 IN A 140.211.167.50
;; AUTHORITY SECTION:
linux.com. 86386 IN NS ns1.linux-foundation.org.
linux.com. 86386 IN NS ns2.linux-foundation.org.
;; ADDITIONAL SECTION:
ns1.linux-foundation.org. 261 IN A 140.211.169.10
ns2.linux-foundation.org. 262 IN A 140.211.169.11

24
Interactive Query
 Default mechanism on DNS
root
server

soict.hust.edu.vn soict.hust.edu.vn
TLD
202.191.56.65 Ask dns.hust.edu.vn server
Default dns.vn
server

Authoritative
DNS server
dns.hust.edu.vn 25
Recursive Query
 Extensible option
Root
server

soict.hust.edu.vn

soict.hust.edu.vn 202.191.56.65

TLD
202.191.56.65 server
Default
server dns.vn
soict.hust.edu.vn
202.191.56.65

Authoritative
DNS server
dns.hust.edu.vn
26
 HTTP and WWW

Reading 7.3
Computer Networks, Tanenbaum

27
HTTP và Web
 Internet before 1990s:
 Limited using for government institutes, research centers, ...
 Email or FPT services were not suitable for public data sharing
 No effective mechanism to link scattered resources in the
Internet
 In 1990, Tim Berners-Lee introduce World Wide Web:
 Exchange information as hypertext using HTML (Hypertext
Markup Language)
 Objects are not needed to be packed as “all in one” as previous
ones
 Hypertexts only need to contain links to other objects (located by
URL)

28
Uniform Resource Locator
 Areference to a web resource that specifies its
location on a computer network and a
mechanism for retrieving it
protocol://hostname[:port]/directory-path/resource

 protocol: http, ftp, https, smtp, rtsp…

 hostname: domain name or IP address
 port: port number (might not need)
 directory path: path to the resource
 resource: name of the resource

29
Web and HTTP
First, a quick review…
 web page consists of objects, each of which can be stored on
different Web servers
 object can be HTML file, JPEG image, Java applet, audio
file,…
 web page consists of base HTML-file which includes several
referenced objects, each addressable by a URL, e.g.,
www.someschool.edu/someDept/pic.gif

host name path name

HTTP overview
HTTP: hypertext transfer protocol
 Web’s application layer protocol
 client/server model: PC running
• client: browser that requests, Firefox browser
receives, (using HTTP protocol) and
“displays” Web objects
server running
• server: Web server sends (using Apache Web
HTTP protocol) objects in response server
to requests
iPhone running
Safari browser
HTTP overview (continued)
HTTP uses TCP: HTTP is “stateless”
 client initiates TCP connection  server maintains no
(creates socket) to server, port 80 information about past client
 server accepts TCP connection requests
from client aside
 HTTP messages (application-layer protocols that maintain “state”
are complex!
protocol messages) exchanged
 past history (state) must be
between browser (HTTP client) and maintained
Web server (HTTP server)  if server/client crashes, their views
 TCP connection closed of “state” may be inconsistent,
must be reconciled

Application Layer: 2-32

HTTP connections: two types
Non-persistent HTTP Persistent HTTP
1. TCP connection opened TCP connection opened to
2. at most one object sent a server
over TCP connection multiple objects can be
3. TCP connection closed sent over single TCP
connection between
downloading multiple client, and that server
objects required multiple TCP connection closed
connections
 Non-persistent HTTP: example
User enters URL: www.someSchool.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

1a. HTTP client initiates TCP

connection to HTTP server 1b. HTTP server at host
(process) at www.someSchool.edu on www.someSchool.edu waiting for TCP
port 80 connection at port 80 “accepts”
connection, notifying client
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection 3. HTTP server receives request message,
socket. Message indicates forms response message containing
time that client wants object requested object, and sends message
someDepartment/home.index into its socket

Application Layer: 2-34

 Non-persistent HTTP: example
(cont.)
User enters URL: www.someSchool.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

4. HTTP server closes TCP

5. HTTP client receives response connection.
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

6. Steps 1-5 repeated for

each of 10 jpeg objects
time

Application Layer: 2-35

Non-persistent HTTP: response
time
RTT (definition): time for a small
packet to travel from client to
server and back initiate TCP
connection
HTTP response time (per object): RTT
 one RTT to initiate TCP connection
request file
 one RTT for HTTP request and first few
RTT time to
bytes of HTTP response to return transmit
 obect/file transmission time file received
file

time time
Non-persistent HTTP response time = 2RTT+ file transmission time

Application Layer: 2-36

Persistent HTTP (HTTP 1.1)
Non-persistent HTTP issues: Persistent HTTP (HTTP1.1):
 requires 2 RTTs per object  server leaves connection open
 OS overhead for each TCP after sending response
connection  subsequent HTTP messages
 browsers often open multiple between same client/server sent
parallel TCP connections to over open connection
fetch referenced objects in  client sends requests as soon as it
parallel encounters a referenced object
 as little as one RTT for all the
referenced objects (cutting
response time in half)

Application Layer: 2-37

 Operation of HTTP/1.0
Web client Web server

Init TCP connection

Accept TCP connection

OK, send HTTP request

Send HTTP response: index.html
Close TCP connection

Parse index.html: has 10

reference to 10 images

Accept TCP connection

Repeat above steps 10
times!

Send images 1
Close TCP connection
2xRTT 38

Time Time
Operation of HTTP/1.1
Web client Web server

Init TCP connection

Accept TCP connection

OK, send HTTP request

Send HTTP
Parse index.html: has 10 response: index.html
reference to 10 images
request images 1
Send images 1

request images 2

Send images 2
Stop-and- Pipeline
request images 10 wait! 39

Time Time
HTTP/1.1 with pipeline
Web client Web server

Init TCP connection

Accept TCP connection

OK, send HTTP request

Send HTTP
Parse index.html: has 10 response: index.html
reference to 10 images
request images 1 -10
Send images 1-10

40

Time Time
 HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
• ASCII (human-readable format) carriage return character
line-feed character
request line (GET,
GET /index.html HTTP/1.1\r\n
POST, Host: www-net.cs.umass.edu\r\n
HEAD commands) User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
header Accept-Language: en-us,en;q=0.5\r\n
lines Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
carriage return, line \r\n
feed at start of line
indicates end of header
lines

Application Layer: 2-41

 Other HTTP request messages
POST method: HEAD method:
 web page often includes form  requests headers (only) that
input would be returned if specified
 user input sent from client to URL were requested with an
server in entity body of HTTP HTTP GET method.
POST request message
PUT method:
 uploads new file (object) to
GET method (for sending data to server
server):  completely replaces file that
 include user data in URL field of HTTP exists at specified URL with
GET request message (following a ‘?’): content in entity body of POST
www.somesite.com/animalsearch?monkeys&banana
HTTP request message

Application Layer: 2-42

HTTP response message
status line (protocol HTTP/1.1 200 OK\r\n
status code status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n
\r\n
data, e.g., requested data data data data data ...
HTML file

Application Layer: 2-43

HTTP response status codes
 status code appears in 1st line in server-to-client response message.
 some sample codes:
200 OK
• request succeeded, requested object later in this message
301 Moved Permanently
• requested object moved, new location specified later in this message (in
Location: field)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported

Application Layer: 2-44

Trying out HTTP (client side) for
yourself
1. Telnet to your favorite Web server:
telnet gaia.cs.umass.edu 80  opens TCP connection to port 80 (default HTTP server
port) at gaia.cs.umass. edu.
 anything typed in will be sent to port 80 at
gaia.cs.umass.edu
2. type in a GET HTTP request:
GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.edu
 by typing this in (hit carriage return twice), you send
this minimal (but complete) GET request to HTTP
server

3. look at response message sent by HTTP server!

(or use Wireshark to look at captured HTTP request/response)

Application Layer: 2-45

Maintaining user/server state:
cookies
a stateful protocol: client makes
Recall: HTTP GET/response two changes to X, or none at all
interaction is stateless
X
 no notion of multi-step exchanges
of HTTP messages to complete a X
Web “transaction”
• no need for client/server to track X
“state” of multi-step exchange t’
’

• all HTTP requests are independent of X

each other ’’

• no need for client/server to “recover” X’’

from a partially-completed-but-never-
time time
completely-completed transaction
Q: what happens if network connection or
client crashes at t’ ?

Application Layer: 2-46

Maintaining user/server state:
cookies
Web sites and client browser use Example:
cookies to maintain some state  Susan uses browser on laptop,
visits specific e-commerce site
between transactions for first time
four components:  when initial HTTP requests
1) cookie header line of HTTP response arrives at site, site creates:
message • unique ID (aka “cookie”)
2) cookie header line in next HTTP • entry in backend database
for ID
request message
• subsequent HTTP requests
3) cookie file kept on user’s host, from Susan to this site will
managed by user’s browser contain cookie ID value,
4) back-end database at Web site allowing site to “identify”
Susan

Application Layer: 2-47

Maintaining user/server state:
cookies
client
server
ebay 8734 usual HTTP request msg Amazon server
cookie file creates ID
usual HTTP response 1678 for user backend
create
ebay 8734 set-cookie: 1678 entry database
amazon 1678

usual HTTP request msg

cookie: 1678 cookie- access
specific
usual HTTP response msg action

one week later:

access
ebay 8734 usual HTTP request msg
amazon 1678 cookie: 1678 cookie-
specific
usual HTTP response msg action
time time

Application Layer: 2-48

HTTP cookies: comments
aside
What cookies can be used for: cookies and privacy:
 authorization  cookies permit sites to
 shopping carts learn a lot about you on
their site.
 recommendations  third party persistent
 user session state (Web e-mail) cookies (tracking cookies)
allow common identity
(cookie value) to be
Challenge: How to keep state: tracked across multiple
 protocol endpoints: maintain state at
web sites
sender/receiver over multiple transactions
 cookies: HTTP messages carry state

Application Layer: 2-49

Web caches (proxy servers)
Goal: satisfy client request without involving origin server
 user configures browser to
point to a Web cache proxy
 browser sends all HTTP server
requests to cache client
origin
server
• if object in cache: cache
returns object to client
• else cache requests object
from origin server, caches
received object, then client
origin
returns object to client server

Application Layer: 2-50

Web caches (proxy servers)
 Web cache acts as both Why Web caching?
client and server  reduce response time for client
• server for original request
requesting client
• cache is closer to client
• client to origin server
 reduce traffic on an institution’s
 typically cache is access link
installed by ISP
(university, company,  Internet is dense with caches
residential ISP) • enables “poor” content providers
to more effectively deliver content

Application Layer: 2-51

Caching example
Scenario:
 access link rate: 1.54 Mbps origin
 RTT from institutional router to server: 2 sec servers
 Web object size: 100K bits public
Internet
 Average request rate from browsers to
origin servers: 15/sec
 average data rate to browsers: 1.50
1.54 Mbps
Mbps
Performance: problem: large
access link

 LAN utilization: .0015 delays at high institutional

network
 access link utilization = .97 utilization! 1 Gbps LAN

 end-end delay = Internet delay +

access link delay + LAN delay
= 2 sec + minutes + usecs

Application Layer: 2-52

Caching example: buy a faster
access link
Scenario: 154 Mbps
 access link rate: 1.54 Mbps origin
 RTT from institutional router to server: 2 sec servers
 Web object size: 100K bits public
Internet
 Avg request rate from browsers to origin
servers: 15/sec
 avg data rate to browsers: 1.50 Mbps 154 Mbps
1.54 Mbps
Performance: access link

 LAN utilization: .0015 institutional

network
1 Gbps LAN
 access link utilization = .97 .0097
 end-end delay = Internet delay +
access link delay + LAN delay
= 2 sec + minutes + usecs
msecs
Cost: faster access link (expensive!)

Application Layer: 2-53

Caching example: install a web
cache
Scenario:
 access link rate: 1.54 Mbps origin
 RTT from institutional router to server: 2 sec servers
 Web object size: 100K bits public
Internet
 Avg request rate from browsers to origin
servers: 15/sec
 avg data rate to browsers: 1.50 Mbps
1.54 Mbps
Performance: access link

 LAN utilization: .? How to compute link

institutional
network
1 Gbps LAN
 access link utilization = ? utilization, delay?
 average end-end delay = ?
Cost: web cache (cheap!) local web cache

Application Layer: 2-54

Caching example: install a web
cache
Calculating access link utilization, end-
end delay with cache: origin
 suppose cache hit rate is 0.4: 40% requests servers
satisfied at cache, 60% requests satisfied at public
Internet
origin
 access link: 60% of requests use access link
 data rate to browsers over access link
1.54 Mbps
= 0.6 * 1.50 Mbps = .9 Mbps access link
 utilization = 0.9/1.54 = .58 institutional
network
 average end-end delay 1 Gbps LAN
= 0.6 * (delay from origin servers)
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs local web cache

lower average end-end delay than with 154 Mbps link (and cheaper too!)

Application Layer: 2-55

Local cache
 Web pages could be stored in local server
(local cache)
 Using local cache for
 Reading web offline
 Improve performance in accessing web pages

56
Conditional GET client server

Goal: don’t send object if cache has

HTTP request msg
up-to-date cached version If-modified-since: <date> object
not
• no object transmission delay
modified
• lower link utilization HTTP response
before
HTTP/1.0
<date>
 cache: specify date of cached copy 304 Not Modified

in HTTP request
If-modified-since: <date>
HTTP request msg
 server: response contains no If-modified-since: <date> object
object if cached copy is up-to- modified
after
date: HTTP response
HTTP/1.0 200 OK <date>
HTTP/1.0 304 Not Modified <data>

Application Layer: 2-57

HTTP/2
Key goal: decreased delay in multi-object HTTP requests
HTTP1.1: introduced multiple, pipelined GETs over single TCP
connection
 server responds in-order (FCFS: first-come-first-served scheduling) to
GET requests
 with FCFS, small object may have to wait for transmission (head-of-
line (HOL) blocking) behind large object(s)
 loss recovery (retransmitting lost TCP segments) stalls object
transmission

Application Layer: 2-58

HTTP/2
Key goal: decreased delay in multi-object HTTP requests

HTTP/2: [RFC 7540, 2015] increased flexibility at server in sending

objects to client:
 methods, status codes, most header fields unchanged from HTTP
1.1
 transmission order of requested objects based on client-specified
object priority (not necessarily FCFS)
 push unrequested objects to client
 divide objects into frames, schedule frames to mitigate HOL
blocking

Application Layer: 2-59

HTTP/2: mitigating HOL blocking
HTTP 1.1: client requests 1 large object (e.g., video file, and 3 smaller
objects)
server

GET O4 GET O3 GET O

2 GET O1 object data requested
client

O1

O2
O1
O2 O3
O3
O4
O4

objects delivered in order requested: O2, O3, O4 wait behind O1

Application Layer: 2-60

HTTP/2: mitigating HOL blocking
HTTP/2: objects divided into frames, frame transmission interleaved
server

GET O4 GET O3 GET O

2 GET O1 object data requested
client
O2
O4
O3 O1

O2
O3
O1
O4

O2, O3, O4 delivered quickly, O1 slightly delayed

Application Layer: 2-61

HTTPS
 Limitation of HTTP:
 No mechanism for users to check the reliability of web server 
Không có cơ chế để người dùng kiểm tra tính tin cậy của Web
server  security vulnerability for imposters or embed malicious
code to HTML
 No mechanism for data encryption  security vulnerability for
attackers to sneak and steal sensitive information
 Secure HTTP: use SSL/TLS instead of TCP to send
HTTP messages
 Authentication:
 Users can access to the correct website

 Communication data won’t be changed

 Security: data are kept secretly during data transmission

 Port: 443
62
HTTPS on the Web
Access Web with HTTPS

- The whole content of website

(including images, CSS, Flash, scripts...)
has been verified by the browsers to
make sure the integrity and safe source.
- All exchanged information between the
broser and Vietcombank is kept secret. 63
Email

66
 Electronic mail (E-mail)
 MUA (Mail User Agent)  Protocols:
 Get emails from servers, send  Send emails: SMTP-Simple
emails to servers
Mail Transfer Protocol
 e.g. Outlook, Thunderbird…
 MTA (Mail Transfer Agent): :  Receive emails
 Contain the mail boxes of user  POP – Post Office Protocol
 Queue to send emails  IMAP – Internet Mail Access
 e.g. Sendmail, MS Exchange… Protocol

IMAP IMAP
mail mail
POP POP
user server server user
SMTP
agent agent
SMTP SMTP 67

Mail box Message queue

SMTP
 RFC 2821
 TCP, port 25: send emails from client to server
and between servers
 Interactive request/response
 Request: Command with ASCII

 Response: state code and data

69
Web Mail
 Use Web browser as MUA
 MUA and MTA exchange information through HTTP
 Mails are stored on servers
 E.g.
 Gmail,
 Hotmail,
 Yahoo! Mail, etc.
 Today, there are many MTA accessible through web
interface
 http://mail.hust.edu.vn
 http://mail.soict.hust.edu.vn
70
Mail message format
SMTP: protocol for exchanging e-mail
messages, defined in RFC 531 (like HTTP)
RFC 822 defines syntax for e-mail message
itself (like HTML)
 header lines, e.g., header
blank
• To:
line
• From:
• Subject:
these lines, within the body of the email body
message area different from SMTP MAIL
FROM:, RCPT TO: commands!
 Body: the “message” , ASCII characters only

Application Layer: 2-71

 MIME standard
 Represent email content with multimedia data
 MIME: multimedia mail extension, RFC 2045, 2056
 Add one line in the header to specify the sending data
type
From: alice@crepes.fr
MIME version To: bob@hamburger.edu
Subject: Picture of yummy crepe.
method used MIME-Version: 1.0
to encode data Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
type, subtype, base64 encoded data .....
parameter declaration .........................
......base64 encoded data
encoded data

72
File Transfer Protocol

73
FTP: File Transfer Protocol

TCP control
connection, port 21
user FTP FTP
interface client server
TCP data
user connection, port 20

local file system remote file system

 Client-server model  Out-of-band control:

 File transfer between two  FTP command : port 21
hosts  Data: port 20
 RFC 959  Need user to log-in before
data transfer
 Use TCP, port 20, 21
 Some servers allow
anonymous user 74
FTP commands, responses
Sample commands: Sample return codes
 USER username  331 Username OK,
 PASS password password required
 LIST return list of file in  125 data connection
already open; transfer
current directory
starting
 RETR filename retrieves  425 Can’t open data
(gets) file connection
 STOR filename stores  452 Error writing file
(puts) file onto remote host

75
FTP client
Command line

C:\Documents and Settings\hongson>ftp

ftp> ?
Commands may be abbreviated. Commands are:

! delete literal prompt send

? debug ls put status
append dir mdelete pwd trace
ascii disconnect mdir quit type
bell get mget quote user
binary glob mkdir recv verbose
bye hash mls remotehelp
cd help mput rename
close lcd open rmdir

GUI FTP clients: IE, Firefox, GFTP, …. 76