2.4. Một số thuật toán điều khiển lƣu lƣợng trong TCP
Hiện tƣợng tắc nghẽn số liệu biểu hiện rõ nhất bằng việc gia tăng RTT của các gói số liệu khi di chuyển trong mạng, hoặc thực thể TCP phát bị hết giờ (timeout), hoặc thực thể phát nhận đƣợc một số biên nhận lặp... Để hạn chế hiện tƣợng tắc nghẽn số liệu, trong TCP sử dụng các thuật toán điều khiển lƣu lƣợng sau: “Khởi động chậm”, “Tránh tắc nghẽn”, “Phát lại nhanh”, “Khơi phục nhanh”.
2.4.1. Thuật tốn “Khởi động chậm” – SS (Slow Start)
Đặc trƣng của thuật toán “Khởi động chậm” là phải định nghĩa thêm khái niệm “Cửa sổ tắc nghẽn” (congestion window), ký hiệu là cwnd, cho thực thể TCP phát. Một khi kết nối TCP đƣợc thiết lập, cwnd đƣợc gán giá trị bằng 1 (đơn vị kích thƣớc gói tin), có độ lớn đƣợc thông báo bởi thực thể TCP bên nhận, độ dài mặc định là 512 Byte. [RFC 2001]
Thực thể TCP phát bắt đầu phát với cwnd = 1, gửi một gói dữ liệu đầu tiên và đợi biên nhận. Khi nhận đƣợc biên nhận ACK đầu tiên, thực thể phát tăng giá trị cửa sổ cwnd thành 2, gửi 2 gói dữ liệu, và đợi. Khi nhận đƣợc 2 biên nhận tiếp theo, với mỗi biên nhận TCP sẽ gia tăng cửa sổ cwnd thêm 1. Lúc đó
giá trị của cwnd sẽ là 4 và TCP có thể gửi 4 gói tin cùng lúc. Các biên nhận cho các gói tin này sẽ gia tăng cwnd thành 8. Nhƣ vậy chỉ sau 4 vòng (4 * RTT), TCP đã gia tăng cửa sổ cwnd thành 16, cho phép gửi 16 gói tin. Do đó, sau log2N vịng là TCP có thể gửi N gói tin. Q trình trên đƣợc lặp lại cho đến khi thoả mãn một trong các điều kiện sau:
cwnd ssthresh (ssthresh: ngƣỡng chuyển đổi từ giai đoạn khởi động chậm sang giai đoạn tránh tắc nghẽn).
cwnd rwnd (rwnd: kích thƣớc cửa sổ nhận).
Xuất hiện dấu hiệu tắc nghẽn thể hiện qua việc gia tăng của thời gian RTT quá một giới hạn nhất định - RTO (Retransmit Timeout).
Nhận đƣợc biên nhận lặp.
Lúc đó, thực thể phát biết rằng độ lớn của cửa sổ cwnd đã quá lớn, và cần phải có sự điều chỉnh giảm tốc độ phát sao cho phù hợp, nó chuyển sang “pha” tránh tắc nghẽn.
2.4.2. Thuật toán “Tránh tắc nghẽn” – CA (Congestion Avoidance)
Dấu hiệu của hiện tƣợng mất gói tin do tắc nghẽn trên đƣờng truyền end- to-end là thời gian RTT tăng quá mức hoặc bên nhận nhận đƣợc liên tiếp các biên nhận lặp (dup ACK), cụ thể nhƣ sau:
Nếu có gói số liệu bị mất tại một chặng nào đó trên đƣờng truyền trong mạng (do tràn bộ đệm), sẽ dẫn đến việc thực thể gửi TCP bị timeout và phải thực hiện phát lại gói số liệu bị mất.
Nếu thực thể phát nhận đƣợc nhiều biên nhận (ACK) cho cùng một gói tin, điều đó cho biết rằng tại trạm nhận, các gói số liệu đã đến, khơng có lỗi, nhƣng khơng theo đúng thứ tự phát (out-of-order) do đã có một hoặc một số gói tin bị mất do tắc nghẽn trên đƣờng truyền.
Biện pháp tránh tắc nghẽn duy nhất thích hợp là giảm lƣu lƣợng gửi gói tin vào mạng để mạng có thể ra khỏi trạng thái tắc nghẽn. Thuật toán “Bắt đầu
chậm” và thuật toán “Tránh tắc nghẽn” đƣợc phối hợp sử dụng và thƣờng đƣợc cài đặt đồng thời nhƣ một thuật toán. Hoạt động của hai thuật toán đƣợc kết hợp lại nhƣ sau:
Đặt giá trị ban đầu cwnd = 1 và ssthresh = 65.535 Byte.
Thực thể TCP sử dụng cơ chế cửa sổ trƣợt (sliding window) để gửi dữ liệu. Độ lớn của cửa sổ, ký hiệu là W, chính bằng số gói dữ liệu đƣợc gửi liên tục mà không cần chờ thông báo trả lời. Thực thể TCP gửi không bao giờ phát đi số gói tin vƣợt quá một trong hai giá trị là cửa số tắc nghẽn cwnd và cửa sổ nhận rwnd (Receiver Window) đƣợc thông báo bởi bên nhận dữ liệu. Hay nói cách khác: W=min{cwnd, rwnd}.
Khi hiện tƣợng tắc nghẽn xuất hiện, giá trị ssthresh đƣợc điều chỉnh bằng max(2, W/2) và đặt cwnd = 1.
Mỗi khi nhận đƣợc thông báo ACK, tăng giá trị cwnd lên theo 2 cách, tùy thuộc vào giai đoạn và thuật toán nào đang tiến hành:
o Nếu cwnd < ssthesh, thuật toán khởi động chậm đƣợc thực hiện: giá trị của cwnd đƣợc tăng thêm 1 đơn vị với mỗi thông báo biên nhận ACK nhận đƣợc.
o Nếu cwnd = ssthesh, thuật toán tránh tắc nghẽn đƣợc thực hiện: giá trị cwnd đƣợc tăng thêm 1/cwnd với mỗi thông báo ACK nhận đƣợc.
Nhƣ vậy, khi phát hiện tắc nghẽn, tốc độ mở cửa sổ phát đƣợc điều chỉnh dần dần một cách tuyến tính, trong khi ở thuật tốn bắt đầu chậm (trong trƣờng hợp không tắc nghẽn) tốc độ mở cửa sổ phát tăng theo hàm mũ. Điều này đảm bảo cho TCP khả năng nhanh chóng sử dụng đƣợc hết dải thơng cịn “rỗi” trong pha khởi động chậm và tiếp tục thăm dị phần dải thơng cịn có thể sử dụng đƣợc trong pha tránh tắc nghẽn mà khơng làm cho tình trạng tắc nghẽn thêm trầm trọng.
2.4.3. Thuật toán “Phát lại nhanh” – FRTX (Fast Retransmit)
Thực thể gửi TCP cần thực hiện phát lại một gói số liệu khi nhận biết đƣợc có gói tin bị mất hoặc đƣợc đồng hồ quản lý phát lại kích hoạt (timeout). Thuật tốn phát lại nhanh cho phép thực thể phát thực hiện phát lại không cần chờ đồng hồ “timeout”, trong trƣờng hợp nhận đƣợc nhiều hơn hai thông báo ACK lặp lại.
Thông báo ACK lặp lại đƣợc tạo ra trong trƣờng hợp thực thể nhận thơng báo gói số liệu đến khơng đúng theo thứ tự phát và nêu ra số thứ tự gói số liệu chờ nhận. Trong thực tế, thƣờng chỉ cần từ một đến hai thông báo ACK lặp lại là đủ thời gian để gói số liệu bị lạc đến đích và đƣợc xử lý đúng thứ tự. Nếu thực thể phát nhận đƣợc nhiều hơn hai thơng báo ACK lặp thì thực thể phát có cơ sở (khá chắc chắn) để cho rằng gói số liệu đó đã bị mất và cần phát lại nhanh chóng gói số liệu bị mất đó. Sau khi phát lại nhanh, thực thể phát trở về pha “Khởi động chậm” (cwnd=1).
2.4.4. Thuật tốn “Khơi phục nhanh” – FRCV (Fast Recovery)
Thuật tốn khơi phục nhanh quy định việc thực hiện thuật toán tránh tắc nghẽn ngay sau khi thực hiện thuật tốn phát lại nhanh, chứ khơng trở về pha “Khởi động chậm”. Điều này tránh cho lƣu lƣợng số liệu trong kết nối TCP khơng bị giảm đột ngột, gây lãng phí dải thơng của đƣờng truyền.
Thuật tốn phát lại nhanh và khôi phục nhanh thƣờng đƣợc cài đặt kết hợp với nhau nhƣ sau:
(i) Sau khi nhận đƣợc biên nhận ACK lặp thứ 3 liên tiếp, thực thể phát kết luận rằng gói số liệu đó đã bị mất nên phát lại gói số liệu bị mất đó chứ khơng chờ cho đến khi bị timeout, sau đó thiết lập ngƣỡng ssthresh = max(2, cwnd/2).
Khác với FRTX, sau khi phát lại gói số liệu bị mất sẽ trở về pha “Khởi động chậm” bằng cách đặt cwnd=1. Trong FRCV, sau khi
phát lại gói số liệu bị mất, thực thể phát sẽ tăng cwnd=ssthresh + 3. Điều này có nghĩa là cwnd đƣợc tăng lên thêm ba gói số liệu tƣơng ứng với ba gói số liệu đã rời mạng (thực chất là ba gói số liệu đã đƣợc nhận trong bộ đệm của thực thể nhận, tƣơng ứng với ba thông báo ACK lặp).
(ii) Với mỗi thông báo ACK lặp tiếp theo, tăng cwnd = cwnd + 1, tƣơng ứng với một gói số liệu đã đƣợc nhận đúng và đi ra khỏi mạng.
Thực hiện việc phát một gói số liệu, nếu cwnd và rwnd có giá trị mới và cửa sổ phát W vẫn chƣa lớn hơn min{cwnd, rwnd}.
(iii) Sau khi nhận đƣợc báo nhận ACK của gói dữ liệu bị mất và đã
đƣợc phát lại ở bƣớc (i), thực thể phát TCP thiết lập lại cửa sổ cwnd đƣợc giữ trong trƣờng ssthresh sau đó kết thúc thuật tốn.
2.5. Các phiên bản của giao thức TCP
2.5.1. Tahoe
Giao thức TCP ngun thuỷ ban đầu sử dụng mơ hình go-back-n (phát lại từ gói tin thứ n) [3], trong mơ hình này khi bên nhận phát hiện ra gói tin thu đƣợc khơng đúng thứ tự, bên nhận sẽ thông báo cho bên gửi phát lại các gói tin từ gói tin nhận khơng đúng thứ tự đó [31].
Tahoe TCP là phiên bản TCP đã đƣợc cải tiến, sử dụng các thuật toán Slow-Start, Congestion Avoidance và Fast Retransmit. Giao thức này còn bao gồm một sự sửa đổi bộ ƣớc lƣợng thời gian khứ hồi đƣợc sử dụng để thiết lập giá trị hết giờ phát lạị, đây là một cải tiến rất hiệu quả. Với Fast Retransmit, các nhà phát triển lập luận rằng sau khi nhận đƣợc một số lƣợng nhỏ các biên nhận lặp của cùng một gói tin TCP, bên phát dữ liệu kết luận rằng một gói dữ liệu đã bị mất và quyết định phát lại không chờ hết giờ đồng hồ phát lại. Thuật toán
này đã cải thiện một cách rõ rệt hiệu suất của Tahoe TCP so với TCP thông thƣờng [30].
2.5.2. Reno
Cài đặt của Reno TCP giữ lại những cải tiến đã đƣợc sử dụng trong Tahoe nhƣng sửa đổi quá trình phát lại nhanh bằng cách bổ sung thêm thuật tốn khơi phục nhanh (FRCV), đƣợc thực hiện ngay sau thuật toán phát lại nhanh (FRTX). Thuật toán tránh phải sử dụng Slow-Start để đổ đầy đƣờng truyền sau khi mất một gói tin, qua đó nâng cao hiệu suất sử dụng đƣờng truyền.
Trong Reno, bên TCP phát có kích thƣớc sổ phát dữ liệu = min(rwnd, cwnd+ndup) trong đó rwnd (receiver window) là kích thƣớc cửa sổ báo nhận do bên TCP nhận thơng báo, cwnd là kích thƣớc cửa sổ tắc nghẽn bên gửi. Tham số ndup luôn đƣợc gán giá trị bằng 0, ngƣỡng tcprexmtthresh (tcp retransmit
threshold) đƣợc gán giá trị bằng 3. Khi số lƣợng các biên nhận lặp đạt ngƣỡng
tcprexmtthresh thì ndup mới bắt đầu đếm số biên nhập lặp tiếp tục đến. Theo
đó, trong q trình Fast Recovery bên gửi mở rộng dần cửa sổ tắc nghẽn lên cùng với số biên nhận lặp đã nhận đƣợc, với giả thuyết là mỗi biên nhận lặp nhận đƣợc đồng nghĩa với việc có một gói tin đã ra khỏi mạng. Sau khi bƣớc vào quá trình Fast Recovery và phát lại gói tin bị mất, bên gửi sẽ tối ƣu việc chờ đợi cho tới khi nhận đƣợc biên nhận cho một nửa số gói tin của cửa sổ có biên nhận lặp, và sau đó gửi đi một gói tin mỗi khi nhận đƣợc thêm một biên nhận lặp. Khi nhận đƣợc biên nhận cho gói tin khác, khơng phải gói tin đƣợc phát lại trong Fast Recovery và đƣợc gọi là “biên nhận phục hồi”, Reno TCP biết rằng gói tin phát lại đã đƣợc nhận. Căn cứ vào “biên nhận phục hồi”, bên phát ngừng quá trình Fast Recovery bằng cách đặt ndup bằng 0.
Thuật toán Fast Recovery cài đặt trong Reno TCP đƣợc thiết kế để tối ƣu hóa hiệu suất sử dụng đƣờng truyền của TCP trong trƣờng hợp chỉ có một gói
tin của cửa sổ phát bị loại bỏ. Bên gửi chỉ phát lại nhiều nhất một gói tin bị mất trong mỗi chu kì thời gian khứ hồi. Tuy nhiên, Reno có thể vấp phải một số vấn đề về hiệu suất trong trƣờng hợp có nhiều gói dữ liệu bị mất trong cùng một cửa số phát. Trong trƣờng hợp một cửa sổ phát có nhiều gói dữ liệu bị mất thì Reno TCP chỉ có thể phát lại một gói dữ liệu bị mất bằng thuật tốn Fast Recovery, sau đó kết thúc Fast Recovery, do đó hiệu suất sử dụng đƣờng truyền suy giảm. Nhƣợc điểm trên sẽ đƣợc khắc phục trong phiên bản New-Reno TCP.
2.5.3. New-Reno
Phiên bản New-Reno cải tiến cách thức thực hiện Fast Recovery và tránh tắc nghẽn của Reno, giúp cho nó có thể khắc phục đƣợc một số nhƣợc điểm của Reno mà không cần phải sử dụng đến SACK. Kiểu cài đặt này của TCP loại bỏ thời gian chờ hết giờ của đồng hồ phát lại của Reno khi có nhiều gói tin bị loại bỏ trong một cửa sổ. Điểm khác biệt là cách xử lý của bên gửi trong quá trình Fast Recovery khi nhận đƣợc một biên nhận cục bộ (Partial ACK). Biên nhận cục bộ là một biên nhận mới, nhận đƣợc sau khi thực hiện Fast Recovery, biên nhận này có số thứ tự nhỏ hơn số thứ tự của gói tin cuối cùng đã truyền khi thực hiện Fast Recovery. Việc nhận đƣợc biên nhận cục bộ có nghĩa là chỉ biên nhận cho một số chứ khơng phải tất cả các gói tin đã gửi từ khi bắt đầu thực hiện quá trình Fast Recovery.
Trong New-Reno các biên nhận cục bộ không ảnh hƣởng đến quá trình Fast Recovery, các biên nhận cục bộ trong quá trình Fast Recovery đƣợc xem nhƣ dấu hiệu cho biết gói tin ngay sau gói tin đã đƣợc biên nhận đúng thứ tự đã bị mất và cần đƣợc phát lại. Do đó, khi nhiều gói tin trong cùng cửa sổ bị mất, New-Reno có thể phát lại ngay chứ khơng chờ hết giờ. Mỗi gói số liệu bị mất đƣợc phát lại trong khoảng thời gian khứ hồi cho đến khi tất cả các gói số liệu bị mất trong cùng cửa sổ đã đƣợc phát lại hết. New-Reno tiếp tục ở trong quá
trình Fast Recovery cho đến khi tất cả các gói dữ liệu đƣợc gửi từ khi bắt đầu thực hiện Fast Recovery đƣợc biên nhận.
2.5.4. SACK TCP
Phiên bản SACK TCP đƣợc thiết kế nhằm nhanh chóng phát lại các gói tin bị mất trong một khoảng thời gian RTT, qua đó làm tăng hiệu suất sử dụng TCP.
Trong SACK TCP (Selective ACKnowledgement TCP), trƣờng tuỳ chọn SACK chứa đựng một số lƣợng các khối SACK, trong đó mỗi khối SACK xác định các gói tin (thực chất là khối byte số liệu) đã nhận đƣợc và đang nằm ở bộ nhớ đệm phía nhận. Điều này đồng nghĩa với việc bên gửi sẽ xác định đƣợc các gói tin nào chƣa nhận đƣợc và cần phải gửi lại.
Chi tiết về SACK TCP sẽ đƣợc thảo luận ở chƣơng 3, mục 3.2.
2.6 Ƣu điểm của TCP trong mạng truyền thông
Trong các mạng truyền thống, giao thức TCP đã chứng tỏ là một giao thức có nhiều ƣu điểm, các ƣu điểm chính bao gồm:
Tự thích ứng với trạng thái đƣờng truyền: TCP có thể tự thích nghi với trạng thái của đƣờng truyền (tỉ lệ dải thông đã sử dụng, mức độ tắc nghẽn, …) để thực hiện việc truyền dữ liệu cho thích hợp.
Sử dụng hữu hiệu đƣờng truyền: TCP tận dụng đƣợc tối đa băng thông của đƣờng truyền bằng cách tự điều chỉnh cửa sổ phát dữ liệu cho phù hợp.
Chia sẻ công bằng đƣờng truyền: Khi có nhiều kết nối TCP qua một đƣờng truyền vật lý, các kết nối này sẽ cùng nhau chia sẻ công bằng đƣờng truyền.
Chƣơng 3 - CÁC GIẢI PHÁP CẢI THIỆN HIỆU SUẤT TCP TRONG MẠNG CÓ ĐƢỜNG TRUYỀN VỆ TINH
Nhƣ đã đề cập đến trong chƣơng một, truyền thơng vệ tinh có rất nhiều ƣu điểm mà không loại đƣờng truyền nào có đƣợc nhƣ vùng phủ sóng rộng, băng thông lớn. Tuy nhiên đƣờng truyền vệ tinh cũng có những nhƣợc điểm khơng nhỏ, đó là tỷ suất lỗi cao, trễ đƣờng truyền lớn… Để truyền thông vệ tinh đạt hiệu quả cao, cần phải có các giải pháp hạn chế những nhƣợc điểm nêu trên. Trong chƣơng này đề cập tới các giải pháp thƣờng đƣợc sử dụng để nâng cao hiệu suất đƣờng truyền vệ tinh, bao gồm sửa lỗi phía trƣớc - FEC (Forward Error Correction), SACK và TCP SACK, TCP HACK (HeAder ChecKsum option) và TCP Trunk.
3.1. Sửa lỗi phía trƣớc - FEC (Forward Error Correction)
Khi dữ liệu đƣợc truyền, các tín hiệu đại diện luồng bit rất dễ bị thay đổi do sự tác động của nhiễu điện từ trong mơi trƣờng bên ngồi, tức là các tín hiệu đại diện cho bit 1 bị máy thu dịch ra thành bit nhị phân 0 và ngƣợc lại, thậm chí tín hiệu có thể bị biến mất hồn tồn. Để việc truyền dữ liệu đƣợc chính xác cần phải có biện pháp để bên thu có khả năng biết đƣợc dữ liệu thu đƣợc có chứa lỗi hay khơng. Hơn nữa, nếu phát hiện đƣợc lỗi có khả năng sửa lỗi.
Có hai cách tiếp cận cho vấn đề này:
Sửa lỗi theo phản hồi (Feedback Error Correction): mỗi ký tự hay Frame dữ liệu đƣợc truyền chỉ đƣợc bổ sung một lƣợng thông tin đủ cho máy