버퍼블로트

3. 응용 프로그램에 미치는 영향

대부분의 TCP 혼잡 제어 알고리즘은 연결 양쪽 끝 사이의 사용 가능한 대역폭을 결정하기 위해 패킷 손실 발생을 측정하는 데 의존한다. 이 알고리즘은 패킷이 떨어지기 시작할 때까지 데이터 전송 속도를 높인 다음 전송 속도를 늦춘다. 이상적으로는 링크의 평형 속도에 도달할 때까지 전송 속도를 계속 조정한다. 알고리즘이 적절한 전송 속도를 선택할 수 있도록 패킷 손실에 대한 피드백이 적시에 발생해야 한다. 채워진 큰 버퍼를 사용하면 패킷이 대상에 도착하지만 지연 시간이 더 길어진다. 패킷이 손실되지 않아 업링크가 포화된 후에도 TCP는 속도를 늦추지 않고 버퍼를 더 채운다. 새로 도착하는 패킷은 버퍼가 완전히 포화되었을 때만 손실된다. 이 경우 TCP는 연결 경로가 변경되었다고 결정하고 다시 새로운 작동 지점을 보다 공격적으로 검색할 수도 있다.^[8]

패킷은 전송되기 전에 네트워크 버퍼 내에 대기열에 추가된다. 문제가 있는 상황에서는 버퍼가 가득 찬 경우에만 패킷이 손실된다. 구형 라우터에서는 버퍼가 비교적 작아서 빠르게 채워졌고, 따라서 링크가 포화된 직후 패킷이 떨어지기 시작하여 TCP 프로토콜이 조정될 수 있었고 문제는 눈에 띄지 않게 되었다. 최신 라우터에서는 버퍼가 몇 초 분량의 버퍼링된 데이터를 보관할 수 있을 정도로 커졌다. TCP에게는 혼잡한 링크가 버퍼가 채워짐에 따라 정상적으로 작동하는 것처럼 보일 수 있다. TCP 알고리즘은 링크가 혼잡하다는 것을 알지 못하며 버퍼가 마침내 오버플로되어 패킷이 손실될 때까지 수정 조치를 시작하지 않는다.

단일 큐로 구현된 단순한 버퍼를 통과하는 모든 패킷은 유사한 지연을 경험하므로 채워진 버퍼를 통과하는 모든 연결의 대기 시간에 영향을 받는다. 또한 사용 가능한 채널 대역폭이 사용되지 않을 수 있는데, 이는 느린 대상에 대한 전송을 기다리는 데이터로 버퍼가 막혀 일부 빠른 대상에 신속하게 도달하지 못할 수 있기 때문이다. 이러한 영향은 VoIP 및 온라인 게임과 같이 대기 시간에 민감한 응용 프로그램에서 사용되는 UDP를 포함하여 다른 네트워크 프로토콜을 사용하는 응용 프로그램의 상호 작용을 손상시킨다.^[9]

지속적으로 낮은 지연 시간 또는 지터 없는 전송을 필요로 하는 모든 유형의 서비스는 버퍼블로트의 영향을 받을 수 있다. 이러한 서비스에는 VoIP와 같은 디지털 음성 통화, 온라인 게임, 화상 채팅, 라디오 스트리밍, 주문형 비디오, 원격 로그인과 같은 기타 대화형 애플리케이션이 포함된다.

버퍼블로트 현상이 나타나고 네트워크에 부하가 걸리면, 일반적인 웹 페이지 로드조차 완료하는 데 수 초가 걸릴 수 있으며, 간단한 DNS 쿼리가 시간 초과로 인해 실패할 수 있다.^[10] 실제로 모든 TCP 연결이 시간 초과로 인해 끊어질 수 있으며, UDP 패킷이 폐기될 수 있다. TCP 다운로드 스트림의 지속은 업로드 스트림의 승인(ACK) 패킷에 의존하기 때문에, 업로드의 버퍼블로트 문제는 클라이언트 ACK 패킷이 인터넷 서버에 적시에 도달하지 못하여 관련 없는 다른 다운로드 애플리케이션의 실패를 초래할 수 있다.

4. 탐지

확장된 버퍼는 해당 버퍼가 실제로 사용될 때, 즉 버퍼링하는 링크가 병목 현상을 일으킬 때만 영향을 미친다. 병목 지점의 버퍼 크기는 운영 체제에서 제공하는 ping 유틸리티를 사용하여 측정할 수 있다. 먼저 다른 호스트에 지속적으로 ping을 보내면서, 몇 초 동안 파일을 다운로드하고 중지하는 과정을 반복한다. TCP 혼잡 회피 알고리즘은 설계상 경로의 병목 지점을 빠르게 채우게 된다. 만약 다운로드(및 업로드) 중에 ping에서 보고하는 왕복 시간이 눈에 띄게 증가한다면, 이는 현재 병목 지점의 버퍼가 과도하게 크다는 것을 보여준다. 왕복 시간의 최대 증가는 해당 버퍼의 대략적인 크기(밀리초)를 나타낸다.

간단한 ping 대신 고급 traceroute 도구(예: MTR)를 사용하면, 병목 현상에 확장된 버퍼가 존재한다는 사실을 증명할 뿐만 아니라 네트워크 상에서 그 정확한 위치까지 파악할 수 있다. Traceroute는 패킷이 네트워크를 통과하는 경로를 추적하고 각 중간 지점(홉)에서의 전송 지연을 측정하여 이를 수행한다. 경로 정보는 각 연속된 호스트(원격 노드)에서 수신된 패킷의 왕복 시간으로 기록된다.^[7]

몇 가지 온라인 도구를 통해서도 버퍼블로트를 확인할 수 있다.

• DSL Reports 속도 테스트^[11]는 버퍼블로트 점수를 제공하는 사용하기 쉬운 테스트이다.
• ICSI Netalyzr^[12]는 네트워크의 버퍼블로트 존재 여부 및 다른 일반적인 설정 문제를 확인하는 데 사용되던 온라인 도구였으나,^[13] 2019년 3월에 서비스가 종료되었다.
• bufferbloat.net 웹사이트에서는 연결 속도를 늦추는 과도한 버퍼링이 있는지 확인하기 위한 도구와 절차를 제공한다.^[14][15]

5. 해결책 및 완화

버퍼블로트 문제를 해결하거나 완화하기 위한 여러 기술적 접근 방식이 존재한다. 이들은 크게 네트워크 자체를 개선하는 방법과 통신의 양 끝단, 즉 최종 지점에서 문제를 해결하는 방법으로 나눌 수 있다. 이 두 가지 접근 방식은 서로 보완적으로 작용하는 경우가 많다. 이 문제는 때때로 빠르고 느린 네트워크 경로가 혼합된 환경에서 발생하기도 한다.

네트워크를 대상으로 하는 해결책은 주로 큐 관리 알고리즘을 개선하는 형태로 나타난다. 이는 IETF의 AQM(Active Queue Management) 워킹 그룹^[16]에서 중점적으로 다루는 분야로, CoDel^[17], PIE^[17], FQ-CoDel^[18]과 같은 알고리즘 개발, DOCSIS 표준 개정^[19][10]을 통한 케이블 모뎀의 버퍼 제어 개선, 리눅스 운영 체제의 Wi-Fi 하위 시스템에 큐 관리 통합^[20] 등이 대표적인 예시다.

최종 지점을 대상으로 하는 해결책으로는 TCP의 혼잡 제어 방식을 개선한 BBR 알고리즘, 비트토렌트 클라이언트 등에서 사용되는 마이크로 전송 프로토콜, 그리고 HTTP/2처럼 더 적은 연결을 사용하는 기술^[10] 등이 있다. OS^[10]나 네트워크 하드웨어의 버퍼 크기를 직접 줄이는 방법도 있으나, 이는 종종 사용자가 직접 구성하기 어렵고 최적의 버퍼 크기가 회선 속도나 연결 대상에 따라 달라질 수 있다는 한계가 있다.

또한, DiffServ 기술을 활용하여 트래픽 종류에 따라 우선순위를 부여함으로써 문제를 완화할 수도 있다. 이는 지연 시간에 민감한 VoIP, 화상 회의, 온라인 게임 등의 트래픽 전송을 우선시하고, 혼잡 및 버퍼블로트의 영향을 우선 순위가 낮은 트래픽으로 제한하는 방식이다.^[21]

5. 1. 네트워크 기반 솔루션

• IP 큐 길이 제한 설정 (TCP 튜닝 참조)
• AQM 알고리즘 사용: 대표적으로 CoDel^[17]과 PIE^[17]가 있다.
• 하이브리드 AQM 및 패킷 스케줄링 알고리즘 적용: FQ-CoDel^[18] 등이 이에 해당한다.
• DOCSIS 표준^[19] 개정: 케이블 모뎀에서 더 스마트한 버퍼 제어를 가능하게 한다.^[10]
• 리눅스 운영 체제의 Wi-Fi 하위 시스템에 큐 관리 통합: 무선 액세스 포인트에서 널리 사용되는 리눅스에 큐 관리 알고리즘(FQ-CoDel)을 통합하였다.^[20]

5. 2. 최종 지점 기반 솔루션

• TCP BBR 혼잡 제어 알고리즘: TCP를 위한 혼잡 제어 방식이다.
• 마이크로 전송 프로토콜: 많은 비트토렌트 클라이언트에서 사용된다.
• HTTP/2: HTTP 파이프라이닝이나 일반 HTTP 프로토콜 대신 더 적은 연결을 사용하는 기술이다.^[10]
• OS^[10] 및 네트워크 하드웨어의 버퍼 크기를 줄이는 방법도 있다. 하지만 이는 종종 사용자가 직접 설정하기 어렵고, 최적의 버퍼 크기는 회선 속도에 따라 달라지며, 연결 대상에 따라서도 달라질 수 있다.

5. 3. DiffServ를 활용한 완화

6. 최적 버퍼 크기

과거 네트워크 장비 제조업체들은 장치를 통과하는 트래픽 스트림에 대해 최소 250ms의 버퍼링을 수용할 만큼 충분히 큰 버퍼를 제공하는 것이 일반적이었다. 예를 들어, 라우터의 기가비트 이더넷 인터페이스에는 비교적 큰 32 MB 버퍼가 필요하다고 여겨졌다.^[4] 그러나 이렇게 과도하게 큰 버퍼는 TCP 혼잡 제어 알고리즘의 정상적인 작동을 방해할 수 있다. 버퍼가 가득 차면 혼잡 제어가 재설정되고, TCP 연결이 다시 속도를 높여 버퍼를 채우기 전에 버퍼가 비워지는 데 시간이 걸리게 된다.^[5] 결과적으로 버퍼블로트는 높은 가변 지연 시간과 네트워크 병목 현상 같은 문제를 일으킨다. 특히 한 TCP 스트림의 패킷으로 버퍼가 가득 차면 다른 모든 흐름의 패킷이 삭제될 수 있다.^[6]

지나치게 큰 버퍼는 해당 버퍼가 위치한 링크가 병목 현상을 겪을 때만 문제가 된다. 병목 지점의 버퍼 크기는 운영 체제에서 제공하는 ping 유틸리티로 측정할 수 있다. 다른 호스트에 지속적으로 ping을 보내면서 몇 초간 다운로드를 시작하고 중지하는 것을 반복한다. TCP 혼잡 회피 알고리즘은 경로상의 병목 구간을 빠르게 채우게 되는데, 이때 다운로드(및 업로드) 속도와 ping으로 확인되는 왕복 시간(RTT) 사이에 직접적이고 큰 증가가 관찰된다면, 해당 방향의 병목 구간 버퍼가 지나치게 크다는 것을 의미한다. 왕복 시간의 증가는 병목 구간의 버퍼 때문에 발생하므로, 증가한 시간의 최댓값이 대략적인 버퍼 크기(밀리초 단위)를 나타낸다.

단순한 ping 대신 MTR과 같은 고급 traceroute 도구를 사용하면, 병목 현상을 일으키는 과도한 버퍼의 존재를 확인할 뿐만 아니라 네트워크상의 정확한 위치까지 파악할 수 있다. Traceroute는 패킷이 네트워크를 통해 이동하는 경로를 보여주고 각 구간(홉)에서의 전송 지연 시간을 측정하여 이를 가능하게 한다.^[7]

TCP 연결들이 가장 긴 지연 시간 속에서도 대역폭을 공정하게 나누어 가지려면, 버퍼 크기는 최소한 대역폭-지연 곱을 동시에 활성화된 스트림 수의 제곱근으로 나눈 값 이상이어야 한다.^[22][4] 일반적으로는 회선 속도로 전송되는 데이터의 50ms 분량을 버퍼 크기의 기준으로 삼는 경험 법칙이 있다.^[23] 하지만 일부 널리 사용되는 소비자용 스위치는 1ms 정도의 작은 버퍼만 지원하기도 한다.^[24] 이런 경우, 로컬 네트워크 내에서 다른 연결과의 경쟁이 발생하면 지연 시간이 더 긴 연결에서 추가적인 대역폭 손실이 발생할 수 있다.

참조

_[1] 웹사이트 On Packet Switches with Infinite Storage https://www.ietf.org[...] 1985-12-31
_[2] 웹사이트 Understanding Bufferbloat and the Network Buffer Arms Race https://arstechnica.[...] 2011-01-07
_[3] 논문 Bufferbloat: Dark Buffers in the Internet: Networks without effective AQM may again be vulnerable to congestion collapse
_[4] 웹사이트 Sizing Router Buffers http://conferences.s[...] ACM 2013-10-15
_[5] 웹사이트 Controlling Queue Delay http://queue.acm.org[...] ACM Publishing 2012-05-06
_[6] 간행물 Bufferbloat: Dark Buffers in the Internet http://www.computer.[...] IEEE 2011-05
_[7] 웹사이트 traceroute(8) – Linux man page http://linux.die.net[...] 2013-09-27
_[8] 논문 Congestion avoidance and control http://www.cord.edu/[...]
_[9] 웹사이트 Technical Introduction to Bufferbloat http://www.bufferblo[...] 2013-09-27
_[10] 논문 Bufferbloat: Dark Buffers in the Internet ACM 2012-01
_[11] 웹사이트 Speed test - how fast is your internet? http://dslreports.co[...] 2017-10-26
_[12] 웹사이트 ICSI Netalyzr http://netalyzr.icsi[...] 2015-01-30
_[13] 웹사이트 Understanding your Netalyzr results https://www.newscien[...] 2017-10-26
_[14] 웹사이트 Tests for Bufferbloat https://www.bufferbl[...] 2017-10-26
_[15] 웹사이트 Introduction to Bufferbloat https://www.bufferbl[...] 2023-05-08
_[16] 웹사이트 IETF AQM working group https://datatracker.[...] 2017-10-26
_[17] 간행물 2013 IEEE 14th International Conference on High Performance Switching and Routing (HPSR) IEEE 2013
_[18] 간행물 The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm
_[19] 웹사이트 DOCSIS "Upstream Buffer Control" feature http://www.cablelabs[...] CableLabs 2012-08-09
_[20] 간행물 Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi https://www.usenix.o[...] USENIX - The Advanced Computing Systems Association 2017-09-28
_[21] 웹사이트 Bufferbloat » ADMIN Magazine http://www.admin-mag[...] 2020-06-11
_[22] 웹사이트 Sizing the buffer https://blog.apnic.n[...] 2022-10-16
_[23] 웹사이트 Router/Switch Buffer Size Issues https://fasterdata.e[...] 2022-10-16
_[24] 웹사이트 BCM53115 https://www.broadcom[...] 2022-10-16
_[25] 웹인용 On Packet Switches With Infinite Storage http://tools.ietf.or[...] 1985-12-31
_[26] 웹인용 Understanding Bufferbloat and the Network Buffer Arms Race https://arstechnica.[...] 아르스 테크니카 2011-01-07