왠 가속기
상태바
왠 가속기
  • 승인 2005.01.12 00:00
  • 댓글 0
이 기사를 공유합니다

압축·QoS 이용 속도·전송 상태 향상 … ‘페리비트’ 관리 소프트웨어 막강
“추가 대역폭 없이 왠의 병목을 너머…”

압축·QoS 이용 속도·전송 상태 향상 … ‘페리비트’ 관리 소프트웨어 막강

왠 가속기(WAN accelerator)는 추가 대역폭이 없는 상태에서 처리 속도를 높이고 전송 상태를 향상시켜준다. 이번 호에서는 케이블링, 압축 및 QoS를 이용해 네트워크에서 데이터를 가속화해주는 네 가지 제품을 테스트해 보았으며, 그 결과 뛰어난 관리 소프트웨어를 보유한 페리비트 제품이 우승의 영광을 안았다.
Mike DeMaria·mdemaria@nwc.com

랜이 기가비트 속도로 데이터를 전달할 수 있다 하더라도 대부분의 왠은 최대 속도가 45Mbps다. 지사들간의 접속은 심지어 이보다 더 느려질수도 있으며, 대기시간과 패키 유실로 인해 처리속도는 꼼짝할 수가 없게 된다.
다행히도 왠 가속기는 이런 병목 현상을 피할 수 있게 해주며, 처리속도를 높이고 전송상태를 향상시켜준다. 게다가 여기에는 추가 대역폭이 필요치 않다. 이러한 하드웨어 장비들은 또한 왠 최적화기(WAN optimizer)라고 불리기도 하는데, 데이터를 압축 및 캐싱하며, TCP 파라미터를 변경하고, 우선순위 지정과 속도 쉐이핑(rate shaping) 기능을 이용해 QoS를 강행한다. 일부 업체들은 자신들의 장비가 성능을 10배로 향상시켜준다고 선전하고 있으며, 이번 왠 가속기 테스트에서는 이 정도 수치는 달성할 수 없었지만 거의 4배 가까이 향상된 속도를 얻을 수 있었다.

추가 대역폭 필요 없어
왠 가속기는 전혀 새로운 개념이 아니다. 모뎀들까지도 전화선으로 데이터를 보내기 이전에 이들을 압축하고 있다. 전형적인 셋업에서, 왠 가속기는 왠 회선의 각각의 종단에 놓인다. 이 어플라이언스는 VPN 장비의 암호화되지 않은 명문(clear-text)쪽과, 방화벽이나 인터넷 라우터의 뒤에 배치돼 모든 트래픽을 가로챈다. 트래픽은 압축돼 왠을 통해 전송된 다음 원격 가속기를 통해 압축이 해제돼 목적지로 전달이 된다.
왠 가속기의 효율성을 테스트하기 위해 우리는 6개 회사들에게 본지 시러큐스 대학 리얼월드 랩으로 제품을 보내줄 것을 요청했으며, 익스팬드 네트웍스(Expand Networks), 패킷티어(Packeteer), 페리비트 네트웍스(Peribit Networks) 및 스완랩스(Swan Labs) 등 업체들이 제품을 보내 왔다. 리버베드(Riverbed) 장비는 우리의 필요조건을 충족시켰지만 우리가 테스트하고자 했던 QoS 기능이 없었기 때문에, 이 회사는 참가하지 않기로 결정을 내렸다. IT웍스(ITWorx)도 또한 초청을 했지만 알고보니 이 회사는 스완랩스에서 이미 인수한 상태였다.
하나는 본사용 장치로, 두 개는 원격지용 장치로, 업체당 3개씩 테스트를 해 보았다. 일반적으로는 갖고 있는 왠 회선보다 하나가 더 많은 왠 가속기가 필요할 것인데, 이는 각각의 지사용 장치에다 본사용 장치 하나가 추가되기 때문이다. 그리고 각 제조업체들은 전용 압축방안을 사용하고 있기 때문에 모든 장비는 한 업체 것으로 구입을 해야 한다.
가속기는 조직의 구성에 따라 허브 앤 스포크 방식이나 망 구조 방식으로 배치될 수 있다. 하지만 수동으로 연결을 만들어야 하는 장비들은 망 구조 환경에서 구성하기가 힘들 수 있으며, 이것이 바로 익스팬드와 스완랩스 가속기의 한 가지 한계점이었다. 이에 비해 패킷티어의 패킷쉐이퍼 엑스프레스(PacketShaper Xpress)는 피어를 탐지해서 자동으로 압축 터널을 만들어 냄으로써 구성 프로세스를 보다 더 수월하게 만들어 두었다.
또한 특히 망 구조 구성에서 많은 수의 왠 연결을 관리하고 있는 경우에는 중앙식 관리 소프트웨어를 이용하는 것도 생각해 볼만하다. 중앙식 관리 소프트웨어는 어디에나 배치가 가능하지만, 이상적으로 볼 때 본사에 있는 별도의 윈도 서버가 바람직하다. 관리 소프트웨어는 모든 장치를 폴링하고, 모든 어플라이언스로 구성 파일을 푸싱해준다.

압축의 법칙
대체로 압축이 잘 되는 데이터일수록(텍스트 파일이나 웹 페이지 등) 처리속도가 높다. 한 벤치마크에서 우리는 시뮬레이팅된 T1 회선에서 30개 웹 페이지를 93초만에 전송했다. 압축이 지원되는 상태에서 이 수치는 대폭 줄어들었는데, 예를 들어 페리비트의 SM-500의 경우는 24초만에 전송이 됐다. 바이너리 파일, 비반복 데이터, VoIP 트래픽, 스트리밍 비디오, 그리고 이미 압축된 트래픽은 웹이나 텍스트 파일만큼 좋은 결과가 나오지 못했다. 임의의 ASCII 및 확장 ASCII 문자들로 구성된 15MB 데이터 파일을 전송했을 때는 불과 1초 남짓밖에 줄어들지 않았다.
일부 제품들은 또한 반복되는 트래픽도 매우 잘 처리했다. 42MB 파워포인트 데이터 파일을 전송한 다음, 여기에 사소한 변경을 가해서 재전송을 하자 페리비트 SM-500 및 익스팬드 액셀러레이터즈는 변경된 파일을 분 단위가 아니라 초 단위로 전송했다. 이런 장비들은 전통적인 방식의 파일 캐시를 사용하지 않고 있다. 즉, 이들은 프록시로 작동하는 것도 아니고, 파일 이름을 살피는 것도 아니다. 대신 이들은 네트워크 트래픽의 패턴을 본다. 서버는 언제나 접속된 상태로, 완전한 파일을 전송하며, 네트워크 가속기는 무엇이 전송돼야 할지, 무엇이 전송되지 말아야 할지를 결정한다.
전통적인 파일 캐시들은 파일을 다운로드 하지 않고 그 로컬 카피를 클라이언트에게 보낸다. 반복되는 트래픽을 탐지하는 데는 업체 전용의 패턴 매칭(pattern-matching) 알고리즘이 사용된다. 일부 장비들은 특정 데이터 블록 안에 있는 반복되는 패턴을 탐지하며, 이와 달리 지난 패턴을 기반으로 앞으로의 패턴을 예측하려는 것들도 있고, 트래픽의 작은 세그먼트를 이용해 이런 세그먼트들이 보다 큰 패턴의 일부인지 여부를 파악하는 것들도 있다.
장치 내에 있는 스토리지 공간이 많을수록 캐싱될 수 있는 데이터 양이 늘어나고, 장비에서 가능한 압축 사전(compression dictionary)도 보다 커진다. 이 사전은 연간된 비압축 값을 이용해 압축 정보를 상호연관시키는 데이터의 집합을 말한다. 압축 알고리즘은 사전을 참조해서 데이터를 축소하거나 확장시킨다. 페리비트 SM-500은 경쟁자들의 네 배, 즉 최고 16GB까지 램을 장착할 수 있다.
페리비트 제품처럼 하드드라이브가 있는 제품은 많은 양의 데이터를 저장할 수 있게 해준다. 500GB 공간이 사용 가능할 경우, 하나의 T1이 캐시를 고갈시키는 데는 몇 주가 걸릴 것이다. 램 캐싱은 디스크 캐싱보다 뛰어난 성능을 제공하지만, 느린 속도에서는 그 효과가 그리 눈에 띄지 않을 것이다.
우리의 네트워크에서 나타난 결과와는 관계없이, 각자의 왠 성능은 어떤 종류의 데이터를 전송하느냐, 얼마나 자주 보내느냐, 얼마나 압축이 가능하며, 캐싱은 얼마나 쉽게 이뤄질 수 있느냐에 따라 달라질 것이다. 크고 압축이 불가능한 파일(그래픽이나 오디오/비디오 파일 등)을 보내고 있다면, 그리 좋은 처리속도를 얻지 못할 것이다. 반면에 주가목록이나 식료품점 UPC 코드 등과 같이 똑같은 기본적인 텍스트 파일들을 매일 같이 변경 및 전송하는 경우에는 캐싱 능력이 뛰어난 페리비트 SM-500이나 익스팬드 액셀러레이터 등을 이용해 막대한 성능 향상을 볼 수 있다.
중간 수준의 압축 상황(압축 가능한 텍스트 파일과 압축 불가능한 임의 파일들의 조합)에서 이런 장비들을 테스트하자 150~230%의 성능 향상이 목격됐다. 고 압축 테스트를 수행했을 때(각각 최소 50%의 압축이 가능한 텍스트 파일과 웹 페이지), 처리속도는 380%까지 치솟았다.

최적의 TCP, QoS 찾기
패킷 유실과 높은 대기시간은 TCP 접속 속도를 다시 떨어뜨리는 원인이 된다. 이는 곧 1.5Mbps 접속에 대한 돈을 지불하면서 500Kbps밖에는 사용하지 못한다는 것을 의미한다. 저렴한 요금 덕분에 인기를 얻고 있는 VPN의 경우 대기시간과 패킷 유실에 대해 할 수 있는 일이 거의 없다. 우리가 테스트한 제품들은 모두가 자체적으로 하는 것보다 TCP 속도 저하를 보다 신속하게 복구할 수 있도록 도와줬다.
마지막으로 트래픽 우선순위 지정을 통해 보다 덜 중요하고 시간에 덜 민감한 트래픽을 억압함으로써 애플리케이션 응답 시간을 향상시킬 수 있다. 채택된 QoS 메커니즘은 프로토콜 우선순위 지정과 속도 제한이다. 디프서브나 인트서브(DiffServ/IntServ) 기술은 찾을 수 없을 것이며, 일부 업체들이 ToS(type of service) 비트를 지원하긴 하지만 이것은 그리 도움이 되지 못한다. 대신 특정 사용자나 애플리케이션이 액세스하게 되는 대역폭 양을 제한하거나, 혹은 최소값 보증을 설정할 수 있다. 테스트한 모든 장비들은 TCP 창 크기를 조정해서 TCP 트래픽을 제어할 수 있었고, 모두가 UDP용 큐잉 알고리즘을 이용하고 있었다.
제품들이 QoS 정책을 얼마나 잘 지키는지를 파악하기 위해 우리는 QoS가 지원되는 상태에서 30개의 압축률 높은 웹 페이지를 전송했다. 우리의 목표는 웹 페이지가 HTTP용으로 사용 가능한 대역폭의 95~97%를 얻는 것이었다. 이 테스트에서는 예상대로 패킷티어의 패킷쉐이퍼 엑스프레스가 단연코 빛이 났다. 패킷티어는 뛰어난 QoS 제품으로 시작해서 압축 부문을 추가한 반면, 다른 업체들은 역으로 진행해 왔기 때문이다. QoS 정책을 지원하자 패킷쉐이퍼는 불과 3초의 전송 속도만이 추가됐으며, 이는 곧 큰 지연이 없이 정책을 고수할 수 있다는 점을 나타내 주는 결과다.

효과 만점
결국 그 뛰어난 성능 수치와 간편한 관리 덕분에 에디터즈 초이스는 페리비트 SM-500에게 돌아갔지만, 각각의 제품은 저마다의 강점을 갖고 있다. 네 가지 가속기들이 모두 왠 성능을 향상시키고, 간편한 구성 옵션을 제공하며, 고급 구성 기능들로의 액세스를 주고, 보다 명확한 보고서를 만들어 낸다. 게다가 모두가 패스쓰루 페일오버(passthrough failover)를 지원한다. 만약 어떤 가속기의 플러그를 뽑더라도 트래픽은 이 장비가 여전히 연결돼 있는 것처럼 이를 통과해 전달된다.
모든 업체들이 회선 속도를 기반으로 제품을 라이선싱하고 있으며, 같은 하드웨어 모델이 T1에서 T3까지 다양한 속도를 지원하는 경우도 많다. 왠 속도를 바꿀 경우에는 새 라이선스 키만 있으면 된다. 페리비트와 스완랩스는 둘 다 지사와 본사용으로 같은 하드웨어 모델을 제시했다. 페리비트의 경우는 1.544Mbps 라이선스가 1만9천750달러고, 10Mbps 라이선스가 4만1천달러다. 스완랩스는 각기 1만499달러와 3만3천999달러를 받고 있다.
우리의 모든 벤치마크는 1.544Mbps 연결에서 이뤄졌다. 허브 스포크 환경에서는 지사용 장비보다 본사용 장비에서 더 높은 속도가 필요할 것이다. 별도의 비용을 지불할 각오도 또한 해야 한다. 하나의 본사용 장비를 배치할 계획이라면 보다 큰 사전을 저장하기 위해 추가 메모리가 필요할 것이기 때문이다. 업체측의 집중식 관리 소프트웨어를 이용하려면 2천499달러~1만5천달러 가량을 들여야 할 것이다.

페리비트 네트웍스
SM-500

SM-500(Sequence Mirror-500)은 뛰어난 성능과 강력한 사양들을 갖추고 있다. SM-500은 별도의 압축 사전 데이터를 보관하기 위한 하드 드라이브를 갖춘 유일한 제품이었다. 이 모델에는 500GB의 스토리지가 듀얼 250GB IDE 드라이브의 형태로 들어 있다. 드라이브가 찰 때까지 데이터는 캐싱이 되며, 그런 다음에는 오래된 것부터 삭제된다. 캐싱 기능을 제공하는 다른 장비로는 익스팬드 제품이 유일했다.
페리비트 장비는 또한 반복되는 네트워크 트래픽을 탐지해 낸다. 우리는 42MB의 파워포인트 파일을 204초만에 T1 회선에서 전송했다. 그런 다음 원래의 것과 변경된 파일 사이에 1MB도 안되는 차이가 나도록 파일을 변경했다. 새로 만들어진 43MB 파워포인트 파일이 전달되는 데는 6초도 채 걸리지 않았다. 나아가 고 압축 웹 테스트에서 SM-500은 93초에서 24초로 전송 시간을 줄였는데, 이는 가장 가까운 경쟁자보다도 훨씬 빠른 속도였다.
SM-500은 패킷 유실에 직면했을 때 매우 잘 수행됐다. 낮은 속도 회선 테스트에서는 250ms의 왕복 대기시간과 0.5%의 임의 유실률로 T1에서 전송을 완료하는 데 962초가 걸렸지만, 에러 보정(error correction) 기능을 작동시키자 109초밖에 걸리지 않았다. 이는 2위 제품보다 절반도 채 되지 않는 시간이다. 이 장비는 또한 QoS 테스트도 잘 수행했다.
왠에 SM-500을 추가하기는 간단하다. 네트워크에 있는 어떠한 페리비트 장비든 등록 서버(registration server)처럼 작동할 수 있으며, 단 허브 앤 스포크 환경에서 가장 논리적인 선택은 중앙 장비가 된다. 각각의 추가 스포크 장비용으로 IP 어드레스와 패스워드를 입력하면, 등록 서버는 압축 터널을 수립한다. 망 구조일 경우에는 등록 서버가 스포크들에게 망 안에 있는 다른 모든 장비들에 대해 알려주며, 모든 연결을 수립한다. 등록 서버는 또한 제한적인 애드혹 관리를 설정할 수 있게 해주기 때문에, 동료가 그 압축 설정을 받아서 다른 동료들의 위치를 파악할 수도 있다.
SM-500은 또한 장비들간 랜 투 랜 IPSec VPN 터널을 만들 수 있다. 하지만 이런 장비들은 같은 것들끼리 나란히 사용되도록 만들어졌기 때문에 페리비트 장비들간에만 VPN 터널을 만들 수 있다. 하지만 이 업체의 하드드라이브 모델과 비 하드드라이브 모델은 함께 섞어서 사용할 수 있다.
중앙식 관리 소프트웨어는 모든 종단 장비들로의 구성을 제어하고 읽고 띄울 수 있게 해준다. 또한 트래픽 우선순위 지정 정책, 시스템 구성 및 펌웨어 개정 등과 같이 더 많은 옵션들을 설정할 수도 있다. 이 소프트웨어는 모든 장비에서의 압축 효과를 볼 수 있게 해주며, 기본적인 통계와 수치들이 있는 맞춤 홈페이지를 만들 수 있게 해준다.
SM-500의 보고 엔진은 좋은 편으로, 통계 표와 트래픽의 및 선그래프, 압축률, QoS 등을 볼 수 있었다. 또한 그래프에 시간 간격을 지정할 수도 있었다. 하지만 이런 그래프들은 엑스포팅이 불가능했다.
페리비트는 추가 하드웨어와 기능에 대해 상당한 비용을 요구하고 있다. SM-500의 본사용 장비는 테스트한 제품의 경우 4만1천 달러며, 지사용 장비는 1만9천750달러다. 두 번 째로 비싼 스완랩스 제품의 경우는 각각 3만3천999달러와 1만499달러다. 하지만 최종평가에서 가격 부문의 상당한 벌점을 안고서도 이 시스템은 역시 경쟁자들을 물리칠 수 있었다. 다른 어떤 장비도 SM-500의 막강한 성능에는 근접하지 못했기 때문이다.

익스팬드 네트웍스
액셀러레이터 4820 및 6810

익스팬드 네트웍스의 액셀러레이터와 패킷티어의 패킷쉐이퍼 엑스프레스 장비는 최종평가표에서 동률을 기록하긴 했지만, 성능과 가격 면에서는 익스팬드 장비가 좀더 앞섰다. 이것이 우리 테스트 장비의 새 펌웨어를 지원하지 않는 액셀러레이터의 중앙식 관리 시스템용이 아니었더라면, 아마도 강력한 1위 후보자가 됐을 것이다.
익스팬드의 액셀러레이터는 콘솔 케이블과 전면 패널의 푸시 버튼 스위치, 그리고 웹 셋업 마법사가 있어 구성이 비교적 간편했다. 하지만 수동으로 한 가속기에서 연결을 설정해야 그 피어들이 자체적으로 구성된다.
액셀러레이터 대역폭 한계와 우선순위 지정을 설정하기는 간단했다. 이 장비는 HTTP와 사이트릭스 통신에서 레이어 7 점검 기능을 지원한다. 각각의 애플리케이션에는 우선순위나 대역폭 보증 및 제한이 할당될 수 있다. 우리는 효력을 갖는 QoS 정책을 특정 IP, 서브넷, 혹은 가속기 연결로 제한했다. 하지만 정책 준수 상황은 일관되지 못했다. 이 장비는 고 압축 웹 테스트를 39초만에 통과했지만, 95%가 고 우선순위의 웹 트래픽일 경우 FTP 트래픽과 동시에 실행시켰을 때 이를 전송하는 데 78초가 걸렸다. 우선순위를 가장 높은 설정인 실시간으로 지정하자 같은 테스트에 42초밖에 걸리지 않았다. 조금 더 낮은 우선순위에서 왜 대역폭 스레숄드가 그만큼 잘 지켜지지 못했는지에 대해 익스팬드는 명쾌한 해답을 제시하지 못했다.
액셀러레이터는 파워포인트 테스트에서 거의 페리비트 장비 만큼이나 좋은 성능을 냈으며, 사실상 중간급 압축 테스트에서는 1위와 동률이기도 했다. 하지만 페리비트 장비와 달리 엑셀러레이트에는 하드 드라이브가 없으며, 따라서 설치된 램이 있는 만큼 많은(42MB 파일만이 아니라) 비반복 데이터를 장비를 통해 전송했다면, 캐싱된 파워포인트 콘텐츠는 덮어쓰기 되었을 것이다. 액셀러레이터는 또한 패킷 유실 테스트에서 2위와 격차가 먼 3위에 그쳤다.
중앙식 보고 기능은 테스트할 수가 없었지만, 기본적인 종단 장비 보고는 볼 수 있었는데, 간단하다 못해 지나치게 단순한 것 같아 보였다. 선그래프에서는 작업처리량, 회선 활용도, 가속률 및 압축률을 확인할 수 있다. 또한 레이어 2 정보(바이트, 패킷 및 CRC 에러 등)에 대한 원시 통계도 볼 수 있을 것이다. 사전에 설정된 시간 간격으로만 그래프를 얻을 수 있지만, 이들은 엑셀 파일로 엑스포팅이 가능하다. 특정 애플리케이션에 대한 통계를 보여주는 막대 그래프도 또한 사용할 수 있다. 하지만 그래프를 읽으려면 자바가 설치 및 지원돼야 한다.
QoS가 지원되는 제품으로, 익스팬드 엑셀로레이터는 5만 달러 아래의 유일한 왠 최적화 제품이다. 중앙식 관리를 채택할 계획이 없는 한 이 제품의 향상된 버전을 기다릴 것을 권장한다. 중앙식 관리 및 보고 소프트웨어가 완비될 경우 이 장비는 매우 매력적이고 경제적인 선택이 될 것이다.

패킷티어
패킷쉐이퍼 2500/6500 엑스프레스

패킷티어는 우리가 한때 에디터즈 초이스로 선정했던 제품에 진행 중 압축 기능을 추가했지만, 패킷티어 엑스프레스에서 그 새 이름에 걸맞는 속도를 찾아보기는 힘들었다. 이 장비에는 최고의 트래픽 쉐이핑 기능이 있으며, 가격과 성능은 테스트한 제품들 가운데 가장 낮았다. 압축 터널을 설정하기는 간단했다. 압축 기능을 켜기만 하면 장비가 자동으로 피어를 탐지하고 압축 터널을 만들어 준다. 패킷쉐이퍼는 많은 옵션을 제공하며, 각 정책용으로 정밀한 제어가 가능하다. 이러한 수준의 정밀성이 유일하게 갖는 약점은 QoS 정책을 구성하기가 쉽지 않다는 점이다.
우리 QoS 테스트에서 패킷티어는 다른 어떤 장비도다도 우리가 요구했던 정책에 가깝게 고수를 했다. 원래 70초가 걸리던 고 압축 웹 테스트는 트래픽 쉐이핑 정책이 지원될 때도 72초밖에 걸리지 않았다. 그 어떤 장비도 우리의 95% 보증된 대역폭 필요조건을 이처럼 가깝게 달성한 제품은 없었다. 하지만 불행히도 패킷쉐이퍼 엑스프레스는 다른 부문에서는 좋은 결과를 보여주지 못했다. 파워포인트 테스트에서는 어떠한 속도 향상도 볼 수가 없었으며, 다른 모든 테스트에서도 최하위를 기록했다.
중앙식 관리는 폴리시센터(PolicyCenter)를 이용해 가능하다. 우리는 몇 개의 그룹을 지정하고, 각각의 그룹용으로 구성과 QoS 정책을 설정했다. 그런 다음 지사용 장비로 로그온을 해서 폴리시센터 컴퓨터의 IP를 지정했다.
테스트한 장비들 가운데 패킷쉐이퍼에는 최고의 보고 기능이 있으며, 각각의 장비는 모든 압축 레벨과 애플리케이션 성능 및 활용도를 디스플레이하고 그래프로 보여줄 수 있다. 리포트센터(ReportCenter)는 모든 장비들로부터 데이터를 수집하는데, 여기서 패킷쉐이퍼를 다양한 로케이션이나 네트워크로 그루핑을 하고, 하나, 혹은 여러 개 장비용의 그래프를 만들 수 있다.
QoS 정책을 강력히 이행할 장비가 필요하다면 패킷쉐이퍼가 맞겠지만 그렇지 않을 경우에는 다른 제품이 나을 것이다.

스완랩스
넷셀레라

넷셀레라(NetCelera)는 테스트를 잘 통과하긴 했지만, 올해 초 스완랩스가 IT웍스(ITWorx)로부터 인수한 이 장비에는 셋업, 관리 및 QoS 정책 고수 등에서 몇 가지 단점이 드러났다.
우선 넷셀레라의 압축 터널은 수동으로 구성돼야 한다. 다행히도 이 제품의 중앙식 관리 소프트웨어는 설치된 다른 모든 넷셀레라 제품들을 인식했다. 하지만 자동탐지 기능의 부족 때문에 대형 망구조 네트워크를 만들기에는 충분치가 못하다. 이 제품은 또한 트래픽 쉐이핑 기능도 떨어졌다. 넷셀레라는 각각의 왠 회선에 자체 정책을 주는데, 여기서는 각 프로토콜용으로 최소, 혹은 최대 대역폭을 전체 중 차지하는 비율로 설정할 수 있다.
이 장비는 우선순위 지정 기능은 제공하지 않으며, 다중 왠 회선에서 정책을 공유할 수도 없다. 넷셀레라의 성능은 여러 벤치마크에서 좋은 편이었지만, QoS 정책 준수와 파워포인트에서 비틀거리는 모습이었다.
넷셀레라의 보고서는 정확했다. 활용도와 압축률을 백분율로 보여주는 그래프를 만들 수 있으며, 전체 송수신 트래픽을 그래프로 나타낼 수도 있다.

Executive Summary

왠 가속기

왠 가속기는 캐싱, 압축 및 QoS 기술을 이용해 전송 속도를 향상시킨다. 네트워크 캐싱에서, 가속기들은 전용 알고리즘을 이용해 데이터 트래픽 패턴을 탐지하며, 전송 시간을 분 단위에서 초 단위로 줄여줄 수 있다. 압축은 네트워크를 이동하는 트래픽을 줄여주는 알고리즘과 체크섬을 이용해 이뤄진다. QoS는 이런 장비들이 트래픽에 우선순위를 지정함으로써 시간에 민감한 데이터가 목적지에 먼저 도착할 수 있도록 해준다.
우리는 익스팬디드, 패킷티어, 페리비트 및 스완랩스 등의 왠 가속기를 테스트했다. 이들은 모두 파일 크기와 압축 능력에 관계없이 파일 전송 속도를 높여주었다. 에디터즈 초이스는 뛰어난 관리 소프트웨어를 제공하고, 몇몇 성능 테스트에서 극적인 우승을 거둔 페리비트 SM-500에게로 돌아갔다.

왠 가속기 테스트 방법

테스트에 참가한 각 업체는 10Mbps 접속을 지원하는 하나의 본사용 장비와 T1(1.544Mbps)의 지사용 장비 두 개를 제출했다. 우리는 션라 스톰 STX-100 라인 시뮬레이터를 이용해 왠을 만들었으며, 여기서 라우팅을 하고 대기시간을 삽입하며 패킷 유실을 유발시켰다. 원격 사무소에서는 넷기어 FS108(Netgear FS108) 스위치를, 본사용으로는 시스코 카탈리스트 2948G 스위치를 사용했으며, 접속은 100Mbps 전이중으로 설정했다. 원격 사무소에 있는 5대의 클라이언트 기계는 본사의 두 대의 서버로부터 데이터를 풀링한다. 클라이언트는 600MHz 펜티엄 3 장비로, 256MB 램이 장착돼 있었으며, 서버는 1GB 램과 35GB 레이드 5 드라이브가 있는 듀얼 2.4GHz 제온이었다.
우리는 다양한 수준의 압축 능력으로 파일들을 테스트했으며, 머큐리 인터랙티브의 로드러너(RoadRunner) 에뮬레이터를 이용해 FTP, HTTP 및 IMAP 테스트를 실시했다. 맞춤 프로그램으로 임의의 텍스트 및 HTML 파일들을 만들어 냈으며, 임의의 데이터 파일은 일반 및 확장 ASCII 문자를 포함하고 있어 거의 압축이 불가능했다. 텍스트 및 HTML 파일은 125만1천140개의 단어와 구문이 담긴 사전으로부터 임의로 단어를 풀링함으로써 만들어졌다. HTML 파일은 중간 정도로 가능했으며, HTML 파일은 HTML 태그 반복과 임베디드 테이블 및 임베디드 GIG 파일들 덕분에 고도로 압축이 가능했다.
하지만 우리는 최고 99개의 고유의 GIF 파일들을 레퍼런싱하는 웹 페이지 60개를 만들었는데, 우리가 전송한 대부분의 페이지에는 2~10개의 GIF가 포함됐다. 우리는 약 절반 메가바이트로 10개의 임의 데이터 파일을 만들고, 2~10MB의 FTP 트래픽으로 된 10개의 텍스트 파일을 만들었다. 그리고 이메일 메시지용으로 6KB와 18KB사이의 텍스트 파일 10개를 만들고, 첨부파일을 나타내주는 59KB~1.2MB 임의 파일 10개를 만들었다.
압축 테스트용으로는 세 가지 데이터 세트를 만들었는데, 각각은 독특하지만 크기와 콘텐츠 면에서 서로 유사한 것들이었다. 우리는 각각의 벤치마크를 세 차례 돌린 다음 그 결과의 평균을 냈다. 세 테스트에서 모두 다음의 조건들을 적용시켰다: 50ms의 왕복 지연. 지터 없음. 패킷유실률 0.
파워포인트 테스트에서는 이전에 전송된 덩치 큰 파일을 탐지할 수 있는지 여부를 테스트했다. 이 테스트를 완료하기 위해 우리는 내부의 CMP 웹 서버에서 다중 CMP 지사 사무실로 42MB 파워포인트 파일을 다운로드했다. 그런 다음 프리젠테이션의 중간에 있는 슬라이드 하나를 변경하고, 이 파일을 ‘presentation2.ppt’로 저장했다. 이 두 개의 파일들은 818KB 데이터만큼만 서로 달랐다. 우리는 첫 번째 파일을 전송한 다음, 위의 테스트와 같은 대기시간, 지터 및 패킷유실 조건으로 윈도 FTP를 이용해 두 번째 것을 보냈다.
QoS 시행 테스트에서는 압축이 지원된 30개 웹 페이지의 전송 시간을 쟀으며, 그런 다음 각 장비에 있는 캐시를 비우고 크고 압축 불가능한 FTP 전송을 실시했다. 그리고 이와 동시에 웹 전송도 다시 한번 실시했다. 첫 번째 전송과 두 번째 전송이 거의 같은 시간이 걸릴 것으로 예상했는데, 이런 결과는 대역폭이 고 우선선위 애플리케이션에 적절하게 할당됐음을 나타내 준다.
마지막으로 우리의 느린 회선 테스트는 이와는 다른 조건들, 즉 250ms 왕복 대기시간, 10% 지터 및 0.5%의 임의 패킷 유실률 상태에서 측정됐다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.