Chương 5

Lớp Transport

Computer Networking:
A Top Down Approach
Featuring the Internet,
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2004.

J.F Kurose and K.W. Ross, All Rights Reserved Lớp Transport 1
Chương 5: Lớp Transport
Mục tiêu:
D hiểu các nguyên tắc
đằng sau các dịch vụ
lớp transport:
O multiplexing/demultipl
exing
O truyền dữ liệu tin cậy
O điều khiển luồng
O điều khiển tắc nghẽn
D nghiên cứu về các giao
thức lớp Transport trên
Internet:
O UDP: vận chuyển không kết
nối (connectionless)
O TCP: vận chuyển hướng kết
nối (connection-oriented)
O điều khiển tắc nghẽn TCP
Lớp Transport 2
Chương 5: Nội dung trình bày
D 5.1 Các dịch vụ D 5.5 Vận chuyển hướng
lớp Transport kết nối: TCP
D 5.2 Multiplexing O cấu trúc phân đoạn
và demultiplexing O truyền dữ liệu tin cậy
điều khiển luồng
D 5.3 Vận chuyển
O

quản lý kết nối

không kết nối: UDP O

D 5.6 Các nguyên lý của

D 5.4 Các nguyên lý
điều khiển tắc nghẽn
của việc truyền dữ
liệu tin cậy D 5.7 Điều khiển tắc
nghẽn TCP

Transport Layer 3-3

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

Lớp Transport 4
Các dịch vụ và giao thức Transport
D cung cấp truyền thông logic application
transport
chạy trên các host khác nhau network
data link network
D các giao thức transport chạy physical
network
data link
physical
trên các hệ thống đầu cuối data link
physical

O phía gửi: cắt các thông network

data link
điệp ứng dụng thành các physical network
data link
đoạn, chuyển cho lớp physical

network network
data link
physical
O phía nhận: tái kết hợp các
đoạn thành các thông điệp, application
transport
chuyển cho lớp application network
data link

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

physical

transport dành cho các ứng

dụng
O Internet: TCP và UDP
Lớp Transport 5
Lớp Transport với lớp network
D lớp network: truyền
thông logic giữa các
host
D lớp transport:
truyền thông logic
giữa các tiến trình
O dựa vào và làm nổi bật
các dịch vụ lớp network
Tình huống tự nhiên tương
tự:
12 đứa trẻ gửi thư đến 12
đứa trẻ khác
D các tiến trình = các đứa
trẻ
D c á c thông điệp =
thư trong bao thư
D c á c host = các gia đình
D g i a o thức transport
= Ann và Bill
D g i a o thức lớp network
= dịch vụ bưu điện
Lớp Transport 6
Các giao thức lớp transport trên
Internet
D tin cậy, truyền theo application
transport

thứ tự (TCP) network

data link network
physical data link
O thiết lập kết nối network physical
data link
O điều khiển tắc nghẽn physical
network

O điều khiển luồng

data link
physical network
data link
D không tin cậy, truyền physical

không theo thứ tự: UDP

network
data link
physical
O mở rộng của giao thức IP
application
D không có các dịch vụ: transport
network
data link
O bảo đảm trễ physical

O bảo đảm bandwidth

Lớp Transport 7
5.2 Multiplexing và
demultiplexing

Lớp Transport 8
 Multiplexing/demultiplexing
Demultiplexing tại host nhận: Multiplexing tại host gửi:
thu nhặt dữ liệu từ nhiều
vận chuyển các đoạn đã nhận
socket, đóng gói dữ liệu với
được đến đúng socket
header (sẽ dùng sau đó cho
demultiplexing)
= socket = tiến trình

P1 P2 P4 application
application P3 P1 application

transport transport transport

network network network

link link link

physical physical physical

host 2 host 3
host 1
Lớp Transport 9
Demultiplexing làm việc như thế nào
D host nhận các IP datagrams
O mỗi datagram có địa chỉ IP
nguồn và IP đích
O mỗi datagram mang 1 đoạn
của lớp transport
O mỗi đoạn có số port nguồn
và đích
D host dùng địa chỉ IP & số
port để điều hướng đoạn đến
socket thích hợp

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

Lớp Transport 10
Demultiplexing không kết nối
D Tạo các sockets với các số
port:
DatagramSocket mySocket1 = new
DatagramSocket(12534);
DatagramSocket mySocket2 = new
DatagramSocket(12535);
D UDP socket được xác định
bởi bộ 2:
(địa chỉ IP, số port đích)
D Khi host nhận đoạn UDP:
O kiểm tra port đích trong
đoạn
O điều hướng đoạn UDP đến
socket nào phù hợp với số
port đó
D 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
Lớp Transport 11
 Demultiplexing không kết nối
(tt)
DatagramSocket serverSocket = new DatagramSocket(6428);

P1
P2 P3 P1

SP: 6428 SP: 6428

DP: 9157 DP: 5775

SP: 9157 SP: 5775

client DP: 6428 DP: 6428 Client
server
IP: A IP: C IP:B

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

Lớp Transport 12
 Demultiplexing hướng kết nối
D TCP socket được xác D Host server có thể
định bởi bộ 4: hỗ trợ nhiều TCP
O địa chỉ IP nguồn socket đồng thời:
O số port nguồn O mỗi socket được xác định
O địa chỉ IP đích bởi bộ 4 của nó
O số port đích D Web server có các
D host nhận dùng cả 4 socket khác nhau cho mỗi
giá trị trên để điều kết nối từ client
hướng đoạn đến socket O kết nối HTTP không bền
thích hợp vững sẽ có socket khác
nhau cho mỗi yêu cầu

Lớp Transport 13
Demultiplexing hướng kết nối
(tt)

P1
P1 P4 P5 P6 P2 P3

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

SP: 9157 SP: 9157

client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C
S-IP: B IP:B
D-IP:C D-IP:C

Lớp Transport 14
Demultiplexing hướng kết nối:
Threaded Web Server

P1
P1 P4 P2 P3

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

SP: 9157 SP: 9157

client DP: 80 DP: 80 Client
server
IP: A S-IP: A
IP: C
S-IP: B IP:B
D-IP:C D-IP:C

Lớp Transport 15
5.3 Vận chuyển không kết nối:
UDP

Lớp Transport 16
UDP: User Datagram Protocol [RFC 768]
D giao thức Internet
transport “đơn giản hóa”
Có UDP để làm gì?
D không thiết lập kết nối (giúp
D dịch vụ “best effort”, các
đoạn UDP có thể: có thể thêm delay)
D đơn giản: không trạng thái
O mất mát
kết nối tại nơi gửi, nơi nhận
O vận chuyển không thứ tự
D header của đoạn nhỏ
đến ứng dụng
D không điều khiển tắc nghẽn:
D connectionless (không kết
UDP có thể gửi nhanh nhất
nối):
theo mong muốn
O không bắt tay giữa bên
nhận và bên gửi UDP
O mỗi đoạn UDP được quản
lý độc lập

Lớp Transport 17
UDP: (tt)
D thường dùng cho các ứng
dụng streaming multimedia 32 bits
source port # dest port #
O chịu mất mát Độ dài
O cảm nhận tốc độ đoạn UDP length checksum
bao gồm cả dữ liệu
D ngoài ra, UDP dùng header ứng dụng
O DNS
(thông điệp)
O SNMP
D truyền tin cậy trên UDP:
thêm khả năng này tại lớp
application
O sửa lỗi

dạng thức đoạn UDP

Lớp Transport 18
UDP checksum
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

bên gửi: bên nhận:

D đối xử các nội dung đoạn D tính toán checksum của đoạn
như một chuỗi các số đã nhận
nguyên 16-bit D kiểm tra giá trị trên có bằng
D checksum: bổ sung(tổng với giá trị trong trường
bù 1) của các nội dung checksum:
đoạn O NO – có lỗi xảy ra
D đặt giá trị checksum vào O YES – không có lỗi.
trường UDP checksum O Nhưng có thể còn lỗi khác
nữa? Xem tiếp phần sau ….

Lớp Transport 19
 Ví dụ Checksum
D Lưu ý
O Khi cộng các số, một bit nhớ ở phía cao nhất có
thể sẽ phải thêm vào kết quả
D Ví dụ: cộng hai số nguyên 16-bit

1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
bit dư

tổng 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Lớp Transport 20
5.4 Các nguyên lý của việc
truyền dữ liệu tin cậy

Lớp Transport 21
Các nguyên lý truyền dữ liệu tin cậy
D quan trọng trong các lớp application, transport, link
D là danh sách 10 vấn đề quan trọng nhất của mạng

D 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)
Lớp Transport 22
Các nguyên lý truyền dữ liệu tin cậy
D quan trọng trong các lớp application, transport, link
D là danh sách 10 vấn đề quan trọng nhất của mạng

D 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)
Lớp Transport 23
Các nguyên lý truyền dữ liệu tin cậy
D quan trọng trong các lớp application, transport, link
D là danh sách 10 vấn đề quan trọng nhất của mạng

D 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)
Lớp Transport 24
 Truyền dữ liệu tin cậy
rdt_send(): được gọi bởi lớp app. deliver_data(): được gọi
Chuyển dữ liệu cần truyền đến lớp bởi rdt để truyền dữ liệu đến
cao hơn bên nhận lớp cao hơn

bên bên
gửi nhận

udt_send(): được gọi bởi rdt_rcv(): được gọi khi gói đến
rdt, để truyền các gói trên kênh bên nhận
kênh không tin cậy đến nơi
nhận
Lớp Transport 25
 Truyền dữ liệu tin cậy
Sẽ:
D chỉ xem xét truyền dữ liệu theo 1 hướng duy
nhất
O nhưng điều khiển luồng thông tin sẽ theo cả 2 chiều!
D dùng máy trạng thái hữu hạn (finite state
machines-FSM) để xác định bên gửi, bên nhận

sự kiện gây ra trạng thái truyền

các hành động xảy ra khi truyền
trạng thái: khi ở “trạng
thái” này thì trạng trthái trthái
1 sự kiện
thái kế tiếp duy nhất 2
được xác định bởi sự các hành động
kiện kế tiếp

Lớp Transport 26
Rdt1.0: truyền dữ liệu tin cậy trên 1 kênh truyền tin
cậy
D kênh ưu tiên tin cậy hoàn toàn
O không có các lỗi
O không mất mát các gói

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

O bên gửi gửi dữ liệu vào kênh ưu tiên
O bên nhận nhận dữ liệu từ kênh ưu tiên

chờ gọi rdt_send(data) chờ gọi rdt_rcv(packet)

từ lớp từ lớp extract (packet,data)
trên packet = make_pkt(data) dưới deliver_data(data)
udt_send(packet)

bên gửi bên nhận

Lớp Transport 27
Rdt2.0: kênh với các lỗi
D kênh ưu tiên có thể bật lên một số bit trong gói
O checksum để kiểm tra các lỗi

D Hỏi: làm sao khôi phục các lỗi?

O các acknowledgements (ACK): bên nhận thông báo cho
bên gửi rằng quá trình nhận gói tốt
O các negative acknowledgements (NAK): bên nhận thông
báo cho bên gửi rằng quá trình nhận gói có lỗi
O bên gửi gửi lại gói nào được xác nhận là NAK
D các cơ chế mới trong rdt2.0 (sau rdt1.0):
O kiểm tra lỗi
O 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

Lớp Transport 28
rdt2.0: đặc tả FSM
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
bên nhận
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
chờ gọi từ chờ ACK rdt_rcv(rcvpkt) &&
lớp trên hoặc udt_send(sndpkt) corrupt(rcvpkt)
NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

chờ gọi từ

lớp dưới
bên gửi
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Lớp Transport 29
rdt2.0: hoạt động khi không lỗi
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
chờ gọi từ chờ ACK rdt_rcv(rcvpkt) &&
lớp dưới hoặc udt_send(sndpkt) corrupt(rcvpkt)
NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

chờ gọi từ
 lớp dưới

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Lớp Transport 30
rdt2.0: hoạt động khi có lỗi
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
chờ gọi từ chờ ACK rdt_rcv(rcvpkt) &&
lớp dưới hoặc udt_send(sndpkt) corrupt(rcvpkt)
NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

chờ gọi từ
 lớp dưới

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Lớp Transport 31
rdt2.0 có lỗ hổng nghiêm trọng!
Điều gì xảy ra nếu Quản lý trùng lặp:
ACK/NAK bị hỏng? D bêngửi truyền lại gói hiện tại
D bên gửi không biết điều gì nếu ACK/NAK bị hỏng
đã xảy ra tại bên nhận! D bên gửi thêm số thứ tự vào
D không thể đơn phương mỗi gói
truyền lại: khả năng trùng D bên nhận hủy (không nhận)
lặp gói trùng lặp

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

Lớp Transport 32
rdt2.1: bên gửi quản lý các ACK/NAK bị
hỏng
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
chờ gọi 0 chờ ACK
hoặc NAK isNAK(rcvpkt) )
từ lớp trên udt_send(sndpkt)
0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)


chờ ACK chờ gọi 1
hoặc NAK từ lớp trên
rdt_rcv(rcvpkt) && 1
( corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)

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

udt_send(sndpkt)

rdt2.1 sender
Lớp Transport 33
 rdt2.1: bên gửi quản lý các ACK/NAK bị
hỏng
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) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
chờ chờ
rdt_rcv(rcvpkt) && 0 từ 1 từ rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && dưới dưới not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
rdt2.1 receiver udt_send(sndpkt)

Lớp Transport 34
rdt2.1: thảo luận
bên gửi:
D số thứ tự # thêm vào
gói
D chỉ cần hai số thứ
tự (0,1) là đủ. Tại
sao?
D phải kiểm tra nếu việc
nhận ACK/NAK bị hỏng
D số trạng thái tăng lên
2 lần
O trạng thái phải “nhớ” gói
“hiện tại” có số thứ tự là
0 hay 1
bên nhận:
D phải kiểm tra có
nhận trùng gói không
O trạng thái chỉ rõ có hay
không mong chờ số thứ
tự 0 hoặc 1
D 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
Lớp Transport 35
rdt2.2: một giao thức không cần
NAK
D chức năng giống như rdt2.1, chỉ dùng các ACK
D thay cho NAK, bên nhận gửi ACK cho gói vừa rồi đã
nhận tốt
O bên nhận phải rõ ràng chèn số thứ tự của gói vừa ACK
D 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

Lớp Transport 36
 rdt2.2: gửi, nhận các mảnh
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Chờ cho Chờ cho
ACK isACK(rcvpkt,1) )
gọi 0 từ
trên 0 udt_send(sndpkt)
gửi phân mảnh
FSM rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || 
has_seq1(rcvpkt)) Chờ
cho gọi
nhận phân mảnh
udt_send(sndpkt) 0 từ FSM
dưới
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Lớp Transport 37
rdt3.0: các kênh với lỗi và mất mát
Giả định mới: kênh ưu tiên
cũng có thể làm mất
các gói (dữ liệu hoặc
các ACK)
O checksum, số thứ tự, các
ACK, các việc truyền lại
sẽ hỗ trợ nhưng không đủ
Cách tiếp cận: bên gửi chờ
ACK trong khoảng thời
gian “chấp nhận được”
D truyền lại nếu không nhận ACK
trong khoảng thời gian này
D nếu gói (hoặc ACK) chỉ trễ
(không mất):
O truyền lại sẽ gây trùng,
nhưng dùng số thứ tự sẽ
giải quyết được
O bên nhận phải xác định số
thứ tự của gói vừa gửi ACK
D cần bộ định thì đếm lùi
Lớp Transport 38
rdt3.0 gửi
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer 
 Chờ cho Chờ
cho timeout
gọi 0 từ udt_send(sndpkt)
trên ACK 0
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Chờ Chờ cho
timeout cho gọi 1
udt_send(sndpkt) ACK 1 từ trên
start_timer rdt_rcv(rcvpkt)
rdt_send(data) 
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer


Lớp Transport 39
hành động của rdt3.0

Lớp Transport 40
hành động của rdt3.0

Lớp Transport 41
Hiệu suất của rdt3.0
D rdt3.0 làm việc được, nhưng đánh giá hiệu suất hơi rắc rối
D ví dụ: liên kết 1 Gbps, trễ lan truyền giữa hai đầu cuối là 15
ms, gói 1KB:
L (độ dài gói tính bằng bits) 8kb/pkt
dtrans = = = 8 microsec
R (tốc độ truyền, bps) 10**9 b/sec

O U sender: độ khả dụng –

U sender = L/R .008

= = 0.00027
RTT + L / R 30.008

O gói 1KB mỗi 30 msec -> 33kB/s trên đường truyền 1 Gbps
O giao thức network hạn chế việc dùng các tài nguyên vật lý!

Lớp Transport 42
 rdt3.0: hoạt động dừng-và-chờ
gửi nhận
gói đầu tiên đã truyền, t = 0
gói cuối cùng đã truyền, t = L / R

gói đầu tiên đã đến

RTT gói cuối cùng đã đến, gửi ACK

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

t = RTT + L / R

U sender = L/R .008

= = 0.00027
RTT + L / R 30.008

Lớp Transport 43
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
O nhóm các số thứ tự phải tăng dần
O phải có bộ nhớ đệm tại nơi gửi và/hoặc nơi nhận

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

Go-Back- N and Selective Repeat
Lớp Transport 44
 Pipelining: độ khả dụng tăng
sender receiver
gói đầu tiên đã truyền, t = 0
gói cuối cùng đã truyền,
t=L/R

gói đầu tiên đã đến

RTT gói cuối cùng đã đến, gửi ACK
bit cuối của gói thứ 2 đến, gửi ACK
bit cuối của gói thứ 3 đến, gửi ACK
ACK đến, gửi gói
kế tiếp, t = RTT + L / R

Độ khả dụng tăng lên

gấp 3 lần!

U sender = 3*L/R .024

= = 0.0008
RTT + L / R 30.008

Lớp Transport 45
Go-Back-N
Bên gửi:
D k-bit số thứ tự trong header của gói
D “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

D ACK(n): ACKs tất cả các gói đến, chứa số thứ tự n – “ACK tích lũy”
O có thể nhận các ACK trùng lặp (xem bên nhận)
D định thì cho mỗi gói trên đường truyền
D timeout(n): gửi lại gói n và tất cả các gói có số thứ tự cao hơn
trong cửa sổ
Lớp Transport 46
GBN: bên gửi mở rộng FSM
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)
base=1
nextseqnum=1
timeout
start_timer
chờ udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer Lớp Transport 47
GBN: bên nhận mở rộng FSM
default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
 && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 chờ extract(rcvpkt,data)
sndpkt = deliver_data(data)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++

ACK-duy nhất: luôn luôn gửi ACK cho gói đã nhận đúng,
với số thứ tự xếp hạng cao nhất
O có thể sinh ra các ACK trùng nhau
O chỉ cần nhớ expectedseqnum
D gói không theo thứ tự:
O hủy -> không nhận vào bộ đệm!
O gửi lại ACK với số thứ tự xếp hạng cao nhất
Lớp Transport 48
GBN
hoạt động

Lớp Transport 49
Lặp có lựa chọn
D bên nhận thông báo đã nhận đúng tất cả từng gói
một
O đệm (buffer) các gói nếu cần thiết
D bên gửi chỉ gửi lại các gói nào không nhận được
ACK
O bên gửi định thì đối với mỗi gói không gửi ACK
D cửa sổ bên gửi
O N số thứ tự liên tục
O hạn chế số thứ tự các gói không gửi ACK

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

Lớp Transport 51
Lặp có lựa chọn
Gửi
dữ liệu từ lớp trên:
D nếu số thứ tự kế tiếp sẵn
sàng trong cửa sổ, gửi gói
timeout(n):
D gửi lại gói n, tái khởi tạo bộ
định thì
ACK(n) trong
[sendbase,sendbase+N]:
D đánh dấu gói n là đã nhận
D nếu gói không ACK có n nhỏ
nhất, dịch chuyển cửa sổ
base đến số thứ tự không
ACK kế tiếp
Nhận
gói n trong [rcvbase, rcvbase+N-
1]
D gửi ACK(n)
D không thứ tự: đệm (buffer)
D có thứ tự: truyền (cũng
truyền các gói đã đệm, có
thứ tự), dịch chuyển cửa sổ
đến gói chưa nhận kế tiếp
gói n trong [rcvbase-N,rcvbase-
1]
D ACK(n)
ngược lại:
D lờ đi

Lớp Transport 52
Hoạt động của lặp có lựa chọn
Lớp Tr

ansport 53
Lặp có lựa chọn:
tình trạng khó
giải quyết
Ví dụ:
D Số thứ tự: 0, 1, 2, 3
D Kích thước cửa sổ = 3

D bên nhận không thấy

sự khác nhau trong 2
tình huống
D chuyển không chính
xác dữ liệu trùng lặp
như dữ liệu mới trong
(a)

Hỏi: quan hệ giữa dãy số

thứ tự và kích thước
cửa sổ? Lớp Transport 54
5.5 Vận chuyển hướng kết nối:
TCP

Lớp Transport 55
 TCP: Tổng quan RFCs: 793, 1122, 1323, 2018, 2581

D point-to-point: D dữ liệu full duplex:

O một bên gửi, một bên nhận O luồng dữ liệu đi 2
chiều trong cùng một
D tin cậy, dòng byte kết nối
có thứ tự: O MSS: maximum segment
O không “ranh giới thông size – kích thước đoạn tối
điệp” đa
D h ướng kết
D kênh liên lạc: nối: O bắt tay (trao đổi các
O TCP điều khiển luồng và
thông điệp điều khiển)
trạng thái bên gửi, bên
tắc nghẽn, thiết lập kích
nhận trước khi trao đổi dữ
thước cửa sổ liệu
D các bộ đệm gửi & nhận D điều khiển luồng:
application
writes data
application
reads data
O bên gửi sẽ không lấn át
bên nhận
socket socket
door door
TCP TCP
send buffer receive buffer
segment

Lớp Transport 56
 TCP: cấu trúc đoạn
32 bits
URG: dữ liệu khẩn cấp đếm bởi số byte
(thường không dùng) port # nguồn port # đích
của dữ liệu
ACK: ACK # số thứ tự
hợp lệ số ACK
head not
PSH: push data now len used
UA P R S F cửa sổ nhận
(thường không dùng) số byte bên
checksum con trỏ URG
nhận sẵn
RST, SYN, FIN: sàng chấp
Tùy chọn (độ dài thay đổi)
thiết lập kết nối nhận
(các lệnh thiết lập,
chia nhỏ)
dữ liệu ứng dụng
Internet (độ dài thay đổi)
checksum
(giống UDP)

Lớp Transport 57
 Các số thứ tự TCP và ACK
Các số thứ tự:
Host A Host B
O dòng byte “đánh
số” byte đầu tiên User
nhập
trong dữ liệu của ‘C’
đoạn host ACKs
báo nhận
các ACK: ‘C’, phản hồi
O số thứ tự của byte ngược lại ‘C’
kế tiếp được chờ đợi
từ phía bên kia host ACKs
O ACK tích lũy nhận phản hồi
‘C’
Hỏi: làm thế nào bên nhận
quản lý các đoạn không
thứ tự
time
O Trả lời: TCP không tình huống telnet đơn giản
đề cập, tùy thuộc
người hiện thực Lớp Transport 58
TCP Round Trip Time vàTimeout
Hỏi: Làm thế nào để Hỏi : Làm thế nào để thiết lập
thiết lập giá trị TCP RTT?
timeout? D SampleRTT: thời gian được đo từ
D dài hơn RTT khi truyền đoạn đến khi báo nhận
O khác với RTT
ACK
O lờ đi việc truyền lại
D quá ngắn: timeout sớm
D SampleRTT sẽ thay đổi, muốn ước
O truyền lại không cần
thiết lượng RTT “mượt hơn”
O tính trung bình một số giá trị
D quá dài: phản ứng chậm
đối với việc mất mát gói đo được gần đó, không chỉ
SampleRTT hiện tại

Lớp Transport 59
TCP Round Trip Time và Timeout
EstimatedRTT = (1 – α) * EstimatedRTT + α * SampleRTT

• EstimatedRTT: weighted combination of the previous value of

EstimatedRTT and the new value for SampleRTT
• Recommended value of α = 0.125 (~1/8) [RFC6298]

EstimatedRTT = 0.875 * EstimatedRTT + 0.125 * SampleRTT

Lớp Transport 69
Ví dụ đánh giá RTT:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

Lớp Transport 61
TCP Round Trip Time và Timeout
Thiết lập timeout
D EstimtedRTT cộng “hệ số dự trữ an toàn”
O sự biến thiên lớn trong EstimatedRTT -> hệ số dự trữ an toàn
lớn hơn
D ước lượng đầu tiên về sự biến thiên của SampleRTT từ
EstimatedRTT :
DevRTT = ()*DevRTT +
*|SampleRTT-EstimatedRTT|

(tiêu biểu  = 0.25)

Sau đó thiết lập timeout interval:

TimeoutInterval = EstimatedRTT + 4*DevRTT

Lớp Transport 62
TCP: truyền dữ liệu tin cậy
D TCP tạo dịch vụ rdt D Truyền lại được
trên dịch vụ không tin kích hoạt bởi:
cậy IP O các sự kiện timeout
D các đoạn Pipelined O các ack trùng lặp
D các ACK tích lũy D lúc đầu khảo sát các

D TCP dùng bộ định

bên gửi TCP đơn giản:
lờ đi các ack trùng lặp
thì truyền lại đơn
O

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

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

Lớp Transport 63
TCP các sự kiện:
dữ liệu đã nhận từ ứng timeout:
dụng: D gửi lại đoạn nào gây
D tạo đoạn với số thứ ra timeout
tự của nó D khởi động lại bộ
D số thứ tự là số theo định thì
byte dữ liệu đầu tiên Ack đã nhận:
D khởi động bộ định O cập nhật cái gì sẽ được
thì nếu chưa chạy ACK
khởi động bộ định thì
D khoảng thời gian
O
nếu có các đoạn còn chờ
hết hạn:
TimeOutInterval

Lớp Transport 64
 NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum

loop (forever) { TCP

bên gửi
switch(event)
event: data received from application above
create TCP segment with sequence number NextSeqNum
if (timer currently not running) (đơn giản)
start timer
pass segment to IP
NextSeqNum = NextSeqNum + length(data) Chú thích:
•SendBase-1: byte
event: timer timeout
vừa được ACK
retransmit not-yet-acknowledged segment with
smallest sequence number
tích lũy
start timer Ví dụ:
• SendBase-1 = 71;
event: ACK received, with ACK field value of y
if (y > SendBase) {
y= 73, vì thế bên nhận
SendBase = y muốn 73+ ;
if (there are currently not-yet-acknowledged segments) y > SendBase, vì thế
start timer dữ liệu mới được
} chấp nhận
Break;
} /* end of loop forever */

Lớp Transport 65
 TCP: các tình huống truyền lại
Host A Host B Host A Host B

Seq=92 timeout
timeout

X
loss

Sendbase
= 100

Seq=92 timeout
SendBase
= 120

SendBase
= 100 SendBase
= 120 timeout sớm
time time
tình huống mất ACK Lớp Transport 66
 TCP: các tình huống truyền lại (tt)
Host A Host B
timeout

X
loss

SendBase
= 120

time
tình huống ACK tích lũy

Lớp Transport 67
TCP sinh ra ACK [RFC 1122, RFC 2581]
Sự kiện tại bên nhận TCP bên nhận hành động
Đoạn đến với đúng số thứ tự ACK trễ. Chờ đến 500ms
mong muốn. Tất cả dữ liệu đến cho đoạn kế tiếp. Nếu không có đoạn
đã được ACK kế tiếp, gửi ACK

Đoạn đến với đúng số thứ tự Gửi ngay một ACK tích lũy, chấp nhận
mong muốn. Một đoạn khác đang cho cả các đoạn theo thứ tự
chờ ACK

Các đoạn đến không thứ tự Gửi ngay ACK trùng lặp, chỉ thị số thứ tự
lớn hơn số thứ tự đoạn mong muốn. đoạn của byte kế tiếp đang mong chờ
Có khoảng trống

Đoạn đến lấp đầy từng phần Gửi ngay ACK, với điều kiện là đoạn
hoặc toàn bộ khoảng trống bắt đầu ngay điểm có khoảng trống

Lớp Transport 68
Truyền lại nhanh
D Chu kỳ Time-out D Nếu bên gửi nhận 3
thường tương đối dài: ACK của cùng một dữ
O độ trễ dài trước khi gửi liệu, nó cho là đoạn sau
lại gói đã mất dữ liệu đã ACK bị mất:
D Xác nhận các đoạn O Truyền lại nhanh: gửi lại
đã mất bằng các ACK đoạn trước khi bộ định thì
trùng lặp. hết hạn
O bên gửi thường gửi nhiều
đoạn song song
O Nếu đoạn bị mất, sẽ xảy
ra tình trạng giống như
nhiều ACK trùng nhau

Lớp Transport 69
 Giải thuật truyền lại nhanh:

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

if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}

một ACK trùng lặp cho Truyền lại nhanh

đoạn đã được ACK

Lớp Transport 70
TCP điều khiển luồng
điều khiển luồng
bên gửi sẽ không làm
D bên nhận của kết tràn bộ đệm vì truyền
nối TCP có một bộ quá nhiều và quá nhanh
đệm nhận:

D dịch vụ so trùng tốc

độ: so trùng tốc độ gửi
với tốc độ nhận của ứng
dụng
D tiến trình ứng dụng có
thể chậm tại lúc đọc bộ
đệm
Lớp Transport 71
TCP điều khiển luồng: cách làm?
(Giả sử bên nhận TCP loại bỏ
các đoạn không có thứ tự)
D dự phòng trong bộ đệm
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]
D Bên nhận thông báo
khoảng dự trữ nhờ giá
trị RcvWindow trong
các đoạn
D Bên gửi hạn chế dữ
liệu không được ACK vào
RcvWindow
O bảo đảm bộ đệm nhận
không tràn
Lớp Transport 72
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
D khởi tạo các biến TCP:
O các số thứ tự đoạn
O thông tin các bộ đệm,
điều khiển luồng (như
RcvWindow)
D client: người khởi xướng kết
nối
Socket clientSocket = new
Socket("hostname","port
pp bắt tay 3 bước:
Bước 1: client host gửi đoạnTCP
SYN đến server
O xác định số thứ tự khởi đầu
O không phải dữ liệu
Bước 2: server host nhận SYN,
trả lời với đoạn SYNACK
O server cấp phát các bộ
đệm
O xác định số thứ tự khởi đầu

number"); Bước 3: client nhận SYNACK, trả

lời với đoạn ACK (có thể chứa
D server: được tiếp xúc bởi
dữ liệu)
client
Socket connectionSocket =
welcomeSocket.accept();
Lớp Transport 73
TCP quản lý kết nối (tt)

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

đóng
client đóng socket:
clientSocket.close();

Bước 1: client gửi đoạn điều đóng

khiển TCP FIN đến server

Bước 2: server nhận FIN, trả

thời gian chờ

lời với ACK. Đóng kết nối,
gửi FIN.

đã đóng

Lớp Transport 74
TCP quản lý kết nối (tt)

Bước 3: client nhận FIN, trả client server

lời với ACK. đang đóng
O Trong khoảng “thời gian
chờ” – sẽ phản hồi với
ACK để nhận các FIN
đang đóng
Bước 4: server, nhận ACK.
Kết nối đã đóng.

thời gian chờ

Chú ý: với một sửa đổi nhỏ,
đã đóng
có thể quản lý nhiều FIN
đồng thời.

đã đóng

Lớp Transport 75
TCP quản lý kết nối (tt)

chu kỳ sống của

TCP server

chu kỳ sống của

TCP client

Lớp Transport 76
5.6 Các nguyên lý của điều
khiển tắc nghẽn

Lớp Transport 77
Các nguyên lý điều khiển tắc nghẽn

Tắc nghẽn:
D “quá nhiều nguồn gửi quá nhanh và quá nhiều dữ liệu
đến mạng”
D khác với điều khiển luồng!
D các biểu hiện:
O các gói bị mất (tràn bộ đệm tại các router)
O các độ trễ quá dài (xếp hàng trong bộ đệm của
router)
D là 1 trong 10 vấn đề nan giải nhất!

Lớp Transport 78
 Các nguyên nhân/chi phí của tắc nghẽn:
tình huống 1 Host A 
in : original data
out

• 2 gửi, 2 nhận
• 1 router, các bộ unlimited shared
đệm không giới hạn
Host B
output link buffers

• không có truyền lại

• các độ trễ tới

vô hạn khi tắc
nghẽn
• Thông lượng
có thể đạt tối
đa
Lớp Transport 79
 Các nguyên nhân/chi phí của tắc nghẽn:
tình huống 2
• 1 router, các bộ đệm có giới hạn
• bên gửi truyền lại các gói đã mất

Host A in : dữ liệu gốc

out

'in : dữ liệu gốc, cùng với

dữ liệu truyền lại

Host B chia sẻ vô hạn

các bộ đệm ouput

Lớp Transport 80
 Các nguyên nhân/chi phí của tắc nghẽn:
tình huống 2 =
D luôn luôn: in out
D truyền lại “hoàn toàn” chỉ khi mất mát:  > out
in
D truyền lại vì trễ (không mất) làm cho  lớn hơn với cùng
in
out
R/2 R/2 R/2

R/3
out

out
out

R/4

R/2 R/2 R/2

in in in

a. b. c.
“các chi phí” của tắc nghẽn:
D nhiều việc (truyền lại)
D các truyền lại không cần thiết: liên kết nhiều bản sao của gói
Lớp Transport 81
Các nguyên nhân/chi phí của tắc nghẽn:
tình huống 3
D 4 người gửi Hỏi: điều gì xảy ra nếu  và 
in in
D các đường qua nhiều hop tăng lên?
D timeout/truyền lại
Host A out
in : dữ liệu gốc
'in : dữ liệu gốc, cùng
với dữ liệu truyền lại

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

Host B

Lớp Transport 82
Các nguyên nhân/chi phí của tắc nghẽn:
tình huống 3
H 
o
s o
u
t
A t

H
o
s
t
B

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

D 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í!”

Lớp Transport 83
Các cách tiếp cận đối với điều khiển tắc
nghẽn
2 cách:

điều khiển tắc nghẽn end- điều khiển tắc nghẽn có sự

end: hỗ trợ của mạng:
D không có phản hồi rõ ràng D các router cung cấp phản hồi
từ mạng về các hệ thống đầu cuối
D tắc nghẽn được suy ra từ O 1 bit duy nhất chỉ thị tắc
việc quan sát các hệ thống nghẽn (SNA, DECbit,
đầu cuối có mất mát, trễ TCP/IP ECN, ATM)
D tiếp cận được quản lý bởi O tốc độ sẽ gửi được xác
TCP định rõ ràng

Lớp Transport 84
Ví dụ: điều khiển tắc nghẽn ATM ABR

ABR: tốc độ bit sẵn RM (resource management):

sàng: D gửi bởi bên gửi, rải rác với các ô
D “dịch vụ mềm dẻo” dữ liệu
D nếu đường gửi “chưa hết”: D các bit trong ô thiết lập bởi các
O bên gửi sẽ dùng băng switch
thông sẵn sàng O bit NI : không tăng tốc độ

D nếu đường gửi tắc nghẽn:

(tắc nghẽn nhẹ)
O bit CI : tắc nghẽn rõ rệt
O bên gửi điều tiết với
tốc độ tối thiểu D Các ô RM được trả về bên gửi từ
bên nhận với nguyên vẹn các bit

Lớp Transport 85
Ví dụ: điều khiển tắc nghẽn ATM ABR

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

O switch đã tắc nghẽn có thể có giá trị ER thấp hơn trong ô
O tốc độ gửi do đó có thể được hỗ trợ tối đa trên đường

D EFCI bit trong các ô dữ liệu: được cài giá trị 1 trong
switch đã tắc nghẽn
O nếu ô dữ liệu đứng trước ô RM có cài EFCI, bên gửi sẽ cài bit
CI trong ô RM trả về
Lớp Transport 86
5.7 Điều khiển tắc nghẽn TCP

Lớp Transport 87
TCP điều khiển tắc nghẽn: additive tăng lên,
multiplicative giảm xuống
D Cách tiếp cận: tăng tốc độ truyền (kích thước cửa sổ),
tìm khả năng băng thông có thể, cho đến khi có mất
mát xảy ra
O additive tăng lên: tăng CongWin bởi 1 MSS mỗi RTT
cho đến khi có mất mát xảy ra
O multiplicative giảm xuống: bỏ CongWin trong nửa
giai đoạn sau khi mất mát congestion
window
24

Tìm kiếm
kích thước cửa sổ

Kbytes

băng thông
tắc nghẽn

16
Kbytes

8 Kbytes

time
time

Lớp Transport 88
 TCP điều khiển tắc nghẽn: chi
tiết
D bên gửi hạn chế việc truyền: Làm thế nào bên gửi nhận
LastByteSent-LastByteAcked biết tắc nghẽn?
 CongWin D mất mát xảy ra =
timeout hoặc 3 ack
D Công thức,
trùng lặp
CongWin
tốc độ = Bytes/s D bên gửi giảm tốc độ
RTT (CongWin) sau khi mất
D CongWin thay đổi, chức năng mát xảy ra
là nhận biết tắc nghẽn trên 3 cơ chế:
mạng O AIMD
O khởi động chậm
O thận trọng sau khi có
các sự kiện timeout

Lớp Transport 89
 TCP khởi động chậm
D Khi kết nối bắt đầu, D Khi kết nối bắt đầu,
CongWin = 1 MSS tăng tốc lên rất nhanh
O Ví dụ: MSS = 500 bytes & cho đến khi sự cố mất
RTT = 200 ms mát xảy ra đầu tiên
O tốc độ khởi tạo = 20 kbps
D băng thông sẵn sàng có
thể >> MSS/RTT
O mong muốn nhanh chóng
tăng tốc lên tốc độ có thể
đáp ứng

Lớp Transport 90
TCP khởi động chậm (tt)
D Khi kết nối bắt đầu, Host A Host B
tăng tốc lên rất nhanh
cho đến khi sự cố mất

RTT
mát xảy ra đầu tiên:
O nhân đôi CongWin mỗi
RTT
O hoàn thành nhờ tăng
CongWin ứng với mỗi
ACK đã nhận
D Tổng kết: tốc độ khởi
đầu là chậm nhưng sau
đó tăng tốc rất nhanh thời gian

Lớp Transport 91
Tinh chế
Hỏi: Khi nào việc tăng
tốc trở thành tuyến
tính?
Trả lời: Khi CongWin
đạt đến 1/2 giá trị
của nó trước khi
timeout.

Hiện thực:
D Ngưỡng thay đổi
D Tại thời điểm có sự cố mất
mát, ngưỡng được cài giá trị
bằng ½ của CongWin ngay
trước đó

Lớp Transport 92
 Tinh chế: nhận biết mất mát
D Sau 3 ACK trùng lặp:
OCongWin sẽ giảm 1/2 Nguyên lý:
O kích thước cửa sổ tăng
tuyến tính 0 3 ACK trùng nhau chỉ ra
D nhưng sau sự cố timeout: khả năng truyền của mạng
0 timeout chỉ thị “nhiều
O CongWin thay giá trị
cảnh báo” về tình huống
bằng 1 MSS;
tắc nghẽn
O kích thước cửa sổ tăng
cấp lũy thừa
O khi đến một ngưỡng thì
tăng tuyến tính

Lớp Transport 93
Tổng kết: TCP điều khiển tắc nghẽn

D Khi CongWin dưới Threshold, bên gửi đang trong

giai đoạn khởi động chậm, kích thước cửa sổ tăng
nhanh theo cấp lũy thừa.
D Khi CongWin trên Threshold, bên gửi đang trong
giai đoạn tránh tắc nghẽn, kích thước cửa sổ tăng
nhanh theo cấp tuyến tính.
D Khi có 3 ACK trùng lặp xảy ra, Threshold =
CongWin/2 và CongWin = Threshold.

D Khi timeout xảy ra, Threshold = CongWin/2 và

CongWin = 1 MSS.
Lớp Transport 94
TCP điều khiển tắc nghẽn bên gửi
Trạng thái Sự kiện TCP bên gửi hành động Diễn giải
Slow Start ACK báo CongWin = CongWin + MSS, Hậu quả làm tăng gấp đôi
(SS)-Khởi nhận cho dữ If (CongWin > Threshold) CongWin mỗi RTT
động chậm liệu chưa cài đặt trạng thái “Tránh tắc
ACK trước nghẽn”
đó
Congestion ACK báo CongWin = CongWin+MSS * Additive tăng lên, làm tăng
Avoidance nhận cho dữ (MSS/CongWin) CongWin lên 1 MSS mỗi
(CA) –Tránh liệu chưa RTT
tắc nghẽn ACK trước
đó
SS hoặc CA Sự cố mất Threshold = CongWin/2, Khôi phục nhanh, hiện thực
mát xảy ra CongWin = Threshold, giảm xuống multiplicative.
khi thấy có 3 cài đặt trạng thái “Tránh tắc CongWin sẽ không giảm
ACK trùng nghẽn” xuống dưới 1 MSS.
lặp
SS hoặc CA Timeout Threshold = CongWin/2, Vào chế độ “Khởi động
CongWin = 1 MSS, chậm”
cài đặt trạng thái “Khởi động
chậm”
SS hoặc CA ACK trùng Đếm ACK tăng lên cho đoạn CongWin và Threshold
lặp vừa được ACK không thay đổi
Lớp Transport 95
TCP throughput
D Throughout trung bình của TCP biểu diễn
qua kích thước của sổ và RTT?
O Bỏ qua trạng thái “Khởi động chậm”
D Cho W là kích thước cửa sổ khi có mất mát
xảy ra.
D Khi kích thước cửa sổ = W, lưu lượng =
W/RTT
D Chỉ ngay sau khi mất mát, cửa sổ giảm xuống
= W/2, lưu lượng = W/2RTT.
D throughout trung bình: 0.75 W/RTT
Lớp Transport 96
TCP tương lai

D Ví dụ: các đoạn dài 1500 byte, RTT 100ms, lưu

lượng 10 Gbps
D Kích thước cửa sổ yêu cầu W = 83,333 đoạn trên
đường truyền
D Lưu lượng trong các trường hợp mất mát:
1.22  MSS
RTT L
D ➜ L = 2·10-10
D Phiên bản mới của TCP dành cho nhu cầu tốc độ cao!

Lớp Transport 97
TCP: tính công bằng
Mục tiêu: nếu K phiên làm việc TCP chia sẻ kết nối cổ
chai của băng thông là R, mỗi phiên có tốc độ
trung bình là R/K

TCP kết nối 1

router cổ chai
TCP
khả năng R
kết nối 2

Lớp Transport 98
Tại sao phải TCP công bằng?
2 phiên làm việc cạnh tranh nhau:
D Additive tăng, lưu lượng tăng
D multiplicative giảm lưu lượng tương xứng

R chia sẻ băng thông bằng nhau

Connection 2 throughput

mất mát: giảm cửa sổ bằng 1/2

tránh tắc nghẽn: additive tăng lên
mất mát: giảm cửa sổ bằng 1/2
tránh tắc nghẽn: additive tăng lên

Connection 1 throughput R

Lớp Transport 99
TCP: tính công bằng (tt)
Tính công bằng & UDP
D nhiều ứng dụng
thường không dùng
TCP
không muốn tốc độ bị
O
điều tiết do điều khiển
tắc nghẽn
D Thay bằng dùng UDP:
O truyền audio/video với
tốc độ ổn định, chịu
được mất mát
D Nghiên cứu: giao thức
thân thiện với TCP
Tính công bằng & các kết nối
TCP song song
D không có gì ngăn cản
việc ứng dụng mở các kết
nối song song giữa 2
host.
D Trình duyệt Web làm
giống như thế
D Ví dụ: tốc độ R hỗ trợ
9 kết nối ;
O ứng dụng mới yêu cầu 1 TCP,
có tốc độ R/10
O ứng dụng mới yêu cầu 11 TCP,
có tốc độ R/2 !
Lớp Transport 100
 Mô hình trễ
Hỏi: Mất bao lâu để nhận 1
đối tượng từ Web server
sau khi gửi yêu cầu?
Bỏ qua tắc nghẽn, trễ bị ảnh
hưởng bởi:
D thiết lập kết nối TCP
D trễ truyền dữ liệu
D khởi động chậm
Notation, các giả định:
D Giả sử một kết nối giữa
client và server có tốc độ R
D S: MSS (bits)
D O: kích thước đối tượng
(bits)
D không truyền lại (không mất
mát, không hỏng)
Kích thước cửa sổ:
D Giả định 1: cửa sổ tắc nghẽn
cố định, có W đoạn
D Sau đó cửa sổ thay đổi, mô
hình khởi động chậm
Lớp Transport 101
Cửa sổ tắc nghẽn cố định (1)

Trường hợp đầu tiên:

WS/R > RTT + S/R: cho đoạn
đầu tiên trong cửa sổ trả
về trước khi cửa sổ dữ liệu
gửi ACK

trễ = 2RTT + O/R

Lớp Transport 102

Cửa sổ tắc nghẽn cố định (2)

Trường hợp thứ hai:

D WS/R < RTT + S/R: sent
chờ cho ACK sau khi gửi
dữ liệu

trễ = 2RTT + O/R

+ (K-1)[S/R + RTT - WS/R]

Lớp Transport 103

 TCP Mô hình trễ: Khởi động chậm (1)
Bây giờ giả sử kích thước cửa sổ tăng lên tùy theo quá
trình khởi động chậm
Độ trễ của một đối tượng sẽ là:
Latency = 2RTT + + P  RTT +  − (2 P −
O S
S  
1) R R R

trong đó P là số lần TCP rảnh ở tại server:

P = min{Q, K −1}

- trong đó Q là số lần server rảnh nếu đối tượng đã khởi tạo kích thước

- và K là số lượng cửa sổ bao trùm đối tượng

Lớp Transport 104

 TCP Mô hình trễ: Khởi động chậm (2)
Các thành phần trễ: initiate TCP
connection
•2 RTT dành cho thiết
lập kết nối và yêu cầu request

•O/R để truyền đối

object
first window

tượng
= S/R

•thời gian server rảnh RTT

second window
bởi vì khởi động chậm = 2S/R

Server rảnh: third window

= 4S/R
P = min{K-1,Q} lần

Ví dụ: fourth window

= 8S/R
• O/S = 15 đoạn
• K = 4 cửa sổ
•Q=2
• P = min{K-1,Q} = 2 object
complete
transmission
delivered

Server rảnh P=2 lần time at

time at
server
client

Lớp Transport 105

 TCP Mô hình trễ(3)
S
+ RTT = time from when server starts to send segment
R
until server receives acknowledgement
initiate TCP
connection
S
2 k −1 = time to transmit the kth window
R request
object
first window
= S/R

 S + RTT − 2k −1 S+ = idle time after the RTT

 R
second window
= 2S/R
kth window R

 
third window
= 4S/R

O
delay = + 2RTT + P
idleTime
R
 p
fourth window
= 8S/R
p=1

O P
S S
= + 2RTT +  [ + RTT − 2 k −1 ]
R k =1 R R S complete
O S object
= + 2RTT + P[RTT + ] − (2 −1)
P transmission
delivered

R R R time at
time at server
client

Lớp Transport 106

TCP Mô hình trễ (4)
K = số lượng cửa sổ bao trùm đối tượng
Làm thế nào tính được K ?

K = min{k : 20 S + 21 S +L + 2 k −1 S  O}
= min{k : 20 + 21 +L + 2 k −1  O / S}
O
= min{k : 2 k −1  }
S
O
= min{k : k  log 2 ( +1)}
S
=  log (
O
  2 S
+1)

cách tính toán Q 

tương tự (xem HW).


Lớp Transport 107

HTTP Mô hình
D Giả sử trang Web chứa:
O 1 trang HTML (kích thước O bits)
O M hình ảnh (mỗi cái kích thướcO bits)
D HTTP không bền vững:
O M+1 TCP kết nối
O Thời gian đáp ứng = (M+1)O/R + (M+1)2RTT + tổng số thời gian
rảnh
D HTTP bền vững:
O 2 RTT để yêu cầu và nhận file HTML
O 1 RTT để yêu cầu và nhận M hình ảnh
O Thời gian đáp ứng = (M+1)O/R + 3RTT + tổng số thời gian rảnh
D HTTP không bền vững với X kết nối song song
O Giả sử M/X là số nguyên.
O 1 TCP kết nối cho file
O M/X thiết lập các kết nối song song cho các hình ảnh
O Thời gian đáp ứng = (M+1)O/R + (M/X + 1)2RTT + tổng số thời
gian rảnh Lớp Transport 108
HTTP thời gian đáp ứng (giây)
RTT = 100 msec, O = 5 Kbytes, M=10 và X=5
20
18
16
14
12 non-persistent
10
8 persistent
6
4 parallel non-
2 persistent
0
28 100 1 10
Kbps Kbps Mbps Mbps
Với băng thông thấp, thời gian kết nối & đáp ứng trội hơn thời gian
truyền
Các kết nối bền vững chỉ cho sự cải thiện không đáng kể trên các kết nối
song song
Lớp Transport 109
HTTP thời gian đáp ứng (giây)
RTT =1 sec, O = 5 Kbytes, M=10 and X=5
70
60
50
non-persistent
40
30 persistent
20
parallel non-
10 persistent
0
28 100 1 10
Kbps Kbps Mbps Mbps
Với RTT lớn hơn, thời gian đáp ứng trội hơn thời gian trễ chờ thiết lập kết nối
TCP & khởi động chậm. Các kết nối bền vững bây giờ cho thấy cải thiện rõ rệt:
đặc biệt với các mạng băng thông cao
Lớp Transport 119
Chương 5: Tổng kết
D các nguyên lý của các
dịch vụ lớp transport
O multiplexing,
demultiplexing
O truyền dữ liệu tin cậy
O điều khiển luồng Tiếp theo:
O điều khiển tắc nghẽn D nghiên cứu xong
D khởi tạo và hiện thực trong các vấn đề “ngoài
Internet biên” (các lớp
O UDP
application,
transport)
O TCP
D chuẩn bị vào
phần “lõi”Lớp
củaTransport 111