인터넷 회선에 일종의 트래픽 관리를 추가하고 싶습니다. 많은 문서를 읽은 후 HFSC가 나에게 너무 복잡하다고 생각합니다 (모든 곡선을 이해하지 못합니다. 정확하지 않을 것입니다) .CBQ는 권장되지 않으며 기본적으로 HTB가 방법입니다. 대부분의 사람들을 위해 가십시오.
우리의 내부 네트워크에는 세 개의 "세그먼트"가 있으며 대역폭을 최소한 (초기) 최소한 동일하게 공유하고 싶습니다. 또한 3 가지 종류의 트래픽 (실시간 트래픽, 표준 트래픽 및 대량 트래픽)에 따라 트래픽의 우선 순위를 지정해야합니다. 대역폭 공유는 실시간 트래픽이 가능할 때마다 항상 프리미엄 트래픽으로 처리되어야한다는 사실만큼 중요하지는 않지만, 다른 트래픽 클래스도 굶주릴 수는 없습니다.
문제는 더 의미가 있고 더 나은 실시간 처리량을 보장하는 것입니다.
세그먼트 당 하나의 클래스를 작성하십시오. 각 클래스는 동일한 비율을 갖습니다 (우선 순위는 HTB 개발자에 따라 휴가가없는 클래스의 경우 중요하지 않음). 각 클래스에는 우선 순위가 다른 3 개의 우선 순위 레벨에 대해 3 개의 서브 클래스 (리브)가 있습니다. 다른 요금).
우선 순위 수준 당 하나의 클래스가 있으며 각 클래스마다 다른 비율 (다시 우선 순위는 중요하지 않음)이 있고 각각 세그먼트 당 하나씩 3 개의 하위 클래스가 있습니다. 반면에 실시간 클래스의 3 개는 모두 가장 높은 prio, 가장 낮은 prio를 갖습니다. 수업 등.
다음 ASCII 아트 이미지를 사용하여 더 명확하게 만들려고합니다.
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
사례 1 대부분의 사람들이하는 방식처럼 보이지만 HTB 구현 세부 정보를 제대로 읽지 않으면 사례 2의 우선 순위가 더 높아질 수 있습니다.
HTB 매뉴얼에 따르면 클래스가 속도에 도달하면 부모로부터 빌릴 수 있으며 빌릴 때 우선 순위가 높은 클래스는 항상 대역폭이 먼저 제공됩니다. 그러나 낮은 트리 수준에서 사용 가능한 대역폭을 가진 클래스 는 우선 순위에 관계없이 항상 높은 트리 수준의 클래스보다 선호됩니다 .
다음과 같은 상황을 가정 해 보겠습니다. 세그먼트 C가 트래픽을 보내지 않습니다. 세그먼트 A는 가능한 한 빨리 (링크 만 포화시키기에 충분한) 실시간 트래픽 만 전송하고 세그먼트 B는 가능한 한 빨리 (전체 링크 만 포화시키기에 충분한) 대량 트래픽 만 전송합니다. 무슨 일이 일어날 것?
사례 1 :
A-> 높은 Prio 세그먼트와 B-> 낮은 Prio 세그먼트에는 모두 전송할 패킷이 있습니다. 이제 세그먼트 A에서 빌리려고하지만 세그먼트 A가 더 높은 레벨에 있고 세그먼트 B-> 낮은 Prio가 아직 이율에 도달하지 않았으므로이 클래스는 이제 이율에 도달하여 빌리기를 원할 때까지 먼저 제공됩니다. 세그먼트 B. 일단 둘 다 요율에 도달하면 둘 다 다시 같은 레벨에있게됩니다. 이제 세그먼트 A-> 고위 Prio는 세그먼트 A의 비율에 도달 할 때까지 다시 이길 것입니다. 이제 루트에서 빌리려고합니다. 세그먼트 C는 보장 된 트래픽을 사용하지 않기 때문에 트래픽 여유가 충분하지만 세그먼트 B-> 낮은 Prio가 루트 수준에 도달 할 때까지 기다려야합니다. 그런 일이 생기면
사례 2 :
High Prio-> Segment A 및 Low Prio-> Segment B에는 둘 다 보낼 패킷이 있으며 High Prio-> Segment A는 우선 순위가 높을수록 이기게됩니다. 일단 속도에 도달하면 대역폭이 부족한 High Prio에서 빌리려고 시도하지만 더 높은 레벨에 있으면 Low Prio-> Segment B가 다시 그 속도에 도달 할 때까지 기다려야합니다. 둘 다 금리에 도달하고 모두 빌려야하는 경우 High Prio-> Segment A는 High Prio 클래스의 속도에 도달 할 때까지 다시 승리합니다. 그런 일이 발생하면 루트에서 차용을 시도하는데, 다시 충분한 대역폭이 남아 있습니다 (현재 일반 Prio의 모든 대역폭이 사용되지 않음). 낮은 Prio-> 세그먼트 B가 낮은 Prio 클래스와 루트에서 빌리려고 시도합니다. 마지막으로 두 클래스 모두 루트에서 빌리려고 시도하고 우선 순위가 고려되며 High Prio->
실시간 트래픽이 차용 할 수있는 충분한 대역폭이 남아 있지만 대량 트래픽을 기다려야하는 경우가 있기 때문에 두 경우 모두 최적이 아닌 것 같습니다. 그러나 2의 경우 실시간 트래픽이 1의 경우보다 덜 기다려야하는 것처럼 보입니다. 벌크 트래픽 속도에 도달 할 때까지만 기다려야하므로 전체 세그먼트의 속도보다 낮을 가능성이 높습니다. 1) 대기해야하는 속도입니다. 아니면 내가 완전히 틀렸습니까?
우선 순위 qdisc를 사용하여 더 간단한 설정에 대해 생각했습니다. 그러나 우선 순위 대기열은 어떻게 든 제한되지 않으면 기아를 유발한다는 큰 문제가 있습니다. 기아는 허용되지 않습니다. 물론 속도를 제한하고 기아를 피하기 위해 TBF (Token Bucket Filter)를 각 우선 순위 클래스에 넣을 수 있지만 그렇게하면 단일 우선 순위 클래스가 다른 모든 우선 순위 클래스 인 경우에도 링크를 더 이상 포화시킬 수 없습니다 TBF가 비어 있으면이를 방지 할 수 있습니다. 그리고 다른 클래스가 현재 필요하지 않은 클래스가 왜 회선 대역폭의 100 %를 얻지 못합니까?
이 설정에 대한 의견이나 아이디어가 있습니까? 표준 tc qdiscs를 사용하는 것은 너무 어려워 보입니다. 프로그래머로서 간단하게 내 스케줄러를 작성할 수 있다면 그렇게 쉬운 작업이었습니다 (허용되지 않습니다).