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ư biết truyền thơng liệu qua mạng việc kiểm sốt lưu lượng truyền quan trọng Nó định đến việc truyền cách tin cậy từ nguồn đến đích khơng Vì tìm hiểu 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 báo cáo Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP Mục lục: Kiểm soát tắc nghẽn TCP cổ điển ………………………………………… - Khởi động chậm ( Slow Start)……………………………………………6 Tránh tắc nghẽn( Congestion Avoidance)……………………………….7 Khơi phục nhanh( Fast Recovery)……………………………………… Kiểm sốt tắc nghẽn TCP: Retrospective……………………………… 10 TCP Cubic…………………………………………………………………11 Mô tả macro Thông lượng TCP Reno………………………………13 Thông báo tắc nghẽn rõ ràng mạng hỗ trợ kiểm soát tắc nghẽn dựa độ 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ễ( Delay Based)…………………….15 Kiểm soá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 ……………………………………… Hình 2: Mơ tả FSM kiểm sốt tắc nghẽn TCP…………………… Hình 3: Sự phát triển cửa sổ tắc nghẽn TCP……………… 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 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 mạng hỗ trợ…………………………………………………… 14 ▪ Hình 7: Hai kết nối TCP chia sẻ liên kết tắc nghẽn nhất……17 ▪ Hình 8: Thơng lượng thực kết nối TCP 2… 18 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ư biết TCP cung cấp dịch vụ truyền tải đáng tin cậy hai tiến trình chạy máy chủ khác Một thành phần quan trọng khác TCP chế kiểm sốt tắc nghẽn Theo tìm hiểu trước đây, gọi TCP “Cổ điển” — phiên TCP chuẩn hóa [RFC 2581] gần [RFC 5681] —sử dụng kiểm soát tắc nghẽn đầu cuối thay tắc nghẽn mạng hỗ trợ kiểm sốt, lớp IP khơng cung cấp phản hồi rõ ràng cho hệ thống đầu cuối tắc nghẽn mạng Đầu tiên trình bày sâu phiên TCP “cổ điển” Phần Trong Phần 2, sau xem xét phiên TCP sử dụng báo tắc nghẽn rõ ràng lớp mạng cung cấp khác chút với TCP “cổ điển” theo cách số cách khác Sau đó, chúng tơi đề cập đến thách thức cung cấp công luồng vận chuyển phải chia sẻ liên kết bị tắc nghẽn Kiểm soát tắc nghẽn TCP cổ điển Phương pháp TCP thực yêu cầu 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 chức tắc nghẽn mạng Trong qua trình trao đổi liệu: • Nếu người gửi TCP nhận thấy có tắc nghẽn đường dẫn đích, người gửi TCP tăng tốc độ gửi • Nếu người gửi nhận thấy có tắc nghẽn dọc theo đường dẫn, người gửi giảm tốc độ gửi ➢ Nhưng cách tiếp cận đặt ba câu hỏi: • Đầu tiên, làm để người gửi TCP giới hạn tốc độ mà gửi lưu lượng truy cập vào kết nối mình? • Thứ hai, làm để người gửi TCP nhận thấy có tắc nghẽn đường dẫn đích? 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 để thay đổi tốc độ gửi hàm tắc nghẽn đầu cuối nhận thức? Trước tiên, 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 • Chúng ta thấy bên kết nối TCP bao gồm: đệm nhận, đệm gửi 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 biến bổ sung, “cửa sổ tắc nghẽn” Cửa sổ tắc nghẽn, ký hiệu cwnd, áp đặt hạn chế tốc độ mà người gửi TCP gửi lưu lượng truy cập vào mạng lưới Cụ thể, số lượng liệu chưa xác nhận người gửi không vượt mức tối thiểu cwnd rwnd, nghĩa là: Thời gian byte cuối gửi trừ thời gian byte cuối kiểm tra “phải nhỏ bằng” giá trị nhỏ 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), đó, giả sử đệm nhận TCP lớn nên bỏ qua ràng buộc cửa sổ nhận; đó, số lượng liệu chưa xác nhận người gửi bị giới hạn cwnd Chúng giả định người gửi ln có liệu để gửi, tức tất phân đoạn cửa sổ tắc nghẽn gửi • Ràng buộc giới hạn số lượng liệu chưa xác nhận người gửi gián tiếp giới hạn tốc độ gửi người gửi Để thấy điều này, xem xét kết nối mà mát độ trễ truyền gói khơng đáng kể Sau đó, đại khái, đầu RTT, ràng buộc cho phép người gửi gửi cwnd byte liệu vào kết nối; vào cuối RTT, người gửi nhận thông báo xác nhận cho liệu Do đó, tốc độ gửi người gửi khoảng cwnd / RTT byte / giây Bằng cách điều chỉnh giá trị cwnd, đó, người gửi điều chỉnh tốc độ gửi liệu vào kết nối • Tiếp theo, xem xét cách người gửi TCP nhận thấy có tắc nghẽn đường dẫn đích Hãy để chúng tơi xác định "sự kiện mát" người gửi TCP xuất thời gian chờ nhận ba ACK trùng lặp từ người nhận Khi có tắc nghẽn mức, (hoặc nhiều) đệm định tuyến dọc theo đường dẫn tràn, gây Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP datagram (chứa đoạn TCP) bị loại bỏ Khi datagram bị rớt lại dẫn đến kiện liệu người gửi — hết thời gian chờ nhận ba ACK trùng lặp — người gửi coi dấu hiệu tắc nghẽn đường dẫn người gửi đến người nhận • Sau xem xét cách phát tắc nghẽn, xem xét trường hợp mạng tắc nghẽn, nghĩa kiện mạng không xảy Trong trường hợp này, xác nhận cho phân đoạn chưa xác nhận trước nhận người gửi TCP ✓ Như thấy, TCP đưa xác nhận dấu hiệu cho thấy tất ổn - phân đoạn truyền vào mạng phân phối thành cơng đến đích - sử dụng xác nhận để tăng kích thước cửa sổ tắc nghẽn (và tốc độ truyền nó) ✓ Lưu ý xác nhận đến với tốc độ tương đối chậm (ví dụ: đường dẫn đầu cuối có độ trễ cao chứa liên kết băng thơng thấp), cửa sổ tắc nghẽn tăng lên với tốc độ tương đối chậm Mặt khác, xác nhận đến với tốc độ cao, cửa sổ tắc nghẽn nhanh chóng tăng lên Bởi TCP sử dụng xác nhận để kích hoạt (hoặc đồng hồ) gia tăng kích thước cửa sổ tắc nghẽn nó, TCP cho có khả tự xung nhịp • Với chế điều chỉnh giá trị cwnd để kiểm soát tốc độ gửi, câu hỏi quan trọng là: Người gửi TCP nên xác định tốc độ nên gửi? Nếu người gửi TCP gửi chung nhanh, họ làm nghẽn mạng, dẫn đến kiểu sụp đổ tắc nghẽn Tuy nhiên, người gửi TCP thận trọng gửi chậm, họ sử dụng băng thơng mạng; nghĩa là, người gửi TCP gửi với tốc độ cao mà không làm nghẽn mạng Sau đó, làm cách để người gửi TCP xác định tốc độ gửi họ để họ không làm nghẽn mạng đồng thời tận dụng tất băng thơng có sẵn? Người gửi TCP có phối hợp cách rõ ràng hay có cách tiếp cận phân tán người gửi TCP đặt tốc độ gửi họ dựa thông tin cục bộ? TCP trả lời câu hỏi cách sử dụng nguyên tắc hướng dẫn sau: ✓ Một phân đoạn bị có nghĩa tắc nghẽn đó, tốc độ người gửi TCP giảm phân đoạn bị Nếu kiện hết thời gian chờ việc nhận bốn xác nhận cho phân đoạn định (một ACK gốc sau ba ACK trùng lặp) Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP hiểu dấu hiệu ngầm định "sự kiện mát" 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ị Từ quan điểm kiểm soát tắc nghẽn, câu hỏi đặt làm người gửi TCP nên giảm kích thước cửa sổ tắc nghẽn, tốc độ gửi nó, để đáp ứng với kiện mát suy luận ✓ Một phân đoạn xác nhận cho biết mạng phân phối phân đoạn người gửi đến người nhận đó, tỷ lệ người gửi tăng lên ACK đến cho phân đoạn chưa xác nhận trước Sự xuất xác nhận coi dấu hiệu ngầm tất tốt - phân đoạn chuyển thành công từ người gửi đến người nhận mạng khơng bị tắc nghẽn Do đó, kích thước cửa sổ tắc nghẽn tăng lên ✓ Thăm dị băng thơng Với ACK đường dẫn từ nguồn đến đích khơng bị tắc nghẽn kiện mát đường dẫn bị tắc nghẽn, chiến lược TCP để điều chỉnh tốc độ truyền tăng tốc độ để đáp ứng với ACK đến xảy kiện mất, tỷ lệ giảm xuống Do đó, người gửi TCP tăng tốc độ truyền để thăm dị tốc độ bắt đầu tắc nghẽn, lùi lại từ tốc độ đó, 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 người gửi TCP có lẽ tương tự đứa trẻ yêu cầu (và nhận) ngày nhiều quà tặng cuối đứa trẻ thông báo “Không!”, Lùi lại chút, sau bắt đầu thực lại yêu cầu sau ➢ Lưu ý mạng khơng có báo hiệu rõ ràng trạng thái tắc nghẽn — ACK kiện mát đóng vai trị tín hiệu ngầm định — TCP người gửi hành động thông tin cục cách không đồng từ người gửi TCP khác Với tổng quan kiểm soát tắc nghẽn TCP, chúng tơi xem xét chi tiết 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 (3) khôi phục nhanh Khởi động chậm tránh tắc nghẽn thành phần bắt buộc TCP, khác cách chúng tăng kích thước cwnd để đáp ứng với ACK nhận Khôi phục nhanh khuyến nghị, không bắt buộc, người gửi TCP 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ị cwnd thường khởi tạo thành giá trị nhỏ MSS [RFC 3390], dẫn đến tốc độ gửi ban đầu khoảng MSS /RTT Ví dụ: MSS = 500 byte RTT = 200 msec, tốc độ gửi ban đầu kết khoảng 20 kbps Vì băng thơng khả dụng cho người gửi TCP lớ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 cách nhanh chóng Do đó, trạng thái khởi động chậm, giá trị cwnd MSS tăng MSS đoạn truyền ghi nhận lần Hình 1: Khởi động chậm TCP Ta thấy Hình 1, TCP gửi phân đoạn vào mạng chờ xác nhận Khi xác nhận đến, người gửi TCP tăng cửa sổ tắc nghẽn lên MSS gửi hai phân đoạn có kích thước tối đa Các phân đoạn sau xác nhận, với người gửi tăng cửa sổ tắc nghẽn lên MSS cho phân đoạn xác nhận, đưa cửa sổ tắc nghẽn MSS, v.v Q trình dẫn đến việc tăng gấp đơi tốc độ gửi RTT Do đó, tốc độ gửi TCP bắt đầu chậm tăng theo cấp số nhân giai đoạn bắt đầu chậm Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP • Nhưng tăng trưởng theo cấp số nhân kết thúc? Bắt đầu chậm cung cấp số câu trả lời cho câu hỏi ✓ Đầu tiên, có kiện mát (tức tắc nghẽn) thời gian chờ, người gửi TCP đặt giá trị cwnd thành bắt đầu lại trình khởi động chậm Nó đặt giá trị biến trạng thái thứ hai, ssthresh (viết tắt “ngưỡng khởi động chậm”) thành cwnd / — nửa giá trị tắc nghẽn giá trị cửa sổ phát tắc nghẽn ✓ Cách thứ hai bắt đầu chậm kết thúc gắn trực tiếp với giá trị ssthresh Vì ssthresh nửa giá trị cwnd lần cuối phát tắc nghẽn, nên liều lĩnh tiếp tục nhân đơi cwnd đạt đến vượt qua giá trị ssthresh Do đó, giá trị cwnd ssthresh, khởi động chậm kết thúc TCP chuyển sang chế độ tránh tắc nghẽn ✓ Chúng ta thấy, TCP tăng cwnd cách thận trọng chế độ tránh tắc nghẽn Cách cuối khởi động chậm kết thúc phát ba ACK trùng lặp, trường hợp TCP thực truyền lại nhanh chuyển sang trạng thái khôi phục nhanh, thảo luận bên Hành vi TCP khởi động chậm tóm tắt mơ tả FSM kiểm sốt tắc nghẽn TCP 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ị cwnd xấp xỉ nửa giá trị lần cuối gặp phải tắc nghẽn — tắc nghẽn gần đến! Do đó, thay tăng gấp đôi giá trị cwnd RTT, TCP áp dụng cách tiếp cận thận trọng tăng giá trị cwnd MSS RTT [RFC 5681] Điều thực theo số cách Một cách tiếp cận phổ biến người gửi TCP tăng cwnd theo byte MSS (MSS / cwnd) xác nhận đến Ví dụ: MSS 1.460 byte cwnd 14.600 byte, 10 phân đoạn gửi RTT Mỗi ACK đến (giả sử ACK đoạn) làm tăng kích thước cửa sổ tắc nghẽn lên 1/10 MSS đó, giá trị cửa sổ tắc nghẽn tăng thêm MSS sau ACK tất 10 phân đoạn nhận Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP • Nhưng gia tăng tuyến tính tính tránh tắc nghẽn (1 MSS RTT) nên kết thúc? Thuật toán tránh tắc nghẽn TCP hoạt động tương tự hết thời gian chờ xảy trường hợp khởi động chậm: Giá trị cwnd đặt thành MSS giá trị ssthresh cập nhật thành nửa giá trị cwnd kiện mát xảy Tuy nhiên, nhớ lại kiện thua lỗ kích hoạt kiện ACK trùng lặp ba lần Hình 2: Mơ tả FSM kiểm sốt tắc nghẽn TCP • Trong trường hợp này, mạng tiếp tục phân phối số phân đoạn từ người gửi đến người nhận (như việc nhận ACK trùng lặp) Vì vậy, hành vi TCP loại kiện mát nghiêm trọng so với tổn thất định thời gian chờ: TCP giảm nửa giá trị cwnd (thêm vào MSS để tính tốn cho ba ACK trùng lặp nhận được) ghi lại giá trị ssthresh nửa giá trị cwnd nhận ba ACK trùng lặp Trạng thái phục hồi nhanh sau nhập 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ị cwnd tăng thêm MSS cho ACK trùng lặp nhận cho phân đoạn bị thiếu khiến TCP vào trạng thái khôi phục nhanh Cuối cùng, ACK đến cho phân đoạn bị thiếu, TCP vào trạng thái tránh tắc nghẽn sau xả bớt cwnd Nếu kiện hết thời gian xảy ra, khôi phục nhanh chuyển sang trạng thái khởi động chậm sau thực hành động tương tự khởi động chậm tránh tắc nghẽn: Giá trị cwnd đặt thành MSS giá trị ssthresh đặt thành nửa giá trị cwnd kiện mát xảy Hình 3: Sự phát triển cửa sổ tắc nghẽn TCP (Tahoe Reno) • Khơi phục nhanh thành phần khuyến nghị, không bắt buộc TCP Điều thú vị phiên TCP, gọi TCP Tahoe, cắt vô điều kiện cửa sổ tắc nghẽn thành MSS bước vào giai đoạn khởi động chậm sau kiện ACK định thời gian chờ ba lần trùng lặp Phiên TCP, TCP Reno, tích hợp khả phục hồi nhanh • Hình minh họa phát triển cửa sổ tắc nghẽn TCP cho Reno Tahoe Trong hình này, ngưỡng ban đầu MSS Trong tám vòng truyền đầu tiên, Tahoe Reno thực hành động giống hệt Cửa sổ tắc nghẽn tăng nhanh theo cấp số nhân khởi động chậm chạm ngưỡng vòng truyền thứ tư Cửa sổ tắc nghẽn sau 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 kiện ACK trùng lặp ba lần xảy ra, sau vòng truyền Lưu ý cửa sổ tắc nghẽn 12 MSS kiện mát xảy Giá trị ssthresh sau đặt thành 0,5 cwnd = MSS Trong TCP Reno, cửa sổ tắc nghẽn đặt thành cwnd = MSS sau phát triển tuyến tính Trong TCP Tahoe, cửa sổ tắc nghẽn đặt thành MSS tăng theo cấp số nhân đạt đến giá trị ssthresh, thời điểm đó, phát triển tuyến tính • Hình trình bày mơ tả FSM đầy đủ thuật toán kiểm soát tắc nghẽn TCP — khởi động chậm, tránh tắc nghẽn khơi phục nhanh Hình nơi xảy việc truyền phân đoạn phân đoạn truyền lại Mặc dù điều quan trọng phải phân biệt kiểm soát lỗi / truyền lại TCP kiểm soát tắc nghẽn TCP, cần đánh giá cao cách hai khía cạnh TCP liên kết chặt chẽ với ❖ Kiểm sốt tắc nghẽn TCP: Retrospective • Sau sâu vào chi tiết khởi động chậm, tránh tắc nghẽn khôi phục nhanh Bỏ qua khoảng thời gian khởi động chậm ban đầu kết nối bắt đầu giả định tổn thất ba ACK trùng lặp thời gian chờ, kiểm soát tắc nghẽn TCP bao gồm tăng tuyến tính (cộng) cwnd MSS cho RTT sau giảm nửa (giảm số nhân) cwnd kiện ACK trùng lặp ba lần Vì lý này, kiểm sốt tắc nghẽn TCP thường gọi 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” hiển thị Hình 4, minh họa độc đáo trực giác trước việc “thăm dị” TCP băng thơng — TCP tăng tuyến tính kích thước cửa sổ tắc nghẽn (và tốc độ truyền nó) nhân đơi ba lần kiện ACK xảy Sau đó, giảm kích thước cửa sổ tắc nghẽn xuống hệ số hai 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 TCP phát triển dựa lượng lớn thông tin chi tiết kỹ thuật thử nghiệm kiểm soát tắc nghẽn mạng hoạt động Mười năm sau phát triển TCP, phân tích lý thuyết cho thấy thuật tốn kiểm sốt tắc nghẽn TCP đóng vai trị 10 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP thuật tốn tối ưu hóa khơng đồng phân tán, dẫn đến số khía cạnh quan trọng hiệu suất mạng người dùng tối ưu hóa đồng thời Từ đó, lý thuyết phong phú kiểm sốt tắc nghẽn 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 TCP Reno để kiểm soát tắc nghẽn, người ta tự hỏi liệu có phải cách tốt để “thăm dị” tốc độ gửi gói ngưỡng kích hoạt gói hay khơng Thật vậy, việc cắt giảm nửa tốc độ gửi (hoặc chí tệ hơn, cắt giảm tốc độ gửi xuống gói RTT phiên TCP trước gọi TCP Tahoe) sau tăng chậm theo thời gian thận trọng Nếu trạng thái liên kết bị tắc nghẽn nơi xảy gói khơng thay đổi nhiều, có lẽ tốt nên tăng tốc độ gửi nhanh để đạt gần với tốc độ gửi trước bị sau thăm dị băng thơng cách thận trọng gọi TCP CUBIC • TCP CUBIC khác chút so với TCP Reno Một lần nữa, cửa sổ tắc nghẽn tăng lên nhận ACK giai đoạn khởi động chậm phục hồi nhanh cũ CUBIC thay đổi giai đoạn tránh tắc nghẽn, sau: ✓ Đặt Wmax kích thước cửa sổ kiểm soát tắc nghẽn TCP mát phát lần cuối đặt K thời điểm tương lai kích thước cửa sổ TCP CUBIC lại đạt đến Wmax, giả sử khơng có tổn thất 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 giao thức đạt đến Wmax nhanh ✓ CUBIC làm tăng cửa sổ tắc nghẽn hàm lập phương khoảng cách thời điểm tại, t K Do đó, t xa K, kích thước cửa sổ tắc nghẽn tăng lớn nhiều so với t gần K Điều là, CUBIC nhanh chóng tăng tốc độ gửi TCP để đạt gần với tốc độ trước mất, Wmax, sau thăm dị cách thận trọng băng thơng tiến gần đến Wmax ✓ Khi t lớn K, quy tắc khối hàm ý cửa sổ tắc nghẽn CUBIC tăng nhỏ t gần K (tốt mức tắc nghẽn liên kết gây tổn thất khơng thay đổi nhiều) sau tăng nhanh t vượt q K (cho phép CUBIC nhanh chóng tìm điểm hoạt động mức độ tắc nghẽn liên kết gây mát thay đổi đáng kể) Theo quy tắc này, hiệu suất lý tưởng hóa TCP Reno TCP CUBIC so sánh Hình • Chúng ta thấy giai đoạn bắt đầu chậm kết thúc t0 Sau đó, tắc nghẽn xảy t1, t2 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 TCP Reno) Chúng ta thấy đồ thị cách TCP CUBIC cố gắng trì luồng lâu tốt ngưỡng tắc nghẽn (không xác định người gửi) Lưu ý t 3, mức tắc nghẽn có lẽ giảm đáng kể, cho phép TCP Reno TCP CUBIC đạt tốc độ gửi cao Wmax Hình 5: Tốc độ gửi tránh tắc nghẽn TCP: TCP Reno TCP CUBIC 12 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP ❖ Mô tả macro thơng lượng TCP Reno • Với TCP Reno, điều tự nhiên phải xem xét thông lượng trung bình (nghĩa tốc độ trung bình) kết nối TCP Reno tồn lâu dài Trong phân tích này, chúng tơi bỏ qua giai đoạn bắt đầu chậm xảy sau kiện hết thời gian chờ (Các giai đoạn thường ngắn, người gửi phát triển khỏi giai đoạn nhanh theo cấp số nhân.) Trong khoảng thời gian cụ thể, tốc độ TCP gửi liệu hàm cửa sổ tắc nghẽn RTT Khi kích thước cửa sổ w byte thời gian RTT giây, tốc độ truyền TCP khoảng w / RTT TCP sau thăm dị băng thông bổ sung cách tăng w MSS RTT xảy kiện mát Ký hiệu W giá trị w xảy kiện mát Giả sử RTT W gần không đổi suốt thời gian kết nối, tốc độ truyền TCP nằm khoảng từ W / (2 · RTT) đến W / RTT • Những giả định dẫn đến mơ hình vĩ mơ đơn giản hóa cao cho hành vi ổn định TCP Mạng bỏ gói tin khỏi kết nối tốc độ tăng lên W / RTT; Sau đó, tốc độ bị cắt nửa sau tăng MSS / RTT RTT đạt W / RTT lần Quá trình lặp lặp lại nhiều lần Vì thơng lượng TCP (nghĩa tốc độ) tăng tuyến tính hai giá trị cực, ta có: Thơng lượng trung bình kết nối = (0.75*W)/RTT Thông báo tắc nghẽn rõ ràng mạng hỗ trợ kiểm soát tắc nghẽn dựa độ trễ Kể từ tiêu chuẩn hóa ban đầu khởi động chậm tránh tắc nghẽn vào cuối 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 báo tắc nghẽn rõ ràng từ mạng thay vào đó, gây tắc nghẽn thơng qua việc gói quan sát Gần hơn, phần mở rộng cho IP TCP [RFC 3168] đề xuất, thực triển khai cho phép mạng báo hiệu rõ ràng tắc nghẽn cho người gửi người nhận TCP Ngoài ra, số biến thể giao thức kiểm soát tắc nghẽn TCP đề xuất để suy tắc nghẽn 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 đo Chúng ta xem xét kiểm soát tắc nghẽn mạng hỗ trợ dựa độ trễ phần ❖ Thông báo tắc nghẽn cụ thể Thông báo tắc nghẽn rõ ràng [RFC 3168] hình thức kiểm sốt tắc nghẽn mạng hỗ trợ thực Internet Như Hình 6, TCP IP có liên quan Ở lớp mạng, hai bit (với bốn giá trị có thể, tổng thể) trường Loại dịch vụ tiêu đề sơ đồ IP sử dụng cho ECN Hình 6: Thơng báo tắc nghẽn rõ ràng: kiểm sốt tắc nghẽn mạng hỗ trợ Một cài đặt bit ECN định tuyến sử dụng để định tuyến gặp cố tắc nghẽn Dấu hiệu tắc nghẽn sau thực IP datagram tới máy chủ đích, sau thơng báo cho máy chủ gửi, Hình RFC 3168 không cung cấp định nghĩa thời điểm định tuyến bị tắc nghẽn; định lựa chọn cấu hình nhà cung cấp định tuyến thực nhà khai thác mạng định Tuy nhiên, trực giác bit báo tắc nghẽn thiết lập để báo hiệu khởi đầu tắc nghẽn trình gửi trước mát thực xảy Thiết lập thứ hai bit ECN sử dụng máy chủ gửi để thông báo cho định tuyến người gửi người nhận có khả ECN có khả thực hành động để đáp ứng với tắc nghẽn mạng ECN định 14 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP Trong Hình 6, TCP máy chủ nhận nhận báo tắc nghẽn ECN thông qua sơ đồ liệu nhận, TCP máy chủ nhận thông báo TCP máy chủ gửi báo tắc nghẽn 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) 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ó báo tắc nghẽn cách giảm nửa cửa sổ tắc nghẽn, phản ứng với phân đoạn bị cách sử dụng truyền lại nhanh đặt bit CWR (Cửa sổ tắc nghẽn giảm) tiêu đề lần truyền 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 sử dụng ECN 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 UDP kiểm sốt tắc nghẽn, chi phí thấp sử dụng ECN DCTCP (Trung tâm liệu TCP) [Alizadeh 2010, RFC 8257] DCQCN (Thơng báo tắc nghẽn lượng tử hóa Trung tâm liệu) [Zhu 2015] thiết kế đặc biệt cho mạng trung tâm liệu, sử dụng ECN Các phép đo Internet gần cho thấy việc triển khai khả ECN ngày tăng máy chủ phổ biến định tuyến dọc theo đường dẫn đến máy chủ [Kühlewind 2013] ❖ Kiểm soát tắc nghẽn dựa độ trễ Một định tuyến bị tắc nghẽn đặt bit báo tắc nghẽn để báo hiệu cố tắc nghẽn bắt đầu cho người gửi trước đệm đầy khiến gói bị rơi định tuyến Điều cho phép người gửi giảm tốc độ gửi họ sớm hơn, hy vọng trước gói, tránh gói truyền lại tốn 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ễ để chủ động phát khởi đầu tắc nghẽn trước xảy gói • Trong TCP Vegas [Brakmo 1995], người gửi đo lường RTT đường dẫn đến nguồn đích cho tất gói thừa nhận Gọi RTTmin giá trị tối thiểu phép đo người gửi; điều xảy đường dẫn khơng bị chặn 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 TCP Vegas cwnd,thì tốc độ thông lượng chưa kiểm tra cwnd / RTTmin Trực giác đằng sau TCP Vegas thông lượng thực tế người gửi đo gần với giá trị này, tốc độ gửi TCP tăng lên (theo định nghĩa theo phép đo) đường dẫn chưa bị tắc nghẽn Tuy nhiên, thông lượng thực tế người gửi đo nhỏ đá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 bị tắc nghẽn người gửi Vegas TCP giảm tốc độ gửi Thông tin chi tiết tìm thấy [Brakmo 1995] • TCP Vegas hoạt động theo trực giác người gửi TCP có nghĩa liên kết (đặc biệt liên kết tắc nghẽn hạn chế thông lượng kết nối) bận rộn việc truyền tải, thực cơng việc hữu ích • Xem thêm: Giao thức kiểm soát tắc nghẽn BBR [Cardwell 2017] xây dựng dựa ý tưởng TCP Vegas kết hợp chế cho phép cạnh tranh công với người gửi TCP BBR [Cardwell 2017] báo cáo vào năm 2016, Google bắt đầu sử dụng BBR cho tất lưu lượng TCP mạng B4 riêng [Jain 2013] kết nối trung tâm liệu Google, thay CUBIC Nó triển khai máy chủ Web Google YouTube Các giao thức kiểm soát tắc nghẽn TCP dựa độ trễ khác bao gồm TIMELY cho mạng trung tâm liệu [Mittal 2015], Compound TCP (CTPC) [Tan 2006] FAST [Wei 2006] cho mạng tốc độ cao đường dài Kiểm soát cách tin cậy Hãy xem xét K kết nối TCP, kết nối có đường dẫn end-to-end khác nhau, tất qua 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, muốn nói kết nối, tất liên kết khác dọc theo đường dẫn kết nối khơng bị tắc nghẽn có khả truyền tải dồi so với khả truyền tải liên kết nút cổ chai.) Giả sử kết nối truyền tệp lớn khơng có lưu lượng UDP qua liên kết nút cổ chai Một chế kiểm soát tắc nghẽn cho cơng tốc độ truyền trung bình kết nối xấp xỉ R / K; nghĩa là, kết nối nhận phần băng thông liên kết Thuật tốn AIMD TCP có tin cậy không, đặc biệt kết nối TCP khác bắt đầu vào thời điểm khác có kích thước cửa sổ khác thời điểm định? [Chiu 1989] cung cấp lời giải thích trực quan lý kiểm soát tắc nghẽn TCP hội tụ để cung cấp phần băng thông liên kết nút cổ chai 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 xem xét trường hợp đơn giản hai kết nối TCP chia sẻ liên kết với tốc độ truyền R, thể Hình Giả sử hai kết nối có MSS RTT (để chúng có kích thước cửa sổ tắc nghẽn, chúng có thơng lượng), tức chúng có lượng lớn liệu để gửi, khơng có kết nối TCP sơ đồ liệu UDP khác qua liên kết chia sẻ Ngoài ra, bỏ qua giai đoạn khởi động chậm TCP giả sử kết nối TCP hoạt động chế độ CA (AIMD) lúc Hình 7: Hai kết nối TCP chia sẻ liên kết tắc nghẽn Hình vẽ biểu đồ thơng lượng thực hai kết nối TCP Nếu TCP chia sẻ băng thơng liên kết hai kết nối, thông lượng nhận nằm dọc theo mũi tên 45 độ (chia sẻ băng thông nhau) xuất phát từ điểm gốc Lý tưởng nhất, tổng hai thông lượng phải R (Chắc chắn, kết nối nhận phần chia sẻ dung lượng liên kết nhau, khơng, khơng phải tình mong muốn!) Vì vậy, mục tiêu phải để thơng lượng đạt rơi vào gần Giao điểm đường chia sẻ băng thông đường sử dụng băng thơng đầy đủ Hình Giả sử kích thước cửa sổ TCP cho thời điểm định, kết nối nhận thông lượng điểm A Hình Vì lượng băng thơng liên kết tiêu thụ chung hai kết nối nhỏ R nên không xảy mát hai kết nối tăng cửa sổ chúng thêm MSS RTT thuật toán tránh tắc nghẽn TCP ➢ Do đó, thơng lượng chung hai kết nối tiến hành dọc theo đường 45 độ (tăng cho hai kết nối) điểm A Cuối cùng, băng thông liên kết sử dụng chung hai kết nối lớn R, cuối gói mát xảy Giả sử kết nối bị gói chúng nhận thơng lượng điểm B Các kết nối sau giảm cửa sổ chúng 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 nhận điểm C, nằm vectơ B kết thúc điểm gốc Bởi việc sử dụng băng thơng chung nhỏ R điểm C, hai kết nối lại tăng thông lượng chúng dọc theo đường 45 độ C Cuối cùng, mát lại xảy ví dụ: điểm D hai kết nối lại giảm kích thước cửa sổ họ theo hệ số hai, v.v Bạn nên thuyết phục thân băng thông nhận hai kết nối cuối dao động dọc theo đường chia sẻ băng thông Bạn nên thuyết phục thân hai kết nối hội tụ thành hành vi chúng đâu không gian hai chiều! Mặc dù số giả định lý tưởng hóa nằm sau kịch này, mang lại cảm giác trực quan lý TCP dẫn đến việc chia sẻ băng thông kết nối Hình 8: Thơng lượng thực kết nối TCP Trong kịch lý tưởng hóa, giả định kết nối TCP qua liên kết nút cổ chai, kết nối có giá trị RTT kết nối TCP liên kết với cặp máy chủ-đích Trong thực tế, điều kiện thường không đáp ứng, ứng dụng máy khách-máy chủ nhận phần băng thông liên kết không Đặc biệt, chứng minh nhiều kết nối chia sẻ nút cổ chai chung, phiên có 18 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP RTT nhỏ lấy băng thơng có sẵn liên kết nhanh trở nên miễn phí (nghĩa mở cửa sổ tắc nghẽn chúng nhanh hơn) có thơng lượng cao kết nối có RTT lớn ❖ Kiểm soá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 ứng dụng thông qua chế cửa sổ tắc nghẽn Nhiều ứng dụng đa phương tiện, chẳng hạn điện thoại Internet hội nghị truyền hình, thường khơng chạy qua TCP lý họ khơng muốn tốc độ truyền bị hạn chế, mạng tắc nghẽn Thay vào đó, ứng dụng thích chạy qua UDP, khơng có tính kiểm sốt tắc nghẽn tích hợp Khi chạy qua UDP, ứng dụng bơm âm video chúng vào mạng với tốc độ không đổi đơi bị gói, thay giảm tốc độ chúng xuống mức “hợp lý” thời điểm tắc nghẽn khơng bị gói Từ quan điểm TCP, ứng dụng đa phương tiện chạy UDP không tin cậy, chúng không hợp tác với kết nối khác điều chỉnh tốc độ truyền chúng cách thích hợp Bởi kiểm sốt tắc nghẽn TCP làm giảm tốc độ truyền đối mặt với tình trạng tắc nghẽn ngày tăng (mất mát), nguồn UDP khơng cần, nguồn UDP lấn át lưu lượng TCP Một số chế kiểm soát tắc nghẽn đề xuất cho Internet để ngăn lưu lượng UDP đưa thông lượng Internet bị đình trệ [Floyd 1999; Floyd 2000; Kohler năm 2006; RFC 4340] ❖ Kết nối TCP tin cậy Nhưng buộc lưu lượng UDP hoạt động tin cậy, vấn đề tin cậy khơng giải hồn tồn Điều khơng có ngăn ứng dụng dựa TCP sử dụng nhiều kết nối song song Ví dụ: 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 trang Web (Số lượng xác nhiều kết nối định cấu hình hầu hết trình duyệt) Khi ứng dụng sử dụng nhiều kết nối song song, nhận phần lớn băng thông liên kết bị tắc nghẽn Chúng ta xem xét liên kết có tốc độ R hỗ trợ chín ứng dụng máy khách-máy chủ diễn ra, với ứng dụng sử dụng kết nối TCP Nếu ứng dụng xuất sử dụng kết nối TCP, 19 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP ứng dụng có tốc độ truyền gần R/10 Nhưng ứng dụng thay vào sử dụng 11 kết nối TCP song song, ứng dụng bị phân bổ không tin cậy nhiều R / Bởi lưu lượng truy cập Web phổ biến Internet, nhiều kết nối song song khơng phải 20 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP Kết luận Sau tìm hiểu biết hoạt đơng kiểm sốt tắc nghẽn TCP Vai trị việc truyền thơng quan trọng Nó kiểm sốt lưu lượng truyền tránh mát , độ uy tín cao Tài liệu tham khảo: James F Kurose/Keith W.ross- Computer Networking_ A Top-Down Approach-Pearson Hoang Trọng Minh-Bài giảng báo hiệu điều khiển kết nối 21 ... chia sẻ liên kết tắc nghẽn nhất……17 ▪ Hình 8: Thơng lượng thực kết nối TCP 2… 18 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ư biết TCP cung cấp dịch... Wmax Hình 5: Tốc độ gửi tránh tắc nghẽn TCP: TCP Reno TCP CUBIC 12 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP ❖ Mô tả macro thơng lượng TCP Reno • Với TCP Reno, điều tự nhiên phải xem xét thông... kiểm soát tắc nghẽn mạng hoạt động Mười năm sau phát triển TCP, phân tích lý thuyết cho thấy thuật tốn kiểm sốt tắc nghẽn TCP đóng vai trị 10 Nhóm 12 Điều khiển tắc nghẽn cho giao thức TCP thuật