CN2019 Chapter2 Application Layer (VIE Final)

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

KHOA CÔNG NGHỆ THÔNG TIN
Môn học (3TC):

MẠNG MÁY TÍNH
Lớp INT 2209-4&5&6 (K62 CNTT)
Chương 2 Tầng ứng dụng
PGS. TS. Nguyễn Đình Việt

Hà nội – 2019
Chapter 2
Application Layer
A note on the use of these ppt slides:

We‟re making these slides freely available to all (faculty, students, readers). Computer
They‟re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs. Networking: A Top
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Down Approach
 If you use these slides (e.g., in a class) that you mention their source (after 6th edition
all, we‟d like people to use our book!)
 If you post any slides on a www site, that you note that they are adapted
Jim Kurose, Keith Ross
from (or perhaps identical to) our slides, and note our copyright of this Addison-Wesley
material.
March 2012
Thanks and enjoy! JFK/KWR
All material copyright 1996-2012

J.F Kurose and K.W. Ross, All Rights Reserved
2-2
Các nội dung chính của chương 2
2.1 Các nguyên lý của ứng dụng mạng

2.2 Web và HTTP
2.3 Giao thức truyền file FTP
2.4 Electronic mail
 SMTP, POP3, IMAP
2.5 DNS – Dịch vụ danh bạ của Internet
2.6 Các ứng dụng ngang hàng - P2P
2.7 Lập trình socket với UDP và TCP
Chương 2, Mạng máy tính INT2209-4&5&6, HK1 2018-2019. PGS. TS. Nguyễn Đình Việt 2-3
Chương 2: tầng ứng dụng
Mục tiêu:
 Các khái niệm, khía cạnh về  Nghiên cứu (learn) về các
thi hành (implementation) giao thức bằng việc khảo sát
các giao thức ứng dụng các giao thức tầng ứng dụng
mạng  HTTP
 Các mô hình dịch vụ của  FTP
tầng transport  SMTP / POP3 / IMAP
 Mô hình (paradigm)  DNS
client-server  Việc tạo ra các ứng dụng
 Mô hình ngang hàng mạng
(peer-to-peer)  Socket API
Các ứng dụng mạng chính là lý do tồn tại của mạng
Một số ứng dụng mạng phổ biến:
 E-mail  Voice over IP (e.g., Skype)

 Web  Real-time video
 Text messaging (gửi tin conferencing (Hội thảo
nhắn text) video thời gian thực)
 Đăng nhập từ xa (remote  Social networking (Kết nối
login) mạng xã hội)
 Chia sẻ file ngang hàng  Search (tìm kiếm)
(P2P file sharing)  …
 Multi-user network games  …
 Streaming stored video
(YouTube, Hulu, Netflix)
Việc tạo ra các ứng dụng mạng
application
transport
Đó là việc viết các chương trình:

network
data link
physical
 Chạy trên các end system khác
National or
nhau Global ISP
 Truyền thông với nhau qua mạng
 Thí dụ: phần mềm web server Mobile network
truyền thông với phần mềm trình
duyệt (browser )
Home network Local or
Không cần phải viết phần mềm Regional
ISP
cho các thiết bị lõi mạng application
 Các thiết bị lõi mạng không chạy transport
network
các ứng dụng của người sử dụng data link
physical
application
transport
 Các ứng dụng trên end systems cho network
data link
phép phát triển và truyền bá ứng physical
dụng nhanh chóng

Interprise network
… 2.1 Các nguyên lý của ứng dụng mạng
2.1.1 Các kiến trúc ứng dụng mạng
Các kiến trúc có thể của các ứng dụng:

 Client-server
 Peer-to-peer (P2P)
Kiến trúc client-server
Server:
 Là host luôn luôn bật
National or
(always-on host)
Global ISP
 Có địa chỉ IP cố định
Mobile network
 Các trung tâm dữ liệu để mở
rộng (scaling)
Local or
Regional ISP
Clients:
Home network
 Truyền thông với server
client/server  Có thể kết nối không liên tục
 Có thể có địa chỉ IP động
 Không truyền thông trực tiếp
với nhau
Interprise network
Kiến trúc P2P
 Không có server luôn luôn bật peer-peer

(always-on)
 Các end systems bất kỳ có thể
truyền thông trực tiếp với nhau
 Các peers có thể yêu cầu dịch vụ
từ các peer khác, ngược lại cũng
cung cấp dịch vụ cho các peer
khác
 Self scalability (tính tự mở rộng) –
các peers mới sẽ đem lại dung
lượng (capacity) dịch vụ mới, cũng
như yêu cầu dịch vụ mới
 Các peers kết nối không liên
tụcvà thay đổi địa chỉ IP
 Quản lý phức tạp
2.1.2 Việc truyền thông của các tiến trình
Process: là chương trình Clients, servers

chạy trong một host Client process: tiến trình
 Hai tiến trình chạy trên một khởi tạo (initiates) việc
host truyền thông với nhau truyền thông
bằng việc sử dụng inter-
process communication Server process: Tiến trình
(được định rõ bởi OS) chờ để được tiếp xúc
 Các tiến trình trên các host
 Ngoài ra: Các ứng dụng với
khác nhau truyền thông với
kiến trúc P2P có các tiến
nhau bằng việc trao đổi
trình client và các tiến trình
messages (bản tin)
server
… 2.1.2 Việc truyền thông của các tiến trình
Sockets
 Một tiến trình gửi/nhận các bản tin (messages) đến/từ (to/from) socket
của nó. Socket là giao diện của các phần mềm bên trong một host,
tương tự như cái cửa (door).
 Socket còn có tên gọi là – API (Application Programming Interface)
 Tiến trình gửi đẩy bản tin ra khỏi cửa
 Tiến trình gửi dựa vào hạ tầng giao vận ở phía ngoài cửa sẽ phân phát
bản tin đến socket tại tiến trình nhận.
application application
socket controlled by
process process app developer
transport transport
network network controlled
link by OS
link Internet
physical physical
… 2.1.2 Việc truyền thông của các tiến trình
Đánh địa chỉ các tiến trình
 Để nhận các bản tin, tiến  identifier bao gồm cả IP
trình phải có cái định danh address và port numbers gắn
(identifier) với tiến trình chạy trên host.
 Thiết bị host có địa chỉ IP  Thí dụ một số port numbers:
32-bit duy nhất  HTTP server: 80
 Q: Việc host trên đó tiến  mail server: 25
trình chạy có địa chỉ IP đã là  Để gửi bản tin HTTP tới
đủ để định danh tiến trình gaia.cs.umass.edu web server:
hay chưa?  IP address: 128.119.245.12
 A: Chưa, vì nhiều tiến
 port number: 80
trình có thể đang cùng  Sẽ có thêm nhiều thí dụ nữa…
chạy trên cùng một host  Danh sách port đã xác định:
 http://
Giao thức tầng ứng dụng định nghĩa:
 Loại bản tin được trao đổi, Các giao thức mở:
 Thí dụ: request, response  Được định nghĩa trong
 Cú pháp (syntax) của bản tin: RFCs
 Cho biết các trường (fields)  Cho phép cùng hoạt động
trong bản tin & Các trường (interoperability)
được mô tả ntn  Thí dụ: HTTP, SMTP
 Ngữ nghĩa (semantics) của bản Các giao thức có bản quyền
tin (proprietary):
 Ý nghĩa của thông tin trong 
các trường
 Các quy tắc (rules) về việc các
tiến trình gửi & hồi đáp các
bản tin khi nào và như thế nào
2.1.3 Các dịch vụ vận chuyển có sẵn cho các ứng dụng
Một ứng dụng cần dịch vụ vận chuyển làm gì:
Tính toàn vẹn (integrity) dữ liệu: Thông lượng (throughput)

 Một số ứng dụng (thí dụ:  Một số ứng dụng (thí dụ:
truyền file, giao dịch web multimedia) đòi hỏi phải có
(web transactions) đòi hỏi việc một thông lượng tối thiểu
truyền dữ liệu tin cậy 100% thì mới là “hiệu quả”
 Các ứng dụng khác (thí dụ:  Các ứng dụng “mềm dẻo”
audio) có thể khoan thứ khác (“elastic apps”) sử
(tolerate) một tỉ lệ mất mát dụng bất cứ thông lượng
nhất định nào mà nó có
Kịp thời (timing): An ninh (security)
 Một số ứng dụng (thí dụ: điện
 Encryption, data integrity,
thoại Internet, trò chơi tương
…
tác) đòi hỏi độ trễ thấp thì mới
là “hiệu quả” (“effective”)
… 2.1.3 Các dịch vụ vận chuyển có sẵn cho các ứng dụng
Các yêu cầu đối với dịch vụ vận chuyển: Các ứng dụng nói chung
application data loss throughput time sensitive
file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100‟s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100‟s msec
text messaging no loss elastic yes and no
2.1.4 Các dịch vụ của giao thức vận chuyển Internet:
Dịch vụ TCP: UDP service:

 Hướng kết nối (connection-oriented):  Không hướng nối (connectionless)
cần thiết lập (kết nối) giữa các tiến  Vận chuyển không tin cậy
trình client & server (unreliable data transfer) giữa tiến

 Vận chuyển tin cậy (reliable trình gửi và tiến trình nhận
transport) giữa tiến trình gửi và tiến  Không điều khiển lưu lượng và
trình nhận điều khiển tắc nghẽn
 Điều khiển lưu lượng (flow control):  UDP không cung cấp: sự tin cậy
Bên gửi không làm ngập lụt (reliability), điều khiển lưu lượng,
(overwhelm) bên nhận điều khiển tắc nghẽn, sự kịp thời,
 Điều khiển tắc nghẽn (congestion đảm bảo thông lượng, an ninh,
control): Làm giảm tốc độ (throttle) hoặc thiết lập kết nối,
bên gửi khi mạng bị quá tải
 TCP không cung cấp: tính kịp thời Q: Dở thế (why bother)? Tại sao lại
(timing), đảm bảo thông lượng tối phải có giao thức UDP?
thiểu, an ninh
… 2.1.4 Các dịch vụ của giao thức vận chuyển Internet:
Các ứng dụng Internet được sử dụng phổ biến, các giao thức tầng
ứng dụng của chúng và các giao thức vận chuyển bên dưới.
application underlying
application layer protocol transport protocol
e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP
… 2.1.4 Các dịch vụ của giao thức vận chuyển Internet:
TCP an toàn (Securing TCP)

TCP & UDP không có sự mã hóa SSL ở tầng ứng dụng
 Mật khẩu cleartext được gửi vào  Các ứng dụng sử dụng các thư
socket đi qua Internet ở dạng viện SSL, chúng “nói chuyện”
cleartext (“talk”) với TCP
Người ta đã cải tiến TCP bằng SSL socket API
cách bổ sung 1 lớp con, gọi là  Mật khẩu cleartext được mã
SSL (Secure Sockets Layer). hóa trước khi gửi vào socket
 Cung cấp kết nối TCP được mã rồi đi qua Internet
hóa  Xem chi tiết tại Chương 7
 Đảm bảo tính toàn vẹn dữ liệu
 Xác thực end-point

2.2 Web và HTTP
2.4 Electronic mail
2.2 Web và HTTP
Trước hết, xem lại…
 web = World Wide Web
 web page (còn được gọi là document) bao gồm các objects
 object có thể là file HTML, hình ảnh JPEG, vi mã Java (Java

applet), tập tin âm thanh (audio file),…
 web page bao gồm base HTML-file nó gồm có một số đối
tượng được tham khảo (referenced objects)
 Mỗi đối tượng được địa chỉ hóa (addressable) bởi một URL
(Universal Resource Locator), thí dụ:
www.someschool.edu/someDept/pic.gif
host name path name
… 2.2 Web và HTTP
2.2.1 Tổng quan về HTTP
HTTP (HyperText Transfer

Protocol) – giao thức truyền
siêu văn bản
Là giao thức tầng ứng dụng của PC running
Firefox browser
Web
Theo mô hình client/server
 Client: là trình duyệt (browser),

nó gửi, nhận (sử dụng HTTP) server
và hiển thị (“displays”) các đối running
tượng Web Apache Web
server
 Server: Web server gửi (sử
dụng HTTP) các đối tượng đáp iphone running
ứng yêu cầu của requests Safari browser
… 2.2.1 HTTP overview (tiếp)
HTTP sử dụng TCP như sau: Giao thức HTTP là “không

 Client khởi tạo kết nối TCP trạng thái” (“stateless”)
(tạo socket) với server, port Server không duy trì thông tin
80 về các yêu cầu của client trong
 Server chấp nhận kết nối từ quá khứ
client aside
 Bản tin HTTP (application- Các giao thức duy trì thông
layer protocol messages) tin trạng thái là phức tạp!
được trao đổi giữa browser  Trạng thái đã qua phải được
duy trì
(HTTP client) và Web  Nếu server/client bị sập
server (HTTP server) (crashes), thông tin trạng thái
 Kết nối TCP được đóng lại
của chúng sẽ không nhất quán
(inconsistent), phải được làm
cho nhất quán (reconciled)
2.2.2 Hai loại kết nối HTTP
Kết nối HTTP không kiên trì Kết nối HTTP kiên trì
(non-persistent; HTTP/1.0) (persistent; HTTP/1.1)
Nhiều nhất có một object được Nhiều objects có thể được
gửi qua một kết nối TCP gửi qua một kết nối TCP duy
 Sau đó kết nối sẽ đóng lại nhất giữa client và server
Khi download nhiều objects thì
cần nhiều kết nối
HTTP with Non-persistent connection
Giả sử người dùng nhập vào URL: (contains text,
www.someSchool.edu/someDepartment/home.index references to 10
jpeg images)
1a. HTTP client bắt đầu kết nối
TCP đến HTTP server
(process) tại host 1b. HTTP server tại host
www.someSchool.edu ở www.someSchool.edu đang chờ
port 80 kết nối TCP tại port 80; Nhận
(“accepts”) kết nối, báo cho
2. HTTP client gửi HTTP request client biết.
message (chứa URL) vào
socket của kết nối TCP. Bản tin 3. HTTP server nhận được bản tin
(message) chỉ ra rằng client request, tạo response message
muốn nhận object có chứa đối tượng được (client)
someDepartment/home.index yêu cầu, và gửi bản tin vào
socket của nó.
time
… HTTP with non-persistent connection (tiếp)
4. HTTP server đóng kết nối TCP.
5. HTTP client nhận bản tin đáp lại

chứa html file, hiển thị html. Phân
tích ngữ pháp (parsing) html file,
tìm 10 đối tượng jpeg được tham
khảo
time
6. Các bước 1-5 được lặp lại đối
với mỗi một trong 10 đối tượng
jpeg
Non-persistent connection HTTP:
Thời gian đáp ứng (response time)
Thời gian khứ hồi - RTT

(Round Trip Time): Là thời
gian cho một packet nhỏ đi từ
client tới server và ngược lại
initiate TCP
Thời gian đáp ứng của HTTP: connection
 1 RTT để khởi tạo kết nối TCP RTT
 1 RTT cho HTTP request và một
request
số bytes đầu tiên của HTTP file
response quay trở về time to
RTT
 Thời gian truyền file transmit
file
 Thời gian đáp ứng của Non-
file
persistent HTTP = received
2RTT+ file transmission time
time time
Persistent HTTP
Các vấn đề đối với non- Các vấn đề đối với

persistent HTTP: persistent HTTP:
 Cần 2 RTTs cho mỗi object  Server để kết nối mở (open)
 Chi phí của HĐH (OS sau khi gửi bản tin response
overhead) cho mỗi kết nối  Các bản tin HTTP kế tiếp
TCP giữa cùng một cặp
 Trình duyệt thường mở song client/server được gửi qua kết
song các kết nối TCP để lấy nối mở
về các đối tượng được tham  Client gửi requests ngay khi
khảo nó gặp một đối tượng được
tham khảo
 Chỉ cần 1 RTT cho tất cả các
đối tượng được tham khảo
2.2.3 Khuôn dạng bản tin HTTP
HTTP request message (bản tin yêu cầu của HTTP)
 Hai loại bản tin HTTP: request, response
 HTTP request message:
 ASCII (human-readable format)
carriage return character
line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
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
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
2.2.3 Khuôn dạng bản tin HTTP
HTTP request message: General format (khuôn dạng chung)
method sp URL sp version cr lf request line
header field name value cr lf

header lines
~
~ ~
~
header field name value cr lf

cr lf
~
~ entity body ~
~ body
Uploading form input (Tải lên đầu vào theo mẫu)
Phương thức POST (POST method):

 Trang web thường có đầu vào theo khuôn mẫu (form input)
 Input được tải lên server theo toàn bộ khuôn mẫu
Phương thức URL (URL method):

 Dùng phương thức GET
 Input được tải lên trong trường URL của dòng yêu cầu
(request line):
www.somesite.com/animalsearch?monkeys&banana
Các loại phương thức (Method types)
HTTP/1.0: HTTP/1.1:
 GET: đọc 1 trang web  GET
 POST: nối vào 1 trang web  POST
 HEAD: đọc header của 1  HEAD
trang web  PUT
 Bảo server bỏ lại đối tượng  Tải lên toàn bộ file vào
đã yêu cầu khỏi bản tin đường dẫn được chỉ ra trong
đáp ứng (asks server to leave trường URL
requested object out of
response)  DELETE
 Xóa file được chỉ ra trong
trường URL
Bản tin hồi đáp của HTTP (HTTP response message)
status line
(protocol
status code HTTP/1.1 200 OK\r\n
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., data data data data data ...
requested
HTML file
HTTP response status codes (mã trạng thái hồi đáp của HTTP)
 Mã trạng thái xuất hiện ở dòng thứ nhất trong bản tin hồi đáp
gửi từ server đến client.
 Một số mã trạng thái làm thí dụ:
200 OK
 request succeeded, requested object later in this msg
301 Moved Permanently
 requested object moved, new location specified later in this msg (Location:)
400 Bad Request
 request msg not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported
Hãy tự mình thử nghiệm HTTP (client side)
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!

(or use Wireshark to look at captured HTTP request/response)
User-server state: cookies
Nhiều Web sites dùng cookies Thí dụ:
Bốn thành phần:  Susan luôn luôn truy cập
1) Dòng tiêu đề cookie của bản Internet từ PC

tin HTTP response  Lần đầu tiên thăm (visits) một
2) Dòng tiêu đề cookie trong site thương mại điện tử cụ thể

 Khi các HTTP requests đầu
bản tin HTTP request kế tiếp
tiên đến site, site tạo ra:
3) Tệp (file) cookie được giữ
trên máy của người dùng,  Một ID duy nhất
được quản lý bởi trình duyệt  Một entry ở CSDL
của người dùng backend cho ID đó
4) CSDL back-end tại Web site
Cookies: keeping “state” (cont.)
client server
ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
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
Cookies (continued)
Cookies có thể được sử dụng aside

Cookies và tính riêng tư:
làm gì:
 Cho phép (authorization)
 Cookies cho phép các sites
 Xe để hàng (shopping carts)
biết rất nhiều về bạn (người
 Giới thiệu
dùng)
(recommendations)  Người dùng có thể cung cấp
 Trạng thái phiên của người tên và e-mail cho các sites
dùng (Web e-mail)
Làm sao giữ được “state”:

 Điểm cuối giao thức (protocol endpoints): duy trì trạng
thái tại sender/receiver thông qua nhiều giao dịch
 Cookies: Các bản tin http mang (carry) trạng thái
Web caches (proxy server)
Mục đích: Thỏa mãn client request mà không kéo theo (involving)
server gốc
 Người dùng thiết lập
browser: Việc truy cập
Web thông qua cache proxy
 Browser gửi mọi HTTP server
requests đến cache client
origin
 Nếu đối tượng (object) server
có ở cache: cache trả về
đối tượng
 Nếu không có, cache gửi
requests đối tượng từ
server gốc (origin), sau
đó chuyển đối tượng cho client origin
client server
More about Web caching
 Cache hành động vừa Tại sao phải dùng Web

như client vừa như caching?
server  Để giảm thời gian đáp ứng cho
 Server đối với client gửi các client request
yêu cầu lần đầu tiên  Để giảm lưu lượng trên các
 Client đối với server gốc đường truy cập của cơ quan
 Cache thường được cài  Sử dụng dày đặc cache trên
Internet: cho phép các nhà
đặt bởi ISP (trường đại cung cấp nội dung loại yếu
học, công ty, nơi ở) (“poor”) có thể phân phát nội
dung một cách hiệu quả (tương
tự như vậy đối với việc chia sẻ
file P2P)
Thí dụ về caching:
Giả thiết:
 Kích thước đối tượng avg: 100K bits
 Tốc độ gửi yêu cầu avg từ các browsers
đến servers gốc:15/sec
 RTT từ router của cơ quan đến server gốc origin
bất kỳ: 2 sec servers
 Tốc độ đường truyền truy cập: 1.54 Mbps public
Internet
Kết quả là:
 Tốc độ dữ liệu avg đến các browsers: 1.50
Mbps (100kbits/rep*15rep/sec)
 LAN utilization: 15% (1.5Mbps/1Gbps) 1.54 Mbps
(problem! too low) access link
 access link utilization = 99%
institutional
(downlink throughput + uplink network
throughput)/1.54Mbps = 1 Gbps LAN
(1.5Mbps+15req/sec*200bytes/req*8bits/
byte) /1.54Mbps = 0.9888  99%)
 total delay = Internet delay + access
delay + LAN delay (access delay không tính
chính xác được từ các giả thiết trên)
= 2 sec + minutes + secs
Theo Lý thuyết hàng đợi (Queuing Theory): Avg-queue-size = r/(1- r ), r=l/
Trong thí dụ này, nếu lấy pkt_size = object size = 100kbits, thì với “access link”:
pkt_tx_time = 100,000 bits/1.54mbps ~ 10/1.54 s ~ 6.5 s
100*pkt_tx_time ~ 650s ~ 11 minutes.
Thí dụ về caching: Đường truy cập “béo” hơn
assumptions:
 Kích thước đối tượng avg: 100K bits
 Tốc độ gửi yêu cầu avg từ các browsers
đến servers gốc:15/sec
origin
 RTT từ router của cơ quan đến server gốc
bất kỳ : 2 sec servers
public
 Tốc độ đường truyền truy cập: 1.54Mbps Internet
Kết quả là: 154 Mbps
 Tốc độ dữ liệu avg đến các browsers:
1.50Mbps (100kbits/rep*15rep/sec)
 LAN utilization: 15% (1.5Mbps/1Gbps)
1.54 Mbps 154 Mbps
access link
 Access link utilization = 99%
9.9%
(downlink throughput + uplink institutional
throughput)/1.54Mbps = network
1 Gbps LAN
(1.5Mbps+15req/sec*200bytes/req*8bits/b
yte) /1.54Mbps = 0.9888  99%)
 total delay = Internet delay + access delay
+ LAN delay = 2 sec + minutes + secs
msecs
Giá (Cost): Tăng tốc độ đường truyền truy cập (không rẻ!)
Thí dụ về caching: Cài đặt cache cục bộ
assumptions:
 avg object size: 100K bits
 avg request rate from browsers to
origin servers:15/sec origin
 avg data rate to browsers: 1.50 Mbps servers
public
 RTT from institutional router to any Internet
origin server: 2 sec
 access link rate: 1.54 Mbps
consequences: 1.54 Mbps
 LAN utilization: 15% access link
 access link utilization = 100%
?
institutional
 total delay = Internet delay + access
network
delay + LAN delay 1 Gbps LAN
= 2 sec + minutes + usecs?
local web
cache
How to compute link
utilization, delay?
Cost: web cache (cheap!)
Thí dụ về caching: Cài đặt cache cục bộ
Tính độ sử dụng đường truyền truy
cập (access link), delay khi có cache:
 Giả sử cache hit rate bằng 0.4
origin
 40% requests được thỏa mãn tại cache,
servers
 60% requests được thỏa mãn tại gốc public
 Độ sử dụng đường truyền truy cập: Internet
 60% of requests sử dụng đường truyền
truy cập
 Tốc độ dữ liệu đến browsers qua đường
truyền truy cập = 0.6*1.50 Mbps = 0.9 Mbps 1.54 Mbps
 Độ sử dụng = 0.9/1.54 = 0.58 access link
 Độ trễ tổng cộng institutional
 = 0.6 * (delay from origin servers) +0.4 network
1 Gbps LAN
* (delay when satisfied at cache)
 = 0.6 (2.01) + 0.4 (~msecs) local web
 = ~ 1.2 secs cache
 Sẽ nhỏ hơn nếu đường truyền là 154
Mbps (và cũng rẻ hơn!)
Conditional GET
client server
 Mục đích: không gửi đối
tượng nếu cache có bản cập
nhật (up-to-date) HTTP request msg
object
 Không có trễ truyền If-modified-since: <date>
(trans.) đối tượng not
modified
 Độ sử dụng đường truyền HTTP response
before
thấp hơn HTTP/1.0
<date>
 Cache: chỉ ra date của bản 304 Not Modified
copy ở cache trong (bản tin)
HTTP request
If-modified-since: <date>
 Server: (bản tin) response sẽ
HTTP request msg
If-modified-since: <date> object
không chứa đối tượng nếu modified
bản copy trong cache là cập after
HTTP response
nhật: HTTP/1.0 200 OK <date>
HTTP/1.0 304 Not Modified <data>

2.2 Web và HTTP
2.4 Electronic mail
2.3 Giao thức truyền file FTP (File Transfer Protocol)
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system
 Truyền file đến/khỏi (to/from) host từ xa

 Theo mô hình client/server
 Client: là side khởi đầu (initiates) việc truyền (có thể là
to/from từ xa)
 Server: là host từ xa
 ftp: RFC 959
 ftp server: port 21
… 2.3 Giao thức truyền file FTP
FTP: separate control, data connections
 FTP client giao thiệp với FTP

server tại port 21, sử dụng TCP control connection,
TCP server port 21
 Client được cho phép qua kết

nối điều khiển (control FTP
TCP data connection,
server port 20 FTP
connection) client server
 Client duyệt (browses) thư
mục ở xa, gửi lệnh qua kết nối  Server mở kết nối dữ liệu
điều khiển TCP để chuyển file khác
 Khi server nhận được lệnh  Kết nối điều khiển: “out of
chuyển file, server mở kết nối band” (?)
dữ liệu TCP thứ 2 (để chuyển  FTP server duy trì “state”:
file) tới client thư mục hiện thời, sự cho
 Sau khi truyền một file, server phép (authentication) trước
đóng kết nối dữ liệu đó
… 2.3 Giao thức truyền file FTP
Các lệnh FTP và đáp ứng (responses)
Một số lệnh làm thí dụ: Một số mã trả về làm thí dụ:
 Lệnh được gửi dưới dạng  Mã trạng thái và nhóm từ (phrase)
ASCII text qua kênh điều khiển (giống như ở giao thức HTTP)
 USER username  331 Username OK, password
 PASS password required
 LIST trả về danh sách các file ở  125 data connection already open;
thư mục hiện thời (Ubuntu: ls) transfer starting
 RETR filename lấy về file  425 Can’t open data connection
(Ubuntu: get)  452 Error writing file
 STOR filename Chứa (puts)
file lên host ở xa (Ubuntu: put)

2.2 Web và HTTP
2.4 Electronic mail
2.4 Electronic mail
outgoing
message queue
Ba thành phần chính: user mailbox
 User agents (tác tử người dùng) user
agent
 Mail servers
 Simple mail transfer protocol: mail user
SMTP (giao thức chuyển/truyền server agent
thư đơn giản)
SMTP mail user
User Agent server agent
 Còn được gọi là “mail reader” SMTP
 Soạn (composing), sửa (editing),
đọc (reading) các mail messages SMTP user
 Thí dụ: Outlook, Thunderbird, agent
mail
iPhone mail client server
 Các bản tin đi (outgoing), đến user
agent
(incoming) được chứa ở server
user
agent
2.4 Electronic mail: mail servers
Mail servers: user

agent
 Mailbox (hộp thư) chứa các
bản tin đến cho người dùng mail user
server
 Message queue chứa các agent
bản tin thư chuẩn bị gửi đi SMTP mail user
 SMTP là giao thức để các server agent
mail servers gửi các bản tin SMTP
thư cho nhau
SMTP user
 Client: là mail server agent
mail
gửi (mail message) server
 “server”: là mail server user
agent
nhận (mail message)
user
agent
2.4 Electronic Mail: SMTP [RFC 2821]
 SMTP sử dụng TCP để chuyển một cách tin cậy email message
từ client đến server, port 25
 Chuyển trực tiếp (direct transfer): từ server gửi đến server nhận
 Ba pha của việc chuyển
 Bắt tay (handshaking, greeting)
 Truyền các bản tin
 Kết thúc (closure)
 Tương tác command/response (giống HTTP, FTP)
 Commands: ASCII text
 Response: status code and phrase
 Messages phải sử dụng mã ASCII 7-bit (plain text)
2.4 Electronic Mail
Kịch bản: Alice gửi message cho Bob
1) Alice sử dụng UA (User Agent) 4) SMTP client gửi message của

để soạn message gửi đến (“to”) Alice qua kết nối TCP
bob@someschool.edu 5) Mail server của Bob đặt
2) UA của Alice gửi message đến message vào hộp thư
mail server của cô ấy; message (mailbox) của Bob
được đặt vào hàng đợi message 6) Bob dùng UA của mình để đọc
3) Bên client của SMTP mở kết nối message
TCP với mail server của Bob
1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice‟s mail server Bob‟s mail server
2.4 Electronic Mail
Thí dụ về tương tác SMTP Client (C) và SMTP Server (S)
S: 220 hamburger.edu ;# hostname of the server

C: HELO crepes.fr ;# hostname of the client
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
2.4 Electronic Mail
SV hãy tự thử tương tác SMTP (Try SMTP interaction for yourself)
 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email client (reader)
2.4 Electronic Mail
Vài câu kết về SMTP (SMTP: final words)
 SMTP sử dụng các kết nối So sánh SMTP với HTTP:

bền (persistent connections)
 HTTP: pull (kéo)
 SMTP yêu cầu bản tin
(header & body) phải dùng  SMTP: push (đẩy)
các mã ASCII 7-bit  Cả hai đều có tương tác
 SMTP server sử dụng command/response dùng mã
CRLF.CRLF để xác định ASCII, mã trạng thái
cuối (end) của message
 HTTP: mỗi đối tượng được
gói (encapsulated) trong bản
tin hồi đáp riêng của nó
 SMTP: Nhiều objects được
gửi đi trong một bản tin có
nhiều phần (multipart msg)
2.4 Electronic Mail
Mail message format
SMTP: Giao thức dùng cho

việc trao đổi email msgs header
blank
RFC 822: chuẩn cho khuôn line
dạng bản tin text:
 Header lines, e.g.,
 To: body
 From:
 Subject:
khác với SMTP MAIL FROM,
RCPT TO: là lệnh
(commands)!
 Thân (body): chính là bản
tin (message)
 Chỉ chứa các ký tự ASCII
2.4 Electronic Mail
Các giao thức truy cập mail
user
mail access user
SMTP SMTP protocol
agent agent
(e.g., POP,
IMAP)
sender‟s mail receiver‟s mail

server server
 SMTP: phân phát (delivery) và chứa (storage) mail vào server

của người nhận
 Giao thức truy cập mail: lấy mail từ server về
 POP (now – POP3): Post Office Protocol [RFC 1939]: cho phép
(authorization), tải xuống
 IMAP: Internet Mail Access Protocol [RFC 1730]: có nhiều đặc
tính hơn POP, bao gồm việc các thao tác đối với các msgs được
chứa ở server
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.
2.4 Electronic Mail
POP3 protocol
S: +OK POP3 server ready
C: user bob
Pha cấp phép (authorization) S: +OK
C: pass hungry
 Các lệnh của client:
S: +OK user successfully logged on
 user: Khai báo username
 pass: password C: list
 Server hồi đáp S: 1 498
 +OK S: 2 912
S: .
 -ERR
C: retr 1
Pha giao dịch, client: S: <message 1 contents>
 list: xem danh sách số bản tin S: .
 retr: lấy bản tin về theo số C: dele 1
 dele: xóa bản tin (theo số) C: retr 2
 quit: kết thúc S: <message 1 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
2.4 Electronic Mail
POP3 (more) and IMAP
Thêm nữa về POP3 IMAP

 Thí dụ trước là về việc sử  Giữ tất cả các bản tin
dụng phương thức “download (messages) ở cùng một chỗ:
and delete” của POP3 tại server
 Bob không thể đọc lại e-mail  Cho phép người dùng tổ
nếu anh ta thay đổi client
chức các bản tin trong các
 POP3 “download-and-keep”: folders
copies các bản tin trên các
 Giữ (keeps) trạng thái người
client khác nhau
dùng giữa các phiên:
 POP3 là không trạng thái
 Đặt tên cho các folders
(stateless) giữa các phiên
và ánh xạ giữa message
IDs và tên folder

2.2 Web và HTTP
2.4 Electronic mail
DNS: Hệ thống tên miền (domain name system)
Con người: Nhiều định danh: Domain Name System:

 SSN, name, passport #  Là CSDL phân tán được thực
Internet hosts, routers: hiện kiểu có cấp bậc gồm
 Địa chỉ IP (32 bit) – nhiều name servers
được dùng để đánh địa  Giao thức tầng ứng dụng:
chỉ datagrams hosts, name servers giao tiếp
 “tên”, thí dụ để phân giải (resolve) tên
www.yahoo.com – được (address/name translation)
dùng bởi con người  Chú ý: Chức năng Internet
lõi, được thực hiện như là
Q: Làm thế nào để ánh xạ giao thức tầng ứng dụng
giữa địa chỉ IP và “tên” và
 Tính phức tạp ở biên của
ngược lại ?
mạng
… 2.5 DNS – Dịch vụ danh bạ của Internet
Các dịch vụ, cấu trúc
Các dịch vụ DNS Tại sao không dùng DNS

 Dịch từ hostname sang địa tập trung?
chỉ IP  Một điểm hư hỏng (failure)
 Đặt bí danh cho host (host duy nhất
aliasing)  Độ lớn của lưu lượng
 Tên chính tắc (Canonical), bí  CSDL tập trung ở xa
danh
 Bảo trì
 Đặt bí danh cho mail server
 Phân tán (distribution) tải A: Không khả mở
 Các Web servers được làm
các bản sao: Nhiều địa chỉ IP (doesn’t scale!)
ứng với một tên
CSDL phân tán, có cấp bậc (hierachichal)
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 muốn có địa chỉ IP cho tên www.amazon.com; 1st approx:

 Client hỏi (queries) root server để tìm com DNS server
 Client hỏi .com DNS server để tìm ra amazon.com DNS server
 Client hỏi amazon.com DNS server để tìm ra địa chỉ IP của
www.amazon.com
Server tên gốc (root name servers)
 Nếu server tên cục bộ không phân giải được một tên thì sẽ giao tiếp với server
tên gốc
 Server tên gốc:
 Giao tiếp với server tên có thẩm quyền (authoritative name server) nếu không biết
ánh xạ tên
 Nhận về ánh xạ
 Trả ánh xạ cho server tên cục bộ
c. Cogent, Herndon, VA (5 other sites)

d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)
e. NASA Mt View, CA m. WIDE Tokyo

f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
sites)
a. Verisign, Los Angeles CA 13 root name

(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers”
l. ICANN Los Angeles, CA worldwide
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)
TLD, authoritative servers
Server tên miền mức cao nhất – TLD (Top-Level Domain):

 Có trách nhiệm về các miền: com, org, net, edu, aero, jobs,
museums, và tất cả các tên miền quốc gia mức cao nhất, Thí
dụ: uk, fr, ca, jp, vn
 Network Solutions duy trì các servers cho .com TLD
 Educause duy trì các server cho .edu TLD
Server DNS có thẩm quyền (authoritative DNS servers):
 (Các) server DNS của riêng một tổ chức cung cấp ánh xạ
hostname to IP tin cậy cho các hosts được đặt tên của tổ chức
 Có thể được duy trì bởi tổ chức hoặc nhà cung cấp dịch vụ
Server tên DNS cục bộ (Local DNS name server)
 Không thuộc hoàn toàn vào cấp bậc (hierarchy)

 Mỗi ISP (ISP nơi ở, công ty, trường đại học) có một
 Cũng còn được gọi là “default name server”
 Khi host sinh ra một truy vấn (query) DNS, truy vấn
được gửi tới DNS server cục bộ của nó
 Có cache cục bộ của bản dịch cặp name-to-address (nhưng có
thể quá hạn!)
 Hành động như người được ủy nhiệm (proxy), chuyển tiếp
truy vấn vào hierarchy
Thí dụ về việc phân giải tên DNS root DNS server
 Host tại cis.poly.edu

muốn có địa chỉ IP cho 2
3
gaia.cs.umass.edu TLD DNS server
4
Query được lặp đi lặp lại: 5
 Server bị hỏi trả lời
bằng tên của server để local DNS server
liên lạc dns.poly.edu
7 6
 Tôi không biết cái tên 1 8
này, nhưng hãy hỏi
server này authoritative DNS server
 (“I don’t know this name, dns.cs.umass.edu
requesting host
but ask this server”)
cis.poly.edu
gaia.cs.umass.edu
…Thí dụ về việc phân giải tên DNS root DNS server
2 3
Query được lặp đi lặp lại: 7
6
 Đặt gánh nặng phân TLD DNS
giải tên lên name server server
bị liên lạc local DNS server
 Tải nặng tại các mức dns.poly.edu 5 4
cao hơn của cấp bậc 1 8
(hierarchy)?
authoritative DNS server
dns.cs.umass.edu
requesting host
cis.poly.edu
gaia.cs.umass.edu
Việc caching, cập nhật các bản ghi
 Một khi name server nào đó biết về ánh xạ, nó sẽ

caches ánh xạ
 Các đầu vào cache sẽ hết hạn - timeout (mất đi) sau một
khoảng thời gian- TTL (Time To Live)
 TLD servers thường được cached ở name servers cục bộ
 Vì vậy root name servers không bị ghé thăm thường xuyên
 Các mục cache có thể hết hạn (out-of-date), việc dịch
name-to-address là cố gắng tối đa (best effort)
 Nếu host có tên thay đổi địa chỉ IP, việc đó sẽ không có “ai”
trên toàn Internet biết, cho đến khi tất cả TTLs hết hạn
 Các cơ chế cập nhật/thông báo (update/notify) được đề
xuất làm chuẩn cho IETF
 RFC 2136
Các bản ghi DNS
DNS: CSDL phân tán chứa các bản ghi nguồn – RR (resource records)
RR format: (name, value, type, ttl)
type=A type=CNAME
 name là tên bí danh cho một cái
 name là hostname
tên chính tắc (“canonical”) nào đó
 value là địa chỉ IP  www.ibm.com thực sự là
servereast.backup2.ibm.com
type=NS  value là tên chính tắc
 name là domain (thí dụ:
foo.com)
 value là hostname của type=MX
server tên có thẩm quyền
đối với domain này  value là tên của mailserver liên
kết với name
Giao thức DNS, các bản tin
 Cả bản tin query lẫn bản tin reply có cùng khuôn dạng
Header của bản tin có các 2 bytes 2 bytes
trường identification flags

 identification: số16 bit cho # questions # answer RRs
query, bản tin reply tương
ứng sử dụng cùng con số # authority RRs # additional RRs
 flags:
questions (variable # of questions)
 query or reply
 recursion desired answers (variable # of RRs)
 recursion available
 reply is authoritative authority (variable # of RRs)
additional info (variable # of RRs)
… Giao thức DNS, các bản tin
2 bytes 2 bytes
identification flags
# questions # answer RRs
# authority RRs # additional RRs
name, type fields

questions (variable # of questions)
for a query
RRs in response answers (variable # of RRs)
to query
records for authority (variable # of RRs)
authoritative servers
additional “helpful” additional info (variable # of RRs)
info that may be used
Chèn các bản ghi vào trong DNS
 Thí dụ: Có một startup mới “Network Utopia”

 Đăng ký tên networkuptopia.com tại một nhà đăng ký
DNS (DNS registrar) , thí dụ Network Solutions
 Cung cấp tên, địa chỉ IP của server tên chính tắc
(authoritative) (primary and secondary)
 Nhà đăng ký chèn hai RRs vào trong .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
 Tạo ra bản ghi authoritative server kiểu A record cho
www.networkuptopia.com; bản ghi kiểu MX cho
networkutopia.com
Tấn công DNS
Tấn công kiểu DDoS Tấn công kiểu chuyển hướng

(Distributed Denial of Service) (Redirect)
 Oanh tạc root servers bằng  Đứng vào giữa (Man-in-
lưu lượng middle)
 Cho đến nay, cách này không  Chặn các queries
thành công  Đầu độc poisoning (DNS)
 Lọc lưu lượng (Traffic  Gửi các relies giả tới DNS server,
Filtering) which caches
 Các servers DNS cục bộ
cache địa chỉ IPs của TLD Exploit DNS for DDoS
servers, cho phép root server  Send queries with spoofed
bỏ qua source address: target IP
 Oanh tạc TLD servers  Requires amplification
 Có thể là nguy hiểm hơn
DDoS

2.2 Web và HTTP
2.4 Electronic mail
2.6.1 Phân phát file P2P
2.6.2 Bảng băm phân tán – DHT (Distributed Hash Tables)
Pure P2P architecture
 Không có server luôn bật (on)

 Các end systems bất kỳ liên
lạc trực tiếp với nhau
 Các bên ngang hàng (peers)
thỉnh thoảng bị ngắt kết nối và
thay đổi địa chỉ IP
Các thí dụ:

 Phân phát (distribution )
file: BitTorrent
 Streaming (KanKan)
 VoIP (Skype)
2.6.1 Phân phát file P2P: so sánh client-server với P2P
Question: mất bao nhiêu thời gian để phân phát một file kích thước
F từ một server tới N peers?
 Năng lực (capacity) upload/download của một peer là tài nguyên có giới
hạn
us: server upload

capacity
di: peer i download

file, size F u1 d1 capacity
us u2 d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity
Thời gian phân phát file theo mô hình Client-Server
 Việc truyền của server: phải truyền

(upload) tuần tự N bản copy của F
us
file:
 Thời gian truyền 1 copy: F/us di
 Thời gian truyền N copies: NF/us network
ui
 Bên client: mỗi client phải download một bản

copy của file
 dmin = tốc độ download tối thiểu của client
 Thời gian download tối thiểu của client: F/dmin
Thời gian phân phối F

Đến N clients sử dụng Dc-s > max{NF/us,,F/dmin}
Cách tiếp cận client-server
Tăng tuyến tính theo N

Thời gian phân phát file theo mô hình P2P
 Việc truyền của server: Phải

upload ít nhất 1 bản copy của file
F
 Thời gian truyền 1 copy: F/us us
 Bên client: mỗi client phải di
download một bản copy của file network
 Thời gian download tối thiểu ui
là: F/dmin
 Clients: để tập hợp lại (thành files) N clients phải download NF bits
 Tốc độ upload tối đa (làm hạn chế tốc độ download tối đa) is us + Sui
Thời gian để phân phối F

đến N clients sử dụng DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
cách tiếp cận P2P
Tăng tuyến tính theo N …

… nhưng do làm như vậy, mỗi peer đem lại năng lực phục vụ
2.6.1 Phân phát file P2P
So sánh (thời gian phân phát file) client-server với P2P: Một thí dụ
Tốc độ upload của client = u, F/u = 1 giờ, us = 10u, dmin ≥ us
3.5
P2P
Minimum Distribution Time
3
Client-Server
2.5
1.5
0.5
0
0 5 10 15 20 25 30 35
2.6.1 Phân phối file P2P: BitTorrent (torrent: dòng nước lũ)
 File được chia thành các khúc (chunks) 256Kb

 Các peers trong torrent send/receive các chunks của file
Tracker: theo dấu các peers Torrent: nhóm các peers trao đổi
Tham gia trong torrent các khúc (chunks) của một file
Alice đi đến …
… nhận danh sách các

peers từ tracker
… và bắt đầu trao đổi các khúc

của file với các peers trong torrent
2.6.1 Phân phối file P2P: BitTorrent
 Peer gia nhập torrent:

 Chưa có chunks nào cả, nhưng
sẽ tích lũy chúng theo thời gian
từ các peers khác
 Nó đăng ký với tracker để nhận
danh sách các peers, rồi kết nối
với một tập con (subset) các
peers (“neighbors”)
 Trong khi đang download, peer uploads các khúc cho các peers khác
 Một peer có thể thay đổi các peers mà nó trao đổi các khúc
 Churn (tạo sóng): Là các peers có thể đến và đi
 Khi một peer có nguyên một file, nó có thể (một cách ích kỷ) rời đi
hoặc (một cách vị tha) ở lại trong torrent
2.6.1 Phân phối file P2P
BitTorrent: Việc yêu cầu, gửi các khúc (chunks) của file
Việc yêu cầu (requesting) Việc gửi các chunks: tit-for-tat

chunks: (trao đổi ngang bằng)
 Tại mọi thời điểm bất kỳ, các  Alice gửi các chunks đến 4 peers hiện
peers khác nhau có các tập con đang gửi cho nó các chunks với tốc độ
khác nhau của các khúc (chunks) cao nhất
 Một cách định kỳ, Alice hỏi xin  Các peers khác bị Alice bóp nghẹt
(choked) (không nhận được chunks từ
từng peer danh sách các chunks
Alice)
mà chúng có
 Đánh giá lại top 4 sau mỗi khoảng10 secs
 Alice yêu cầu các chunks còn
 Sau mỗi 30 secs: chọn ngẫu nhiên một
thiếu từ các peers, đầu tiên là các
peer khác, bắt đầu gửi chunks
chunk hiếm nhất
 Làm cho thông peer này
(“optimistically unchoke”)
 Peer vừa mới được chọn gia nhập
nhóm top 4
2.6.1 Phân phối file P2P
BitTorrent: tit-for-tat
1) Alice làm cho Bob thông (“optimistically unchokes”)
2) Alice trở thành một trong các nhà cung cấp top-four của Bob; Bob đền đáp lại
3) Bob trở thành một trong các nhà cung cấp top-four của Alice
Tốc độ upload cao hơn: Tìm các đối tác

trao đổi tốt hơn, lấy được file nhanh hơn !
2.6.2 Bảng băm phân tán – DHT (Distributed Hash Table)
 Bảng băm (Hash table)
 Mẫu DHT (DHT paradigm)
 DHT vòng tròn và mạng overlay (Circular DHT

and overlay networks)
 Tạo sóng peer (Peer churn)
CSDL đơn giản được sử dụng trong mạng P2P
CSDL đơn giản có các cặp (key, value)
• key: tên người; value: số an sinh xã hội (social security #)
Key Value
John Washington 132-54-3570
Diana Louise Jones 761-55-3791
Xiaoming Liu 385-41-0902
Rakesh Gopal 441-89-1956
Linda Cohen 217-66-5609
……. ………
Lisa Kobayashi 177-23-0199
• key: có thể là tên bộ phim; value: địa chỉ IP
Bảng băm (Hash Table)
• Việc chứa (store) và tìm kiếm trên biểu diễn số của khóa là tiện
lợi hơn nhiều
• key = hash(original key)
Original Key Key Value

John Washington 8962458 132-54-3570
Diana Louise Jones 7800356 761-55-3791
Xiaoming Liu 1567109 385-41-0902
Rakesh Gopal 2360012 441-89-1956
Linda Cohen 5430938 217-66-5609
……. ………
Lisa Kobayashi 9290124 177-23-0199
 Mọi peer đều được phép insert các cặp (key, value) vào CSDL
 CSDL phân tán như vậy còn được gọi là Bảng băm phân tán -
DHT
 Phân phối các cặp (key, value) đến hàng triệu peers
 Các cặp (pairs) cuối cùng sẽ được phân phát đến các peers
 Mọi peer đều có thể query (truy vấn) CSDL với một khóa
 CSDL trả về (returns) giá trị cho khóa
 Để phân giải (resolve) query, một số nhỏ các bản tin được trao đổi giữa
các peers
 Mỗi peer chỉ biết về một số nhỏ các peers khác
 Là mạnh (robust) đối với các peers đến và đi (churn)
Việc gán cặp key-value cho các peers
 Quy tắc (rule): gán cặp key-value cho peer có ID gần

nhất.
 Quy ước (convention): gần nhất là cái liền sau
(immediate successor) của khóa.
 Thí dụ: không gian ID {0,1,2,3,…,63} ;# (0..2^n -1)
 Giả sử có 8 peers: 1, 12, 13, 25, 32, 40, 48, 60
 If key = 51, then gán cho peer 60
DHT vòng tròn (Circular DHT)
• Mỗi peer chỉ nhận thấy được phần

tử ngay sau và phần tử ngay trước.
60 12
13
48
25
40
32
“overlay network”
Phân tích một truy vấn (Resolving a query)
Trung bình cần O(N)

bản tin để phân tích 1 What is the value
một query, khi có associated with
N peers value key 53 ?
12
60
13
48
25
40
32
DHT vòng tròn với shortcuts (Circular DHT with shortcuts)
1 What is the value for

value key 53
12
60
13
48
25
40
32
• Mỗi peer theo dõi id và đc IP của phần tử sau, phần tử trước và các short cuts.
• Giảm số bản tin từ 6 xuống 3.
• Có thể thiết kế các shortcuts với O(log N) hàng xóm, O(log N) bản tin để
Tạo sóng peer (peer churn)
Xử lý (handling) peer
1 churn:
Peers có thể đến và đi (churn)
3 Mỗi peer biết địa chỉ của 2
15
phần tử sau nó
4 Mỗi peer định kỳ pings 2 phần
tử sau nó để kiểm tra xem còn
12
5 sống (aliveness) không
Nếu phần tử liền ngay sau nó
10
8 rời đi, thì chọn phần tử sau nó
kế tiếp làm phần tử liền ngay
Thí dụ: peer 5 đột ngột rời đi sau nó mới
… Tạo sóng peer (peer churn)
1 … Xử lý (handling) peer churn:
Peers có thể đến và đi (churn)
15 3 Mỗi peer biết địa chỉ của 2 phần tử sau
nó
4 Mỗi peer định kỳ pings 2 phần tử sau
nó để kiểm tra xem còn sống (aliveness)
12 không
Nếu phần tử liền ngay sau nó rời đi, thì
10 chọn phần tử sau nó kế tiếp làm phần tử
8
liền ngay sau nó mới
… Thí dụ: peer 5 đột ngột rời đi
Peer 4 phát hiện thấy sự rời đi của peer 5; nó lấy peer 8 làm phần tử liền ngay
sau nó
Peer 4 hỏi peer 8 ai là phần tử đứng liền ngay sau nó (8); nó (4) lấy phần tử
đứng liền ngay sau peer 8 làm phần tử sau thứ 2

2.2 Web và HTTP
2.4 Electronic mail
2.7.1 Socket Programming with UDP
2.7.2 Socket Programming with TCP
Mục tiêu (goal): Học được cách xây dựng các ứng dụng
client/server truyền thông bằng việc sử dụng sockets
Socket: là cửa giữa tiến trình ứng dụng và giao thức vận chuyển
e2e (end-end-transport)
application application
socket controlled by
process process app developer
transport transport
network network controlled
link by OS
link Internet
physical physical
… 2.7 Lập trình socket với UDP và TCP
Hai loại socket dùng cho hai dịch vụ vận chuyển:

 UDP: vận chuyển bản tin (datagram) không tin cậy
 TCP: vận chuyển tin cậy, định hướng dòng byte (byte stream-
oriented)
Thí dụ ứng dụng:
1. Client đọc một dòng ký tự (data) từ bàn phím của nó và gửi dữ
liệu đến server.
2. Server nhận dữ liệu và chuyển đổi (converts) các ký tự thành chữ
hoa (uppercase).
3. Server gửi dữ liệu đã sửa đổi đến client.
4. Client nhận dữ liệu đã sửa đổi và hiển thị dòng ký tự lên màn
hình của nó.
2.7.1 Lập trình socket với UDP
UDP: không có “connection” giữa client & server
 Không có bắt tay (handshaking) trước khi gửi dữ liệu
 Sender gắn một cách rõ ràng địa chỉ IP đích và port # vào mỗi
packet
 Receiver tách địa chỉ IP và port# của người gửi từ packet nhận
được
UDP: Dữ liệu được truyền có thể bị mất hoặc nhận không đúng
thứ tự
Quan điểm của ứng dụng:
 UDP cung cấp sự truyền (transfer) không tin cậy các nhóm
bytes (“datagrams”) giữa client và server
… 2.7.1 Lập trình socket với UDP
Tương tác socket client/server: UDP
server (running on serverIP) client

create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
read datagram from clientSocket
serverSocket
write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket
2.7.1 Lập trình socket với UDP
Thí dụ ứng dụng: UDP client
Python UDPClient
include Python‟s socket
library
from socket import *
serverName = „hostname‟
serverPort = 12000
create UDP socket for clientSocket = socket(socket.AF_INET,
server
socket.SOCK_DGRAM)
get user keyboard
input message = raw_input(‟Input lowercase sentence:‟)
Attach server name, port to
message; send into socket
clientSocket.sendto(message,(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string print modifiedMessage
and close socket
clientSocket.close()
(… 2.7) Lập trình socket với UDP
Thí dụ ứng dụng: UDP server
Python UDPServer
serverPort = 12000
create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM)
bind socket to local port serverSocket.bind(('', serverPort))
number 12000
print “The server is ready to receive”
loop forever while 1:
Read from UDP socket into message, clientAddress = serverSocket.recvfrom(2048)
message, getting client‟s
address (client IP and port) modifiedMessage = message.upper()
send upper case string
serverSocket.sendto(modifiedMessage, clientAddress)
back to this client
2.7.2 Lập trình socket với TCP
Client phải liên lạc với server  Khi được client liên lạc, server
 Tiến trình server phải chạy TCP tạo ra socket mới cho tiến
trước trình server liên lạc với client
 Server phải tạo (xong) socket cụ thể đó
(door) để đón nhận sự liên lạc  Cho phép server nói chuyện
của client (talk) với nhiều clients
 Source port numbers được
Client liên lạc với server bằng: sử dụng để phân biệt các
 Tạo ra TCP socket, bằng việc clients (more in Chap 3)
chỉ ra địa chỉ IP, port number
của tiến trình server
Quan điểm của ứng dụng:
 Khi client tạo socket: client
TCP thiết lập kết nối với server TCP cung cấp sự vận chuyển tin
TCP cậy, dòng byte đúng thứ tự (“pipe”)
Giữa client và server
Tương tác socket client/server: TCP
server (running on hostid) client

create socket,
port=x, for incoming
request:
serverSocket = socket()
wait for incoming create socket,

connection request
TCP connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket()
serverSocket.accept()
send request using

read request from clientSocket
connectionSocket
write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket
Example app: TCP client
Python TCPClient
serverName = ‟servername‟
create TCP socket for

serverPort = 12000
server, remote port 12000 clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = raw_input(„Input lowercase sentence:‟)
No need to attach server clientSocket.send(sentence)
name, port
modifiedSentence = clientSocket.recv(1024)
print „From Server:‟, modifiedSentence
clientSocket.close()
Example app: TCP server
Python TCPServer
create TCP welcoming
serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((„‟,serverPort))
server begins listening for
incoming TCP requests
serverSocket.listen(1)
print „The server is ready to receive‟
loop forever while 1:
server waits on accept() connectionSocket, addr = serverSocket.accept()
for incoming requests, new
socket created on return
sentence = connectionSocket.recv(1024)
read bytes from socket (but
not address as in UDP) capitalizedSentence = sentence.upper()
close connection to this
connectionSocket.send(capitalizedSentence)
client (but not welcoming connectionSocket.close()
socket)
Chương 2: Tóm tắt
Việc nghiên cứu các ứng dụng mạng của chúng ta kết thúc!
 Các kiến trúc ứng dụng  Các giao thức cụ thể:
 Client-server  HTTP
 P2P
 FTP
 Các yêu cầu đối với dịch vụ  SMTP, POP, IMAP
ứng dụng:
 DNS
 Reliability, bandwidth, delay
 P2P: BitTorrent, DHT
 Mô hình dịch vụ vận chuyển
Internet  Socket programming: TCP,
 Hướng kết nối, tin cậy UDP sockets
(Connection-oriented, reliable):
TCP
 Không tin cậy, bản tin
(Unreliable, datagrams): UDP
… Chương 2: Tóm tắt
Quan trọng nhất là: học về các giao thức!
 Sự trao đổi bản tin (msg) Các chủ đề (themes) quan trọng:
request/reply điển hình:  So sánh các bản tin control và
 Client yêu cầu thông tin
(info) hoặc dịch vụ data
 Server đáp lại với dữ liệu  in-band, out-of-band
(data), mã trạng thái (status  Tập trung và không tập trung
code)
(centralized vs. decentralized)
 Khuôn dạng bản tin:
 Headers: gồm các  Không trạng thái và có trạng
trường (fields) cung cấp thái (stateless vs. stateful)
thông tin về dữ liệu  Truyền msg tin cậy và không
 Data: là thông tin được tin cậy
trao đổi
 Sự phức tạp tại biên mạng
(“complexity at network edge”)
Chương 1
Các slides bổ sung
… Chương 1 Các slides bổ sung
application
packet (www browser,
analyzer email client)

application
OS
packet Transport (TCP/UDP)
copy of all Network (IP)
capture Ethernet
frames Link (Ethernet)
(pcap) sent/receive
Physical
d
Q&A

CN2019 Chapter2 Application Layer (VIE Final)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CN2019 Chapter2 Application Layer (VIE Final)

Uploaded by

Copyright:

Available Formats

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Môn học (3TC):

PGS. TS. Nguyễn Đình Việt

A note on the use of these ppt slides:

All material copyright 1996-2012

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

 E-mail  Voice over IP (e.g., Skype)

Đó là việc viết các chương trình:

dụng nhanh chóng

Các kiến trúc có thể của các ứng dụng:

 Không có server luôn luôn bật peer-peer

Process: là chương trình Clients, servers

Tính toàn vẹn (integrity) dữ liệu: Thông lượng (throughput)

application data loss throughput time sensitive

file transfer no loss elastic no

Dịch vụ TCP: UDP service:

trình client & server (unreliable data transfer) giữa tiến

e-mail SMTP [RFC 2821] TCP

TCP an toàn (Securing TCP)

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

 object có thể là file HTML, hình ảnh JPEG, vi mã Java (Java

host name path name

HTTP (HyperText Transfer

 Client: là trình duyệt (browser),

HTTP sử dụng TCP như sau: Giao thức HTTP là “không

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

5. HTTP client nhận bản tin đáp lại

Thời gian khứ hồi - RTT

Các vấn đề đối với non- Các vấn đề đối với

method sp URL sp version cr lf request line

header field name value cr lf

header field name value cr lf

Phương thức POST (POST method):

Phương thức URL (URL method):

1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 opens TCP connection to port 80

2. type in a GET HTTP request:

3. look at response message sent by HTTP server!

1) Dòng tiêu đề cookie của bản Internet từ PC

2) Dòng tiêu đề cookie trong site thương mại điện tử cụ thể

one week later:

Cookies có thể được sử dụng aside

Làm sao giữ được “state”:

 Cache hành động vừa Tại sao phải dùng Web

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

 Truyền file đến/khỏi (to/from) host từ xa

 FTP client giao thiệp với FTP

 Client được cho phép qua kết

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

Mail servers: user

1) Alice sử dụng UA (User Agent) 4) SMTP client gửi message của

1 user mail user

S: 220 hamburger.edu ;# hostname of the server

 SMTP sử dụng các kết nối So sánh SMTP với HTTP:

SMTP: Giao thức dùng cho

sender‟s mail receiver‟s mail

 SMTP: phân phát (delivery) và chứa (storage) mail vào server

Thêm nữa về POP3 IMAP

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

Con người: Nhiều định danh: Domain Name System:

Các dịch vụ DNS Tại sao không dùng DNS

Root DNS Servers