Chất lượng dịch vụ trên linux

áy tính phải cài đặt gói iproute2. Trong gói này có tiện ích “tc” (traffic control) dùng để điểu khiển tất cả lưu lượng qua lại trên hệ thống. Đây tiện ích dạng dòng lệnh (command line). Đối với hệ thống đang sử dụng kernel 2.6 thì gói iproute2 mặc định đã được tích hợp. Cách sử dụng lệnh được trình bày rất chi tiết trong trang hướng dẫn (manpage) của lệnh: #man tc Ở đây sẽ trình bày các lệnh cơ bản nhất trong tiện ích tc. Thêm một cơ chế hàng đợi (queuing discipline) #tc qdisc add Ví dụ # tc qdisc add dev eth1 root handle 1:0 htb Thêm một cơ chế hàng đợi (tc qdisc add) vào interface eth1 (dev eth1). Chỉ định đây là hàng đợi cha của tất cả hàng đợi trong interface eth1 (root) và có chỉ số là 1:0 (handle 1:0). Loại cơ chế hàng đợi là HTB. Thêm một lớp dịch vụ (class of service) #tc class add Ví dụ # tc class add dev eth1 parent 1:1 classid 1:2 htb rate 717kbit ceil 1024kbit Thêm một lớp dịch vụ (tc class add) vào interface eth1 (dev eth1). Lớp dịch vụ này có chỉ số là 1:2 (classid 1:2), lớp dịch vụ cha của nó là lớp 1:1 (parent 1:1). Loại lớp dịch vụ là HTB (htb). Lớp dịch vụ này dùng để giới hạn băng thông ở tốc độ 717 kilobit/s (rate 717kbit). Đây là băng thông được lớp dịch vụ cha 1:1 cấp riêng cho lớp dịch vụ 1:2. Các lưu lượng khi vào lớp dịch vụ này đều được đảm bảo có băng thông tối thiểu là 717 kilobit/s. Nếu lớp dịch vụ cha 1:1 còn dư băng thông, thì lớp dịch vụ 1:2 được phép mượn thêm băng thông của lớp dịch vụ cha. Tuy nhiên, băng thông tổng cộng sau khi mượn không được vượt quá giá trị băng thông tối đa là 1024 kilobit/s (ceil 1024kbit). Thêm một bộ lọc (filter) #tc filter add Ví dụ # tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 match ip tos 0x26 0xff flowid 1:21 Thêm một bộ lọc (tc filter add) vào interface eth1 (dev eth1). Vị trí bộ lọc: nằm ngay dưới bộ lọc gốc (parent 1:0), tức các gói tin phải qua bộ lọc này trước tiên rồi mới qua các bộ lọc con khác (nếu có). Bộ lọc này dùng để lọc các gói tin ip (protocol ip), thứ tự ưu tiên xử lý của bộ lọc khi có nhiều bộ lọc cùng cấp là đầu tiên (prio 1). Bộ lọc sử dụng bộ phân lớp u32 (u32) để phân lớp dịch vụ cho các gói tin. Bộ phân lớp u32 là bộ phân lớp sử dụng các trường trong IP header của gói tin để phân lớp. Cách lọc gói tin như sau: nếu gói tin có địa chỉ IP đích là 202.0.0.2/24 (match ip dst 202.0.0.2/24) và có trường tos là 0x26 (tos 0x26 0xff) thì các gói tin này sẽ được đẩy vào lớp dịch vụ có chỉ số 1:21 (flowid 1:21). Xóa cấu hình chất lượng dịch vụ của một hàng đợi #tc qdisc del Ví dụ #tc qdisc del dev eth1 root Lệnh trên xóa tất cả cấu hình tc của hàng đợi gốc (root) nằm trên interface eth1 (dev eth1). Xem trạng thái hiện tại của các lớp dịch vụ đã cấu hình ở interface #tc –s class ls dev Ví dụ #tc –s class ls dev eth1 class htb 1:22 parent 1:2 leaf 220: prio 0 rate 215000bit ceil 215000bit burst 1625b cburst 1625b Sent 5600426 bytes 3701 pkt (dropped 63, overlimits 0 requeues 0) rate 214968bit 17pps backlog 0b 8p requeues 0 lended: 3693 borrowed: 0 giants: 0 tokens: -111556 ctokens: -111556 Trạng thái của lớp dịch vụ 1:22 như sau: lớp dịch vụ cha là 1:2 (parent 1:2). Đây là lớp dịch vụ cuối cùng với hàng đợi tương ứng có chỉ số là 220: (leaf 220). Thứ tự ưu tiên của lớp dịch vụ này là 0, băng thông giới hạn là 215000bit/s ( rate 215000bit ceil 215000bit). Số gói tin mà lớp dịch vụ đã gởi đi là 3701 gói tin (3701 pkt) với tổng dung lượng tương ứng là 5600426 bytes (Sent 5600426). Băng thông hiện hành là 214968 bit/s 17 packets/s (rate 214968bit 17pps). CHƯƠNG IV KẾT QUẢ THỰC NGHIỆM Ở chương III đã giới thiệu sơ lược mô hình hệ thống. Trong chương này sẽ trình bày chi tiết hơn về cách cấu hình chất lượng dịch vụ, cũng như cách kiểm tra việc thực hiện chất lượng dịch vụ đã thực hiện thành công hay chưa. Quá trình triển khai chất lượng dịch vụ gồm hai vấn đề chính đó là: chỉnh sửa trường DSCP của gói tin và hạn chế băng thông. Để thấy rõ kết quả của việc thực hiện chất lượng dịch vụ, mô hình hệ thống sẽ được xem xét ở các kịch bản khác nhau. Cụ thể: Kịch bản 1: Sửa trường DSCP cho các gói tin (quá trình này diễn ra ở bộ định tuyến biên). Kịch bản 2: Hạn chế băng thông – không cho phép mượn băng thông (quá trình này diễn ra ở bộ định tuyến nhân). Kịch bản 3: Hạn chế băng thông – cho phép mượn băng thông (quá trình này diễn ra ở bộ định tuyến nhân). Với mỗi kịch bản sẽ được chia thành 2 lần kiểm tra: trước và sau khi triển khai. Trước khi trình bày nội dung chi tiết từng kịch bản, mục IV.1 sẽ giới thiệu sơ lược các cách thức kiểm tra kết quả của việc triển khai chất lượng dịch vụ. IV.1 Cách thức kiểm tra chất lượng dịch vụ trên linux IV.1.1 Kiểm tra giá trị trường DSCP Đối với tất cả hệ thống linux đều hỗ trợ sẵn công cụ tcpdump. Đây là một công cụ bắt gói tin phổ biến, dạng dòng lệnh (command-line). Để kiểm tra giá trị trường DSCP cho các gói tin HTTP xuất phát từ máy có địa chỉ ip là , chỉ cần gõ lệnh: #tcpdump –vi eth0 src and tcp port 80 Ý nghĩa -v : Hiển thị nhiều thông tin (mục đích để xem trường tos của gói tin). Nếu không có tùy chọn này, thông tin các gói tin chỉ bao gồm các trường cơ bản nhất, không bao gồm trường tos đang cần. -i : Chỉ bắt các gói tin ra vào interface được chỉ định. src : Chỉ hiển thị các gói tin có địa chỉ IP nguồn là . tcp port 80 : Chỉ hiển thị các gói tin ftp. Ví dụ #tcpdump –vi eth0 src 200.0.0.2 and tcp port 80 Kết quả xuất ra trên màn hình 04:03:05.617757 IP (tos 0x0, ttl 64, id 20277, offset 0, flags [DF], proto: TCP (6), length: 52) 200.0.0.2.http > 200.0.0.1.40500: F, cksum 0xe962 (correct), 268:268(0) ack 117 win 91 Giải thích 04:03:05.617757 : Thời gian bắt gói tin (vào lúc 4 giờ 3 phút…). tos 0x0 : Giá trị trường tos của gói tin là 0x00. 200.0.0.2.http : Địa chỉ IP nguồn là 200.0.0.2 và địa chỉ port là http (port 80). IV.1.2 Kiểm tra thông số chất lượng dịch vụ Tương tự như lệnh tcpdump, các hệ thống linux hầu hết đều đã hỗ trợ lệnh tc. Đây là công cụ dùng để triển khai chất lượng dịch vụ mạng rất hiệu quả. Bên cạnh việc triển khai, công cụ này cũng dùng để kiểm tra chất lượng dịch vụ mạng. Lệnh dưới đây dùng để lấy các thông tin cần thiết về băng thông ra/vào, băng thông mượn, thống kê số lượng gói tin nhận/gởi đi,…trên interface được chỉ định. #tc –s class ls dev eth0 Ý nghĩa tc : Công cụ dùng để triển khai và kiểm tra chất lượng dịch vụ. Viết tắt của từ “Traffic Control”. -s : Hiển thị thống kê các thông tin quan trọng từ các gói tin bắt được. Viết tắt của từ “Statictis”. class : Là nơi nhận xử lý các gói tin theo một chính sách nào đó. ls dev eth0 : Hiển thị các thông tin cần thiết liên quan đến gói tin ra/vào interface eth0. Ví dụ #tc –s class ls dev eth0 Kết quả xuất ra trên màn hình class htb 1:10 parent 1:1 leaf 10: prio 0 rate 100000bit ceil 300000bit burst 1612b cburst 1636b Sent 1650624 bytes 24325 pkt (dropped 4392, overlimits 0 requeues 0) rate 187912bit 351pps backlog 0b 80p requeues 0 lended: 8158 borrowed: 16087 giants: 0 tokens: -81455 ctokens: -44681 Giải thích Class htb 1:10 : Lớp dịch vụ này sử dụng hàng đợi HTB và có chỉ số là 1:10. Rate 100000bit : Băng thông tối thiểu của lớp dịch vụ này là 100000bit/giây. Ceil 300000bit : Băng thông tối đa của lớp dịch vụ này là 300000bit/giây. Sent 1650624 bytes 24325 pkt: Tổng dung lượng các gói tin đã gởi là 1650624 bytes. Số lượng gói tin đã gởi là 23425 packets. Dropped 4392 : Số gói tin đã bị đánh rớt là 4392. Rate 187912bit 351pps : Băng thông hiện tại là 187912bit/giây. Tương ứng là 351 packets per seconds. IV.2 Kịch bản 1 Hình 4.1: Mô hình kịch bản 1 IV.2.1 Nội dung Các máy trạm sẽ tạo lưu lượng FTP và HTTP đến máy chủ. Các gói tin truy vấn có thứ tự luân chuyển trên hệ thống mạng như sau: Máy trạm à Bộ định tuyến nhân à Bộ định tuyến biên à Máy chủ. Sau khi máy chủ xử lý các truy vấn xong, gói tin trả lời sẽ có thứ tự luân chuyển ngược lại với gói tin truy vấn. Tức gói tin trả lời sẽ xuất phát từ máy chủ à Bộ định tuyến biên à Bộ định tuyến nhân à Máy trạm. Các gói tin trả lời khi đến bộ định tuyến biên sẽ được chỉnh sửa giá trị trong trường DSCP từ giá trị mặc định là 0x00 thành các giá trị mong muốn. Ví dụ như các gói tin FTP sẽ được chỉnh sửa giá trị DSCP trong IP header là 0x26. Tương tự, trường DSCP của gói HTTP sẽ mang giá trị mới là 0x14. Sau đó, các gói tin này sẽ tiếp tục đi đến bộ định tuyến nhân. Tại đây, tùy thuộc vào giá trị DSCP của mỗi gói tin mà bộ định tuyến nhân sẽ có ứng xử khác nhau về độ ưu tiên xếp vào hàng đợi (Precedence) và chỉ định khả năng đánh rớt gói tin khi có tắt nghẽn xảy ra. Như vậy, mục đích chính của kịch bản này là chỉnh sửa giá trị trong trường DSCP của mỗi gói tin. Hình 4.2: Mục đích của kịch bản 1 IV.2.2 Thực hiện Để bộ định tuyến biên làm nhiệm vụ đánh dấu trường DSCP cần thực thi script editTOS.sc được trình bày ở phụ lục. Chức năng của script này như sau: đối với mỗi gói tin đi qua interface eth1 của máy đang thực thi script, nếu gói tin đó có địa chỉ port nguồn là 21 (tức gói tin FTP) thì sẽ được chỉnh sửa giá trị DSCP là 0x26. Tương tự, nếu gói tin có địa chỉ port nguồn là 80 (tức gói tin HTTP) thì giá trị DSCP sẽ là 0x14. Các gói tin không thuộc hai loại trên sẽ được đánh dấu trong trường DSCP là 0x00. Trong script trình bày ở phụ lục có rất nhiều hàm, nhiều dòng lệnh; nhưng trong đó có các dòng lệnh chính sau đây: IF='dev eth1' tc qdisc add $IF handle 1 root dsmark indices 64 tc class change $IF classid 1:1 dsmark mask 0x3 value 0x26tc class change $IF classid 1:2 dsmark mask 0x3 value 0x14tc class change $IF classid 1:3 dsmark mask 0x3 value 0x00 Match1='match ip sport 21 0xffff'Match2='match ip sport 80 0xffff'Match3='match ip src 0/0' tc filter add $IF parent 1:0 protocol ip prio 1 handle 1:0 u32 divisor 1tc filter add $IF parent 1:0 prio 1 u32 $Match1 flowid 1:1tc filter add $IF parent 1:0 prio 1 u32 $Match2 flowid 1:2tc filter add $IF parent 1:0 prio 1 u32 $Match3 flowid 1:3 Hình 4.3: Minh họa script kịch bản 1 Vì cách sử dụng lệnh tc đã được trình bày ở mục 3.2.3, nên đoạn script trên là hoàn toàn dễ hiểu. Sau đây là vài dòng mô tả cách thực thi của hệ thống khi thực thi script trên: Tất cả tác vụ đều được thực thi trên interface eth1 ( IF=’dev eth1’). Script sẽ tạo ra một cơ chế hàng đợi loại DSMARK nhờ dòng lệnh “tc qdisc add…dsmark”. Tiếp theo, nó sẽ tạo 3 lớp dịch vụ con nhờ 3 dòng lệnh “tc class”. Các lớp dịch vụ phân biệt với nhau nhờ chỉ số được chỉ định sau từ “classid” (VD: classid 1:1 , classid 1:2 và classid 1:2). Các lớp dịch vụ sẽ dùng 2 giá trị “mask” và “values” để thực hiện chức năng đánh dấu trường DSCP. Trong đó, các giá trị mask đều là 0x3 (để giữ lại giá trị của 2 bit ECN). Lớp 1:1 có “value” là 0x26, lớp 1:2 là 0x14 và lớp 1:3 là 0x00. Các “value” này cũng chính là giá trị DSCP mới cho các gói tin. Vấn đề bây giờ là làm sao để đẩy các gói tin FTP và HTTP vào đúng lớp dịch vụ mong muốn. Lệnh “tc filter” sẽ tạo ra một bộ lọc để phân loại các gói tin vào từng lớp dịch vụ. Bộ lọc này sử dụng trình phân lớp (classifier) là u32. Đây là trình phân lớp rất thường được sử dụng. Nó dựa vào các trường nằm trong IP header để phân loại gói tin. Cụ thể trong 3 dòng lệnh “tc filter” đã dùng các địa chỉ port nguồn nằm trong IP header để phân lớp. Nếu gói tin có địa chỉ port nguồn là 21 (match ip sport 21 0xffff), thì sẽ được phân vào lớp 1:1 (flowid 1:1). Tương tự, với gói tin có địa chỉ port nguồn là 80 (match ip sport 80 0xffff), thì sẽ được đẩy vào lớp 1:2 (flowid 1:2). Các gói tin không thuộc 2 loại trên thì sẽ được lớp dịch vụ 1:3 (flowid 1:3) xử lý. IV.2.3 Kiểm tra Tại bộ định tuyến nhân hoặc tại các máy trạm dùng công cụ bắt gói tin để bắt các gói tin FTP và HTTP. Sau đó quan sát trường DSCP ( nếu dùng tcpdump thì gọi là trường tos) để xem giá trị của trường DSCP. Để làm rõ chức năng chỉnh sửa giá trị trường DSCP, thì việc kiểm tra kết quả chia làm 2 giai đoạn: Trước và sau khi đánh dấu gói tin. IV.2.3.1 Trước khi đánh dấu gói tin Trong giai đoạn này, trường DSCP của các gói tin trả lời từ máy chủ luôn mang giá trị mặc định là 0x00. #tcpdump –vi eth0 src 200.0.0.2 and tcp port 21 Hình 4.4: Trước khi chỉnh sửa trường DSCP cho các gói tin FTP Gói đầu tiên trong hình 22:33:00.514666 IP (tos 0x0, ttl 63, id 37663, offset 0, flags [DF], proto: TCP (6), length: 76) 200.0.0.2.ftp > 202.0.0.2.47169: P, cksum 0x5ffa (correct), 259:283(24) ack 69 win 91 Gói tin có địa chị IP nguồn là 200.0.0.2 và có port nguồn là ftp (200.0.0.2.ftp), thì có trường tos là 0x0 (tos 0x0). #tcpdump –vi eth0 src 200.0.0.2 and tcp port 80 Hình 4.5: Trước khi chỉnh sửa trường DSCP cho các gói tin HTTP Gói đầu tiên trong hình 22:40:26.780833 IP (tos 0x0, ttl 63, id 23488, offset 0, flags [DF], proto: TCP (6), length: 52) 200.0.0.2.http > 202.0.0.2.32890: F, cksum 0xac0b (correct), 144:144(0) ack 495 win 108 Gói tin có địa chị IP nguồn là 200.0.0.2 và có port nguồn là http (200.0.0.2.http), thì có trường tos là 0x0 (tos 0x0). IV.2.3.2 Sau khi đánh dấu gói tin Nếu sau khi thực thi script editTOS.sc mà giá trị DSCP của các gói tin FTP là 0x26 và gói tin HTTP là 0x14 thì việc chỉnh sửa trường DSCP đã thành công. Tại bộ định tuyến biên thực thi 2 dòng lệnh sau: #chmod u+x editTOS.sc Cấp quyền thực thi cho file. #./editTOS.sc start Thực thi script. Tại bộ định tuyến nhân sử dụng lệnh tcpdump để bắt các gói tin ftp và http. #tcpdump –vi eth0 src 200.0.0.2 and tcp port 21 Hình 4.6: Sau khi chỉnh sửa trường DSCP cho các gói tin FTP Gói đầu tiên trong hình 02:06:33.488737 IP (tos 0x26,ECT(0), ttl 63, id 11812, offset 0, flags [DF], proto: TCP (6), length: 76) 200.0.0.2.ftp > 202.0.0.2.52376: P, cksum 0x7637 (correct), 258:282(24) ack 69 win 91 Gói tin có địa chị IP nguồn là 200.0.0.2 và có port nguồn là ftp (200.0.0.2.ftp), thì có trường tos là 0x26 (tos 0x26). #tcpdump –vi eth0 src 200.0.0.2 and tcp port 80 Hình 4.7: Sau khi chỉnh sửa trường DSCP cho các gói tin HTTP Gói đầu tiên trong hình 02:12:37.087247 IP (tos 0x14, ttl 63, id 47600, offset 0, flags [DF], proto: TCP (6), length: 52) 200.0.0.2.http > 202.0.0.2.46382: F, cksum 0x684c (correct), 144:144(0) ack 495 win 108 Gói tin có địa chị IP nguồn là 200.0.0.2 và có port nguồn là http (200.0.0.2.http), thì có trường tos là 0x14 (tos 0x14). IV.2.4 Kết luận Kịch bản 1 cùng với script editTOS.sc đã thành công trong việc chỉnh sửa giá trị trong trường DSCP của gói tin. IV.3 Kịch bản 2 Hình 4.8: Mô hình kịch bản 2 IV.3.1 Nội dung Trong kịch bản này, script qos2.sc sẽ được thực thi trên bộ định tuyến nhân. Nội dụng script được trình bày ở phần phụ lục. Chức năng của script này là dựa vào trường DSCP và địa chỉ IP đích của mỗi gói tin nhận được để bộ định tuyến nhân phân loại vào các lớp dịch vụ. Tại mỗi lớp sẽ có chính sách cho việc cấp băng thông khác nhau. Cụ thể như hình dưới đây: Hình 4.9: Chính sách băng thông cho kịch bản 2 Giả sử băng thông tổng cộng có được trên interface eth1 của bộ định tuyến nhân là BW = 1024kbit/s. Dựa vào hình trên, danh sách băng thông từng loại dịch vụ của từng máy trạm như sau: IV.3.1.1 Băng thông của máy trạm 1 Tổng băng thông trên interface eth0 của máy trạm 1 ( IP = 202.0.0.2/24): BW1 = BW x 70% = 1024 x 70% = 717 kbit/s Trong đó: Băng thông cho dịch vụ FTP là : BW1 x 50% = 717 x 50% = 359 kbit/s Băng thông cho dịch vụ HTTP là : BW1 x 30% = 717 x 30% = 215 kbit/s Băng thông cho các dịch vụ còn lại là : BW1 x 20% = 717 x 20% = 143 kbit/s IV.3.1.2 Băng thông của máy trạm 2 Tổng băng thông trên interface eth0 của máy trạm 2 ( IP = 202.0.0.3/24): BW2 = BW x 30% = 1024 x 30% = 307 kbit/s Trong đó: Băng thông cho dịch vụ FTP là : BW2 x 50% = 307 x 30% = 92 kbit/s Băng thông cho dịch vụ HTTP là : BW2 x 30% = 307 x 30% = 92 kbit/s Băng thông cho các dịch vụ còn lại là : BW2 x 20% = 307 x 40% = 123 kbit/s IV.3.2 Thực hiện Dưới đây là mô hình cơ chế hàng đợi sẽ được xây dựng bởi script qos2.sc để triển khai tất cả chính sách về băng thông vừa đề cập ở mục trên: Hình 4.10: Mô hình cơ chế hàng đợi của bộ định tuyến nhân Trong phụ lục sẽ trình bày đầy đủ nội dụng script qos2.sc. Ở đây sẽ trích ra 4 lệnh quan trọng nằm trong script để phân tích: #tc qdisc add dev eth1 root handle 1:0 htbè Lệnh tạo hàng đợi HTB có chỉ số là 1:0. #tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1024kbitè Lệnh tạo lớp dịch vụ có chỉ số là 1:1 và băng thông giới hạn của lớp này là 1024kbit/s. #tc qdisc add dev $DEV parent 1:21 handle 210: pfifo limit 10è Lệnh tạo hàng đợi pfifo (packets first in first out). Đây là hàng đợi cuối cùng mà gói tin phải đi qua. Chiều dài của hàng đợi là 10 gói tin (limit 10). #tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 match ip tos 0x26 0xff flowid 1:21è Lệnh tạo bộ lọc loại u32 (bộ lọc này dựa trên các trường nằm trong IP header). Những gói tin có địa chỉ nguồn là 202.0.0.2/24 và trường DSCP mang giá trị 0x26, thì được đẩy vào lớp dịch vụ có chỉ số 1:21. Để chạy script này trên bộ định tuyến nhân, cần thực hiện 2 lệnh: #chmod u+x qos2.sc#./qos2.sc start Vì bộ định tuyến nhân sử dụng các giá trị DSCP để phân lớp nên tại bộ định tuyến biên cũng cần thực thi script ở kịch bản 1 (editTOS.sc): #chmod u+x editTOS.sc#./editTOS.sc start IV.3.3 Kiểm tra Tại từng máy trạm, lần lượt tạo lưu lượng FTP, HTTP…đến máy máy chủ. Để cho việc kiểm tra băng thông được chính xác, cần chọn dữ liệu có dung lượng lớn để tải từ máy chủ xuống. Tại bộ định tuyến nhân, sử dụng lệnh sau để xem thông tin về các lớp dịch vụ: #tc –s class ls dev eth1 Có 3 thông tin quan trọng cần chú ý trong kết quả xuất ra: Lớp dịch vụ đang nhận xử lý gói tin Băng thông giới hạn Băng thông hiện tại Ví dụ Nếu máy trạm có địa chỉ IP là 202.0.0.2/24 đang tải dữ liệu FTP từ máy chủ xuống, thì theo mô hình cơ chế hàng đợi vừa được trình bày ở trên (hình 4.10), ta có băng thông giới hạn của lưu lượng này là 359 kbit/s. Nói cách khác lưu lượng FTP do máy trạm có địa chỉ IP là 202.0.0.2/24 truy vấn thì băng thông khi gởi truy vấn sẽ không bị giới hạn, nhưng băng thông cho các gói tin trả lời từ máy chủ về máy trạm sẽ bị thắt nút cổ chai tại interface eth1 của bộ định tuyến nhân. Mục đích của việc giới hạn này là để dành băng thông cho các dịch vụ khác (VD: HTTP, SSH,…). Do vậy, nếu một người dùng nào đó tại máy trạm đang tải dữ liệu FTP hay HTTP có dung lượng rất lớn về máy cục bộ thì vẫn không ảnh hưởng gì đến băng thông của nhau (vì mỗi dịch vụ đã có băng thông giới hạn riêng). Để làm rõ chức năng hạn chế băng thông do việc cấu hình chất lượng dịch vụ mang lại, quá trình kiểm tra sẽ gồm 2 giai đoạn: Trước và sau khi hạn chế băng thông. IV.3.3.1 Trước khi hạn chế băng thông Nếu chỉ có một lưu lượng HTTP Tại máy trạm có địa chỉ IP là 202.0.0.2 tải dữ liệu từ Web server về máy mình bằng lệnh sau: #wget 200.0.0.2/root.tar Hình 4.11: Trước khi hạn chế băng thông cho lưu lượng HTTP (tại thời điểm chỉ có duy nhất lưu lượng HTTP trên đường truyền) Nhìn vào hình trên, ta có kết luận sau: để tải dữ liệu có dung lượng 224Mb, hệ thống chỉ mất 26 giây và băng thông mà hệ thống đã cấp là 8.68 MB/s. Hệ thống đã chọn băng thông theo cơ chế cố gắng tối đa (Best Effort). Nếu có đồng thời lưu lượng HTTP và FTP Cũng với gói tin root.tar (dung lượng 242 MB) nằm trên FTP Server và HTTP Server, nếu đồng thời tải dữ liệu xuống thì băng thông tải bằng đường truyền HTTP sẽ chậm đáng kể do băng thông đã bị chia sẻ cho các dữ liệu đang tải bằng đường truyền FTP. Thực hiện đồng thời 3 dòng lệnh sau trên 3 cửa sổ terminal (mỗi cửa sổ terminal thực hiện một lệnh): #wget 200.0.0.2/root.tar #ftp 200.0.0.2 è Lệnh này thực hiện trên 2 cửa sổ terminal Username = u1 Password = 123 ftp>get root.tar Kết quả về băng thông HTTP trên máy trạm như sau: Hình 4.12: Trước khi hạn chế băng thông cho lưu lượng HTTP (tại thời điểm đường truyền có đồng thời 2 lưu lượng HTTP và FTP) Nhìn vào hình trên, ta có kết luận sau: để tải dữ liệu có dung lượng 224Mb, hệ thống đã mất 77 giây và băng thông mà hệ thống đã cấp là 2.91 MB/s. Vì cùng một thời điểm có 2 dịch vụ khác nhau cùng tải gói tin có dung lượng lớn, nên băng thông HTTP đã bị giảm đáng kể so với lúc chỉ có một lưu lượng HTTP. Cụ thể lúc chỉ có một lưu lượng HTTP thì thời gian tải gói tin là 26 giây và băng thông là 8.68 MB/s. IV.3.3.2 Sau khi hạn chế băng thông Nếu chỉ có một lưu lượng HTTP Sau khi trên bộ định tuyến nhân thực thi script qos2.sc, máy trạm có địa chỉ IP là 202.0.0.2/24 tạo lưu lượng HTTP bằng cách tải dữ liệu từ Web Server về. Thực hiện lệnh sau tại bộ định tuyến nhân để xem các gói tin HTTP từ máy chủ trả về cho máy trạm đang được xử lý ở lớp dịch vụ nào, băng thông giới hạn và băng thông hiện tại cho các gói tin đó là bao nhiêu. #tc –s class ls dev eth1 Hình 4.13: Trạng thái các lớp dịch vụ (tại bộ định tuyến nhân) khi chỉ có duy nhất lưu lượng HTTP trên đường truyền Nhìn vào hình trên, có thể nhận ra rằng các gói tin HTTP đã được xử lý tại lớp dịch vụ cha là lớp 1:1 và lớp dịch vụ con là 1:22 (các lớp dịch vụ khác đều có các số liệu băng thông hiện hành là 0bit 0pps). Vì tại một thời điểm chỉ xử lý một loại lưu lượng từ một máy trạm, nên các số liệu từ lớp dịch vụ cha 1:1 sẽ gần giống với lớp dịch vụ con 1:22. Dưới đây là các số liệu từ lớp dịch vụ con 1:22. class htb 1:22 parent 1:2 leaf 220: prio 0 rate 215000bit ceil 215000bit burst 1625b cburst 1625b Sent 5600426 bytes 3701 pkt (dropped 63, overlimits 0 requeues 0) rate 214968bit 17pps backlog 0b 8p requeues 0 lended: 3693 borrowed: 0 giants: 0 tokens: -111556 ctokens: -111556 Lớp dịch vụ này có băng thông giới hạn là 215000 bit/s ( rate 215000bit), băng thông hiện tại là 214968 bit/s 17 packets/s ( rate 214968bit 17pps) Như vậy script qos2.sc đã chạy đúng như mô hình cơ chế hàng đợi ở hình 4.10. Vì băng thông giới hạn chỉ còn 215kbit/s, nên máy trạm sẽ có tốc độ tải dữ liệu từ Web Server rất chậm. Lý do, bộ định tuyến nhân lại hạn chế băng thông qua thấp đối với lưu lượng HTTP là để chứng minh tính hiệu quả của script qos2.sc. Như vậy, script qos2.sc đã thực hiện được được nhiệm vụ giới hạn băng thông. Dưới đây là hình chụp tại máy trạm: Hình 4.14: Sau khi hạn chế băng thông cho lưu lượng HTTP (tại thời điểm chỉ có duy nhất lưu lượng HTTP trên đường truyền) Nhìn vào hình trên, ta thấy khi tải được 17% dữ liệu với băng thông là 26.3 kilobyte/s (26.3K/s), hệ thống cần 1 tiếng 48 phút (1h 48m) để hoàn tất quá trình tải dữ liệu. So với lúc chưa hạn chế băng thông (tức lúc chưa thực thi script qos2.sc), có thể nói rằng băng thông HTTP nói riêng và băng thông của từng loại dịch vụ nói chung của hệ thống máy trạm đã hoàn toàn nằm trong sự điều khiển của bộ định tuyến nhân (core router). Nếu có đồng thời lưu lượng HTTP và FTP Vì mỗi loại dịch vụ của mỗi máy trạm đều do một lớp dịch vụ riêng biệt quản lý, nên dù hệ thống máy trạm thực hiện cùng lúc việc tải dữ liệu từ HTTP Server và FTP Server thì vẫn không hề ảnh hưởng băng thông của nhau. Nhìn vào mô hình cơ chế hàng đợi ở hình 4.10, đối với các gói dữ liệu từ máy chủ về máy trạm có địa chỉ IP đích là 202.0.0.2/24, nếu đó là dữ liệu FTP thì sẽ được phân loại vào lớp dịch vụ 1:21 và có băng thông giới hạn là 359 kilobit/s, còn nếu đó dữ liệu HTTP thì sẽ được phân loại vào lớp dịch vụ 1:22 với băng thông giới hạn là 215 kilobit/s. Chú ý, đối với máy trạm có địa chỉ IP là 202.0.0.3/24 thì băng thông dành cho FTP và HTTP là 92 kilobit/s cho mỗi loại dịch vụ. Vì trước khi thực hiện chất lượng dịch vụ, máy trạm có địa chỉ IP là 202.0.0.2/24 được chọn để thử nghiệm. Nên để tiện cho việc so sánh kết quả, máy trạm này lại tiếp tục được chọn trong việc thử nghiệm về vấn đề băng thông có bị chia sẻ cho nhau khi có nhiều loại dịch vụ cùng thực hiện một lúc. Tại máy trạm tạo đồng thời các lưu lượng HTTP và FTP đến máy chủ. Sau đó tại bộ định tuyến nhân, thực hiện dòng lệnh sau để xem thông tin của từng lớp dịch vụ cũng như băng thông hiện hành của nó: #tc –s class ls dev eth1 Hình 4.15: Trạng thái các lớp dịch vụ (tại bộ định tuyến nhân) tại thời điểm đường truyền có đồng thời 2 lưu lượng HTTP và FTP Quan sát các lớp dịch vụ, chỉ thấy có 2 lớp dịch vụ con có các chỉ số khác không là lớp 1:21 và lớp 1:22. Các lớp dịch vụ con còn lại đều có các chỉ số băng thông hiện tại bằng 0. Dưới đây là đoạn trích 2 lớp dịch vụ 1:21 và 1:22. class htb 1:22 parent 1:2 leaf 220: prio 0 rate 215000bit ceil 215000bit burst 1625b cburst 1625b Sent 3704898 bytes 2449 pkt (dropped 50, overlimits 0 requeues 0) rate 214272bit 17pps backlog 0b 8p requeues 0 lended: 2441 borrowed: 0 giants: 0 tokens: -111847 ctokens: -111847 Lớp dịch vụ 1:22 là lớp dịch vụ dành cho gói tin HTTP. Băng thông hiện tại là 214272 bit/s 17 packets/s (rate 214272bit 17 pps). class htb 1:21 parent 1:2 leaf 210: prio 0 rate 359000bit ceil 359000bit burst 1643b cburst 1643b Sent 10597908 bytes 7022 pkt (dropped 314, overlimits 0 requeues 0) rate 358888bit 29pps backlog 0b 9p requeues 0 lended: 7013 borrowed: 0 giants: 0 tokens: -66455 ctokens: -65455 Lớp dịch vụ 1:21 là lớp dịch vụ dành cho gói tin FTP. Băng thông hiện tại là 358888 bit/s 29 packets/s (rate 358888bit 29 pps). class htb 1:22 parent 1:2 leaf 220: prio 0 rate 215000bit ceil 215000bit burst 1625b cburst 1625b Sent 3704898 bytes 2449 pkt (dropped 50, overlimits 0 requeues 0) rate 214272bit 17pps backlog 0b 8p requeues 0 lended: 2441 borrowed: 0 giants: 0 tokens: -111847 ctokens: -111847 Lớp dịch vụ 1:22 là lớp dịch vụ dành cho gói tin HTTP. Băng thông hiện tại là 214272 bit/s 17 packets/s (rate 214272bit 17 pps). Quan sát trên giao diện của máy trạm, trong khi đang tải dữ liệu từ FTP Server và HTTP Server thì băng thông của lưu lượng HTTP vẫn ổn định ở tốc độ 215 kbit/s. Do đó, có thể nói rằng băng thông dành cho lưu lượng HTTP vẫn luôn đảm bảo dù cho cùng thời điểm có lưu lượng FTP hay không. IV.3.4 Kết luận Trong kịch bản 2 này đã chứng minh được chức năng giới hạn băng thông cho từng loại dịch vụ cụ thể cũng như những lợi ích mà nó mang lại cho hệ thống mạng. Vì mỗi loại dịch vụ được giới hạn băng thông khác nhau, nên nhà quản trị mạng có thể đưa ra các chính sách ưu tiên đối với băng thông của từng loại dịch vụ, đảm bảo cho hệ thống mạng luôn được ổn định (đặc biệt là thời điểm có nhiều dịch vụ mạng hoạt động cùng truy xuất đến máy chủ). IV.4 Kịch bản 3 Hình 4.16: Mô hình kịch bản 3 IV.4.1 Nội dung Nếu như ở kịch bản 2, băng thông của mỗi loại dịch vụ (VD: HTTP, FTP,..) chỉ phụ thuộc vào 1 lớp dịch vụ (lớp 1:21, lớp 1:22,…) đang quản lý nó; thì ở kịch bản 3, vấn đề băng thông đã trở nên linh động hơn rất nhiều. Cụ thể, một lớp dịch vụ có thể mượn băng thông của các lớp dịch vụ cha nếu lớp dịch vụ cha còn dư băng thông. Nói cách khác, lượng băng thông mà lớp dịch vụ con có thể tăng thêm bằng với lượng băng thông đang dư ở lớp dịch vụ cha. Ví dụ như sau: Băng thông của lớp dịch vụ 1:2 là 717 kilobit/s. Lớp dịch vụ này có 3 lớp dịch vụ con là: 1:21, 1:22, 1:23 với băng thông tương ứng là 359 kbit/s, 215 kbit/s và 143 kbit/s. Như vậy, lượng băng thông tối đa mà lớp dịch vụ 1:21 có thể mượn thêm từ lớp 1:2 là 717 – 359 = 358 kbit/s. Nghĩa là một lớp dịch vụ con nhờ khả năng mượn băng thông từ lớp dịch vụ cha, nên lớp dịch vụ con có thể đạt băng thông bằng với băng thông của lớp dịch vụ cha. Việc cho phép mượn băng thông đã giải quyết hiện tượng lãng phí băng thông trên hệ thống mạng. Lợi ích của việc mượn băng thông là một lớp dịch vụ không bị gò bó băng thông mà lớp dịch vụ cha đã cấp cho riêng nó. Lớp dịch vụ con có thể mượn thêm băng thông dư thừa của lớp dịch vụ cha. Do đó, băng thông của từng loại dịch vụ vừa luôn được đảm bảo ở mức tối thiểu vừa khai thác triệt để băng thông của toàn hệ thống mạng. Đó cũng chính là mục tiêu chính của kịch bản 3. Hình 4.17: Trước và sau khi mượn băng thông IV.4.2 Thực hiện Để quy định việc mượn băng thông cho từng lớp dịch vụ, chỉ cần thêm tùy chọn “ceil ” vào từng dòng “tc class …”. Maximum_rate là giá trị băng thông tối đa mà lớp dịch vụ này đạt được sau khi đã hoàn tất việc mượn. Do vậy, chỉ cần có một chút chỉnh sửa trong script đã thực thi ở kịch bản 2 là đã có một script dành cho kịch bản 3 (xem nội dung script qos3.sc được trình bày ở phụ lục). Dưới đây là vài dòng lệnh quan trọng được trích từ script qos3.sc của kịch bản 3: tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1024kbit tc class add dev eth1 parent 1:1 classid 1:2 htb rate 717kbit ceil 1024kbit tc class add dev eth1 parent 1:1 classid 1:3 htb rate 307kbit ceil 1024kbit tc class add dev eth1 parent 1:2 classid 1:21 htb rate 359kbit ceil 717kbittc class add dev eth1 parent 1:2 classid 1:22 htb rate 215kbit ceil 717kbittc class add dev eth1 parent 1:2 classid 1:23 htb rate 143kbit ceil 717kbit tc class add dev eth1 parent 1:3 classid 1:31 htb rate 92kbit ceil 307kbittc class add dev eth1 parent 1:3 classid 1:32 htb rate 92kbit ceil 307kbittc class add dev eth1 parent 1:3 classid 1:33 htb rate 123kbit ceil 307kbit Từ script trên, ta có nhận xét sau: lớp 1:1 là lớp cha của lớp 1:2, 1:3 lớp 1:2 là lớp cha của lớp 1:21, 1:22, 1:23 lớp 1:3 là lớp cha của lớp 1:31, 1:32, 1:33 Và dưới đây là bảng băng thông quy định băng thông cho mỗi lớp dịch vụ. Lớp dịch vụ Băng thông tối thiểu (kbit/s) Băng thông tối đa (kbit/s) 1:1 1024 1024 1:2 717 1024 1:3 307 1024 1:21 359 717 1:22 215 717 1:23 143 717 1:31 92 307 1:32 92 307 1:33 123 307 Hình 4.18: Bảng băng thông quy định băng thông cho mỗi lớp dịch vụ. Để chạy script này trên bộ định tuyến nhân, cần thực hiện 2 lệnh: #chmod u+x qos3.sc #./qos3.sc start Vì bộ định tuyến nhân sử dụng các giá trị DSCP để phân lớp nên tại bộ định tuyến biên cũng cần thực thi script ở kịch bản 1 (editTOS.sc): #chmod u+x editTOS.sc #./editTOS.sc start IV.4.3 Kiểm tra IV.4.3.1 Nếu chỉ có một lưu lượng HTTP Trên bộ định tuyến nhân, thực thi script qos3.sc. Và tại máy trạm có địa chỉ IP là 202.0.0.2/24 tạo lưu lượng HTTP bằng cách tải dữ liệu từ Web Server về. Sau đó, thực hiện lệnh sau tại bộ định tuyến nhân để xem các gói tin HTTP từ máy chủ trả về cho máy trạm đang được xử lý ở lớp dịch vụ nào, băng thông tối thiểu, băng thông tối đa và băng thông hiện tại cho các gói tin đó là bao nhiêu. #tc –s class ls dev eth1 Hình 4.19: Trạng thái các lớp dịch vụ (tại bộ định tuyến nhân) khi chỉ có duy nhất lưu lượng HTTP trên đường truyền (có cơ chế mượn băng thông) Từ hình trên cho biết gói tin HTTP được hệ thống đẩy vào lớp dịch vụ 1:22 ( lớp dịch vụ cha là 1:1). Dưới đây là trạng thái của lớp dịch vụ 1:22. class htb 1:22 parent 1:2 leaf 220: prio 0 rate 215000bit ceil 717000bit burst 1625b cburst 1688b Sent 13951510 bytes 9215 pkt (dropped 124, overlimits 0 requeues 0) rate 716592bit 59pps backlog 0b 10p requeues 0 lended: 2761 borrowed: 6444 giants: 0 tokens: -36564 ctokens: -32711 Lớp dịch vụ 1:22 là lớp dịch vụ dành cho gói tin HTTP. Băng thông tối thiểu là: 215000bit/s (rate 215000bit) và băng thông tối đa có thể đạt được là 717000 bit/s (ceil 717000bit). Băng thông hiện tại là 716592 bit/s 59 packets/s (rate 716592bit 59 pps). Như vậy lớp dịch vụ 1:22 đã mượn băng thông của lớp dịch vụ cha là lớp 1:1 (nếu lớp dịch vụ 1:22 không mượn băng thông thì băng thông hiện tại của lớp này phải nhỏ hơn hoặc bằng 215000 bit/s) Từ máy trạm, kết quả băng thông có được cho việc tải file từ HTTP Server xuống như hình dưới đây: Hình 4.20: Sau khi hạn chế băng thông cho lưu lượng HTTP tại thời điểm chỉ có duy nhất lưu lượng HTTP trên đường truyền (có cơ chế mượn băng thông) Băng thông tại máy cho lưu lượng HTTP tại máy trạm là 89.4 kilobyte/s ( tức 89.4 kilobyte/s x 8 bit/byte = 715.2 kilobit/s). Giá trị băng thông này hoàn toàn đúng với cấu hình giới hạn băng thông tại bộ định tuyến nhân. IV.4.3.2 Nếu có đồng thời lưu lượng HTTP và FTP Tại bộ định tuyến nhân, thực hiện lệnh sau: #tc –s class ls dev eth1 Hình 4.21: Trạng thái lớp dịch vụ 1:22 tại bộ định tuyến nhân khi có đồng thời lưu lượng HTTP và FTP (có cơ chế mượn băng thông) Class htb 1:22 : Đây là lớp dịch vụ 1:22. Là lớp xử lý lưu lượng HTTP. Rate 215000bit ceil 717000bit: Băng thông tối thiểu là 215000 bit/s. Băng thông tối đa là 717000 bit/s. Rate 409404bit : Băng thông hiện tại là 409704 bit/s. Như vậy, lượng băng thông mà lớp dịch vụ 1:22 đã mượn từ lớp dịch vụ cha 1:2 là 409404 – 215000 = 194404 bit/s. Hình 4.22: Trạng thái lớp dịch vụ 1:21 tại bộ định tuyến nhân khi có đồng thời lưu lượng HTTP và FTP (có cơ chế mượn băng thông) Class htb 1:21 : Đây là lớp dịch vụ 1:21. Là lớp xử lý lưu lượng FTP. Rate 359000bit ceil 717000bit: Băng thông tối thiểu là 359000 bit/s. Băng thông tối đa là 717000 bit/s. Rate 617456bit : Băng thông hiện tại là 617456 bit/s. Như vậy, lượng băng thông mà lớp dịch vụ 1:21 đã mượn từ lớp dịch vụ cha 1:2 là 617456 – 359000 = 258456 bit/s. Như vậy, tổng lượng băng thông mà lớp dịch vụ cha 1:2 đã cho mượn là: 194404 + 258456 = 452860 bit/s. Chú ý, lớp dịch vụ 1:2 lại là con của lớp dịch vụ 1:1 nên nó có quyền mượn băng thông của lớp dịch vụ cha 1:1. Tại máy trạm, băng thông dành cho lưu lượng HTTP như hình sau: Hình 4.23: Sau khi hạn chế băng thông cho lưu lượng HTTP tại thời điểm đường truyền có đồng thời 2 lưu lượng HTTP và FTP (có cơ chế mượn băng thông) Như vậy, băng thông dành cho lưu lượng HTTP là: 59.7 Kilobyte/s (tức 59.7 Kilobyte/s x 8 bit/byte = 477.6 Kilobit/s). Lượng băng thông HTTP quan sát được tại bộ định tuyến nhân là 409404 bit/s. Còn đây là băng thông dành cho lưu lượng FTP tại máy trạm: Hình 4.24: Sau khi hạn chế băng thông cho lưu lượng FTP tại thời điểm đường truyền có đồng thời 2 lưu lượng HTTP và FTP (có cơ chế mượn băng thông) Như vậy, băng thông dành cho lưu lượng FTP là: 77 Kilobyte/s (tức 77 Kilobyte/s x 8 bit/byte = 616 Kilobit/s). Lượng băng thông HTTP quan sát được tại bộ định tuyến nhân là 617456 bit/s. Vì thời điểm quan sát tại bộ định tuyến nhân chưa đúng lúc nên 2 giá trị băng thông tại bộ định tuyến nhân và băng thông tại máy trạm có độ chênh lệnh. Vì độ chênh lệnh này rất nhỏ, nên có thể xem như việc hạn chế băng thông, cũng như việc cho mượn băng thông tại bộ định tuyến nhân đã hoạt động rất tốt. IV.4.4 Kết luận Kịch bản 3 đã áp dụng thành công cơ chế mượn băng thông trong việc triển khai chất lượng dịch vụ trên Linux. Lợi ích mà cơ chế mượn băng thông đã mang lại cho hệ thống mạng đó chính là khắc phục hiện tượng lãng phí băng thông. Kịch bản 3 đã đáp ứng hai vấn đề liên quan đến chất lượng dịch vụ mạng đó là: Đảm bảo băng thông tối thiểu cho từng loại dịch vụ. Sử dụng triệt để băng thông của hệ thống (nhờ cơ chế mượn băng thông). CHƯƠNG V KẾT LUẬN V.1 Tóm lược vấn đề Đồ án đã trình bày những vấn đề trọng tâm nhất trong việc triển khai chất lượng dịch vụ mạng. Đồ án gồm 5 chương. Trong số đó có 3 chương trọng tâm đó là: chương II, chương III và chương IV. Chương II là chương chuyên về lý thuyết QoS. Chương này đã trình bày chi tiết về QoS nói chung và QoS trên Linux. Đối với lý thuyết về QoS trên Linux, vì mô hình phân biệt dịch vụ (DiffServ) có nhiều ưu điểm hơn so với mô hình tích hợp dịch dịch vụ (IntServ), nên chương II đã trình bày rất kĩ về mô hình phân biệt dịch vụ. Đây chính là nền tảng kiến thức cần thiết để chương III và chương IV áp dụng vào thực nghiệm. Mô hình hệ thống trong chương III và các kịch bản trong chương IV đã sử dụng mô hình phân biệt dịch vụ để triển khai chất lượng dịch vụ mạng. Mục đích của hai chương này là sử dụng mô hình mạng thực tế và demo thật chi tiết để làm nổi bật các tính năng QoS mà linux đang hỗ trợ. Cụ thể, trong đồ án này đã triển khai được 3 tính năng hay về chất lượng dịch vụ trong linux đó là: Chỉnh sửa giá trị trường DSCP của gói tin. Hạn chế băng thông – không cho phép mượn băng thông. Hạn chế băng thông – cho phép mượn băng thông. Mục đích chính của đồ án là nghiên cứu việc triển khai chất lượng dịch vụ trên hệ thống mã nguồn mở. Đối tượng hướng đến của đồ án là các công ty có quy mô vừa và nhỏ. V.2 Phương pháp giải quyết Vì các công ty vừa và nhỏ không có đủ kinh phí để trang bị các thiết bị định tuyến chuyên dụng dựa trên phần cứng như là các bộ định tuyến của hãng cisco hay là hãng juniper; nên các công ty đó cần tìm một thiết bị khác vừa rẻ vừa đáp ứng nhu cầu định tuyến cũng như có thể triển khai chất lượng dịch vụ mạng. Và Linux là một giải pháp hoàn hảo cho các công ty như vậy. Lý do thật đơn giản: Linux là một hệ điều hành mã nguồn mở, có thể biến thành một bộ định tuyến mềm hay triển khai chất lượng dịch vụ mạng chỉ bằng vài dòng lệnh cơ bản. Vì không phải là thiết bị chuyên dụng về định tuyến hay là thiết bị chuyên dụng về chất lượng dịch vụ mạng, nên năng lực và tốc độ xử lý của linux chỉ có thể đáp ứng nhu cầu cho công ty vừa và nhỏ. Với những lợi điểm do linux mang lại, ngày nay hệ điều hành linux đang dần trở nên phổ biến trong hệ thống máy chủ của các công ty. Đồ án đã chọn mô hình phân biệt dịch vụ (DiffServ) để triển khai chất lượng dịch vụ thông qua bộ định tuyến mềm chạy trên hệ thống linux. Mô hình phân biệt dịch vụ đó được thể hiện rõ nét qua mô hình hệ thống mà đồ án đưa ra ở chương III. Trong mô hình hệ thống này gồm 2 bộ định tuyến là bộ định tuyến biên (edge router) và bộ định tuyến nhân (core router). Cả 2 bộ định tuyến này đều chạy trên hệ điều hành linux. Chức năng của bộ định tuyến biên đó là phân lớp (classification) cho các gói tin dựa vào các trường của gói tin như: địa chỉ ip nguồn, địa chỉ ip đích, port nguồn, port đích,…Tiếp theo, bộ định tuyến biên sẽ đánh dấu vào trường DSCP của các gói tin rồi chuyển tiếp các gói tin này qua bộ định tuyến nhân. Tại bộ định tuyến nhân, giá trị các trường DSCP sẽ là tiêu chí đánh giá để phân vào các lớp dịch vụ. Tại mỗi lớp dịch vụ sẽ có các chính sách chất lượng dịch vụ khác nhau như: Hạn chế băng thông – không cho phép mượn băng thông hoặc hạn chế băng thông – cho phép mượn băng thông,…Hai bộ định tuyến này đã làm rõ cơ chế hoạt động của mô hình phân biệt dịch vụ và đã chứng tỏ rằng linux có thể triển khai chất lượng dịch vụ rất hiệu quả. V.3 Kết quả đạt được Sau khi hoàn tất quá trình nghiên cứu đề tài “QoS trên Linux”, kiến thức về QoS nói chung và đặc biệt QoS trên linux được trau dồi. Trong đó: Chương II đã trang bị nền tảng lý thuyết về QoS như: các tiêu chí đánh giá, mô hình tích hợp dịch vụ, mô hình phân biệt dịch vụ…Đặc biệt chương này đã ưu tiên trình bày rất chi tiết mô hình phân biệt dịch vụ (DiffServ) trên Linux. Đây chính là mô hình sẽ được triển khai ở hai chương tiếp theo. Với chương III và chương IV, đây là hai chương vận dụng nền tảng lý thuyết ở chương II vào thực tiễn. Quá trình áp dụng từ lý thuyết vào thực hành đã gặp rất nhiều thắc mắc, khó khăn. Nhưng sau khi vượt qua các thử thách đó, sự am hiểu về chất lượng dịch vụ trở nên sâu sắc hơn. Mô hình hệ thống ở chương III cùng với ba kịch bản ở chương IV đã làm rõ được chức năng chất lượng dịch vụ trên Linux. Thật vậy, ba kịch bản chính là cơ hội để biết cách cấu hình, triển khai chất lượng dịch vụ trên Linux bao gồm: Chỉnh sửa giá trị trường DSCP. Hạn chế băng thông – không cho phép mượn băng thông. Hạn chế băng thông – cho phép mượn băng thông. Qua đó, đã hiểu rõ cũng như có khả năng triển khai chất lượng dịch vụ trên Linux cho hệ thống mạng của một công ty. Vì hiện nay có rất nhiều công ty vừa và nhỏ đang dùng linux để làm thiết bị triển khai QoS nên có thể nói rằng đồ án này mang tính thực tiễn rất cao. V.4 Điểm nổi bật Có thể nói rằng xuyên suốt các phần của đồ án đều là những lý thuyết chọn lọc về QoS nói chung cùng với QoS trên Linux. Trong số chúng, kịch bản 3 của chương IV chính là điểm nổi bật nhất của đồ án. Lý do chính là kịch bản này đã thể hiện đầy đủ mục đích của đồ án. Dưới đây là 2 điểm nổi bật trong kịch bản 3: V.4.1 Triển khai mô hình phân biệt dịch vụ Mô hình chất lượng dịch vụ mà kịch bản 3 áp dụng đó là mô hình phân biệt dịch vụ (DiffServ). Mô hình này gồm 2 bộ định tuyến đó là: bộ định tuyến biên (edge router) và bộ định tuyến nhân (core router). Trong đó, bộ định tuyến biên làm nhiệm vụ dựa vào các trường nằm trong IP header để phân loại các gói tin vào các lớp dịch vụ. Mỗi lớp dịch vụ sẽ có chính sách khác nhau trong việc sửa giá trị trong trường DSCP của mỗi gói tin. Do đó, một số gói tin khi đi ra bộ định tuyến biên sẽ có giá trị trong trường DSCP khác với lúc mà nó đã đi vào bộ định tuyến biên. Giá trị DSCP sẽ là tiêu chí để bộ định tuyến nhân xem xét gói tin nào có độ ưu tiên xếp vào hàng đợi và khả năng mất gói. Giá trị DSCP sẽ thật sự hữu dụng khi có sự nghẽn mạng xảy ra. Như vậy vai trò bộ định tuyến nhân rất quan trọng trong việc triển khai chất lượng dịch vụ. Ngoài ra, bộ định tuyến nhân cũng sử dụng giá trị DSCP để phân vào các lớp dịch vụ. Mỗi lớp dịch vụ sẽ có chính sách chất lượng dịch vụ khác nhau. Ví dụ trong kịch bản 3 này, các lớp dịch vụ ở bộ định tuyến nhân đã sử dụng cơ chế hàng đợi là HTB. Đây là cơ chế hàng đợi thường được dùng để hạn chế băng thông. Vì mô hình phân biệt dịch vụ thể hiện nhưng ưu điểm vượt trội hơn so với mô hình tích hợp dịch vụ, nên việc triển khai mô hình phân biệt dịch vụ chính là mục đích đầu tiên của đồ án. V.4.2 Tính linh động trong việc triển khai chất lượng dịch vụ Tính linh động trong việc triển khai chất lượng dịch vụ ở kịch bản 3 được thể hiện rất rõ thông qua tính năng cho phép mượn băng thông của các lớp dịch vụ. Mỗi lớp dịch vụ được cấp một băng thông tối thiểu dành cho riêng lớp đó. Nghĩa là trong trường hợp có nhiều loại lưu lượng của nhiều lớp dịch vụ đang cùng chiếm băng thông trên mạng thì mỗi loại lưu lượng luôn có lượng băng thông tối thiểu được cấp phát cho riêng nó. Lợi ích có được từ việc định ra băng thông tối thiểu cho từng lớp dịch vụ chính là đảm bảo cho lưu lượng của từng loại dịch vụ luôn có thể hoạt động ổn định, không bị ảnh hưởng bởi các loại lưu lượng khác. Vấn đề đặt ra là nếu trong thời điểm có lớp dịch vụ không sử dụng hoặc sử dụng không hết băng thông của nó, trong khi đó có một lớp dịch vụ khác đang thiếu băng thông, thì làm sao để lượng băng thông dư thừa của lớp dịch vụ này được chia sẻ cho lớp dịch vụ khác đang thiếu. Do vậy kĩ thuật cho phép mượn băng thông đã ra đời. Cụ thể như sau, lớp dịch vụ con có thể mượn thêm băng thông của lớp dịch vụ cha nếu lớp dịch vụ cha đang dư băng thông. Có nghĩa là mỗi lớp dịch vụ đều có lượng băng thông tối thiểu, nhưng nó không hề bị gò bó trong việc chỉ được sử dụng chừng đó băng thông mà băng thông thực sự của nó có thể lớn hơn rất nhiều nhờ việc mượn băng thông dư thừa của lớp dịch vụ cha. Như vậy băng thông của toàn hệ thống mạng đã được sử dụng triệt để, khắc phục được tình trạng lãng phí băng thông. V.5 Hạn chế Vì chất lượng dịch vụ mạng có rất nhiều vấn đề liên quan, nên trong khuôn khổ đồ án không thể trình bày đầy đủ được. Ví dụ: Trong linux hỗ trợ rất nhiều cơ chế hàng đợi (queuing discipline) như: Asynchronous Transfer Mode (ATM), Stochastic Fair Queuing (SFQ), Random Early Detection (RED)…Nhưng trong đồ án, chỉ trình bày kĩ hai cơ chế hàng đợi được sử dụng phổ biến hiện nay đó là: Diff-Serv Marker (DS_MARK) và Hierarchical Token Bucket (HTB). DS_MARK được triển khai ở kịch bản 1. HTB được triển khai ở kịch bản 2 và 3. Ngoài thuật ngữ “cơ chế hàng đợi”, chất lượng dịch vụ còn có một thuật ngữ khác không kém phần quan trọng đó chính là bộ phân lớp (classifier). Linux hỗ trợ khá nhiều loại như: fw, route, tcindex,...Trong số đó, bộ phân lớp u32 được xem là bộ phân lớp cao cấp nhất. Bộ phân lớp này có thể dựa vào bất kì trường nào nằm trong IP header của một gói tin để phân lớp. Các kịch bản 1, 2 và 3 chỉ sử dụng bộ phân lớp này mà chưa thử nghiệm với các bộ phân lớp khác. Mô hình phân biệt dịch vụ có nhiều đặc tính hay hơn mô hình tích hợp dịch vụ. Tuy vậy, trong đồ án chưa trình bày và triển khai song song hai mô hình để có thể thấy rõ sự khác biệt. V.6 Phương hướng mở rộng đề tài Từ những hạn chế đã trình bày ở mục V.6, phương hướng mở rộng đề tài chính là khắc phục tất cả các hạn chế đó. Mỗi cơ chế hàng đợi hay là mỗi bộ phân lớp đều có những ưu điểm và nhược điểm riêng. Do vậy, để có thể tối ưu trong việc triển khai chất lượng dịch vụ trên hệ thống linux, cần phải hiểu tất cả loại mà linux đang hỗ trợ. TÀI LIỆU THAM KHẢO [1] [2] [3] [4] PHỤ LỤC Tên script: editTOS.scMục đích: Chỉnh sửa trường DSCP cho các gói tin Kịch bản áp dụng: 1, 2, 3 #! /bin/bash IF='dev eth1' start(){ tc qdisc add $IF handle 1 root dsmark indices 64 tc class change $IF classid 1:1 dsmark mask 0x3 value 0x26 tc class change $IF classid 1:2 dsmark mask 0x3 value 0x14 tc class change $IF classid 1:3 dsmark mask 0x3 value 0x00 Match1='match ip sport 21 0xffff' Match2='match ip sport 80 0xffff' Match3='match ip src 0/0' tc filter add $IF parent 1:0 protocol ip prio 1 handle 1:0 u32 divisor 1 tc filter add $IF parent 1:0 prio 1 u32 $Match1 flowid 1:1 tc filter add $IF parent 1:0 prio 1 u32 $Match2 flowid 1:2 tc filter add $IF parent 1:0 prio 1 u32 $Match3 flowid 1:3} stop(){ tc qdisc del $IF root} restart(){ stop sleep 1 start} show(){ tc -s qdisc ls $IF} #------------------------- Main --------------------------- case "$1" in start)  echo -n "Starting Marking: " start echo "[OK]" ;; stop) echo -n "Stopping Marking: " stop echo "[OK]" ;; restart) echo -n "Restarting Marking: " restart echo "[OK]" ;; show) echo -n "Status of queuing discipline $DEV: " show ;; *) echo "Usage: ./qos2.sc {start|stop|restart|show}" exit 1 esac exit $? Tên script: qos2.sc Mục đích: Giới hạn băng thông – không cho phép mượn băng thông Kịch bản áp dụng: 2 #!/bin/bash DEV="dev eth1" start() { tc qdisc add $DEV root handle 1: htb tc class add $DEV parent 1:0 classid 1:1 htb rate 1024kbit tc class add $DEV parent 1:1 classid 1:2 htb rate 717kbit tc class add $DEV parent 1:1 classid 1:3 htb rate 307kbit tc class add $DEV parent 1:2 classid 1:21 htb rate 359kbit tc class add $DEV parent 1:2 classid 1:22 htb rate 215kbit tc class add $DEV parent 1:2 classid 1:23 htb rate 143kbit tc class add $DEV parent 1:3 classid 1:31 htb rate 92kbit tc class add $DEV parent 1:3 classid 1:32 htb rate 92kbit tc class add $DEV parent 1:3 classid 1:33 htb rate 123kbit tc qdisc add $DEV parent 1:21 handle 210: pfifo limit 10 tc qdisc add $DEV parent 1:22 handle 220: pfifo limit 10 tc qdisc add $DEV parent 1:23 handle 230: pfifo limit 10 tc qdisc add $DEV parent 1:31 handle 310: pfifo limit 10 tc qdisc add $DEV parent 1:32 handle 320: pfifo limit 10 tc qdisc add $DEV parent 1:33 handle 330: pfifo limit 10 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 match ip tos 0x26 0xff flowid 1:21 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 match ip tos 0x14 0xff flowid 1:22 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 flowid 1:23 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.3/24 match ip tos 0x26 0xff flowid 1:31 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.3/24 match ip tos 0x14 0xff flowid 1:32 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.3/24 flowid 1:33 } stop() { tc qdisc del $DEV root } restart() { stop sleep 1 start } show() { tc -s class ls $DEV } #------------ Main ------------------- case "$1" in start) echo -n "Starting QoS: " start echo "[0K]" ;; stop) echo -n "Stopping QoS: " stop echo "[0K]" ;; restart) echo -n "Restarting QoS: " restart echo "[0K]" ;; show) echo "Status for each classes: " show ;; *) echo "Usage: $0 {start|stop|restart|show}" exit 1 esac exit $? Tên script: qos3.sc Mục đích: Giới hạn băng thông –cho phép mượn băng thông Kịch bản áp dụng: 3 #!/bin/bash DEV="dev eth1" start() { tc qdisc add $DEV root handle 1: htb tc class add $DEV parent 1:0 classid 1:1 htb rate 1024kbit tc class add $DEV parent 1:1 classid 1:2 htb rate 717kbit ceil 1024kbit tc class add $DEV parent 1:1 classid 1:3 htb rate 307kbit ceil 1024kbit tc class add $DEV parent 1:2 classid 1:21 htb rate 359kbit ceil 717kbit tc class add $DEV parent 1:2 classid 1:22 htb rate 215kbit ceil 717kbit tc class add $DEV parent 1:2 classid 1:23 htb rate 143kbit ceil 717kbit tc class add $DEV parent 1:3 classid 1:31 htb rate 92kbit ceil 307kbit tc class add $DEV parent 1:3 classid 1:32 htb rate 92kbit ceil 307kbit tc class add $DEV parent 1:3 classid 1:33 htb rate 123kbit ceil 307kbit tc qdisc add $DEV parent 1:21 handle 210: pfifo limit 10 tc qdisc add $DEV parent 1:22 handle 220: pfifo limit 10 tc qdisc add $DEV parent 1:23 handle 230: pfifo limit 10 tc qdisc add $DEV parent 1:31 handle 310: pfifo limit 10 tc qdisc add $DEV parent 1:32 handle 320: pfifo limit 10 tc qdisc add $DEV parent 1:33 handle 330: pfifo limit 10 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 match ip tos 0x26 0xff flowid 1:21 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 match ip tos 0x14 0xff flowid 1:22 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.2/24 flowid 1:23 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.3/24 match ip tos 0x26 0xff flowid 1:31 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.3/24 match ip tos 0x14 0xff flowid 1:32 tc filter add $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 202.0.0.3/24 flowid 1:33 } stop() { tc qdisc del $DEV root } restart() { stop sleep 1 start } show() { tc -s class ls $DEV } #------------ Main ------------------- case "$1" in start) echo -n "Starting QoS: " start echo "[0K]" ;; stop) echo -n "Stopping QoS: " stop echo "[0K]" ;; restart) echo -n "Restarting QoS: " restart echo "[0K]" ;; show) echo "Status for each classes: " show ;; *) echo "Usage: $0 {start|stop|restart|show}" exit 1 esac exit $?