BÁO CÁO TIỂU LUẬN BÁO HIỆU VÀ ĐIỀU KHIỂN VÀ KẾT NỐI ĐỀ TÀI KIỂM SOÁT TẮC NGHẼN TRONG GIAO THỨC TCP

BÁO CÁO TIỂU LUẬN BÁO HIỆU VÀ ĐIỀU KHIỂN VÀ KẾT NỐI ĐỀ TÀI: KIỂM SOÁT TẮC NGHẼN TRONG GIAO THỨC TCP HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG KHOA VIỄN THÔNG 1 BÁO CÁO TIỂU LUẬN BÁO HIỆU VÀ ĐIỀU KHIỂN VÀ KẾT NỐI ĐỀ TÀI: KIỂM SOÁT TẮC NGHẼN TRONG GIAO THỨC TCP

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

KHOA VIỄN THÔNG 1

BÁO CÁO TIỂU LUẬN BÁO HIỆU VÀ ĐIỀU KHIỂN VÀ KẾT NỐI

ĐỀ TÀI:

KIỂM SOÁT TẮC NGHẼN TRONG GIAO THỨC TCP

Giảng viên: Hoàng Trọng Minh

Nhóm 13

Lê Quang Minh : B18DCVT288 Mai Quang Thái : B18DCVT392 Nguyễn Thế Huy : B18DCVT200 Nguyễn Việt Long : B18DCVT264

Hà Nội, 10/2021

MỤC LỤC

I Tổng quan về giao thức TCP 2

1 Cấu trúc đoạn tin của TCP 2

2 Truyền dữ liệu tin cậy 3

3 Điều khiển luồng 4

4 Quản lý kết nối 5

4.1 Thiết lập kết nối 5

4.2 Giải phóng kết nối 5

II Các nguyên tắc kiểm soát tắc nghẽn 5

1 Nguyên nhân và chi phí của tắc nghẽn 6

2.Các cách tiếp cận để kiểm soát tắc nghẽn 11

III Điều khiển tắc nghẽn TCP 13

1 Khái niệm điều khiển tắc nghẽn 13

2 TCP Congestion Control (Điều khiển tắc nghẽn TCP) 13

2.1 Classic TCP Congestion Control (Kiểm soát tắc nghẽn TCP cổ điển) 13

2.2 Làm thế nào để người gửi TCP giới hạn tốc độ mà nó đưa lưu lượng truy cập vào kết nối của mình? 14

2.3 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? 14

2.4 Người gửi nên sử dụng thuật toán nào để thay đổi tốc độ gửi 16

3 TCP Congestion Control: Retrospective (Điều khiển tắc nghẽn TCP: Hồi cứu) 20

4 TCP Cubic 21

IV Network-Assisted Explicit Congestion Notification and Delayed-based Congestion Control (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ễ) 23

1 Explicit Congestion Notification (Thông báo tắc nghẽn rõ ràng) 24

2 Delay-based Congestion Control (Kiểm soát tắc nghẽn dựa trên độ trễ) 25

Tài liệu tham khảo : 26

I Tổng quan về giao thức TCP

Giao thức TCP

TCP là một giao thức tầng vận tải cung cấp dịch vụ truyền dữ liệu tin cậy, nó

sử dụng nhiều nguyên lý để đảm bảo truyền tính tin cậy: phát hiện lỗi, đánh số thứ

tự các đoạn tin, cơ chế xác nhận Giáo thức này thuộc loại kết nối có hướng vì trước khi gửi dữ liệu của lớp ứng dụng, phải có thủ tục “bắt tay” nghĩ là chúng phải gửi

một số đoạn tin đặc biệt để xác định các tham số đảm bảo cho quá trình truyền dữ

liệu

Đặc điểm

- Định hướng kết nối: trước khi truyền dữ liệu phải thực hiện thủ tục thiết lập

liên kết, sau khi truyền dữ liệu xong thì một trong hai bên hoặc cả hai bên gửi tín

hiệu yêu cầu huỷ bỏ liên kết

- Đánh số tuần tự: mỗi đoạn tin trước khi gửi đi phải được đánh số tuần tự, dựa vào cơ chế này mà bên nhận sẽ sắp xếp lại các đoạn tin chính xác và đồng thời phát

hiện được những đoạn tin bị thất lạc

- Đảm bảo độ tin cậy: Lỗi có thể xảy ra khi một đoạn tin nào đó bị thất lạc hoặc nội dung đoạn tin bị thay đổi Trong cả hai trường hợp, TCP sẽ yêu cầu gửi lại

- Điều khiển lưu lượng: do năng lực xử lý của mỗi máy tính chỉ có hạn nhất

định phụ thuộc tốc độ CPU, dung lượng bộ nhớ, tốc độ đọc/ghi thiết bị lưu trữ,… vì vậy cần có cơ chế điều khiển lưu lượng để bên nhận kịp xử lý các đoạn tin gửi đến

và tránh tình trạng mất gói tin, tràn bộ nhớ,…

1 Cấu trúc đoạn tin của TCP

Đoạn tin của giao thức TCP bao gồm các trường: thông tin điều khiển và dữ liệu của lớp ứng dụng Khi cần gửi một tập tin lớn TCP sẽ chia thành những đoạn tin có kích thước nhỏ hơn hoặc bằng kích thước tối đa của đoạn dữ liệu (MMS-Maximum

Segment Size)

Hình 1: Cấu trúc đoạn tin của TCP

- Source Port, Destination Port: trường số liệu cổng nguồn, số hiệu cổng đích

để thực hiện dịch vụ ghép/phân kênh dữ liệu cho các ứng dụng lớp trên

- Sequence Number, Acknowledgement Number: trường số thứ tự SN 32 bit và trường số biên nhận AN 32 bit được hai bên gửi, nhận sử dụng trong việc cung cấp dịch vụ truyền dữ liệu tin cậy

- Leng Field: trường độ dài tiêu đề 4 bit xác định độ dài của phần thông tin điều khiển (đơn vị 4 bytes), độ dài thay đổi phụ thuộc trường Options, nếu trường này rỗng thì chiều dài là 5x4=20 bytes

- ECN: Explicit Congestion Notification: sử dụng trong điều khiển tắc nghẽn

- 6 bit điều khiển: bit ACK được sử dụng chỉ ra giá trị đặt trong trường biên nhận là đúng Các bit RST, SYN và FIN sử dụng trong việc thiết lập hay đóng kết nối Bit PSH bật khi có dấu hiệu yêu cầu bên nhận phải chuyển dữ liệu lên tầng trên ngay lập tức Bit URG báo hiệu dữ liệu trong đoạn tin được thực thể tầng trên bên gửi tạo ra là “khẩn cấp” Byte cuối cùng của dữ liệu khẩn cấp này được xác định bởi con trỏ dữ liệu khẩn 16 bit (ptr to urgent data) TCP phải báo cho tầng trên biết có

dữ liệu khẩn và đặt con trỏ vào cuối dữ liệu khẩn

- Window: trường độ lớn cửa sổ 16 bit được sử dụng để kiểm soát lưu lượng,

đó là số lượng byte dữ liệu tối đa mà bên nhận có thể chấp nhận được

- Checksumn: giá trị kiểm tra lỗi, được tính bằng phần bù của tổng chuỗi 16 bit

- Urgent Pointer: Vị trí byte cuối cùng của dữ liệu khẩn cấp

- Options: trường có thể thay đổi tuỳ ý, được sử dụng để bên gửi và bên nhận

có thể thương lượng về giá trị MMS hoặc giá trị gia tăng của cửa sổ trong mạng cao tốc, lựa chọn nhãn thời gian

2 Truyền dữ liệu tin cậy

Giao thức IP truyền các gói tin mà không đảm bảo độ chính xác, thứ tự và độ toàn vẹn dữ liệu Các gói tin có thể bị tràn tại bộ định tuyến và không thể đến được đích, đến sai thứ tự hoặc các bit tron gói tin bị thay đổi Các đoạn dữ liệu đặt trong gói tin IP để truyền qua mạng hoàn toàn có thể bi mất hoặc thay đổi giá trị Giao thức TCP tạo ra một đường truyền dữ liệu tin cậy trên nền giao thức IP không tin cậy Dịch vụ truyền dữ liệu tin cậy của TCP đảm bảo dòng dữ liệu tới tiến trình nhận không có lỗi, liên tục, không trùng lặp và đúng theo thứ tự, nghĩa là dòng byte khi nhận giống hệt dòng byte khi gửi

TCP sử dụng cơ chế phối hợp số tuần tự, xác nhận số tuần tự ACK và đồng

hồ xác định thời gian quá hạn mỗi đoạn tin cần phải phản hồi Giao thức TCP biên nhận cho dữ liệu đã được nhận chính xác bằng cách gửi lại số tuần tự nhận của đoạn tin kế tiếp đang chờ nhận (số tuần tự của đoạn tin đã nhận + 1) TCP cũng thực hiện việc gửi liên tục theo cơ chế đường ống giúp bên gửi có thể gửi nhiều đoạn tin 1 lúc

mà chưa cần biên nhận ngay Cơ chế này cho phép nâng cao đáng kể hiệu suất của đường truyền, số lượng tối đa các đoạn tin được gửi chưa cần biên nhận ngay phụ thuộc vào cơ chế kiểm soát lưu lượng và kiểm soát tắc nghẽn của TCP

Giả thiết kết nối TCP giữa 2 máy A và B, dữ liệu truyền từ A đến B Tại máy A, TCP lấy dữ liệu của tầng ứng dụng, đóng gói trong các đoạn dữ liệu và chuyển cho tầng mạng Ngay sau khi chuyển đoạn tin cho tầng mạng, TCP khởi động đồng hồ

thời gian cho đoạn tin đó Thời gian đợi kết thúc mà vẫn chưa nhận được biên nhận cho đoạn tin đã gửi sẽ sinh ra một ngắt thời gian, khi đó máy A phải xử lý bằng cách truyền lại đoạn tin đã tạo lên ngắt thời gian

Nhận được một đoạn tin chứa giá trị trường biên nhận ACK hợp lệ, thực thể TCP phía gửi phải quyết định đó là ACK lần đầu tiên nhận được tức là biên nhận cho một đoạn tin đã gửi nhưng chưa được biên nhận, hay chỉ là ACK trùng lặp (biên nhận lại 1 gói tin đã được biên nhận) Với ACK đầu tiên thì bên gửi sẽ biết rằng tất

cả các đoạn tin có số thứ tự không vượt quá giá trị biên nhận vừa nhạn được đã được nhận đúng bên phía nhận Khi đó, bên gửi có thể cập nhật biến trạng thái TCP kiểm soát số thứ tự của đoạn tin cuối cùng mà nó cho rằng đã được nhận chính xác và theo đúng thứ tự tại phía nhận

Các hành động đến từ bên nhận có thể tóm tắt như sau:

Đoạn tin đến có số thứ tự là số thứ tự

mong muốn Tất cả dữ liệu đến số thứ

tự mong muốn đều đã biên nhận

Không có khoảng trống trong dữ liệu

nhận được

Đợi một thời gian nhất định nếu không có đoạn tin mới thì gửi ACK với số tuần tự biên nhận là số thứ tự của đoạn tin đến trước khi chờ + 1

Đoạn tin đến có số thứ tự là số thứ tự

mong muốn Đoạn tin đến trước đang

đợi gửi biên nhận Không có khoảng

trống trong dữ liệu nhận được

Ngay lập tức gửi ACK

Đoạn tin không đúng thứ tự đến, có

số thứ tự cao hơn số thứ tự mong

muốn Phát hiện có khoảng trống dữ

liệu

Ngay lập tức gửi ACK trùng lặp và chỉ ra số thứ tự của đoạn tin mong muốn nhận tiếp theo

Đoạn tin đến lấp đầy một phần hoặc

toàn bộ trống trong dữ liệu nhận

được

Ngay lập tức gửi đi ACK biên nhận cho khoảng đoạn dữ liệu đúng thứ tự lớn nhất nhận được

Khi bên nhận TCP nhận đoạn tin có số thứ tự lớn hơn số thứ tự đúng thứ tự đang mong muốn, nó phát hiện có đoạn trống trong dòng dữ liệu tức là thiếu đọan tin Giao thức TCP không sử dụng biên nhận phủ định nên nó biên nhận lại đoạn tin đúng thứ tự cuối cùng mà nó nhận được (tạo ra ACK trùng lặp) Nếu bên gửi TCP nhận được 3 ACK trùng lặp cho cùng 1 đoạn tin, nó cho rằng đoạn tin ngay sau đoạn tin được biên nhận ba lần bị lỗi Trong trường hợp này, TCP thực hiện cơ chế truyền lại nhanh gửi lại đoạn tin đó trước khi đồng hồ thời gian của đoạn tin lỗi thực hiện ngắt

3 Điều khiển luồng

Khi kết nối TCP nhận được các đoạn dữ liệu, nó sẽ đặt chúng vào một vùng nhớ tạm thời gọi là đệm nhận Tầng ứng dụng sẽ đọc dữ liệu từ bộ đệm này, sau đó

sẽ giải phóng bộ đệm cho các đoạn tin kế tiếp Trong một số tình huống, tiến trình chưa kịp đọc dữ liệu trong bộ đệm sẽ dẫn đến tình trạng tràn bộ đệm Để giải quyết

vấn đề này TCP cung cấp dịch vụ kiểm soát lưu lượng (flow control), thực chất là quá trình làm tương thích về tốc độ gửi/nhận

Để kiểm soát lưu lượng, TCP bên gửi sử dụng biến Receive window Đây là giá trị mà bên nhận báo cho bên gửi biết độ lớn vùng đệm còn trống của nó Trong kết nối hai hướng, ở mỗi phía kết nối có giá trị RW phân biệt Giá trị RW động có ngĩa là nó sẽ thay đổi trong thời gian kết nối

Bước 2: máy chú gửi phân đoạn thứ hai, phân đoạn SYN và ACK Phân đoạn này có hai mục đích: một là xác nhận sự nhận phân đoạn đầu tiên bằng cách sử dụng

cờ ACK và trường số xác nhận, số xác nhận bằng số trình tự khởi tạo của máy khách + 1; hai là phân đoạn được sử dụng như phân đoạn khởi tạo cho máy chủ, nó chứa

số trình tự khởi tạo để đánh số các byte gửi máy chủ tới máy khách Thực chất đây

là hai phân đoạn gộp một

Bước 3: máy khách gửi phân đoạn thứ ba, chỉ là phân đoạn ACK Xác nhận

sự phân đoạn thứ hai sử dụng cờ ACK và trường số xác nhận Số xác nhận này bằng

số trình tự khởi tạo của máy chủ cộng + 1 Máy khách cũng định nghĩa kích thước cửa sổ của máy chủ Phân đoạn thứ ba này có thể được gửi kèm theo dữ liệu

4.2 Giải phóng kết nối

Đóng kết nối có thể xuất phát từ phía bất kỳ, khi kết nối trong một hướng đã được đóng, phía kia vẫn có thể truyền dữ liệu trong hướng khác Có 4 bước để đóng kết nối:

1, Máy khách gửi phân đoạn thứ nhất, phân đoạn FIN

2, Máy chủ gửi phân đoạn thứ 2, phân đoạn ACK để thông báo sự nhận phân đoạn FIN từ máy khách Phân đoạn này sử dụng số xác nhận, bằng số trình tự trong phân đoạn FIN + 1

3, Máy chủ có thể tiếp tục gửi dữ liệu trong hướng máy chủ-máy khách Khi không còn dữ liệu truyền nữa, nó gửi phân đoạn thứ ba là một phân đoạn FIN

4, Máy khách gửi phân đoạn thứ tư là phân đoạn ACK, thông báo sự nhận phân đoạn FIN từ máy chủ Phân đoạn này chứa số xác nhận, bằng số trình tự trong phân đoạn FIN của máy chủ + 1

II Các nguyên tắc kiểm soát tắc nghẽn

Trên thực tế, sự mất mát gói tin là do lưu lượng quá mức của bộ đệm bộ định tuyến khi mạng trở nên tắc nghẽn Truyền lại gói do đó điều trị một triệu chứng của

tắc nghẽn mạng (mất một lớp truyền tải cụ thể phân đoạn) nhưng không xử lý

nguyên nhân gây ra tắc nghẽn mạng — quá nhiều nguồn cố gắng gửi dữ liệu với tốc

độ quá cao Để điều trị nguyên nhân gây ra tắc nghẽn mạng, cần có cơ chế để điều

chỉnh người gửi khi đối mặt với tình trạng tắc nghẽn mạng

Trong phần này, chúng ta xem xét vấn đề kiểm soát tắc nghẽn trong một nội

dung tổng quát, tìm cách hiểu tại sao tắc nghẽn là một điều xấu, tắc nghẽn mạng như thế nào được thể hiện trong hiệu suất mà các ứng dụng lớp trên nhận được và nhiều

các phương pháp tiếp cận có thể được thực hiện để tránh hoặc phản ứng lại sự tắc

nghẽn mạng Cái này nữa nghiên cứu chung về kiểm soát tắc nghẽn là phù hợp vì,

với truyền dữ liệu đáng tin cậy nó nằm trong danh sách “top ten” các vấn đề cơ bản

quan trọng của chúng tôi trong việc nhập mạng Phần sau chứa một nghiên cứu chi

tiết về kiểm soát tắc nghẽn của TCP thuật toán

1 Nguyên nhân và chi phí của tắc nghẽn

Bắt đầu về kiểm soát tắc nghẽn bằng cách xem xét ba tình huống phức tạp gia tăng trong đó tắc nghẽn xảy ra Trong mỗi trường hợp, chúng ta sẽ xem xét lý do tại sao tắc nghẽn xảy ra ngay từ đầu và phải trả giá là tắc nghẽn (về nguồn lực không

được sử dụng đầy đủ và hiệu suất kém mà hệ thống cuối nhận được) Chúng tôi sẽ

không (chưa) tập trung vào cách phản ứng hoặc tránh tắc nghẽn nhưng thay vì tập

trung vào vấn đề đơn giản hơn hiểu điều gì xảy ra khi các máy chủ tăng tốc độ

truyền và mạng trở nên tắc nghẽn

Tình huống 1: Hai người gửi, một bộ định tuyến có bộ đệm vô hạn

Chúng ta bắt đầu bằng cách xem xét có lẽ kịch bản tắc nghẽn đơn giản nhất có thể:

Hai mỗi máy chủ (A và B) có một kết nối chia sẻ một bước nhảy duy nhất giữa

nguồn và điểm đến, như trong hình sau:

Giả sử rằng ứng dụng trong máy chủ A đang gửi dữ liệu vào kết nối (ví dụ:

truyền dữ liệu đến giao thức cấp độ truyền tải thông qua một ổ cắm) ở mức trung

bình tốc độ 𝜆in byte / giây Những dữ liệu này là nguyên bản theo nghĩa là mỗi đơn

vị dữ liệu được gửi đi vào ổ cắm chỉ một lần Giao thức cấp độ truyền tải cơ bản là

một giao thức đơn giản Dữ liệu được đóng gói và gửi đi; không có lỗi khôi phục (ví dụ: truyền lại), kiểm soát luồng, hoặc kiểm soát tắc nghẽn được thực hiện Bỏ qua

chi phí bổ sung do thêm thông tin tiêu đề lớp vận chuyển và lớp thấp hơn, tốc độ mà Máy chủ A cung cấp lưu lượng truy cập đến bộ định tuyến trong trường hợp đầu tiên này là λin byte / giây Máy chủ B hoạt động tương tự và chúng tôi giả định đơn giản rằng nó cũng đang gửi với tốc độ λin byte / giây Các gói từ Máy chủ A và B đi qua

một bộ định tuyến và qua một liên kết gửi đi được chia sẻ dung lượng R Bộ định

tuyến có bộ đệm cho phép nó lưu trữ các gói đến khi tỷ lệ gói đến vượt quá khả năng của liên kết đi Trong kịch bản đầu tiên này, chúng tôi giả sử rằng bộ định tuyến có

một lượng không gian đệm vô hạn

Hình 3.44 vẽ biểu đồ hiệu suất kết nối của Máy chủ A theo kịch bản thứ nhất

này Biểu đồ bên trái vẽ thông lượng cho mỗi kết nối (số byte trên mỗi thứ hai ở

người nhận) như một hàm của tốc độ gửi kết nối Để gửi tỷ lệ từ 0 đến R/2, thông

lượng ở người nhận bằng với mức gửi của người gửi tỷ lệ — mọi thứ do người gửi

gửi đều được nhận ở người nhận với độ trễ hữu hạn Tuy nhiên, khi tốc độ gửi trên

R/2, thông lượng chỉ là R/2 Trên này giới hạn về thông lượng là hệ quả của việc

chia sẻ dung lượng liên kết giữa hai kết nối Liên kết chỉ đơn giản là không thể

chuyển các gói đến người nhận ở trạng thái ổn định tỷ lệ vượt quá R/2 Bất kể Máy

chủ A và B đặt tốc độ gửi của họ cao đến mức nào, họ mỗi cái sẽ không bao giờ

thấy thông lượng cao hơn R/2

Đạt được thông lượng R/2 cho mỗi kết nối thực sự có vẻ là một điều tốt, bởi

vì liên kết được sử dụng đầy đủ trong việc phân phối các gói đến đích của chúng

Tuy nhiên, đồ thị bên phải trong Hình 3.44 cho thấy hệ quả của việc vận hành năng

lực liên kết gần Khi tốc độ gửi tiếp cận R/2 (từ bên trái), độ trễ trung bình ngày

càng lớn hơn Khi tốc độ gửi vượt quá R/2, số lượng gói tin được xếp hàng trung

bình trong bộ định tuyến không bị giới hạn và độ trễ trung bình giữa nguồn và đích

trở nên vô hạn (giả sử rằng các kết nối hoạt động ở các tốc độ gửi này trong một

khoảng thời gian vô hạn và có sẵn một số lượng vô hạn bộ đệm) Do đó, mặc dù

hoạt động ở thông lượng tổng hợp gần R có thể là lý tưởng từ quan điểm thông

lượng, nhưng nó lại là lý tưởng từ quan điểm trễ Ngay cả trong kịch bản lý tưởng

hóa (cực kỳ) này, chúng tôi đã phát hiện ra một chi phí của mạng bị tắc nghẽn - độ

trễ xếp hàng lớn có thể xảy ra khi tốc độ gói đến gần khả năng liên kết

Tình huống 2: Hai người gửi và một bộ định tuyến có bộ đệm hữu hạn

Bây giờ chúng ta hãy sửa đổi một chút kịch bản 1 theo hai cách sau (xem Hình

3.45)

Đầu tiên, số lượng bộ đệm của bộ định tuyến được giả định là hữu hạn Hệ

quả của giả định trong thế giới thực này là các gói tin sẽ bị loại bỏ khi đến một bộ

đệm đã đầy Thứ hai, chúng tôi giả định rằng mỗi kết nối đều đáng tin cậy Nếu một gói chứa một phân đoạn cấp độ truyền tải bị loại bỏ tại bộ định tuyến, người gửi

cuối cùng sẽ truyền lại nó Bởi vì các gói tin có thể được truyền lại, nên bây giờ

chúng ta phải cẩn thận hơn với việc sử dụng thuật ngữ tốc độ gửi Cụ thể, chúng ta

hãy biểu thị lại tốc độ ứng dụng gửi dữ liệu gốc vào socket bằng λin byte / giây Tốc

độ mà lớp truyền tải gửi các phân đoạn (chứa dữ liệu gốc và dữ liệu được truyền lại) vào mạng sẽ được ký hiệu là λ’in byte / giây λ’in đôi khi được gọi là tải cung cấp

cho mạng

Hiệu suất được thực hiện trong kịch bản 2 bây giờ sẽ phụ thuộc mạnh mẽ vào cách truyền lại được thực hiện Đầu tiên, hãy xem xét trường hợp phi thực tế rằng

Máy chủ A có thể bằng cách nào đó (Kỳ diệu!) Xác định xem bộ đệm có trống trong

bộ định tuyến hay không và do đó chỉ gửi một gói khi bộ đệm trống Trong trường

hợp này, sẽ không xảy ra mất mát, λin sẽ bằng lamda′in và thông lượng của kết nối

sẽ bằng λin Trường hợp này được thể hiện trong Hình 3.46 (a) Từ quan điểm

thông lượng, hiệu suất là lý tưởng — mọi thứ được gửi đi đều được nhận Lưu ý

rằng tốc độ gửi trung bình của máy chủ lưu trữ không thể vượt quá R / 2 trong

trường hợp này, vì việc mất gói được cho là không bao giờ xảy ra (Một lần nữa, giả định này hơi phức tạp Tuy nhiên, có thể máy chủ gửi có thể đặt thời gian chờ đủ lớn

để hầu như đảm bảo rằng một gói tin chưa được xác nhận đã bị mất.) Trong trường

hợp này, hiệu suất có thể trông giống như thể hiện trong Hình 3.46 (b) Để đánh giá

cao những gì đang xảy ra ở đây, hãy xem xét trường hợp tải được cung cấp, lamda′in (tốc độ truyền dữ liệu gốc cộng với truyền lại), bằng R / 2 Theo Hình 3.46 (b), tại

giá trị này của tải được cung cấp, tốc độ tại đó dữ liệu được gửi đến ứng dụng người nhận là R / 3 Do đó, trong số 0,5R đơn vị dữ liệu được truyền, 0,333R byte / giây

(trung bình) là dữ liệu gốc và 0,166R byte / giây (trung bình) là dữ liệu được truyền lại Chúng tôi thấy ở đây một chi phí khác của mạng bị tắc nghẽn— người gửi phải

thực hiện truyền lại để bù đắp cho việc bị rớt (bị mất) gói do tràn bộ đệm

Cuối cùng, chúng ta hãy xem xét trường hợp người gửi có thể hết thời gian

sớm và truyền lại một gói tin đã bị trễ trong hàng đợi nhưng chưa bị mất Trong

trường hợp này, cả gói dữ liệu gốc và dữ liệu được truyền lại đều có thể đến được

người nhận Tất nhiên, người nhận chỉ cần một bản sao của gói tin này và sẽ loại bỏ việc truyền tải đó Trong trường hợp này, công việc được thực hiện bởi bộ định

tuyến trong việc chuyển tiếp bản sao được truyền lại của gói tin gốc đã bị lãng phí,

vì người nhận đã nhận được bản sao gốc của gói tin này Thay vào đó, bộ định tuyến nên sử dụng khả năng truyền liên kết để gửi một gói tin khác Đây là một chi phí

khác của mạng bị tắc nghẽn — người gửi phải truyền lại không cần thiết khi đối mặt với sự chậm trễ có thể khiến bộ định tuyến sử dụng băng thông liên kết của nó để

chuyển tiếp các bản sao không cần thiết của gói tin Hình 3.46 (c) cho thấy thông

lượng so với tải được cung cấp khi mỗi gói được bộ định tuyến giả định chuyển tiếp (trung bình) hai lần Vì mỗi gói được chuyển tiếp hai lần, thông lượng sẽ có giá trị

tiệm cận là R/4 khi tải được cung cấp tiếp cận R/2

Tình huống 3: Bốn người gửi, Bộ định tuyến có bộ đệm hữu hạn và Đường

dẫn nhiều cửa hàng

Trong kịch bản tắc nghẽn cuối cùng của chúng tôi, bốn máy chủ truyền các

gói, mỗi gói qua các đường hai bước chồng chéo, như trong Hình 3.47 Chúng tôi lại giả định rằng mỗi máy chủ sử dụng cơ chế thời gian chờ / truyền lại để triển khai

dịch vụ truyền dữ liệu đáng tin cậy, rằng tất cả các máy chủ đều có cùng giá trị λin

và tất cả các liên kết bộ định tuyến đều có dung lượng R byte/giây

Hãy xem xét kết nối từ Máy chủ A đến Máy chủ C, đi qua các bộ định tuyến

R1 và R2 Kết nối A – C chia sẻ bộ định tuyến R1 với kết nối D – B và chia sẻ bộ

định tuyến R2 với kết nối B – D Đối với các giá trị cực nhỏ của λin, lỗi tràn bộ đệm rất hiếm xảy ra (như trong kịch bản tắc nghẽn 1 và 2), và thông lượng xấp xỉ bằng

tải được cung cấp Đối với các giá trị lớn hơn một chút của λin, thông lượng tương

ứng cũng lớn hơn, vì nhiều dữ liệu gốc hơn đang được truyền vào mạng và phân

phối đến đích, và hiện tượng tràn vẫn rất hiếm Do đó, đối với các giá trị nhỏ của

λin, việc tăng λin dẫn đến tăng λout Sau khi xem xét trường hợp lưu lượng truy cập cực kỳ thấp, tiếp theo hãy kiểm tra trường hợp λin (và do đó λ′in) là cực kỳ lớn

Xem xét bộ định tuyến R2 Lưu lượng A – C đến bộ định tuyến R2 (đến R2 sau khi

được chuyển tiếp từ R1) có thể có tốc độ đến tại R2 cao nhất là R, dung lượng của

liên kết từ R1 đến R2, bất kể giá trị của λin Nếu λ’in cực kỳ lớn đối với tất cả các

kết nối (bao gồm Kết nối B – D), khi đó tốc độ đến của lưu lượng B – D tại R2 có

thể lớn hơn nhiều so với lưu lượng A – C Bởi vì lưu lượng A – C và B – D phải

cạnh tranh với bộ định tuyến R2 về lượng không gian đệm giới hạn, lượng lưu lượng

A – C đi qua R2 thành công (nghĩa là không bị mất do tràn bộ đệm) trở nên nhỏ hơn

và nhỏ hơn khi tải được cung cấp từ B – D ngày càng lớn hơn Trong giới hạn, khi

tải được cung cấp tiến đến vô cùng, một bộ đệm trống tại R2 ngay lập tức được lấp

đầy bởi một gói B – D và thông lượng của kết nối A – C tại R2 bằng không Đến

lượt nó, điều này ngụ ý rằng thông lượng A – C end-to-end sẽ bằng 0 trong giới hạn lưu lượng truy cập dày đặc Những cân nhắc này làm phát sinh sự cân bằng giữa tải

được cung cấp so với thông lượng được thể hiện trong Hình 3.48

Lý do cho sự giảm thông lượng cuối cùng với tải cung cấp ngày càng tăng là

hiển nhiên khi người ta xem xét lượng công việc bị lãng phí được thực hiện bởi

mạng Trong tình huống lưu lượng truy cập cao được nêu ở trên, bất cứ khi nào một gói tin bị rơi ở bộ định tuyến bước nhảy thứ hai, công việc được thực hiện bởi bộ

định tuyến bước nhảy thứ nhất trong việc chuyển tiếp một gói tin đến bộ định tuyến bước nhảy thứ hai sẽ bị “lãng phí” Mạng sẽ tốt như nhau (chính xác hơn, tồi tệ như nhau) nếu bộ định tuyến đầu tiên đơn giản đã loại bỏ gói tin đó và vẫn ở chế độ chờ Hơn nữa, dung lượng truyền được sử dụng ở bộ định tuyến đầu tiên để chuyển tiếp

gói tin đến bộ định tuyến thứ hai có thể được sử dụng có lợi hơn nhiều để truyền

một gói tin khác (Ví dụ: khi chọn một gói để truyền, bộ định tuyến có thể ưu tiên

hơn cho các gói đã truyền qua một số bộ định tuyến ngược dòng.) Vì vậy, ở đây

chúng ta thấy một chi phí khác của việc bỏ gói do tắc nghẽn — khi một gói tin bị rơi dọc theo một đường dẫn, dung lượng truyền dẫn được sử dụng tại mỗi liên kết

ngược dòng để chuyển tiếp gói tin đó đến điểm mà tại đó nó bị loại bỏ sẽ bị lãng phí 2.Các cách tiếp cận để kiểm soát tắc nghẽn

Trong phần sau, chúng ta sẽ xem xét cách tiếp cận cụ thể của TCP để kiểm

soát tắc nghẽn một cách chi tiết Ở đây, chúng tôi xác định hai cách tiếp cận rộng rãi

để kiểm soát tắc nghẽn được áp dụng trong thực tế và thảo luận về các kiến trúc mạng cụ thể và các giao thức kiểm soát tắc nghẽn thể hiện các cách tiếp cận này Ở cấp độ cao nhất, chúng ta có thể phân biệt giữa các phương pháp tiếp cận kiểm soát tắc nghẽn bằng cách liệu lớp mạng có cung cấp hỗ trợ rõ ràng cho lớp truyền tải cho các mục đích kiểm soát tắc nghẽn hay không:

• Kiểm soát tắc nghẽn đầu cuối Trong cách tiếp cận end-to-end để kiểm soát tắc nghẽn, lớp mạng không cung cấp hỗ trợ rõ ràng cho lớp truyền tải cho các mục đích kiểm soát tắc nghẽn Ngay cả sự hiện diện của tắc nghẽn mạng cũng phải được suy ra bởi các hệ thống đầu cuối chỉ dựa trên hành vi mạng quan sát được (ví dụ: gói mất mát và chậm trễ) Chúng ta sẽ thấy ngay rằng TCP thực hiện cách tiếp cận end-to-end này để kiểm soát tắc nghẽn, vì lớp IP không bắt buộc phải cung cấp phản hồi cho các máy chủ về tắc nghẽn mạng Mất phân đoạn TCP (như được chỉ ra bởi thời gian chờ hoặc nhận được ba xác nhận trùng lặp) được coi là một dấu hiệu của tắc nghẽn mạng và TCP giảm kích thước cửa sổ của nó tương ứng Chúng tôi cũng sẽ thấy một đề xuất gần đây hơn về kiểm soát tắc nghẽn TCP sử dụng độ trễ phân đoạn khứ hồi ngày càng tăng như một dấu hiệu của việc gia tăng tắc nghẽn mạng

• Kiểm soát tắc nghẽn có sự hỗ trợ của mạng Với tính năng kiểm soát tắc nghẽn được hỗ trợ bởi mạng, các bộ định tuyến cung cấp phản hồi rõ ràng cho người gửi và / hoặc người nhận về trạng thái tắc nghẽn của mạng Phản hồi này có thể đơn giản như một bit duy nhất chỉ ra sự tắc nghẽn tại một liên kết — một cách tiếp cận được thực hiện trong IBM SNA ban đầu [Schwartz 1982], DEC DECnet [Jain 1989; Kiến trúc Ramakrishnan 1990] và kiến trúc mạng ATM [Black 1995] Phản hồi tinh

vi hơn cũng có thể Ví dụ, trong điều khiển tắc nghẽn ATM Available Bite Rate (ABR), một bộ định tuyến thông báo cho người gửi tốc độ gửi máy chủ tối đa mà nó (bộ định tuyến) có thể hỗ trợ trên một liên kết gửi đi Như đã nói ở trên, các phiên bản Internet mặc định của IP và TCP áp dụng phương pháp tiếp cận end-to-end hướng tới kiểm soát tắc nghẽn Tuy nhiên, chúng ta sẽ thấy gần đây hơn, IP và TCP cũng có thể tùy chọn triển khai kiểm soát tắc nghẽn do mạng hỗ trợ

Đối với kiểm soát tắc nghẽn có sự hỗ trợ của mạng, thông tin tắc nghẽn

thường được đưa trở lại từ mạng tới người gửi theo một trong hai cách, như thể hiện trong Hình 3.49 Phản hồi trực tiếp có thể được gửi từ bộ định tuyến mạng đến người gửi Hình thức thông báo này thường có dạng một gói thông báo nghẹt thở (về

cơ bản là "Tôi bị tắc nghẽn!") Hình thức thông báo thứ hai và phổ biến hơn xảy ra khi một bộ định tuyến đánh dấu / cập nhật một trường trong gói truyền từ người gửi đến người nhận để chỉ ra sự tắc nghẽn Khi nhận được một gói được đánh dấu, người nhận sẽ thông báo cho người gửi về dấu hiệu tắc nghẽn Hình thức thông báo sau này mất toàn bộ thời gian khứ hồi