Nhóm 12 điều khiển tắc nghẽn cho giao thức TCP

HỌC VIÊN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG

BÀI BÁO CÁO
BÁO HIỆU VÀ ĐIỀU KHIỂN KẾT NỐI
CHỦ ĐỀ: ĐIỀU KHIỂN TẮC NGHẼN CHO GIAO THỨC TCP
NHĨM: 12

Giảng viên: Hồng Trọng Minh
Thành viên: Đào Đình Đồn–B18DCVT101
Nguyễn Hải Hưng-B18DCVT213
Phạm Văn Thao-B18DCVT405

Hà Nội, Tháng 10/2021


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

Lời mở đâu

Như chúng ta đã biết trong truyền thông dữ liệu qua mạng thì việc kiểm sốt lưu
lượng trong khi truyền là rất quan trọng. Nó quyết định đến việc truyền một cách
tin cậy từ nguồn đến đích khơng. Vì vậy chúng ta sẽ đi tìm hiểu về hoạt động
“kiểm sốt tắc nghẽn” TCP. Do chưa có đầy đủ kiến thức sâu nên mong thầy thông
cảm về bài báo cáo.


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

Mục lục:
1. Kiểm soát tắc nghẽn TCP cổ điển …………………………………………...2
-

Khởi động chậm ( Slow Start)……………………………………………6
Tránh tắc nghẽn( Congestion Avoidance)……………………………….7
Khôi phục nhanh( Fast Recovery)………………………………………..9
Kiểm sốt tắc nghẽn TCP: Retrospective………………………………..10
TCP Cubic…………………………………………………………………11
Mơ tả macro của Thông lượng TCP Reno………………………………13

2. Thông báo tắc nghẽn rõ ràng do mạng hỗ trợ và kiểm soát tắc nghẽn dựa trên
độ trễ……………………………………………………………………........ 13
-

Thông báo tắc nghẽn cụ thể( Explicit Notification)……………………..14
Kiểm soát tắc nghẽn dựa trên độ trễ( Delay Based)…………………….15

3. Kiểm soát một cách tin cậy…………………………………………..……….16
-

Kiểm soát qua giao thức UDP………….…………………………………18

-

Kết nối TCP tin cậy…………………………………….………………….19

Kết luân…………………………………………………………………………….21

Các hình cần lưu ý:
▪
▪
▪
▪
▪

Hình 1: Khởi động chậm TCP ……………………………………… 6
Hình 2: Mơ tả FSM về kiểm sốt tắc nghẽn TCP…………………… 8
Hình 3: Sự phát triển của cửa sổ tắc nghẽn của TCP………………... 9
Hình 4: Điều khiển tắc nghẽn cộng-tăng, nhân-giảm………………...11
Hình 5: Tốc độ gửi tránh tắc nghẽn TCP: TCP Reno và TCP
CUBIC……………………………………………………………… 12
▪ Hình 6: Thơng báo tắc nghẽn rõ ràng: kiểm sốt tắc nghẽn
do mạng hỗ trợ……………………………………………………......14
▪ Hình 7: Hai kết nối TCP chia sẻ một liên kết tắc nghẽn duy nhất……17
▪ Hình 8: Thông lượng được thực hiện bởi các kết nối TCP 1 và 2… 18

1


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

Điều khiển tắc nghẽn cho giao thức TCP

Như chúng ta đã biết TCP cung cấp một dịch vụ truyền tải đáng tin cậy giữa hai
tiến trình chạy trên các máy chủ khác nhau. Một thành phần quan trọng khác của
TCP là cơ chế kiểm sốt tắc nghẽn của nó. Theo những gì đã tìm hiểu trước đây,

những gì chúng ta có thể gọi là TCP “Cổ điển” — phiên bản TCP được chuẩn hóa
trong [RFC 2581] và gần đây nhất là [RFC 5681] —sử dụng kiểm sốt tắc nghẽn
đầu cuối thay vì tắc nghẽn do mạng hỗ trợ kiểm sốt, vì lớp IP không cung cấp
phản hồi rõ ràng cho hệ thống đầu cuối về tắc nghẽn mạng. Đầu tiên chúng ta sẽ
trình bày sâu về phiên bản TCP “cổ điển” này trong Phần 1. Trong Phần 2, sau đó
chúng ta sẽ xem xét các phiên bản mới hơn của TCP sử dụng chỉ báo tắc nghẽn
rõ ràng do lớp mạng cung cấp hoặc khác một chút với TCP “cổ điển” theo bất kỳ
cách nào trong số các cách khác nhau. Sau đó, chúng tơi sẽ đề cập đến thách thức
cung cấp sự công bằng giữa các luồng vận chuyển phải chia sẻ một liên kết bị tắc
nghẽn.

1. Kiểm soát tắc nghẽn TCP cổ điển
Phương pháp được TCP thực hiện là yêu cầu mỗi người gửi giới hạn tốc độ
gửi lưu lượng truy cập vào kết nối của mình như một chức năng của tắc nghẽn
mạng.
Trong qua trình trao đổi dữ liệu:
• Nếu người gửi TCP nhận thấy rằng có rất ít tắc nghẽn trên đường dẫn
giữa chính nó và đích, thì người gửi TCP sẽ tăng tốc độ gửi của nó.
• Nếu người gửi nhận thấy rằng có tắc nghẽn dọc theo đường dẫn, thì
người gửi sẽ giảm tốc độ gửi.
➢ Nhưng cách tiếp cận này đặt ra ba câu hỏi:
• Đầu tiên, làm thế nào để người gửi TCP giới hạn tốc độ mà nó gửi lưu
lượng truy cập vào kết nối của mình?
• Thứ hai, làm thế nào để một người gửi TCP nhận thấy rằng có sự tắc
nghẽn trên đường dẫn giữa chính nó và đích?

2


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

• Thứ ba, người gửi nên sử dụng thuật toán nào để thay đổi tốc độ gửi như
một hàm của tắc nghẽn đầu cuối được nhận thức?
Trước tiên, chúng ta hãy kiểm tra cách người gửi TCP giới hạn tốc độ gửi lưu
lượng truy cập vào kết nối của mình.
• Chúng ta đã thấy rằng mỗi bên của kết nối TCP bao gồm: một bộ đệm
nhận, một bộ đệm gửi và một số biến (LastByteRead, rwnd, v.v.).
• Cơ chế kiểm sốt tắc nghẽn TCP hoạt động ở người gửi theo dõi của
một biến bổ sung, “cửa sổ tắc nghẽn”. Cửa sổ tắc nghẽn, được ký hiệu
là cwnd, áp đặt một hạn chế đối với tốc độ mà người gửi TCP có thể gửi
lưu lượng truy cập vào mạng lưới. Cụ thể, số lượng dữ liệu chưa được
xác nhận tại một người gửi không được vượt quá mức tối thiểu của cwnd
và rwnd, nghĩa là:
Thời gian byte cuối cùng được gửi trừ đi thời gian byte cuối cùng được
kiểm tra “phải nhỏ hơn hoặc bằng” giá trị nhỏ nhất của cwnd, rwnd.

Để tập trung vào kiểm soát tắc nghẽn (trái ngược với kiểm sốt luồng), do đó,
chúng ta hãy giả sử rằng bộ đệm nhận TCP quá lớn nên có thể bỏ qua ràng buộc
cửa sổ nhận; do đó, số lượng dữ liệu chưa được xác nhận ở người gửi chỉ bị giới
hạn bởi cwnd. Chúng tôi cũng sẽ giả định rằng người gửi ln có dữ liệu để gửi,
tức là tất cả các phân đoạn trong cửa sổ tắc nghẽn đều được gửi.
• Ràng buộc trên giới hạn số lượng dữ liệu chưa được xác nhận ở người gửi
và do đó gián tiếp giới hạn tốc độ gửi của người gửi. Để thấy điều này, hãy
xem xét một kết nối mà mất mát và độ trễ truyền gói là khơng đáng kể. Sau
đó, đại khái, ở đầu mỗi RTT, ràng buộc cho phép người gửi gửi cwnd byte
dữ liệu vào kết nối; vào cuối RTT, người gửi nhận được thông báo xác nhận
cho dữ liệu. Do đó, tốc độ gửi của người gửi là khoảng cwnd / RTT byte /
giây. Bằng cách điều chỉnh giá trị của cwnd, do đó, người gửi có thể điều

chỉnh tốc độ gửi dữ liệu vào kết nối của mình.
• Tiếp theo, hãy xem xét cách người gửi TCP nhận thấy rằng có tắc nghẽn
trên đường dẫn giữa chính nó và đích. Hãy để chúng tơi xác định một "sự
kiện mất mát" tại một người gửi TCP như sự xuất hiện của thời gian chờ
hoặc nhận ba ACK trùng lặp từ người nhận. Khi có tắc nghẽn quá mức, thì
một (hoặc nhiều) bộ đệm bộ định tuyến dọc theo đường dẫn tràn, gây ra
3


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

một datagram (chứa một đoạn TCP) bị loại bỏ. Khi datagram bị rớt lại dẫn
đến sự kiện mất dữ liệu ở người gửi — hết thời gian chờ hoặc nhận ba ACK
trùng lặp — được người gửi coi là dấu hiệu tắc nghẽn trên đường dẫn người
gửi đến người nhận.
• Sau khi xem xét cách phát hiện tắc nghẽn, tiếp theo hãy xem xét trường hợp
khi mạng khơng có tắc nghẽn, nghĩa là khi sự kiện mất mạng không xảy ra.
Trong trường hợp này, các xác nhận cho các phân đoạn chưa được xác nhận
trước đó sẽ được nhận tại người gửi TCP.
✓ Như chúng ta sẽ thấy, TCP sẽ đưa những xác nhận như một dấu hiệu
cho thấy tất cả đều ổn - rằng các phân đoạn được truyền vào mạng
đang được phân phối thành cơng đến đích - và sẽ sử dụng xác nhận
để tăng kích thước cửa sổ tắc nghẽn của nó (và do đó tốc độ truyền
của nó).
✓ Lưu ý rằng nếu các xác nhận đến với tốc độ tương đối chậm (ví dụ:
nếu đường dẫn đầu cuối có độ trễ cao hoặc chứa liên kết băng thơng
thấp), thì cửa sổ tắc nghẽn sẽ được tăng lên với tốc độ tương đối
chậm. Mặt khác, nếu các xác nhận đến với tốc độ cao, thì cửa sổ tắc

nghẽn sẽ nhanh chóng tăng lên. Bởi vì TCP sử dụng các xác nhận để
kích hoạt (hoặc đồng hồ) sự gia tăng kích thước cửa sổ tắc nghẽn của
nó, TCP được cho là có khả năng tự xung nhịp.
• Với cơ chế điều chỉnh giá trị của cwnd để kiểm soát tốc độ gửi, câu hỏi
quan trọng vẫn là: Người gửi TCP nên xác định tốc độ như thế nào nên
gửi? Nếu người gửi TCP gửi chung quá nhanh, họ có thể làm nghẽn
mạng, dẫn đến kiểu sụp đổ tắc nghẽn. Tuy nhiên, nếu người gửi TCP
quá thận trọng và gửi quá chậm, họ có thể sử dụng băng thơng trong
mạng; nghĩa là, người gửi TCP có thể gửi với tốc độ cao hơn mà khơng
làm nghẽn mạng. Sau đó, làm cách nào để người gửi TCP xác định tốc
độ gửi của họ để họ không làm nghẽn mạng nhưng đồng thời tận dụng
được tất cả băng thơng có sẵn? Người gửi TCP có được phối hợp một
cách rõ ràng hay có một cách tiếp cận phân tán trong đó người gửi TCP
có thể đặt tốc độ gửi của họ chỉ dựa trên thông tin cục bộ? TCP trả lời
những câu hỏi này bằng cách sử dụng các nguyên tắc hướng dẫn sau:
✓ Một phân đoạn bị mất có nghĩa là tắc nghẽn và do đó, tốc độ của
người gửi TCP sẽ giảm khi một phân đoạn bị mất. Nếu một sự kiện
hết thời gian chờ hoặc việc nhận được bốn xác nhận cho một phân
đoạn nhất định (một ACK gốc và sau đó ba ACK trùng lặp) được
4


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

hiểu là một dấu hiệu ngầm định về "sự kiện mất mát" của phân đoạn
theo sau bốn lần Phân đoạn ACKed, kích hoạt truyền lại phân đoạn
bị mất. Từ quan điểm kiểm soát tắc nghẽn, câu hỏi đặt ra là làm thế
nào người gửi TCP nên giảm kích thước cửa sổ tắc nghẽn, và do đó

tốc độ gửi của nó, để đáp ứng với sự kiện mất mát được suy luận này.
✓ Một phân đoạn được xác nhận cho biết rằng mạng đang phân phối
các phân đoạn của người gửi đến người nhận và do đó, tỷ lệ của
người gửi có thể tăng lên khi một ACK đến cho một phân đoạn chưa
được xác nhận trước đó. Sự xuất hiện của các xác nhận được coi là
một dấu hiệu ngầm rằng tất cả đều tốt - các phân đoạn đang được
chuyển thành cơng từ người gửi đến người nhận và do đó mạng
khơng bị tắc nghẽn. Do đó, kích thước cửa sổ tắc nghẽn có thể được
tăng lên.
✓ Thăm dị băng thơng. Với các ACK chỉ ra một đường dẫn từ nguồn
đến đích khơng bị tắc nghẽn và các sự kiện mất mát chỉ ra một đường
dẫn bị tắc nghẽn, chiến lược của TCP để điều chỉnh tốc độ truyền của
nó là tăng tốc độ của nó để đáp ứng với các ACK đến cho đến khi
xảy ra sự kiện mất, tỷ lệ được giảm xuống. Do đó, người gửi TCP
tăng tốc độ truyền của nó để thăm dị tốc độ bắt đầu tắc nghẽn, lùi lại
từ tốc độ đó, và sau đó bắt đầu thăm dị lại để xem tốc độ bắt đầu tắc
nghẽn có thay đổi hay khơng.
Ví dụ: Hành vi của người gửi TCP có lẽ tương tự như đứa trẻ yêu
cầu (và nhận) ngày càng nhiều quà tặng cho đến khi cuối cùng đứa
trẻ được thông báo “Không!”, Lùi lại một chút, nhưng sau đó bắt đầu
thực hiện lại yêu cầu ngay sau đó.
➢ Lưu ý rằng mạng khơng có báo hiệu rõ ràng về trạng thái tắc nghẽn —
ACK và sự kiện mất mát đóng vai trị là tín hiệu ngầm định — và mỗi
TCP người gửi hành động trên thông tin cục bộ một cách không đồng
bộ từ những người gửi TCP khác.
Với tổng quan này về kiểm sốt tắc nghẽn TCP, giờ đây chúng tơi có thể xem xét
các chi tiết của thuật tốn kiểm sốt tắc nghẽn TCP. Thuật tốn có ba thành phần
chính: (1) khởi động chậm, (2) tránh tắc nghẽn và (3) khôi phục nhanh. Khởi động
chậm và tránh tắc nghẽn là các thành phần bắt buộc của TCP, khác nhau về cách
chúng tăng kích thước cwnd để đáp ứng với các ACK đã nhận. Khôi phục nhanh

được khuyến nghị, nhưng không bắt buộc, đối với người gửi TCP.
5


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

❖ Khởi động châm
• Khi kết nối TCP bắt đầu, giá trị của cwnd thường được khởi tạo thành
giá trị nhỏ là 1 MSS [RFC 3390], dẫn đến tốc độ gửi ban đầu khoảng
MSS /RTT. Ví dụ: nếu MSS = 500 byte và RTT = 200 msec, tốc độ gửi
ban đầu kết quả chỉ khoảng 20 kbps. Vì băng thơng khả dụng cho người
gửi TCP có thể lớn hơn nhiều so với MSS / RTT, người gửi TCP muốn
tìm lượng băng thơng khả dụng một cách nhanh chóng. Do đó, ở trạng
thái khởi động chậm, giá trị của cwnd bắt đầu từ 1 MSS và tăng 1 MSS
mỗi khi một đoạn truyền được ghi nhận lần đầu tiên.

Hình 1: Khởi động chậm TCP

Ta thấy ở Hình 1, TCP gửi phân đoạn đầu tiên vào mạng và chờ một xác
nhận. Khi xác nhận này đến, người gửi TCP tăng cửa sổ tắc nghẽn lên một
MSS và gửi đi hai phân đoạn có kích thước tối đa. Các phân đoạn này sau
đó được xác nhận, với người gửi tăng cửa sổ tắc nghẽn lên 1 MSS cho mỗi
phân đoạn được xác nhận, đưa ra cửa sổ tắc nghẽn là 4 MSS, v.v. Quá trình
này dẫn đến việc tăng gấp đôi tốc độ gửi mỗi RTT. Do đó, tốc độ gửi TCP
bắt đầu chậm nhưng tăng theo cấp số nhân trong giai đoạn bắt đầu chậm.
6

Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

• Nhưng khi nào thì sự tăng trưởng theo cấp số nhân này kết thúc? Bắt
đầu chậm cung cấp một số câu trả lời cho câu hỏi này.
✓ Đầu tiên, nếu có sự kiện mất mát (tức là tắc nghẽn) được chỉ ra bởi
thời gian chờ, người gửi TCP đặt giá trị của cwnd thành 1 và bắt đầu
lại quá trình khởi động chậm. Nó cũng đặt giá trị của biến trạng thái
thứ hai, ssthresh (viết tắt của “ngưỡng khởi động chậm”) thành cwnd
/ 2 — một nửa giá trị của tắc nghẽn giá trị cửa sổ khi phát hiện tắc
nghẽn.
✓ Cách thứ hai trong đó bắt đầu chậm có thể kết thúc được gắn trực
tiếp với giá trị của ssthresh. Vì ssthresh bằng một nửa giá trị của
cwnd khi lần cuối phát hiện tắc nghẽn, nên có thể hơi liều lĩnh nếu
tiếp tục nhân đơi cwnd khi nó đạt đến hoặc vượt qua giá trị của
ssthresh. Do đó, khi giá trị của cwnd bằng ssthresh, khởi động chậm
kết thúc và TCP chuyển sang chế độ tránh tắc nghẽn.
✓ Chúng ta thấy, TCP tăng cwnd một cách thận trọng hơn khi ở chế độ
tránh tắc nghẽn. Cách cuối cùng trong đó khởi động chậm có thể kết
thúc là nếu phát hiện ba ACK trùng lặp, trong trường hợp đó TCP
thực hiện truyền lại nhanh và chuyển sang trạng thái khôi phục
nhanh, như được thảo luận bên dưới. Hành vi của TCP khi khởi động
chậm được tóm tắt trong mơ tả FSM về kiểm sốt tắc nghẽn TCP
trong Hình 3.51.
❖ Tránh tắc nghẽn
• Khi chuyển sang trạng thái tránh tắc nghẽn, giá trị của cwnd xấp xỉ một
nửa giá trị của nó khi lần cuối cùng gặp phải tắc nghẽn — tắc nghẽn có
thể chỉ gần đến! Do đó, thay vì tăng gấp đôi giá trị của cwnd mỗi RTT,
TCP áp dụng một cách tiếp cận thận trọng hơn và tăng giá trị của cwnd

chỉ bằng một MSS mỗi RTT [RFC 5681]. Điều này có thể được thực
hiện theo một số cách. Một cách tiếp cận phổ biến là người gửi TCP
tăng cwnd theo byte MSS (MSS / cwnd) bất cứ khi nào một xác nhận
mới đến.
Ví dụ: nếu MSS là 1.460 byte và cwnd là 14.600 byte, thì 10 phân đoạn
đang được gửi trong một RTT. Mỗi ACK đến (giả sử một ACK trên mỗi
đoạn) làm tăng kích thước cửa sổ tắc nghẽn lên 1/10 MSS và do đó, giá trị
của cửa sổ tắc nghẽn sẽ tăng thêm một MSS sau ACK khi tất cả 10 phân
đoạn đã được nhận.
7


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

• Nhưng khi nào thì sự gia tăng tuyến tính của tính năng tránh tắc nghẽn
(1 MSS trên mỗi RTT) nên kết thúc? Thuật toán tránh tắc nghẽn của
TCP hoạt động tương tự khi hết thời gian chờ xảy ra như trong trường
hợp khởi động chậm: Giá trị của cwnd được đặt thành 1 MSS và giá trị
của ssthresh được cập nhật thành một nửa giá trị của cwnd khi sự kiện
mất mát xảy ra. Tuy nhiên, hãy nhớ lại rằng một sự kiện thua lỗ cũng có
thể được kích hoạt bởi một sự kiện ACK trùng lặp ba lần.

Hình 2: Mơ tả FSM về kiểm sốt tắc nghẽn TCP

• Trong trường hợp này, mạng đang tiếp tục phân phối một số phân đoạn
từ người gửi đến người nhận (như được chỉ ra bởi việc nhận các ACK
trùng lặp). Vì vậy, hành vi của TCP đối với loại sự kiện mất mát này sẽ
ít nghiêm trọng hơn so với tổn thất được chỉ định thời gian chờ: TCP

giảm một nửa giá trị của cwnd (thêm vào 3 MSS để tính tốn cho ba
ACK trùng lặp nhận được) và ghi lại giá trị của ssthresh bằng một nửa
giá trị của cwnd khi nhận được ba ACK trùng lặp. Trạng thái phục hồi
nhanh sau đó được nhập.

8


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

❖ Khơi phục nhanh
• Trong khơi phục nhanh, giá trị của cwnd được tăng thêm 1 MSS cho
mỗi ACK trùng lặp nhận được cho phân đoạn bị thiếu khiến TCP đi vào
trạng thái khôi phục nhanh. Cuối cùng, khi một ACK đến cho phân đoạn
bị thiếu, TCP sẽ đi vào trạng thái tránh tắc nghẽn sau khi xả bớt cwnd.
Nếu sự kiện hết thời gian xảy ra, khôi phục nhanh sẽ chuyển sang trạng
thái khởi động chậm sau khi thực hiện các hành động tương tự như khi
khởi động chậm và tránh tắc nghẽn: Giá trị của cwnd được đặt thành 1
MSS và giá trị của ssthresh được đặt thành một nửa giá trị của cwnd khi
sự kiện mất mát xảy ra.

Hình 3: Sự phát triển của cửa sổ tắc nghẽn của TCP (Tahoe và Reno)
• Khơi phục nhanh là một thành phần được khuyến nghị, nhưng không bắt
buộc của TCP. Điều thú vị là phiên bản đầu tiên của TCP, được gọi là
TCP Tahoe, đã cắt vô điều kiện cửa sổ tắc nghẽn của nó thành 1 MSS
và bước vào giai đoạn khởi động chậm sau sự kiện mất ACK được chỉ
định thời gian chờ hoặc ba lần trùng lặp. Phiên bản mới hơn của TCP,
TCP Reno, tích hợp khả năng phục hồi nhanh.

• Hình 3 minh họa sự phát triển của cửa sổ tắc nghẽn của TCP cho cả
Reno và Tahoe. Trong hình này, ngưỡng ban đầu bằng 8 MSS. Trong
tám vòng truyền đầu tiên, Tahoe và Reno thực hiện các hành động giống
hệt nhau. Cửa sổ tắc nghẽn tăng nhanh theo cấp số nhân khi khởi động
chậm và chạm ngưỡng ở vòng truyền thứ tư. Cửa sổ tắc nghẽn sau đó
9


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

tăng lên theo tuyến tính cho đến khi sự kiện ACK trùng lặp ba lần xảy
ra, ngay sau vòng truyền 8. Lưu ý rằng cửa sổ tắc nghẽn là 12 . MSS khi
sự kiện mất mát này xảy ra. Giá trị của ssthresh sau đó được đặt thành
0,5 . cwnd = 6 . MSS. Trong TCP Reno, cửa sổ tắc nghẽn được đặt thành
cwnd = 9 . MSS và sau đó phát triển tuyến tính. Trong TCP Tahoe, cửa
sổ tắc nghẽn được đặt thành 1 MSS và tăng theo cấp số nhân cho đến
khi nó đạt đến giá trị của ssthresh, tại thời điểm đó, nó phát triển tuyến
tính.
• Hình 3 trình bày mơ tả FSM đầy đủ về các thuật tốn kiểm soát tắc
nghẽn của TCP — khởi động chậm, tránh tắc nghẽn và khơi phục nhanh.
Hình này cũng chỉ ra nơi có thể xảy ra việc truyền các phân đoạn mới
hoặc phân đoạn đã truyền lại. Mặc dù điều quan trọng là phải phân biệt
giữa kiểm soát lỗi / truyền lại TCP và kiểm soát tắc nghẽn TCP, nhưng
cũng cần đánh giá cao cách hai khía cạnh này của TCP được liên kết
chặt chẽ với nhau.
❖ Kiểm soát tắc nghẽn TCP: Retrospective
• Sau khi đi sâu vào các chi tiết về khởi động chậm, tránh tắc nghẽn và
khôi phục nhanh. Bỏ qua khoảng thời gian khởi động chậm ban đầu khi

kết nối bắt đầu và giả định rằng tổn thất được chỉ ra bởi ba ACK trùng
lặp chứ không phải thời gian chờ, kiểm soát tắc nghẽn của TCP bao gồm
tăng tuyến tính (cộng) trong cwnd 1 MSS cho mỗi RTT và sau đó giảm
một nửa (giảm số nhân) của cwnd trên một sự kiện ACK trùng lặp ba
lần. Vì lý do này, kiểm soát tắc nghẽn TCP thường được gọi là một hình
thức kiểm sốt tắc nghẽn cộng tính-tăng, đa phân tử (AIMD).
• Kiểm sốt tắc nghẽn AIMD làm phát sinh hành vi “răng cưa” được hiển
thị trong Hình 4, cũng minh họa độc đáo trực giác trước đây của chúng
ta về việc “thăm dò” TCP đối với băng thơng — TCP tăng tuyến tính
kích thước cửa sổ tắc nghẽn (và do đó tốc độ truyền của nó) cho đến khi
nhân đôi ba lần sự kiện ACK xảy ra. Sau đó, nó giảm kích thước cửa sổ
tắc nghẽn của mình xuống một hệ số hai nhưng sau đó lại bắt đầu tăng
tuyến tính, thăm dị để xem liệu có thêm băng thơng khả dụng hay
khơng.
• Thuật tốn AIMD của TCP được phát triển dựa trên một lượng lớn thông
tin chi tiết về kỹ thuật và thử nghiệm kiểm soát tắc nghẽn trong các mạng
hoạt động. Mười năm sau sự phát triển của TCP, các phân tích lý thuyết
cho thấy rằng thuật tốn kiểm sốt tắc nghẽn của TCP đóng vai trò như
10


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

một thuật tốn tối ưu hóa khơng đồng bộ phân tán, dẫn đến một số khía
cạnh quan trọng của hiệu suất mạng và người dùng được tối ưu hóa đồng
thời Từ đó, một lý thuyết phong phú về kiểm soát tắc nghẽn đã được
phát triển.

Hình 4: Điều khiển tắc nghẽn cộng-tăng, nhân-giảm
❖ TCP CUBIC (khối)
• Với cách tiếp cận cộng - tăng, nhân - giảm của TCP Reno để kiểm
soát tắc nghẽn, người ta có thể tự hỏi liệu đây có phải là cách tốt nhất
để “thăm dị” tốc độ gửi gói chỉ dưới ngưỡng kích hoạt mất gói hay
khơng. Thật vậy, việc cắt giảm một nửa tốc độ gửi (hoặc thậm chí tệ
hơn, cắt giảm tốc độ gửi xuống một gói trên mỗi RTT như trong phiên
bản TCP trước đó được gọi là TCP Tahoe) và sau đó tăng khá chậm
theo thời gian có thể quá thận trọng. Nếu trạng thái của liên kết bị tắc
nghẽn nơi xảy ra mất gói khơng thay đổi nhiều, thì có lẽ tốt hơn nên
tăng tốc độ gửi nhanh hơn để đạt gần với tốc độ gửi trước khi bị mất
và chỉ sau đó thăm dị băng thơng một cách thận trọng và nó được gọi
là TCP CUBIC.
• TCP CUBIC chỉ khác một chút so với TCP Reno. Một lần nữa, cửa
sổ tắc nghẽn chỉ được tăng lên khi nhận ACK và các giai đoạn khởi
động chậm và phục hồi nhanh vẫn như cũ. CUBIC chỉ thay đổi giai
đoạn tránh tắc nghẽn, như sau:
✓ Đặt Wmax là kích thước của cửa sổ kiểm sốt tắc nghẽn của TCP
khi mất mát được phát hiện lần cuối và đặt K là thời điểm trong
tương lai khi kích thước cửa sổ của TCP CUBIC sẽ lại đạt đến
Wmax, giả sử khơng có tổn thất nào. Một số tham số CUBIC có
11


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

thể điều chỉnh xác định giá trị K, nghĩa là, kích thước cửa sổ tắc
nghẽn của giao thức sẽ đạt đến Wmax nhanh như thế nào.

✓ CUBIC làm tăng cửa sổ tắc nghẽn như một hàm lập phương của
khoảng cách giữa thời điểm hiện tại, t và K. Do đó, khi t càng xa
K, kích thước cửa sổ tắc nghẽn tăng lớn hơn nhiều so với khi t
gần K. Điều đó là, CUBIC nhanh chóng tăng tốc độ gửi của TCP
để đạt gần với tốc độ trước khi mất, Wmax, và chỉ sau đó thăm dị
một cách thận trọng băng thơng khi nó tiến gần đến Wmax.
✓ Khi t lớn hơn K, quy tắc khối hàm ý rằng cửa sổ tắc nghẽn của
CUBIC tăng nhỏ khi t vẫn gần K (tốt nếu mức tắc nghẽn của liên
kết gây ra tổn thất không thay đổi nhiều) nhưng sau đó tăng nhanh
khi t vượt q K (cho phép CUBIC nhanh chóng tìm được điểm
hoạt động mới nếu mức độ tắc nghẽn của liên kết gây ra mất mát
đã thay đổi đáng kể). Theo các quy tắc này, hiệu suất lý tưởng hóa
của TCP Reno và TCP CUBIC được so sánh trong Hình 5.
• Chúng ta thấy giai đoạn bắt đầu chậm kết thúc ở t0. Sau đó, khi mất
tắc nghẽn xảy ra ở t1, t2 và t3, CUBIC nhanh chóng tăng lên gần với
Wmax (do đó tận hưởng thơng lượng tổng thể nhiều hơn TCP Reno).
Chúng ta có thể thấy bằng đồ thị cách TCP CUBIC cố gắng duy trì
luồng càng lâu càng tốt ngay dưới ngưỡng tắc nghẽn (không xác định
đối với người gửi). Lưu ý rằng ở t 3, mức tắc nghẽn có lẽ đã giảm
đáng kể, cho phép cả TCP Reno và TCP CUBIC đạt được tốc độ gửi
cao hơn Wmax.

Hình 5: Tốc độ gửi tránh tắc nghẽn TCP: TCP Reno và TCP
CUBIC

12


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

❖ Mơ tả macro của thơng lượng TCP Reno
• Với TCP Reno, điều tự nhiên là phải xem xét thông lượng trung bình
(nghĩa là tốc độ trung bình) của một kết nối TCP Reno tồn tại lâu dài
có thể là bao nhiêu. Trong phân tích này, chúng tơi sẽ bỏ qua các giai
đoạn bắt đầu chậm xảy ra sau các sự kiện hết thời gian chờ. (Các giai
đoạn này thường rất ngắn, vì người gửi phát triển ra khỏi giai đoạn
nhanh theo cấp số nhân.) Trong một khoảng thời gian khứ hồi cụ thể,
tốc độ TCP gửi dữ liệu là một hàm của cửa sổ tắc nghẽn và RTT hiện
tại. Khi kích thước cửa sổ là w byte và thời gian khứ hồi hiện tại là
RTT giây, thì tốc độ truyền của TCP là khoảng w / RTT. TCP sau đó
thăm dị băng thông bổ sung bằng cách tăng w 1 MSS mỗi RTT cho
đến khi xảy ra sự kiện mất mát. Ký hiệu bằng W giá trị của w khi xảy
ra sự kiện mất mát. Giả sử rằng RTT và W gần như không đổi trong
suốt thời gian kết nối, tốc độ truyền TCP nằm trong khoảng từ W / (2
· RTT) đến W / RTT.
• Những giả định này dẫn đến một mơ hình vĩ mơ được đơn giản hóa
cao cho hành vi ổn định của TCP. Mạng bỏ một gói tin khỏi kết nối
khi tốc độ tăng lên W / RTT; Sau đó, tốc độ bị cắt đi một nửa và sau
đó tăng MSS / RTT mỗi RTT cho đến khi đạt W / RTT một lần nữa.
Quá trình này lặp đi lặp lại nhiều lần. Vì thơng lượng của TCP (nghĩa
là tốc độ) tăng tuyến tính giữa hai giá trị cực, ta có:
Thơng lượng trung bình của một kết nối = (0.75*W)/RTT
2. Thông báo tắc nghẽn rõ ràng do mạng hỗ trợ và kiểm soát tắc nghẽn
dựa trên độ trễ
Kể từ khi tiêu chuẩn hóa ban đầu về khởi động chậm và tránh tắc nghẽn vào
cuối những năm 1980 [RFC 1122], TCP đã triển khai hình thức kiểm sốt tắc
nghẽn đầu cuối: người gửi TCP khơng nhận được chỉ báo tắc nghẽn rõ ràng
nào từ mạng và thay vào đó, gây ra tắc nghẽn thơng qua việc mất gói được

quan sát. Gần đây hơn, các phần mở rộng cho cả IP và TCP [RFC 3168] đã
được đề xuất, thực hiện và triển khai cho phép mạng báo hiệu rõ ràng sự tắc
nghẽn cho người gửi và người nhận TCP. Ngoài ra, một số biến thể của giao
thức kiểm soát tắc nghẽn TCP đã được đề xuất để suy ra tắc nghẽn bằng cách
13


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

sử dụng độ trễ gói được đo. Chúng ta sẽ xem xét cả kiểm soát tắc nghẽn do
mạng hỗ trợ và dựa trên độ trễ trong phần này.

❖ Thông báo tắc nghẽn cụ thể
Thông báo tắc nghẽn rõ ràng [RFC 3168] là hình thức kiểm sốt tắc nghẽn
do mạng hỗ trợ được thực hiện trong Internet. Như trong Hình 6, cả TCP
và IP đều có liên quan. Ở lớp mạng, hai bit (với bốn giá trị có thể, tổng thể)
trong trường Loại dịch vụ của tiêu đề sơ đồ IP được sử dụng cho ECN.

Hình 6: Thơng báo tắc nghẽn rõ ràng: kiểm soát tắc nghẽn do mạng hỗ trợ

Một cài đặt của các bit ECN được bộ định tuyến sử dụng để chỉ ra rằng bộ
định tuyến đang gặp sự cố tắc nghẽn. Dấu hiệu tắc nghẽn này sau đó được
thực hiện trong IP datagram tới máy chủ đích, sau đó thơng báo cho máy
chủ gửi, như trong Hình 6. RFC 3168 không cung cấp định nghĩa về thời
điểm bộ định tuyến bị tắc nghẽn; quyết định đó là lựa chọn cấu hình do nhà
cung cấp bộ định tuyến thực hiện và do nhà khai thác mạng quyết định. Tuy
nhiên, trực giác là bit chỉ báo tắc nghẽn có thể được thiết lập để báo hiệu
sự khởi đầu của tắc nghẽn đối với quá trình gửi trước khi sự mất mát thực

sự xảy ra. Thiết lập thứ hai của các bit ECN được sử dụng bởi máy chủ gửi
để thông báo cho các bộ định tuyến rằng người gửi và người nhận có khả
năng ECN và do đó có khả năng thực hiện hành động để đáp ứng với tắc
nghẽn mạng do ECN chỉ định.

14


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

Trong Hình 6, khi TCP trong máy chủ nhận nhận được chỉ báo tắc nghẽn
ECN thông qua sơ đồ dữ liệu đã nhận, TCP trong máy chủ nhận sẽ thông
báo TCP trong máy chủ gửi chỉ báo tắc nghẽn bằng cách đặt bit ECE (Tiếng
vọng thông báo tắc nghẽn rõ ràng) (xem Hình 3.29) trong phân đoạn TCP
ACK từ người nhận đến người gửi. Đến lượt người gửi TCP phản ứng với
ACK có chỉ báo tắc nghẽn bằng cách giảm một nửa cửa sổ tắc nghẽn, vì nó
sẽ phản ứng với một phân đoạn bị mất bằng cách sử dụng truyền lại nhanh
và đặt bit CWR (Cửa sổ tắc nghẽn giảm) trong tiêu đề của lần truyền tiếp
theo Phân đoạn người gửi đến người nhận TCP.
Các giao thức lớp truyền tải khác ngồi TCP cũng có thể sử dụng ECN
được báo hiệu lớp mạng. Giao thức kiểm soát tắc nghẽn Datagram (DCCP)
[RFC 4340] cung cấp dịch vụ không đáng tin cậy giống như UDP được
kiểm sốt tắc nghẽn, chi phí thấp sử dụng ECN. DCTCP (Trung tâm dữ liệu
TCP) [Alizadeh 2010, RFC 8257] và DCQCN (Thơng báo tắc nghẽn lượng
tử hóa của Trung tâm dữ liệu) [Zhu 2015] được thiết kế đặc biệt cho mạng
trung tâm dữ liệu, cũng sử dụng ECN. Các phép đo Internet gần đây cho
thấy việc triển khai các khả năng ECN ngày càng tăng trong các máy chủ
phổ biến cũng như trong các bộ định tuyến dọc theo đường dẫn đến các

máy chủ đó [Kühlewind 2013].
❖ Kiểm soát tắc nghẽn dựa trên độ trễ
Một bộ định tuyến bị tắc nghẽn có thể đặt bit chỉ báo tắc nghẽn để báo hiệu
sự cố tắc nghẽn bắt đầu cho người gửi trước khi bộ đệm đầy khiến các gói
bị rơi tại bộ định tuyến đó. Điều này cho phép người gửi giảm tốc độ gửi
của họ sớm hơn, hy vọng trước khi mất gói, do đó tránh mất gói và truyền
lại tốn kém. Cách tiếp cận tránh tắc nghẽn thứ hai áp dụng cách tiếp cận
dựa trên độ trễ để cũng chủ động phát hiện sự khởi đầu tắc nghẽn trước khi
xảy ra mất gói.
• Trong TCP Vegas [Brakmo 1995], người gửi đo lường RTT của
đường dẫn đến nguồn đích cho tất cả các gói được thừa nhận. Gọi
RTTmin là giá trị tối thiểu của các phép đo này ở người gửi; điều này
xảy ra khi đường dẫn không bị chặn và các gói gặp phải độ trễ xếp
hàng tối thiểu. Nếu kích thước cửa sổ tắc nghẽn của TCP Vegas là
cwnd,thì tốc độ thơng lượng chưa được kiểm tra sẽ là cwnd / RTTmin.
Trực giác đằng sau TCP Vegas là nếu thông lượng thực tế do người
gửi đo gần với giá trị này, tốc độ gửi TCP có thể được tăng lên vì
(theo định nghĩa và theo phép đo) đường dẫn chưa bị tắc nghẽn. Tuy
nhiên, nếu thông lượng thực tế do người gửi đo nhỏ hơn đáng kể so
15


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

với tốc độ thông lượng không bị tắc nghẽn, đường dẫn sẽ bị tắc nghẽn
và người gửi Vegas TCP sẽ giảm tốc độ gửi. Thơng tin chi tiết có thể
được tìm thấy trong [Brakmo 1995].
• TCP Vegas hoạt động theo trực giác rằng người gửi TCP có nghĩa là

các liên kết (đặc biệt là liên kết tắc nghẽn đang hạn chế thông lượng
của kết nối) luôn bận rộn trong việc truyền tải, thực hiện cơng việc
hữu ích.
• Xem thêm: Giao thức kiểm soát tắc nghẽn BBR [Cardwell 2017]
được xây dựng dựa trên các ý tưởng trong TCP Vegas và kết hợp các
cơ chế cho phép nó cạnh tranh cơng bằng với những người gửi TCP
không phải BBR. [Cardwell 2017] báo cáo rằng vào năm 2016,
Google đã bắt đầu sử dụng BBR cho tất cả lưu lượng TCP trên mạng
B4 riêng của mình [Jain 2013] kết nối các trung tâm dữ liệu của
Google, thay thế CUBIC. Nó cũng đang được triển khai trên các máy
chủ Web của Google và YouTube. Các giao thức kiểm soát tắc nghẽn
TCP dựa trên độ trễ khác bao gồm TIMELY cho mạng trung tâm dữ
liệu [Mittal 2015], và Compound TCP (CTPC) [Tan 2006] và FAST
[Wei 2006] cho mạng tốc độ cao và đường dài.
3. Kiểm soát một cách tin cậy
Hãy xem xét K kết nối TCP, mỗi kết nối có một đường dẫn end-to-end khác
nhau, nhưng tất cả đều đi qua một liên kết nút cổ chai với tốc độ truyền R bps.
(Theo liên kết nút cổ chai, chúng tơi muốn nói rằng đối với mỗi kết nối, tất cả
các liên kết khác dọc theo đường dẫn của kết nối khơng bị tắc nghẽn và có khả
năng truyền tải dồi dào so với khả năng truyền tải của liên kết nút cổ chai.) Giả
sử mỗi kết nối đang truyền một tệp lớn và ở đó là khơng có lưu lượng UDP đi
qua liên kết nút cổ chai. Một cơ chế kiểm sốt tắc nghẽn được cho là cơng bằng
nếu tốc độ truyền trung bình của mỗi kết nối xấp xỉ R / K; nghĩa là, mỗi kết
nối nhận được một phần băng thơng liên kết bằng nhau.
Thuật tốn AIMD của TCP có tin cậy khơng, đặc biệt khi các kết nối TCP khác
nhau có thể bắt đầu vào các thời điểm khác nhau và do đó có thể có các kích
thước cửa sổ khác nhau tại một thời điểm nhất định? [Chiu 1989] cung cấp
một lời giải thích trực quan về lý do tại sao kiểm soát tắc nghẽn TCP hội tụ để
cung cấp một phần băng thông của liên kết nút cổ chai như nhau giữa các kết
nối TCP cạnh tranh.

16


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

Chúng ta hãy xem xét trường hợp đơn giản của hai kết nối TCP chia sẻ một
liên kết duy nhất với tốc độ truyền R, như thể hiện trong Hình 6. Giả sử rằng
hai kết nối có cùng MSS và RTT (để nếu chúng có cùng kích thước cửa sổ tắc
nghẽn, thì chúng có cùng thơng lượng), tức là chúng có một lượng lớn dữ liệu
để gửi, và khơng có kết nối TCP hoặc sơ đồ dữ liệu UDP nào khác đi qua liên
kết được chia sẻ này. Ngoài ra, hãy bỏ qua giai đoạn khởi động chậm của TCP
và giả sử các kết nối TCP đang hoạt động chế độ CA (AIMD) mọi lúc.

Hình 7: Hai kết nối TCP chia sẻ một liên kết tắc nghẽn duy nhất

Hình 7 vẽ biểu đồ thông lượng được thực hiện bởi hai kết nối TCP. Nếu TCP
chia sẻ băng thông liên kết như nhau giữa hai kết nối, thì thơng lượng nhận ra
sẽ nằm dọc theo mũi tên 45 độ (chia sẻ băng thông bằng nhau) xuất phát từ
điểm gốc. Lý tưởng nhất, tổng của hai thông lượng phải bằng R. (Chắc chắn,
mỗi kết nối nhận được một phần chia sẻ dung lượng liên kết bằng nhau, nhưng
bằng khơng, khơng phải là một tình huống mong muốn!) Vì vậy, mục tiêu phải
là để thơng lượng đạt được rơi vào đâu đó gần Giao điểm của đường chia sẻ
băng thông bằng nhau và đường sử dụng băng thơng đầy đủ trong Hình 7.
Giả sử rằng các kích thước cửa sổ TCP sao cho tại một thời điểm nhất định,
các kết nối 1 và 2 nhận ra thông lượng được chỉ ra bởi điểm A trong Hình 7.
Vì lượng băng thơng liên kết được tiêu thụ chung bởi hai kết nối nhỏ hơn R
nên sẽ không xảy ra mất mát và cả hai kết nối sẽ tăng cửa sổ của chúng thêm

1 MSS trên mỗi RTT do thuật tốn tránh tắc nghẽn của TCP.
➢ Do đó, thông lượng chung của hai kết nối tiến hành dọc theo một đường
45 độ (tăng bằng nhau cho cả hai kết nối) bắt đầu từ điểm A. Cuối cùng,
băng thông liên kết được sử dụng chung bởi hai kết nối sẽ lớn hơn R, và
cuối cùng là gói mất mát sẽ xảy ra. Giả sử rằng các kết nối 1 và 2 bị mất
gói khi chúng nhận ra thơng lượng được chỉ ra bởi điểm B. Các kết nối
1 và 2 sau đó giảm cửa sổ của chúng đi một phần hai.
17


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

➢ Do đó, thơng lượng kết quả được nhận ra là tại điểm C, nằm giữa một
vectơ bắt đầu từ B và kết thúc tại điểm gốc. Bởi vì việc sử dụng băng
thông chung nhỏ hơn R tại điểm C, hai kết nối lại tăng thông lượng của
chúng dọc theo đường 45 độ bắt đầu từ C. Cuối cùng, mất mát sẽ lại xảy
ra.
ví dụ: tại điểm D và hai kết nối lại giảm kích thước cửa sổ của họ theo
hệ số hai, v.v. Bạn nên thuyết phục bản thân rằng băng thông được nhận
ra bởi hai kết nối cuối cùng dao động dọc theo đường chia sẻ băng thông
bằng nhau. Bạn cũng nên thuyết phục bản thân rằng hai kết nối sẽ hội tụ
thành hành vi này bất kể chúng ở đâu trong không gian hai chiều! Mặc
dù một số giả định lý tưởng hóa nằm sau kịch bản này, nhưng nó vẫn
mang lại cảm giác trực quan về lý do tại sao TCP dẫn đến việc chia sẻ
băng thông như nhau giữa các kết nối.

Hình 8: Thơng lượng được thực hiện bởi các kết nối TCP 1 và 2

Trong kịch bản lý tưởng hóa, giả định rằng chỉ các kết nối TCP đi qua
liên kết nút cổ chai, rằng các kết nối có cùng giá trị RTT và chỉ một kết
nối TCP duy nhất được liên kết với một cặp máy chủ-đích.
Trong thực tế, các điều kiện này thường khơng được đáp ứng, và các
ứng dụng máy khách-máy chủ do đó có thể nhận được các phần băng
thơng liên kết rất khơng bằng nhau. Đặc biệt, nó đã được chứng minh
rằng khi nhiều kết nối chia sẻ một nút cổ chai chung, những phiên có
18


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

RTT nhỏ hơn có thể lấy băng thơng có sẵn tại liên kết đó nhanh hơn khi
nó trở nên miễn phí (nghĩa là mở cửa sổ tắc nghẽn của chúng nhanh hơn)
và do đó sẽ có thơng lượng cao hơn những kết nối có RTT lớn hơn.
❖ Kiểm sốt qua giao thức UDP
Chúng ta thấy cách kiểm soát tắc nghẽn TCP điều chỉnh tốc độ truyền của
ứng dụng thông qua cơ chế cửa sổ tắc nghẽn. Nhiều ứng dụng đa phương
tiện, chẳng hạn như điện thoại Internet và hội nghị truyền hình, thường
khơng chạy qua TCP vì lý do họ khơng muốn tốc độ truyền của mình bị
hạn chế, ngay cả khi mạng rất tắc nghẽn. Thay vào đó, các ứng dụng này
thích chạy qua UDP, khơng có tính năng kiểm sốt tắc nghẽn tích hợp. Khi
chạy qua UDP, các ứng dụng có thể bơm âm thanh và video của chúng vào
mạng với tốc độ không đổi và đôi khi bị mất gói, thay vì giảm tốc độ của
chúng xuống mức “hợp lý” tại thời điểm tắc nghẽn và không bị mất bất kỳ
gói nào.
Từ quan điểm của TCP, các ứng dụng đa phương tiện chạy trên UDP không
tin cậy, chúng không hợp tác với các kết nối khác cũng như điều chỉnh tốc

độ truyền của chúng một cách thích hợp. Bởi vì kiểm sốt tắc nghẽn TCP
sẽ làm giảm tốc độ truyền của nó khi đối mặt với tình trạng tắc nghẽn ngày
càng tăng (mất mát), trong khi các nguồn UDP thì khơng cần, các nguồn
UDP có thể lấn át lưu lượng TCP. Một số cơ chế kiểm soát tắc nghẽn đã
được đề xuất cho Internet để ngăn lưu lượng UDP đưa thơng lượng của
Internet bị đình trệ [Floyd 1999; Floyd 2000; Kohler năm 2006; RFC 4340].
❖ Kết nối TCP tin cậy
Nhưng ngay cả khi chúng ta có thể buộc lưu lượng UDP hoạt động tin cậy,
vấn đề tin cậy vẫn sẽ khơng được giải quyết hồn tồn. Điều này là do
khơng có gì ngăn ứng dụng dựa trên TCP sử dụng nhiều kết nối song song.
Ví dụ: các trình duyệt Web thường sử dụng nhiều kết nối TCP song song
để chuyển nhiều đối tượng trong một trang Web. (Số lượng chính xác của
nhiều kết nối có thể được định cấu hình trong hầu hết các trình duyệt). Khi
một ứng dụng sử dụng nhiều kết nối song song, nó sẽ nhận được một phần
lớn hơn của băng thông trong một liên kết bị tắc nghẽn.
Chúng ta hãy xem xét một liên kết có tốc độ R hỗ trợ chín ứng dụng máy
khách-máy chủ đang diễn ra, với mỗi ứng dụng sử dụng một kết nối TCP.
Nếu một ứng dụng mới xuất hiện và cũng sử dụng một kết nối TCP, thì mỗi
19


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

ứng dụng sẽ có tốc độ truyền gần như nhau là R/10. Nhưng nếu ứng dụng
mới này thay vào đó sử dụng 11 kết nối TCP song song, thì ứng dụng mới
sẽ bị phân bổ không tin cậy nhiều hơn R / 2. Bởi vì lưu lượng truy cập Web
rất phổ biến trên Internet, nhiều kết nối song song không phải là hiếm.

20


Nhóm 12

Điều khiển tắc nghẽn cho giao thức TCP

Kết luận
Sau khi tìm hiểu chúng ta đã biết hoạt đơng của kiểm sốt tắc nghẽn TCP.
Vai trị của nó trong việc truyền thơng là rất quan trọng. Nó kiểm sốt lưu
lượng truyền và tránh mất mát , độ uy tín cao.

Tài liệu tham khảo:
1. James F. Kurose/Keith W.ross- Computer Networking_ A Top-Down
Approach-Pearson.
2. Hoang Trọng Minh-Bài giảng báo hiệu và điều khiển kết nối.

21