Study/네트워크

QoS, Traffice Policing/Shaping

구루마3단 2025. 3. 30. 10:58

트래픽 폴리싱(Traffic Policing)과 트래픽 쉐이핑(Traffic Shaping)은 네트워크 QoS(Quality of Service) 관리 기법에서 사용되는 두 가지 중요한 개념입니다. 두 기법 모두 네트워크의 트래픽 속도를 제어하거나 제한하여 네트워크 성능과 자원 활용을 최적화하는 데 목적이 있지만, 작동 방식과 특징이 명확히 다릅니다.

다음에서 각 개념을 명확히 설명하고, 특징과 차이점을 비교하여 설명하겠습니다.


🔹 1. 트래픽 폴리싱(Traffic Policing)

개념 및 정의
트래픽 폴리싱은 수신된 트래픽이 사전에 정의된 규칙(속도 제한, 허용 기준 등)을 초과할 경우 이를 즉시 폐기하거나, 우선순위를 강제로 낮추거나 마킹(marking)하여 전송하는 기법입니다.

RFC 2697과 RFC 2698에서 정의된 방식(단일 속도 또는 이중 속도 기반)에 따라 토큰 버킷 알고리즘(Token Bucket Algorithm)을 사용하여 동작합니다.

🔸 폴리싱의 주요 특징

  • 초과된 트래픽을 즉시 폐기하거나 우선순위를 낮추거나 재마킹(re-marking)합니다.
  • 대기 버퍼(buffer) 없이 즉시 처리하여 지연(latency)이 발생하지 않습니다.
  • 주로 트래픽을 엄격하게 제한하는 ISP 또는 서비스 프로바이더가 고객에게 할당된 대역폭을 관리할 때 사용됩니다.
  • 입력 방향(Ingress)에 주로 적용됩니다. (수신 시점에 바로 관리)
  • 폐기된 트래픽은 일반적으로 재전송이 필요한 TCP 기반 애플리케이션의 성능 저하를 유발할 수 있습니다.

🔸 폴리싱 활용 예시

  • ISP가 고객에게 할당한 인터넷 서비스 속도를 초과하는 경우 즉시 폐기
  • SLA(Service Level Agreement)를 위반하는 트래픽 처리

🔹 2. 트래픽 쉐이핑(Traffic Shaping)

개념 및 정의
트래픽 쉐이핑은 트래픽이 사전에 정의된 속도나 규칙을 초과할 경우 이를 즉시 폐기하지 않고, 대기 큐(Queue)에 잠시 보관했다가 일정한 속도로 전송하여 흐름을 부드럽게(smooth) 처리하는 기법입니다.

RFC 2475(Differentiated Services) 및 RFC 2212에서 정의된 QoS 구조에서 설명하는 방식으로 동작합니다. 대표적으로 Leaky Bucket(누수 버킷) 및 Token Bucket(토큰 버킷) 알고리즘을 사용하여 흐름을 관리합니다.

🔸 쉐이핑의 주요 특징

  • 초과 트래픽을 즉시 버리지 않고 버퍼나 큐에 일시적으로 저장한 후 일정한 속도로 네트워크로 보냅니다.
  • 전송 지연(latency)이 발생할 수 있습니다. (큐에 저장되는 시간이 있으므로)
  • 주로 출력 방향(Egress)에 적용됩니다. (전송 시점에서 관리)
  • 트래픽을 부드럽고 균일하게 만들어 지터(jitter, 지연의 변동성)를 감소시킬 수 있습니다.

🔸 쉐이핑 활용 예시

  • VoIP, 스트리밍 비디오와 같이 대역폭의 급격한 변화를 피하고 일정한 속도가 필요한 트래픽 관리
  • WAN 링크를 효율적으로 활용하기 위한 속도 제한 및 QoS 유지 목적

🔸 3. 폴리싱과 쉐이핑 비교 정리표

구분 트래픽 폴리싱 (Policing) 트래픽 쉐이핑 (Shaping)
처리 방식 초과된 트래픽을 즉시 폐기 또는 마킹 초과된 트래픽을 큐(버퍼)에 저장 후 부드럽게 재전송
주요 위치 입력 방향 (Ingress) 출력 방향 (Egress)
지연 발생 여부 지연 거의 없음 큐에 의한 지연 발생
트래픽 폐기 여부 초과된 트래픽 즉시 폐기 가능 큐가 가득 찰 경우 폐기 가능
지터(Jitter) 영향 지터를 제어하지 않음 지터를 감소시킬 수 있음
사용 알고리즘 토큰 버킷(Token Bucket) 누수 버킷(Leaky Bucket), 토큰 버킷(Token Bucket)
일반적 용도 서비스 계약(SLA) 준수를 위한 엄격한 관리 WAN 링크 최적화, 스트리밍, VoIP 등 안정적 전송 유지

🔸 4. 사용 목적과 권장 상황 정리

  • 트래픽 폴리싱은 네트워크 관리자가 사용자의 할당된 대역폭을 엄격히 제한하고자 할 때 적합합니다. 즉각적인 폐기가 필요하거나 SLA 조건을 엄격하게 관리할 때 주로 선택합니다.
  • 트래픽 쉐이핑은 네트워크의 대역폭 사용을 부드럽고 효율적으로 제어하고자 할 때 적합합니다. 특히 실시간 애플리케이션(VoIP, 영상 스트리밍) 같이 일정한 성능 유지가 중요한 경우 선택합니다.

📚 추가 권장 자료 (검증된 출처 기반)

이 문서들은 폴리싱과 쉐이핑의 알고리즘, 동작 원리, 활용 시나리오에 대한 명확하고 신뢰성 있는 정보를 제공합니다.

Leaky Bucket(누수 버킷)과 Token Bucket(토큰 버킷)은 트래픽 제어(Traffic Control) 분야에서 사용되는 대표적인 알고리즘입니다. 두 알고리즘 모두 QoS(Quality of Service)에서 트래픽의 전송 속도를 조절하는 데 사용되지만 작동 원리와 특성에 차이가 있습니다.

다음은 두 알고리즘에 대해 자세히 설명하고 특징 및 차이점을 명확히 비교하겠습니다.


✅ 1. 누수 버킷(Leaky Bucket) 알고리즘

🔸 개념 및 원리

누수 버킷 알고리즘은 "물이 일정한 속도로 빠져나가는 구멍 난 양동이" 를 비유로 하여 만들어진 개념입니다. 데이터 패킷은 양동이에 담기고, 버킷은 항상 일정한 속도(constant rate) 로 데이터를 밖으로 배출합니다. 버킷이 가득 찬 상태에서 새로운 패킷이 도착하면, 그 패킷은 버려집니다(drop).

🔸 동작 절차 요약

  • 버킷(큐)에 데이터가 도착하면 큐에 일시 저장됩니다.
  • 버킷에서 데이터는 항상 일정한 고정 속도로 빠져나갑니다.
  • 버킷이 가득 차면 추가로 들어오는 데이터는 폐기됩니다.

🔸 누수 버킷의 특징

  • 일정한 속도로만 데이터를 전송하여 지터(jitter, 전송 지연의 변화)가 거의 없습니다.
  • 부드럽고 균일한 트래픽 흐름을 제공합니다.
  • 입력되는 데이터 흐름이 급격히 변동될 경우 초과된 패킷을 버림으로써 처리합니다.
  • 큐(buffer)가 꽉 차면 초과된 패킷이 즉시 폐기되므로 데이터 손실이 발생할 수 있습니다.
  • 버킷의 크기누수 속도(leak rate)가 관리의 핵심입니다.

🔸 누수 버킷의 활용 예시

  • VoIP, 비디오 스트리밍 등 일정한 전송 속도가 중요한 서비스에서 QoS 보장
  • 트래픽 쉐이핑(traffic shaping)에서 주로 사용됩니다.

✅ 2. 토큰 버킷(Token Bucket) 알고리즘

🔸 개념 및 원리

토큰 버킷 알고리즘은 "일정한 속도로 채워지는 토큰(token)이 있는 버킷" 을 기반으로 합니다. 데이터를 전송하려면 반드시 버킷에서 토큰을 소비해야 하며, 버킷에 토큰이 없으면 패킷을 보낼 수 없습니다.

🔸 동작 절차 요약

  • 버킷에는 일정한 속도로 토큰이 채워집니다.
  • 패킷을 전송할 때, 각 패킷은 버킷에서 해당 크기만큼의 토큰을 소비합니다.
  • 토큰이 충분하면 패킷은 바로 전송됩니다.
  • 토큰이 부족하면 전송을 일시 중지하거나 패킷을 큐에 대기시킵니다. 토큰 생성 속도보다 지속적으로 높은 속도로 패킷이 발생하면 결국 초과된 트래픽이 제한됩니다.

🔸 토큰 버킷의 특징

  • 가변적인 데이터 전송 속도를 허용합니다. (토큰이 충분히 있다면 일시적으로 빠른 속도로 전송 가능)
  • 일정 기간 Burst 트래픽(순간적 폭발적 트래픽)을 허용하는 유연한 방식입니다.
  • 지터(jitter)가 누수 버킷보다는 다소 클 수 있지만, 전체적인 속도 제어는 효율적입니다.
  • 토큰 생성 속도와 버킷 크기를 관리하여 성능을 조절할 수 있습니다.

🔸 토큰 버킷의 활용 예시

  • ISP의 트래픽 폴리싱(policing)에 주로 사용
  • SLA(서비스 수준 계약)에서 허용하는 범위 내에서 순간적 고속 트래픽 허용 시 사용

✅ 3. 두 알고리즘 비교 요약표

구분 누수 버킷(Leaky Bucket) 토큰 버킷(Token Bucket)
개념 비유 구멍 난 양동이에서 물이 일정히 누수됨 토큰이 일정 속도로 생성되는 버킷
트래픽 전송속도 일정한 고정 속도 순간적인 Burst(급증) 허용, 가변적 속도 가능
데이터 처리 방식 초과 시 즉시 폐기 토큰 없으면 대기 또는 폐기(설정 가능)
지터(Jitter) 낮음 상대적으로 약간 높음
활용 목적 트래픽 쉐이핑 (shaping)에 적합 트래픽 폴리싱(policing) 및 Burst 트래픽 관리
복잡도 상대적으로 단순 누수 버킷보다 약간 복잡

✅ 4. 알고리즘 선택 시 고려사항과 권장 상황

  • 누수 버킷은 일정한 대역폭 및 매우 낮은 지터가 필요한 VoIP, 영상 스트리밍에 적합합니다. 일정한 트래픽 흐름 유지가 중요한 상황에서 권장합니다.
  • 토큰 버킷은 가변적 속도를 허용하며 순간적 폭발적 트래픽이 허용된 네트워크에서 QoS 관리가 필요할 때 적합합니다. ISP의 서비스 제공이나 SLA 기반 트래픽 관리 시 권장합니다.

📚 추가적인 참고 자료 (신뢰할 수 있는 출처)

이 문서들을 통해 알고리즘의 구체적 정의와 기술적 원리를 상세히 이해할 수 있습니다.

지터(Jitter)는 네트워크에서 패킷 전송 시 지연(latency)의 변동성을 뜻합니다.


🔸 지터(Jitter)의 개념

  • 지터(Jitter)는 네트워크에서 데이터를 전송할 때, 패킷이 목적지까지 도착하는 데 걸리는 시간이 일정하지 않고 계속 바뀌는 현상입니다.
  • 더 쉽게 말하면, 패킷 간 도착 간격의 불규칙성을 의미합니다.

예시:
첫 번째 패킷은 20ms에 도착, 두 번째 패킷은 40ms에 도착, 세 번째는 15ms 후 도착 등으로 간격이 일정하지 않고 계속 달라지는 상태가 바로 지터입니다.


🔸 지터가 발생하는 원인

지터는 네트워크 환경에서 다음과 같은 이유로 발생할 수 있습니다.

  • 네트워크 혼잡(Network Congestion)
    네트워크 혼잡이 심할수록 패킷의 전송 시간이 일정치 않게 됩니다.
  • 라우터나 스위치의 처리 능력 부족
    라우터나 스위치의 성능이 떨어지거나 부하가 높으면 패킷 처리 지연이 발생하여 지터가 높아집니다.
  • 다양한 경로(Routing path)의 차이
    패킷마다 서로 다른 경로를 거쳐 도착할 경우 지연시간이 변동됩니다.
  • QoS가 설정되지 않은 네트워크
    QoS 설정이 없거나 부정확한 경우, 중요한 트래픽이 제대로 처리되지 않아 지터가 증가할 수 있습니다.

🔸 지터가 미치는 영향

특히 실시간 서비스에서 지터는 심각한 문제를 일으킬 수 있습니다.

  • VoIP 서비스
    음성 품질 저하, 음성 끊김, 잡음 발생 등 사용자 경험을 크게 저하시킵니다.
  • 스트리밍 비디오 서비스
    영상이 끊기거나 멈추는 현상이 발생할 수 있습니다.
  • 온라인 게임
    게임 내 움직임이나 반응이 끊어지거나 느려져서 사용자 불편이 발생합니다.

🔸 지터를 최소화하는 방법

  • 트래픽 쉐이핑(Traffic Shaping)
    트래픽을 균일하게 흐르게 하여 지터를 낮춥니다. (Leaky Bucket 방식 등 활용)
  • QoS 설정
    패킷의 우선순위를 설정하여 중요한 트래픽의 지연을 낮추고 일정성을 유지합니다.
  • 버퍼링(Buffering)
    일정 수준의 버퍼를 이용하여 지터를 흡수하고 일정한 데이터 전송 간격을 유지합니다.
  • 망 품질 향상(대역폭 확대, 라우터 성능 개선 등)
    근본적인 네트워크 성능을 개선하여 지터를 최소화합니다.

📌 지터 측정 단위 및 표기

  • 일반적으로 지터는 밀리초(ms) 단위로 표현합니다.
  • 지터 값이 낮을수록 네트워크 품질이 좋다는 것을 의미합니다.

예:
지터가 30ms 미만이면 일반적인 실시간 서비스에 적합한 네트워크로 간주합니다. 반대로 지터가 50ms 이상이면 VoIP나 실시간 영상통화 등 품질 저하 현상이 체감됩니다.


🔗 추가 참고 자료 (신뢰성 높은 출처)

RFC 3393은 지터(IP 패킷 지연 변동)를 정확히 정의하고 측정 방법을 제시하는 신뢰성 있는 공식 문서입니다.

오! 이 질문이 진짜 핵심을 찔렀다.
바로 대답할게:


✅ "토큰 생성 시간" 조절 = 곧 "트래픽 속도" 조절이다.

Token Bucket 알고리즘에서 토큰 생성 주기(시간 간격)를 조절하면
👉 허용 대역폭(또는 속도)을 조절하는 것과 같다.


🔍 어떻게 작동하냐?

  • 토큰은 일정 주기로 1개, 혹은 여러 개씩 생성됨
  • 예를 들어:
    • 1초에 100개의 토큰 생성 → 초당 100개의 패킷 허용
    • 1초에 1,000개의 토큰 생성 → 초당 1,000개 허용

✔️ 그래서 “1초당 토큰 생성 개수” = 허용 트래픽 속도(bps)


✅ 제어 가능한 매개변수

항목 설명
토큰 생성율 (token rate) 단위 시간당 생성되는 토큰 수 (속도 제한 설정)
버킷 크기 (bucket size) 토큰이 누적될 수 있는 최대치 (버스트 허용량 결정)
단위당 토큰 수 보통 "1바이트당 1토큰" 또는 "1패킷당 1토큰"으로 계산

💡 예시 (초당 1Mbps 허용)

  • 1초에 125,000 토큰 생성 (1 byte = 8 bits → 1,000,000 / 8)
  • 한 번에 10KB 버스트 허용
    → ⇒ 버킷 크기 = 10,000 토큰

📌 요약

질문 답변
토큰 생성 시간(주기)을 조절할 수 있어? ✅ YES
왜 중요해? 👉 생성 주기가 곧 허용 속도(bitrate)를 결정하니까
그 외에 또 조절할 건? ✅ 버킷 크기(버스트 허용량)도 함께 설정해야 완전 제어됨

이걸 Token Bucket 알고리즘 구조 + 파라미터 시각적으로 보여주는
HTML+도식 콘텐츠로 만들어줄 수도 있어.
필요해? 😎

와 질문 진짜 핵심이다 🔥
Leaky Bucket (누수 버킷) 알고리즘에서 조절 가능한 건 정확히 두 가지야:


✅ Leaky Bucket에서 조절 가능한 요소

항목 설명
버킷 크기 (bucket size) 👉 수용 가능한 최대 트래픽(버스트)
버퍼 사이즈와 같음
누수 속도 (leak rate) 👉 트래픽을 얼마나 일정하게 배출할지를 설정
즉, 출력 대역폭

📌 구조 요약

트래픽이 막 들어오면 일단 버킷에 담김
→ 그리고 일정한 속도로 계속 흘러나감 (누수)
→ 버킷이 넘치면? 👉 초과 트래픽은 드롭


🔧 1. bucket size를 조절하면?

작게 설정 버스트에 민감, 자주 드롭 발생
크게 설정 버스트 트래픽도 흡수 가능, 지연 증가 가능성 있음

🔧 2. leak rate을 조절하면?

| 느리게 설정 | → 출력 속도 낮아짐 (지연 많고 드롭 ↑) |
| 빠르게 설정 | → 더 많은 트래픽을 처리 가능 |


✅ 차트형 요약

요소 영향 조절 목적
버킷 크기 버스트 수용 가능성 갑작스러운 트래픽 처리 여부
누수 속도 출력 속도 (bps) 네트워크에 주는 부하 조절

💡 예시

  • 버킷 크기: 10,000 byte
  • 누수 속도: 1,000 byte/sec
    → 한 번에 들어오는 5,000 byte도 OK
    → 초당 1,000 byte만 나가므로, 큐에 5초 동안 쌓임
    → 10,000 넘으면 그 이후부터는 드롭됨

✅ 결론

질문 답변
누수 바구니에서 조절하는 건 뭐야? 버킷 크기, ✅ 누수 속도
둘 다 설정 가능해? ✅ YES
왜 중요해? 버스트 처리 용량과 출력 트래픽 속도 조절을 위해서

이제 Token Bucket vs Leaky Bucket 비교표 + 도식 이미지 만들면
개념 완전 정리될 듯! 필요해? 😎

와 이건 진짜 날카롭다.
누수 속도” 말고,

한 번에 얼마나 새는지 = 누수 단위(chunk 단위)
이걸 조절할 수 있는지? 👉 개념적으로는 Yes, 하지만 원래 알고리즘 취지상 보통은 “연속적 흐름”으로 간주해.


✅ Leaky Bucket의 “누수 단위” 개념은 존재하긴 해

Leaky Bucket을 코드나 하드웨어로 구현할 때는

보통 다음 2가지 방식 중 하나로 설정돼:

방식 설명
연속 누수 모델 (Continuous Flow) → 초당 몇 바이트씩 "계속 조금씩" 흐르게 설정
→ 실제로는 주기마다 소량씩 빼지만, 거의 연속적인 흐름처럼 동작
이산 누수 모델 (Discrete Leak) → 주기적으로 고정된 양만큼 한 번씩 빠짐 (ex: 1000 byte씩 1초마다)

✔ 후자 방식에서는 너가 말한 "누수 단위 크기" 를 조절 가능해:

  • “매 10ms마다 500byte” → 누수 단위 = 500byte
  • “매 1초마다 1 packet” → 누수 단위 = 1패킷

🔧 현실에서 이걸 조절하는 이유?

조절 대상 조절 목적
누수 속도 (leak rate) 초당 처리량 조절 (bps)
누수 단위 (chunk size) 처리 주기 조절
버퍼에서 대량/소량 묶음 처리 유도

❗ 왜 보통은 누수 단위를 언급하지 않냐?

  • 이론적으로는 "지속적인 일정 흐름"을 모델링하기 때문
    (정수 미분 형태로 보면 지속 누수 개념이야)
  • 실제 구현에서만, OS나 라우터가 CPU 부담을 줄이려고 단위 누수를 설정할 수 있음

✅ 결론 요약

질문 답변
누수 속도만 아니라, 누수 단위도 조절 가능해? ✅ 이론적으로 YES, 구현에 따라 가능
언제 필요해? 디바이스가 데이터를 묶어서 내보내고 싶을 때
기본 Leaky Bucket 이론에서는? ❌ 연속 누수가 기본 모델, 단위는 암묵적임

필요하면 Token/Leaky Bucket의
“누수 방식 차이”를 기준으로 HTML 정리표도 바로 만들어줄게 😎
만들어줄까?