Nếu các nguồn lưu lượng trên mạng được phát một cách tự nhiên theo nhu cầu riêng, các bên truyền thông không cần biết tình trạng đường truyền xấu hay tốt thì tắc nghẽn mạng là điều khó tránh khỏi. Vì vậy, khi thiết kế các giao thức người ta đã đưa ra các quy tắc giúp các bên truyền thông chi phối nguồn lưu lượng đưa vào mạng để cố gắng tránh tắc nghẽn mạng. Các quy tắc này được gọi là cơ chế điều khiển lưu lượng, việc thực hiện các cơ chế này được gọi là điều khiển lưu lượng (flow control).
Hiện tượng tắc nghẽn mạng sẽ ngày càng trầm trọng nếu không có cơ chế điều khiển tắc nghẽn phù hợp. Trong trường hợp mạng đã bị tắc nghẽn thì có rất ít các gói tin trong mạng đến được đích (ra khỏi mạng), trong khi đó các gói tin vẫn được đưa vào mạng làm cho mạng càng thêm tắc nghẽn hơn, thậm chí bị “tê liệt” hoàn toàn. Trạng thái mạng bị tê liệt hoàn toàn dẫn đến thông lượng vận chuyển của mạng bằng không, trạng thái này được gọi là Deadlock.
Host A Host B
Send FIN seq=x
Receive FIN
Send ACK x+1
....
Send FIN seq=y,ACK x+1
Receive ACK Send ACK y+1
Receive FIN + ACK Receive ACK
Hình 2.11 Trạng thái deadlock
Để cải thiện tình trạng mạng khi bị tắc nghẽn, người ta đưa ra các cơ chế điều khiển tắc nghẽn, giúp cho mạng nếu bị tắc nghẽn có thể phục hồi được.
Vấn đề điều khiển lưu lượng và điều khiển tắc nghẽn có liên quan với nhau. Điều khiển lưu lượng là để tránh tắc nghẽn, còn điều khiển tắc nghẽn là để giải quyết tắc nghẽn khi nó xảy ra hoặc có dấu hiệu sắp xảy ra. Thực tế, giao thức TCP dùng xen kẽ hai thuật toán này nên có thể được xem như một thuật toán duy nhất, gọi là thuật toán điều khiển lưu lượng.
Để điều khiển lưu lượng hiệu quả, người thiết kế giao thức mạng phải biết được nguyên nhân và dấu hiệu mạng tắc nghẽn, cũng như dấu hiệu mạng sắp có tắc nghẽn xảy ra. Một số nguyên nhân dẫn đến tắc nghẽn mạng là: lưu lượng đến trên nhiều lối vào nhưng ra ở cùng một lối, tình trạng này kéo dài dẫn đến tắc nghẽn tại lối ra; tốc độ xử lý tại các route chậm; một số đoạn đường truyền có băng thông thấp hoặc lỗi nhiều... Để nhận biết được tắc nghẽn mạng sắp xảy ra, bên gửi có thể dựa vào giá trị Thời gian khứ hồi -
RTT khi nó tăng bất thường.
a) Cơ chế cửa sổ động
Cơ chế cửa sổ là một trong các phương pháp điều khiển lưu lượng số liệu trong mạng thông tin máy tính. Độ lớn của cửa sổ là số gói tin có thể gửi kiên trì mà không cần phải chờ biên nhận cho các gói số liệu này. Việc mở cửa sổ lớn bao nhiêu là rất quan trọng vì nó quyết định hiệu suất trao đổi số liệu trong mạng. Độ lớn cửa sổ được mở phụ thuộc vào tình trạng hiện tại của mạng, vì nếu cửa sổ lớn trong trường hợp đường truyền xấu (có lỗi xảy ra hay
tắc nghẽn mạng) thì số gói tin phải truyền lại nhiều, dẫn đến hiệu suất mạng giảm đáng kể.
Giao thức TCP cho phép thay đổi độ lớn cửa sổ một cách động, phụ thuộc vào độ lớn bộ đệm thu của thực thể TCP nhận. Để thực hiện cơ chế cửa sổ động, TCP đảm bảo:
− Trả lời về số tuần tự thu tiếp theo trong trường biên nhận, nghĩa là khẳng định tổng số byte nhận đúng cho đến thời điểm gửi gói tin trả lời này.
− Thông báo về tổng số byte có thể nhận được, tương ứng với độ lớn bộ nhớ đệm thu.
b) Cơ chế phát lại thích nghi
Để đảm bảo kiểm tra phát hiện và khắc phục lỗi trong việc trao đổi gói tin trong mạng Internet, được kết nối từ nhiều mạng khác nhau, TCP phải có đồng hồ kiểm tra phát (time-out) và cơ chế phát lại (retransmission) mềm dẻo, thay đổi phụ thuộc vào thời gian trễ thực của môi trường truyền dẫn cụ thể. Thời gian khứ hồi RTT, được xác định từ thời điểm bắt đầu phát gói số liệu cho đến khi nhận được biên nhận của gói số liệu đó. Nó là yếu tố quyết định giá trị của đồng hồ kiểm tra phát (Tout), và Tout phải được chọn lớn hơn RTT.
Cơ chế phát lại thích nghi dựa trên việc xác định thời gian khứ hồi RTT theo thời gian. Bằng việc sử dụng các hàm xác định thời gian của hệ điều hành, hoàn toàn xác định được thời gian khứ hồi của một kết nối TCP tại các mốc thời gian nhất định. Người ta thường tính thời gian khứ hồi RTT theo công thức sau đây [1]:
RTT = ( * Old_RTT) + (1-)*New_RTT, trong đó 01. Từ đó, có thể tính thời gian kiểm tra phát Tout theo công thức: Tout = * RTT, với = 2.
Hình 2.12 Xác định thời gian khứ hồi – RTT
b) Cơ chế điều khiển tắc nghẽn
Hiện tượng tắc nghẽn số liệu được thể hiện ở sự gia tăng bất thường thời gian khứ hồi của một gói tin truyền qua mạng. Để hạn chế khả năng dẫn đến tắc nghẽn trong mạng, người ta điều khiển lưu lượng trao đổi trên mạng theo một số chiến lược như: “Bắt đầu chậm”, “Tránh tắc nghẽn”, “Phát lại nhanh” và “Khôi phục nhanh”.
1/ Thuật toán “Bắt đầu chậm”
Thuật toán “Bắt đầu chậm” (Slow Start – SS) được sử dụng với mục đích chính là vừa truyền vừa thăm dò kênh truyền, nhằm tận dụng đối đa băng thông còn thừa trên kênh truyền. Thuật toán này định nghĩa thêm khái niệm “cửa sổ tắc nghẽn” (congestion window – cwnd), được gọi là cửa sổ phát cho thực thể phát TCP. Khi kết nối TCP được thiết lập, cwnd được gán giá trị là 1 đơn vị gói tin. Khi đó thực thể TCP phát đi với số lượng cwnd (với cwnd là 1) gói tin. Mỗi khi thực thể nhận được thông báo biên nhận đúng ACK, cửa sổ tắc nghẽn tăng thêm một (nghĩa là cửa sổ tắc nghẽn tăng gấp đôi).
Hình 2.13 Minh họa thuật toán Slow Start (adsbygoogle = window.adsbygoogle || []).push({});
Thuật toán trên chỉ thực hiện khi mạng không có dấu hiệu tắc nghẽn xảy ra. Nghĩa là, các gói tin mà thực thể TCP đã phát chưa có gói nào bị loại và cửa sổ tắc nghẽn chưa đạt đến ngưỡng tắc nghẽn (ssthresh). Trong trường hợp cửa sổ tắc nghẽn đã tới ngưỡng thì thuật toán chuyển sang giai đoạn “Tránh tắc nghẽn”, còn nếu có dấu hiệu tắc nghẽn thì thuật toán tự điều chỉnh cho thích hợp. Việc điều chỉnh này phụ thuộc vào thuật toán được cài đặt thực tế, có thể chuyển sang một trong hai chiến lược: “Phát lại nhanh” và “Khôi phục nhanh”. Như vậy, trong giai đoạn này, cửa sổ phát đã tăng theo hàm mũ cơ số 2 sau những khoảng thời gian bằng RTT.
2/ Thuật toán “Tránh tắc nghẽn”
Thuật toán “Tránh tắc nghẽn” (Congestion Avoidance – CA) áp dụng khi cửa sổ phát đã đạt đến ngưỡng, khi đó cửa sổ phát sẽ tăng chậm hơn, cụ thể: cửa sổ phát sẽ được tăng lên một đơn vị (gói tin) khi nhận được tất cả các biên nhận của các gói tin trong cửa sổ phát. Trong trường hợp này cửa sổ phát đã tăng một cách tuyến tính nhằm tiếp tục tận dụng băng thông còn sử dụng được, đồng thời thăm dò tiếp khả năng sử dụng băng thông của đường truyền. Khi bên phát của TCP thấy có dấu hiệu tắc nghẽn, thuật toán CA sẽ giảm ngưỡng của cửa sổ tắc nghẽn ssthresh xuống còn bằng một nửa cửa sổ tắc nghẽn cwnd hiện tại, sau đó giảm cửa sổ tắc nghẽn xuống còn một gói tin,
đồng thời tăng Tout (giá trị mà bên phát dùng để phán đoán là gói tin đã bị mất) lên hai lần và chuyển sang giai đoạn Slow Start.
Hình 2.14 Minh họa thuật toán Slow Start và Congestion Avoidance Dấu hiệu mà CA cho là tắc nghẽn là: thời gian chờ biên nhận tăng quá Tout; hoặc bên gửi nhận được nhiều biên nhận lặp, điều này cho biết có nhiều gói tin đã đến đích không theo thứ tự và phán đoán rằng có gói tin bị mất.
3/ Thuật toán “Phát lại nhanh”
Thuật toán phát lại nhanh (Fast Retransmission – FRTX) cho phép thực thể phát thực hiện phát lại nhanh gói số liệu được cho là mất do có nhiều biên nhận lặp (duplicated ACK) mà không chờ hết Tout. Trong thực tế, thường chỉ cần từ một đến hai thông báo ACK lặp lại là đủ để xác định gói số liệu “bị lạc”. Nếu thực thể phát nhận được nhiều hơn hai thông báo ACK lặp lại thì điều đó đồng nghĩa với việc gói tin “chắc chắn” bị mất và trong trường hợp này, gói số liệu đó cần được phát lại ngay mà không chờ đến Tout, sau đó thực thể gửi quay về giai đoạn Slow Start với cửa sổ phát bằng một.
4/ Thuật toán “Khôi phục nhanh”
Thuật toán khôi phục nhanh (Fast Recovery – FRCV) là một cải tiến của thuật toán Fast Retransmission, nhằm tránh việc giảm lưu lượng đưa vào mạng quá mạnh, có thể gây lãng phí đường truyền sau khi thực hiện FRTX.
Sau khi phát lại nhanh, thực thể gửi không chuyển về giai đoạn SS mà chuyển ngay sang giai đoạn CA. Cụ thể, sau khi nhận ba biên nhận lặp liên tiếp, ngưỡng tắc nghẽn ssthresh được giảm xuống còn một nửa cwnd nhưng không nhỏ hơn 2 gói tin và phát lại gói tin bị mất, đồng thời tăng cửa sổ wcnd lên 3 gói tin. Việc tăng lên 3 gói tin là do bên gửi nhận được 3 ACK lặp, điều này cho biết đã có 3 gói tin đã ra khỏi mạng và đến đích an toàn.
Trong các thuật toán trên, không bao giờ tăng cửa sổ phát quá giá trị mà bên nhận loan báo – rcnd (Receiver Adverticed Window). Nói cách khác, cửa sổ phát luôn nhận giá trị nhỏ nhất trong hai giá trị {cwnd, rcnd}.