Bài giảng Mạng máy tính - Chương 3: Lớp Transport

*DevRTT
Sau đó thiết lập timeout interval:
Lớp Transport 63
TCP: truyền dữ liệu tin cậy
ˆ TCP tạo dịch vụ rdt 
trên dịch vụ không tin 
cậy IP
ˆ các đoạn Pipelined
ˆ các ACK tích lũy
ˆ TCP dùng bộ định thì
truyền lại đơn
ˆ Truyền lại được kích 
hoạt bởi:
 các sự kiện timeout
 các ack trùng lặp
ˆ lúc đầu khảo sát các 
bên gửi TCP đơn giản:
 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
Lớp Transport 64
TCP các sự kiện:
dữ liệu đã nhận từ ứng 
dụng:
ˆ tạo đoạn với số thứ tự
của nó
ˆ số thứ tự là số theo 
byte dữ liệu đầu tiên 
ˆ khởi động bộ định thì
nếu chưa chạy
ˆ khoảng thời gian hết 
hạn: 
TimeOutInterval 
timeout:
ˆ gửi lại đoạn nào gây ra 
timeout
ˆ khởi động lại bộ định 
thì
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ờ
Lớp Transport 65
TCP 
bên gửi
(đơn giản)
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event)
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
start timer
event: ACK received, with ACK field value of y 
if (y > SendBase) { 
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer 
} 
} /* end of loop forever */
Chú thích:
• SendBase-1: byte 
vừa được ACK 
tích lũy 
Ví dụ:
• SendBase-1 = 71;
y= 73, vì thế bên nhận 
muốn 73+ ;
y > SendBase, vì thế
dữ liệu mới được 
chấp nhận
Lớp Transport 66
TCP: các tình huống truyền lại
Host A
Seq=100, 20 bytes data
A C
K = 1
0 0
time
timeout sớm
Host B
Seq=92, 8 bytes data
A C K
= 1 2 0
Seq=92, 8 bytes data
S
e
q
=
9
2
t
i
m
e
o
u
t
A C K
= 1 2 0
Host A
Seq=92, 8 bytes data
A C K =
1 0 0
loss
t
i
m
e
o
u
t
tình huống mất ACK 
Host B
X
Seq=92, 8 bytes data
A C K =
1 0 0
time
S
e
q
=
9
2
t
i
m
e
o
u
t
SendBase
= 100
SendBase
= 120
SendBase
= 120
Sendbase
= 100
Lớp Transport 67
TCP: các tình huống truyền lại (tt)
Host A
Seq=92, 8 bytes data
A C K =
1 0 0
loss
t
i
m
e
o
u
t
tình huống ACK tích lũy
Host B
X
Seq=100, 20 bytes data
A C K =
1 2 0
time
SendBase
= 120
Lớp Transport 68
TCP sinh ra ACK [RFC 1122, RFC 2581]
Sự kiện tại bên nhận
Đoạn đến với đúng số thứ tự
mong muốn. Tất cả dữ liệu đến
đã được ACK
Đoạn đến với đúng số thứ tự
mong muốn. Một đoạn khác đang
chờ ACK
Các đoạn đến không thứ tự
lớn hơn số thứ tự đoạn mong muốn.
Có khoảng trống
Đoạn đến
lấp đầy từng phần hoặc toàn bộ
khoảng trống
TCP bên nhận hành động
ACK trễ. Chờ đến 500ms
cho đoạn kế tiếp. Nếu không có đoạn
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
Lớp Transport 69
Truyền lại nhanh
ˆ Chu kỳ Time-out 
thường tương đối dài:
 độ trễ dài trước khi gửi 
lại gói đã mất
ˆ Xác nhận các đoạn đã 
mất bằng các ACK 
trùng lặp.
 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:
 Truyền lại nhanh: gửi lại 
đoạn trước khi bộ định thì
hết hạn
Lớp Transport 70
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
}
Giải thuật truyền lại nhanh:
một ACK trùng lặp cho 
đoạn đã được ACK
Truyền lại nhanh
Lớp Transport 71
TCP điều khiển luồng
ˆ bên nhận của kết nối 
TCP có một bộ đệm 
nhận:
ˆ 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
ˆ 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
Lớp Transport 72
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ự phòng trong bộ đệm
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]
ˆ Bên nhận thông báo 
khoảng dự trữ nhờ giá
trị RcvWindow trong 
các đoạn
ˆ Bên gửi hạn chế dữ liệu 
không được ACK vào 
RcvWindow
 bảo đảm bộ đệm nhận 
không tràn
Lớp Transport 73
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:
 các số thứ tự đoạn
 thông tin các bộ đệm, 
điều khiển luồng (như 
RcvWindow)
ˆ client: người khởi xướng kết 
nối
Socket clientSocket = new 
Socket("hostname","port 
number");
ˆ server: được tiếp xúc bởi 
client
Socket connectionSocket = 
welcomeSocket.accept();
3 phương pháp bắt tay:
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)
Lớp Transport 74
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. 
client
FIN
server
A C K
ACK
F I N
đóng
đóng
đã đóng
t
h
ờ
i
g
i
a
n
c
h
ờ
Lớp Transport 75
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 
chờ” – sẽ phản hồi với 
ACK để nhận các FIN
Bước 4: server, nhận ACK. 
Kết nối đã đóng. 
Chú ý: với một sửa đổi nhỏ, 
có thể quản lý nhiều FIN 
đồng thời.
client
FIN
server
A C K
ACK
F I N
đang đóng
đang đóng
đã đóng
t
h
ờ
i
g
i
a
n
c
h
ờ
đã đóng
Lớp Transport 76
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
Lớp Transport 77
Lớp Transport 78
Các nguyên lý điều khiển tắc nghẽn
Tắc nghẽn:
ˆ “quá nhiều nguồn gửi quá nhanh và quá nhiều dữ liệu 
đến mạng”
ˆ khác với điều khiển luồng!
ˆ các biểu hiện:
 các gói bị mất (tràn bộ đệm tại các router)
 các độ trễ quá dài (xếp hàng trong bộ đệm của 
router)
ˆ là 1 trong 10 vấn đề nan giải nhất!
Lớp Transport 79
Các nguyên nhân/chi phí của tắc nghẽn: 
tình huống 1
ˆ 2 gửi, 2 nhận
ˆ 1 router, các bộ 
đệm không giới hạn
ˆ không có truyền lại
ˆ các độ trễ lớn 
hơn khi tắc 
nghẽn
ˆ năng suất có
thể đạt tối đa
unlimited shared 
output link buffers
Host A λin : original data
Host B
λout
Lớp Transport 80
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
chia sẻ vô hạn
các bộ đệm ouput
Host A λin : dữ liệu gốc
Host B
λout
λ'in : dữ liệu gốc, cùng với 
dữ liệu truyền lại
Lớp Transport 81
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
λ
in
λout= λ
in
λout>λ
inλout
“các chi phí” của tắc nghẽn:
ˆ nhiều việc (truyền lại)
ˆ 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
R/2
R/2λin
λ
o
u
t
b.
R/2
R/2λin
λ
o
u
t
a.
R/2
R/2λin
λ
o
u
t
c.
R/4
R/3
Lớp Transport 82
Các nguyên nhân/chi phí của tắc nghẽn: 
tình huống 3 
ˆ 4 người gửi
ˆ các đường qua nhiều hop
ˆ timeout/truyền lại
λ
in
Hỏi: điều gì xảy ra nếu và 
tăng lên?
λ
in
chia sẻ vô hạn
các bộ đệm ouput
Host A λin : dữ liệu gốc
Host B
λout
λ'in : dữ liệu gốc, cùng 
với dữ liệu truyền lại
Lớp Transport 83
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
Lớp Transport 84
Các cách tiếp cận đối với điều khiển tắc 
nghẽn
điều khiển tắc nghẽn end-
end:
ˆ không có phản hồi rõ ràng 
từ mạng
ˆ tắc nghẽn được suy ra từ
việc quan sát các hệ thống 
đầu cuối có mất mát, trễ
ˆ tiếp cận được quản lý bởi 
TCP
điều khiển tắc nghẽn có sự
hỗ trợ của mạng:
ˆ 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:
Lớp Transport 85
Ví dụ: điều khiển tắc nghẽn ATM ABR
ABR: tốc độ bit sẵn 
sàng:
ˆ “dịch vụ mềm dẻo”
ˆ nếu đường gửi “chưa hết”: 
 bên gửi sẽ dùng băng 
thông sẵn sàng
ˆ nếu đường gửi tắc nghẽn: 
 bên gửi điều tiết với 
tốc độ tối thiểu
RM (resource management):
ˆ 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 
Lớp Transport 86
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 bit 
CI trong ô RM trả về
3.7 Điều khiển tắc nghẽn TCP
Lớp Transport 87
Lớp Transport 88
TCP điều khiển tắc nghẽn: additive tăng lên, 
multiplicative giảm xuống
8 Kbytes
16 Kbytes
24 Kbytes
time
congestion
window
ˆ 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
 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
multiplicative giảm xuống: bỏ CongWin trong nửa 
giai đoạn sau khi mất mát
time
k
í
c
h
t
h
ư
ớ
c
c
ử
a
s
ổ
t
ắ
c
n
g
h
ẽ
n
Tìm kiếm 
băng thông
Lớp Transport 89
TCP điều khiển tắc nghẽn: chi 
tiết
ˆ bên gửi hạn chế việc truyền:
LastByteSent-LastByteAcked
≤ CongWin
ˆ Công thức,
ˆ CongWin thay đổi, chức năng là
nhận biết tắc nghẽn trên mạng
Làm thế nào bên gửi nhận 
biết tắc nghẽn?
ˆ mất mát xảy ra = 
timeout hoặc 3 ack 
trùng lặp
ˆ bên gửi giảm tốc độ
(CongWin) sau khi mất 
mát xảy ra 
3 cơ chế:
 AIMD
 khởi động chậm
 thận trọng sau khi có
các sự kiện timeout
tốc độ = CongWin
RTT Bytes/s
Lớp Transport 90
TCP khởi động chậm
ˆ Khi kết nối bắt đầu, 
CongWin = 1 MSS
 Ví dụ: MSS = 500 bytes & 
RTT = 200 ms
 tốc độ khởi tạo = 20 kbps
ˆ băng thông sẵn sàng có
thể >> MSS/RTT
 mong muốn nhanh chóng 
tăng tốc lên tốc độ có thể 
đáp ứng
ˆ Khi kết nối bắt đầu, tăng 
tốc lên rất nhanh cho 
đến khi sự cố mất mát 
xảy ra đầu tiên
Lớp Transport 91
TCP khởi động chậm (tt)
ˆ Khi kết nối bắt đầu, 
tăng tốc lên rất nhanh 
cho đến khi sự cố mất 
mát xảy ra đầu tiên:
 nhân đôi CongWin mỗi 
RTT
 hoàn thành nhờ tăng 
CongWin ứng với mỗi 
ACK đã nhận
ˆ Tổng kết: tốc độ khởi 
đầu là chậm nhưng sau 
đó tăng tốc rất nhanh
Host A
1 đoạn
R
T
T
Host B
thời gian
2 đoạn
4 đoạn
Lớp Transport 92
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:
ˆ Ngưỡng thay đổi
ˆ 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 93
Tinh chế: nhận biết mất mát
ˆ Sau 3 ACK trùng lặp:
 CongWin sẽ giảm 1/2
 kích thước cửa sổ tăng 
tuyến tính
ˆ nhưng sau sự cố timeout:
 CongWin thay giá trị
bằng 1 MSS; 
 kích thước cửa sổ tăng 
cấp lũy thừa
 khi đến một ngưỡng thì 
tăng tuyến tính
‰3 ACK trùng nhau chỉ ra 
khả năng truyền của mạng 
‰ timeout chỉ thị “nhiều 
cảnh báo” về tình huống 
tắc nghẽn
Nguyên lý:
Lớp Transport 94
Tổng kết: TCP điều khiển tắc nghẽn
ˆ 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.
ˆ 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.
ˆ Khi có 3 ACK trùng lặp xảy ra, Threshold = 
CongWin/2 và CongWin = Threshold.
ˆ Khi timeout xảy ra, Threshold = CongWin/2 và
CongWin = 1 MSS.
Lớp Transport 95
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 
(SS)-Khởi 
động chậm
ACK báo 
nhận cho dữ
liệu chưa 
ACK trước 
đó
CongWin = CongWin + MSS, 
If (CongWin > Threshold)
cài đặt trạng thái “Tránh tắc 
nghẽn”
Hậu quả làm tăng gấp đôi 
CongWin mỗi RTT
Congestion
Avoidance 
(CA) –Tránh 
tắc nghẽn
ACK báo 
nhận cho dữ
liệu chưa 
ACK trước 
đó
CongWin = CongWin+MSS * 
(MSS/CongWin)
Additive tăng lên, làm tăng 
CongWin lên 1 MSS mỗi 
RTT
SS hoặc CA Sự cố mất 
mát xảy ra 
khi thấy có 3 
ACK trùng 
lặp
Threshold = CongWin/2, 
CongWin = Threshold,
cài đặt trạng thái “Tránh tắc 
nghẽn”
Khôi phục nhanh, hiện thực 
giảm xuống multiplicative. 
CongWin sẽ không giảm 
xuống dưới 1 MSS.
SS hoặc CA Timeout Threshold = CongWin/2, 
CongWin = 1 MSS,
cài đặt trạng thái “Khởi động 
chậm”
Vào chế độ “Khởi động 
chậm”
SS hoặc CA ACK trùng 
lặp
Đếm ACK tăng lên cho đoạn 
vừa được ACK
CongWin và Threshold 
không thay đổi
Lớp Transport 96
TCP throughput
ˆThroughout trung bình của TCP biểu diễn 
qua kích thước của sổ và RTT?
 Bỏ qua trạng thái “Khởi động chậm”
ˆ Cho W là kích thước cửa sổ khi có mất mát 
xảy ra.
ˆ Khi kích thước cửa sổ = W, lưu lượng = 
W/RTT
ˆ Chỉ ngay sau khi mất mát, cửa sổ giảm xuống 
= W/2, lưu lượng = W/2RTT.
ˆ throughout trung bình: 0.75 W/RTT
Lớp Transport 97
TCP tương lai
ˆ Ví dụ: các đoạn dài 1500 byte, RTT 100ms, lưu 
lượng 10 Gbps
ˆ Kích thước cửa sổ yêu cầu W = 83,333 đoạn trên 
đường truyền
ˆ Lưu lượng trong các trường hợp mất mát:
ˆ ➜ L = 2·10-10
ˆ Phiên bản mới của TCP dành cho nhu cầu tốc độ cao!
LRTT
MSS⋅22.1
Lớp Transport 98
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
khả năng RTCP kết nối 2
TCP: tính công bằng
Lớp Transport 99
Tại sao phải TCP công bằng?
2 phiên làm việc cạnh tranh nhau:
ˆ Additive tăng, lưu lượng tăng
ˆ multiplicative giảm lưu lượng tương xứng
R
R
chia sẻ băng thông bằng nhau
Connection 1 throughput
C o
n n
e c
t i
o n
 2
 t
h r
o u
g h
p u
t
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
mất mát: giảm cửa sổ bằng 1/2
Lớp Transport 100
TCP: tính công bằng (tt)
Tính công bằng & UDP
ˆ nhiều ứng dụng thường 
không dùng TCP
 không muốn tốc độ bị 
điều tiết do điều khiển 
tắc nghẽn
ˆ Thay bằng dùng UDP:
 truyền audio/video với 
tốc độ ổn định, chịu 
được mất mát
ˆ 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
ˆ 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.
ˆ Trình duyệt Web làm giống 
như thế
ˆ Ví dụ: tốc độ R hỗ trợ 9 
kết nối ; 
 ứng dụng mới yêu cầu 1 TCP, 
có tốc độ R/10
 ứng dụng mới yêu cầu 11 TCP, 
có tốc độ R/2 !
Lớp Transport 101
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:
ˆ thiết lập kết nối TCP
ˆ trễ truyền dữ liệu 
ˆ khởi động chậm
Notation, các giả định:
ˆ Giả sử một kết nối giữa 
client và server có tốc độ R
ˆ S: MSS (bits)
ˆ O: kích thước đối tượng 
(bits)
ˆ không truyền lại (không mất 
mát, không hỏng)
Kích thước cửa sổ:
ˆ Giả định 1: cửa sổ tắc nghẽn 
cố định, có W đoạn
ˆ Sau đó cửa sổ thay đổi, mô 
hình khởi động chậm
Lớp Transport 102
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 103
Cửa sổ tắc nghẽn cố định (2)
Trường hợp thứ hai:
ˆ 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 104
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à:
R
S
R
SRTTP
R
ORTTLatency P )12(2 −−⎥⎦
⎤⎢⎣
⎡ +++=
trong đó P là số lần TCP rảnh ở tại server:
}1,{min −= KQP
- 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 105
TCP Mô hình trễ: Khởi động chậm (2)
RTT
initiate TCP
connection
request
object
first window
= S/R
second window
= 2S/R
third window
= 4S/R
fourth window
= 8S/R
complete
transmissionobject
delivered
time at
client
time at
server
Ví dụ:
• O/S = 15 đoạn
• K = 4 cửa sổ
• Q = 2
• P = min{K-1,Q} = 2
Server rảnh P=2 lần
Các thành phần trễ:
• 2 RTT dành cho thiết 
lập kết nối và yêu cầu
• O/R để truyền đối 
tượng
•thời gian server rảnh 
bởi vì khởi động chậm
Server rảnh: 
P = min{K-1,Q} lần
Lớp Transport 106
TCP Mô hình trễ(3)
R
S
R
SRTTPRTT
R
O
R
SRTT
R
SRTT
R
O
idleTimeRTT
R
O
P
k
P
k
P
p
p
)12(][2
]2[2
2delay
1
1
1
−−+++=
−+++=
++=
−
=
=
∑
∑
th window after the timeidle 2 1 k
R
SRTT
R
S k =⎥⎦
⎤⎢⎣
⎡ −+
+
−
ementacknowledg receivesserver until 
segment send tostartsserver when from time=+ RTT
R
S
 window kth the transmit totime2 1 =−
R
Sk
RTT
initiate TCP
connection
request
object
first window
= S/R
second window
= 2S/R
third window
= 4S/R
fourth window
= 8S/R
complete
transmissionobject
delivered
time at
client
time at
server
Lớp Transport 107
TCP Mô hình trễ (4)
⎥⎥
⎤⎢⎢
⎡ +=
+≥=
≥−=
≥+++=
≥+++=
−
−
)1(log
)}1(log:{min
}12:{min
}/222:{min
}222:{min
2
2
110
110
S
O
S
Okk
S
Ok
SOk
OSSSkK
k
k
k
L
L
cách tính toán Q tương tự (xem HW).
K = số lượng cửa sổ bao trùm đối tượng
Làm thế nào tính được K ?
Lớp Transport 108
HTTP Mô hình 
ˆ Giả sử trang Web chứa:
 1 trang HTML (kích thước O bits)
 M hình ảnh (mỗi cái kích thướcO bits)
ˆ HTTP không bền vững: 
 M+1 TCP kết nối
 Thời gian đáp ứng = (M+1)O/R + (M+1)2RTT + tổng số thời gian 
rảnh
ˆ HTTP bền vững:
 2 RTT để yêu cầu và nhận file HTML
 1 RTT để yêu cầu và nhận M hình ảnh 
 Thời gian đáp ứng = (M+1)O/R + 3RTT + tổng số thời gian rảnh
ˆ HTTP không bền vững với X kết nối song song
 Giả sử M/X là số nguyên.
 1 TCP kết nối cho file
 M/X thiết lập các kết nối song song cho các hình ảnh
 Thời gian đáp ứng = (M+1)O/R + (M/X + 1)2RTT + tổng số thời 
gian rảnh
Lớp Transport 109
0
2
4
6
8
10
12
14
16
18
20
28
Kbps
100
Kbps
1
Mbps
10
Mbps
non-persistent
persistent
parallel non-
persistent
HTTP thời gian đáp ứng (giây)
RTT = 100 msec, O = 5 Kbytes, M=10 và X=5
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 110
0
10
20
30
40
50
60
70
28
Kbps
100
Kbps
1
Mbps
10
Mbps
non-persistent
persistent
parallel non-
persistent
HTTP thời gian đáp ứng (giây)
RTT =1 sec, O = 5 Kbytes, M=10 and X=5
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 111
Chương 3: Tổng kết
ˆ các nguyên lý của các dịch 
vụ lớp transport
multiplexing, 
demultiplexing
 truyền dữ liệu tin cậy
 điều khiển luồng
 điều khiển tắc nghẽn
ˆ khởi tạo và hiện thực trong 
Internet
 UDP
 TCP
Tiếp theo:
ˆ nghiên cứu xong các 
vấn đề “ngoài biên”
(các lớp application, 
transport)
ˆ chuẩn bị vào phần 
“lõi” của mạng