KHOA CÔNG NGHỆ SỐ

BỘ MÔN CÔNG NGHỆ THÔNG TIN

MẠNG MÁY TÍNH

GV: ThS NGUYỄN VĂN PHÁT

Application Layer 1
CHƯƠNG 2: TẦNG ỨNG DỤNG

Application Layer 2
 Chương 2: Tầng Application

 Các nguyên lý của ứng dụng mạng

 Web và HTTP
 Electronic Mail: SMTP, POP3, IMAP
 Domain Name System
 FTP
 Chia sẻ file P2P

Application Layer 3
Chương 2: Application
Mục tiêu:
 Khái niệm, các khía cạnh hiện thực của các giao thức
ứng dụng mạng
• Các mô hình dịch vụ lớp transport
• Mô hình client-server, mô hình peer-to-peer
 Nghiên cứu giao thức thông qua xem xét một số giao
thức lớp application
• HTTP, FTP, SMTP / POP3 / IMAP, DNS
 Lập trình ứng dụng mạng
• socket API
Application Layer 4
Một số ứng dụng mạng

• Mạng xã hội • Điện thoại Internet

• E-mail • Hội thảo video thời gian
• Web thực
• Tin nhắn nhanh • Tính toán lớn, song song
• Đăng nhập từ xa • Đăng nhập từ xa
• Chia sẻ file P2P
• Trò chơi nhiều người
trên mạng
• Streaming các video clips

Application Layer 5
Tạo một ứng dụng mạng
application
Chương trình: transport
mobile network
network
• chạy trên các hệ thống đầu cuối data link
physical
national or global ISP
khác nhau
• truyền thông qua mạng
• Ví dụ: Web: phần mềm Web server
truyền thông với phần mềm trình
duyệt local or
regional ISP

Phần mềm nhỏ viết cho các thiết

home network content
bị trung tâm mạng application
transport
provider
network network datacenter
applicationnetwork
• các thiết bị trung tâm mạng không data link transport
physical network
chạy các mã ứng dụng của người data link
physical
dùng
enterprise
• ứng dụng trên các hệ thống đầu network
cuối cho phép phát triển ứng dụng
nhanh, phổ biến Application Layer 6
Chương 2: Tầng Application
 Các nguyên lý của ứng dụng mạng
 Web và HTTP
 Electronic Mail: SMTP, POP3, IMAP
 Domain Name System
 FTP
 Chia sẻ file P2P

Application Layer 7
 Kiến trúc client-server
server:
mobile network
• host luôn hoạt động
national or global ISP
• địa chỉ IP cố định
• nhóm các server để chia sẻ
công việc
clients:
local or • truyền thông với server
regional ISP
• có thể kết nối không liên tục
home network content • có thể có địa chỉ IP thay đổi
provider
network datacenter
• không truyền thông trực tiếp
network
với client khác
• ví dụ: HTTP, IMAP, FTP
enterprise
network

Application Layer 8
 Kiến trúc Peer – Peer
• không có server luôn hoạt mobile network

động national or global ISP

• truyền thông trực tiếp với

hệ thống đầu cuối bất kỳ
• các điểm kết nối không local or
liên tục và thay đổi địa chỉ regional ISP

IP home network content

provider
• Ví dụ: p2p chia sẻ file network datacenter
network

Độ linh hoạt cao nhưng khó

quản lý
enterprise
network

Application Layer 9
Tiến trình truyền thông
Client/server
Tiến trình: chương trình Tiến trình Client: tiến
chạy bên trong 1 host. trình khởi tạo truyền
• trong cùng host, 2 tiến thông
trình truyền thông dùng Tiến trình Server: tiến
truyền thông nội bộ (do trình chờ để được tiếp
hệ điều hành xác định). xúc
• các tiến trình trong các
host khác nhau truyền • Chú ý: các ứng dụng
thông bằng cách trao với kiến trúc P2P có cả
đổi các thông điệp các tiến trình client và
server.
Application Layer 10
 Sockets

 các tiến trình gửi/nhận Host / host /

server server
các thông điệp đến/từ
socket của nó điều khiển
bởi người
process process
 socket tương tự như cửa phát triển
ứng dụng
socket socket
• tiến trình gửi đẩy thông TCP với TCP với
Internet
điệp ra ngoài cửa bộ đệm, bộ đệm,
các biến các biến
• tiến trình nhận phụ
thuộc vào hạ tầng lưu điều khiển
bởi hệ điều
thông mang thông điệp hành

đến socket thích hợp

Application Layer 11
Tiến trình định địa chỉ
• Để nhận được thông điệp, tiến trình phải có nhận dạng
(identifier)
• Thiết bị host phải có địa chỉ IP duy nhất
• Địa chỉ IP mà trên đó tiến trình đang chạy có đủ để nhận dạng
tiến trình?
• KHÔNG, nhiều tiến trình có thể chạy trên cùng 1 host
• Nhận dạng bao gồm cả địa chỉ IP và các số cổng (port) liên kết với
tiến trình trên host.
• Ví dụ về số port:
• HTTP server: 80
• Mail server: 25
• Để gửi thông điệp HTTP cho web server gaia.cs.umass.edu :
• IP address: 128.119.245.12
• Port number: 80 Application Layer 12
 Định nghĩa giao thức lớp ứng dụng
• Các kiểu của trao đổi thông Các giao thức mở:
điệp • Định nghĩa trong RFC
• Ví dụ: yêu cầu, đáp ứng
• Cho phép cộng tác
• Cú pháp thông điệp:
• Ví dụ: HTTP, SMTP
• Các trường nào trong thông
điệp và làm sao mô tả? Các giao thức độc quyền:

• Ngữ nghĩa thông điệp • Ví dụ: Sky, Zoom

• Ý nghĩa của thông tin trong
các trường
• Các quy tắc để khi nào và làm
sao các tiến trình gửi và đáp
ứng các thông điệp
Application Layer 13
Các ứng dụng yêu cầu gì ở tầng ứng dụng?
- Toàn vẹn dữ liệu
• một số ứng dụng (vd:
audio) có khả năng chịu lỗi
• các ứng dụng khác (vd:
truyền file, telnet) yêu cầu
dữ liệu tin cậy 100%
- Độ trễ
• một số ứng dụng (vd:
điện thoại Internet, trò
chơi tương tác) yêu cầu
độ trễ thấp để đạt hiệu
quả
- Bandwidth (băng thông)
• một số ứng dụng (vd:
đa phương tiện) yêu
cầu băng thông để đạt
hiệu quả
• các ứng dụng khác
mềm dẻo hơn có thể
dùng bất kỳ băng thông
nào cũng được
Application Layer 14
Yêu cầu đối với các ứng dụng phổ biến

Ứng dụng Mất dữ liệu Băng thông Nhạy cảm thời gian

Truyền file không mềm dẻo không

e-mail không mềm dẻo không
Web Không mềm dẻo không
audio/video chịu lỗi audio: 5kbps-1Mbps có, 100 mili giây
thời gian thực video:10kbps-5Mbps
audio/video đã lưu chịu lỗi Như trên có, một vài giây
Trò chơi tương tác chịu lỗi Một vài kbps có, 100 mili giây
Tin nhắn nhanh không mềm dẻo Có và không

Application Layer 15
Các dịch vụ giao thức trên internet
TCP (transmission control UDP (user datagram protocol):
protocol):
• truyền dữ liệu không tin cậy
• Kết nối có hướng: cần thiết
lập tiến trình giữa client và giữa gửi và nhận
server • Không hỗ trợ: thiết lập kết
• Truyền tải tin cậy: giữa tiến nối, tin cậy, điều khiển
trình gửi và nhận luồng, điều khiển tắc nghẽn,
• Điều khiển luồng: người gửi định thì, bảo đảm băng
sẽ không lấn át người nhận thông tối thiểu
• Điều khiển tắc nghẽn: điều
tiết người gửi khi mạng quá
tải Thế thì sinh ra UDP để làm gì?
• Không cung cấp/đảm bảo:
thời gian, bảo đảm băng
thông tối thiểu Application Layer 16
 Các giao thức lớp application, transport

Giao thức tầng Giao thức tầng

Ứng dụng ứng dụng truyển vận

Chuyển file/tải FTP [RFC 959] TCP

e-mail SMTP [RFC 5321] TCP
Web HTTP 1.1 [RFC 7320] TCP
Gọi internet SIP [RFC 3261], RTP [RFC 3550], TCP or UDP
hoặc độc quyền
streaming audio/video HTTP [RFC 7320], DASH TCP
Tương tác games WOW, FPS (độc quyền) UDP or TCP

Application Layer 17
Bảo mật TCP

TCP và UDP sockets TLS được triển khai trong tầng

• Không có mã hóa ứng dụng:
• Mật khẩu cleartext được gửi • Các ứng dụng sử dụng thư
vào socket truyền qua viện TLS
internet trong cleartext • TCP cleartext được mã hóa.
Bảo mật lớp transport (TLS)
• Cung cấp các kết nối TCP
được mã hóa
• Toàn vẹn dữ liệu
• Xác thực điểm cuối

Application Layer 18
Chương 2: Tầng Application

 Các nguyên lý của ứng dụng mạng

 Web và HTTP
 Electronic Mail: SMTP, POP3, IMAP
 Domain Name System
 FTP
 Chia sẻ file P2P

Application Layer 19
Web và HTTP
• Web page (trang Web) bao gồm các objects (đối
tượng), mỗi đối tượng có thể được lưu trữ trên các
máy chủ Web khác nhau
• Đối tượng: file HTML, hình ảnh JPEG image, Java
applet, file audio,…
• Trang Web file HTML cơ bản sẽ chứa một số đối
tượng có tham chiếu, mỗi đối tượng có thể xác định
địa chỉ bằng một URL
Ví dụ URL:
www.someschool.edu/someDept/pic.gif

Tên host Tên đường dẫn

Application Layer 20
 Tổng quan HTTP
HTTP: Hypertext Transfer Protocol

• Giao thức lớp ứng dụng của Web

• Mô hình client/server
PC running
• Client: trình duyệt yêu cầu, nhận Firefox browser
và hiển thị các đối tượng Web
• Server: Web server gửi các đối
tượng đáp ứng cho yêu cầu server running
Apache Web
• HTTP 1.0: RFC 1945 server
• HTTP 1.1: RFC 2068
iPhone running
• HTTP 2.0: RFC 7540
Safari browser

Application Layer 21
Tổng quan HTTP(tt)
Dùng TCP:
• Client khởi tạo kết nối TCP (tạo socket) đến server, port 80
• Server chấp nhận kết nối TCP từ client
• Các thông điệp HTTP (thông điệp giao thức lớp application) trao
đổi giữa trình duyệt (HTTP client) và Web server (HTTP server)
• Đóng kết nối TCP

HTTP là “không trạng thái”

• server không giữ thông tin về các yêu cầu trước đó của client

Application Layer 22
Kết nối HTTP

HTTP không ổn định HTTP ổn định

• Kết nối TCP được mở • Mở kết nối TCP tới server
• Nhiều nhất một đối • Nhiều đối tượng có thể
tượng được gửi qua được gửi qua một kết nối
kết nối TCP TCP duy nhất giữa khách
• Đóng kết nối TCP và chủ.
• Tải xuống nhiều đối • Đóng kết nối TCP
tượng yêu cầu nhiều
kết nối

Application Layer 23
 HTTP không bền vững
Giả sử user nhập vào URL như sau: (chứa text,
www.someSchool.edu/someDepartment/home.index
tham chiếu đến
10 hình)
1a. HTTP client khởi tạo kết nối TCP
connection đến HTTP server (tiến 1b. HTTP server tại host
trình) tại www.someSchool.edu www.someSchool.edu chờ kết nối
trên port 80 TCP tại port 80. “chấp nhận” kết nối,
thông báo cho client
2. HTTP client gửi HTTP thông điệp
yêu cầu (chứa URL) vào trong
socket kết nối TCP. Thông điệp chỉ 3. HTTP server nhận thông điệp yêu
rằng client muốn các đối tượng cầu, định dạng thông điệp đáp ứng
someDepartment/home.index chứa đối tượng được yêu cầu và
gửi thông điệp vào trong socket
của nó
Thời gian
Application Layer 24
 HTTP không bền vững(tt)

4. HTTP server đóng kết nối TCP.

5. HTTP client nhận thông điệp đáp

ứng chứa file HTML, hiển thị nó.
Phân tích cú pháp html file, tìm ra 1
tham chiếu đến đối tượng jpeg

Thời gian 6. Lặp lại các bước từ 1-5 cho các đối
tượng jpeg khác

Application Layer 25
 HTTP không bền vững: thời gian phản hồi
Định nghĩa RTT(Round Trip Times)
thời gian xoay vòng: thời gian
để gửi một gói nhỏ đi từ client
khởi tạo
đến server và quay lại. kết nối
TCP RTT
Thời gian phản hồi (mỗi đối
tượng): yêu cầu Thời
file gian
• Một RTT để khởi tạo kết nối TCP RTT truyền
file
• Một RTT cho yêu cầu HTTP và
một vài byte đầu tiên của đáp nhận file
ứng HTTP được trả về
• Thời gian truyền file Thời gian Thời gian

Tổng cộng = 2RTT+ Thời gian truyền file

Application Layer 26
 HTTP bền vững (HTTP 1.1)
Vấn đề với HTTP không bền vững:
• Yêu cầu 2 RTT mỗi đối tượng
• Hệ điều hành liên quan đến
mỗi kết nối TCP
• Các trình duyệt thường mở
song song các kết nối TCP để
đem về các tham chiếu đến
các đối tượng
HTTP bền vững (HTTP 1.1)
• server bỏ kết nối sau khi mở
để gửi đáp ứng leaves
• các thông điệp HTTP của
tiến trình con cùng mô hình
client/server gửi thông qua
kết nối mở
• client gửi yêu cầu ngay sau
khi gặp một đối tượng tham
chiếu
• Ít nhất một RTT cho tất cả
đối tượng tham chiếu
Application Layer 27
Thông điệp yêu cầu HTTP
• 2 kiểu message HTTP: resquest, response
• HTTP request message:

dòng yêu cầu

(các lệnh GET, POST, GET /somedir/page.html HTTP/1.1
HEAD) Host: www.someschool.edu
User-agent: Mozilla/4.0
các dòng Connection: close
header Accept-language:fr

Application Layer 28
 Thông điệp phản hồi HTTP

dòng trạng thái

(giao thức
mã trạng thái HTTP/1.1 200 OK
cụm từ trạng thái) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
các dòng
Last-Modified: Mon, 22 Jun 1998 …...
header
Content-Length: 6821
Content-Type: text/html

data data data data data ...

Dữ liệu, vd: file
HTML yêu cầu

Application Layer 29
Kiểm tra HTTP (phía client)

1. Telnet đến Web server ưa thích của bạn:

telnet cis.poly.edu 80 Mở kết nối TCP ở port 80
(port HTTP server mặc nhiên) tại cis.poly.edu.
Mọi thứ nhập vào gửi đến ở
port 80 tại cis.poly.edu

2. Nhập vào yêu cầu trong lệnh GET HTTP:

GET /~ross/ HTTP/1.1 Do đánh lệnh này (enter 2 lần), bạn
Host: cis.poly.edu đã gửi yêu cầu GET tối thiểu (nhưng
đầy đủ) đến HTTP server

3. Xem thông điệp đáp ứng gửi từ HTTP server!

Application Layer 30
 Duy trì trạng thái người dùng/máy chủ: cookies
Nhiều Web sites dùng cookies
4 thành phần:
1) cookie header line của thông
điệp đáp ứng HTTP
2) cookie header line của thông
điệp yêu cầu HTTP
3) cookie file lưu trong host của
user, quản lý bởi trình duyệt
của user
4) cơ sở dữ liệu back-end tại
Web site
Ví dụ:
• Susan truy cập Internet
luôn từ một PC
• Cô ấy lần đầu tiên vào
một e-commerce site xác
định
• Khi yêu cầu khởi tạo HTTP
đến site, site tạo một ID
duy nhất và tạo một điểm
đăng nhập trong cơ sở dữ
liệu back-end cho ID đó
Application Layer 31
Duy trì trạng thái người dùng/máy chủ: 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
 Cookies (tt)
Các cookie đem lại: ngoài ra
• sự cấp phép Cookies và sự riêng tư:
• cookies cho phép các site
• giỏ mua hàng
biết nhiều hơn về bạn
• các khuyến cáo • bạn có thể cung cấp tên
• trạng thái phiên làm việc và e-mail cho sites
của user (Web e-mail)
Làm thế nào để giữ “trạng thái”:
• các thời điểm kết thúc giao
thức: bảo trì trạng thái tại
sender/receiver thông qua
nhiều giao tác
• cookies: trạng thái mang các
thông điệp http
Application Layer 33
 Web caches
Mục tiêu: thỏa mãn yêu cầu của client không cần liên quan
đến server nguồn

 user thiết lập trình duyệt:

truy cập Web thông qua Web
cache
cache client
Server
 trình duyệt gửi tất cả yêu nguồn
cầu HTTP cho cache
• đối tượng trong cache:
cache trả về đối tượng
• ngược lại cache yêu cầu client
đối tượng từ server
nguồn, sau đó trả về cho
client
Application Layer 34
Web caches (tt)
• Cache hoạt động tại client Tại sao dùng Web caching?
và server
• Giảm thời gian đáp ứng
• Máy chủ thông báo cho bộ cho yêu cầu của client
nhớ cache về bộ nhớ đệm
• Giảm lưu thông trên liên
được phép của đối tượng
kết truy cập
trong tiêu đề phản hồi:
• Internet rất ngờ nghệch với
caches: cho phép những
người cung cấp nội dung
• Tiêu biểu cache được cài nghèo nàn phân phát hiệu
đặt bởi ISP (trường học, quả nội dung đó.
công ty, ISP riêng)
Application Layer 35
 Ví dụ caching
Giả sử servers
• kích thước trung bình đối tượng= nguồn
100,000 bits Internet
công cộng
• tốc độ trung bình yêu cầu từ trình
duyệt đến server = 15/s
• độ trễ từ router nơi gửi yêu cầu
đến server nguồn rồi quay lại = 2 s 1.5 Mbps
liên kết truy cập
Kết quả network gửi
• độ khả dụng của LAN = 15% yêu cầu
10 Mbps LAN
• độ khả dụng trên liên kết truy cập=
100%
• tổng thời gian trễ = trễ Internet + cache nơi
trễ truy cập+ trễ LAN = 2 s + các gửi yêu cầu
phút+ mili s
Application Layer 36
Ví dụ caching(tt)
servers
Giải pháp có thể nguồn
• tăng băng thông truy cập lên, Internet
ví dụ 10 Mbps công cộng

Kết quả
• độ khả dụng của LAN = 15%
10 Mbps
• độ khả dụng trên liên kết truy liên kết truy cập
cập = 15% network gửi
yêu cầu
• tổng thời gian trễ = trễ 10 Mbps LAN

Internet + trễ truy cập+ trễ

LAN = 2 s + mili s + mili s
• thường tăng chi phí cache nơi gửi
yêu cầu

Application Layer 37
Ví dụ caching(tt)
cài đặt cache servers
nguồn
• tốc độ hỗ trợ là 0.4
Internet
kết quả công cộng
• 40% yêu cầu sẽ được thỏa
mãn hầu như ngay lập tức
• 60% yêu cầu sẽ được thỏa 1.5 Mbps
mãn bởi server nguồn liên kết truy cập

• độ khả dụng trên liên kết truy network

gửi yêu cầu
cập giảm đến 60%, do trễ 10 Mbps LAN
không đáng kể (vd 10 mili s)
• tổng thời gian trễ = trễ
Internet + trễ truy cập+ trễ cache nơi
LAN = 0.6*(2.01) s + 0.4*mili gửi yêu cầu
s < 1.4 s
Application Layer 38
 GET có điều kiện
client server

• Mục tiêu: không gửi đối

tượng nếu cache đã cập nhật HTTP request msg
Đối tượng
If-modified-since: <date>
không
• cache: xác định ngày của bản
sửa đổi
sao cache trong yêu cầu HTTP response
HTTP/1.0
HTTP: 304 Not Modified

If-modified-since: <date>
• server: đáp ứng không chứa
HTTP request msg
đối tượng nếu bản sao cache If-modified-since: <date> Đối tượng
đã cập nhật: Có
HTTP response sửa đổi
HTTP/1.0 304 Not Modified HTTP/1.0 200 OK
<data>
39
 Chương 2: Lớp Application
 Các nguyên lý của ứng dụng mạng
 Web và HTTP
 Electronic Mail: SMTP, POP3, IMAP
 Domain Name System
 FTP
 Chia sẻ file P2P

Application Layer 40
E-mail

3 thành phần quan trọng: user

agent
user agents mail user
mail servers server agent

simple mail transfer protocol: SMTP SMTP mail user

server agent
SMTP
User Agent user
SMTP
Còn gọi là “mail reader” mail agent
server
viết, sửa đổi, đọc các thông điệp mail user
agent
Ví dụ: Eudora, Outlook, elm, Netscape user
Messenger agent
outgoing
message queue
các thông điệp đi và đến được lưu trên user mailbox
server
E-mail: mail servers
Mail servers: user
agent
mailbox chứa các thông đến mail user
đến user. server agent

Hàng đợi thông điệp cho các SMTP mail user

server agent
thông điệp email ra ngoài SMTP
(chuẩn bị gửi) user
SMTP agent
Giao thức SMTP giữa các mail mail
server
servers để gửi các thông điệp user
agent
email user
 client: mail server gửi agent
outgoing
message queue
 “server”: mail server nhận user mailbox
 SMTP RFC (5321)
“client” “server”
SMTP server SMTP server
 dùng TCP để truyền tin cậy thông
điệp email từ client đến server trên
port 25 initiate TCP
 truyền trực tiếp: server gửi đến connection
server nhận TCP connectionRTT
initiated
 3 kênh truyền
• bắt tay (chào hỏi)
220
• truyền thông điệp
SMTP HELO
• đóng handshaking
 tương tác lệnh/phản hồi 250 Hello

• lệnh: văn bản ASCII

• phản hồi: mã trạng thái và cụm SMTP
transfers
time 43
Tình huống: Alice gửi cho Bob
1) Alice dùng UA viết thông điệp và
“gửi đến”
bob@someschool.edu
2) UA của Alice gửi thông điệp của
cô ấy đến mail server; thông
điệp được gia nhập vào hàng đợi
3) Phía Client của SMTP mở kết nối
TCP với mail server của Bob
4) SMTP client gửi thông điệp của
Alice trên kết nối TCP
5) mail server của Bob đặt thông
điệp vào hộp thư của Bob
6) Bob kích hoạt trình user agent
đọc thông điệp

1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server

Application Layer 44
Thử nghiệm tương tác SMTP:

• telnet servername 25
• thấy 220 trả lời từ server
• nhập các lệnh HELO, MAIL FROM, RCPT TO, DATA, QUIT

Application Layer 45
SMTP: quan sát
• SMTP dùng các kết nối ổn
định
• SMTP yêu cầu các thông điệp
(header & body) phải ở dạng
thức 7-bit ASCII
• SMTP server dùng CRLF.CRLF
xác định kết thúc thông điệp
So sánh với HTTP:
• HTTP: kéo
• SMTP: đẩy
• tất cả đều có tương tác
lệnh/đáp ứng, các mã trạng
thái ASCII
• HTTP: mỗi đối tượng được
đóng kín trong thông điệp
đáp ứng của nó
• SMTP: nhiều đối tượng được
gửi trong thông điệp nhiều
phần
Application Layer 46
Định dạng thông điệp email

SMTP: giao thức cho trao đổi các

thông điệp email header
dòng
RFC 2822: chuẩn cho dạng thức
văn bản: trống
• các dòng header, ví dụ:
• To:
• From:
body
• Subject:
khác với các lệnh SMTP!
• body
• “thông điệp”, chỉ có các ký tự
ASCII

Application Layer 47
Các giao thức truy cập email
user
e-mail access user
SMTP SMTP protocol
agent agent
(e.g., IMAP,
HTTP)

sender’s e-mail receiver’s e-mail

server server

 SMTP: truyền dẫn/lưu trữ vào server của người nhận

 Giao thức truy cập email: trích xuất từ server
• POP: Post Office Protocol [RFC 1939]
• cấp phép (agent <--> server) và download
• IMAP: Internet Mail Access Protocol [RFC 3501]
• nhiều tính năng (phức tạp hơn)
• điều khiển các thông điệp đã lưu trên server
• HTTP: Hotmail , Yahoo! Mail,…
Application Layer 48
Giao thức POP3
S: +OK POP3 server ready
C: user bob
giai đoạn cấp phép S: +OK
C: pass hungry
• các lệnh phía client: S: +OK user successfully logged on
• user: khai báo username
C: list
• pass: password S: 1 498
• các đáp ứng phía server S: 2 912
• +OK S: .
C: retr 1
• -ERR S: <message 1 contents>
giai đoạn giao dịch, client: S: .
C: dele 1
• list: liệt kê các số thông điệp C: retr 2
• retr: khôi phục lại thông điệp theo số S: <message 1 contents>
S: .
• dele: xóa C: dele 2
• quit C: quit
S: +OK POP3 server signing off
Application Layer 49
POP3 và IMAP
Nghiên cứu thêm về POP3
• Ví dụ trước dùng chế độ
“download và xóa”.
• Bob không thể đọc lại email
nếu thay đổi client
• “Download và giữ”:sao chép
các thông điệp trên các
client khác nhau
• POP3 không giữ trạng thái
của các phiên làm việc
IMAP
• Giữ tất cả thông điệp tại 1
vị trí: server
• Cho phép user tổ chức các
thông điệp theo dạng thư
mục
• IMAP giữ trạng thái xuyên
suốt các phiên làm việc:
• các tên của thư mục và ánh
xạ giữa ID của thông điệp và
tên thư mục
Application Layer 50
 Chương 2: Lớp Application
 Các nguyên lý của ứng dụng mạng
 Web và HTTP
 Electronic Mail: SMTP, POP3, IMAP
 Domain Name System
 FTP
 Chia sẻ file P2P

Application Layer 51
DNS: Domain Name System
Con người: nhiều cách nhận
dạng:
• SSN, tên, #hộ chiếu
Internet hosts, routers:
• địa chỉ IP (32 bit) dùng
cho các gói định địa chỉ
• “tên”, ví dụ: cs.umass.edu
– dùng bởi con người
Ánh xạ giữa địa chỉ IP và tên?
Domain Name System:
• cơ sở dữ liệu phân bố hiện
thực theo tổ chức phân cấp
của nhiều servers tên
• giao thức lớp application
host, routers, name servers
để truyền thông với các tên
phân giải (địa chỉ/dịch ra tên)
• lưu ý: chức năng lõi
Internet, hiện thực như
giao thức lớp application
• phức tạp ở “biên” mạng
Application Layer 52
 DNS: dịch vụ, cấu trúc

Các dịch vụ DNS Tại sao không tập trung hóa

• Tên Host chuyển thành địa DNS?
chỉ IP • một điểm chịu lỗi
• Bí danh Host • lưu lượng
• các tên đúng chuẩn và bí danh • khoảng cách cơ sở dữ liệu tập
• Bí danh Mail server trung
• Tải phân bố • bảo trì
• Các Web server bản sao: tập
các địa chỉ IP cho 1 tên đúng
chuẩn không linh hoạt!

Application Layer 53
 Cơ sở dữ liệu phân tán, phân cấp
Root DNS Servers Root
… …
.com DNS servers .org DNS servers .edu DNS servers
Top Level Domain
… … … …
yahoo.com amazon.com pbs.org nyu.edu umass.edu Authoritative
DNS servers DNS servers DNS servers DNS servers DNS servers

Client muốn IP cho www.amazon.com:

• Client hỏi một server gốc (root) để tìm com DNS server
• Client hỏi com DNS server để lấy amazon.com DNS server
• Client hỏi amazon.com DNS server để lấy địa chỉ IP của
www.amazon.com
54
 DNS: root name server
• Các máy chủ tên miền cục bộ sẽ liên hệ máy chủ gốc nếu chúng
không thể tự phân giải tên miền.
• Server tên miền gốc:
• tiếp xúc server tên có thẩm quyền nếu ánh xạ tên không xác định
• lấy ánh xạ, trả về ánh xạ đến server tên cục bộ
• ICANN(Internet Corporation for Assigned Names and Numbers):
quản lý root DNS domain
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD k RIPE London (also Amsterdam,
g US DoD Vienna, VA Frankfurt)
h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3
j Verisign, ( 11 locations) other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)

13 name servers
gốc trên toàn cầu
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

55
 TLD và thẩm quyền server
• Các server Top-level domain (TLD) : chịu trách nhiệm
cho tên miền com, org, net, edu,… và các tên miền
quốc gia như uk, fr, ca, jp.
• Lĩnh vực giáo dục cho edu TLD

• Các DNS server có thẩm quyền: DNS server của tổ

chức, cung cấp các tên host có thẩm quyền để ánh xạ
IP cho server (ví dụ: Web và mail).
• Không thể duy trì bởi tổ chức hoặc người cung cấp dịch vụ
56
DNS name server cục bộ

 không phụ thuộc một cách rõ ràng vào hệ thống

phân cấp
 mỗi ISP (ISP dân sự, cơ quan, trường học) có một
máy chủ tên miền cục bộ.
• còn được gọi là “máy chủ tên miền mặc định”
 khi một máy thực hiện một truy vấn DNS, truy vấn sẽ
được gửi cho máy chủ DNS cục bộ của nó
• hoạt động như là một máy đại diện(proxy), chuyển tiếp
truy vấn lên hệ phân cấp

57
 DNS name resolution: truy vấn lặp
root DNS server
Ví dụ
• Host tại engineering.nyu.edu
muốn địa chỉ IP cho 2
3
gaia.cs.umass.edu TLD DNS server
1 4

8 5

requesting host at local DNS server

engineering.nyu.edu dns.nyu.edu
gaia.cs.umass.edu
7 6
Truy vấn lặp:
 máy chủ được liên hệ trả về tên của authoritative DNS server
dns.cs.umass.edu
máy chủ khác để liên hệ tiếp
 “Tôi không biết tên miền này, nhưng
hãy hỏi máy chủ này xem”
58
 DNS name resolution: truy vấn đệ quy
Truy vấn đệ quy:
 Giao toàn toàn bộ
phân giải tên cho root DNS server
server tên đã tiếp
xúc được 2 3
 tải quá nặng? 7 6
1 TLD DNS server

8
requesting host at local DNS server 4
engineering.nyu.edu dns.nyu.edu 5
gaia.cs.umass.edu

authoritative DNS server

dns.cs.umass.edu
59
 Caching DNS Information
 một khi (bất kỳ ) name server học cách ánh xạ, nó lưu trữ ánh xạ
vào bộ nhớ cache và ngay lập tức trả về một ánh xạ được lưu
trong bộ nhớ cache để phản hồi lại một truy vấn.
• cải thiện thời gian phản hồi
• các thông tin trong bộ nhớ đệm sẽ hết hạn và bị xóa sau một
thời gian nhất định (TTL)
• TLD servers điển hình sẽ được cache trong các server tên cục
bộ. Do đó server tên gốc sẽ không thường xuyên được truy cập
 các mục nhập được lưu trong bộ cache có thể đã hết hạn
• nếu máy chủ có tên thay đổi địa chỉ IP, có thể không được biết
đến trên toàn Internet cho đến khi tất cả các TTL hết hạn!

60
DNS records
DNS: cơ sở dữ liệu phân bố lưu trữ các record tài nguyên
(Resource Record)
Định dạng RR: (name, value, type, ttl)
Type=A Type=CNAME
• name là tên host • name là bí danh của tên
• value là địa chỉ IP “chuẩn” (tên thực).
Type=NS • www.ibm.com là tên thực

• name là tên miền (vd:

servereast.backup2.ibm.com
foo.com) • value là tên chuẩn

• value là tên host của server Type=MX

tên có thẩm quyền cho tên • value là tên của email server
miền này liên kết với name
61
 DNS protocol messages
DNS: các thông điệp truy vấn và trả lời, cả hai có cùng định dạng
thông điệp 2 bytes 2 bytes

header thông điệp identification flags

 identification: 16 bit # # questions # answer RRs
cho truy vấn, trả lời cho
# authority RRs # additional RRs
truy vấn dùng cùng #
 flags: questions (variable # of questions)
• truy vấn hoặc trả lời
đệ quy mong chờ answers (variable # of RRs)

• đệ quy sẵn sàng

authority (variable # of RRs)
• trả lời được cấp phép

additional info (variable # of RRs)

62
 DNS protocol messages
2 bytes 2 bytes

identification flags

các trường Name, # questions # answer RRs

type cho 1 truy vấn # authority RRs # additional RRs

các RR trong đáp questions (variable # of questions)

ứng cho truy vấn
answers (variable # of RRs)
các record cho các
server có thẩm quyền authority (variable # of RRs)
thông tin “hữu ích”
bổ sung có thể sẽ additional info (variable # of RRs)

dùng

63
 Chương 2: Lớp Application
 Các nguyên lý của ứng dụng mạng
 Web và HTTP
 Electronic Mail: SMTP, POP3, IMAP
 Domain Name System
 FTP
 Chia sẻ file P2P

Application Layer 64
FTP: giao thức truyền file
FTP : File Transfer Protocol

giao diện file transfer

FTP FTP
FTP client server
user
user
tại host hệ thống file hệ thống
cục bộ file từ xa

• truyền file đến/từ host từ xa

• mô hình client/server
• client: phía khởi tạo truyền (đến/từ host ở xa)
• server: host ở xa
• ftp: RFC 959
• ftp server: port 21
Application Layer 65
 FTP: kết nối, điều khiển
kết nối điều khiển TCP
• FTP client tiếp xúc FTP server tại port port 21
21, xác định TCP như giao thức
transport
kết nối dữ liệu TCP
• Client nhận giấy phép thông qua kết FTP port 20 FTP
nối điều khiển client server
• Client xem thư mục ở xa bằng việc
gửi các lệnh thông qua kết nối điều  Server mở kết nối dữ liệu TCP khác
khiển. để truyền file khác
• Khi server nhận lệnh truyền file,  Điều khiển kết nối: “out of band”
server mở kết nối TCP thứ 2 (cho  FTP server giữ lại “trạng thái”: thư
file) đến client mục hiện hành, giấy phép trước đó
• Sau khi truyền 1 file, server đóng kết
nối dữ liệu

Application Layer 66
Các lệnh, phản hồi FTP
Ví dụ các lệnh:
• gửi như văn bản ASCII trên kênh
điều khiển
• USER username
• PASS password
• LIST trả về danh sách của file
trong thư mục hiện hành
• RETR filename trích chọn (lấy)
file
• STOR filename lưu (đặt) file vào
trong host ở xa
Ví dụ mã trả về
• mã trạng thái và cụm (như
HTTP)
• 331 Username OK, password
required
• 125 data connection already
open; transfer starting
• 425 Can’t open data connection
• 452 Error writing file
Application Layer 67
 Chương 2: Lớp Application
 Các nguyên lý của ứng dụng mạng
 Web và HTTP
 Electronic Mail: SMTP, POP3, IMAP
 Domain Name System
 FTP
 Chia sẻ file P2P

Application Layer 68
 Kiến trúc Peer-to-peer (P2P)
 Máy chủ hoạt động không thường
xuyên
 Những hệ thống cuối tùy ý giao tiếp mobile network
trực tiếp national or global ISP

 Các peer yêu cầu dịch vụ từ các peer

khác, cung cấp dịch vụ để trả lại các
peer khác.
local or
• Khả năng tự mở rộng – các peer mới regional
ISP
mang lại khả năng dịch vụ mới và home network content
nhu cầu dịch vụ mới. provider
network datacenter
network
 Các peer được kết nối không liên tục
và thay đổi IP.
enterprise
• Quản lý phức tạp network

 Ví dụ: P2P chia sẻ file (BitTorrent),

phát trực tuyến (KanKan), VoIP
(Skype) Application Layer: 2-69
Phân phối file: client-server và P2P

Q: Bao nhiêu thời gian để phân phối tệp (kích thước F) từ một
server đến N peer?
• Khả năng upload/download của peer là tài nguyên hạn chế

us: khả năng tải

lên của server
di: khả năng tải về
file, size F u1 d1 u2 peer i
us d2
server
di
uN Mạng (với băng thông
dồi dào) ui
dN
ui: khả năng tải lên
peer i

Application Layer: 70
 Thời gian phân phối file: client-server
 Server truyền: phải tuần tự gửi (tải
lên) N bản sao file:
• Thời gian gửi một bản sao: F/us
• Thời gian gửi một N bản sao : NF/us F
us
di
 client: mỗi client phải tải xuống network
ui
bản sao file:
• dmin = tỉ lệ client tải xuống tối thiếu
• Thời gian tải xuống client tối thiểu: F/dmin

Thời gian để phân phối F

cho N client Dc-s > max{NF/us,,F/dmin}
sử dụng client – server

Application Layer 71
 Thời gian phân phối file: P2P
 server truyền: phải tải lên ít nhất một bản sao:
• Thời gian gửi một bản sao: F/us
F
 client: mỗi client phải tải xuống một file us
di
• Thời gian tải xuống client tối thiếu: network
ui
F/dmin

 clients: là toàn bộ phải tải xuống NF bits

• Tỉ lệ tải lên cao tối đa (giới hạn tỉ lệ tải xuống tối đa) is us + Sui

Thời gian để phân phối F

cho N client DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
sử dụng P2P

Application Layer: 72
Client-server và P2P
Ví dụ:
client upload rate = u, F/u = 1 hour,
3.5 u = 10u, d
s min ≥ us
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

Application Layer 73
P2P phân phối file: BitTorrent

 file được chia thành các mảnh (chunks) 256Kb

 peers trong torrent gửi/nhận các mảnh files

tracker: theo dõi các peer

tham gia trên torent torrent: nhóm các peer
trao đổi các mảnh của 1 file

Alice đến …
… lấy danh sách các peer
từ tracker
… và bắt đầu trao đổi các
mảnh file với các peer
trong torent

Application Layer 74
 P2P phân phối file: BitTorrent(tt)
 Peer tham gia torent:
• Không có mảnh, nhưng sẽ tích lũy
theo thòi gian từ các peer khác.
• Đăng ký với tracker để nhận danh
sách các peer kết nối với tập hợp
con của các peer (hàng xóm)
 Trong khi tải xuống, peer tải lên các mảnh cho các peer khác
 Rời đi: peers có thể đến hoặc đi
 Mỗi khi peer có toàn bộ file, nó có thể (ích kỷ) rời đi hoặc ở lại
(vị tha) trong torrent

Application Layer: 75
BitTorrent: yêu cầu, gửi các mảnh file

Yêu cầu các mảnh: Gửi các mảnh:

 Tại bắt kỳ thời điểm nào,  Alice gửi các mảnh cho các
các peer khác nhau có peer với tỉ lệ cao nhất
các tập con khác nhau • Các peer không nhận được
của các mảnh file. sẽ đánh giá lại sau 10 giây
 Định kỳ, Alice hỏi từng  Sau 30 giây: chọn ngẫu nhiên
peer về danh sách của một peer khác, bắt đầu gửi
các mảnh mà họ có các mảnh.

 Alice yêu cầu các phần bị

thiếu từ các peer.

Application Layer: 76