우리 인터넷 회선에 일종의 트래픽 관리 기능을 추가하고 싶습니다. 많은 문서를 읽은 후에는 HFSC가 나에게 너무 복잡하다고 생각하고(모든 곡선을 이해하지 못하므로 절대 제대로 이해하지 못할 것 같습니다.) CBQ는 권장하지 않으며 기본적으로 HTB가 방법입니다. 대부분의 사람들에게 가십시오.
우리 내부 네트워크에는 세 개의 "세그먼트"가 있으며 적어도 처음에는 이들 간에 대역폭을 어느 정도 균등하게 공유하고 싶습니다. 또한 최소한 세 가지 종류의 트래픽(실시간 트래픽, 표준 트래픽, 대량 트래픽)에 따라 트래픽의 우선순위를 지정해야 합니다. 대역폭 공유는 가능할 때마다 실시간 트래픽이 항상 프리미엄 트래픽으로 처리되어야 한다는 사실만큼 중요하지 않지만 물론 다른 트래픽 클래스도 부족할 수는 없습니다.
문제는 무엇이 더 합리적이고 더 나은 실시간 처리량을 보장하는지입니다.
세그먼트당 하나의 클래스를 생성합니다. 각 클래스는 동일한 속도를 가지며(HTB 개발자에 따라 리프가 없는 클래스의 경우 우선순위는 중요하지 않음) 이러한 각 클래스에는 3가지 우선순위 수준(우선순위가 서로 다름)에 대해 3개의 하위 클래스(리프)가 있습니다. 그리고 다른 요금).
우선 순위 수준별로 하나의 클래스가 있고 각각 다른 비율을 가지며(우선 순위는 중요하지 않음) 각 클래스에는 세그먼트당 하나씩 3개의 하위 클래스가 있는 반면 실시간 클래스의 3개 모두 대량에서 가장 높은 우선 순위와 가장 낮은 우선 순위를 갖습니다. 수업 등등.
다음 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->High Prio 및 세그먼트 B->Low Prio 둘 다 보낼 패킷이 있습니다. A->High Prio가 더 높은 우선순위를 가지므로 해당 속도에 도달할 때까지 항상 먼저 예약됩니다. 이제 세그먼트 A에서 차용을 시도하지만 세그먼트 A가 더 높은 수준에 있고 세그먼트 B->Low Prio가 아직 해당 속도에 도달하지 않았기 때문에 이 클래스도 이제 속도에 도달하여 차입을 원할 때까지 먼저 제공됩니다. 세그먼트 B. 둘 다 해당 비율에 도달하면 둘 다 다시 동일한 수준에 있게 되며 이제 세그먼트 A의 비율에 도달할 때까지 세그먼트 A->High Prio가 다시 승리할 것입니다. 이제 루트에서 차용을 시도합니다(이는 세그먼트 C는 보장된 트래픽을 사용하지 않기 때문에 충분한 트래픽 여유가 있지만 다시 세그먼트 B->Low Prio도 루트 수준에 도달할 때까지 기다려야 합니다. 그런 일이 발생하면 우선순위가 다시 고려되며 이번에는 Segment A->High Prio가 Segment C에서 남은 모든 대역폭을 가져옵니다.
사례 2:
높은 우선 순위->세그먼트 A 및 낮은 우선 순위->세그먼트 B 모두 전송할 패킷이 있으며, 다시 높은 우선 순위->세그먼트 A가 더 높은 우선 순위를 가지므로 승리하게 됩니다. 일단 해당 속도에 도달하면 대역폭 여유가 있는 High Prio에서 차용을 시도하지만 더 높은 수준에 있으므로 다시 Low Prio->Segment B도 해당 속도에 도달할 때까지 기다려야 합니다. 둘 다 해당 금리에 도달하고 둘 다 빌려야 하면 High Prio->Segment A가 High Prio 클래스의 금리에 도달할 때까지 다시 승리합니다. 그런 일이 발생하면 대역폭이 다시 많이 남아 있는 루트에서 차용을 시도하지만(Normal Prio의 모든 대역폭은 현재 사용되지 않음) Low Prio->Segment B가 속도 제한에 도달할 때까지 다시 기다려야 합니다. Low Prio 클래스이며 루트에서 차용을 시도합니다. 마지막으로 두 클래스 모두 루트에서 차용을 시도하고 우선순위가 고려되며 높은 우선순위->세그먼트 A가 루트에 남은 모든 대역폭을 가져옵니다.
두 경우 모두 차선책으로 보입니다. 어느 쪽이든 빌릴 수 있는 대역폭이 많이 남아 있음에도 불구하고 실시간 트래픽이 대량 트래픽을 기다려야 하는 경우가 있기 때문입니다. 그러나 사례 2의 경우 실시간 트래픽은 사례 1보다 적게 기다려야 하는 것처럼 보입니다. 왜냐하면 대량 트래픽 속도가 전체 세그먼트의 속도보다 낮을 가능성이 높을 때까지 기다려야 하기 때문입니다. 1이 기다려야 하는 속도입니다). 아니면 내가 여기서 완전히 틀렸나요?
우선순위 qdisc를 사용하여 더 간단한 설정을 생각했습니다. 하지만 우선순위 큐는 어떻게든 제한하지 않으면 기아 상태를 초래한다는 큰 문제가 있습니다. 기아는 용납되지 않습니다. 물론 각 우선순위 클래스에 TBF(Token Bucket Filter)를 넣어 속도를 제한하고 고갈을 방지할 수 있지만, 이렇게 하면 다른 모든 우선순위 클래스가 있더라도 단일 우선순위 클래스가 더 이상 자체적으로 링크를 포화시킬 수 없습니다. 비어 있으면 TBF가 이러한 일이 발생하는 것을 방지합니다. 그리고 이것은 차선책이기도 합니다. 현재 다른 클래스에 대역폭이 필요하지 않은데 왜 해당 클래스가 회선 대역폭의 100%를 얻지 못합니까?
이 설정에 관한 의견이나 아이디어가 있으신가요? 표준 tc qdiscs를 사용하는 것은 너무 어려운 것 같습니다. 프로그래머로서 나만의 스케줄러를 간단히 작성할 수 있다면 매우 쉬운 작업이었습니다(이 작업은 허용되지 않습니다).
답변1
HTB를 올바르게 이해하면 요금이 "보장"됩니다. 이것은 당신을 의미합니다가지다"실시간" 트래픽 속도에 대한 아이디어. 이 비율을 초과하는 경우에만 대출됩니다. 여러 수업을 빌리려면 우선순위가 시작되어야 합니다. 보장된 요금은 물리적 한도를 합산해야 합니다. 그렇지 않으면 너무 번거롭습니다.
IMHO, 사례 A는 루트 수준에서 우선 순위 또는 속도 제한이 필요하므로 실제로 작동하지 않습니다. 서로 다른 세그먼트의 우선순위/비율은 서로에 대해 아무것도 알지 못하며 동일하게 처리됩니다.
아마도 당신이 원하는 것은 낮음 및 보통 우선 순위에 대한 "속도"를 0 또는 그에 가깝게 설정하고 나머지 대역폭에 대해 "천장"을 추가하는 것입니다. 높은 우선 순위에 대해서는 물리적 속도의 100%를 보장합니다.