Tôi muốn thêm một số loại quản lý lưu lượng vào đường truyền Internet của chúng tôi. Sau khi đọc rất nhiều tài liệu, tôi nghĩ HFSC quá phức tạp đối với tôi (tôi không hiểu tất cả các công cụ về đường cong, tôi sợ rằng tôi sẽ không bao giờ hiểu đúng), CBQ không khuyến nghị và về cơ bản HTB là cách để đi cho hầu hết mọi người.
Mạng nội bộ của chúng tôi có ba "phân khúc" và tôi muốn chia sẻ băng thông nhiều hơn hoặc ít hơn giữa các phân đoạn đó (ít nhất là vào lúc bắt đầu). Hơn nữa tôi phải ưu tiên lưu lượng theo ít nhất ba loại lưu lượng (lưu lượng thời gian thực, lưu lượng tiêu chuẩn và lưu lượng lớn). Việc chia sẻ băng thông không quan trọng bằng thực tế là lưu lượng thời gian thực phải luôn được coi là lưu lượng cao cấp bất cứ khi nào có thể, nhưng tất nhiên không có lớp lưu lượng nào khác có thể chết đói.
Câu hỏi là, điều gì có ý nghĩa hơn và cũng đảm bảo thông lượng thời gian thực tốt hơn:
Tạo một lớp cho mỗi phân khúc, mỗi lớp có cùng một tỷ lệ (mức độ ưu tiên không quan trọng đối với các lớp không có lá theo nhà phát triển HTB) và mỗi lớp này có ba lớp con (lá) cho 3 cấp độ ưu tiên (với các mức độ ưu tiên khác nhau và tỷ lệ khác nhau).
Có một lớp trên mỗi mức độ ưu tiên, mỗi lớp có một tỷ lệ khác nhau (một lần nữa mức độ ưu tiên sẽ không thành vấn đề) và mỗi lớp có 3 lớp con, một lớp cho mỗi phân khúc, trong khi cả 3 lớp trong thời gian thực đều có số lượng cao nhất, hạng thấp nhất lớp, vân vân.
Tôi sẽ cố gắng làm cho điều này rõ ràng hơn với hình ảnh nghệ thuật ASCII sau đây:
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
Trường hợp 1 Có vẻ như cách mà hầu hết mọi người sẽ làm, nhưng trừ khi tôi không đọc chính xác các chi tiết triển khai HTB, Trường hợp 2 có thể ưu tiên tốt hơn.
Hướng dẫn HTB nói rằng, nếu một lớp đã đạt được tỷ lệ của nó, nó có thể vay từ cha mẹ của nó và khi vay, các lớp có mức độ ưu tiên cao hơn luôn được cung cấp băng thông trước. Tuy nhiên, nó cũng nói rằng các lớp có băng thông khả dụng ở cấp độ cây thấp hơn luôn được ưu tiên hơn các lớp ở cấp độ cây cao hơn, bất kể mức độ ưu tiên .
Giả sử tình huống sau: Phân đoạn C sẽ không gửi bất kỳ lưu lượng truy cập nào. Phân đoạn A chỉ gửi lưu lượng thời gian thực, nhanh nhất có thể (đủ để bão hòa liên kết một mình) và Phân đoạn B chỉ gửi lưu lượng lớn, nhanh nhất có thể (một lần nữa, đủ để bão hòa toàn bộ liên kết một mình). Chuyện gì sẽ xảy ra?
Trường hợp 1:
Phân đoạn A-> Giải thưởng cao và Phân khúc B-> Giải thưởng thấp đều có các gói để gửi, vì A-> Giải thưởng cao có mức độ ưu tiên cao hơn, nó sẽ luôn được lên lịch trước, cho đến khi đạt tỷ lệ. Bây giờ nó cố gắng vay từ Phân đoạn A, nhưng vì Phân đoạn A ở cấp độ cao hơn và Phân khúc B-> Low Prio chưa đạt được tỷ lệ của nó, lớp này hiện được phục vụ trước, cho đến khi nó cũng đạt tỷ lệ và muốn vay từ Phân đoạn B. Một khi cả hai đã đạt được tỷ lệ của mình, cả hai đều ở cùng cấp một lần nữa và bây giờ Phân đoạn A-> Giải thưởng cao sẽ lại giành chiến thắng, cho đến khi đạt được tỷ lệ của Phân đoạn A. Bây giờ, nó cố gắng vay từ gốc (đã có nhiều lưu lượng dự phòng, vì Phân đoạn C không sử dụng bất kỳ lưu lượng được bảo đảm nào của nó), nhưng một lần nữa, nó phải chờ Phân đoạn B-> Giải thưởng thấp cũng đạt đến cấp độ gốc. Một khi điều đó xảy ra,
Trường hợp 2:
High Prio-> Segment A và Low Prio-> Segment B đều có các gói để gửi, một lần nữa High Prio-> Segment A sẽ giành chiến thắng vì nó có mức độ ưu tiên cao hơn. Khi nó đạt đến tốc độ của nó, nó cố gắng mượn từ High Prio, có băng thông dự phòng, nhưng ở mức cao hơn, nó phải đợi Low Prio-> Segment B một lần nữa để đạt được tốc độ của nó. Khi cả hai đã đạt được tỷ lệ của mình và cả hai đều phải vay, High Prio-> Segment A sẽ giành chiến thắng một lần nữa cho đến khi đạt được tỷ lệ của lớp High Prio. Khi điều đó xảy ra, nó cố gắng mượn từ root, một lần nữa có rất nhiều băng thông (tất cả băng thông của Prio bình thường không được sử dụng vào lúc này), nhưng nó phải đợi một lần nữa cho đến khi Low Prio-> Phân đoạn B đạt đến giới hạn tốc độ của Lớp Prio thấp và cũng cố gắng mượn từ root. Cuối cùng, cả hai lớp đều cố gắng mượn từ root, mức độ ưu tiên được tính đến và High Prio->
Cả hai trường hợp đều có vẻ không tối ưu, vì cả hai cách lưu lượng thời gian thực đôi khi phải chờ lưu lượng lớn, mặc dù có rất nhiều băng thông còn lại nó có thể mượn. Tuy nhiên, trong trường hợp 2, có vẻ như lưu lượng truy cập thời gian thực phải chờ ít hơn so với trường hợp 1, vì nó chỉ phải đợi cho đến khi tốc độ lưu lượng lớn bị ảnh hưởng, rất có thể thấp hơn tốc độ của toàn bộ phân khúc (và trong trường hợp 1 đó là tỷ lệ nó phải chờ). Hay tôi hoàn toàn sai ở đây?
Tôi nghĩ về các thiết lập thậm chí đơn giản hơn, sử dụng một qdisc ưu tiên. Nhưng hàng đợi ưu tiên có vấn đề lớn là chúng gây ra chết đói nếu chúng không bị giới hạn. Đói không được chấp nhận. Tất nhiên, người ta có thể đặt TBF (Bộ lọc mã thông báo) vào từng lớp ưu tiên để hạn chế tốc độ và do đó tránh bị đói, nhưng khi làm như vậy, một lớp ưu tiên duy nhất không thể tự bão hòa liên kết nữa, ngay cả khi tất cả các lớp ưu tiên khác trống rỗng, TBF sẽ ngăn điều đó xảy ra. Và điều này cũng không tối ưu, vì tại sao một lớp sẽ không nhận được 100% băng thông của dòng nếu không có lớp nào khác cần bất kỳ lớp nào vào lúc này?
Bất kỳ ý kiến hoặc ý tưởng liên quan đến thiết lập này? Có vẻ như rất khó để làm bằng cách sử dụng qciscs tc tiêu chuẩn. Là một lập trình viên, đó là một nhiệm vụ dễ dàng nếu tôi có thể đơn giản viết lịch trình của riêng mình (điều mà tôi không được phép làm).