Đề tài Đánh giá hiệu năng mạng (bài tham khảo 10)

BÁO CÁO THỰC HÀNH Môn: Đánh giá Hiệu năng Mạng GVHD: TS.Võ Thanh Tú Nhóm 12 – Lớp K13TMT Sinh viên: Lý Triệu Hoàng Đỗ Việt Triều Nguyễn Viết Tài 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) Node 1 về node 6 0,1 3,1 Node 2 về node 6 0,2 3,2 Node 3 về node 6 0,3 3,3 Node 4 về node 6 0,4 3,4 Sau 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 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ô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 = 1887/3149 = 0,599 1.2 Trường hợp 2: Thay đổi băng thông đường truyền từ node 5 và 6 từ 5mbps lên 50mbps 50 mbps Hình 8: Mô hình trường hợp 2 Hình 9: Độ trễ trung bình (trường hợp tăng tốc độ lên 50mbps) So sánh độ trễ trung bình Trường hợp Độ trễ trung bình Băng thông 5-6: 5 mbps 0,07273812295 Băng thông 5-6: 50 mbps 0,07268805397 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ể. 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ông lượng gói tin rơi 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ông lượng gói tin rơi 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 sớm. 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 Thông lượng gói tin rơi 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). Queue Packet Tổng số Rơi DropTail 3149 1262 RED 3242 1281 FairQueue 4448 1975 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 TCP Agent TCP_Reno Agent Gói tin gửi 3149 4018 Gói tin nhận 1887 2237 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_ 210 set 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ông lượng 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.