5.2.1 Mục tiêu của thực nghiệm 2
Mục tiêu: là thực nghiệm khả năng tương tác với mạng thực ở chế độ opaque, cụ thể là tính năng đưa nguồn lưu lượng UDP từ mạng thực vào mạng mô phỏng NS, nguồn lưu lượng này được truyền qua các node mạng mô phỏng, sau đó được đưa ra lại mạng thực để đến đích.
5.2.2 Thiết lập cấu hình mạng mô phỏng 2
Hình 5.5 Topo mạng mô phỏng 2 Hệ thống mô phỏng gồm ba máy tính:
Máy A có địa chỉ IP: 10.0.0.2 Máy B có địa chỉ IP: 192.168.1.2
Máy C có hai card mạng, lần lượt có địa chỉ IP: 10.0.0.1 và 192.168.1.1. Cả hai đường truyền giữa B và C, giữa C và A là hai đường truyền LAN 100Mbps.
Nguồn Video phát từ máy B, nhờ một chương trình VLC (Video LAN Control) phát với tốc độ 9.716 Mbps đến địa chỉ 192.168.1.1. Tại máy C, NS sẽ bắt các gói tin này từ card mạng có địa chỉ IP là 192.168.1.1 để đưa vào bộ mô phỏng. Sau khi cho truyền nguồn Video qua các node mạng mô phỏng sẽ được NS đưa ra card mạng có địa chỉ IP là 10.0.0.1 để đến máy A. Trong bộ mô phỏng, chúng ta hoàn toàn có thể sử dụng nguồn lưu lượng Video như là một nguồn lưu lượng sẵn có trong NS. Khi đó ta có thể can thiệp nguồn lưu
A – 10.0.0.2
NSE
C
192.168.1.1 10.0.0.1
Video Video Video
lượng này như: làm cho một số gói tin bị mất, tạo độ trễ cho các gói tin,... tại bộ mô phỏng trước khi cho ra mạng thực đến máy A.
5.2.3 Kịch bản mô phỏng[18]:
# Tạo đối tượng mô phỏng ns và gọi bộ lập lịch thời gian thực
set ns [new Simulator] $ns use-scheduler RealTime
# Ghi vết mô phỏng vào file Out.tr
set traceFile [open Out.tr w] $ns trace-all $traceFile proc finish {} { global ns global traceFile $ns flush-trace close $traceFile exit 0 }
# Tạo ba node mô phỏng
set node0 $ns node set node1 $ns node set node2 $ns node
# Đưa nguồn lưu lượng thực UDP vào bộ mô phỏng từ UDP client (B)
set ipnetIN [new Network/Pcap/Live] $ipnetIN set promisc_ true
set nd $ipnetIN [open readonly eth0]
$ipnetIN filter "udp and not icmp" # Loại bỏ các gói tin icmp #Thiết lập kết nối đối tượng mạng ipnetIN tới Tap Agent aIn.
set aIn new Agent/Tap $aIn network $ipnetIN
set ipnetOUT [new Network/IP/UDP] $ipnetOUT open writeonly
$ipnetOUT connect 10.0.0.2 12345
#Thiết lập kết nối đối tượng mạng ipnetOUT tới Tap Agent aOut.
set aOut new Agent/Tap $aOut network $ipnetOUT
#Thiết lập đường truyền giữa các node.
$ns duplex-link $node0 $node1 100Mb 0ms DropTail $ns duplex-link $node1 $node2 100Mb 0ms DropTail
$ns queue-limit $node0 $node1 100 # Thiết lập hàng đợi tại node0 đến node1
$ns queue-limit $node1 $node2 100 # Thiết lập hàng đợi tại node1 đến node2
# Gắn Tap Agent aIn cho node0.
$ns attach-agent $node0 $aIn
# Gắn Tap Agent aOut cho node2.
$ns attach-agent $node2 $aOut
# Thiết lập kết nối cho hai agent.
$ns connect $aIn $aOut
# Bắt đầu thực hiện mô phỏng.
$ns run
Để thực hiện các kịch bản mô phỏng tương tác với mạng thực, chúng ta sử dụng lệnh nse <tên_kịch_bản>.tcl, còn kịch bản mô phỏng ns thông thường thì dùng lện ns <tên_kịch_bản>.tcl.
5.2.4 Kết quả nhận đƣợc từ thực nghiệm 2:
1/ Thông lượng trung bình của luồng video (đi qua C) là: 9.519076Mbps. 2/ Sự thay đổi của thông lượng luồng video (đi qua C) theo thời gian mô phỏng
Hình 5.6 Thông lượng luồng video của thực nghiệm 2
3/ Chúng tôi đưa vào mô hình lỗi với tỉ lệ lỗi gói tin lần lượt 10%, 20%, 30% và 50% đồng thời quan sát thông lượng tại card mạng vào và card mạng ra của máy C, được các kết quả như sau:
Hình 5.7(b) Thông lượng luồng video tại hai card mạng với tỉ lệ lỗi 20%
Hình 5.7(c) Thông lượng luồng video tại hai card mạng với tỉ lệ lỗi 30%
Từ các kết quả mô phỏng trên, chúng tôi rút ra một số nhận xét:
1. Thông lượng luồng video do giao thức UDP vận chuyển luôn ổn định và bị thăng giáng nhẹ. Nguyên nhân là phần mềm VLC tại máy thu và máy phát luôn có một bộ đệm thu và bộ đêm phát nên bên phát không cần phải phát với tốc độ đều tuyệt đối.
2. Có thể sử dụng các mô hình lỗi và kích thước hàng đợi để tác động lên các nguồn lưu lượng thực khi nó qua các node mạng mô phỏng NS.
5.3 THỰC NGHIỆM 3: MÔ PHỎNG TRÊN MẠNG LAN: 5.3.1 Mục tiêu của thực nghiệm 3 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