Nguyên lý bảo toàn gói tin trong điều khiển lưu lượng TCP: ”giữ cho số gói số liệu có mặt trong mạng của một kết nối không thay đổi”
2.3.Các cơ chế điều khiển lưu lượng trong giao thứcTCP 1 Một số cơ chế điều khiển lưu lượng trong giao thức TCP
Để thực hiện được điều khiển lưu lượng. TCP có một số cơ chế sau:
Cơ chế cửa sổ động (cửa sổ trượt có kích thước thay đổi)
Cơ chế cửa sổ động là một trong các phương pháp điều khiển số liệu trong mạng thông tin máy tính. Độ lớn cửa sổ chính bằng số gói tin được gửi liên tục mà không cần chờ thông báo trả lời về kết quả nhận các gói tin đó. Ví dụ, nếu độ lớn của cửa sổ w=3 thì sau khi gửi đi ba gói tin liên tiếp nhau, thực thể phát phải chờ trả lời về kết quả nhận 3 gói tin nói trên, trước khi gửi ba gói tin tiếp theo.
Độ lớn cửa sổ quyết định hiệu suất trao đổi trong mạng. Nếu chọn độ lớn cửa sổ cao thì có thể gửi được nhiều số liệu trong cùng một đơn vị thời gian. Một khi việc truyền số liệu có lỗi, trong trường hợp này, rõ ràng số liệu phải gửi lại lớn và vì vậy hiệu quả sử dụng đường truyền thấp (tỷ lệ giữa số liệu được chuyển thực sự trên tổng số số liệu được trao đổi trên mạng).
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 ACK, nghĩa là khẳng định tổng số byte nhận đúng cho đến thời điểm gửi gói 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.
Để đảm bảo kiểm tra phát lại và khắc phục lỗi trong việc trao đổi số liệu qua mạng diện rộng được kết nối từ nhiều mạng khác nhau, TCP phải có cơ chế đồng hộ kiểm tra phát (time-out) và cơ chế phát lại (retransmmision) 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 (Round Trip Time), được xác định từ thời điểm bắt đầu phát gói tin cho đến khi nhận được trả lời về kết quả nhận của thực thể đối tác, là yếu tố quyết định giá trị của đồng hồ kiểm tra phát tout. Rõ ràng tout phải lớn hơn hoặc bằng RTT. Như hình 15.
Hình 15. Xác định thời gian khứ hồi 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.
Có thể tính thời gian khứ hồi theo công thức sâu đây:
RTT α¬RTT+(1-α)*new_RTT (với 0≤α<1, là hằng số khuyếch đại lọc, giá trị gợi ý là 0.9).
Từ đó có thể tính thời gian kiểm tra phát tout theo công thức: Tout=β*RTT (với β được xem là khoảng biến đổi của RTT, có giá trị gợi ý là 2).
Các cơ chế điều khiển tắc nghẽn số liệu:
Hiện tượng tắc nghẽn số liệu được thể hiện trước hết ở việc gia tăng thời gian khứ hồi RTT của một gói tin bất kỳ nào khi chuyển qua mạng.
Để hạn chế khả năng dẫn đến tắc nghẽn số liệu trong mạng, người ta điều khiển lưu lượng số liệu trao đổi trên mạng theo một số chiến lược sau đây:
• Khởi động chậm (Slow Start).
• Phát lại nhanh (fast retransmission). • Khôi phục nhanh (fast recovery).
Để thuận tiện cho việc minh hoạ cơ chế hoạt động của các biện pháp này, ta chọn đơn vị cửa sổ w bằng số gói tin TCP (trong thực tế, độ lớn cửa sổ w được tính bằng đơn vị byte).
Việc kiểm soát tránh tắc nghẽn trên mạng là vấn đề quan trọng, các thuật toán được phát triển bắt nguồn từ ý tưởng của việc tạo được sự vững chắc, ổn định mạng bằng cách thực hiện kết nối chuyển vận để tuân thủ theo một nguyên lý “bảo toàn gói tin”.
Việc chúng ta “bảo toàn gói tin”, có nghĩa rằng thực hiện kết nối “trong cân bằng” (In Equilibrium), tức là, chạy ổn định với một cửa sổ đầy đủ của dữ liệu được chuyển vận qua. Khi đó, một cách vật lý, dòng chảy của các gói tin có thể được đưa vào mạng cho đến khi gói tin cũ đã rời đi. Có thể hình dung thấy tính ổn định của dòng chảy này như một luồng giao thông với sự ổn định lưu lượng của nó.
Jacobson đã đưa ra nguyên lý bảo toàn như ở trên để khẳng định tính ổn định của mạng. Nếu nguyên lý này được tuân theo thì sự suy sụp mạng do tắc nghẽn sẽ rất khó xảy ra. Như vậy, sự điều khiển tắc nghẽn liên quan đến việc tìm ra những nơi vi phạm nguyên lý bảo toàn và sửa chữa chúng:
Các nguyên nhân dẫn đến thực hiện không đúng “nguyên lý bảo toàn” này là:
• Kết nối không đạt tới sự cân bằng
• Người gửi đã đưa một gói tin mới vào mạng trước khi có một gói tin cũ ra khỏi mạng. Nguyên nhân là do hai sai lầm:
o Người gửi không thể đánh giá được đúng độ biến thiên của thời gian khứ hồi RTT.
o Chọn thời gian rút lui sau khi phát lại: nếu một gói số liệu phải được phát lại trên một lần, thì các lần phát lại này phải có cự li thời gian như thế nào? Với nguyên nhân này khi các gói tin cũ chưa đưa ra khỏi mạng mà đã đưa gói tin tiếp theo vào dẫn đến thông tin mà người đó gửi thừa ra. Mà trên mạng có rất nhiều người sử dụng. Giả sử mỗi người gây ra sự dư thừa đó thì tắc nghẽn xảy ra là điều rất khó tránh khỏi.
Không đạt được sự cân bằng do có sự hạn chế các tài nguyên mạng dọc theo đường truyền: các tài nguyên mạng như băng thông (đường truyền), bộ đệm (các node trung gian). Băng thông thấp dẫn đến đường truyền tốc độ kém mà khi đó yêu cầu là truyền những lượng thông tin lớn, hoặc là thiếu bộ đệm dẫn đến các thông tin bị lưu lại trên đường truyền…Nhiều thông tin lưu lại dẫn đến tắc nghẽn chắc chắn sẽ xảy ra.
Các biện pháp khắc phục đã được xây dựng như thuật toán: khởi động chậm (Slow Start), hay việc tính toán lại thời gian khứ hồi RTT,…Chúng ta sẽ xem xét ở sau đây để giải quyết những vi phạm nguyên lý bảo toàn, cái mà gây ra tắc nghẽn mạng.
Với nguyên nhân thứ nhất, sử dụng thuật toán khởi động chậm (Slow Start) để tăng dần lượng dữ liệu đang được truyền thông trên mạng, nhằm đạt tới sự cân bằng.
Với nguyên nhân thứ hai, phải tính lại thời gian khứ hồi một cách “thông minh”: (adsbygoogle = window.adsbygoogle || []).push({});
• Giải quyết sai lầm thứ nhất: tính ước lượng thời gian khứ hồi bằng một bộ lọc giải thông thấp để tránh cho đại lượng này khỏi thăng giáng quá mạnh nhằm duy trì sự cân bằng: RTT α¬RTT+(1-α)*new_RTT
• Giải quyết sai lầm thứ hai: rút lui theo hàm mũ.
• Với nguyên nhân thứ ba, chiến lược tránh tắc nghẽn sẽ được xem xét, gồm hai thành phần:
o Thứ nhất, mạng phải có khả năng gửi tín hiệu đến cho các thực thể ở đầu cuối của các kết nối, báo cho chúng biết là tắc nghẽn đang xảy ra hoặc sắp xảy ra.
o Thứ hai, các thực thể điểm cuối phải có chính sách giảm lưu lượng đưa vào mạng nếu nhận được các tín hiệu báo và tăng thêm lưu lượng đưa vào mạng nếu không nhận được tín hiệu báo này.
Chính sách của thực thể điểm cuối đối với tắc nghẽn: thích ứng với đường truyền (tăng theo cấp số cộng, giảm theo cấp số nhân).
Phản ứng của mạng đối với điều khiển tắc nghẽn: loại bỏ.