Embed Size (px)
Citation preview
Bài giảng Mạng máy tính
ET4230 – 20112 (Tuần 9)
TS. Trần Quang Vinh
Lớp giao vận – Transport Layer (tiếp)
1. Các khái niệm
Điều khiển luồng (Flow Control): Điều khiển lượng dữ liệu được gửi đi để đảm bảo rằng bên gửi có tốc độ nhanh không thể tiếp tục truyền dữ liệu nhanh hơn mức mà bên nhận có thể tiếp thu được (không làm quá tải bên nhận).
Điều khiển luồng luôn luôn liên quan đến một sự phản hồi trực tiếp từ phía nhận đến phía gửi để thông báo khả năng nhận của bên nhận.
Chống tắc nghẽn (Congestion Control):
Chống tắc nghẽn là cơ chế kiểm soát thông tin đi vào mạng nhằm đảm bảo tổng lưu lượng thông tin đi vào mạng không vượt quá khả năng xử lý của toàn mạng.
Chống tắc nghẽn liên quan đến việc kiểm soát thông tin trên toàn mạng, trong khi điều khiển luồng là việc kiểm soát thông tin giữa hai đầu cuối cụ thể. Hai kỹ thuật này có điểm tương đồng là phải giới hạn lưu lượng thông tin nhằm tránh khả năng quá tải của hệ thống đích, điều khiển luồng và tránh tắc nghẽn thường được sử dụng kết hợp với nhau để kiểm soát thông tin trên mạng, ví dụ trong giao thức TCP.
Điều khiển luồng được thực hiện ở tầng nào?
Điều khiển luồng và tránh tắc nghẽn được sử dụng nhiều nhất tại các lớp liên kết dữ liệu (data link), lớp mạng (network) và lớp giao vận (transport) trong đó
Điều khiển luồng từ đầu cuối đến đầu cuối (end-to-end): nhằm tránh cho bộ đệm của quá trình nhận tại đích khỏi bị tràn, được thực hiện ở lớp Giao vận.
Điều khiển luồng trên từng chặng (hop-by-hop): nhằm tránh cho từng đường truyền khỏi bị tắc nghẽn. Tuy nhiên, việc kiểm soát luồng trên từng chặng sẽ có ảnh hưởng đến các chặng khác, do đó nó cũng có tác dụng tránh tắc nghẽn cho các đường truyền có nhiều chặng. Trong mô hình tham chiếu OSI, điều khiển luồng hop-by-hop được thực hiện ở lớp Liên kết dữ liệu và lớp Mạng.
Mục đích chính của việc sử dụng điều khiển luồng và chống tắc nghẽn trong mạng là nhằm:
+ Tối ưu hóa thông lượng sử dụng của mạng + Giảm trễ gói khi đi qua mạng + Đảm bảo tính công bằng cho việc trao đổi thông tin trên mạng + Đảm bảo tránh tắc nghẽn trong mạng
1
2. Kiểm soát luồng (Flow Control)
TCP sử dụng cơ chế “cửa sổ trượt” tương ứng với bộ đệm dữ liệu cung cấp từ các chương trình ứng dụng quy định số lượng dữ liệu tối đa một nguồn có thể gửi trước khi nhận được một báo nhận từ bên nhận.
Đây là một trong các cơ chế kiểm soát luồng được sử dụng rộng rãi nhất, có thể áp dụng tại một hay nhiều tầng của mạng, thường là tầng Liên kết dữ liệu, tầng Mạng, hoặc tầng Giao vận.
Các bên gửi/nhận sử dụng cửa sổ để kiểm soát luồng dữ liệu. Cửa sổ nhận (Rwnd) chỉ ra số lượng dữ liệu tối đa bên thu có thể nhận, tham số này do bên nhận báo cho bên gửi trong trường Receive Window Size (thông thường từ 4kB – 8kB).
Cơ chế kiểm soát luồng bằng cửa sổ trượt cho phép bên gửi phát đi liên tiếp một số segment nhất định rồi mới phải dừng lại chờ thông báo về kết quả nhận, ACK, trước khi tiếp tục phát.
Bên nhận kiểm soát luồng bằng cách kìm lại hay gửi ngay ACK. Tại mọi thời điểm, bên gửi phải ghi nhớ một danh sách chứa số thứ tự liên tiếp các segment mà nó được phép gửi đi, các segment này được gọi là nằm trong cửa sổ gửi. Tương tự như vậy, bên gửi cũng duy trì một danh sách gọi là cửa sổ gửi (Cwnd: Congestion window size), tương ứng với các segment mà nó được phép gửi. Hai cửa sổ gửi và nhận không nhất thiết phải có độ lớn bằng nhau.
Dữ liệu đã gửi và nhận được ACK
Dữ liệu chưa được phép gửi
2
Kích thước cửa sổ phải được điều chỉnh cho phù hợp với bộ đệm của bên thu và đảm bảo hiệu suất kênh truyền. Trong thực tế, kích thước cửa sổ được đánh giá qua RTT.
RTT > Window Size: hiệu suất kênh truyền thấp
RTT= Window Size: hiệu suất kênh đạt 100%.
3. Kiểm soát lỗi (Error Control)
TCP cung cấp độ tin cậy bằng cách kiểm soát lỗi, phát hiện gói tin bị hỏng, bị mất, sai thứ tự, và trùng dữ liệu. Kiểm soát lỗi trong giao thức TCP đạt được thông qua việc sử dụng các tổng kiểm tra (checksum), cơ chế xác nhận (ACK), và thời gian chờ (timeout).
- Acknowledgement (ACK): là một gói tin được gửi bởi một trạm để thông báo một gói tin đã nhận được. Gói ACK được tạo ra bằng cách thay đổi trường type trong phần TCP header. Vì TCP thực hiện truyền tin song công, nên gói ACK cung có thể mang dữ liệu (piggyback). (Rule 1) Gói ACK không được gán sequence number và không có báo nhận cho bản thân gói ACK.
- Timeout: cho biết một gói tin đã gửi đi mà chưa nhận được ACK trong một khoảng thời gian chờ (timer) xác định trước. Tham số Timeout khởi động qua trình truyền lại ở bên gửi (Retransmission TimeOut -RTO). Sau khoảng thời gian RTO>RTT mà không nhận được ACK truyền lại.
- Retransmission: (Rule 2) việc truyền lại sảy ra khi timeout hoặc khi nhận được 3 ACK liên tiếp trùng nhau. (Rule 3) Không thiết lập timer cho gói ACK.
- Out-of-order: (Rule 4) Dữ liệu đến bên nhận có thể không đúng thứ tự, chúng được lưu trong bộ đệm bên thu và chỉ được chuyển lên tầng trên khi đã sắp xếp lại.
Hoạt động ở chế độ song công
3
Hình. Cơ chế truyền lại sử dụng timeout: (a) trường hợp bình thường, (b,c) truyền
lại khi mất frame hoặc mất ACK, (d) timeout < RTT gay ra phát trùng frame.
- RTO là giá trị thay đổi, thích ứng với trạng thái kênh ví dụ như khi RTT thay đổi, vì vậy cần xác định RTO một cách hợp lý để đạt hiệu quả tốt nhất. Nếu RTO quá lớn gây ra trễ truyền lớn, nếu RTO quá nhỏ có thể sảy ra phát trùng các gói tin.
- Để ước lượng RTO, sử dụng phương pháp “trung bình cửa sổ trượt theo trọng số mũ” (Exponential Weighted Moving Average - EWMA) theo thuật toán Jacobson như sau:
Sender Receiver
Frame
ACK
Tim
eout
Tim
e
Sender Receiver
Frame
ACK
Tim
eout
Frame
ACKTim
eout
Sender Receiver
Frame
ACKTim
eout
Frame
ACKTim
eout
Sender Receiver
Frame
Tim
eout
Frame
ACKTim
eout
(a) (c)
(b) (d)
Phát (A)
Thu (B)ACK
Round-trip time (RTT)
ACK
Retransmission TimeOut (RTO)
Estimated RTT
Data1 Data2
Guard Band
RTO trước đó
RTT đo hiện tại
4
+ Tính giá trị ước lượng eRTT:
eRTTk= α eRTTk-1 + (1 - α) SampleRTT (1)
+ Thiết lập timeout dựa trên eRTT
RTO = 2 * eRTTk (2)
Trong đó:
+ α là trọng số thuật toán EWMA (0 ≤ α ≤ 1, thông thường α =7/8),
+ k là số bước lặp
+ SampleRTT: giá trị RTT đo được (thực tế) cho mỗi cặp packet/ACK tại bước k.
Lưu ý: Phải tính eRTT qua eRTT trước đó và RTT hiện tại đo được cộng với một khoảng bảo vệ (chính là giá trị điều chỉnh bởi tham số α).
Trường hợp mất gói (Lost segment)
Chú ý:
+ TCP ở bên nhận chỉ chuyển dữ liệu đã được sắp xếp đúng thứ tự cho tiến trình tương ứng
+ Sinh viên tự tìm hiểu trong trường hợp mất ACK
Ví dụ:
Một kết nối TCP có RTT hiện tại là 30 ms, nhận được các bản tin ACK đến sau 26, 32, và 24 ms. Tính ước lượng giá trị RTT theo thuật toán Jacobson với α = 0.9.
RTT=αRTT+(1-α)M
RTT1=0.9 x 30 + (1-0.9) x 26 = 29.6
RTT2=0.9 x 29.6 + (1-0.9) x 32 = 29.84
RTT3=0.9 x 29.84 + (1-0.9) x 24 = 29.256 5
4. Chống tắc nghẽn (Congestion Control)
4.1. Hiện tượng tắc nghẽn
Tắc nghẽn là một hiện tượng rất quen thuộc trên mạng, mà nguyên nhân nói chung là do tài nguyên mạng giới hạn trong khi nhu cầu truyền thông tin của con người là không có giới hạn. Hay nói cụ thể hơn, tắc nghẽn xảy ra trong mạng khi lưu lượng gửi vào mạng vượt quá dung lượng truyền dẫn. Hiện tượng tắc nghẽn có thể xảy ra ở một hoặc một số nút mạng, hay trên toàn mạng.
Chống tắc nghẽn là cơ chế kiểm soát thông tin đi vào mạng nhằm đảm bảo tổng lưu lượng thông tin đi vào mạng không vượt quá khả năng xử lý của toàn mạng.
Hình. Hiện tượng tắc nghẽn
(a) Khi số lượng segment đến mạng còn tương đối nhỏ, nằm trong khả năng vận tải của mạng, chúng sẽ được phân phát đi hết, số lượng segment được chuyển đi tỉ lệ thuận với số lượng segment đến mạng. (b) Do luôn có một tỉ lệ segment phải phát lại do bị lỗi trong quá trình vận chuyển, lưu lượng mà mạng thực sự phải vận chuyển nhìn chung lớn hơn lưu lượng đi qua mạng (thông lượng <= dung lượng kênh truyền). (c) Khi lưu lượng đến cao quá một mức nào đó, các nút mạng không còn đủ khả năng chứa và chuyển tiếp các segment, do đó các nút mạng bắt đầu phải loại bỏ các segment thông lượng giảm đi. (d) Nếu lưu lượng đến mạng tiếp tục tăng lên, tỉ lệ segment phát lại trên tổng số segment trong mạng có thể tăng đến 100%, nghĩa là không có segment nào được phân phát đi cả, thông lượng của mạng giảm xuống bằng không, mạng bị nghẹt hoàn toàn (deadlock).
Chống tắc nghẽn được chia làm hai loại:
- Điều khiển truy nhập mạng (network access): kiểm soát và điều khiển lượng thông tin có thể đi vào trong mạng.
- Điều khiển cấp phát bộ đệm (buffer allocation): là cơ chế thực hiện tại các nút mạng nhằm đảm bảo việc sử dụng bộ đệm là công bằng và tránh việc không truyền tin được do bộ đệm của tất cả các nút bị tràn (deadlock).
(a)
(b) (c)
(d)
6
4.2. Nguyên nhân gây tắc nghẽn mạng
4.2.1. Tràn bộ đệm
Khi số lượng segment đến trên hai hoặc ba giao diện vào của một nút mạng đều cần đi ra trên cùng một đường truyền để đến đích, chúng sẽ phải xếp hàng đợi được truyền đi. Nếu tình trạng trên kéo dài, hàng đợi sẽ dài dần ra và đầy, không còn chỗ cho các segment mới đến, chúng bị loại bỏ và sẽ được phát lại, làm tăng tỉ lệ segment phải phát lại trong mạng.
Biện pháp khắc phục bằng cách tăng kích thước hàng đợi (bộ nhớ) tại các nút mạng trong một chừng mực nào đó là có ích, tuy nhiên, người ta đã chứng minh được rằng, tăng kích thước hàng đợi quá một giới hạn nào đó sẽ không mang lại lợi ích gì, thậm chí còn có thể làm cho vấn đề tắc nghẽn tồi tệ hơn. Đó là vì các segment sẽ bị timeout ngay trong quá trình xếp hàng, bản sao của chúng được bên gửi phát lại, làm tăng số lượng segment phát lại trong mạng.
4.2.2. Tốc độ xử lý chậm (hay nghẽn cổ chai)
Tốc độ xử lý chậm của các nút mạng cũng là một nguyên nhân quan trọng gây nên tắc nghẽn, bởi vì chúng có thể sẽ làm hàng đợi bị tràn ngay cả khi lưu lượng segment đến nút mạng nhỏ hơn năng lực vận tải của đường truyền đi ra.
Nhu cầu băng thông cao của các dịch vụ đa phương tiện và các loại hình dịch vụ mới: dữ liệu, âm thanh và hình ảnh gây ra tắc nghẽn tại các đường truyền dẫn băng thông nhỏ.
Việc tăng dung lượng đường truyền nhưng không nâng cấp bộ xử lý tại nút mạng, hoặc chỉ nâng cấp từng phần của mạng đôi khi cũng cải thiện được tình hình đôi chút, nhưng thường chỉ làm cái “cổ chai”, nơi xảy ra tắc nghẽn, dời đi chỗ khác mà thôi. Giải quyết vấn đề tắc nghẽn nói chung, cần đến các giải pháp đồng bộ. so sánh với bài toán tắc đường trong giao thông.
Nhận xét:
Nếu bộ đệm rỗng trễ nhỏ, mạng không bị tắc nghẽn. Nhưng: hiệu suất sử dụng kênh thấp.
H1
H2
R1 H3
A1(t)10Mb/s
D(t)1.5Mb/s
A2(t)100Mb/s
A1(t)
A2(t)X(t)
D(t)
7
Nếu bộ đệm luôn đầy trễ lớn, có thể tắc nghẽn, nhưng hiệu suất sử dụng kênh cao.
Tắc nghẽn có khuynh hướng tự làm cho nó trầm trọng thêm. Nếu một nút mạng nào đó bị tràn bộ đệm, segment đến sẽ bị loại bỏ, trong khi đó nút mạng bên trên, phía người gửi, vẫn phải giữ bản sao của segment đã gửi trong hàng đợi, cho đến khi timeout phát lại. Việc phải giữ bản sao segment trong hàng đợi để chờ báo nhận, cộng thêm việc có thể phải phát lại segment một số lần làm cho hàng đợi tại chính nút trên cũng có thể bị tràn. Sự tắc nghẽn lan truyền ngược trở lại phía nguồn phát sinh ra segment.
4.3. Các giải pháp chống tắc nghẽn
4.3.1. Chính sách chung
Các phương pháp chống tắc nghẽn được thực hiện dựa trên các chính sách sau:
− Điều khiển tiếp nhận (Admission control): Cho phép một kết nối mới chỉ khi mạng có thể đáp ứng một cách thích hợp. Người dùng đưa ra một tập các mô tả về lưu lượng (tốc độ truyền dẫn cực đại, tốc độ truyền dẫn trung bình, trễ cực đại cho phép...) trong pha thiết lập kết nối. Mạng cho phép người sử dụng truy nhập đến chỉ khi nào có đủ tài nguyên sẵn sàng trong mạng. Ngược lại, yêu cầu kết nối bị từ chối. Mạng giám sát, kiểm soát các luồng lưu lượng để xem liệu người dùng có tuân theo các mô tả về lưu lượng không.
− Kiểm soát (Policing): Kiểm tra kết nối nào vi phạm các mô tả về lưu lượng để đưa ra xử lý trừng phạt bằng việc: 1) Xoá các gói vi phạm mô tả; 2) Gán cho chúng quyền ưu tiên thấp hơn.
− Điều khiển luồng lưu lượng (Flow control): Yêu cầu các luồng giảm tốc độ.
4.3.2. Phân Loại
Theo các đặc điểm chung nêu trên, các phương pháp điều khiển chống tắc nghẽn có thể được phân loại như trên hình sau.
8
a) Chống tắc nghẽn vòng mở (Open-loop congestion control)
Là sự kết hợp của điều khiển tiếp nhận, kiểm soát, và nguyên lý thùng rò (leaky bucket).
Phương pháp này không sử dụng thông tin phản hồi từ mạng hoặc từ phía nhận. Vì vậy, hệ thống phải có khả năng tự quyết định khi nào thì nhận thêm các lưu lượng mới vào, khi nào thì loại bỏ các segment và loại các segment nào.
Thuật toán thùng rò (Leaky Bucket)
- Do Turner đề xuất năm 1986
- Vấn đề: Dòng dữ liệu từ các trạm xuất ra không đều,lúc nhiều lúc ít khiến cho dòng dữ liệu trên mạng tăng giảm không ổn định, những lúc có nhiều trạm đồng thời đổ nhiều dữ liệu vào sẽ gây tắc nghẽn. Cần phải điều hòa luồng dữ liệu trên mạng để đạt tới một lưu lượng ổn định, muốn vậy phải điều hòa luồng dữ liệu từ mỗi trạm xuất ra đường truyền.
- Giải pháp: Hãy hình dung một cái thùng đựng nước có một lỗ rò dưới đáy. Khi thùng có nước, lượng nước chảy qua lỗ thủng dưới đáy gần như không đổi. Khi thùng đầy mà nước vẫn chảy vào thêm, lượng nước thừa sẽ tràn đi.
Ở đây cái thùng tượng trưng cho một vùng đệm đặt giữa CPU và đường truyền. Như vậy dù dữ liệu từ CPU vào thất thường, lúc nhiều lúc ít thì luồng dữ liệu ra (chảy từ đáy thùng) vẫn đều đặn Lương lượng được kiểm soát.
Hình minh họa thuật toán Leaky Bucket
- Lưu ý: Nếu thùng đã đầy rồi mà nước vẫn chảy vào thì sẽ bị tràn ra ngoài, tức là những gói tin đến sau khi vùng đệm đã đầy sẽ bị hủy bỏ. Nếu các đơn vị dữ liệu trên mạng có cùng kích thước, chẳng hạn như các gói tin trong mạng cell ATM thì có thể căn cứ vào đơn vị đếm là số gói tin để biết bộ đệm đã đầy hay chưa và lưu
9
lượng đi qua là bao nhiêu. Nhưng nếu các gói tin không cùng kích thước thì phải cài đặt thêm một bộ đếm (theo đơn vị byte) để tính lưu lượng vào và ra.
Thuật toán Token Bucket
Đây là thuật toán cải tiến hơn thuật toán thùng rò.
- Vấn đề: Trong thuật toán thùng rò có một số điểm chưa linh hoạt. Đó là, dữ liệu chỉ xuất ra đều đặn từ một trạm, do đó không đáp ứng được một số thời điểm trạm muốn truyền ngay một lượng lớn dữ liệu. Ta hãy xét một thuật toán linh hoạt hơn gọi là Token Bucket.
- Gải pháp: Trong thuật toán này, thùng không chứa các gói tin mà chứa các token (thẻ truyền tin), các token này được sinh ra một cách đều đều, cứ sau một khoảng t nào đó lại có một token được sinh ra. Trong thùng có bao nhiêu token thì trạm được phép truyền cùng lúc bấy nhiêu đơn vị dữ liệu,và sau khi truyền thì token trong thùng bị trừ đi một số tương ứng với số đơn vị dữ liệu đã truyền.
Cũng như thuật toán Leaky Bucket, đơn vị dữ liệu có thể tính theo số gói tin hoặc theo tổng kích thước (byte) của chúng.
Khi trạm rỗi, truyền ít thì số token còn dư được tích lũy (khác với thuật toán Leaky bucket). Với cơ chế này, khi mỗi trạm rỗi thì là lúc nó để dành quyền được gửi để về sau có thể gửi cùng lúc một lượng lớn dữ liệu.
b) Chống tắc nghẽn vòng đóng (Close-loop congestion control)
Đây là phương pháp chống tắc nghẽn dựa trên trạng thái của mạng. Việc giám sát tắc nghẽn và kiểm soát luồng dựa trên thông tin phản hồi hiện (explicit) hoặc ẩn (implicit) từ mạng hoặc từ phía nhận.
+ Phản hồi ẩn (implicit feedback): bên phát sử dụng thời gian chờ (time-out) để xác định liệu có xảy ra tắc nghẽn hay không. Ví dụ: điều khiển chống tắc nghẽn trong TCP thực hiện theo kiểu này.
+ Phản hồi hiện (explixit feedback): một số bản tin tường minh được gửi đến nguồn phát. Ví dụ: điều khiển chống tắc nghẽn cho dịch vụ ABR (Available Bit Rate) trong ATM.
+ Điều khiển theo tốc độ: điều khiển một cách trực tiếp tốc độ truyền tại phía gửi (nguồn gửi tin).
+ Điều khiển theo kích thước cửa sổ: điều khiển gián tiếp tốc độ truyền thông qua việc thay đổi kích thước cửa sổ.
Các bước điều khiển vòng đóng:
Các giải pháp điều khiển vòng lặp đóng gồm ba bước như sau:
- Bước một: theo dõi hệ thống để phát hiện tắc nghẽn xảy ra khi nào và ở đâu.
10
Việc phát hiện tắc nghẽn có thể dựa trên một số tham số đo khác nhau, như tỉ lệ segment bị loại bỏ do thiếu bộ đệm, chiều dài trung bình của hàng đợi, số segment phải phát lại do bị time-out, thời gian trễ trung bình của segment khi đi qua mạng v.v. Sự tăng lên của các thông số này nói lên rằng tắc nghẽn đang tăng lên trong mạng.
- Bước hai: nơi phát hiện ra tắc nghẽn cần phải chuyển thông tin về sự tắc nghẽn đến những nơi có thể phản ứng lại. Một cách thực hiện rất đơn giản là nút mạng phát hiện ra tắc nghẽn sẽ gửi segment đến các nguồn sinh lưu lượng trên mạng để báo tin về sự cố. Tất nhiên, việc này sẽ làm tăng thêm lưu lượng đưa vào mạng đúng lúc lẽ ra phải giảm đi. Người ta cũng đã đề xuất và thực hiện một số cách khác nữa. Chẳng hạn, nút mạng phát hiện ra tắc nghẽn sẽ đánh dấu vào một bit hay một trường định trước của mọi segment trước khi segment được nút mạng chuyển tiếp đi, nhằm loan báo cho các nút mạng khác về trạng thái tắc nghẽn. Có thể nêu ra một cách thực hiện khác nữa, đó là làm cho các nút mạng đều đặn gửi đi các segment thăm dò để biết tình trạng của mạng.
- Bước ba: điều chỉnh lại hệ thống để sửa chữa sự cố. Các cơ chế thực hiện phản hồi đều nhằm mục đích là để các máy tính trên mạng có những phản ứng phù hợp nhằm làm giảm tắc nghẽn. Nếu phản ứng xảy ra quá nhanh, lưu lượng trong hệ thống sẽ thăng giáng mạnh và không bao giờ hội tụ. Nếu phản ứng quá chậm, việc điều khiển tắc nghẽn có thể không có ý nghĩa thực tế gì nữa. Chính vì vậy, để cơ chế phản hồi có hiệu quả, cần phải sử dụng một số cách tính trung bình.
11
4.4. Chống tắc nghẽn trong TCP
4.4.1. Nguyên tắc
Chống tắc nghẽn trong TCP thuộc loại chống tắc nghẽn vòng kín phản hồi ẩn. TCP dựa vào mất gói để phát hiện tắc nghẽn.
Hai cơ chế để phát hiện ra mất gói.
- Timeout: Khi gói được gửi, phía TCP khởi tạo bộ định thời. Nếu bộ định thời hết hiệu lực trước khi gói được xác nhận, TCP xem như gói bị mất
- 3dupack: Khi phía nhận TCP nhận gói không đúng trật tự, nó sẽ gửi xác nhận ACK cho gói mà nó đã nhận đúng gần nhất. Ví dụ, giả sử phía nhận nhận gói từ 1 đến 5, và gói 6 bị mất. Khi phía nhận nhận gói 7, nó gửi dupack cho gói 5. Phía gửi TCP coi việc nhận được 3 bản phúc đáp giống nhau như là dấu hiệu của 1 gói mất.
4.4.2. Hoạt động
Xem xét mối quan hệ giữa tải, trễ, và hiệu năng sử dụng mạng:
Tải: L (bit/s), trễ: D (s).
Gọi P là một tham số đơn giản để đánh giá hiệu năng mạng, với: P=L/D
Mục tiêu là đạt được P càng lớn càng tốt.
Để đạt được trạng thái tối ưu, bên phát TCP thay đổi tốc độ bằng việc thay đổi kích thước cửa sổ (Cwnd) theo công thức:
(1) Giai đoạn khởi đầu chậm SS (Slow Start)
TCP đi vào mô hình khởi đầu chậm khi bắt đầu kết nối. Trong suốt quá trình khởi đầu chậm, phía gửi tăng nhanh tốc độ gửi theo hàm mũ (exponential increase) để sớm đạt trạng thái tối ưu.
Thuật toán hoạt động như sau:
Trễ
trun
g bì
nh
Tải
Hiệu năng
Tải“Tải tối ưu”
Window=min{ReceiveWindow, CongestionWindow}
Rwnd bên thu Cwnd bên phát
12
- Bổ sung thêm các tham số cửa sổ tắc nghẽn Cwnd (Congestion window) và giới hạn trên của Cwnd là ssthresh (ss threshhold) vào tập trạng thái của mỗi kết nối.
- Khi bắt đầu phát hoặc bắt đầu lại việc phát sau khi có segment bị mất thì đặt Cwnd := 1 MSS (Maximum Segment Size).
- Mỗi khi nhận được một báo nhận mới, thì tăng Cwnd lên gấp đôi. Nhưng không tăng cwnd quá Window Size (Rwnd) mà bên nhận thông báo.
- Khi Cwnd ≥ ssthresh, chuyển sang giai đoạn tránh tắc nghẽn CA.
Hình. Tăng cửa sổ theo hàm mũ trong giai đoạn khởi động chậm (SS).
Theo cơ chế khởi động chậm, cửa sổ tăng lên theo hàm mũ, nó đạt tới kích thước W sau thời gian bằng RTT.log2W, trong đó RTT là thời gian khứ hồi và W tính bằng đơn vị segment. Điều này có nghĩa là cho phép phiên TCP tăng tốc độ nhanh chóng sau khi thiết lập kết nối để đạt hiệu năng cao. Theo thuật toán này, bên gửi sẽ truyền dữ liệu với tốc độ khi cao nhất là gấp đôi giá trị cực đại có thể của đường truyền. Chính vì vậy, giai đoạn khởi động chậm cần phải được kết thúc khi cửa sổ W đạt tới một ngưỡng nhất định.
(2) Giai đoạn chống tắc nghẽn CA (Congestion Avoidance)
Sau khi kích thước Cwnd đạt đến giá trị ngưỡng ssthresh, kết nối TCP chuyển sang chế độ tránh tắc nghẽn (CA).
Cwnd tăng tuyến tính mỗi một đơn vị (01 MSS) sau một RTT không có gói lỗi cho
13
đến khi tắc nghẽn được phát hiện.
Hình. Tăng cửa sổ theo cấp số cộng trong giai đoạn tránh tắc nghẽn (CA).
Dấu hiệu tắc nghẽn:
TCP chuyển sang trạng thái phát hiện tắc nghẽn khi mất gói xảy ra khi:
(1) RTT > Timeout mà không nhận được ACK.
+ Đặt ngưỡng ssthresh xuống còn một nửa giá trị hiện tại của Cwnd: ssthresh := Cwnd/2 (giảm theo cấp số nhân)
+ Đặt Cwnd về 1 MSS: Cwnd := 1
+ TCP chuyển về trạng thái slow start (SS)
(2) Nhận được 3 Ack (báo nhận lặp), điều đó cho biết đã có nhiều gói tin đến đích không đúng thứ tự, nghĩa là đã có gói tin bị mất.
+ Đặt ngưỡng ssthresh xuống còn một nửa giá trị hiện tại của Cwnd: ssthresh := cwnd/2
+ Đặt Cwnd bằng ½ giá trị hiện tại: Cwnd:= Cwnd/2
+ TCP quay lại trạng thái chống tắc nghẽn (CA).
14
Hình. Tổng kết chính sách điều khiển chống tắc nghẽn của TCP.
Hình. Ví dụ TCP Congestion control
Nhận xét:
- Trong giai đoạn CA, Cwnd tăng tuyến tính:
+ Đảm bảo tận dụng băng thông có thể sử dụng được
+ Vẫn thăm dò tiếp khả năng sử dụng băng thông nhiều hơn,
- Cwnd bị giảm theo cấp số nhân (Multiplicative Decreased): bởi vì theo cơ chế khởi động chậm, cửa sổ gửi tăng lên theo hàm mũ, cho nên cũng cần phải rút lui theo cách này cho đủ nhanh khi đã có dấu hiệu của tắc nghẽn.
- Vì tắc nghẽn tăng lên theo hàm mũ, cho nên việc phát hiện sớm là quan trọng. Nếu tắc nghẽn được phát hiện sớm, thì chỉ cần một vài điều chỉnh nhỏ đối với cửa sổ của bên gửi cũng có thể giải quyết được vấn đề; ngược lại, sẽ phải điều chỉnh
15
rất nhiều để mạng có thể chuyển hết đống segment tắc nghẽn trong mạng ra ngoài. Tuy nhiên, do bản chất luôn thăng giáng mạnh của lưu lượng, phát hiện tắc nghẽn sớm một cách tin cậy là một việc khó.
- Thông tin phản hồi là ẩn và vì vậy cửa sổ gửi luôn giảm đi một nửa khi xảy ra tắc nghẽn là không thực sự hiệu quả
- TCP không chia sẻ thông tin điều khiển, vì vậy các kết nối cùng một thời điểm đến cùng một đích (một trường hợp thường xảy ra với lưu lượng web) sẽ phải cạnh tranh, thay vì phối hợp để sử dụng băng thông mạng một cách hợp lý
- Đối với mạng đa dịch vụ, thuật toán điều khiển chống tắc nghẽn của TCP không đem lại bình đẳng cần thiết cho các ứng dụng
- Đối với mạng có lưu lượng biến đổi động, biến đổi nhanh, điều khiển tắc nghẽn của TCP tỏ ra bất ổn định và không hội tụ.
Thuật toán Fast Retransmit (FRTX): (bỏ)
- Sau khi nhận được Dupack (>=3), TCP thực hiện phát lại nhanh, không chờ bị Timeout, sau đó chuyển ngay về SS.
- Đây là một cách “dự đoán thông minh” rằng, gói tin đã bị mất.
Hình 5.11. Giao thức Tahoe TCP
Thuật toán Fast Recovery (FRCV): (bỏ)
Cải tiến FRTX: thực hiện FRTX xong về CA chứ không về SS:
- ssthresh := cwnd/2, nhưng không nhỏ hơn 2 (gói tin) - cwnd := cwnd + 3. Bên gửi “đoán”: 3 dupack ứng với 3 gói tin đã được
nhận đúng. - Với mỗi dupack nhận được thêm, tăng cwnd := cwnd + 1
16
Hình 5.12. Giao thức Reno TCP
Bài tập
1. Xét tính hiệu quả của việc xử dụng cơ chế SS với một liên kết có RTT=10ms và không có tắc nghẽn. Cho biết Rwnd = 24 KB và MSS = 2 KB. Cần bao nhiêu thời gian trước khi cửa sổ thu đầy đủ có thể được gửi đi?
The first bursts contain 2K, 4K, 8K, and 16K bytes, respectively. The next one is 24 KB and occurs after 40 msec.
Tại giai đoạn SS, Cwind tăng theo hàm mũ
0ms Cwnd = 1 MSS = 2K
10ms Cwnd = 2 MSS = 4K
20ms Cwnd = 4 MSS = 8K
30ms Cwnd = 8 MSS = 16K
40ms Cwnd = min(Rwnd=24K, Cwnd = 32K)= 24K
2. Giả sử một kết nối TCP sử dụng cửa sổ tắc nghẽn Cwnd = 18 KB thì sảy ra timeout. Tính kích thước cửa sổ nếu 4 lần truyền sau đó đều thành công. Giải thiết kích thước segment tối đa là 1 KB.
Timeout chuyển về SS với Cwnd:=1 MSS, so the next transmission will be 1 maximum segment size. Then 2, 4, and 8.
So after four successes, Cwnd will be 8 KB.
17
3. A TCP machine is sending full windows of 65,535 bytes over a 1-Gbps channel that has a 10-msec one-way delay. What is the maximum throughput achievable? What is the line efficiency?
RRT=20ms, One window can be sent every 20 msec. This gives 50 windows/sec, for a maximum data rate of about 50 x 65,535 bytes = 3.3 million bytes/sec = 26.2Mbps. The line efficiency is then 26.2 Mbps/1000 Mbps or 2.6 percent.
18
