• 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?. • Cơ chế kiểm soát tắc nghẽn TCP hoạt động ở người gửi theo dõi
Trang 1HỌ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: Hoàng Trọng Minh
Thành viên: Đào Đình Đoàn–B18DCVT101
Nguyễn Hải Hưng-B18DCVT213
Phạm Văn Thao-B18DCVT405
Hà Nội, Tháng 10/2021
Trang 2Lờ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 soá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 soá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
Trang 3Mụ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 soá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 soá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 soá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
Trang 4Đ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 soá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 soát tắc nghẽn đầu cuối thay vì tắc nghẽn do mạng hỗ trợ kiểm soá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?
Trang 5• 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 soá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
• 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
Trang 6mộ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
Trang 7hiể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 soá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 toán kiểm soát tắc nghẽn TCP Thuật toá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
Trang 8❖ 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
Trang 9• 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 soá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
Trang 10• 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 soá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 toá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
Trang 11❖ 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
• 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 đó
