Mạng máy tính-chương 2: Tầng ứng dụng pps

❒ Tiến trình gửi/nhận thông báo với nhau qua socket ❒ socket tương tự như cửa ❍ Tiến trình gửi chuyển thông báo ra ngoài cửa process socket host or server process socket host or server

❒ 2.7 Lập trình socket với TCP

❒ 2.9 Phát truển một Web server

❍ HTTPFTP

❍ socket API

server giao tiếp với các trình duyệt

Không phần mềm dưdợc viết

cho thiết bị trong lõi

application

transport network data link physical

❒ 2.7 Lập trình socket với TCP

❒ 2.9 Phát truển một Web server

Các kiến trúc ứng dụng

❒ Khách-phục vụ (Client-server)

❒ Ngang hàng (Peer-to-peer - P2P)

❒ Lai (client-server và P2P)

❍ Không giao tiếp với client khác

Kiến trúc thuần ngang hàng

❒ Không có server luôn

❒ Các đầu cuối ngang hàng

(peers) kết nối theo thời

điểm và thay đổi địa chỉ

IP giữa các lần kết nối

❒ vd: Gnutella

Tính khả mở rộng rất cao

Nhưng khó quản trị

Lai giữa client-server và P2P

Napster

❍ Truyền tệp P2P

❍ Tìm tệp tập trung:

• Peers đăng ký nội dung tại server trung tâm

• Peers truy vấn server trung tâm để định vị nội dung

Truyền thông tiến trình

Tiến trình (process):

chương trình đang chạy

ở một host.

❒ ở trên cùng host, hai

tiến trình truyền thông

Tiến trình khách: tiến trình khởi tạo truyền thông

Tiến trình phục vụ: tiến trình đợi được liên hệ

tiến trình truyền thông

sử dụng truyền thông

liên tiến trình (được xác

định bởi HĐH).

❒ Các tiến trình ở các host

khác nhau truyền thông

bằng trao đổi thông báo

❒ Ghi chú: các ứng dụng với kiến trúc P2P có cả tiến trình khác và tiến trình phục vụ

❒ Tiến trình gửi/nhận thông

báo với nhau qua socket

❒ socket tương tự như cửa

❍ Tiến trình gửi chuyển thông

báo ra ngoài cửa

process socket

host or server

process socket

host or server

controlled by app developer

2: Tầng ứng dụng 12

báo ra ngoài cửa

❍ Hậ tầng truyền thông bên

ngoài cửa chuyển thông báo

đến trước cửa của tiến trình

nhận

TCP with buffers, variables

TCP with buffers, variables Internet

controlled

by OS

❒ API: (1) lựa chọn giao thức vận chuyển; (2) xác định một

số tham số

Địa chỉ của tiến trình

và số hiệu cổng tương

ứ ng với tiến trình.

❒ Ví dụ số hiệu cổng:

❍ HTTP server: 80

❒ H: địa chỉ IP của host

mà tiến trình đang chạy

Giao thức tầng ứng dụng định

nghĩa

❒ Các loại thông báo được

trao đổi giữa các tiến

trúc của các thông báo:

dãy các trường (thông

tin)

❒ Ngữ nghĩa của các trường

= nghĩa của thông tin

trong các trường

❒ Các luật xử lý (khi nào và

như thế nào) gửi/nhận

thông báo

Giao thức đặc quyền:

có “hiệu lực”

Các ng d ng khác

truyền tệp, telnet) yêu cầu

100% truyền dữ liệu tin cậy

Yêu cầu dịch vụ giao vận của một số ứng dụng phổ

biến

Application

file transfer

e-mailWeb documents

Bandwidth

elasticelasticelasticaudio: 5kbps-1Mbps

Time Sensitive

nononoyes, 100’s msec

no loss

audio: 5kbps-1Mbpsvideo:10kbps-5Mbpssame as above

few kbps upelastic

yes, 100’s msec

yes, few secsyes, 100’s msecyes and no

Các dịch vụ giao vận Internet

TCP service:

❒ Hướng kết nối: cần có thiết lập

kết nối giữa các tiền trình

truyền thông với nhau

❒ Giao vận tin cậy giữa tiến trình

gửi và tiến trình nhận

UDP service:

❒ Truyền không tin cậy giữa tiến trình gửi và tiến trình nhận

❒ Không cung cấp: thiết lập kết nối, kiểm soát luồng, gửi và tiến trình nhận

❒ Kiểm soát luồng: tiến trình gửi

không gửi quá khả năng nhận

của tiến trình nhận

❒ Kiểm soát tắc nghẽn: giảm tốc

độ gửi khi mạng quá tải

❒ Không cung cấp: định thời,

đảm bảo băng thông tối thiểu

kết nối, kiểm soát luồng, kiểm soát tắc nghẽn, định thời, hoặc đảm bảo băng thông

H: Tại sao lại có UDP?

Các ứng dụng Internet: giao thức tầng ứng dụng và giao thức giao vận được sử dụng

Ứ ng d ụ ng

e-mailremote terminal access

Web file transfer

TCPTCPTCPTCP

2: Tầng ứng dụng 18

file transferstreaming multimedia

Internet telephony

FTP [RFC 959]

proprietary(e.g RealNetworks)proprietary

(e.g., Dialpad)

TCPTCP or UDP

typically UDP

❒ 2.7 Lập trình socket với TCP

❒ 2.9 Phát truển một Web server

Web và HTTP

Một số thuật ngữ ban đầu

❒ Trang web bao gồm các đối tượng

❒ Đối tượng có thể là tệp HTML, JPEG image, Java

applet, audio file,…

❒ Trang web bao gồm tệp HTML chứa các đối tượng

2: Tầng ứng dụng 20

❒ Trang web bao gồm tệp HTML chứa các đối tượng

được tham chiếu

❒ Mỗi đối tượng có thể đánh địa chỉ bằng một URL

❒ Vd URL:

www.someschool.edu/someDept/pic.gif

❍ client: trình duyệt yêu

cầu, nhận và hiển thị các

đối tượng Web

❍ server: Web server gửi

các đối tượng web trong

các đáp ứng yêu cầu

❒ HTTP 1.0: RFC 1945

❒ HTTP 1.1: RFC 2068

Server running Apache Web server Mac running

Navigator

Tổng quan HTTP (tiếp)

Sử dụng TCP:

❒ client khởi tạo kết nối TCP

(tạo socket) đến server, cổng

80

❒ server chấp nhận kết nối TCP

của client

HTTP là “phi trạng thái”

❒ server không duy trì thông tin các yêu cầu trước của

Bên lề

2: Tầng ứng dụng 22

của client

❒ Các thông báo HTTP được

trao đổi giữa trình duyệt

(HTTP client) và Web server

(HTTP server)

❒ Kết nối TCP được đóng

Giao thức duy trì trạng thái phức tạp!

❒ Phải lưu lịch sử (trạng thái)

❒ Nếu server/client treo, cái nhìn về “trạng thái” của hai tiến trình sẽ không nhất quán

Bên lề

độ mặc định

2 HTTP client gửi thông báo

HTTP request (chứa URL) vào socket TCP Thông báo biểu thị rằng client cần các đối tượng tại

time

HTTP không liên tục (tiếp)

5 HTTP client nhận response chưa tệp html, hiển thị html

Phân tích html, tìm thấy 10 đối tượng jpeg được tham chiếu

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

time 6. Các bước 1-5 dược lặp lại cho

mỗi đối tượng ảnh

time

Mô hình hóa thời gian đáp ứng

Thời gian quay vòng - RRT:

thời gian để gửi một gói

❒ Thời gian truyền tệp

total = 2RTT+transmit time

time to transmit file

request file

RTT

file received

HTTP liên tục

Hạn chế của HTTP không liên

tục:

❒ Yêu cầu 2 RTTs / đối tượng

❒ HĐH phải làm việc và cấp tài

nguyên cho mỗi kết nối TCP

❒ nhưng các trình duyệt

Liên tục không pipelining:

❒ client gửi yêu cầu tiếp theo khi đã nhận được response cho yêu cầu trước

❒ Một RTT/ đối tượng tham chiếu

Liên t c v i pipelining:

❒ nhưng các trình duyệt

thường mở nhiều kết nối TCP

song song để yêu cầu các đối

tượng tham chiếu

HTTP liên tục

❒ server để kết nối mở sau khi

gửi response

❒ Các thông báo HTTP tiếp sau

được gửi qua kết nối

Liên tục với pipelining:

❒ Mặc định ở HTTP/1.1

❒ client gửi các yêu cầu ngay khi nó bắt gặp đối tượng tham chiếu

❒ Có thể chỉ cần một RTT cho tất cả các đối tượng tham chiếu

User-agent: Mozilla/4.0 Connection: close

Carriage return,

line feed

indicates end

of message

HTTP request: cấu trúc

Upload dữ liệu form

Phương thức Post:

gồm form nhập

❒ Dữ liệu được đẩy lên

server trong thân của

❍ Yêu cầu server bỏ qua

đối tượng được yêu cầu

thư mục được xác định bởi URL

❍ Xóa tệp được xác định bởi URL

HTTP response

HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 22 Jun 1998 …

❍ Đối tượng được yêu cầu đã bị chuyển, thư mục mới của đối

tượng được xác định phía sau (Location:)

Thử HTTP phía client

1 Telnet đến Web server:

Mở kết nối TCP tới cổng 80 (cổng mặc định của HTTP) tại cis.poly.edu Mọi thứ được nhập sẽ được gửi đến cổng

Bằng việc nhập nội dung này (hai dấu xuống dòng), bạ gửi yêu cầu

GET request tối thiểu đến HTTP server

3 Quan sát HTTP response nhận được!

Trạng thái người dùng-server:

❍ Cô vào một trang thương mại điện tử lần đầu

trong HTTP response

2) Dòng tiêu đề cookie

trong HTTP request

3) Tệp cookie được lưu

trên máy người dùng và

quản trị bởi trình duyệt

4) CSDL ở phía server

mại điện tử lần đầu

❍ Khi các HTTP requests đến site, site tạo một định danh duy nhất và tạp một phần tử trong CSDL trên server cho

ID này

Cookies: lưu “trạng thái” (tiếp)

usual http request msg usual http response +

Set-cookie: 1678

usual http request msg

servercreates ID

spectificaction

& cookies để thu thập thông tin

❒ Các công ty quảng cáo nhận thông tin từ các sites

Web caches (proxy server)

❒ Trình duyệt gửi HTTP đến

cache

❍ Nếu đối tượng được yêu

cầu ở trong cache: cache

gửi đối tượng cho trình

Mục đích: đáp ứng yêu cầu của client mà không cần server

gốc làm việc

client

Proxyserver

origin server

2: Tầng ứng dụng 38

gửi đối tượng cho trình

duyệt

❍ Ngược lại cache yêu cầu

đối tượng từ server gốc,

rồi gửi đối tượng cho

client

client

origin server

Web caching (tiếp)

❒ Cache đóng vai trò cả client

và server

❒ Thường cache được cài đặt

bởi ISP (trường ĐH, công

ty, ISP địa phương)

Tại sao Web caching?

❒ Giảm thời giam đáp ứng đến yêu cầu của client

❒ Giảm lưu lượng trên các liên kết bên trong tổ chức

Internet với nhiều caches

❒ Internet với nhiều caches cho phép các nhà cung cấp nội dung chuyển tải nội dung hiệu quả

Ví dụ Caching

Giả thiết

❒ Kích thước trung bình các đối

tượng = 100,000 bits

❒ Trung bình tần suất yêu cầu từ

các trình duyệt bên trong tổ

chức đến server gốc = 15/sec

Tr vòng t router c a t ch c

originservers

public Internet

1.5 Mbps access link

institutional cache

public Internet

10 Mbps access link

institutional cache

public Internet

1.5 Mbps access link

institutional cache

GET có điều kiện

❒ Mục đích: không gửi đối tượng

nếu cache đang có phiên bản

cập nhật

❒ cache: đưa thông tin ngày cập

nhât cuối của bản copy trên

cache vào HTTP request

cache vào HTTP request

If-modified-since:

<date>

❒ server: response không chứa

đối tượng nếu bản copy trên

❒ 2.7 Lập trình socket với TCP

❒ 2.9 Phát truển một Web server

FTP: file transfer protocol

file transfer FTP

server

FTP user interface

FTP client

local file system

remote file system

FTP: phân biệt hai kết nối điều khiển/dữ

trên kết nối điều khiển

❒ Client gửi lệnh qua kết nối điều

FTPclient

FTPserver

❒ Khi nhận được lệnh chuyển tệp,

server mở kết nối TCP trên

cổng 20 đến client để truyền

tệp

❒ Sau khi truyền xong một tệp,

server đóng kết nối dữ liệu

❒ Server mở kết nối TCP thứ hai

để truyền tệp thứ hai

❒ Kết nối điều khiển: “out of band”

❒ FTP server duy trì “trạng thái”: thư mục hiện tại, xác thực trước đây

Lệnh FTP, đáp ứng

Ví dụ lệnh:

❒ Được gửi văn bản mã ASCII

qua kênh điều khiển

❒ 125 data connection already open;

❒ 2.7 Lập trình socket với TCP

❒ 2.9 Phát truển một Web server

mail server

user agent

user

mail server

user agent

SMTP

SMTPUser Agent

mail server

user agent user

agent

SMTP SMTP

user agent

user

mail server

user agent

SMTP

2: Tầng ứng dụng 50

❒ Giao thức SMTP giữa các

mail servers để chuyển thư

❍ client: mail server gửi

❍ “server”: mail server

nhận

server user

agent

user agent

mail server

user agent user

agent

SMTP SMTP

❍ commands: ASCII text

❍ response: mã và miêu tả trạng thái

❒ Thư phải ở dạng 7-bit ASCII

Kịch bản: Alice gửi thư cho Bob

1) Alice sử dụng UA để soạn

thư với “to”

bob@someschool.edu

2) UA của Alice gửi thư đến

mail server của cô ta; thư

được lưu ở message queue

3) Phía client của SMTP trên

mail server c a Alice m

4) SMTP client gửi thư của Alice’s qua kết nối TCP5) Mail server của Bob lưu the trong mailbox của Bob

6) Bob chạy UA của anh ta và đọc thư

2: Tầng ứng dụng 52

3) Phía client của SMTP trên

mail server của Alice mở

kết nối TCP với mail server

của Bob

user

agent

mail server

Ví dụ tương tác SMTP

S: 220 hamburger.edu

C: HELO crepes.fr

S: 250 Hello crepes.fr, pleased to meet you

C: MAIL FROM: <alice@crepes.fr>

Tự thử tương tác SMTP:

❒ telnet servername 25

❒ Xem trả lời 220 từ server

DATA, QUIT

2: Tầng ứng dụng 54

❒ SMTP sử dụng kết nối bền

vững

❒ SMTP yêu cầu thư (header

& body) ở dạng 7-bit ASCII

thúc thư command/response với mã ASCII , các mã trạng thái

❒ HTTP: mỗi đối tượng được chứa bên trong một thông báo trả lời

❒ SMTP: nhiều đối tượng được gửi trong thông báo có

nhiều phần

Định dạng thư

SMTP: giao thức dùng cho

trao đổi email

RFC 822: chuẩn cho format

thông báo bằng văn bản:

Định dạng thư: các mở rộng multimedia

❒ MIME: multimedia mail extension, RFC 2045, 2056

❒ Các dòng được thêm vào tiêu đề thư khai báo các dạng nội

dung MIME

From: alice@crepes.fr To: bob@hamburger.edu

PhiMIME version To: bob@hamburger.edu

Subject: Picture of yummy crepe MIME-Version: 1.0

Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data

Các giao thức truy cập email

❒ SMTP: truyền email đến server nhận

user agent

sender’s mail server

user agent

protocol

receiver’s mail server

2: Tầng ứng dụng 58

❒ SMTP: truyền email đến server nhận

❒ Giao thức truy cập email: nhận email từ server

❍ POP: Post Office Protocol [RFC 1939]

• Xác thực (agent < >server) và download

❍ IMAP: Internet Mail Access Protocol [RFC 1730]

• Nhiều tính năng hơn (phức tạp hơn)

• Quản lý các thư được lưu trên server

❍ HTTP: Hotmail , Yahoo! Mail, Gmail, …

S: +OK POP3 server ready C: user bob

S: +OK C: pass hungry S: +OK user successfully logged on

❍ +OK

❍ -ERR

Pha giao dịch, client:

❒ list: liệt kê các số hiệu thư

❒ retr: nhận thư theo số hiệu

❒ dele: delete

❒ quit

S: C: retr 1 S: <message 1 contents>

S: C: dele 1 C: retr 2 S: <message 1 contents>

S: C: dele 2 C: quit S: +OK POP3 server signing off

POP3 (tiếp) và IMAP

Tiếp về POP3

❒ Ví dụ trước sử dụng chế

độ “download and

delete”.

❒ Bob không thể đọc lại

e-mail nếu anh ta thay

IMAP

❒ Giữ mọi thư trên server

❒ Cho phép người dùng sắp xếp thư theo thư mục

❍ Tên của các thư mục và ánh xạ giữa định danh thư và tên thư mục

❒ 2.7 Lập trình socket với TCP

❒ 2.9 Phát truển một Web server

Domain Name System:

❒ Cơ sở dữ liệu phân tán được cài đặt theo kiến trúc phân cấp các name servers

❒ Giao thức tầng ứng dụng host, routers, name servers giao

❍ Ghi chú: chức năng lõi Internet, được cài đặt nhưgiao thức tầng ứng dụng

❍ Phức tạp ở biên mạng

❒ Đặt bí danh cho Host

❍ Tên gốc và các bí danh ❒ CSDL tập trung ở xa

Root DNS Servers

poly.edu DNS servers

umass.edu DNS servers

yahoo.com

DNS servers

amazon.com DNS servers

pbs.org DNS servers

CSDL phân cấp, phân tán

2: Tầng ứng dụng 64

Client muốn biết địa chỉ IP của www.amazon.com :

❒ Client yêu cầu root server tìm com DNS server

❒ Client truy vấn com DNS server để biết

amazon.com DNS server

❒ Client truy vấn amazon.com DNS server để lấy địa

chỉ IP của www.amazon.com

DNS: Root name servers

❒ Được liên lạc bởi name server địa phương nếu name server không biết địa chỉ IP tương ứng tên

❒ root name server:

❍ Liên lạc name server có thẩm quyền nếu không biết ánh xạ tên

❍ Lấy ánh xạ tên

❍ Trả ánh xạ tên cho name server địa phương

❍ Trả ánh xạ tên cho name server địa phương

13 root name servers worldwide

b USC-ISI Marina del Rey, CA

l ICANN Los Angeles, CA

e NASA Mt View, CA

f Internet Software C Palo Alto,

CA (and 17 other locations)

i Autonomica, Stockholm (plus 3

c Cogent, Herndon, VA (also Los Angeles)

d U Maryland College Park, MD

g US DoD Vienna, VA

h ARL Aberdeen, MD

j Verisign, ( 11 locations)

TLD Server và Servers thẩm

quyền

nhiệm cho com, org, net, edu, …, và tất cả các tên miền cấp một các quốc gia như uk, fr, ca, jp.

❍ Network solutions duy trì các servers cho com

2: Tầng ứng dụng 66

❍ Network solutions duy trì các servers cho com

TLD

❍ Educause duy trì các servers cho edu TLD

các tổ chức, cung cấp ánh xạ tên miền sang địa chỉ IP cho các servers của tổ chức (vd., Web mail).

❍ Có thể được bảo trì bởi tổ chức hoặc nhà cung cấp dịch vụ

Local Name Server

❒ Không nhất thiết phải thuộc hệ thống phân

cấp

❒ Mỗi ISP (ISP địa phương, công ty, trường

học) có một LNS.

học) có một LNS.

❍ Còn được gọi là “default name server”

❒ Khi một host tạo một truy vấn DNS, truy

vấn được gửi đến DNS địa phương

❍ Hoạt động như một proxy, chuyển truy vấn đến

hệ thống phân cấp.