인터넷이 느려지는 숨은 이유 ‘버퍼블로트’와 해결 방법

2010년 현재 구글에서 근무하고 있는 베테랑 컴퓨터 프로그래머 짐 게티스는 집에서 자신의 업무용 서버로 파일을 업로드하고 있었다. 그의 아이들이 그를 찾아와 "아빠, 오늘은 인터넷이 느려요"라고 말했다. 그는 자신의 업로드 활동이 아이들의 다운로드에 어떻게 영향을 끼칠 수 있는지 궁금해 하다가 조사를 시작했다.

인터넷 연결에서 핑(Ping)과 여러 수준의 부하를 실험하면서 게티스는 지연 속도가 때로는 예상보다 4~10배 더 높다는 사실을 발견했다. 이 현상을 "버퍼블로트(Bufferbloat)"라고 명명한 게티스는 임계 데이터 패킷이 과도하게 큰 버퍼에 갇혔다고 결론 내렸다.

게티스가 관찰해 알리기 시작한 이후로 시스코와 구글 등의 대형 업체, IETF 등의 표준 그룹, 주요 대학과기관의 연구원들은 버퍼블로트를 조사 및 시험하고 이에 관한 논문을 작성했다. 필자 역시 간단한 시험을 실시했다. 버퍼블로트는 실제로 존재한다. 정상적인 인터넷 트래픽의 흐름에 대한 영향의 범위가 아직 완전히 파악되지 않은 것이다.

그렇다면 이 현상에 가장 큰 영향을 받는 사용자는 ?
능동적인 브라우징(Browsing)을 수행하거나 검색 엔진을 사용하는 사람이면 누구나 해당된다. 또한 음성이나 영상 등의 실시간 애플리케이션을 사용하는 사람도 그렇다. 집이나 호텔에서 와이파이 핫스팟을 이용해 일하는 직원들을 예로 들 수 있다. 필자의 조사에서는 호텔과 와이파이 카페가 심각한 버퍼블로트 문제가 발생하기 쉬운 것으로 나타났다.

어떤 종류의 트래픽이 영향을 받는가?
대역폭 활용이 높은 링크에서 반대 방향으로 흐르는 트래픽이 저하된다. VoIP, DNS, APR 등의 소형 패킷을 이용하는 애플리케이션 또한 문제가 될 수 있다. VoIP에 대한 영향으로 지연 속도와 지터가 증가한다. DNS 쿼리는 정상 응답 시간의 2~8배 늦게 되돌아 올 수 있다.

인터넷 운영에 영향을 끼치는 이 문제가 어떻게 그렇게 오랫동안 숨어 있을 수 있었나?
여기에는 3가지 이유가 있다. 우선, 이 문제는 TCP 프로토콜이 운영되는 방식 및 네트워크 버퍼가 관리되는 방식과 밀접하게 관련되어 있다. 둘 다 광범위하게 파악하지 못한 부분이다. 둘째, 인터넷에서 패킷 드롭은 무조건 나쁜 것이라는 생각이 만연해 있다. 사실, 패킷 드롭은 적절한 TCP 운영에 필수적이다. 셋째, 거의 모든 성능 저하를 없앨 수 있는 방법이 대역폭을 추가하는 것이라는 생각이 팽배해 있다.

그렇다면 버퍼블로트란 정확하게 무엇인가?
인터넷에서 패킷 손실을 줄이기 위한 시도로 통신업체, 개발자, 엔지니어들은 네트워크 버퍼를 몇 배나 증가시켰다. 이로 인해 지연 시간이 증가했지만 처리량에는 거의 영향이 없었다. 그래서 VoIP, DNS, TCP 'ack'에서 사용되는 것과 같은 중요 소형 패킷이 파일 전송이나 가변 비트율 동영상 등의 대용량 전송으로 발생하는 더 큰 패킷에 밀려 버퍼 안에 갇힐 수 있다.

버퍼 관리와 관련된 인식의 문제가 있다. 실험과 백서 그리고 강사들조차 버퍼를 작은 메모리 덩어리로 설명하곤 한다. 버퍼는 어떤 순간이든 수 백, 수 천 개의 패킷을 담을 수 있다. 그리고 단지 네트워크 장비 안에만 있지 않다. 종단국(End Station)의 프로토콜 스택, 네트워크 카드 드라이버, 종단국 사이의 경로에 있는 모든 게이트웨이(Gateway)에도 존재한다.

TCP에 미치는 버퍼블로트의 영향은?
네트워크 트래픽의 대부분은 TCP를 전송 프로토콜로 사용한다. TCP가 동작하는 방식은 버퍼블로트가 문제가 될 수 있는 이유를 보여준다. TCP 연결이 수립되면 3웨이 핸드셰이크(Handshake)를 통해 TCP 개체(Entity)의 송수신은 초기 시퀀스 번호를 포함하여 데이터 교환을 위한 파라미터를 협상한다.

FTP 서버에 대용량 파일을 전송하도록 요청했다고 가정해 보자. 일반적으로 TCP는 4개 세그먼트를 보내고 전달 확인을 기다리는 것으로 전송을 시작한다. 일반적인 확인 정책은 세그먼트를 수신할 때마다 'ack'를 전송하는 것이다.

4개 세그먼트가 'ack'되면 수신자는 8개 세그먼트를 전송하여 전송률을 높이고 확인을 기다린다. 이런 세그먼트 확인 후 전송률이 16 등으로 증가한다.

이 전달 속도를 슬로우 스타트(Slow Start)라고 부른다. 그 핵심은 링크를 패킷으로 포화시키는 것이다. 하지만 슬로우 스타트 한계값의 수준에서 전송자는 속도를 두 배씩 증가시키기보다는 매 회마다 한 번에 1개 세그먼트씩 추가하여 속도를 더 천천히 증가시킨다.

그럼에도 불구하고 버퍼가 넘치면서 연결이 과부하되는 임계점이 존재한다. 그러면 하나 이상의 패킷이 드롭된다. 전송자가 이 현상을 감지하면 일반적으로 전송률을 반으로 줄이고 슬로우 스타트를 다시 시작한다. 결국 TCP 속도는 사용하는 회선의 용량에 적응하게 된다. 이런 일련의 단계를 TCP 정체 제어(TCP Congestion Control) 알고리즘이라 부른다.


그렇다면 버퍼블로트는 어떻게 간섭을 일으키는가?
고속 링크와 저속 링크 사이의 연결을 생각해 보자. 버퍼가 중요하다고 여겨지는 상황이다. 예를 들어, 케이블이나 DSL 모뎀 등 가정용 게이트웨이에 1Gbps가 있다고 가정해 보자. 또한 모뎀이 10Mbps 다운로드 및 2Mbps 업로드를 제공하는 ISP 연결에 연결되어 있다고 가정하자.

FTP 서버는 빠른 연결로 진입하는 버퍼를 느린 링크로의 출구 속도보다 더욱 빠르게 채운다. ack가 전송자가 전송할 수 있는 속도를 궁극적으로 결정하는 속도이다. 하지만 버퍼가 크면 두 가지 상황이 발생할 수 있다. 첫째, 버퍼가 채워지면 마지막으로 도착하는 패킷이 드롭된다. 이것을 테일 드롭(Tail Drop)이라 부른다. 전송자에게 이 패킷 드롭을 알리는 ack는 (버려진 패킷를 뒤를 잇는) 다음 패킷이 도착하고 장애가 발생했음을 선언할 때까지 전송되지 않는다.

큰 버퍼를 통과하는데 상당한 시간이 소요될 수 있다. 가변 비트율 동영상으로 실시한 일부 실험에서 전송 스테이션이 드롭된 세그먼트를 재전송할 때까지 약 200개의 세그먼트를 전달할 수 있었다.

또한 여러 개의 흐름이 유입되는 경우 큐(Queue)가 대기 큐로 진화할 수 있다. 즉, 큐에 고정되거나 거의 고정된 수의 패킷이 있는 대기 상태에 도달할 수 있다. 그 양이 버퍼를 넘치게 하기에 충분하지 않은 경우 패킷이 드롭되지 않고 TCP 정체 제어가 무산된다. 하지만 모든 버퍼 사용의 지연 속도는 증가했다.

버퍼 관리
한 동안 네트워크 큐를 관리해야 한다는 인식이 있었다. 특정 트래픽에 우선순위를 추가하기 위해 IP 계층 diffserv 비트는 네트워크 제어나 VoIP 등의 특정 트래픽 유형을 선호하는 정책을 이행하도록 설정할 수 있다. 우선순위 트래픽 유형을 여러 큐로 분류하여 이를 달성한다.

하지만 버퍼블로트가 없어지지는 않는다. 우선순위가 부여되지 않은 트래픽이 포함된 일부 큐는 계속해서 비대해지는 문제를 안게 된다. 때로는 많은 대용량 TCP 세그먼트가 포함될 때가 있다. 그래서 여전히 TCP 정체 메커니즘에 대한 부정적인 영향의 문제를 계속 겪게 된다.

RED(Random Early Discard)와 WRED(Weighted RED) 등 여러 AQM(Active Queue Management) 기법이 소개되었다. 이런 것들은 버퍼가 임계 수준에 도달할 때 패킷을 버리도록 고안되었지만 반드시 꽉 차야 하는 것은 아니었다. 하지만 이런 기법은 결함이 있었으며 RED 구성은 어려웠다. 그래서 RED와 WRED는 널리 사용되지 않고 있다. 자동이며 조정이 필요 없는 방법이 필요했다.

2012년 케이시 니콜스와 반 제이콥슨는 CoDel(Controlling Queue Delay)이라는 기법을 홍보하기 시작했다. 이 방법은 패킷이 큐에 머무르는 시간을 추적함으로써 큐를 관리하며, 그 이유는 큐에 머무르는 시간이 정말로 중요한 문제이기 때문이다.

두 가지 중요한 파라미터, 인터벌(Interval)과 한계값이 존재한다. 인터벌만큼의 패킷이 대상보다 지연이 길면 패킷이 무작위로 드롭된다. 이 기법은 큐의 크기와 상관 없다. 그리고 테일 드롭도 아니다.

이 절차를 시험하면서 RED보다 지연 속도가 전반적으로 더 나았고 결과도 훨씬 나았다. 특히, 무선 액세스 링크의 경우에는 더욱 그랬다. 또한 이 기법은 하드웨어에 적용하기가 쉬웠다.

버퍼블로트 완화에 대한 또 다른 권고사항은 데이브 태트, 에릭 듀마즈, 짐 게티스 등이 제시했다. fq-codel이라 불리는 것으로, 큐를 통과하는 다양한 흐름에 더욱 일관된 영향을 제공하기 위한 것이다. 케이시 니콜스와 반 제이콥슨도 fq-codel 사용을 지지하고 있다.

이 방법은 기본적으로 큐를 1024개의 하위 큐로 분류한다. 그리고 각각의 새로운 흐름을 개별적인 큐로 무작위 할당한다. 각 하위 큐 안에서 Codel이 적용되어 TCP 정체 제어를 돕는다. de-queue 정책은 DRR(Deficit Round Robin)에 기초하고 있다.


Codel과 fq-codel의 기능은?
첫째, TCP 정체 제어가 고안된 대로 기능하도록 한다. 둘째, 큐들의 패킷을 혼합하여 DNS 응답과 TCP ack 등의 작은 임계 패킷이 큰 큐에 갇히지 않도록 한다. 다시 말해, 큰 패킷과 작은 패킷의 처리를 더욱 공평하게 한다. 여러 연구를 통해 fq-codel의 이점이 입증되었으며, 실제로 최신 리눅스 배포판에 포함되어 있다.

앞으로 어떻게 될 것인가?
안타깝게도 버퍼블로트에 대한 인식이 여전히 널리 확산되지 않았다. 더 많은 통신업체와 사용자들이 ICSI Netylyzr와 www.DSLReports/speedtest/에서의 시험 등 즉시 제공되는 시험을 실시해야 한다. 그리고 상당한 버퍼블로트 문제를 감지하는 경우 여러 대안을 선택할 수 있다.

1. 액세스 하드웨어를 fq-codel이 포함된 새로운 리눅스 배포판을 이용하는 디바이스로 바꾼다. 이 기능이 켜져 있는지 확인한다.
2. 디바이스를 컴퓨터와 fq-codel 기능이 켜져 있는 게이트웨이/라우터(Router) 사이에 배치한다. 그러면 라우터의 대형 버퍼 사용이 제한된다.
3. 나머지가 모두 실패하면 업링크와 다운로드 링크로 제한하는 속도를 정격 용량보다 낮은 것에 적용한다. 그러면 큰 대기 버퍼가 사라진다. 대신에 가벼운 부하에서 처리량이 다소 감소한다. 하지만 DNS, ARP, TCP 확인 등의 임계 흐름이 크게 향상된다.

여러 업체가 버퍼블로트 완화에 깊은 관심을 갖고 있다. 시스코는 컴캐스트와 협력하면서 원래 시스코의 유명한 연구 엔지니어인 롱 판이 개발한 PIE(Proportional Integral controller Enhanced)라는 큐 관리 기법을 도입했다.

타임워너 케이블은 이 문제에 정통한 것으로 보이며 버퍼블로트 완화를 위한 조치를 취할 준비가 되어 있다. 버라이즌과 센추리링크(Centurylink)에 가정용 게이트웨이를 공급하는 액션텍(Actiontec)은 버퍼블로트를 연구했으며, 영향을 완화하기 위한 조치를 취하고 있다고 밝혔다. 주니퍼의 협력사인 럭키스 와이어리스(Ruckess Wireless)는 지속적인 액세스 링크 버퍼링 문제 개선에 매진하고 있다.

하지만 일부 업체는 버퍼블로트에 관해 모르고 있는 것처럼 보였다. 콕스 케이블(Cox Cable) 등은 이 문제가 하드웨어 및 반도체 제조사에 달려 있다고 말했다. 안타깝게도 필자가 연락한 대부분의 주요 네트워크 시험 장비 제조업체는 이 문제에 관해 모르고 있는 것 같았다.

상황이 바뀌어야 한다. 특히 브라우징 등의 활동으로 인한 전체 처리량이 가장 유해한 요소가 아니라는 사실을 이해하는 것이 중요하다. 가장 중요한 요소는 지연이다.

HTTP GET 명령을 통한 응답은 짧은 버스티(Bursty) 파일 전송인 경우가 많으며, 이것이 끝날 때까지 슬로우 스타트 프로세스는 거의 시작되지 않는다. 따라서 세션 수립과 종료의 지연이 세션 지속 시간에 중요한 영향을 끼친다. 또한 일반적인 인기 웹 사이트 방문으로 get 명령보다 선행하는 10~25개의 DNS 쿼리/응답 교환을 갖는 경우가 많을 수 있다. 버퍼블로트로 인한 3개 요소 중 하나로 인해 속도가 저하된다면 분명 알아차리게 될 것이다.

통신업체는 이미 버퍼블로트에 관해 제공되고 있는 광범위한 연구 결과를 조사하는 것이 좋다. 그리고 무선과 모바일 AP) 등의 중요 네트워크 연결 환경에서 버프블로트를 시험해야 한다. 서비스 제공업체 또는 무선 AP 업체와의 논의를 위해서는 이런 시험의 데이터가 필요할 것이다. 


[출처 : http://www.itworld.co.kr/news/100874?page=0,2]