Bài giảng Mạng máy tính
ET4230 – 20112 (Tuần 9)
TS. Trần Quang Vinh
Lớp giao vận – Transport Layer (tiếp)
1. Các khái niệm
Điều khiển luồng (Flow Control): Điều khiển lượng dữ liệu được gửi đi để đảm
bảo rằng bên gửi có tốc độ nhanh không thể tiếp tục truyền dữ liệu nhanh hơn
mức mà bên nhận có thể tiếp thu được (không làm quá tải bên nhận).
Điều khiển luồng luôn luôn liên quan đến một sự phản hồi trực tiếp từ phía nhận
đến phía gửi để thông báo khả năng nhận của bên nhận.
Chống tắc nghẽn (Congestion Control):
Chống tắc nghẽn là cơ chế kiểm soát thông tin đi vào mạng nhằm đảm bảo tổng
lưu lượng thông tin đi vào mạng không vượt quá khả năng xử lý của toàn mạng.
Chống tắc nghẽn liên quan đến việc kiểm soát thông tin trên toàn mạng, trong khi
điều khiển luồng là việc kiểm soát thông tin giữa hai đầu cuối cụ thể. Hai kỹ thuật
này có điểm tương đồng là phải giới hạn lưu lượng thông tin nhằm tránh khả năng
quá tải của hệ thống đích, điều khiển luồng và tránh tắc nghẽn thường được sử
dụng kết hợp với nhau để kiểm soát thông tin trên mạng, ví dụ trong giao thức
TCP.
Điều khiển luồng
được thực hiện ở tầng nào?

Điều khiển luồng và tránh tắc nghẽn được sử dụng nhiều nhất tại các lớp liên kết
dữ liệu (data link), lớp mạng (network) và lớp giao vận (transport) trong đó
Điều khiển luồng từ đầu cuối đến đầu cuối (end-to-end): nhằm tránh cho bộ đệm
của quá trình nhận tại đích khỏi bị tràn, được thực hiện ở lớp Giao vận.
Điều khiển luồng trên từng chặng (hop-by-hop): nhằm tránh cho từng đường
truyền khỏi bị tắc nghẽn. Tuy nhiên, việc kiểm soát luồng trên từng chặng sẽ có
ảnh hưởng đến các chặng khác, do đó nó cũng có tác dụng tránh tắc nghẽn cho
các đường truyền có nhiều chặng. Trong mô hình tham chiếu OSI, điều khiển
luồng hop-by-hop được thực hiện ở lớp Liên kết dữ liệu và lớp Mạng.

Mục đích chính của việc sử dụng điều khiển luồng và chống tắc nghẽn trong mạng
là nhằm:
+ Tối ưu hóa thông lượng sử dụng của mạng
+ Giảm trễ gói khi đi qua mạng
+ Đảm bảo tính công bằng cho việc trao đổi thông tin trên mạng
+ Đảm bảo tránh tắc nghẽn trong mạng
1

2. Kiểm soát luồng (Flow Control)
TCP sử dụng cơ chế “cửa sổ trượt” tương ứng với bộ đệm dữ liệu cung cấp từ các
chương trình ứng dụng quy định số lượng dữ liệu tối đa một nguồn có thể gửi
trước khi nhận được một báo nhận từ bên nhận.
Đây là một trong các cơ chế kiểm soát luồng được sử dụng rộng rãi nhất, có thể
áp dụng tại một hay nhiều tầng của mạng, thường là tầng Liên kết dữ liệu, tầng
Mạng, hoặc tầng Giao vận.
Các bên gửi/nhận sử dụng cửa sổ để kiểm soát luồng dữ liệu. Cửa sổ nhận
(
Rwnd
) chỉ ra số lượng dữ liệu tối đa bên thu có thể nhận, tham số này do bên
nhận báo cho bên gửi trong trường Receive Window Size (thông thường từ 4kB –
8kB).
Cơ chế kiểm soát luồng bằng cửa sổ trượt cho phép bên gửi phát đi liên tiếp
một số segment nhất định rồi mới phải dừng lại chờ thông báo về kết quả nhận,
ACK, trước khi tiếp tục phát.
Bên nhận kiểm soát luồng bằng cách kìm lại hay gửi ngay ACK. Tại mọi thời
điểm, bên gửi phải ghi nhớ một danh sách chứa số thứ tự liên tiếp các segment
mà nó được phép gửi đi, các segment này được gọi là nằm trong cửa sổ gửi.
Tương tự như vậy, bên gửi cũng duy trì một danh sách gọi là cửa sổ gửi (Cwnd:
Congestion window size), tương ứng với các segment mà nó được phép gửi.
Hai cửa sổ gửi và nhận không nhất thiết phải có độ lớn bằng nhau.




Dữ liệu đã gửi và
nhận được ACK
Dữ liệu chưa
được phép gửi
2

Kích thước cửa sổ phải được điều chỉnh cho phù hợp với bộ đệm của bên thu và
đảm bảo hiệu suất kênh truyền. Trong thực tế, kích thước cửa sổ được đánh giá
qua RTT.
RTT > Window Size: hiệu suất kênh truyền thấp
RTT= Window Size: hiệu suất kênh đạt 100%.

3. Kiểm soát lỗi (Error Control)
TCP cung cấp độ tin cậy bằng cách kiểm soát lỗi, phát hiện gói tin bị hỏng, bị
mất, sai thứ tự, và trùng dữ liệu. Kiểm soát lỗi trong giao thức TCP đạt được thông
qua việc sử dụng các tổng kiểm tra (checksum), cơ chế xác nhận (ACK), và thời
gian chờ (timeout).
- Acknowledgement (ACK): là một gói tin được gửi bởi một trạm để thông báo một
gói tin đã nhận được. Gói ACK được tạo ra bằng cách thay đổi trường type trong
phần TCP header. Vì TCP thực hiện truyền tin song công, nên gói ACK cung có
thể mang dữ liệu (piggyback). (Rule 1) Gói ACK không được gán sequence
number và không có báo nhận cho bản thân gói ACK.
- Timeout: cho biết một gói tin đã gửi đi mà chưa nhận được ACK trong một
khoảng thời gian chờ (timer) xác định trước. Tham số Timeout khởi động qua trình
truyền lại ở bên gửi (Retransmission TimeOut -RTO). Sau khoảng thời gian
RTO>RTT mà không nhận được ACK  truyền lại.
- Retransmission: (Rule 2) việc truyền lại sảy ra khi timeout hoặc khi nhận được 3

ACK liên tiếp trùng nhau. (Rule 3) Không thiết lập timer cho gói ACK.
- Out-of-order: (Rule 4) Dữ liệu đến bên nhận có thể không đúng thứ tự, chúng
được lưu trong bộ đệm bên thu và chỉ được chuyển lên tầng trên khi đã sắp xếp lại.

Hoạt động ở chế độ
song công
3



Hình. Cơ chế truyền lại sử dụng timeout: (a) trường hợp bình thường, (b,c) truyền
lại khi mất frame hoặc mất ACK, (d) timeout < RTT gay ra phát trùng frame.
- RTO là giá trị thay đổi, thích ứng với trạng thái kênh ví dụ như khi RTT thay đổi,
vì vậy cần xác định RTO một cách hợp lý để đạt hiệu quả tốt nhất. Nếu RTO quá
lớn gây ra trễ truyền lớn, nếu RTO quá nhỏ có thể sảy ra phát trùng các gói tin.



- Để ước lượng RTO, sử dụng phương pháp “trung bình cửa sổ trượt theo trọng số
mũ” (Exponential Weighted Moving Average - EWMA) theo thuật toán Jacobson
như sau:
Sender Receiver
Frame
ACK
Timeout
Time
Sender Receiver
Frame
ACK
Timeout

Frame
ACK
Timeout
Sender Receiver
Frame
ACK
Timeout
Frame
ACK
Timeout
Sender Receiver
Frame
Timeout
Frame
ACK
Timeout
(a) (c)
(b)
(d)
Phát (A)
Thu (B)
ACK
Round-trip time (RTT)
ACK
Retransmission TimeOut (RTO)
Estimated RTT
Data1 Data2
Guard
Band
RTO trước đó

RTT đo hiện tại
4

+ Tính giá trị ước lượng eRTT:
eRTT
k
=
α
eRTT
k-1
+ (1 -
α
) SampleRTT (1)
+ Thiết lập timeout dựa trên eRTT
RTO = 2 * eRTT
k
(2)
Trong đó:
+
α
là trọng số thuật toán EWMA (0 ≤
α
≤ 1, thông thường
α
=7/8),
+ k là số bước lặp
+ SampleRTT: giá trị RTT đo được (thực tế) cho mỗi cặp packet/ACK tại
bước k.
Lưu ý: Phải tính eRTT qua eRTT trước đó và RTT hiện tại đo được cộng với một
khoảng bảo vệ (chính là giá trị điều chỉnh bởi tham số

α
).

Trường hợp mất gói (Lost segment)
Chú ý:
+ TCP ở bên nhận chỉ chuyển dữ liệu đã được sắp xếp đúng thứ tự cho tiến trình
tương ứng
+ Sinh viên tự tìm hiểu trong trường hợp mất ACK
Ví dụ:
Một kết nối TCP có RTT hiện tại là 30 ms, nhận được các bản tin ACK đến sau 26,
32, và 24 ms. Tính ước lượng giá trị RTT theo thuật toán Jacobson với α = 0.9.
RTT=αRTT+(1-α)M
RTT
1
=0.9 x 30 + (1-0.9) x 26 = 29.6
RTT
2
=0.9 x 29.6 + (1-0.9) x 32 = 29.84
RTT
3
=0.9 x 29.84 + (1-0.9) x 24 = 29.256
5

4. Chống tắc nghẽn (Congestion Control)
4.1. Hiện tượng tắc nghẽn
Tắc nghẽn là một hiện tượng rất quen thuộc trên mạng, mà nguyên nhân nói chung
là do tài nguyên mạng giới hạn trong khi nhu cầu truyền thông tin của con người là
không có giới hạn. Hay nói cụ thể hơn, tắc nghẽn xảy ra trong mạng khi lưu
lượng gửi vào mạng vượt quá dung lượng truyền dẫn. Hiện tượng tắc nghẽn có thể
xảy ra ở một hoặc một số nút mạng, hay trên toàn mạng.

Chống tắc nghẽn là cơ chế kiểm soát thông tin đi vào mạng nhằm đảm bảo tổng
lưu lượng thông tin đi vào mạng không vượt quá khả năng xử lý của toàn mạng.

Hình. Hiện tượng tắc nghẽn
(a) Khi số lượng segment đến mạng còn tương đối nhỏ, nằm trong khả năng vận
tải của mạng, chúng sẽ được phân phát đi hết, số lượng segment được chuyển đi
tỉ lệ thuận với số lượng segment đến mạng.
(b) Do luôn có một tỉ lệ segment phải phát lại do bị lỗi trong quá trình vận chuyển,
lưu lượng mà mạng thực sự phải vận chuyển nhìn chung lớn hơn lưu lượng đi qua
mạng (thông lượng <= dung lượng kênh truyền).
(c) Khi lưu lượng đến cao quá một mức nào đó, các nút mạng không còn đủ khả
năng chứa và chuyển tiếp các segment, do đó các nút mạng bắt đầu phải loại bỏ
các segment  thông lượng giảm đi.
(d) Nếu lưu lượng đến mạng tiếp tục tăng lên, tỉ lệ segment phát lại trên tổng số
segment trong mạng có thể tăng đến 100%, nghĩa là không có segment nào được
phân phát đi cả, thông lượng của mạng giảm xuống bằng không, mạng bị nghẹt
hoàn toàn (
deadlock
).
Chống tắc nghẽn được chia làm hai loại:
- Điều khiển truy nhập mạng (network access): kiểm soát và điều khiển lượng
thông tin có thể đi vào trong mạng.
- Điều khiển cấp phát bộ đệm (buffer allocation): là cơ chế thực hiện tại các
nút mạng nhằm đảm bảo việc sử dụng bộ đệm là công bằng và tránh việc
không truyền tin được do bộ đệm của tất cả các nút bị tràn (deadlock).
(a)
(b)
(c)
(d)
6


4.2. Nguyên nhân gây tắc nghẽn mạng

4.2.1. Tràn bộ đệm
Khi số lượng segment đến trên hai hoặc ba giao diện vào của một nút mạng đều
cần đi ra trên cùng một đường truyền để đến đích, chúng sẽ phải xếp hàng đợi
được truyền đi. Nếu tình trạng trên kéo dài, hàng đợi sẽ dài dần ra và đầy,
không còn chỗ cho các segment mới đến, chúng bị loại bỏ và sẽ được phát lại, làm
tăng tỉ lệ segment phải phát lại trong mạng.

Biện pháp khắc phục bằng cách tăng kích thước hàng đợi (bộ nhớ) tại các nút
mạng trong một chừng mực nào đó là có ích, tuy nhiên, người ta đã chứng
minh được rằng, tăng kích thước hàng đợi quá một giới hạn nào đó sẽ không
mang lại lợi ích gì, thậm chí còn có thể làm cho vấn đề tắc nghẽn tồi tệ hơn. Đó
là vì các segment sẽ bị timeout ngay trong quá trình xếp hàng, bản sao của chúng
được bên gửi phát lại, làm tăng số lượng segment phát lại trong mạng.
4.2.2.
Tốc độ xử lý chậm (hay nghẽn cổ chai)
Tốc độ xử lý chậm của các nút mạng cũng là một nguyên nhân quan trọng gây
nên tắc nghẽn, bởi vì chúng có thể sẽ làm hàng đợi bị tràn ngay cả khi lưu
lượng segment đến nút mạng nhỏ hơn năng lực vận tải của đường truyền đi ra.
Nhu cầu băng thông cao của các dịch vụ đa phương tiện và các loại hình dịch vụ
mới: dữ liệu, âm thanh và hình ảnh gây ra tắc nghẽn tại các đường truyền dẫn băng
thông nhỏ.
Việc tăng dung lượng đường truyền nhưng không nâng cấp bộ xử lý tại nút
mạng, hoặc chỉ nâng cấp từng phần của mạng đôi khi cũng cải thiện được tình
hình đôi chút, nhưng thường chỉ làm cái “cổ chai”, nơi xảy ra tắc nghẽn, dời đi
chỗ khác mà thôi. Giải quyết vấn đề tắc nghẽn nói chung, cần đến các giải pháp
đồng bộ.


so sánh với bài toán tắc đường trong giao thông.
Nhận xét:
Nếu bộ đệm rỗng  trễ nhỏ, mạng không bị tắc nghẽn. Nhưng: hiệu suất sử dụng
kênh thấp.
H
1
H
2
R1
H
3
A
1
(t)
10Mb/s
D(t)
1.5Mb/s
A
2
(t)
100Mb/s
A
1
(t)
A
2
(t)
X(t)
D(t)
7


Nếu bộ đệm luôn đầy  trễ lớn, có thể tắc nghẽn, nhưng hiệu suất sử dụng kênh
cao.
Tắc nghẽn có khuynh hướng tự làm cho nó trầm trọng thêm. Nếu một nút mạng
nào đó bị tràn bộ đệm, segment đến sẽ bị loại bỏ, trong khi đó nút mạng bên
trên, phía người gửi, vẫn phải giữ bản sao của segment đã gửi trong hàng đợi,
cho đến khi timeout phát lại. Việc phải giữ bản sao segment trong hàng đợi để chờ
báo nhận, cộng thêm việc có thể phải phát lại segment một số lần làm cho hàng
đợi tại chính nút trên cũng có thể bị tràn. Sự tắc nghẽn lan truyền ngược trở lại
phía nguồn phát sinh ra segment.
4.3. Các giải pháp chống tắc nghẽn
4.3.1. Chính sách chung
Các phương pháp chống tắc nghẽn được thực hiện dựa trên các chính sách sau:
− Điều khiển tiếp nhận (Admission control): Cho phép một kết nối mới chỉ khi
mạng có thể đáp ứng một cách thích hợp. Người dùng đưa ra một tập các mô tả về
lưu lượng (tốc độ truyền dẫn cực đại, tốc độ truyền dẫn trung bình, trễ cực đại cho
phép ) trong pha thiết lập kết nối. Mạng cho phép người sử dụng truy nhập đến chỉ
khi nào có đủ tài nguyên sẵn sàng trong mạng. Ngược lại, yêu cầu kết nối bị từ chối.
Mạng giám sát, kiểm soát các luồng lưu lượng để xem liệu người dùng có tuân theo
các mô tả về lưu lượng không.
− Kiểm soát (Policing): Kiểm tra kết nối nào vi phạm các mô tả về lưu lượng để
đưa ra xử lý trừng phạt bằng việc: 1) Xoá các gói vi phạm mô tả; 2) Gán cho chúng
quyền ưu tiên thấp hơn.
− Điều khiển luồng lưu lượng (Flow control): Yêu cầu các luồng giảm tốc độ.
4.3.2. Phân Loại
Theo các đặc điểm chung nêu trên, các phương pháp điều khiển chống tắc nghẽn có
thể được phân loại như trên hình sau.

8


a) Chống tắc nghẽn vòng mở (Open-loop congestion control)
Là sự kết hợp của điều khiển tiếp nhận, kiểm soát, và nguyên lý thùng rò (leaky
bucket).
Phương pháp này không sử dụng thông tin phản hồi từ mạng hoặc từ phía nhận. Vì
vậy, hệ thống phải có khả năng tự quyết định khi nào thì nhận thêm các lưu
lượng mới vào, khi nào thì loại bỏ các segment và loại các segment nào.
Thuật toán thùng rò (Leaky Bucket)
- Do Turner đề xuất năm 1986
- Vấn đề: Dòng dữ liệu từ các trạm xuất ra không đều,lúc nhiều lúc ít khiến cho
dòng dữ liệu trên mạng tăng giảm không ổn định, những lúc có nhiều trạm đồng
thời đổ nhiều dữ liệu vào sẽ gây tắc nghẽn.  Cần phải điều hòa luồng dữ liệu trên
mạng để đạt tới một lưu lượng ổn định, muốn vậy phải điều hòa luồng dữ liệu từ
mỗi trạm xuất ra đường truyền.
- Giải pháp: Hãy hình dung một cái thùng đựng nước có một lỗ rò dưới đáy. Khi
thùng có nước, lượng nước chảy qua lỗ thủng dưới đáy gần như không đổi. Khi
thùng đầy mà nước vẫn chảy vào thêm, lượng nước thừa sẽ tràn đi.
Ở đây cái thùng tượng trưng cho một vùng đệm đặt giữa CPU và đường truyền.
Như vậy dù dữ liệu từ CPU vào thất thường, lúc nhiều lúc ít thì luồng dữ liệu ra
(chảy từ đáy thùng) vẫn đều đặn  Lương lượng được kiểm soát.
Hình minh họa thuật toán Leaky Bucket

- Lưu ý: Nếu thùng đã đầy rồi mà nước vẫn chảy vào thì sẽ bị tràn ra ngoài, tức là
những gói tin đến sau khi vùng đệm đã đầy sẽ bị hủy bỏ. Nếu các đơn vị dữ liệu
trên mạng có cùng kích thước, chẳng hạn như các gói tin trong mạng cell ATM thì
có thể căn cứ vào đơn vị đếm là số gói tin để biết bộ đệm đã đầy hay chưa và lưu
9

lượng đi qua là bao nhiêu. Nhưng nếu các gói tin không cùng kích thước thì phải
cài đặt thêm một bộ đếm (theo đơn vị byte) để tính lưu lượng vào và ra.
Thuật toán Token Bucket

Đây là thuật toán cải tiến hơn thuật toán thùng rò.
- Vấn đề: Trong thuật toán thùng rò có một số điểm chưa linh hoạt. Đó là, dữ liệu
chỉ xuất ra đều đặn từ một trạm, do đó không đáp ứng được một số thời điểm trạm
muốn truyền ngay một lượng lớn dữ liệu. Ta hãy xét một thuật toán linh hoạt hơn
gọi là Token Bucket.
- Gải pháp: Trong thuật toán này, thùng không chứa các gói tin mà chứa các token
(thẻ truyền tin), các token này được sinh ra một cách đều đều, cứ sau một khoảng t
nào đó lại có một token được sinh ra. Trong thùng có bao nhiêu token thì trạm được
phép truyền cùng lúc bấy nhiêu đơn vị dữ liệu,và sau khi truyền thì token trong
thùng bị trừ đi một số tương ứng với số đơn vị dữ liệu đã truyền.
Cũng như thuật toán Leaky Bucket, đơn vị dữ liệu có thể tính theo số gói tin hoặc
theo tổng kích thước (byte) của chúng.
Khi trạm rỗi, truyền ít thì số token còn dư được tích lũy (khác với thuật toán Leaky
bucket). Với cơ chế này, khi mỗi trạm rỗi thì là lúc nó để dành quyền được gửi để
về sau có thể gửi cùng lúc một lượng lớn dữ liệu.
b) Chống tắc nghẽn vòng đóng (Close-loop congestion control)
Đây là phương pháp chống tắc nghẽn dựa trên trạng thái của mạng. Việc giám sát
tắc nghẽn và kiểm soát luồng dựa trên thông tin phản hồi hiện (explicit) hoặc ẩn
(implicit) từ mạng hoặc từ phía nhận.
+ Phản hồi ẩn (implicit feedback): bên phát sử dụng thời gian chờ (time-out) để xác
định liệu có xảy ra tắc nghẽn hay không. Ví dụ: điều khiển chống tắc nghẽn trong
TCP thực hiện theo kiểu này.
+ Phản hồi hiện (explixit feedback): một số bản tin tường minh được gửi đến nguồn
phát. Ví dụ: điều khiển chống tắc nghẽn cho dịch vụ ABR (Available Bit Rate)
trong ATM.
+ Điều khiển theo tốc độ: điều khiển một cách trực tiếp tốc độ truyền tại phía gửi
(nguồn gửi tin).
+ Điều khiển theo kích thước cửa sổ: điều khiển gián tiếp tốc độ truyền thông qua
việc thay đổi kích thước cửa sổ.
Các bước điều khiển vòng đóng:

Các giải pháp điều khiển vòng lặp đóng gồm ba bước như sau:
- Bước một: theo dõi hệ thống để phát hiện tắc nghẽn xảy ra khi nào và ở đâu.
10

Việc phát hiện tắc nghẽn có thể dựa trên một số tham số đo khác nhau, như tỉ lệ
segment bị loại bỏ do thiếu bộ đệm, chiều dài trung bình của hàng đợi, số segment
phải phát lại do bị time-out, thời gian trễ trung bình của segment khi đi qua mạng
v.v. Sự tăng lên của các thông số này nói lên rằng tắc nghẽn đang tăng lên trong
mạng.
- Bước hai: nơi phát hiện ra tắc nghẽn cần phải chuyển thông tin về sự tắc nghẽn
đến những nơi có thể phản ứng lại. Một cách thực hiện rất đơn giản là nút mạng
phát hiện ra tắc nghẽn sẽ gửi segment đến các nguồn sinh lưu lượng trên mạng để
báo tin về sự cố. Tất nhiên, việc này sẽ làm tăng thêm lưu lượng đưa vào mạng
đúng lúc lẽ ra phải giảm đi. Người ta cũng đã đề xuất và thực hiện một số cách
khác nữa. Chẳng hạn, nút mạng phát hiện ra tắc nghẽn sẽ đánh dấu vào một bit
hay một trường định trước của mọi segment trước khi segment
được nút mạng
chuyển tiếp đi, nhằm loan báo cho các nút mạng khác về trạng thái tắc nghẽn.
Có thể nêu ra một cách thực hiện khác nữa, đó là làm cho các nút mạng đều đặn
gửi đi các segment thăm dò để biết tình trạng của mạng.
- Bước ba: điều chỉnh lại hệ thống để sửa chữa sự cố. Các cơ chế thực hiện phản
hồi đều nhằm mục đích là để các máy tính trên mạng có những phản ứng phù hợp
nhằm làm giảm tắc nghẽn. Nếu phản ứng xảy ra quá nhanh, lưu lượng trong hệ
thống sẽ thăng giáng mạnh và không bao giờ hội tụ. Nếu phản ứng quá chậm, việc
điều khiển tắc nghẽn có thể không có ý nghĩa thực tế gì nữa. Chính vì vậy, để cơ
chế phản hồi có hiệu quả, cần phải sử dụng một số cách tính trung bình.


11


4.4. Chống tắc nghẽn trong TCP
4.4.1. Nguyên tắc
Chống tắc nghẽn trong TCP thuộc loại chống tắc nghẽn vòng kín phản hồi ẩn. TCP
dựa vào mất gói để phát hiện tắc nghẽn.
Hai cơ chế để phát hiện ra mất gói.
- Timeout: Khi gói được gửi, phía TCP khởi tạo bộ định thời. Nếu bộ định thời
hết hiệu lực trước khi gói được xác nhận, TCP xem như gói bị mất
- 3dupack: Khi phía nhận TCP nhận gói không đúng trật tự, nó sẽ gửi xác nhận
ACK cho gói mà nó đã nhận đúng gần nhất. Ví dụ, giả sử phía nhận nhận gói từ 1
đến 5, và gói 6 bị mất. Khi phía nhận nhận gói 7, nó gửi dupack cho gói 5. Phía
gửi TCP coi việc nhận được 3 bản phúc đáp giống nhau như là dấu hiệu của 1 gói
mất.
4.4.2. Hoạt động
Xem xét mối quan hệ giữa tải, trễ, và hiệu năng sử dụng mạng:

Tải: L (bit/s), trễ: D (s).
Gọi P là một tham số đơn giản để đánh giá hiệu năng mạng, với: P=L/D
Mục tiêu là đạt được P càng lớn càng tốt.
Để đạt được trạng thái tối ưu, bên phát TCP thay đổi tốc độ bằng việc thay
đổi kích thước cửa sổ (Cwnd) theo công thức:


(1) Giai đoạn khởi đầu chậm SS (Slow Start)
TCP đi vào mô hình khởi đầu chậm khi bắt đầu kết nối. Trong suốt quá trình khởi
đầu chậm, phía gửi tăng nhanh tốc độ gửi theo hàm mũ (exponential increase)
để sớm đạt trạng thái tối ưu.
Thuật toán hoạt động như sau:
Trễ trung bình
Tải
Hiệu năng

Tải
“Tải tối ưu”
Window=min{ReceiveWindow, CongestionWindow}
Rwnd bên thu Cwnd bên phát
12

- Bổ sung thêm các tham số cửa sổ tắc nghẽn Cwnd (Congestion window)
và giới hạn trên của Cwnd là ssthresh (ss threshhold) vào tập trạng thái của
mỗi kết nối.
- Khi bắt đầu phát hoặc bắt đầu lại việc phát sau khi có segment bị mất thì
đặt Cwnd := 1 MSS (Maximum Segment Size).
- Mỗi khi nhận được một báo nhận mới, thì tăng Cwnd lên gấp đôi. Nhưng
không tăng cwnd quá Window Size (Rwnd) mà bên nhận thông báo.
- Khi Cwnd ≥ ssthresh, chuyển sang giai đoạn tránh tắc nghẽn CA.


Hình. Tăng cửa sổ theo hàm mũ trong giai đoạn khởi động chậm (SS).

Theo cơ chế khởi động chậm, cửa sổ tăng lên theo hàm mũ, nó đạt tới kích thước
W sau thời gian bằng RTT.log2W, trong đó RTT là thời gian khứ hồi và W
tính bằng đơn vị segment. Điều này có nghĩa là cho phép phiên TCP tăng tốc độ
nhanh chóng sau khi thiết lập kết nối để đạt hiệu năng cao. Theo thuật toán này,
bên gửi sẽ truyền dữ liệu với tốc độ khi cao nhất là gấp đôi giá trị cực đại có thể
của đường truyền. Chính vì vậy, giai đoạn khởi động chậm cần phải được kết
thúc khi cửa sổ W đạt tới một ngưỡng nhất định.
(2) Giai đoạn chống tắc nghẽn CA (Congestion Avoidance)
Sau khi kích thước Cwnd đạt đến giá trị ngưỡng ssthresh, kết nối TCP chuyển sang
chế độ tránh tắc nghẽn (CA).
Cwnd tăng tuyến tính mỗi một đơn vị (01 MSS) sau một RTT không có gói lỗi cho
13


đến khi tắc nghẽn được phát hiện.

Hình. Tăng cửa sổ theo cấp số cộng trong giai đoạn tránh tắc nghẽn (CA).

Dấu hiệu tắc
ngh
ẽ
n:

TCP chuyển sang trạng thái phát hiện tắc nghẽn khi mất gói xảy ra khi:
(1) RTT > Timeout mà không nhận được ACK.
+ Đặt ngưỡng ssthresh xuống còn một nửa giá trị hiện tại của Cwnd: ssthresh :=
Cwnd/2 (giảm theo cấp số nhân)
+ Đặt Cwnd về 1 MSS: Cwnd := 1
+ TCP chuyển về trạng thái slow start (SS)
(2) Nhận được 3 Ack (báo nhận lặp), điều đó cho biết đã có nhiều gói tin đến đích
không đúng thứ tự, nghĩa là đã có gói tin bị mất.
+ Đặt ngưỡng ssthresh xuống còn một nửa giá trị hiện tại của Cwnd: ssthresh :=
cwnd/2
+ Đặt Cwnd bằng ½ giá trị hiện tại: Cwnd:= Cwnd/2
+ TCP quay lại trạng thái chống tắc nghẽn (CA).

14


Hình. Tổng kết chính sách điều khiển chống tắc nghẽn của TCP.

Hình. Ví dụ TCP Congestion control
Nhận

xét:
- Trong giai đoạn CA, Cwnd tăng tuyến tính:
+ Đảm bảo tận dụng băng thông có thể sử dụng được
+ Vẫn thăm dò tiếp khả năng sử dụng băng thông nhiều hơn,
- Cwnd bị giảm theo cấp số nhân (Multiplicative Decreased): bởi vì theo cơ chế
khởi động chậm, cửa sổ gửi tăng lên theo hàm mũ, cho nên cũng cần phải rút lui
theo cách này cho đủ nhanh khi đã có dấu hiệu của tắc nghẽn.
- Vì tắc nghẽn tăng lên theo hàm mũ, cho nên việc phát hiện sớm là quan trọng.
Nếu tắc nghẽn được phát hiện sớm, thì chỉ cần một vài điều chỉnh nhỏ đối với cửa
sổ của bên gửi cũng có thể giải quyết được vấn đề; ngược lại, sẽ phải điều chỉnh
15

rất nhiều để mạng có thể chuyển hết đống segment tắc nghẽn trong mạng ra
ngoài. Tuy nhiên, do bản chất luôn thăng giáng mạnh của lưu lượng, phát hiện
tắc nghẽn sớm một cách tin cậy là một việc khó.
- Thông tin phản hồi là ẩn và vì vậy cửa sổ gửi luôn giảm đi một nửa khi xảy ra tắc
nghẽn là không thực sự hiệu quả
- TCP không chia sẻ thông tin điều khiển, vì vậy các kết nối cùng một thời điểm
đến cùng một đích (một trường hợp thường xảy ra với lưu lượng web) sẽ phải cạnh
tranh, thay vì phối hợp để sử dụng băng thông mạng một cách hợp lý
- Đối với mạng đa dịch vụ, thuật toán điều khiển chống tắc nghẽn của TCP không
đem lại bình đẳng cần thiết cho các ứng dụng
- Đối với mạng có lưu lượng biến đổi động, biến đổi nhanh, điều khiển tắc nghẽn
của TCP tỏ ra bất ổn định và không hội tụ.
Thuật toán Fast Retransmit
(FRTX): (bỏ)

- Sau khi nhận được Dupack (>=3), TCP thực hiện phát lại nhanh, không
chờ bị Timeout, sau đó chuyển ngay về SS.
- Đây là một cách “dự đoán thông minh” rằng, gói tin đã bị mất.










Hình 5.11. Giao thức Tahoe TCP

Thuật toán Fast Recovery
(FRCV): (bỏ)

Cải tiến FRTX: thực hiện FRTX xong về CA chứ không về SS:
- ssthresh := cwnd/2, nhưng không nhỏ hơn 2 (gói tin)
- cwnd := cwnd + 3. Bên gửi “đoán”: 3 dupack ứng với 3 gói tin đã được
nhận đúng.
- Với mỗi dupack nhận được thêm, tăng cwnd := cwnd + 1
16


Hình 5.12. Giao thức Reno TCP

Bài tập
1. Xét tính hiệu quả của việc xử dụng cơ chế SS với một liên kết có RTT=10ms và
không có tắc nghẽn. Cho biết Rwnd = 24 KB và MSS = 2 KB. Cần bao nhiêu thời
gian trước khi cửa sổ thu đầy đủ có thể được gửi đi?
The first bursts contain 2K, 4K, 8K, and 16K bytes, respectively. The next one is
24 KB and occurs after 40 msec.

Tại giai đoạn SS, Cwind tăng theo hàm mũ
0ms Cwnd = 1 MSS = 2K
10ms Cwnd = 2 MSS = 4K
20ms Cwnd = 4 MSS = 8K
30ms Cwnd = 8 MSS = 16K
40ms Cwnd = min(Rwnd=24K, Cwnd = 32K)= 24K

2. Giả sử một kết nối TCP sử dụng cửa sổ tắc nghẽn Cwnd = 18 KB thì sảy ra
timeout. Tính kích thước cửa sổ nếu 4 lần truyền sau đó đều thành công. Giải thiết
kích thước segment tối đa là 1 KB.
Timeout chuyển về SS với Cwnd:=1 MSS, so the next transmission will be 1
maximum segment size. Then 2, 4, and 8.
So after four successes, Cwnd will be 8 KB.

17


3. A TCP machine is sending full windows of 65,535 bytes over a 1-Gbps channel
that has a 10-msec one-way delay. What is the maximum throughput achievable?
What is the line efficiency?
RRT=20ms, One window can be sent every 20 msec. This gives 50 windows/sec,
for a maximum data rate of about 50 x 65,535 bytes = 3.3 million bytes/sec =
26.2Mbps. The line efficiency is then 26.2 Mbps/1000 Mbps or 2.6 percent.




18