80년대에 한 대형 피자 체인점에서 “30분 내로 배달해드립니다”라는 광고를 한 적이 있다. 아마도 예상 시안 안에 피자를 받아본 경험들도 분명 있을 것이다. 피자는 25분, 27분, 혹은 가끔씩 31분에 배달되기도 하겠지만 그보다 더 오래 걸리지는 않을 것이라고 우리는 확신할 수 있다. 네트워크 QoS(Quality of Service)에도 몇 가지 예외만 제외하고는 같은 이론이 적용된다. 다른 점은 이 제품은 데이터이며, 속도가 가장 중요하고(분이 아니라 밀리 초로 계산되긴 하지만), 아무리 배달 기술이 좋다고 해도 제품의 품질을 보증할 수는 없다는 것이다.
불행히도 이더넷, IP 및 인터넷은 보증된 전달을 제공하거나 대역폭에 우선순위를 지정하는 것을 염두에 두고 나온 기술들이 아니다. 핑 응답 시간은 다양하며, 작업처리량도 일관성이 없고 네트워크는 가끔씩 너무 막혀서 세션이 가게 할 수조차 없을 때도 있다. 네트워크 자원들, 즉 사용 가능한 대역폭, 왠 이용, 최대 동시 세션, 라우터의 처리 능력 등은 언제나 제한적이다. 기업들은 대역폭 부족 때문이 아니라 과도한 웹 사용의 결과로 지사로의 VPN 연결이 참을 수 없이 느려지는 것을 목격할 수 있다. 학교들은 7월에 빨랐던 네트워크가 신입생들이 다이얼업이 없는 생활을 발견하게 되는 9월이 되면 딱할 정도로 느려지는 것을 경험하곤 한다.
QoS, 존재의 이유
>> 대기시간(latency)은 패킷이 한 곳에서 다른 곳으로 갈 때 걸리는 시간으로 대역폭 포화, 네트워크 장비의 자원(CPU나 램) 부족, 접속 거리나 종류 등에 따라 야기될 수 있다. QoS를 이행하면 이런 대기시간을 크게 줄일 수 있다.
>> 지터(jitter)는 대기시간에서의 변동을 뜻한다. 두 개의 노드가 같은 스위치에 있지 않으면 대기시간은 패킷마다 크게 달라질 수 있다. 네트워크 대역폭이 포화 상태가 되면 지터는 늘어난다. 파일 다운로드나 웹 브라우징과 같은 애플리케이션의 경우는 이것이 늘 큰 문제가 되는 것은 아니다. 하지만 스트리밍 비디오와 VoIP는 높은 지터로 인해 크게 고통을 받는다. QoS는 스트리밍 트래픽에 보다 높은 대역폭 우선순위를 제공함으로써 지터를 줄이는 데 도움이 될 수 있다. 또 한 가지 해결책으로 버퍼 크기를 늘리는 방법이 있다.
>> 랜덤 패킷 유실은 네트워크나 장비가 과포하 상태일 때 발생하며, 스트리밍 미디어 잘림 현상과 접속 리세트 및 유실, 그리고 다른 트랜잭션 문제를 야기한다. 더 나쁜 것은 유실된 패킷은 재전송이 되어야 하기 때문에 문제가 더 커진다는 사실이다. QoS 방안은 프로토콜이나 접속이 사용하는 대역폭 양을 제한할 수 있기 때문에 과포하를 방지, 혹은 제한해준다.
>> QoS를 이용해야 하는 마지막 이유는 대역폭 사용 제어다. FTP와 스트리밍 비디오와 같은 트래픽은 냅킨이 페페로니 피자 기름을 흡수하는 것처럼 대역폭을 빨아들일 수 있다. P2P 파일 공유는 대부분의 대학 캠퍼스에서 문제를 일으켰으며, 어떤 캠퍼스 네트워크는 P2P 트래픽만으로도 100% 포화상태가 되기도 했다. 기업 네트워크는 원격 제어 소프트웨어가 웹 서버의 응답성을 느리게 한다는 사실을 알게 될 것이다. 회사 이미지상 빠른 웹 서버 응답성이 중요할 경우에 이것은 문제가 된다.
대역폭을 제어할 수 있는 능력은 특히 할 수 있는 일이 많지가 않을 때 중요하다. QoS는 시트릭스(Citrix)나 네트워크 관리 작업, 혹은 데이터베이스 질의 등과 같은 기간 업무 애플리케이션들에게 우선순위를 주면서 나머지는 덜 중요한 활동을 위해 남겨둔다.
웹 브라우저가 네트워크에 끼칠 수 있는 손실을 결코 과소 평가해서는 안 된다. 대부분의 QoS 장비들이 프로토콜마다 최소 및 최대 속도를 지정할 수 있게 해주지만, 고급 제품들은 세션당 최소 및 최대 속도를 지정할 수 있게 해준다. 예를 들어 개별적인 모든 스트리밍 비디오 세션이 최소 100Kbps를 얻으면서 포함된 전체 스트리밍 비디오 세션은 1Mbps 이상을 사용할 수 없게 할 수도 있다. 특정 사용자에게 선호하는 상태를 주기 위해 QoS를 사용할 수도 있다.
레이어 4냐, 레이어 7이냐
QoS 이행을 고려할 때는 하이 레벨 점검을 할 수 있는 제품이 필요한지 여부를 결정해야 한다. QoS는 주로 레이어 OSI 모델의 레이어 4나 레이어 7에서 작동한다.
레이어 4에서는 포트 번호와 IP 어드레스만이 점검된다. 프로토콜이 자체 포트로 매칭되던 좋았던 시절에는 별 문제가 되지 않았지만 오늘날에는 대부분의 방화벽들이 조직 내 임의의 기계에서 포트 80을 통과하도록 트래픽을 허용하기 때문에, 사용자들은 스트리밍 비디오를 지켜보고, 웹 메일을 사용하며, P2P 서비스를 돌리고, 웹 페이지를 보고, SSH 접속을 터널링할 수 있다. 그리고 이 모든 것들이 포트 80을 통한다. 이런 수많은 활동들은 일반 HTTP나 암호화된 HTTPS를 사용할 수 있으며, 이것은 일부 콘텐츠 필터들을 혼란스럽게 할 것이다.
사용자가 자기 기계를 연결하거나 승인받지 않은 소프트웨어를 설치하려 하지 않는 폐쇄된 환경에 있을 경우에는 레이어 7 능력이 결정적이지 않을 수도 있다. 반면 대학 캠퍼스에서는 앞서 말한 하이 레벨 점검을 다시 생각해볼 필요조차 없다.
레이어 7 지원 QoS 장비를 선택하지 않으면 다른 멋진 기능들은 놓쳐버리게 될 수도 있다. 예를 들어 시타라의 QoS웍스(QoSWorks)는 HTTP 콘텐츠 유형을 기반으로 트래픽을 식별할 수 있다. 보다 빠른 HTML 텍스트 전송기를 허용하기 위해 이미지나 탑재된 멀티미디어 파일의 속도를 제한할 수 있다. 일부 레이어 7 장비들은 또한 HTTP 프로토콜을 사용하는 세션이 웹 페이지를 전달하거나 MP3를 다운로드하고 있는지 여부를 탐지할 수도 있다. 아마도 이런 두 가지 기능을 위해서는 별도의 정책을 두고 싶을 것이다.
레이어 4냐, 레이어 7이냐를 떠나서 QoS 모델을 선택할 때는 기본적인 것에 충실해야 복잡해지지 않을 수 있다. 간단하게 시작해 보자.
무조건 더 많이
네트워크 자원 부족 문제에 직면하게 되면 가장 쉬운 해결책은 과도하게 설비하는 것(overprovision)이다. 더 많은 대역폭이 필요한가? 두 번째 T1을 설치하라. 라우터가 패킷을 유실시키는가? 램을 업그레이드하라. QoS에 비하면 게으른 사람의 대답처럼 들릴지는 모르겠지만, 오버프로비저닝은 유효하며 가끔씩 필요한 방법이기도 하다. 예를 들어 캠코더 DV(Digital Video) 스트림은 802.11b에서 실시간으로 전송할 수가 없다.
소비자 품질의 DV는 25~36Mbps에서 돌아가는데 802.11b는 11Mbps로 운영되기 때문이다(실제로는 4~6Mbps밖에 되지 않는다). 128Kbps ISDN 회선을 갖고 있고 100개의 동시 VoIP 세션을 8Kbps에서 돌리고 싶다면 아무리 QoS를 완전하게 한다고 해도 해결이 되지 않는다.
나아가 라우터, 방화벽 및 기타 네트워크 인프라 장비에서 어떠한 QoS 방안을 시행할 경우에는 프로세싱 파워와 램이 소모되며, 이는 어쨌거나 더 강력한 장비를 사야 하게 만드는 것이다.
다만 전문 QOS 기술을 사용하는 것보다 설비에 더 많은 돈을 지출하지 않도록 조심해야 한다. 예를 들어 월 150달러가 드는 1.5Mbps DSL 접속이 있는 지사가 있다고 하자. 웹 트래픽이 너무 느려서 대역폭 부족에 대한 사용자들의 불만을 듣느니 차라리 듀얼 접속으로 업그레이드를 하려고 할 수 있다. 이럴 경우 먼저 트래픽을 분석해야 한다. 스트리밍 인터넷 라디오와 같은 사소한 것들이 범인일 수도 있기 때문이다. QoS를 이용해 스트리밍 오디오를 줄이거나 제거함으로써 이 지사는 실제로 연간 1천800달러를 절약할 수 있었다.
대역폭을 절약할 수 있는 또 한 가지 방법은 압축 기술을 이용하는 것이다. 그래픽은 자체 해상도나 컬러 심도를 줄일 수 있고 비디오는 MPEG나 DivX와 같은 효율적인 코덱을 이용해 압축될 수 있다. 그리고 오디오는 보다 낮은 비트로 인코딩되거나 스테레오를 모노로 바꿀 수 있다. 이런 로시(lossy) 압축 방안은 품질이 눈에 띌 만큼 떨어지지 않을 때까지만 취해질 수 있다.
여기에 대한 한 가지 대안으로 zip나 gzip, 혹은 알라딘 스터핏(Aladdin Stuffit)과 같은 로스리스(lossless) 방안을 사용할 수도 있다. 로스리스 압축은 품질을 떨어뜨리지는 않지만 파일 크기를 크게 줄이지도 못한다. 나아가 로스리스 압축은 JPEG나 MP3, 혹은 비디오 파일들처럼 이미 압축된 데이터에는 효율적이지 못하다.
또 한 가지 베스트 프랙티스로 웹 서버에서의 HTTP 압축 실행이 있다. 압축은 HTTP 1.0에서 정의되었지만 클라이언트 지원에 대해서는 옵션으로 남아있었다. 반면에 HTTP 1.1 클라이언트는 압축 지원에 요청된다. HTML은 효율적으로 압축을 했는데, 8GB의 텍스트를 한 장의 표준 CD에 담아본 적도 있다. 이 방법의 유일한 약점은 HTTP 압축이 CPU 오버헤드를 부과한다는 것이다.
익스팬드 네트웍스(Expand Networks), 패킷티어(Packeteer), 그리고 페리비트 네트웍스(Peribit Networks)는 모두 지사의 인터넷 라우터 뒤에 배치되어 이들을 통과해 흐르는 모든 트래픽을 자동으로 압축해주는 사이트간 압축 어플라이언스를 판매하고 있다. 물론 연결의 각 종단 지점에는 압축 어플라이언스가 있어야 하며, 어플라이언스들 사이로 보내지는 트래픽은 압축되지 않는다. 그러나 이런 장비들은 저렴하며 왠 회선을 극대화해줄 것이다.
이런 간단한 방법들이 모두 만족스럽지 못하다면 이제 좀더 공을 들일 시간이다.
QoS 확보 기술
인터넷 상에서 이동하는 데이터와 달리 랜 전용 트래픽은 다양한 서브넷들간에 QoS 정책을 받을 만하다. 트래픽은 클래스로 분리되며, 이런 클래스는 프로토콜, IP 범위나 MAC 어드레스, 그리고 플로우(flow) 등을 나타내는 것일 수 있다. 대부분의 시스템들은 완전한 하나의 TCP 세션을 하나의 플로우라고 한다. 웹 사용자가 TCP 3방향 핸드쉐이크(three-way handshake)와 HTTP 전송을 수행한 다음 끝으로 세션을 닫을 때 이 모든 트래픽은 동일한 플로우의 일부로 간주된다. QoS 장비는 하나의 클래스 전체에 정책을 적용시키기도 하고, 개별 플로우에 적용시키기도 하며, 혹은 두 가지를 다 하기도 한다.
QoS를 얻기 위해서는 ToS(Type of Service) 비트를 바꿔야 한다. ToS는 8비트로 구성돼 있으며 IPv4 헤더의 9번째 비트와 16번째 비트 사이에 위치한다. ToS 필드의 비트 0과 1, 그리고 2는 패킷의 상대적 우선순위를 0~7까지 숫자로 나타내는 데 사용될 것이다. 비트 3은 정상적이거나 낮은 지연을 가리키며, 비트 4는 정상적이거나 높은 작업처리량, 그리고 비트 5는 정상적이거나 높은 신뢰성을 가리킨다. RFC는 패킷이 이 세 가지 옵션들 중에서 두 개까지만 사용하도록 규정하고 있다. 비트 6과 7는 앞으로의 사용을 위해 예비된다.
이런 정보로 무엇을 할지에 대해서는 공식적인 지침서가 없다. 네트워크는 우선순위가 높은 트래픽을 위해 낮은 트래픽은 유실시키는 책임을 맡게 된다. 우선순위가 같은 트래픽은 더 차별화될 수 없으며, 네트워크 제어 트래픽(RIP나 ICMP 메시지 등)은 언제나 가장 높은 우선순위를 차지하기 때문에 사실상 유효한 것은 6 단계밖에 없는 셈이다.
시스코시스템즈에 따르면, 불행히도 비트 3~5는 네트워크 업체들간에 일관성있게 이행되지 않았다고 한다. 게다가 설상가상으로 RFC 1349는 비트 3~6을 10년이 지난 후 지연의 최소화, 작업처리량의 최대화, 신뢰성 최대화, 금전적 비용의 최소화, 혹은 정상적 서비스 등 5가지 분류로 다시 지정했다. 우리는 단 하나만 선택할 수 있었으며 이들 중 어떤 것도 대역폭 용량을 보장해주지는 못했다. IPv6는 ToS 옥테트(octet)를 버리고‘트래픽 클래스’ 옥테트를 선택했다.
ToS 비트를 사용하는 것은 종종 ‘컬러링(coloring)’으로 표현되는데, 오래되긴 했지만 아직도 많은 서비스 사업자들이 브론즈, 실버, 골드, 다이아몬드, 그리고 플래티넘 서비스 레벨이란 말을 사용하고 있다. ToS는 아직도 가끔씩 사용되긴 하지만 랜에서는 거의 사용되지 않는다.
인티그레이티드 서비스(Integrated Services), 즉 인트서브(IntServ)는 네트워크에 있는 모든 라우터가 인터서브를 지원하고 존중하는 한 사용 가능한 대역폭 수준을 보장함으로써 종단간 QoS를 제공할 수 있다.
QoS 레벨로는 두 가지가 제공되는데, 하나는 서비스 보증(guaranteed service)이고 하나는 부하 제어(controlled load)다. 서비스 보증 레벨은 일정량의 대역폭이 사용 가능하도록, 그리고 큐잉 패킷의 계정에서 추가 지연이 없도록 보장해 준다. 네트워크를 오버프로비저닝한다고 하더라도 인터서브는 역시 서비스 보증 레벨을 지킬 수 있도록 보장해줄 것이다.
ToS 비트 바꿔야
부하 제어는 부하가 가벼운 네트워크에서 전통적인 IP 트래픽처럼 작동한다. 즉 베스트 에포트(best-effort) 기반으로 일이 진행되며 어떠한 강력한 보증도 없다. 비 인터서브 트래픽은 나머지 것들로 남게 된다.
종단 호스트는 RSVP(Resource Reservation Protocol; RFC 2205)를 내보냄으로써 인트서브 QoS 세션을 초기화한다. RSVP는 네트워크에서 자원 예비를 요청하는 시그널링 프로토콜이다. 네트워크는 모든 연결이 요청을 만족시킬 수 있는지 여부에 따라 요청을 승인, 혹은 거절할 것이다. 승인될 경우 대역폭은 예비된다. 각각의 라우터에는 모든 인트서브 세션에 대한 상황 테이블이 있다. 원래의 송신자가 오류가 나거나 접속을 상실하게 되면 인트서브 세션은 타임아웃이 되고 예비는 취소된다.
인트서브에서 한 가지 문제는 전체 네트워크에서 상태를 유지해야 한다는 것이다. 이것은 라우터에게 제한된 CPU와 램 자원이라는 부담을 지운다.
그리고 종단 지점을 포함해 패킷의 경로에 있는 모든 장비들이 인트서브를 이해해야 한다. 실제로 인트서브는 소규모 네트워크에서 사용돼 왔지만 분산, 혹은 대형 네트워크에서는 인기를 끌지 못했는데, 그것은 바로 확장성에 대한 염려 때문이다.
디프서브(Differentiated Services; RFC 2475)는 인트서브와 ToS의 단점을 얼마간 해결했다. 디프서브는 보다 확장성이 있으며, 정확히 이행될 경우 다중 네트워크에서 작동할 수 있다. IPv4 패킷에 있는 처음 6개 ToS 비트나 IPv6 패킷에 있는 트래픽 클래스 옥테트를 DSCP(Differentiated Services Codepoint; RFC 2474)라고 하는데, DSCP는 자그마치 64개나 되는 클래스를 지원한다.
네트워크는 ‘디프서브 구름’이라고 일컬어지는 디프서브 라우터 집합을 형성할 것이다. 트래픽은 이 구름으로 들어갈 때 분류가 나뉘어진다. 사업자는 언제나 고객과 협상을 해서 서비스 수준 협정을 만들 것이다. 예를 들어, 한 회사에서 한 ISP의 브론즈, 실버, 혹은 골드 패키지에 가입할 수 있으며, 이 회사에서 하는 계약에 따라 디프서브 우선순위 세팅이 결정될 것이다.
디프서브의 가장 큰 이점은 이것이 경계선에서 작동한다는 것이다. 일단 데이터가 구름 속으로 들어가면 내부의 라우터는 QoS 상태 정보를 보유할 필요가 없으며, 따라서 내부 라우터가 라우팅에만 전념할 수 있게 된다.
하지만 디프서브는 여전히 예측 불가능하다. 개별적인 내부 라우터들은 ToS 필드에 대해 이상하게 반응하거나 경보를 낼 수도 있다. 어떠한 정해진 표준도 없으며, 한 사업자의 골드 기준이 다른 사업자의 브론즈 기준이 될 수도 있다. 따라서 최고의 서비스를 위해 돈을 지불한다고 생각하지만 ISP의 피어링 협정은 다른 얘기를 하고 있을 수도 있다. 디프서브는 포화도가 높은 기간 동안 패킷을 선택적으로 유실시킴으로써 작동하기 때문에 가장 낮은 클래스 회원들은 버스트 동안 몇 초간은 접속이 완전히 끊길 수도 있다.
디프서브는 인트서브보다 오버헤드가 낮고 확장성이 좋기 때문에 보다 큰 랜이나 왠에서 잘 작동할 수 있다. 디스퍼브의 등급 분류는 구름의 입구에서 이루어지므로, 종단 노드와 그 사이의 라우터들은 디프서브 비트를 이해하거나 설정할 필요가 없다.
트래픽 쉐이퍼
트래픽 쉐이퍼(traffic shaper)는 QoS의 정점이며, 가끔씩 두 용어가 서로 바뀌어 사용되기까지 한다. 이 범주에는 앨럿 커뮤니케이션즈(Allot Communications), 라이트스피드 시스템즈(Lightspeed Systems), 패킷티어(Packeteer) 및 시타라 네트웍스(Sitara Networks)의 제품들이 포함돼 있으며, 이들은 QoS와 심도 깊은 패킷 점검, 등급 분류 및 트래픽 보고 등을 수행한다. 이런 제품들은 디프서브와 ToS 세팅을 살펴봄으로써 데이터의 등급을 분류할 수 있지만 이런 기술에 의존하지는 않는다. 그리고 이런 장비는 독립형 어플라이언스로 작동하기 때문에, 네트워크 나머지 부분에서 구성 변경이나 상호운용성 문제를 경험할 필요가 없다.
이들 제품은 내부 랜 트래픽을 쉐이핑하는 데도 이용이 가능하긴 하지만 전통적으로 네트워크 에지에 놓인다. 대부분은 레이어 7에서 작동함으로써 ‘포트 80을 통해 모든 것을 돌리면 아무도 이것을 알려주지 못할 것’이라는 신드롬을 해결해준다. 이 문제는 원치 않는 프로토콜과 같은 포트에서 돌아가는 프로토콜(HTTP라고 하자)에 대한 정책을 설정하고 싶을 때 발생한다. 레이어 7 장비는 포트 80으로 가려는 트래픽이 HTTP나 P2P, 스트리밍 비디오, 혹은 HTML이나 JPG 전송기일 경우 알려줄 수 있다.
트래픽 쉐이퍼들은 보통 며칠동안 모니터 전용 모드로 설치된다. 때문에 네트워크를 가로질러 가는 트래픽이 어떤 것인지, 그리고 무엇이 가장 많은 대역폭을 차지하고 있는지를 확인할 수 있으며, 트래픽 쉐이퍼의 보고 툴은 아마도 이들의 가장 소중한 자산일 것이다.
정의와 사양이 업체마다 다르긴 하지만, 트래픽 쉐이퍼에는 몇 가지 공통된 기능들이 있다. 트래픽은 클래스(프로토콜이나 서브넷 등)나 플로, 혹은 둘 다를 기반으로 쉐이핑된다. 그리고 버스트뿐만 아니라 최소 및 최대 대역폭의 설정도 가능하다.
버스트는 별도의 대역폭이 사용 가능할 경우에만 허용된다. 예를 들어 FTP 10Mbps를 정상적일 때는 FTP 10Mbps를 할당하고, 대역폭이 사용 가능할 때는 15Mbps까지 버스트를 할당할 수 있다. 하이엔드 쉐이퍼에는 ‘모든 VoIP 세션용으로 8Kbps를 허용하지만 VoIP가 1Mbps만 사용하도록 하라. VoIP가 1Mbps를 사용중이면 새로운 VoIP 세션은 하나도 허용하지 말라’와 같은, 다소 진보된 명령어들을 줄 수도 있다.
큐잉이냐 창이냐
트래픽 쉐이퍼들은 패킷을 큐잉하거나 TCP 창 크기를 조작함으로써 작동한다. 큐잉을 사용하는 업체들은 대기열로 인해 TCP가 자동으로 스스로 작아지기 때문에 TRS(TCP Rate Shaping)는 불필요하고 자연스럽지 못하며 IETF에서 규정한 것도 아니라고 주장하고 있다.
TRS는 또한 UDP(User Datagram Protocol) 트래픽을 처리하지도 못한다. 이것은 하지만 사소한 일인데, 그 이유는 TRS를 사용하는 트래픽 쉐이핑 업체는 어느 곳이든 제 2의 큐잉 기반 알고리즘을 이행해 UDP를 처리할 것이기 때문이다. 앨럿과 라이트스피드는 모두 큐잉 트래픽 쉐이퍼를 만들고 있다.
TRS는 TCP 제어 데이터와 창 크기를 조작함으로써 작동하며, TCP 세션을 훨씬 더 느린 회선에 있는 호스트와 커뮤니케이션을 하는 것처럼 믿게 만든다. 모뎀 사용자가 T3에 있는 서버에 접속할 경우 이와 유사한 쉐이핑이 당연히 발생할 것이다.
TRS 업체들은 큐잉이 대기시간을 추가하고, 더 많은 패킷 유실을 가져오며, 수신 트래픽을 느리게 하는 것 만큼 좋지가 않다고 주장하고 있다. 패킷티어와 시타라는 모두 TRS를 사용하는 업체들이다.
큐잉 업체들이 다룰 수 있는 주요 기술들로는 다음과 같은 네 가지가 있다:
>> PQ(Priority Queuing)는 ToS와 유사한 방식이다. 우선순위가 높은 대기열이 낮은 대기열에 앞서 송신하며, 이는 즉 우선순위가 가장 낮은 대기열은 굶어죽을 수도 있다는 얘기다.
>> CBQ(Class-Based Queuing)는 PQ에서의 기아 문제를 어느 정도 해결했다. 클래스는 최소한의 대역폭을 갖도록 구성될 수 있으며, 가능할 경우 다른 클래스에서 대역폭을 빌려올 수도 있다.
>> WFQ(Weighted Fair Queuing)은 우선순위 레벨을 기준으로 대기열 크기를 늘리거나 줄여준다. 여기서 대역폭 이용도는 참작되지 않는다.
>> HWFQ(Hierarchical Weighted Fair Queuing)은 실시간 트래픽을 기반으로 다양한 트래픽 상황 하에서 최악의 경우 패킷 지연을 평가하며, 대기열 평가에 이 데이터를 사용한다.
큐잉 대 속도 쉐이핑의 논쟁은 수년 동안 계속돼 온 것이지만, 사실 관리 인터페이스, 보고 품질, 그리고 성능은 기반 기술보다도 SUB의 문제라는 게 우리 생각이다.
단기적 이행도 유용
QoS 이행이 꼭 어렵거나 지나치게 시간 소모적인 것은 아니지만 너무 힘들게 하다보면 그렇게 될 수도 있다. 절대적으로 필요한 애플리케이션들을 선택하고, 이들이 충분한 네트워크 자원을 언제나 확보하고 있는지를 확인하라. 아니면 그냥 최악의 범죄자들을 제한하라.
이 글의 결론은 성능 부족을 바로 더 많은 대역폭에의 필요와 연관짓지 말라는 것이다. 무료로 라우터에서 QoS를 지원함으로써 만족스러운 결과를 얻을 수 있을 때 굳이 기가비트 이더넷으로 이동할 이유가 없다. QoS는 최소한 다음 구매 사이클 때까지 네트워크가 가동되도록 유지하기 위해 단기적으로 사용될 수도 있다.
===== 랜과 왠에서의 QoS =====
궁극적으로 진정한 QoS는 네트워크의 경계선만큼만 확장될 수 있기 때문에 사실상 인터넷 라우터에서 중단된다. ISP와 인터넷 백본 사업자들은 QoS 방안을 존중할 필요가 없기 때문에 사실 이들이 QoS를 간단히 무시해버리는 것도 충분히 예상할 수 있는 일이다.
그렇다면 QoS를 이행해야 할까, 아니면 그냥 대역폭을 더 사는 게 나을까.
‘더 많은 대역폭을 사는 게 좋다’는 논거는 간단하다. 즉 대역폭은 저렴하고 QoS는 복잡하다는 것이다. 용량이 충분하다면 QoS는 의미가 없다. 인터넷은 용량 면에서 계속 성장하고 있으며, 기술적인 진보는 네트워킹 속도를 지속적으로 향상시키고 있다.
이 주장은 왠 쪽 보다는 랜 쪽에서 더 잘 적용된다. 기가비트 이더넷은 가격이 적당하며 대부분의 시스템들은 이것을 포화 상태로 만들기 힘들기 때문에 10기가비트 이더넷은 말할 것도 없다. 하지만 왠 속도는 그렇듯 적당한 가격에서 향상되지 않았으며, 인터넷 접속이 최소한 하루 몇 시간 동안 포화 상태에 있는 것을 쉽게 볼 수 있다.
QoS 기능은 이제 포티넷(FortiNet)의 포티게이트(FordiGate)와 같은 다용도 보안 제품과 VPN 게이트웨이 및 라우터 등 많은 인프라 제품에서 무료로 제공되고 있다.
무제한 공급 모델에서 가장 간과하기 쉬운 문제는 여분의 대역폭이 있을 경우 누군가 이것을 사용하게 될 수 있다는 것이다. 이것은 마치 교통 시스템과 같다. 1930년대 뉴욕시에서는 기존 구간에서의 정체를 완화하기 위해 두 개의 다리를 만들었다. 다리가 완성되고 난 후 늘어난 수용량에도 불구하고 정체는 이 프로젝트가 시작되기 전이나 다를 게 없었다.
공유, 음악 교류 및 P2P의 급증으로 인해 대역폭은 더 이상 무한대라는 말이 어울릴 수가 없게 되었다. 웹페이지도 또한 점차 부풀어가고 있다.
콘텐츠 필터로 중요하지 않은 다운로드들을 차단할 수도 있다(사용자가 콘텐츠 필터가 쉽게 암호화된 HTTPS 트래픽을 차단할 수 없다는 사실을 알 만큼 현명하지 못하다는 전제하에). 하지만 수용 가능한 사용 정책을 따르는 트래픽이라 하더라도 파괴력을 행사할 수 있다. 즉 100명의 수신자에게 전송되는 5MB 첨부 파일도 얼마간의 손상을 입힐 수 있다. 웹 서버에 접속하는 사용자들은 DSL 사용자들에게서 모든 대역폭을 앗아가 버릴 것이다. QoS는 모든 사용자가 사이트에서 동등한 경험을 하도록 보장해줄 수 있다.
일부 조직에서는 웹 로그 파일에 대해 웹사이트 분석 툴을 실행하고 있다. 이런 파일들은 여러 기가비트로 구성될 수 있기 때문에 웹 서버에서 FTP로 이들을 다운로딩하는 데 너무 많은 대역폭을 써서 정작 중요한 SQL 룩업에는 거의 대역폭이 남지 않을 수도 있다.
그리고 VoIP가 있다. 독자들은 VoIP 파일로트가 많은 IT 관리자들의 아젠다란 얘기를 한다. 당신도 마찬가지라면 QoS가 필요할 것이다. 대역폭 포화 기간이 아무리 짧다고 하더라도(몇 초밖에 되지 않더라도) 전화 통화에서는 단절이 일어날 수 있다. VoIP 호출이 POTS 호출만큼이나 상태가 좋다는 보증이 없이는 경영진이 VoIP 배치를 승인하도록 만들기가 힘들 것이다.
=================================================================
Executive Summary
Quality of Service
완전한 세상이라면 QoS는 인터넷에 처음부터 구축되었을 것이며, 그랬더라면 일관성 없는 대역폭 이용, 지터 대기시간, 패킷 유실, 그리고 탐욕스러운 애플리케이션들로 인해 걱정할 필요도 없었을 것이다.
하지만 세상은 완전하지 않으며, 따라서 VoIP(Voice over IP)와 같은 스트리밍 미디어에 대해서는 정량의 대역폭뿐만 아니라 낮고 일정한 대기시간을 보장해야 한다. FTP나 웹 트래픽과 같은 애플리케이션들은 대기시간에 민감하지 않을지 모르지만, 이들은 미친 듯이 대역폭을 먹어치울 수 있다. 과포화된 네트워크는 패킷 유실과 비효율적인 데이터 전송을 가져오고 사용자를 아우성치게 만든다.
QoS는 몇 가지 방법으로 확보될 수 있다. 압축을 지원하고 더 많은 대역폭을 구입하는 게 가장 간단한 방법이지만, 지연만은 피해갈 수 없을 것이다. 사용자 파이프를 막히게 하지 못하게 할 수 있는 보다 효과적인 방법은 ToS(Type of Service), 인티그레이티드 서비스(Integrated Services), 디퍼런시에이티드 서비스(Differentiated Services), 큐잉, 혹은 TCP 속도 쉐이핑(TCP rate-shaping) 등을 이용하는 것이다. 이들 중에서 인터넷을 가로질러 전송되는 데이터를 제어하는 데는 뒤의 두 가지만이 효과적이다. 나머지는 내부 랜 QoS나 서비스 협정을 맺은 파트너들간에 사용하기에 가장 좋다.
부족할 때는 언제든 더 많은 대역폭만 사면된다는 식의 생각을 해서는 안 된다. 몇 가지 간단한 QoS 정책을 이행함으로써 기간 업무 프로토콜을 존중하면서 대역폭에 목말라하는 애플리케이션을 달랠 수 있다. 그리고 QoS 능력은 네트워크 인프라의 많은 조각들에서 지원되고 있기 때문에, QoS 시행 비용은 최소화될 수 있을 것이다.
