Các phiên bản của giao thức TCP

Một phần của tài liệu Các cải tiến TCP cho đường truyền vệ tinh (Trang 40 - 43)

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 quá 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.

Một phần của tài liệu Các cải tiến TCP cho đường truyền vệ tinh (Trang 40 - 43)

Tải bản đầy đủ (PDF)

(84 trang)