5.3.1 Mục tiêu của thực nghiệm 3
Mục tiêu của thực nghiệm là quan sát, ghi lại vết các nguồn lưu lượng thực được vận chuyển bởi các giao thức tầng Giao vận, nhằm hiểu rõ hơn về sự hoạt động của các giao thức này trên mạng thực tế.
Cụ thể, chúng tôi sẽ sử dụng vết mô phỏng với hai mục tiêu sau:
– Trình diễn các sự kiện mô phỏng trên NAM, giúp người xem có thể thấy được các luồng lưu lượng giống như chúng được truyền trên đường truyền thực.
– Phân tích vết thu được để đánh giá thông lượng của các kết nối trên đường truyền thực.
5.3.2 Thiết lập cấu hình mạng mô phỏng 3
Mạng thực nghiệm gồm 4 máy tính: Máy A, B, D chạy hệ điều hành WinXP, máy C chạy hệ điều hành Linux Fedora 4 cài đặt NS-2.30. Để tạo ra nguồn lưu lượng UDP, máy B sẽ truyền một luồng Video Mpeg 2 với tốc độ 9.716 Mbps (720x480, 29.97 fps) đến máy D, nguồn Video được phát bởi chương trình VLC. Máy A sẽ truyền một luồng lưu lượng ứng dụng FTP đến máy D nhằm sinh nguồn lưu lượng TCP. Tốc độ của mạng LAN là 100Mbps, được cấu hình như sơ đồ sau:
Hình 5.8 Topo mạng mô phỏng 3
Việc cấu hình mạng mô phỏng và thiết lập kịch bản mô phỏng sau đây là nhằm tiện lợi cho việc phân tích kết quả và hiển thị trên NAM.
Hình 5.9 Cấu hình mạng mô phỏng
5.3.3 Kết quả nhận đƣợc từ thực nghiệm 3
5.3.3.1 Quan sát các nguồn lƣu lƣơng thực bằng NAM
Hình 5.10 Quan sát nguồn lưu lượng thực
2 0 3 4 5 1 tcp ftp udp streaming nulltcp acktc p ackftp nulludp nullack 192.168.0.1 192.168.0.2 192.168.0.3 192.168.0.3 10.0.0.1 10.0.0.2 C Modem NSE FTP Video A B D
Với NAM, ta có thể quan sát các nguồn lưu lượng NSE ghi lại tại máy tính C. Nguồn lưu lượng có màu xanh từ node 2 đến node 3 là nguồn FTP từ máy A gửi cho máy D, nguồn biên nhận tương ứng có màu đỏ truyền ngược lại từ node 3 đến node 2. Nguồn UDP từ máy B đến máy D có màu đen tương ứng từ node 4 đến node 5.
5.3.3.2 Tranh chấp đƣờng truyền của giao thức UDP và TCP
Hình 5.11 Đồ thị tranh chấp đường truyền của giao thức TCP và UDP Mô phỏng được thực hiện với khoảng thời gian 120 giây. Nguồn FTP (sử dụng TCP để vận chuyển) được kích hoạt trước khoảng thời gian giây thứ 6, lúc này thông lượng TCP đã tăng đáng kể đạt hơn 8Mbps. Đến khoảng giây thứ 13, nguồn UDP bắt đầu phát thì có sự tranh chấp băng thông xảy ra, thông lượng nguồn FTP giảm đáng kể vì phải chia phần băng thông cho nguồn UDP. Sau khi nguồn UDP kết thúc tại giây 76 thì nguồn FTP bắt đầu lấy lại băng thông của nguồn UDP trả lại.
Từ kết quả nhận được như trên, chúng tôi có một số nhận xét như sau: 1. Giao thức TCP có khả năng thích nghi với đường truyền, còn giao thức UDP phát với một tốc độ bit cố định cho dù có gói tin bị mất trên đường truyền. Tuy nhiên, kết quả thực nghiệm 3 (Hình 5.11) cho thấy, thông lượng
nguồn phát UDP cũng bị thăng giáng mạnh như thông lượng nguồn phát TCP. Nguyên nhân là giao thức TCP sử dụng cơ chế cửa sổ trượt có kích thước thay đổi. Thông lượng TCP tiếp tục tăng cho đến khi bên phát của thực thể TCP không nhận được biên nhận đúng trong thời gian time-out, khi đó bên phát TCP cho rằng có dấu hiệu tắt nghẽn nên giảm cửa sổ phát xuống đáng kể và sau đó tăng trở lại làm thông lượng nguồn phát TCP thăng giáng mạnh. Khi thông lượng kết nối TCP tăng cao thì số lượng các gói tin UDP bị loại lớn hơn và ngược lại thông lượng TCP giảm thì số lượng các gói tin UDP bị loại ít hơn, làm cho thông lượng UDP bị thăng giáng theo sự thăng giáng của thông lượng TCP.
2. Một số nguyên nhân làm cho thông lượng nguồn TCP và UDP chỉ chiếm một phần rất nhỏ băng thông đường truyền, có thể là:
– Bộ đệm phát và bộ đệm thu tại các máy tính A, B, C, D không đủ lớn để tăng thêm thông lượng đường truyền.
– Hàng đợi tại Modem không đủ lớn để chứa tất các gói tin đến từ máy A và máy B trước khi được đưa lên đường truyền đến máy C, dẫn đến sự loại bỏ các gói tin ngay tại Modem. Hơn nữa mục đích của Modem là truy cập Internet ADSL có dung lượng thấp, cho nên có bộ nhớ nhỏ, tốc độ xử lý chậm. Do đó, có thể Modem không thích hợp cho truyền dữ liệu trong mạng LAN tốc độ cao (100Mbps).
– Có sự xung đột khi sử dụng đường truyền chung từ Modem đến máy C của hai kết nối trên làm cho các gói tin bị hỏng, dẫn đến thông lượng TCP giảm đáng kể và sự loại bỏ gói tin UDP.
Các lý do trên có thể là nguyên nhân làm cho các kết nối sử dụng kém hiệu quả băng thông đường truyền. Khi lưu lượng đến vượt quá khả năng nhận thì các gói tin bị loại, hoặc thời gian đợi biên nhận quá lâu nên bên gửi TCP cho rằng có sự mất mát gói tin xảy ra. Đó là các lý do làm cho thông lượng TCP giảm đáng kể khi nguồn UDP bắt đầu phát. Cụ thể, tổng thông
lượng của hai kết nối trên tại thời điểm ổn định vào khoảng 10Mbps, chiếm khoảng 10% khả năng vận chuyển của đường truyền.
3. Nguồn phát UDP tại máy B có thông lượng khoảng 9.716 Mbps, nhưng đến máy nhận C thì chỉ còn khoảng 4.6Mbps. Điều này cho thấy sự hạn chế của các thiết bị phần cứng sử dụng cho thực nghiệm này là có thật. Để thêm tính thuyết phục của nhận xét này, chúng tôi thực hiện thêm một thực nghiệm giống như trên với duy nhất một nguồn phát UDP (9.716 Mbps), thu được kết quả về thông lượng nguồn UDP tại máy C như Hình 5.12.
Hình 5.12 Đồ thị thông lượng của giao thức UDP khi truyền riêng
Rõ ràng, lưu lượng nguồn video thu được không bị hao hụt nhiều như khi sử dụng chung đường truyền với ứng dụng ftp (Hình 5.11).
5.4 THỰC NGHIỆM 4 – MÔ PHỎNG TRUYỀN THÔNG VỚI INTERNET
5.4.1 Mục tiêu của thực nghiệm 4
Để kết quả việc đánh giá các giao thức không bị ảnh hưởng nhiều bởi phần cứng tại trạm thu như ở thực nghiệm 3, chúng tôi sẽ thực hiện một thực nghiệm khác tương tự như thực nghiệm 3 với các nguồn lưu lượng phát trực tiếp trên Internet thông qua kết nối ADSL.
5.4.2 Thiết lập cấu hình mạng mô phỏng 4
Hình 5.13 Topo mạng mô phỏng 4
Mạng mô phỏng được cấu hình tương tự như cấu hình mạng thực nghiệm 3. Địa chỉ IP của các máy như sau: A(192.54.34.190), B(150.65.7.130), E(208.113.214.86), các máy còn lại được cấu hình như thí nghiệm mô phỏng 3. Máy D lần lượt thực hiện các kết nối với ba máy A, B, E với đường truyền ADSL 3072/640 Kbps. Tuy nhiên, thông số đường truyền ADSL thực (do chính tôi đăng ký gói dịch vụ ADSL MegaYOU (downlink/uplink = 3072 Kbps/640 Kbps) của nhà cung cấp dịch vụ FPT) không phải luôn ổn định (điều này hoàn toàn nằm ngoài khả năng kiểm soát của tôi). Nên ở đây chúng tôi chỉ quan sát quá trình chia sẻ đường truyền của ba kết nối ftp.
Nguồn ftp-1 được tạo ra bằng cách download tệp tin “Fedora-9-i386- DVD.iso” tại địa chỉ website:
http://mirror.fraunhofer.de/download.fedora.redhat.com/fedora/linux/rele ases/9/Fedora/i386/iso/
Nguồn ftp-2 được tạo ra bằng cách download phần mềm “ns-allinone- 2.33” tại địa chỉ website:
http://sourceforge.net/project/showfiles.php?group_id=149743
Nguồn ftp-3 được tạo ra bằng cách download tệp tin “driverXP.rar” tại địa chỉ: ftp://dung.thanhdatvn.com/ C Modem ADSL NSE FTP1 FTP3 Internet ADSL line A B D E FTP2
5.4.3 Kết quả nhận đƣợc từ thực nghiệm 4
Mô phỏng bắt đầu thực hiện vào lúc 04h15, ngày 1/6/2008. Thời gian mô phỏng là 653 giây với kết quả được trình bày dưới đây:
Hình 5.14 Đồ thị thông lượng của ba kết nối fpt khi chia sẻ băng thông FPT-3 truyền đầu tiên, trong thời gian 8 giây đầu thông lượng đạt hơn 2000 Kbps (Hình 5.15 cho ta thấy rõ ràng hơn). Đến giây thứ 8, khi kết nối FPT-1 bắt đầu truyền thì thông lượng FPT-3 giảm xuống vì phải chia sẻ đường truyền cho FPT-1. Hai nguồn FPT-1 và FPT-3 có thông lượng ổn định cho đến giây 125 trước khi có kết nối FPT-2 truyền. Sau khi nguồn FTP-2 bắt đầu truyền, thì phần băng thông chung của đường truyền được chia cho ba kết nối tương đối công bằng. Tuy nhiên đến giây thứ 470 thì thông lượng FPT-1, FPT-2 không ổn định và đột giảm xuống, có lẽ do các dòng thông lượng này phải chia sẻ dải thông với các dòng thông lượng mới xuất hiện ở một số chặng nào đó, dọc theo đường truyền chung từ máy D đến hai máy tính A và E.
Từ kết quả nhận được như trên, chúng tôi có nhận xét là: Các giao thức TCP đảm bảo thực hiện rất công bằng việc sử dụng đường truyền chung. Bởi
vì, giao thức TCP có sử dụng cơ chế điều khiển lưu lượng và điều khiển tắc nghẽn (mục 2.2.1.3).
Hình 5.15 Đồ thị thông lượng của các kết nối trong 150 giây đầu
5.5 THỰC NGHIỆM 5 – MÔ PHỎNG VỚI INTERNET CÓ NGUỒN PHÁT UDP
5.5.1 Mục tiêu của thực nghiệm 5
Mục tiêu của thực nghiệm 5 là đánh giá sự tương tác của các nguồn lưu lượng thực do các giao thức khác nhau của tầng Giao vận vận chuyển trên đường truyền Internet. Cụ thể là đánh giá sự ảnh hưởng của nguồn lưu lượng UDP đối với hai nguồn lưu lượng TCP.
5.5.2 Thiết lập cấu hình mạng mô phỏng 5
Mạng mô phỏng được cấu hình tương tự như mạng thực nghiệm 4, chỉ khác là ở đây thay nguồn FTP3 thành nguồn UDP. Hai nguồn FTP1 và FTP2 được thiết lập bằng cách download cùng một tệp tin trên mạng Internet (http://media.thanhnien.com.vn/VIDEO/NhuChuaHeCoCuocChiaLysSo7.wm v) của trang báo Thanh Niên. Nguồn UDP được tạo ra bằng cách xem một kênh tivi trực tuyến (kênh “TT Movie” trên trang web:
http://road.awardspace.com). Kênh tivi này được phát với tốc độ 964Kbps và được vận chuyển bằng giao thức UDP.
Hình 5.16 Topo mạng mô phỏng 5
5.5.3 Kết quả nhận đƣợc từ thực nghiệm 5
Cấu hình mô phỏng trên được thực hiện 3 lần, đồng thời đo thông lượng của 3 kết nối được kết quả như sau:
Kết quả thực hiện mô phỏng lần 1: (01h38 – 08/06/2008)
Hình 5.17(a) Kết quả mô phỏng lần 1
C Modem ADSL NSE FTP1 FTP2 Internet ADSL line A B D E UDP
Kết quả thực hiện mô phỏng quả lần 2: (01h52 – 08/06/2008)
Hình 5.17(b) Kết quả mô phỏng lần 2 Kết quả thực hiện mô phỏng lần 3: (02h25 – 09/06/2008)
Trên các hình 5.17(a), 5.17(b) và 5.17(c), thông lượng trung bình (TLTB) được tính sau các khoảng thời gian 5s. Để thấy rõ hơn sự thăng giáng TLTB của các kết nối trên, chúng tôi sẽ tính TLTB trong các khoảng thời gian 0.5s, các kết quả được trình bày dưới đây:
Hình 5.18(a) Kết quả mô phỏng lần 1với thời gian tính TLTB là 0.5s
Hình 5.18(c) Kết quả mô phỏng lần 3 với thời gian tính TLTB là 0.5s Từ các kết quả phân tích mô phỏng như trên, chúng tôi rút ra được một số nhận xét như sau:
1. Nguồn phát lưu lượng sử dụng TCP luôn chia sẻ đường truyền với các kết nối TCP khác một cách “công bằng”, còn kết nối UDP thì không và luôn phát với thông lượng không đổi. Điều này dễ dàng thấy được ở cả ba lần quan sát lưu lượng như trên, các nguồn lưu lượng TCP luôn giảm thông lượng đột ngột khi có bất kỳ nguồn lưu lượng nào khác bắt đầu phát, còn nguồn lưu lượng UDP thì phát với tốc độ cố định phụ thuộc vào yêu cầu của các ứng dụng.
2. Với TCP, thông lượng đến nút (chạy NS) thăng giáng mạnh, do sử dụng cơ chế cửa sổ trượt có kích thước thay đổi (Hình 5.18(a), Hình 5.18(b) và Hình 5.18(c)).
3. Với UDP, thông lượng đến nút (chạy NS) gần như không đổi, vì lý do giao thức UDP không có cơ chế điều khiển lưu lượng nên nguồn phát UDP luôn phát với tốc độ ổn định mà không cần quan tâm đến băng thông đường truyền, ngay cả trong trường hợp mạng tắc nghẽn thì thực thể gửi của giao thức UDP vẫn phát dữ liệu. Điều này giải thích câu hỏi “Tại sao hiện nay các
ứng dụng thời gian thực như Video online, TV online, Music online, … người ta vẫn dùng giao thức TCP thay vì dùng UDP, RTP, …?”. Hơn nữa, với điều kiện băng thông còn hạn chế như hiện nay, nếu tất cả các ứng dụng thời gian thực trên Internet dùng giao thức UDP thì hệ thống mạng sẽ bị tắc nghẽn. Đây cũng là lý do mà hầu hết (hơn 90%) lưu lượng trên Internet là do giao thức TCP vận chuyển.
4. Ngược lại với giao thức UDP, TCP luôn giảm thông lượng truyền khi băng thông đường truyền giảm nhằm thích nghi với đường truyền. Do đó, giao thức TCP không phù hợp với các ứng dụng truyền thông thời gian thực. Tuy nhiên, trong điều kiện băng thông còn hạn chế thì UDP không phải là giải pháp tốt để vận chuyển dữ liệu thời gian thực.
KẾT LUẬN
Đánh giá hiệu suất bằng phương pháp lập mô hình mô phỏng là phương pháp nghiên cứu hiện đại, được sử dụng rộng rãi trên thế giới nhờ có những ưu điểm vượt trội, đó là: nhanh chóng, chính xác và hiệu quả, đặc biệt với chi phí thấp nên thích hợp cho đông đảo người sử dụng.
NS-2 là một trong những công cụ mô phỏng có nhiều ưu điểm như trên, cho phép người sử dụng dễ dàng lập mô hình mô phỏng cho nhiều loại mạng khác nhau, đáp ứng hầu hết các nhu cầu của người nghiên cứu giao thức mạng. Thêm vào đó, tính năng tương tác với mạng thực của NS-2 đã làm tăng thêm tính tin cậy của hệ thống, vì có thể thực hiện mô phỏng trong môi trường mạng thật, được thừa kế tất cả những ưu điểm của tính năng mô phỏng NS-2 thông thường.
Một số ưu điểm nổi bật của bộ mô phỏng NS-2 có sử dụng tính năng tương tác với mạng thực, đó là:
– Khả năng đưa nguồn lưu lượng thực vào bộ mô phỏng và ngược lại. – Khả năng tác động lên nguồn lưu lượng thực như: tăng độ trễ, làm hỏng gói tin, loại bỏ gói tin, phát lại gói tin nhiều lần,...
– Khả năng ghi lại vết của nguồn lưu lượng thực làm nguồn lưu lượng mô phỏng về sau.
– Khả năng sinh ra các gói tin để có thể truyền thông với mạng thực. – Khả năng kiểm chứng một vài hành vi của một số giao thức đã được cài trong thực tế như giao thức TCP, UDP.
Với việc hoàn thành Luận văn này, ngoài việc nắm vững và hệ thống hoá các kiến thức nền tảng về đánh giá hiệu suất mạng máy tính và bộ mô phỏng NS-2, tôi đã đạt được các kết quả cụ thể sau đây về khả năng tương tác với mạng thực của NS-2:
1/ Thực nghiệm khả năng phản hồi lệnh Ping (thực nghiệm 1). 2/ Thực nghiệm tác động lên nguồn lưu lượng thực (thực nghiệm 2).
3/ Đưa được các nguồn lưu lượng đến từ mạng thực vào để tương tác với mạng mô phỏng (thực nghiệm 1, 2).
4/ Quan sát được vết các nguồn lưu lượng thực (thực nghiệm 3).
5/ Đánh giá được thông lượng các nguồn lưu lượng thực tại tầng Giao vận (thực nghiệm 3,4,5).
Các kết quả nghiên cứu của chúng tôi đã khẳng định các ưu điểm nổi bật nêu trên của NS.
Tuy nhiên, chức năng Emulation của NS-2 vẫn còn một số hạn chế như: chưa phát triển các tính năng phát hiện gói tin được truyền lại, gói tin ACK, và các loại gói tin khác nhau trên đường truyền thực.
CÁC HƢỚNG NGHIÊN CỨU TIẾP THEO
Trên cơ sở đã đạt được, chúng tôi dự kiến sẽ tiếp tục nghiên cứu các vấn đề sau với công cụ NS-2:
1. Nhận biết các gói tin trên đường truyền thực khi đưa vào bộ mô phỏng như: các gói tin truyền lại, các gói tin ACK, các loại gói tin khác nhau trên đường truyền,...
2. Nghiên cứu đánh giá các độ đo khác như: tần suất lỗi, độ trễ, thăng