보장과 제한 — 예제로 보는 규칙들
규칙·서브 규칙의 Action 속성이 대역폭 배분을 결정합니다. 여기서는 보장과 제한을 제대로 쓰는 원칙 을 예제로 따져 봅니다.
규칙 단위 보장(Per Rule Guarantee)
규칙에 배정되는 대역폭은 보장된 양 + 가중치에 따른 몫 입니다. 보장을 지키려고 보장분을 총 대역폭에서 먼저 떼어 두고, 남은 대역폭을 모든 규칙의 가중치대로 나눕니다.
예를 들어 회선이 190KBps, Rule A가 Guarantee 100KBps에 Weight 10, Rule B가 Weight 20이라면 — Rule A는 130KBps(보장 100 + (10/30)×(190-100)=30)를, Rule B는 60KBps((20/30)×90)를 받습니다.
서브 규칙과 얽힐 때는 몇 가지 반드시 지킬 제약 이 있습니다. 서브 규칙에 보장을 정하면 그 위 부모 규칙에도 보장이 있어야 하고, 서브 규칙의 보장은 부모 규칙의 보장보다 클 수 없 습니다. 또 부모 규칙의 보장은 그 서브 규칙들의 보장 합보다 작으면 안 됩니다(예: 서브 A1·A2가 각 80이면 합 160 > 부모 A의 100이라 틀림 → A를 160 이상으로). 그리고 최상위 규칙들의 보장 합은 회선 용량의 90%를 넘으면 안 됩니다. 보장은 매칭되는 연결이 있을 때만 대역폭을 잡 고, 연결 속도가 보장보다 낮으면 남는 양은 다른 연결이 쓸 수 있 게 풀립니다.
여기에 한 가지 함정이 있습니다. 규칙의 가중치가 너무 낮으면, 그 규칙에 매칭된 연결이 받을 대역폭이 거의 없 어질 수 있습니다. 예컨대 Rule A가 Guarantee 100·Weight 1 이면 거의 103KBps만 받고, 그 안의 서브 A1이 보장 100을 다 가져가면 서브 A2는 1.5KBps밖에 못 받 습니다.
연결 단위 보장(Per Connection Guarantee)
연결마다 보장하는 경우, Accept additional connections 를 켜면 보장 연결 수를 넘는 연결도 열리 며, 그 옆 칸이 비어 있으면 추가 연결은 규칙 가중치대로 대역폭을 받습니다. 서브 규칙의 연결 단위 보장은 부모 규칙의 그것보다 클 수 없 고, 서브 규칙에 연결 보장이 없으면 부모 규칙의 값을 물려받 습니다.
제한과, 보장-제한의 상호작용
규칙은 Rule Limit와 Per connection Limit를 둘 다 가질 수 있지만 연결 제한이 규칙 제한보다 크면 안 됩니다. 서브 규칙 모두에 제한이 있으면 부모 규칙의 제한은 서브 규칙 제한들의 합보다 클 수 없 습니다.
보장과 제한이 한 규칙에 같이 있으면, 제한이 보장보다 작으면 안 되고, 제한 = 보장이면 연결이 대역폭을 못 받는 상황 이 생길 수 있습니다.
Differentiated Services (DiffServ)
DiffServ 는 네트워크 트래픽에 종류·등급별로 다른 서비스를 주는 아키텍처 입니다. 기업망 안에서 패킷의 IP 헤더 TOS 바이트에 어떤 등급(QoS Class)에 속하는지 표시(marking) 해 두면, 공인망(public network)으로 나갔을 때 그 등급에 따라 우선권을 받습니다. DiffServ 표시는 공인망에서 의미가 있고 기업망 안에서는 아닙니다. 그러니 거치는 모든 공인망 구간이 그 표시를 인정 해야 제대로 동작합니다.
IPSec 패킷에 DiffServ 표시를 쓸 때는, $FWDIR/conf/objects_5_0.c 의 속성으로 헤더 간에 표시를 복사 할 수 있습니다. :ipsec.copy_TOS_to_inner 는 복호화/역캡슐화 후 IPSec 헤더의 표시를 IP 헤더로, :ipsec.copy_TOS_to_outer 는 캡슐화 후 IP 헤더의 표시를 IPSec 헤더로 복사합니다. 기본값은 다음과 같습니다.
:ipsec.copy_TOS_to_inner (false)
:ipsec.copy_TOS_to_outer (true)DiffServ 규칙도 일반 규칙처럼 QoS Class와 함께 가중치를 갖지만, 그 가중치는 해당 클래스 규칙이 설치된 인터페이스에서만 적용 됩니다. 예컨대 FTP에 weight 50인 DiffServ 규칙은 그 QoS Class가 정의된 인터페이스에만 설치 되고, 다른 인터페이스를 지나는 FTP는 그 가중치를 못 받습니다. 모든 FTP에 가중치를 주려면 "Best Effort"(비-DiffServ 규칙) 아래에 규칙을 추가합니다. QoS Class는 인터페이스 속성의 QoS 탭에서 정의합니다(QoS 관리 참고). 참고로 QoS는 매칭된 패킷에 DiffServ 표시를 더하는 건 지원하지만, DiffServ 태깅을 보고 패킷을 매칭하는 건 지원하지 않 습니다.
Low Latency Queuing (LLQ)
웹의 대부분 TCP 트래픽에는 WFQ면 충분합니다. 패킷을 큐에 넣고 인터페이스 대역폭과 규칙 우선순위에 따라 내보내, 패킷을 떨구지 않는 대신 (때로 긴) 큐를 유지 합니다. 문제는 음성·영상처럼 지연을 일정 한계 안으로 묶어야 하는 트래픽 입니다. 긴 큐는 큰 지연을 부르니까요. 다행히 이런 스트림은 비트레이트가 알려진 경우가 많 아, 들어오는 만큼 바로 내보내면 큐가 거의 안 쌓여 지연이 무시할 만해집니다.
LLQ 는 바로 이런 "지연 민감" 애플리케이션을 위한 특수 Class of Service 를 만들게 해 줍니다. 이 클래스에는 허용 최대 지연(Maximum Delay)과 Constant Bit Rate(고정 비트레이트) 를 지정하고, QoS는 매칭 트래픽이 그 지연 한계 안에서 전달되도록 보장 합니다.
Low Latency 클래스의 동작
각 LLQ 클래스에는 활성 방향마다 고정 비트레이트와 최대 지연을 정합니다. QoS는 패킷이 최대 지연을 넘겼는지 검사해, 넘긴 패킷은 떨구고 아니면 고정 비트레이트로 전송 합니다. 고정 비트레이트가 도착 속도보다 작지 않으면 패킷은 안 떨어지 고, 도착 속도가 고정 비트레이트보다 높으면 초과분을 떨궈 최대 지연을 지킵니다.
클래스 우선순위와 비트레이트·지연 계산
보통은 한 LLQ 클래스로 충분하지만, 트래픽마다 다른 최대 지연이 필요하면 여러 클래스를 둡니다. 클래스는 (Expedited Forwarding 제외) 다섯 단계 우선순위 를 가지며, 최대 지연이 낮은 클래스가 더 높은 우선순위 를 받아야 합니다. 두 클래스의 패킷이 동시에 준비되면 높은 우선순위 패킷이 먼저 나가고, 낮은 쪽은 더 큰 지연을 겪기 때문입니다. 그래서 우선순위를 최대 지연 순으로 정하고, 우선순위 높은 순으로 클래스를 정의 하는 것이 권장됩니다.
고정 비트레이트 계산 에는 한계가 있습니다. 모든 LLQ 클래스의 고정 비트레이트 합은 총 대역폭의 20%를 넘을 수 없 습니다 — 그래야 Best Effort 트래픽이 큰 지터를 안 겪습니다. 값 자체는 한 애플리케이션 스트림의 비트레이트 × 동시에 열릴 것으로 예상하는 스트림 수 로 잡습니다. 예상보다 스트림이 많으면 드롭이 늘어나니, 드롭을 막으려면 동시 스트림 수를 제한합니다.
최대 지연 계산 은 스트림이 견딜 수 있는 최대 지연 과 QoS가 보장할 수 있는 최소 지연 사이에서 정합니다. 너무 작게 잡으면 불필요한 드롭 이 생깁니다 — 지연이 작을수록 큐가 짧아져, 전달 전에 패킷이 떨어질 수 있기 때문입니다. 상한은 (애플리케이션이 견디는 지연) − (외부 WAN이 더하는 지연) 으로 잡습니다(음성은 보통 전체 지연 150ms를 넘으면 사용자가 이상을 느낌). 하한은 버스트가 없으면 [3 × 패킷크기] / 비트레이트(패킷 3개를 큐에 담을 여유), 버스트가 있으면 [(버스트크기+1) × 패킷크기] / 비트레이트 입니다. 실제 값은 상·하한 사이로 잡되 어느 한쪽에 너무 붙이지 말 고, 버스트가 의심되면 상한 쪽에 가깝게 둡니다.
고정 비트레이트 초과 막기
LLQ 클래스를 지나는 총 비트레이트가 고정 비트레이트를 넘으면 드롭이 생깁니다. 막으려면 그 클래스 아래에 규칙을 하나 두고, Per Connection Guarantee로 연결당 비트레이트를 정하고, Number of guaranteed connections로 허용 연결 수를 못 박 습니다. 이때 Accept additional non-guaranteed connections 는 끕니다.
LLQ를 인터페이스처럼 생각하기
LLQ 클래스를 활성화하려면 그 아래에 규칙을 최소 하나 둬야 합니다. 매칭된 트래픽은 클래스의 지연·고정 비트레이트 속성과 규칙 속성(가중치·보장·제한)을 함께 적용받습니다. LLQ 클래스를 별도 네트워크 인터페이스처럼 생각하면 쉽습니다 — 클래스 지연 안에서 고정 비트레이트로 패킷을 내보내고, 그 앞에서 규칙들이 상대 우선순위를 정하는 셈입니다.
언제 LLQ를 쓰나
LLQ는 지연이 중요하고 들어오는 스트림의 비트레이트를 알 때 씁니다(음성·영상 — 최대 지연과 고정 비트레이트를 둘 다 지정). 지연 통제는 중요한데 비트레이트를 모르는 경우 도 됩니다(예: Telnet — 고정 비트레이트를 높게, 최대 지연을 아주 크게(99999ms) 잡으면, 버스트 때 패킷을 떨구지 않고 큐에 담아 고정 비트레이트로 내보냄). 반대로 지연 통제가 그리 중요치 않은 대부분의 TCP(HTTP·FTP·SMTP)에는 가중치·제한·보장이 더 적합 합니다.
LLQ vs DiffServ
LLQ 클래스는 TOS 표시를 받지 않 아, 우선 대우가 QoS 게이트웨이를 지나는 동안에만 보장됩니다. 예외는 Expedited Forwarding DiffServ 클래스 로, 이를 정의하면 자동으로 최고 우선순위 LLQ 클래스 가 되어 QoS 안에서도, 네트워크에서도 DiffServ 표시에 따른 대우를 받습니다(지연 강제 없이 DiffServ로만 쓰려면 Maximal Delay를 99999로).
언제 무엇을 쓸지는 ISP에 달렸습니다. ISP가 DiffServ를 지원하거나 MPLS로 여러 Class of Service를 제공 한다면, LLQ로 지연만 묶지 말고 DiffServ 클래스로 트래픽을 표시 해 ISP에 원하는 등급을 알려야 합니다.