ĐÁNH GIÁ HIỆU NĂNG MẠNG
Trang 1TRƯỜNG ĐẠI HỌC DUY TÂNKHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN KỸ THUẬT MẠNG
ĐÁNH GIÁ HIỆU NĂNG MẠNG
GIẢNG VIÊN HƯỚNG DẪNTS.VÕ THANH TÚSINH VIÊN THỰC HIỆN
1.NGUYỄN VĂN TÂN-132114038 2.LÊ QUANG HIỂN-132114
3.LÊ VĂN TRỌNG-132114
Đà Nẵng, 2010
Trang 2
I.Giới thiệu về NS-2
NS-2 (Network Simulation) chương trình phần mềm dạng hướng đối tượng được sử dụng để mô phỏng lại các sự kiện xảy ra trong hệ thống mạng từ đó đưa ra các yêu cầu, đặc tính vận hành của hệ thống mạng thực NS được sử dụng để mô phỏng mạng cục bộ LAN (Local Area Network) và mạng diện rộng WAN (Wide Area Network) Hệ mô phỏng NS-2 được phát triển ở trường đại học Berkeylay cộng tác với một số cơ quan khác, bây giờ là một phần trong dự án VINT (Virtual Internet Testbed) của phòng thí nghiệm quốc gia Lawrence Berkeley.
Hệ mô phỏng NS được viết trên ngôn ngữ C++ và Otcl C++ dùng để xử lý dữ liệu, các thao thác về gói tin, còn Otcl dùng để định dạng cấu hình mô phỏng, điều khiển mô phỏng NS-2 là phần mềm mã nguồn mở có sẵn cho cả nền Windows 32 và Linux, 1.2
1 Mô phỏng các gói tin UDP/TCP
1.1.UDP
UDP agent được thực hiện trong file udp.{cc, h} Một UDP agent cho phép dữ liệu trong một kích cỡ biến thiên lấy từ một ứng dụng và phân đoạn dữ liệu đó nếu cần 1.2.TCP
Có hai loại TCP agent chính là agent một chiều và hai chiều.Tác tử một chiều được chia nhỏ hơn thành các tập hợp bên gửi TCP (tuân theo các công nghệ điều khiển lỗi và chống tắc nghẽn khác nhau) và bên nhận (“sinks”).Các tác tử hai chiều đối xứng trong cảm nhận, mô tả cả bên gửi và bên nhận.
Các agent gửi TCP một chiều hiện được hỗ trợ là : Agent/TCP - a “tahoe” TCP sender
Agent/TCP/Reno - a “Reno” TCP sender
Agent/TCP/Newreno - Reno with a modification
Agent/TCP/Sack1 - TCP with selective repeat (follows RFC2018) Agent/TCP/Vegas - TCP Vegas
Agent/TCP/Fack - Reno TCP with “forward acknowledgment” The one-way TCP receiving agents currently supported are: Agent/TCPSink - TCP sink with one ACK per packet
Agent/TCPSink/DelAck - TCP sink with configurable delay per ACK Agent/TCPSink/Sack1 - selective ACK sink (follows RFC2018) Agent/TCPSink/Sack1/DelAck - Sack1 with DelAck
• TCP Reno/ TCP Vegas
Reno TCP Reno TCP agent ương tự như Tahoe TCP agent, ngoại trừ nó bao
gồm fast recovery,với của sổ tắc nghẽn hiện tại được tăng lên bởi số các bản sao ACK
mà TCP sender nhận được trước khi nhận một ACK mới.Một ACK mới tức là ACK với giá trị cao hơn so với giá trị cao nhất trước đó.Thêm vào đó, Reno TCP agent không quay về slow-start trong quá trình truyền lại nhanh.
TCP Vegas điều khiển kích thước cửa sổ của nó bằng cách quan sát RTTs (khứ
hồi lần) của các gói tin rằng chủ người gửi đã gửi trước Nếu RTTs quan sát trở nên lớn,
Trang 3TCP Vegas nhận ra rằng mạng bắt đầu được tắc nghẽn, và throttles kích thước cửa sổ Nếu RTTs trở nên nhỏ, mặt khác, các chủ nhà người gửi TCP Vegas xác định rằng mạng được miễn tắc nghẽn, và làm tăng kích thước cửa sổ một lần nữa Do đó, các kích thước cửa sổ trong một tình hình lý tưởng dự kiến sẽ được hội tụ đến một giá trị thích hợp Cụ thể hơn, trong giai đoạn tránh tắc nghẽn, các kích thước cửa sổ được cập nhật như.
2 Cơ chế quản lý hàng đợi DropTail, Red
2.1.Cơ chế hủy bỏ sớm ngẫu nhiên(RED: Random Early Detection)
Sử dụng 2 giá trị chặn trên và chặn dưới để đánh dấu các vị trí hàng đợi :maxth và minth
Nếu hàng đợi chứa trong khoảng minth và maxth gói tin thì hủy bỏ gói
tin một cách ngẫu nhiên tùy theo một hàm xác suất p.
Nếu hàng đợi chứa ít hơn minth gói tin thì thêm gói tin mới vào hàng
đợi và xác suất hủy bỏ là 0.
Nếu hàng đợi chứa nhiều hơn maxth gói tin thì hủy bỏ những gói tin
mới và xác suất hủy bỏ là 1 2.2 Cơ chế hàng đợi DropTail
Bộ định tuyến sẽ lưu trữ các gói tin gửi đến trong một hàng đợi của bộ nhớ cho đến khi nó có thể được xử lý theo nguyên tắc FIFO (vào trước, xử lý trước).Khi các gói tin gửi đến nhanh hơn là chúng được chuyển đi thì hàng đợi sẽ dài ra và ngược lại, khi các gói tin chuyển đến chậm hơn thì hàng đợi thu ngắn lại Nhưng vì bộ nhớ là hữu hạn, hàng đợi không thể dài ra quá giới hạn cho phép.
II.Xây dựng và đánh giá hiệu năng mạng trên phần mềm NS-2 1.Mô hình 1
1.1.Mô tả hệ thống.
Mạng trên bao gồm 4 node (n0, n1, n2, n3) Duplex link (liên kết truyền nhận dữ liệu hai chiều diễn ra đồng thời) giữa node n0 và n2, n1 và n2 có bandwidth (băng thông) = 2 Mbps, delay (thời gian trì hoãn) = 10 ms Duplex link giữa n2 và n3 có bandwidth = 1.7 Mbps và delay = 20 ms Các node dùng hàng đợi DropTail, max size (kích thuớc lớn nhất) = 10
Agent “tcp” gắn với n0 và agent “sink” gắn với n3 Agent “tcp” có thể tạo packet với max size = 1 KByte Agent tcp “sink” tạo và gửi packet dạng ACK cho sender (sender là agent gửi packet đi) và giải phóng packet nhận được Agent “udp” gắn với n1 sẽ kết nối với agent “null” gắn với n3 Agent “null” chỉ giải phóng packet đã nhận được Bộ khởi tạo lưu lượng “ftp” và “cbr” tương ứng được gắn vào agent “tcp” và “udp” “cbr” được cấu hình để tạo ra packet 1 KByte tại tốc độ 1 Mbps “cbr” được thiết lập cho start bắt đầu tại thời điểm 0.1 giây và kết thúc tại thời điểm 4.5 giây, “ftp” bắt đầu lúc 1.0 giây và kết thúc lúc 4.0 giây.
Trang 4Bắt đầu node 1 sẽ truyền các segment qua node 3 bằng giao thức UDP.CBR ở đây mang nghĩa “ constant bit rate” nghĩa là tốc độ bit không đổi.Nhiệm vụ của nó :
+ Thiêt lập packetsize.
Trang 5+ Thiết lập interval_ khoảng thời gian giữa hai lần truyền liên tiếp.
b.Hoạt động bình thường
Hình 1.3.Quá trình chạy mô hìnhNhận xét:
Từ 1(s) node 0 cũng tham gia truyền đến node 3 qua giao thức TCP, và bắt đầu từ đây khoảng 2 (s) cả node 0 và node 1 đều truyến sang node 3 1 cách
khá ổn đinh nhưng hình trên vẫn cho ta thấy các gói tin được đưa vào hàng đợi có xu thế mỗi lúc 1 nhiều hơn
c.Quá trình các gói tin xảy ra hiện tượng Drop.
Hình 1.4.Quá trình các gói tin bi Drop.
Trang 6Nhận xét:Khoảng từ 2(s)4(s) các gói tin rớt mỗi lúc 1 nhiều nhưng xu thế các
gói tin của UDP rớt nhiều hơn
d.Kết thúc
Hình 1.5.Quá trình kết thúc mô hình Nhận xét:
Từ 4(s)4.5(s) chỉ còn mình node 1 truyền dữ liệu đến node 3 , hàng đơi giảm
xuông nhanh chóng mạng lai ổn định
1.3.Phân tích các chỉ số mạng.
a.Bảng mô phỏng thông tin thông lượng mạng.
Hình 1.6.Thông tin quá trình thực mô hình
Trang 7Các gói tin bị drop ở nodes số 2 vì xảy ra hiện tượng BottleNeck ( Thắt cổ chai) Nguyên nhân của hiện tượng này là do hàng đợi có độ lớn 20 vì vậy khi số lượng gói tin vượt quá giá trị max cho phép thì các gói tin bị drop khá
nhiều.Quá trình Drop xảy ra càng nhiều khi các nodes đồng thời cùng tham gia vào mạng ,các dịch vụ CBR,FTP gửi liên tục dẫn đến sự quá tải của hang đợi.
b.Biểu đồ thông lượng
Hình 1.7.Biểu đồ thông lượng Nhận xét
Biểu đồ cho thấy đường truyền không ổn định , các gói tin bị Drop theo thời gian Dlay.
Trang 8- Mạng trên bao gồm 4 node (n0, n1, n2, n3).Giữa node n3 và n2 là 100MB, n1 và n2 có bandwidth (băng thông) = 10 Mbps, delay (thời gian trì hoãn) = 20 ms, giữa n1 và n0 có bandwidth = 50 Mbps và delay = 20 ms Các node dùng hàng đợi DropTail, max size (kích thuớc lớn nhất) = 10
- Agent “tcp” gắn với n3 và agent “sink” gắn với n0 Agent “tcp” có thể tạo packet với max size = 1 KByte Agent tcp “sink” tạo và gửi packet dạng ACK cho sender (sender là agent gửi packet đi) và giải phóng packet nhận được.Bộ khởi tạo lưu lượng “ftp” tương ứng được gắn vào agent “tcp” và được thiết lập cho start bắt đầu tại thời điểm 0.0 giây và kết thúc tại thời điểm 5 giây.
2.2.Quá trình thực hiện
Trang 9•Quá trình chạy của hệ thống sử dụng giao thức TCP.
Trang 10• So sánh biểu đồ thông lượng mạng.
o Biểu đồ thông lượng mạng sử dụng giao thức TCP-RENO
o Biểu đồ thông lượng mạng sử dụng giao thức TCP
Trang 11Nhận xét:
Qua biểu đồ ta thấy sự khac biệt giữa TCP và TCP-RENO.
TCP-RENO điều chế được sự tăng giảm của các gói tin, làm giảm thiểu các gói tin bị mất.
• Thông tin hiển thi 2 hệ thống.
TCP-RENO
Trang 12•Mô hình 3.
Hình 3.1: Mô hình mô phỏng
Trường hợp 1:
• Mô hình gồm 6 node mạng và được liên kết như hình 3.1.
• Dùng giao thức TCP để truyền gói tin từ node 1, node 2 đến node 6, dùng dịch vụ FTP TCP Agent được gắn cho node 1, node 2 TCP Sink được gắn cho node 6 để nhận dữ liệu gửi đến
• Dùng giao thức UDP để truyền gói tin từ node 3, node 4 đến node 6, dùng dịch vụ truyền gói tin là CBR UDP Agent được gắn cho node 3, node 4, Agent Null được gắn cho node 6 để nhận dữ liệu gửi đến.
• Liên kết với nhau giữa các node trong mô hình là liên kết song công (Duplex Link), độ trễ 20ms Hàng đợi sử dụng: DropTail.
• Băng thông đường truyền giữa các node 1 và 5, 2 và 5, 3 và 5 là 10mbps, giữa node 4 và 5 là 100mbps, giữa 5 và 6 là 5mbps.
• Thời gian truyền gói tin tại các node
Thời gian bắt đầu Thời gian kết thúc
Trang 13Sau khi thiết kế mô hình, chạy mô hình với NAM ta được kết quả cụ thể sau:
Hình 3.2: Khi tất cả các node cùng tham gia truyền gói tin
Nhận xét: Các gói tin truyền trong mạng ổn định theo thời gian do sự ổn định về băng thông đường truyền.Mặc dù trong khoảng thời gian đầu vẫn xuất hiện các gói tin chờ đợi tại các Queue Node 1 và Node 0.
Dùng TraceGraph chạy file thuchanh.tr, ta thu được các kết quả:
Hình 3.3: Thống kê thông tin mô hình mô phỏng
Kết quả thu được trong thời gian 5s: - Tổng số gói tin gửi là 8008
- Số gói tin rơi là 0
Trang 14- Số gói tin mất là 81
Thông lượng
Hình 3.4: Biểu đồ thông lượng của hệ thống
Tỉ lệ gói tin truyền thành công
Tỉ lệ gói truyền thành công = Số gói tin truyền thành công/Tổng số gói tin
=7970/8008 = 0.995
Trang 15Trường hợp 2:
Thay đổi băng thông đường truyền từ node 5 và 6 từ 5mbps lên 50mbps
Hình 3.6: Mô hình trường hợp 2
Nhận xét: Độ trễ trung bình sau khi tăng thông lượng đường truyền nối node 5 và node 6 giảm
đi nhưng không đáng kể.
Hình 3.7.Thông lượng gói tin giữa node 5Mbps50Mbps So sánh thông lượng khi thay đổi thông lượng từ 5 Mbps50Mbps
50 mbps
Trang 16Hình 3.8:So sánh thông lượng của 2 trường hợp Thông lượng gói tin chạy BW là 5Mbps giữa node 56 Thông lượng gói tin chạy BW là 50Mbps giữa node 56