Computer Networking - Chương 3: Lớp Transport pptx

Các giao th c l p transport trên ứ ớ❒ không tin cậy, truyền không theo application transport network data link physical network data link physical network data link physical network da

Transport trên Internet:

❍ UDP: v n chuy n không k t ậ ể ế

n i (connectionless)ố

❍ TCP: v n chuy n h ng k t ậ ể ướ ế

n i (connection-oriented)ố

❍ đi u khi n t c ngh nề ể ắ ẽ TCP

Ch ng 3: N i dung trình bày ươ ộ

3.1 Các d ch v l p Transport ị ụ ớ

Các d ch v và giao th c ị ụ ứ

Transport

❒ cung cấp truyền thông

đo n thành các thông đi p, ạ ệ

chuy n cho l p application ể ớ

❒ có nhiều hơn 1 giao thức

transport dành cho các

ứng dụng

application transport network data link physical

application transport network data link physical

network data link physical

network data link physical

network data link physical

network data link physical network

data link physical

log ica

l en d-e

nd t ran sport

12 đứa trẻ gửi thư đến

12 đứa trẻ khác

❒ các tiến trình = các đứa trẻ

❒ các thông điệp = thư trong bao thư

❒ các host = các gia đình

❒ giao thức transport = Ann và Bill

❒ giao thức lớp network

= dịch vụ bưu điện

Các giao th c l p transport trên ứ ớ

❒ không tin cậy,

truyền không theo

application transport network data link physical

network data link physical

network data link physical

network data link physical

network data link physical network

data link physical

log ica

l en d-e

nd t ran sport

3.2 Multiplexing và

demultiplexing

link physical

application transport network link physical

❒ host dùng địa chỉ IP &

số port để điều hướng

d ng th c đo n TCP/UDPạ ứ ạ

(địa chỉ IP, số port đích)

❒ Khi host nhận đoạn UDP:

❍ ki m tra port đích trong ể

đo nạ

❍ đi u h ng đo n UDP đ n ề ướ ạ ếsocket nào phù h p v i s ợ ớ ốport đó

❒ IP datagrams với địa chỉ IP nguồn và/hoặc

số port khác nhau có thể được điều hướng đến cùng socket

Demultiplexing không k t n i ế ố

(tt)

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P2

client

IP: A

P1P1 P3

serverIP: C

SP: 6428 DP: 9157

SP: 9157 DP: 6428

SP: 6428 DP: 5775

SP: 5775 DP: 6428

SP cung c p “đ a ch tr v ”ấ ị ỉ ở ề

❍ m i socket đ c xác đ nh ỗ ượ ị

b i b 4 c a nóở ộ ủ

❒ Web server có các socket khác nhau cho mỗi kết nối từ client

❍ k t n i HTTP không b n ế ố ề

v ng s có socket khác ữ ẽnhau cho m i yêu c uỗ ầ

Demultiplexing h ng k t n i ướ ế ố

(tt)

ClientIP:B

P1

client

IP: A

P1 P2

P4

serverIP: C

SP: 9157 DP: 80

SP: 9157 DP: 80

D-IP:C

S-IP: A D-IP:C

S-IP: B

SP: 5775 DP: 80 D-IP:C S-IP: B

Demultiplexing h ng k t n i: ướ ế ố

Threaded Web Server

ClientIP:B

P1

client

IP: A

P1 P2

serverIP: C

SP: 9157 DP: 80

SP: 9157 DP: 80

D-IP:C

S-IP: A D-IP:C

S-IP: B

SP: 5775 DP: 80 D-IP:C S-IP: B

3.3 V n chuy n không k t n i: ậ ể ế ố

UDP

UDP: User Datagram Protocol [RFC 768]

❒ header của đoạn nhỏ

❒ không điều khiển tắc nghẽn: UDP có thể gửi nhanh nhất theo mong muốn

❒ truyền tin cậy trên

UDP: thêm khả năng này

d ng th c đo n UDPạ ứ ạ

length checksum

Đ dài ộ

đo n UDP ạ bao g m c ồ ả

header

UDP checksum

bên gửi:

❒ đối xử các nội dung

đoạn như một chuỗi

❍ NO – có l i x y ra ỗ ả

❍ YES – không có l i ỗ

❍ Nh ng có th còn l i khác ư ể ỗ

n a?ữ Xem ti p ph n sau … ế ầ

M c tiêu: ụ ki m tra các “l i” (các bit c đã b t lên) ể ỗ ờ ậ

trong các đo n đã truy n ạ ề

3.4 Các nguyên lý c a vi c ủ ệ truy n d li u tin c y ề ữ ệ ậ

Các nguyên lý truy n d li u tin ề ữ ệ

c y ậ

❒ quan trọng trong các lớp application, transport, link

❒ là danh sách 10 vấn đề quan trọng nhất của mạng

❒ các đặc thù của kênh truyền không tin cậy sẽ xác định sự phức

tạp của giao thức truyền dữ liệu data transfer protocol (rdt)

Các nguyên lý truy n d li u tin ề ữ ệ

c y ậ

❒ quan trọng trong các lớp application, transport, link

❒ là danh sách 10 vấn đề quan trọng nhất của mạng

❒ các đặc thù của kênh truyền không tin cậy sẽ xác định sự phức tạp của giao thức

truyền dữ liệu data transfer protocol (rdt)

Các nguyên lý truy n d li u tin ề ữ ệ

c y ậ

❒ quan trọng trong các lớp application, transport, link

❒ là danh sách 10 vấn đề quan trọng nhất của mạng

❒ các đặc thù của kênh truyền không tin cậy sẽ xác định sự phức tạp của giao thức

truyền dữ liệu data transfer protocol (rdt)

Truy n d li u tin c y ề ữ ệ ậ

Sẽ:

❒ chỉ xem xét truyền dữ liệu theo 1

hướng duy nhất

❍ nh ng đi u khi n lu ng thông tin s theo c 2 chi u!ư ề ể ồ ẽ ả ề

❒ dùng máy trạng thái hữu hạn (finite

state machines-FSM) để xác định bên

Rdt1.0: truy n d li u tin c y trên 1 kênh truy n tin ề ữ ệ ậ ề

❒ kênh ưu tiên tin cậy hoàn toàn

❍ không có các l iỗ

❍ không m t mát các góiấ

❒ các FSM phân biệt cho bên gửi, bên nhận:

❍ bên g i g i d li u vào kênh u tiênử ử ữ ệ ư

❍ bên nh n nh n d li u t kênh u tiênậ ậ ữ ệ ừ ư

chờ gọi

từ lớp dưới

rdt_rcv(packet)

Rdt2.0: kênh v i các l i ớ ỗ

❒ kênh ưu tiên có thể bật lên một số bit trong gói

❍ checksum đ ki m tra các l i ể ể ỗ

❍ các acknowledgements (ACK): bên nh n rõ ràng thông báo cho ậ bên g i r ng quá trình nh n gói t t ử ằ ậ ố

❍ các negative acknowledgements (NAK): bên nh n rõ ràng thông ậ báo cho bên g i r ng quá trình nh n gói có l i ử ằ ậ ỗ

❍ bên g i g i l i gói nào đ c xác nh n là NAK ử ử ạ ượ ậ

❒ các cơ chế mới trong rdt2.0 (sau rdt1.0):

❍ ki m tra l i ể ỗ

❍ nh n ph n h i: các thông đi p đi u khi n (ACK,NAK) bên nh n ậ ả ồ ệ ề ể ậ

 bên g i ử

chờ ACK hoặc NAK

chờ gọi từ lớp dướibên g i ử

bên nh n ậrdt_send(data)

Λ

chờ ACK hoặc NAK

chờ gọi từ lớp dưới rdt_send(data)

Λ

chờ ACK hoặc NAK

chờ gọi từ lớp dưới rdt_send(data)

Λ

rdt2.0 có l h ng nghiêm tr ng! ỗ ổ ọ

Điều gì xảy ra nếu

ACK/NAK bị hỏng?

❒ bên gửi không biết

điều gì đã xảy ra tại

bên nhận!

❒ không thể đơn phương

truyền lại: khả năng

trùng lặp

Quản lý trùng lặp:

❒ bêngửi truyền lại gói hiện tại nếu ACK/NAK bị hỏng

❒ bên gửi thêm số thứ tự

vào mỗi gói

❒ bên nhận hủy (không nhận) gói trùng lặp

bên g i g i 1 gói, ử ửsau đó d ng l i ch ph n h iừ ạ ờ ả ồ

từ bên nhận

Λ Λ

rdt2.1: bên g i qu n lý các ACK/NAK b ử ả ị

h ng ỏ

chờ

0 từ dưới

sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) &&

not corrupt(rcvpkt) &&

has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

chờ

1 từ dưới

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)

extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) &&

(corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

❍ tr ng thái ch rõ có hay ạ ỉkhông mong ch s th ờ ố ứ

t 0 ho c 1 ự ặ

❒ chú ý: bên nhận không biết ACK/NAK vừa rồi của nó có được bên gửi nhận tốt hay không

❍ bên nh n ph i ậ ả rõ ràng chèn s th t c a gói v a ACKố ứ ự ủ ừ

❒ trùng ACK tại bên gửi hậu quả giống như

hành động của NAK: truyền lại gói vừa rồi

rdt2.2: g i, nh n các m nh ử ậ ả

Chờ cho gọi 0 từ trên

sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt)

g i phân m nhử ả

FSM

Chờ cho gọi

0 từ dưới

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

❒ truyền lại nếu không nhận ACK trong khoảng thời gian này

❒ nếu gói (hoặc ACK) chỉ trễ (không mất):

❍ truy n l i s gây trùng, nh ng ề ạ ẽ ư dùng s th t s gi i quy t ố ứ ự ẽ ả ế

đ c ượ

❍ bên nh n ph i xác đ nh s th ậ ả ị ố ứ

t c a gói v a g i ACK ự ủ ừ ử

❒ cần bộ định thì đếm lùi

rdt3.0 g i ử

sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt)

start_timer rdt_send(data)

Chờ cho ACK 0

rdt_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

Chờ cho gọi 1

từ trên

sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)

start_timer rdt_send(data)

udt_send(sndpkt) start_timer

từ trên

Chờ cho ACK 1

Λ rdt_rcv(rcvpkt)

Λ Λ

Λ

hành đ ng c a rdt3.0 ộ ủ

hành đ ng c a rdt3.0 ộ ủ

L (đ dài gói tính b ng bits)ộ ằ

R (t c đ truy n, bps)ố ộ ề =

❍ gói 1KB m i 30 msec -> 33kB/s trên đ ng truy n 1 Gbpsỗ ườ ề

❍ giao th c network h n ch vi c dùng các tài nguyên v t lý!ứ ạ ế ệ ậ

rdt3.0: ho t đ ng d ng-và-ch ạ ộ ừ ờ

gói đầu tiên đã truyền, t = 0

RTT

gói cuối cùng đã truyền, t = L / R

gói đầu tiên đã đến gói cuối cùng đã đến, gửi ACK

ACK đến, gửi gói kế tiếp,

t = RTT + L / R

30.008 = 0.00027 microsec

L / R RTT + L / R =

Các giao th c Pipelined ứ

Pipelining: bên gửi cho phép gửi nhiều

gói đồng thời, không cần chờ báo nhận

được

❍ nhóm các s th t ph i tăng d nố ứ ự ả ầ

❍ ph i có b nh đ m t i n i g i và/ho c n i nh nả ộ ớ ệ ạ ơ ử ặ ơ ậ

❒ hai dạng phổ biến của các giao thức

pipelined: go-Back-N, Lặp có lựa chọn

3 * L / R RTT + L / R =

Bên gửi:

❒ k-bit số thứ tự trong header của gói

❒ “cửa sổ” tăng lên đến N, cho phép gửi các gói liên tục không cần ACK

❒ ACK(n): ACKs t t c các gói đ n, ch a s th t n – “ACK tích ấ ả ế ứ ố ứ ự

lũy”

❍ có th nh n các ACK trùng l p (xem bên nh n)ể ậ ặ ậ

❒ đ nh thì cho m i gói trên đ ng truy nị ỗ ườ ề

❒ timeout(n): g i l i gói n và t t c các gói có s th t cao h n ử ạ ấ ả ố ứ ự ơ

GBN: bên g i m r ng FSM ử ở ộ

chờ start_timerudt_send(sndpkt[base])

udt_send(sndpkt[base+1])

… udt_send(sndpkt[nextseqnum- 1])

timeout

rdt_send(data)

if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum])

if (base == nextseqnum) start_timer

nextseqnum++

} else refuse_data(data)

rdt_rcv(rcvpkt)

&& corrupt(rcvpkt)

Λ

deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt)

GBN

ho t đ ng ạ ộ

L p có l a ch n ặ ự ọ

❒ bên nhận thông báo đã nhận đúng tất cả

từng gói một

❍ đ m (buffer) các gói n u c n thi tệ ế ầ ế

❒ bên gửi chỉ gửi lại các gói nào không

nhận được ACK

❍ bên g i đ nh thì đ i v i m i gói không g i ACKử ị ố ớ ỗ ử

❒ cửa sổ bên gửi

❍ N s th t liên t cố ứ ự ụ

❍ h n ch s th t các gói không g i ACKạ ế ố ứ ự ử

L p có l a ch n: các c a s g i, nh n ặ ự ọ ử ổ ử ậ

Ho t đ ng c a l p có l a ch n ạ ộ ủ ặ ự ọ

3.5 V n chuy n h ng k t ậ ể ướ ế

n i: TCP ố

TCP: T ng quan ổ RFCs: 793, 1122, 1323, 2018, 2581

❒ dữ liệu full duplex:

❍ lu ng d li u đi 2 chi u ồ ữ ệ ề trong cùng m t k t n i ộ ế ố

❍ MSS: maximum segment size – kích th c đo n t i ướ ạ ố đa

❒ hướng kết nối:

❍ b t tay (trao đ i các ắ ổ thông đi p đi u khi n) ệ ề ể

tr ng thái bên g i, bên ạ ử

nh n tr c khi trao đ i ậ ướ ổ

d li u ữ ệ

❒ điều khiển luồng:

❍ bên g i s không l n át ử ẽ ấ bên nh n ậ

TCP: c u trúc đo n ấ ạ

port # ngu nồ port # đích

32 bits

d li u ng d ngữ ệ ứ ụ(đ dài thay đ i)ộ ổ

s th tố ứ ự

s ACKố

c a s nh n ử ổ ậ con tr URG ỏ checksum

F S R P A U

head len usednot

Tùy ch n (đ dài thay đ i)ọ ộ ổ

URG: d li u kh n c p ữ ệ ẩ ấ

(th ng không dùng) ườ

ACK: ACK #

h p l ợ ệ PSH: push data now

nh n ậ

đ m b i s byte ế ở ố

c a d li u ủ ữ ệ

Internet checksum (gi ng UDP) ố

‘C’, ph n h i ả ồ

ng c l i ‘C’ ượ ạ

time

tình hu ng telnet đ n gi n ố ơ ả

TCP Round Trip Time vàTimeout

❒ SampleRTT: thời gian được

đo từ khi truyền đoạn đến khi báo nhận ACK

❍ l đi vi c truy n l iờ ệ ề ạ

muốn ước lượng RTT “mượt hơn”

❍ tính trung bình m t s giá tr ộ ố ị

đo đ c g n đó, không ch ượ ầ ỉ

SampleRTT hi n t i ệ ạ

TCP Round Trip Time và Timeout

❒ giá tr đ c tr ng: ị ặ ư α = 0.125

Ví d đánh giá RTT: ụ

TCP Round Trip Time và Timeout

Thiết lập timeout

❒ EstimtedRTT cộng “hệ số dự trữ an toàn”

❍ s bi n thiên l n trong ự ế ớ EstimatedRTT -> h s d tr an toàn l n h nệ ố ự ữ ớ ơ

❒ ước lượng đầu tiên về sự biến thiên của SampleRTT từ

❍ l đi các ack trùng l pờ ặ

❍ l đi đi u khi n lu ng, ờ ề ể ồ

đi u khi n t c ngh nề ể ắ ẽ

thì nếu chưa chạy

❒ khoảng thời gian

Ack đã nhận:

❍ c p nh t cái gì s đ c ậ ậ ẽ ượACK

❍ kh i đ ng b đ nh thì ở ộ ộ ị

n u có các đo n còn ch ế ạ ờ

event: data received from application above

create TCP segment with sequence number NextSeqNum

if (timer currently not running)

start timer

pass segment to IP

NextSeqNum = NextSeqNum + length(data)

event: timer timeout

retransmit not-yet-acknowledged segment with

smallest sequence number

= 100

= 120

kế tiếp, gửi ACK

Gửi ngay một ACK tích lũy, chấp nhận cho cả các đoạn theo thứ tự

Gửi ngay ACK trùng lặp, chỉ thị số thứ tự đoạn của byte kế tiếp đang mong chờ

Gửi ngay ACK, với điều kiện là đoạn bắt đầu ngay điểm có khoảng trống

❍ bên g i th ng g i nhi u ử ườ ử ề

đo n song songạ

❍ N u đo n b m t, s x y ế ạ ị ấ ẽ ả

ra tình tr ng gi ng nh ạ ố ư

nhi u ACK trùng nhauề

❒ Nếu bên gửi nhận 3 ACK của cùng một

dữ liệu, nó cho là đoạn sau dữ liệu

đã ACK bị mất:

đo n tr c khi b đ nh ạ ướ ộ ịthì h t h nế ạ

sự kiện: ACK đã nhận, với trường là y

increment count of dup ACKs received for y

if (count of dup ACKs received for y = 3) {

resend segment with sequence number y

❒ ti n trình ng d ng có ế ứ ụ

th ch m t i lúc đ c ể ậ ạ ọ

b đ m ộ ệ

bên g i s không làm ử ẽtràn b đ m vì truy n ộ ệ ềquá nhi u và quá nhanhề

đi u khi n lu ng ề ể ồ

ACK vào RcvWindow

❍ b o đ m b đ m nh n ả ả ộ ệ ậkhông tràn

TCP qu n lý k t n i ả ế ố

Chú ý: Bên gửi và bên nhận

TCP thiết lập “kết nối”

trước khi trao đổi dữ liệu

❒ khởi tạo các biến TCP:

Bước 1: client host gửi đoạnTCP SYN đến server

❍ xác đ nh s th t kh i đ u ị ố ứ ự ở ầ

❍ không ph i d li u ả ữ ệ

Bước 2: server host nhận SYN, trả lời với đoạn SYNACK

❍ server c p phát các b đ m ấ ộ ệ

❍ xác đ nh s th t kh i đ u ị ố ứ ự ở ầ

Bước 3: client nhận SYNACK, trả lời với đoạn ACK (có thể chứa dữ liệu)

TCP qu n lý k t n i (tt) ả ế ố

Đóng một kết nối:

client đóng socket:

clientSocket.close();

Bước 1: client gửi đoạn

điều khiển TCP FIN đến

server

Bước 2: server nhận

FIN, trả lời với ACK

Đóng kết nối, gửi FIN

TCP qu n lý k t n i (tt) ả ế ố

Bước 3: client nhận

FIN, trả lời với ACK

❍ Trong kho ng “th i gian ả ờ

TCP qu n lý k t n i (tt) ả ế ố

chu kỳ s ng c aố ủ

TCP client

chu kỳ s ng c aố ủTCP server

3.6 Các nguyên lý c a đi u ủ ề

khi n t c ngh n ể ắ ẽ

Các nguyên lý đi u khi n t c ngh n ề ể ắ ẽ

❒ năng suất có thể đạt tối

unlimited shared output link buffers

Host A

λ in : original data

Host B

λ out

Các nguyên nhân/chi phí c a t c ngh n: ủ ắ ẽ

tình hu ng 2 ố

❒ luôn luôn:

❒ truyền lại “hoàn toàn” chỉ khi mất mát:

❒ truyền lại vì trễ (không mất) làm cho lớn hơn với cùng

chia sẻ vô hạn các bộ đệm ouput

Các nguyên nhân/chi phí c a t c ngh n: ủ ắ ẽ

tình hu ng 3 ố

“chi phí” khác c a t c ngh n: ủ ắ ẽ

❒ khi các gói b b , b t kỳ “kh năng truy n ị ỏ ấ ả ề

upstream dùng cho gói đó s b lãng phí!” ẽ ị

H o s

t A

H o s

t B

λ

o u t

❒ các router cung cấp phản hồi về các hệ thống đầu cuối

❍ 1 bit duy nh t ch th t c ấ ỉ ị ắ ngh n (SNA, DECbit, ẽ

TCP/IP ECN, ATM)

❍ t c đ s g i đ c xác ố ộ ẽ ử ượ

đ nh rõ ràng ị

2 cách:

Ví d : đi u khi n t c ngh n ATM ABR ụ ề ể ắ ẽ

❒ gửi bởi bên gửi, rải rác với các ô dữ liệu

❒ các bit trong ô thiết lập bởi các switch

❍ bit NI : không tăng t c đ ố ộ (t c ngh n nh ) ắ ẽ ẹ

❍ bit CI : t c ngh n rõ r t ắ ẽ ệ

❒ Các ô RM được trả về bên gửi từ bên nhận với nguyên vẹn các bit

Ví d : đi u khi n t c ngh n ATM ABR ụ ề ể ắ ẽ

❒ trường 2-byte ER trong ô RM

❍ switch đã t c ngh n có th có giá tr ER th p h n trong ôắ ẽ ể ị ấ ơ

❍ t c đ g i do đó có th đ c h tr t i đa trên đ ngố ộ ử ể ượ ỗ ợ ố ườ

❒ EFCI bit trong các ô dữ liệu: được cài

giá trị 1 trong switch đã tắc nghẽn

❍ n u ô d li u đ ng tr c ô RM có cài EFCI, bên g i s cài ế ữ ệ ứ ướ ử ẽ

3.7 Đi u khi n t c ngh n TCP ề ể ắ ẽ