Điều khiển lưu lượng trong giao thức TCP

c thể gửi hiểu được là tắc nghẽn đã xảy ra và nó tính lại thời gian phát gói tin để truyền một cách thích hợp nhất. Thứ hai: các endpoint 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 endpoint đối với tắc nghẽn: thích ứng với đường truyền. Khi nhận được tín hiệu báo là có tắc nghẽn xảy ra các thực thể giảm lưu lượng đi vào. Phản ứng của các nốt (node): tăng theo cấp số cộng, tắc nghẽn xảy ra thì giảm theo cấp số nhân (kích thước cửa sổ giảm một nửa). Phản ứng của mạng đối với điều khiển tắc nghẽn: loại bỏ Thuật toán tránh tắc nghẽn như sau: Với mỗi time-out, đặt cwnd tới một nửa kích thước cửa sổ hiện tại (đây được xem là sự giảm theo cấp số nhân, multiplicative decrease). Với mỗi ACK cho dữ liệu mới, tăng cwnd bởi 1/cwnd (đây được xem là sự tăng theo cấp số cộng (additive increase). Khi gửi, chỉ gửi lượng nhỏ nhất của cửa sổ đã thông báo của người nhận và cwnd. Thuật toán khởi động chậm và tránh tắc nghẽn là những kỹ thuật điều khiển lưu lượng, tránh tắc nghẽn số liệu hoạt động độc lập, song có quan hệ mật thiết với nhau và thường được cài đặt cùng nhau. Hoạt động của hai giải pháp kết hợp này như sau: Đặt giá trị ban đầu cwnd=1 đơn vị gói tin và ssthresh=65.535 byte, trong đó ssthresh là ngưỡng trên của thuật toán khởi động chậm. Thực thể TCP không bao giờ phát nhiều hơn giá trị cửa sổ tối thiểu của cwnd và độ lớn của cửa sổ thu rwnd được thực thể thu thông báo trước đó: w=min(cwnd,rwnd). Khi hiện tượng tắc nghẽn số liệu xuất hiện, đặt giá trị cửa sổ w/2 lưu giữ trong trường ssthresh và đặt cwnd=1 đơn vị gói tin. Mỗi khi nhận được thông báo ACK, giá trị cwnd được tăng lên, phụ thuộc vào thuật toán khởi động chậm hay thuật toán tránh tắc nghẽn được thực hiện: Nếu cwnd<ssthresh, thuật toán khởi động chậm được thực hiện: giá trị cwnd được tăng lên 1 đơn vị gói tin với mỗi thông báo ACK nhận được. Ngược lại, nếu cwnd=ssthresh,, thuật toán tránh tắc nghẽn được thực hiện: giá trị cwnd được tăng lên1/cwnd với mỗi thông báo ACK nhận được Chúng ta có thể xem xét việc cài đặt hoạt động kết hợp của hai thuật toán như ở dưới: Hình 18. Hoạt động kết hợp của Slow Start và Congestion Avoidance Có thể thấy độ gia tăng giá trị của cửa sổ phát trong trường hợp điều khiển tránh tắc nghẽn là tuyến tính, trong khi ở thuật toán khởi động chậm (không có tắc nghẽn) là tăng theo hàm số mũ. Điều này đảm bảo tận dụng băng thông được cấp phát, tăng hiệu suất trao đổi số liệu trên kết nối TCP khi áp dụng thuật toán khởi động chậm và vẫn phòng tránh có hiệu quả khi hiện tượng tắc nghẽn số liệu xuất hiện. 2.3.2.3 Thuật toán “phát lại nhanh”. Thông thường, thực thể TCP thực hiện phát lại một gói tin khi nhận được thông báo thu sai, hoặc được đồng hồ quảnlý phát lại kích hoạt (time-out). Thuật toán “phát lại nhanh” (fast retransmission) cho phép thực thể phát thực hiện phát lại không cần chờ đồng hồ time-out, trong trường hợp nhận được nhiều hơn ba thông báo ACK lặp lại, (duplicated ACK). 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 tin đến không đúng theo thứ tự phát (out-of-order) và nêu số thứ tự gói tin 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à đủ để gói tin “bị lạc” đến và được xử lý đúng thứ tự.nếu thực thể phát nhận được nhiều hơn ba thông báo ACK lặp lại thì điều đó đồng nghĩa với việc gói tin bị mất (packet loss) và trong trường hợp này, gói tin đó cần được phát lại nhanh. 2.3.2.4 Thuật toán “khôi phục nhanh”. Thuật toán khôi phục nhanh (fast recovery) 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 phát lại nhanh. Điều này tránh cho lưu lượng số liệu trong kết nối TCP không bị thay đổi đột ngột- nếu thực hiện thuật toán khởi động chậm- và đảm bảo thông lượng số liệu được phù hợp với bối cảnh thực tế: việc phát, thu có lỗi. Thuật toán phát lại nhanh và khôi phục nhanh thường được cài đặt cùng nhau như sau: Sau khi nhận được ba thông báo ACK lặp lại liên tiếp nhau, thực thể phát thiết lập ssthresh=cwnd/2 (không nhỏ hơn hai đơn vị gói tin SMSS) và phát lại gói tin bị mất; Tăng cwnd=cwnd+3*SMSS. Điều này cho phép tăng “nhân tạo” cửa sổ phát cwnd tương ứng với ba gói tin đã rời khỏi mạng, hay nói cách khác: chúng không còn chiếm giữ tài nguyên của mạng (thực chất là: ba gói tin đã 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 lại). Với mỗi thông báo ACK lặp lại, tăng cwnd=cwnd+1*SMSS, tương ứng với một gói tin được phát vào mạng (và như được lưu giữ trong bộ đệm của thực thể nhận). Thực hiện phát một gói tin, nếu thoả mãn w=min(cwnd,rwnd); Sau khi nhận được thông báo trả lời ACK không bị lặp lại nghĩa là thông báo về số gói tin nhận được đúng trong khoảng thời gian cho đến thời điểm đó. Đặt w(t)=ssthresh (bước1) và kết thúc thuật toán. Như vậy, việc phát lại nhanh (fash retransmission) được thực thi ngay sau ba biên nhận lặp được nhận, nó tránh được việc phải đợi time-out và không cần phải thực thi Slow Start mà quy định ngay việc thực thi của congestion avoidance điều này tránh cho băng thông bị giảm đột ngột, không tận dụng được đường truyền, khi này, cwnd sẽ dao động xung quanh một giá trị kích thước cửa sổ tối ưu. TCP thực thi các cơ chế điều khiển lưu lượng cũng như tắc nghẽn mạng trong khi vẫn giữ vững, duy trì hiệu suất người dùng tốt. Các sự thực thi trước đó theo mô hình go-back-n, sử dụng biên nhận xác thực tích luỹ và đòi hỏi một sự mãn hạn bộ thời gian truyền lại để gửi lại dữ liệu đã mất trong khi chuyển vận. Các sự thực thi TCP này đã thực hiện được chút ít trong việc hạn chế sự tắc nghẽn mạng của mình. 2.4. Các cơ chế thực thi TCP 2.4.1. Việc áp dụng cơ chế điều khiển lưu lượng trong phiên bản TCP đầu tiên là: Tahoe TCP Tahoe TCP thêm vao các thuật toán mới, cũng như tự tinh chế và làm cho nó thực thi tốt hơn so với TCP trước đó. Các thuật toán được thêm vào bao gồm: Slow Start, congestion avoidance, và fast retransmiss. Tahoe TCP còn tinh chế bộ ước lượng RTT được sử dụng để thiết lập các giá trị time-out chuyển vận lại. Thuật toán phát lại nhanh là sự quan tâm đặc biệt trong sự thực thi này. Với thuật toán này, sau khi nhận được một số lượng nhỏ của các biên nhận lặp cho cùng một TCP segment, người gửi sẽ kết luận rằng một gói tin đã bị thất lạc và sẽ gửi lại gói tin ấy mà không phải chờ cho đến khi bộ thời gian chuyển vận lại hết hạn, điều đó làm cho hiệu suất kết nối và sử dụng kênh truyền được nâng cao. Như vậy, nếu trên mạng xảy ra hiện tượng mất mát gói tin, người gửi sẽ gửi lại dữ liệu sau khi nhận được ba biên nhận lặp, tránh phải đợi time-out, và việc khởi đầu lại được bắt đầu với Slow Start. Hình vẽ 19 cho thấy hoạt động của Tahoe TCP: Hình 19. Hoạt động của Tahoe TCP Với kết qủa mô phỏng như hình 20 sau: Hình 20. Tahoe TCP với một gói tin bị loại bỏ Ở dưới cho trường hợp có một gói tin bị loại bỏ từ cửa sổ dữ liệu, Tahoe TCP sử dụng thuật toán Slow Start để khôi phục lại từ một gói tin bị mất mát. Như trên hình 20, các gói tin từ 0 đến 13 được gửi đi và không có lỗi xảy ra khi cửa sổ tắc nghẽn TCP được người gửi tăng theo hàm mũ từ 1 đến 15, phụ thuộc theo thuật toán Slow Start. Vào lúc cuối của cửa sổ dữ liệu lần gửi thứ tư (lúc này kích thước cửa sổ đã tăng lên đến 8), xảy ra hiện tượng mất mát gói tin do hàng đợi của bộ định tuyến bị đầy, nó là nguyên nhân làm cho gói 14 bị loại bỏ (dropped). Bởi vì bẩy gói trước đó của cửa sổ dữ liệu lần gửi thứ tư đã được phân phát thành công, khi bảy ACKs đã về tới người gửi, kích thước cửa sổ người gửi sẽ tăng lên từ 8 đến 15 và tiếp tục gửi đi 14 gói nữa, từ 15 đến 28. Sau khi nhận ACK đầu tiên của gói tin 13, người nhận gửi nhận 14 biên nhận lặp ACK cho gói tin 13 tương ứng với việc nhận thành công các gói tin từ 15 đến 28 của người nhận. Biên nhận lặp ACK thứ ba đã đạt tới ngưỡng, và thuật toán Retransmission và Slow Start được gọi đến. Thêm nữa, ngưỡng Slow Start, ssthresh, được giảm giá trị thành 7 tức ((8+7)/2). TCP người gửi thiết lập lại cửa sổ tắc nghẽn tới 1 và gửi lại gói tin 14. Người nhận đã nhận được các gói tin từ 15 đến 28, và nhận gói tin 14 đã được gửi lại. Biên nhận cho gói 28 là nguyên nhân làm cho người gửi tăng lên cửa sổ tắc nghẽn bởi 1 và tiếp tục truyền số liệu từ gói 29. Trong khi truyền , khi cửa sổ bắt đầu với gói tin 35, ngưòi gửi đạt tới ngưỡng trên của thuật toán Slow Start và bắt đầu tiến hành thuật toán tránh tắc nghẽn (congestion avoidance). Trong suốt việc truyền thông sau đó, cửa sổ người gửi được tăng lên bởi một gói tin qua mỗi khoảng thời gian khứ hồi round-trip-time. Hình 21 cho chúng ta thấy rõ hơn các quá trình hoạt động ở trên: Hình 21. Hoạt động chi tiết của Tahoe TCP với một gói tin bị loại bỏ 2.4.2. Các cải tiến của giao thức TCP 2.4.2.1 Reno, new-Reno, SACK v.v. Cho mạng truyền thông có dây Reno TCP: Reno TCP đã giữ lại những điểm nổi bật hợp thành lên Tahoe TCP nhưng đã sửa thuật toán phát lại nhanh để thêm vào thuật toán khôi phục nhanh. Thuật toán mới này ngăn chặn đường truyền thông sẽ bị rỗng sau khi phát lại nhanh (do bắt đầu Slow Start lại), vì thế tránh được việc cần thiết phải có thuật toán Slow Start để làm đầy lại đường truyền thông sau khi xảy ra sự mất mát của gói tin. Khôi phục nhanh (fast recovery) hoạt động bằng cách giả thiết rằng mỗi biên nhận lặp ACK đã nhận, sẽ đại diện cho một gói tin đã vừa ra khỏi đường truyền thông. Do đó, trong suốt thời gian khôi phục nhanh, người gửi có thể thực hiện những ước lượng thông minh về khối lượng dữ liệu còn tồn tại. Fast recovery được đưa vào bởi TCP người gửi sau khi nhận một ngưỡng khởi tạo của cácc biên nhận lặp. Giá trị ngưỡng này thường được biết đến như là tcprexmtthresh, thường được gán giá trị bằng 3. Khi giá trị ngưỡng của các biên nhận lặp được nhận, người gửi truyền lại một gói và giảm bớt cửa sổ tắc nghẽn của mình xuống một nửa. Thay vì Slow Start, như được thực hiện bởi người gửi ở Tahoe TCP, người gửi Reno TCP sử dụng các biên nhận lặp mới đến thêm vào để điểm giờ cho các gói tin sắp đi ra tiếp sau. Sau đây là sơ đồ hoạt động của Reno TCP: Hình 22. Hoạt động của Reno TCP Trong hoạt động của Reno TCP, cửa sổ có thể sử dụng được của người gửi trở thành min(awin,cwnd+ndup), ở đây awin là cửa sổ đã thông báo của người nhận, cwnd là cửa sổ tắc nghẽn của người gửi,và ndup được duy trì tại 0 cho đến khi số lượng các biên nhận lặp đạt tới tcprexmtthresh, và sau đó theo dõi số lượng của các biên nhận lặp. Do đó, trong giai đoạn fast recovery người gửi tăng thêm cửa sổ của mình bằng số lượng của các biên nhận lặp mà nó đã vừa nhận, phụ thuộc vào sự theo dõi mỗi biên nhận lặp đó và chỉ ra vài gói tin đã bị đi ra khỏi mạng và đón được tại phía người nhận.sau khi đưa vào thuật toán fast recovery và gửi lại một gói đơn lẻ, người gửi chờ cho đến khi một nửa cửa sổ của các biên nhận lặp được nhận, và rồi gửi một gói tin mới cho mỗi biên nhận lặp thêm vào mà đã được nhận. Cho đến khi nhận một biên nhận ACK cho một gói tin mới (được gọi là biên nhận phục hồi, “recovery ACK”), người gửi thoát khỏi fast recovery bằng cách đặt ndup tới 0. Hình 23. Reno TCP với một gói tin bị loại bỏ Với Reno TCP, thuật toán fast recovery của nó đưa đến sự thực thi tối ưu trong khuôn cảnh này. Cửa sổ tắc nghẽn người gửi bị giảm xuống một nửa, các biên nhận lặp mới đến đã được sử dụng để điểm giờ cho các gói tin sắp đi ra, nó tránh được Slow Start. Các hoạt động của Reno như trên là giống với Tahoe cho đến khi biên nhận thứ tư cho gói tin 13 được nhận ở người gửi. Các biên nhận tương ứng với các gói từ 15 đến 28 bao gồm 14 biên nhận lặp cho gói tin 13. Biên nhận lặp thứ ba gây ra việc truyền lại của gói tin 14, làm cho người gửi phải dùng đến fast recovery, và giảm cửa sổ tắc nghẽn của nó xuống, ngưỡng Slow Start được đặt tới bẩy. Trong giai đoạn fast recovery, việc nhận biên nhận lặp thứ tư đưa cửa sổ có thể sử dụng được đến 11, và bởi biên nhận lặp thứ 14 cửa sổ có thể sử dụng được đạt đến 21. Cửa sổ đã tăng thêm từ sáu biên nhận lặp vừa rồi cho phép ngưòi gửi gửi các gói tin từ 29 đến 34. Cho đến khi biên nhận cho gói 28, người gửi thoát khỏi fast recovery và tiếp tục thực hiện congestion avoidance với cửa sổ tắc nghẽn là bảy. Quá trình hoạt động của nó được thể hiện trên hình 24. Hình 24. Hoạt động chi tiết của Reno TCP với một gói tin bị loại bỏ New-Reno New-Reno có một sửa đổi nhỏ trong thuật toán frcv để cải thiện hiệu năng trong trường hợp một cửa sổ có trên một gói số liệu bị loại. Sự thay đổi liên quan đến hành vi của bên gửi trong quá tình thực hiện frcv, khi nhận được một biên nhận một phần (partial ACK), đó là một biên nhận mới, nhận được sau khi thực hiện phát lại nhanh, biên nhận này có số thứ tự nhỏ hơn số thứ tự của byte cuối cùng đã truyền khi thực hiện phát lại nhanh. Mỗi biên nhận từng phần biên nhận cho một số chứ không phải là tất cả các gói số liệu đã đi vào trong mạng từ khi bắt đầu giai đoạn frcv, do đó nó chỉ ra việc có nhiều gói số liệu bị mất trong một cửa sổ phát. Trong Reno TCP, biên nhận từng phần không làm cho TCP ra khỏi giai đoạn frcv, ngược lại, việc nhận được các biên nhận từng phần được coi như là một tín hiệu báo rằng gói số liệu đi sau (có thứ tự tiếp theo) gói số liệu được biên nhận đã bị mất và nó cần được truyền lại. Như vậy, khi trong một cửa sổ có nhiều gói số liệu bị mất, new-Reno có thể phát lại ngay chứ không bị 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 sẽ vẫn ở trong trạng thái frcv cho đến khi mọi gói số liệu được gửi đi từ khi bắt đầu thực hiện frcv được nhận hết. Hình 25. Hoạt động của New Reno TCP, trường hợp có ba gói số liệu bị loại bỏ Trường hợp trong một cửa sổ chỉ có một gói số liệu bị loại, hoạt động của new-Reno và Reno là giống nhau. Hình 25 minh hoạ sự hoạt động của new-Reno trong trường hợp có ba gói số liệu bị loại. SACK TCP Trong SACK TCP (Selective ACKnowledgement TCP) mỗi segment có chứa một trường tuỳ chọn SACK, trường này gồm một số khối SACK, mỗi khối chứa các thông tin về một khối dữ liệu đã được nhận, nhưng không đúng thứ tự, đang được bên nhận chứa trong bộ đệm. Khối SACK thứ nhất chứa thông tin về gói số liệu nhận được mới nhất, khối SACK thứ hai cũng chứa các thông tin như vậy. Việc bổ sung tuỳ chọn SACK vào giao thức TCP không làm thay đổi cơ chế điều khiển tắc nghẽn bên trong của nó, SACK TCP vẫn bảo toàn được các đặc tính của Tahoe và Reno TCP là mạnh trong trường hợp có các gói số liệu đến không đúng thứ tự, nó sử dụng cơ chế phát lại khi bị hết giờ như giải pháp cuối cùng. Hình 26 minh hoạ sự hoạt động của SACK TCP trong trường hợp có ba gói số liệu bị loại. Hình 26. Hoạt động của SACK TCP, trường hợp có ba gói số liệu bị mất SACK TCP giống Reno TCP ở chỗ: SACK TCP đi vào giai đoạn frcv khi bên gửi nhận được số biên nhận lặp bằng tcprexmtthresh; bên gửi sẽ phát lại gói số liệu và giảm cwnd xuống còn một nửa. SACK TCP khác Reno TCP ở chỗ: trong khi thực hiện frcv, SACK TCP duy trì một biến được gọi là pipe. Biến này biểu diễn ước lượng số gói số liệu đã gửi vào mạng nhưng chưa có biên nhận. Bên gửi chỉ gửi dữ liệu mới hoặc phát lại khi ước lượng nói trên nhỏ hơn cửa sổ tắc nghẽn cwnd. Biến pipe sẽ được tăng thêm một mỗi khi bên gửi phát đi một gói số liệu mới hoặc phát lại một gói số liệu cũ, nó giảm đi một khi bên gửi nhận được một gói số liệu biên nhận lặp, trong đó trường tuỳ chọn SACK cho biết rằng bên nhận đã nhận được dữ liệu mới. Trong trường hợp một cửa sổ có không quá một gói số liệu bị loại, hoạt động của SACK TCP cũng giống như Reno và new-Reno TCP. SACK TCP khác Reno TCP một cách căn bản khi nhiều gói số liệu trong một cửa sổ bị loại. Nhận xét các biện pháp thực thi TCP: Hiệu suất của Tahoe TCP không bị giảm quá mạnh khi tỉ lệ gói tin hỏng tăng. Reno TCP có hiệu suất cao hơn hẳn Tahoe TCP khi trong một cửa sổ có một gói số liệu bị loại. Số gói số liệu bị loại trong một cửa sổ càng tăng thì hiệu suất của Reno TCP càng tồi. Ngay cả trường hợp trong một cửa sổ có hai gói số liệu bị loại, hiệu suất của Reno TCP đã thấp hơn hiệu suất của Tahoe TCP nhiều. New-Reno và SACK TCP có hiệu suất cao hơn Tahoe và Reno khi số gói số liệu bị loại trong một cửa sổ lớn hơn một. Khi số gói số liệu trong một cửa sổ bị loại tăng lên trên hai, SACK TCP có hiệu suất cao hơn new-Reno TCP. Đó là vì new-Reno chỉ có thể phát lại nhiều nhất là một gói số liệu bị loại trong mỗi khoảng thời gian khứ hồi, gây ra sự trễ lớn trong việc phát lại các gói số liệu bị loại tiếp theo trong cùng cửa sổ. 2.4.2.2 Sơ qua các cải tiến giao thức TCP cho mạng không dây Indirect TCP (I-TCP) TCP gián tiếp (Indirect TCP): theo cơ chế này, kết nối TCP từ người gửi sẽ kết thúc tại đầu vào đường truyền hay gây lỗi, nơi đặt agent TCP, agent sẽ biên nhận các gói số liệu mà nó nhận được và chịu trách nhiệm gửi nó đến đích. Trên đường truyền không dây, nơi có tỉ suất lỗi bit cao và thất thường, một kết nối TCP được tinh chỉnh cho phù hợp với đặc điểm của đường truyền này sẽ được thiết lập. Ngoài kết nối TCP, tại đây, cũng có thể sử dụng một giao thức giao vận khác. Nhược điểm của I-TCP là làm mất ngữ nghĩa đầu cuối- đầu cuối của giao thức TCP, nút trung gian (trong đó có agent TCP) gửi biên nhận thay cho người nhận, do đó biên nhận có thể đến người gửi trước khi gói số liệu thực sự đến người nhận. Ngoài ra, I-TCP cũng gây khó khăn cho các trạm cơ sở, vì chúng phải chuyển cho nhau một lượng lớn thông tin trạng thái khi xảy ra việc chuyển cuộc gọi. Snoop TCP Cơ chế thực hiện agent TCP thứ hai này tôn trọng ngữ nghĩa “end-to-end”. Agent nằm giữa hai mạng không chia đôi kết nối TCP, nó chỉ giữ bản sao các gói số liệu chứ không tự sinh ra các biên nhận. Các biên nhận không phải là lặp mà bên nhận gửi lại sẽ được agent chuyển tiếp tới cho bên gửi, còn các biên nhận lặp sẽ bị chặn lại, tránh cho bên gửi chuyển sang pha phát lại nhanh. Khi nhận được biên nhận lặp thứ ba, hoặc khi agent đã đợi quá một khoảng thời gian hết giờ cục bộ, gói số liệu tương ứng sẽ được agent phát lại. Thời gian hết giờ cục bộ này phải được xác định phù hợp với đường truyền không dây chỉ có một chặng, nó đương nhiên là nhỏ hơn thời gian hết giờ mà bên người gửi (nguồn) sử dụng. Về thực chất, giải pháp Snoop-TCP cũng giống giải pháp phát lại ở tầng liên kết dữ liệu, vì vậy, chúng cũng còn có tên gọi là “phát lại ở tầng liên kết có sự nhận biết TCP” (TCP aware link layer retransmission). Cả hai giải pháp này đều đòi hỏi không có sự mất gói số liệu do tắc nghẽn trên đường truyền snoop agent và đích, nghĩa là từ trạm cơ sở đến người nhận chỉ có một chặng. Ngoài ra, giải pháp này cũng có nhược điểm tương tự giải pháp phát lại ở tầng liên kết dữ liệu, đó là nó có thể vẫn cản trở các cơ chế kiểu đầu cuối- đầu cuối, nếu thời gian đường truyền xấu kéo quá dài. Như vậy, với các biện pháp cải tiến này ta thấy sử dụng mạng hiệu suất cao hơn hẳn. Chương 3: KHẢO SÁT ĐÁNH GIÁ HIỆU SUẤT CỦA TCP BẰNG BỘ MÔ PHỎNG MẠNG NS2 3.1. Giới thiệu về bộ mô phỏng mạng NS2 (Network Simulator Version 2) Việc nghiên cứu các mạng thực sẽ trở nên trực quan, đáng tin cậy, dễ dàng và đưa đến những kết quả chính xác hơn nếu chúng ta sử dụng một hệ thống phần mềm mô phỏng mạng thích hợp, NS (Network Simulator) là một phần mềm như thế. Các hoạt động mạng thực được mô phỏng để xem xét về đặc tính, tính chất hoạt động của mạng, từ đó có thể đánh giá hay đề ra các cải tiến, tinh chỉnh giao thức để nâng cao hiệu suất truyền thông trên mạng. NS2 (Network Simulator Version 2) là hệ thống phần mềm mô phỏng máy tính được xây dựng và phát triển bởi dự án VINT của phòng thí nghiệm quốc gia Lawrence Berkeyley Laborary ở Mỹ. NS là hệ mô phỏng có cấu trúc hướng đối tượng được xây dựng bằng hai ngôn ngữ C++ và Otcl, nó được xây dựng theo cách để có thể mở rộng được dễ dàng bởi người dùng. Với NS, người dùng có thể mô phỏng các mạng LAN, WAN, theo kiểu truyền thống có dây, không dây, hỗn hợp có dây và không dây, các mạng thông tin vệ tinh, NS có thể mô phỏng sự thực thi của những giao thức mạng như TCP, UDP, thực hiện phương thức khai thác truyền thông như FTP, TELNET, WEB, CBR và VBR, kỹ thuật quản lý hàng đợi tại các bộ định tuyến như là Drop Tail, Red, và CBQ, các thuật toán định tuyến như Dijkstra, Cùng với NS, NAM (Network Animator) và Xgraph là hai bộ công cụ phần mềm đi kèm được dùng để xem xét, nghiên cứu, trực quan hoá những kết quả thu được từ ns dưới dạng đồ hoạ. Chúng thể hiện các quá trình và kết quả thu được trên giao diện màn hình đồ hoạ, tiện cho người dùng có thể xem xét sự hoạt động của mạng và có thể phát hiện được một số sai sót trong việc viết kịch bản mô phỏng. Hình vẽ 27 dưới đây cho thấy sự thể hiện của màn hình NAM. Ngoài các công cụ đi kèm NS là NAM và XGRAPH nêu trên, em cũng đã sử dụng một bộ chương trình công cụ để phân tích kết quả mô phỏng trong trace file, có tên là trace graph, tác giả là Jaroslaw malek, thuộc trường Đại học Tổng hợp kỹ thuật Wroclaw, Ba Lan, đóng góp cho cộng đồng sử dụng NS. Phiên bản 2.02 có thể chạy trong môi trường Linux, Unix và cả Windows nữa. Màn hình hiển thị kết quả phân tích bằng đồ thị của trace graph được trình bày trên hình 31. Hình 27. Màn hình thể hiện của NAM (Network Animator) Có thể hình dung một cách đơn giản về hoạt động của ns qua hình vẽ 28 sau đây: Hình 28. Hoạt động của NS dưới góc nhìn của người sử dụng Như vậy, để có thể thực hiện một chương trình mô phỏng mạng, cũng như công việc lập trình, người dùng cần viết một kịch bản (script) cho chương trình mô phỏng, nó là một script trong ngôn ngữ otcl, được NS xử lý, thông qua việc liên kết tới các thư viện của mình, NS sẽ đưa ra kết quả mô phỏng, thông qua NAM hay công cụ xử lý khác, người dùng có thể đánh giá các tham số mạng mô phỏng của mình. NS cung cấp các kết quả mô phỏng dưới dạng file văn bản một cách chính xác, đầy đủ và có thể tuỳ biến mềm dẻo. Các file kết quả: Khi thực hiện việc mô phỏng, NS sẽ sinh ra các trace file ghi lại toàn bộ quá trình xảy ra các sự kiện trong thời gian mô phỏng được gọi là các trace file (các file dấu vết), có phần tên mở rộng là tr. Ngoài ra NS còn có thể tạo ra một loại trace file nữa, có tên mở rộng là NAM, dùng làm input cho chương trình hiển thị trực quan NAM. Sau đây là cấu trúc một trace file: Hình 29. Cấu trúc một trace file Theo hình trên chúng ta thấy, cấu trúc một trace file gồm các dòng, mỗi dòng ghi các thông tin về một sự kiện mạng và bao gồm 12 trường, các trường có ý nghĩa như sau: Event: có bốn giá trị được diễn tả là: r (receive), + (enqueue), - (dequeue), và d (drop), chúng lần lượt tương ứng với việc nhận packet tại nút mạng có định danh được ghi trong trường to_node, đưa packet vào hàng đợi, đưa packet ra khỏi hàng đợi, và loại bỏ packet khỏi hàng đợi. Time: thời gian xảy ra sự kiện mô phỏng, tính theo đơn vị giây. From node: xác định nút gửi gói tin. Pkt type: kiểu của packet. Pkt size: kích thước của packet tính theo byte. Flags: thiết lập các giá trị cờ. Fid: flow id, định danh dòng (hay kết nối). Src addr: địa chỉ nút nguồn. Dst addr: địa chỉ nút đích. Seq num: định danh duy nhất của packet. Như vậy, các trace file chứa đầy đủ các thông tin về từng sự kiện diễn ra trong quá trình hoạt động của mạng, trace file là cần thiết cho việc nghiên cứu mạng mô phỏng. 3.2. Thí nghiệm mô phỏng và kết quả đạt được 3.2.1. Thí nghiệm mô phỏng Chương trình mô phỏng do em xây dựng được in trong phụ lục của khoá luận tốt nghiệp này. File chương trình có tên “kltn-nthat01.tcl”, file vết của chương trình mô phỏng có tên là “kltn-nthat01.tr”, file vết dùng cho chương trình hiển thị NAM có tên là “kltn-nthat01.nam”. Mạng mô phỏng được xây dựng gồm 6 nốt tham gia vào quá trình truyền thông, với các kết nối như mô tả trên hình vẽ 30. NS tự động đánh số thứ tự các nốt theo thứ tự các nốt được tạo ra, đầu tiên là nốt 0. Để dễ nhớ, em gán tên cho các nốt, thí dụ s1, s2 ... với chữ cái s nhần chỉ các nốt có thể gửi (send) gói tin số liệu hoặc gói tin biên nhận, chữ cái r ngầm chỉ bộ định tuyến – router. Nốt 0 (trên hình ghi nhãn là s1) sẽ gửi các gói tin tới nốt 4 (s3), nốt 1 (s2) sẽ gửi các gói tin tới nốt 5 (s4), hai luồng gói tin ứng với 2 kết nối sẽ cùng đi qua chặng đường từ nốt 2 (r1) đến nốt 3 (r2). Như vậy, tô pô của mạng đã được xác định. Để thực hiện việc gửi dữ liệu giữa các nốt, chúng ta phải tạo các agent gửi dữ liệu từ các nốt gửi cũng như tạo các agent nhận dữ liệu trên nốt nhận. Ở đây, các agent TCP (TCP1, TCP2) gửi sẽ được gắn vào các nốt s1, s2. Các agent sink (sink1, sink2) nhận dữ liệu sẽ được gắn vào nốt s3, s4. Khi đó chúng ta nối các agent này tương ứng lại với nhau. Tiếp đến chúng ta tạo các nguồn truyền thông (traffic source) ftp (ftp1,ftp2) và gắn chúng tương ứng vào các agent TCP. Chúng ta có thể thấy rõ chi tiết mạng mô phỏng qua hình vẽ 30 sau: Hình 30. Chi tiết tô pô của mạng mô phỏng Em thực hiện thí nghiệm mô phỏng với việc truyền thông từ nốt s1 đến nốt s3 và từ nốt s2 đến nốt s4. Thực thể tcp1 truyền các gói tin đến thực thể nhận sink1 trên nốt s3 trong khoảng thời gia