Đánh giá Hiệu năng Mạng.doc

Đánh giá Hiệu năng Mạng

Giới thiệu

Đánh giá hiệu năng Mạng là một trong những vấn đề quan trọng cho việc thiết kế và triển khai một hệ thống Mạng máy tính Và việc đánh giá đó được thể hiện thông qua các chỉ số cơ bản: thời gian truyền tin, độ trễ trung bình, lưu lượng của đường truyền, tỉ suất lỗi…

Có nhiều phương pháp đánh giá hiệu năng của một hệ thống Mạng máy tính và phương pháp mô phỏng là một phương pháp khá tốt để đánh giá.

Với mục đích làm rõ các kiến thức đã được học về môn “Đánh giá hiệu năng Mạng” và tiếp cận với phần mềm mô phỏng NS2, phần mềm đồ họa TraceGraph; nhóm 12 thực hiện đánh giá hiệu năng của các hệ thống mạng cơ bản, và đưa ra các nhận xét khi đánh giá một hệ thống Mạng.

1 Mô hình 1

Hình 1: Mô hình

1.1 Trường hợp 1:

• Mô hình gồm 6 node mạng và được kết nối như hình 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 TCP 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 UDP 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 giữa các node

Thời gian bắt đầu(s) Thời gian kết thúc(s)

Hình 2: Khi tất cả các node cùng tham gia truyền gói tin

Hình 3: Các gói tin bắt đầu rơi

Hình 4: Các gói tin TCP đã điều chỉnh khi phát hiện mạng tắc nghẽn

Nguyên lý của giao thức TCP trong điều khiển tắc nghẽn mạng:

 Đối với mạng cố định, việc mất gói tin do lỗi đường truyền hiếm khi xảy ra Mất gói tin đồng nghĩa với việc xảy ra tắt nghẽn ở các node (Router) trong mạng Cơ chế điều khiển chống tắt nghẽn của TCP sẽ căn cứ vào điều kiện mất gói và kiểm tra time-out để xác định tắt nghẽn trong mạng.

 TCP không có khả năng phân biệt giữa mất gói do đường truyền hay mất gói do tắt nghẽn, mỗi khi xảy ra hiện tượng trên TCP giảm tốc độ truyền.

Nhận xét: Ban đầu khi chỉ các gói TCP từ node 0 và 1(theo mô hình sau khi build) truyền về node 5 các gói TCP truyền ổn định; lúc các gói UDP xuất hiện từ node 2 và 3 truyền về 5, các gói tin dần rơi tại hàng đợi và các gói TCP giảm dần (Hình 4) Thời gian này trên đường truyền từ 4 về 5 hoàn toàn chỉ có các gói UDP, thỉnh thoảng các từ các node 0 và 1 phát ra các gói TCP nhưng đến hàng đợi đều bị rơi.

Dùng TraceGraph chạy file bt3.tr, ta thu được các kết quả:

Hình 5: Thống kê thông tin mô hình mô phỏng

Kết quả thu được trong thời gian 3.85s: - Tổng số gói tin gửi: 3149 gói

- Số gói tin gửi thành công: 1887 gói - Số gói tin rơi: 1262 gói

Thông lượng

Thời gian(s)

Hình 6: Biểu đồ thông lượng của hệ thống

Nhận xét: Các gói tin ban đầu tăng dần trong khoảng giây 0 -> 1, sau đó dần ổn định và giảm dần do kết thúc thời gian truyền gói tin

Độ trễ trung bình

Hình 7: Độ trễ trung bình

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

Nhận xét: Độ trễ sẽ giảm khi ta tăng băng thông đường truyền do vậy độ 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ể.

50 mbps

1.3 Trường hợp 3:

Thay đổi Queue tại node 5 về 6 thành cơ chế RED

Cơ chế hàng đợi RED (Random Early Detection) – Dò sớm ngẫu nhiên – Khi xảy

ra tăt nghẽn RED sẽ thông báo cho trạm nguồn về tắc nghẽn bằng cách cho rơi sớm gói tin, như vậy trạm nguồn nhận biết thông qua “time out” hoặc “duplicate ACK” và trạm nguồn giảm tốc độ phát với hi vọng không phải hủy bỏ nhiều gói tin sau đó Xác suất rơi gói tin sớm phụ thuộc độ dài trung bình hàng đợi và hai ngưỡng minth, maxth Vì vậy RED rất hữu dụng trong các mạng TCP tốc độ cao để tránh tắc nghẽn.

Sau khi dùng chương trình TraceGraph ta thu được kết quả:

Hình 10: Thông tin chi tiết trường hợp 3

Thời gian(s)

Hình 11: Thông lượng gói rơi

So sánh thông lượng gói tin rơi trong 2 trường hợp DropTail và RED

Thời gian(s)

Hình 12: Biểu đồ so sánh thông lượng gói tin rơi DropTail và RED

Nhận xét: Theo kết quả của biểu đồ hình 12 ta thấy hàng đợi RED tối ưu hơn hàng đợi DropTail, các gói tin rơi ít hơn và hiệu năng mạng tốt hơn do RED có cơ chế rơi gói tin

1.4 Trường hợp 4:

Thay đổi Queue tại node 5 về 6 thành cơ chế FairQueue

Cơ chế hàng đợi FairQueue:

Trong hàng đợi FIFO có thể xảy ra vấn đề có hàng chờ mãi không được phục vụ và bị tràn gói tin đến Để khắc phục nhược điểm này trong hàng đợi FairQueue các gói tin bên trong mỗi hàng đợi được truyền theo nguyên tắc FIFO, còn các hàng đợi khác nhau sẽ được truyền theo quy tắc vòng tròn (Round Robin).

Sau khi thay đổi, ta thu được kết quả:

Hình 13: Thông tin chi tiết

Hình 14: Thông lượng gói rơi

Sau khi thay đổi 3 kiểu hàng đợi khác nhau (DropTail, RED, FairQueue), ta thu được kết quả: việc sử dụng hàng đợi dò sớm ngầu nhiên RED và hàng đợi cân bằng FairQueue làm chi hiệu năng mạng của hệ thông được nâng cao hơn (số gói tin rơi so với tổng số gói tin gửi có giảm hơn so với việc sử dụng hàng đợi DropTail).

1.5 Trường hợp 5:

Thay đổi TCP Agent thành TCP_Reno Agent

TCP_Reno Agent là một cải tiến của TCP_Tahoe, ở đây sau “phát lại nhanh” không

phải là “bắt đầu chậm” mà là “hồi phục nhanh”, tức là các gói tin sẽ có cơ chế truyền nhanh hơn.

Ta thay đổi code OTcl trong file bt3.ns # Create agents.

set agent(1) [new Agent/TCP/Reno]$ns attach-agent $node(1) $agent(1)$ns color 1 "#00000000ffff"

$agent(1) set fid_ 1

$agent(1) set packetSize_ 210

Sau khi biên dịch ta thu được kết quả:

Hình 15: Thông tin chi tiết

Hình 16: Các gói tin bắt đầu rơi

Hình 17: Khi các gói tin TCP Reno truyền ổn định

Hình 18: Thông lượng truyền

Kết quả thu được cho ta thấy việc sử dụng TCP_Reno Agent là hiệu quả hơn so với TCP Agent, hiệu năng của mạng được nâng cao hơn, lưu lượng gói tin trong đường truyền tăng lên.

Hình 19: Biểu đồ so sánh thông lượng TCP và TCP_Reno

So sánh về gói tin nhận và gửi của TCP và TCP_Reno

2 Mô hình 2

Hình 20 – Sơ đồ mô phỏng mạng

Sử dụng NAM thiết kế mô hình mạng, lưu thành file MoHinh2.ns

Hình 21 – Sơ đồ thiết kế mô hình

Mô tả:

• Trên mô hình mô phỏng ta dùng giao thức TCP để truyền gói tin từ node 1 đến node 4, dùng dịch vụ FTP TCP Agent được gắn cho node 1, TCP Sink được gắn cho node 4 để nhận dữ liệu gửi đến

• Dùng giao thức UDP để truyền gói tin từ node 2 đến node 4, dùng dịch vụ truyền gói tin là CBR UDP Agent được gắn cho node 2, Agent Null được gắn cho node 4 để nhận dữ liệu gửi đến.

• Liên kết giữa node 1 và node 3, node 2 và node 3 là liên kết song công (Duplex Link), băng thông 2mb, độ trễ 10ms

• Liên kết giữa node 3 và node 4 băng thông 1,7mb độ trễ 20ms

• Thời gian bắt đầu và kết thúc dịch chuyển gói tin từ node 1 đến node 4 lần lượt là 1s và 4s.

• Thời gian bắt đầu và kết thúc dịch chuyển gói tin từ node 2 đến node 4 lần lượt là 0,1s và 4,5s.

Lập trình bằng ngôn ngữ OTcl, điều chỉnh lại kích thước packet ở agent2 (Hình 1) lên 1KB, thiết lập thông số rate là 1mb.

# Create agents.

set agent(4) [new Agent/Null]$ns attach-agent $node(4) $agent(4)set agent(3) [new Agent/TCPSink]$ns attach-agent $node(4) $agent(3)$agent(3) set packetSize_ 210set agent(2) [new Agent/UDP]

$ns attach-agent $node(2) $agent(2)

$ns color 2 "#00000000ffff"$agent(2) set fid_ 2

$agent(2) set packetSize_ 1000$agent(2) set rate_ 1mb

Sau khi dùng NS biên dịch file nhom12.ns với lệnh ns vd4.ns ta được 2 file

• MoHinh2.nam

• MoHinh2.tr

• Dùng NAM chạy file MoHinh2.nam ta có kết quả

Hình 22 – Trạng thái hoạt động

Nhận xét:

• Từ giây 0,1 đến giây 1 chỉ có sự dịch chuyển các gói tin từ node 2 đến node 0 dùng giao thức UDP.

• Từ giây 1 trở đi có sự dịch chuyển các gói tin từ node 3 đến node 0 dùng giao thức TCP Giao thức TCP yêu cầu gửi trả gói ACK xác nhận.

• Tổ chức hàng đợi Droptail cho đường truyền từ node 1 đến node 0.

• Từ giây 1,51 trở đi có hiện tượng tràn hàng đợi, các gói tin bắt đầu bị drop Các gói tin TCP và UDP đều bị drop rất nhiều (Hình 4)

• Từ giây 1,7 trở đi TCP nhận biết có tắc nghẽn mạng làm mất gói tin nên điều chỉnh lại tốc độ truyền Vì thế các gói tin TCP ít bị drop (Hình 5)

• Ngược lại giao thức UDP là giao thức “không kết nối”, không cung cấp chức năng báo nhận ( đòi gửi trả ACK) cho bên gửi Vì vậy các gói tin UDP vẫn truyền với vận tốc ban đầu mà không có điều chỉnh.

• Tóm lại hiệu năng mạng đã được cải thiện từ giây thứ 1,7 trở đi, khi các gói tin TCP điều chỉnh lại tốc độ truyền, các gói tin không còn bị drop nữa.

Hình 23 – Trạng thái truyền từ giây 1,51

Hình 24 – Trạng thái truyền ổn định sau khi TCP điều chỉnh tốc độ truyền

Dùng TraceGraph chạy file MoHinh2.tr, ta thu được các kết quả:

Hình 25 – Thông tin chi tiết Thống kê thông lượng chung của các gói tin gửi

Thời gian

Hình 26: Thông lượng chung

Nhận xét: Các gói tin được bắt đầu gửi một cách dần dần, đến thời điểm nhất định thì ổn định và đến cuối thời gian, các gói tin gửi giảm dần và cho đến hết.

Kết luận

Qua quá trình thực hiện bài báo cáo, nhóm đã khảo sát mô hình và đưa ra các đánh giá nhận xét về các hệ thống Mạng cơ bản Qua đó nhận thấy rằng việc đánh giá hiệu năng Mạng của một hệ thống trong quá trình thiết kế là rất quan trọng và cần thiết.

Bằng việc thay đổi các thông số về băng thông, các cơ chế hàng đợi…, chúng ta có thể quyết định tốc độ của các gói tin trong mạng, giảm độ trễ, tăng lưu lượng trên đường truyền… và trên hết là nâng cao được hiệu năng của hệ thống Mạng Từ đó, ta có được thiết kế tốt nhất để tiến hành triển khai, lắp đặt một hệ thống Mạng phù hợp và tối ưu nhất.

Và cũng qua đây, chúng ta thấy được sự tiện dụng của phần mềm mô phỏng NS2, NAM, phần mềm đồ họa TraceGraph trong việc khảo sát hiệu năng của hệ thống Mạng Đây thật sự là công cụ mô phỏng hữu hiệu cho quá trình đánh giá hiệu năng Mạng máy tính.