Application Layer

❑ Conceptual, implementation aspects of network application protocols

❑ Learn about protocols by examining popular application-level protocols
❑ Programming network applications
 Chapter 3: Application layer
2

 2.1 Principles of network

applications
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
2.1 Principles of network
applications

Lớp Application 3
Kiến trúc phân tầng
Ứng dụng mạng
 Ứng dụng application
transport

 Chương trình hoạt động trên network

data link

các thiết bị đầu cuối physical

 Trao đổi thông điệp

 Giao thức ứng dụng
 Định nghĩa các quy tắc giao
tiếp
 Sử dụng các dịch vụ giao vận
(TCP/UDP…) application
transport
 Ví dụ ứng dụng/giao thức network
data link
application
physical
 Web (HTTP) transport
network

 Mail (SMTP, POP, IMAP)

data link
physical
Các thành phần của ứng dụng
 Giao diện NSD:
 Hỗ trợ cho NSD để làm việc với ứng dụng, e.g. trình
duyệt Web (Firefox, IE), chương trình gửi thư
(Thunderbird, Outlook,..)
 Cài đặt các giao thức và sử dụng dịch vụ giao vận
 Tiến trình người dùng: một chương trình đang chạy
 Các tiến trình giao tiếp ntn?
 Trên một máy: IPC (inter-process communication)
 Giữa các máy trên mạng: Giao thức ứng dụng
◼ Socket
 Giao tiếp giữa các tiến trình trên mạng

 Socket: là một giao diện giữa

host or
tiến trình ứng dụng và tầng host or
server
giao vận server

 Socket được phân định bởi: controlled by

 Số hiệu cổng app developer
process process
 Địa chỉ IP
 Kiểu giao thức giao vận (TCP socket socket
hay UDP) TCP with TCP with
 Socket API (Application buffers, Internet buffers,
Programming Interface): variables variables
cho phép các tiến trình lựa
chọn tham số, lựa chọn dịch controlled by
vụ… OS
Các mô hình ứng dụng
 Mô hình Khách chủ
 Mô hình Peer 2 Peer
 Mô hình Lai
Mô hình khách chủ
 Khách
 Gửi yêu cầu truy cập dịch vụ
đến máy chủ
 Có thể có IP động hay vào mạng
không thường xuyên
 Không liên lạc trực tiếp với các
máy khách khác
 Chủ
 Thường xuyên online
 Địa chỉ IP tĩnh
 Có thể có máy chủ dự phòng
để nâng cao hiệu năng, phòng
sự cố
 e.g. Web, Mail, …
Mô hình Peer 2 Peer
 Không có máy chủ trung tâm
 Các máy có vai trò ngang
nhau
 Hai máy bất kỳ có thể liên lạc
trực tiếp với nhau
 Có thể có IP động, không cần
vào mạng thường xuyên
 E.g. Gnutella

 Độ linh hoạt cao nhưng khó quản

lý
Mô hình lai
 Một máy chủ trung tâm
để quản lý NSD, thông tin
tìm kiếm…
 Các máy khách sẽ giao
tiếp trực tiếp với nhau sau
khi đăng nhập
 E.g. Skype
 Máy chủ Skype quản lý các
phiên đăng nhập, mât khẩu
 Sau khi kết nối, các máy sẽ
gọi VoIP trực tiếp cho nhau
Addressing processes
 to receive messages,
process must have identifier
 host device has unique 32-
bit IP address
 Q: does IP address of host
on which process runs
suffice for identifying the
process?
 A:No, many processes
can be running on
same host
 identifier includes both IP
address and port numbers
associated with process on
host.
 Example port numbers:
 HTTP server: 80
 Mail server: 25
 to send HTTP message to
gaia.cs.umass.edu web
server:
 IP address: 128.119.245.12
 Port number: 80
 more shortly… 12
2.2 Web and HTTP

Lớp Application 13
Web and HTTP
First some jargon
 Web page consists of objects

 Object can be HTML file, JPEG image, Java applet, audio

file,…
 Web page consists of base HTML-file which includes several

referenced objects
 Each object is addressable by a URL

 Example URL:
www.someschool.edu/someDept/pic.gif

host name path name

HTTP overview

HTTP: hypertext transfer

protocol
 Web’s application layer protocol PC running
Explorer
 client/server model
 client: browser that requests,
receives, “displays” Web objects
 server: Web server sends Server
running
objects in response to requests Apache Web
 HTTP 1.0: RFC 1945 server

 HTTP 1.1: RFC 2068

Mac running
Navigator

15
HTTP overview (continued)
Uses TCP:
 client initiates TCP connection
(creates socket) to server, port 80
 server accepts TCP connection
from client
 HTTP messages (application-layer
protocol messages) exchanged
between browser (HTTP client)
and Web server (HTTP server)
 TCP connection closed
HTTP is “stateless”
 server maintains no
information about past
client requests
aside
Protocols that maintain “state” are
complex!
 past history (state) must be
maintained
 if server/client crashes, their
views of “state” may be
inconsistent, must be reconciled
16
 HTTP request message

 two types of HTTP messages: request, response

 HTTP request message:
 ASCII (human-readable format)

request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return, (extra carriage return, line feed)

line feed
indicates end
of message
HTTP request message: general format
Uploading form input
Post method:
 Web page often includes

form input URL method:

 Input is uploaded to server  Uses GET method

in entity body  Input is uploaded in URL

field of request line:

www.somesite.com/animalsearch?monkeys&banana

19
 Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 Opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu

2. Type in a GET HTTP request:

GET /~ross/ HTTP/1.1 By typing this in (hit carriage

Host: cis.poly.edu return twice), you send
this minimal (but complete)
GET request to HTTP server

3. Look at response message sent by HTTP server!

20
2.3 FTP

Lớp Application 21
FTP: the file transfer protocol

FTP file transfer

FTP FTP
user client server
interface
user
at host remote file
local file system
system

 transfer file to/from remote host

 client/server model
 client: side that initiates transfer (either to/from remote)

 server: remote host

 ftp: RFC 959

 ftp server: port 21

22
 FTP: separate control, data connections

 FTP client contacts FTP server at port TCP control connection

port 21
21, TCP is transport protocol
 client authorized over control
connection TCP data connection
FTP port 20 FTP
 client browses remote directory by client server
sending commands over control
connection.  server opens another TCP data
 when server receives file transfer connection to transfer another file.
command, server opens 2nd TCP  control connection: “out of band”
connection (for file) to client  FTP server maintains “state”:
 after transferring one file, server current directory, earlier
closes data connection. authentication

23
2.4 Electronic Mail

Lớp Application 24
 outgoing
Electronic Mail message queue
user mailbox

user
Three major components: agent
 user agents mail
user
server
 mail servers agent
 simple mail transfer protocol: SMTP SMTP
mail
server user
User Agent SMTP agent
 a.k.a. “mail reader”
SMTP
 composing, editing, reading mail user
mail
messages agent
server
 e.g., Eudora, Outlook, elm, Mozilla
Thunderbird user
agent
 outgoing, incoming messages stored user
on server agent

25
Electronic Mail: mail servers
user
Mail Servers agent
 mailbox contains incoming mail
user
messages for user server
agent
 message queue of outgoing (to SMTP
be sent) mail messages mail
server user
 SMTP protocol between mail SMTP agent
servers to send email messages
 client: sending mail server
SMTP
mail user
 “server”: receiving mail server agent
server

user
agent
user
agent

26
Electronic Mail: SMTP [RFC 2821]

 uses TCP to reliably transfer email message from client to server,

port 25
 direct transfer: sending server to receiving server
 three phases of transfer
 handshaking (greeting)

 transfer of messages

 closure

 command/response interaction
 commands: ASCII text

 response: status code and phrase

 messages must be in 7-bit ASCII

27
Scenario: Alice sends message to Bob

1) Alice uses UA to compose 4) SMTP client sends Alice’s

message and “to”
bob@someschool.edu
2) Alice’s UA sends message to her
mail server; message placed in
message queue
3) Client side of SMTP opens TCP
connection with Bob’s mail server
message over the TCP
connection
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent to
read message

1 mail
mail
server user
user server
2 agent
agent 3 6
4 5

28
Mail message format

SMTP: protocol for exchanging

email msgs header
blank
RFC 822: standard for text message
line
format:
 header lines, e.g.,
 To: body
 From:
 Subject:
different from SMTP commands!
 body
 the “message”, ASCII characters
only

29
Mail access protocols
access
user
SMTP SMTP protocol
agent
user
agent

sender’s mail receiver’s mail

server server

 SMTP: delivery/storage to receiver’s server

 Mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]

◼ authorization (agent <-->server) and download

 IMAP: Internet Mail Access Protocol [RFC 1730]
◼ more features (more complex)
◼ manipulation of stored msgs on server
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.

30
 POP3 protocol
S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
C: pass hungry
 client commands:
S: +OK user successfully logged on
 user: declare username
C: list
 pass: password
S: 1 498
 server responses S: 2 912
 +OK S: .
 -ERR
C: retr 1
S: <message 1 contents>
transaction phase, client: S: .
 list: list message numbers C: dele 1
 retr: retrieve message by C: retr 2
number S: <message 1 contents>
S: .
 dele: delete C: dele 2
 quit C: quit
S: +OK POP3 server signing off

31
2.5 DNS

Lớp Application 32
Domain Name
 Domain Name
 FQDN: Fully Qualified Domain Name
 Làtên của một máy tính hay của một mạng máy tính,
sử dụng tên (chữ cái, chữ số)
◼ www.uef.edu.vn
◼ www.vnexpress.net
◼ www.moet.gov.vn
Không gian tên miền
Tên và địa chỉ
 Trước khi truyền tin, máy trạm phải được xác định:
 Bởi một địa chỉ IP, hoặc
 Bởi một tên miền (thuận tiện cho NSD)
 Tên:
 Độ dài thay đổi
 Dễ nhớ cho con người
 Không liên quan tới vị trí vật lý của máy
 Địa chỉ:
 Độ dài cố định
 Dễ cho máy tính để xử lý
 Liên quan tói vấn đề chọn đường
Chuyển đổi địa chỉ

 Cơ chế cho phép tìm một địa chỉ IP từ một tên miền và ngược lại
 Máy chủ tên miền (DNS):
 Một phương thức được sử dụng để chuyển đổi địa chỉ
 Được sử dụng rộng rãi trên Internet
Chuyển đổi địa chỉ - ví dụ
Công cụ nslookup
 Nhập tham số www.hedspi.hut.edu.vn
 Chuyển đổi “Tên  Địa chỉ” được thực hiện
 Lệnh nslookup
 nslookup www.hedspi.hut.edu.vn
ARP: Chuyển đổi địa chỉ vật lý – địa chỉ IP

 Address Resolution Protocol

 Dùng để tìm địa chỉ vật lý từ địa chỉ IP

 Ví dụ ARP table
DNS: Domain Name System
People: many identifiers:
 SSN, name, passport #
Internet hosts, routers:
 IP address (32 bit) - used for
addressing datagrams
 “name”, e.g., ww.yahoo.com -
used by humans
Q: map between IP addresses
and name ?
Domain Name System:
 distributed database implemented in
hierarchy of many name servers
 application-layer protocol host,
routers, name servers to
communicate to resolve names
(address/name translation)
 note: core Internet function,
implemented as application-
layer protocol
 complexity at network’s “edge”
40
 DNS

DNS services Why not centralize DNS?

 hostname to IP address  single point of failure

translation  traffic volume

 host aliasing  distant centralized database

 Canonical, alias names  maintenance

 mail server aliasing
 load distribution doesn’t scale!
 replicated Web servers: set
of IP addresses for one
canonical name

41
Distributed, Hierarchical Database

Root DNS Servers

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

Client wants IP for www.amazon.com; 1st approx:

 client queries a root server to find com DNS server

 client queries com DNS server to get amazon.com DNS server

 client queries amazon.com DNS server to get IP address for

www.amazon.com
42
 DNS: Root name servers

 contacted by local name server that can not resolve name

 root name server:
 contacts authoritative name server if name mapping not known

 gets mapping

 returns mapping to local name server

a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD k RIPE London (also 16 other locations)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus
j Verisign, ( 21 locations) 28 other locations)
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
f Internet Software C. Palo Alto, Paris, SF)
CA (and 36 other locations)

13 root name servers

worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

43
Local Name Server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company, university) has
one.
 also called “default name server”
 when host makes DNS query, query is sent to its
local DNS server
 acts as proxy, forwards query into hierarchy
 DNS name resolution example
root DNS server
 Host at cis.poly.edu
wants IP address for
2
gaia.cs.umass.edu 3
TLD DNS server
iterated query: 4
 contacted server replies
5
with name of server to
contact local DNS server
 “I don’t know this name, dns.poly.edu
but ask this server” 1 8
7 6

authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu
45
gaia.cs.umass.edu
 DNS name resolution example
root DNS server
recursive query:
 puts burden of name
resolution on contacted 2 3
name server
 heavy load? 7 6
TLD DNS server

local DNS server

dns.poly.edu 5 4

1 8

authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu
DNS protocol, messages

DNS protocol : query and reply messages, both with same message format

msg header
 identification: 16 bit # for
query, reply to query uses
same #
 flags:
❖ query or reply
❖ recursion desired
❖ recursion available
❖ reply is authoritative

47
DNS protocol, messages

Name, type fields

for a query

RRs in response
to query

records for
authoritative servers

additional “helpful”
info that may be used

48
Summary
our study of network apps now complete!
 specific protocols:
 application architectures
❖ HTTP
 client-server ❖ FTP
 P2P ❖ SMTP, POP, IMAP
 hybrid ❖ DNS
 application service requirements: ❖ P2P: BitTorrent, Skype
 reliability, bandwidth, delay
 Internet transport service model
 connection-oriented, reliable: TCP
 unreliable, datagrams: UDP
Summary
Most importantly: learned about protocols
 typical request/reply Important themes:
message exchange:  control vs. data msgs
❖ in-band, out-of-band
 client requests info or service  centralized vs. decentralized
 server responds with data,  stateless vs. stateful
status code  reliable vs. unreliable msg transfer
 message formats:  “complexity at network edge”
 headers: fields giving info
about data
 data: info being
communicated

50