완충류

Bufferbloat

버퍼블로트는 패킷의 과도한 버퍼링으로 인한 패킷 교환 네트워크의 지연 및 지터의 원인이 된다. 버퍼블로는 전체 네트워크 처리량을 감소시킬 뿐만 아니라 패킷 지연 변동(지터라고도 함)을 유발할 수 있다. 라우터나 스위치가 과도하게 큰 버퍼를 사용하도록 구성되었을 때, 초고속 네트워크조차도 VoIP, 오디오 스트리밍, 온라인 게임, 그리고 심지어 일반적인 웹 브라우징과 같은 많은 인터랙티브 애플리케이션에 실제로 사용할 수 없게 될 수 있다.

일부 통신 장비 제조업체는 불필요하게 큰 버퍼들을 그들의 네트워크 제품 중 일부에 설계했다. 이러한 장비에서 버퍼블로는 네트워크 링크가 정체될 때 발생하며, 패킷이 이러한 오버사이즈 버퍼에서 장기간 대기하게 된다. 최초 입력 대기열 시스템에서 지나치게 큰 버퍼는 대기열이 길어지고 대기 시간이 길어지며 네트워크 처리량이 향상되지 않는다. 또한 다른 패킷의 정시 전달을 방해하는 특정 저속 연결에 의해서도 유도될 수 있다.

완충현상은 1985년 초에 설명되었다.[1] 2009년부터 더욱 광범위한 관심을 받았다.[2]

버퍼링

참고 항목: CoDel § 이론적 기초

네트워크 장비 제조업체에 대해 확립된 경험칙은 장치를 통과하는 트래픽 흐름에 대해 최소 250ms의 버퍼링을 수용할 수 있을 만큼 충분히 큰 버퍼를 제공하는 것이었다. 예를 들어, 라우터의 기가비트 이더넷 인터페이스는 상대적으로 큰 32MB의 버퍼가 필요할 것이다.[3] 이러한 버퍼 사이징은 TCP 정체 제어 알고리즘의 실패를 초래할 수 있다. 그런 다음 버퍼가 배수되는 데 시간이 좀 걸리고 정체 제어가 재설정되고 TCP 연결이 다시 속도를 높여 버퍼를 채운다.[4] 따라서 버퍼블로는 버퍼에 하나의 TCP 스트림의 패킷이 가득 차서 다른 패킷이 삭제될 때 다른 모든 흐름의 네트워크 병목현상과 같은 문제를 야기한다.[5]

부풀어 오른 버퍼는 이 버퍼가 실제로 사용될 때만 효과가 있다. 즉, 오버사이즈 버퍼는 링크 버퍼가 병목현상이 될 때에만 피해를 주는 효과가 있다. 병목현상을 지원하는 버퍼의 크기는 대부분의 운영 체제에서 제공하는 ping 유틸리티를 사용하여 측정할 수 있다. 먼저, 다른 호스트는 계속 ping되어야 하고, 그 다음, 그것으로부터 몇 초 동안 다운로드를 시작하고 몇 번 중지해야 한다. 설계에 의해, TCP 정체 방지 알고리즘은 경로의 병목 현상을 빠르게 메울 것이다. 다운로드(각각 업로드)가 ping에 의해 보고된 왕복 시간의 직접적이고 중요한 증가와 상관관계가 있다면, 다운로드(각각 업로드) 방향의 현재 병목현상의 완충장치가 비대해 있음을 증명한다. 원형 트립 시간의 증가는 병목현상의 완충제에 의해 발생하기 때문에, 최대 증가는 밀리초 단위의 대략적인 크기를 추정한다.[citation needed]

앞의 예에서 단순 핑(예를 들어 MTR) 대신 고급 추적 도구를 사용하면 병목현상에 비대해진 버퍼의 존재를 증명할 뿐만 아니라 네트워크에서의 위치를 정확히 파악할 수 있다. Traceroute는 경로(경로)를 표시하고 네트워크를 통한 패킷의 전송 지연을 측정함으로써 이를 달성한다. 경로 기록은 경로(경로)의 각 연속 호스트(원격 노드)로부터 수신한 패킷의 왕복 시간으로 기록된다.[6]

메커니즘

참고 항목: TCP 튜닝 § 창 크기 및 느린 시작

대부분의 TCP 정체 제어 알고리즘은 연결의 두 끝 사이에 사용 가능한 대역폭을 결정하기 위해 패킷 드롭 발생의 측정에 의존한다. 알고리즘은 패킷이 떨어지기 시작할 때까지 데이터 전송 속도를 높인 다음 전송 속도를 늦춘다. 이상적으로는 링크의 평형 속도에 도달할 때까지 계속 전송 속도를 조절한다. 알고리즘이 적절한 전송 속도를 선택할 수 있도록 패킷 감소에 대한 피드백은 적시에 발생해야 한다. 채워진 큰 버퍼로 패킷은 목적지에 도착하지만 대기 시간이 더 길어질 것이다. 패킷이 삭제되지 않았으므로 업링크가 포화되면 TCP 속도가 느려지지 않아 버퍼가 더 채워진다. 새로 도착한 패킷은 버퍼가 완전히 포화상태일 때만 삭제된다. 일단 이런 일이 일어나면 TCP는 연결 경로가 바뀌었다고까지 판단하고, 다시 새로운 운영 지점을 더 적극적으로 검색에 들어갈 수 있다.[7]

패킷은 전송되기 전에 네트워크 버퍼 내에 대기한다. 문제가 있는 상황에서는 버퍼가 꽉 찬 경우에만 패킷이 삭제된다. 오래된 라우터에서는 버퍼들이 상당히 작아서 빠르게 채워졌고 따라서 패킷들이 링크가 포화상태에 이른 직후부터 떨어지기 시작했기 때문에 TCP 프로토콜이 조정될 수 있었고 문제가 명백해지지 않았다. 새로운 라우터에서는 버퍼들이 수 초의 버퍼링된 데이터를 저장할 수 있을 만큼 충분히 커지게 되었다. TCP에는, 버퍼가 채워질 때 정체 링크가 정상적으로 작동하는 것처럼 보일 수 있다. TCP 알고리즘은 링크가 혼잡하다는 것을 모르고 버퍼가 마침내 오버플로되고 패킷이 손실될 때까지 시정 조치를 취하지 않는다.

단일 대기열로 구현된 단순 버퍼를 통과하는 모든 패킷은 유사한 지연을 경험하므로 채워진 버퍼를 통과하는 모든 연결의 지연 시간이 영향을 받게 된다. 사용 가능한 채널 대역폭도 사용되지 않을 수 있는데, 이는 느린 수신처로 전송 대기 중인 데이터로 인해 버퍼로 인해 일부 빠른 수신처에 즉시 도달하지 못할 수 있기 때문이다. 이러한 영향은 VoIP와 온라인 게임과 같은 지연 시간에 민감한 애플리케이션에 사용되는 UDP를 포함하여 다른 네트워크 프로토콜을 사용하는 애플리케이션의 상호작용을 손상시킨다.[8][self-published source]

애플리케이션에 미치는 영향

대역폭 요구 사항과 관계없이 지연 시간이 짧거나 지터가 없는 전송이 지속적으로 필요한 모든 유형의 서비스는 버퍼블로의 영향을 받을 수 있다. 음성 통화, 온라인 게임, 비디오 채팅 및 인스턴트 메시징, 라디오 스트리밍, 주문형 비디오, 원격 로그인 등의 기타 대화형 응용 프로그램이 그 예다.

버퍼블로트 현상이 존재하고 네트워크가 로딩 중일 때는 정상적인 웹 페이지 로딩이라도 완료하는 데 수 초가 걸리거나, 타임아웃으로 인해 간단한 DNS 쿼리가 실패할 수 있다.[9] 실제로 어떤 TCP 연결도 시간이 초과되고 연결이 끊길 수 있으며 UDP 패킷은 손실될 수 있다. TCP 다운로드 스트림의 지속은 업로드 스트림의 ACK 패킷에 의존하므로, 클라이언트 ACK 패킷이 인터넷 서버에 적시에 도달하지 못하기 때문에 업로드의 버퍼블로트 문제는 다른 관련 없는 다운로드 응용 프로그램의 실패를 야기할 수 있다. 예를 들어 인터넷 라디오 청취와 같은 다른 홈 네트워크 사용자를 방해하지 않기 위해 업로드 OneDrive 동기화의 전송 속도를 제한할 수 있다.

탐지

DSL Reports Speed test는[10] 사용하기 쉬운 시험으로 완충재에 대한 점수가 포함되어 있다. ICSI Netalyzr은[11] 다른 많은 일반적인 구성 문제를 확인하는 것과 함께 네트워크의 완충성 존재 여부를 확인하는 데 사용할 수 있는 또 다른 온라인 도구였다.[12] 이 서비스는 2019년 3월 폐쇄됐다. bufferbloat.net 웹 사이트에는 연결에 속도가 느려지는 버퍼링이 과도한지 여부를 결정하기 위한 도구와 절차가 나열되어 있다.[13][self-published source]

솔루션 및 완화

크게 두 가지 범주로 분류할 수 있는 몇 가지 기술 솔루션이 존재한다.: 네트워크를 대상으로 하는 솔루션과 엔드포인트를 대상으로 하는 솔루션이다. 두 가지 유형의 해결책은 종종 보완적이다. 문제는 때때로 빠르고 느린 네트워크 경로의 조합으로 발생한다.

네트워크 솔루션은 일반적으로 대기열 관리 알고리즘의 형태를 취한다. 이러한 유형의 솔루션은 IETF AQM 작업 그룹의 초점이 되어 왔다.[14] 주목할 만한 예는 다음과 같다.

엔드포인트를 대상으로 하는 솔루션의 주목할 만한 예는 다음과 같다.

OS와[9] 네트워크 하드웨어의 버퍼 크기를 줄임으로써도 문제를 완화할 수 있지만, 이는 종종 구성할 수 없고 최적의 버퍼 크기는 목적지마다 다를 수 있는 회선 속도에 따라 달라진다.

DiffServ를 활용(그리고 다중 우선순위 기반 대기열을 채택)하면 대기 시간이 짧은 트래픽(VoIP, 화상 회의, 게임 등)의 전송 우선 순위를 결정하는데 도움이 되며, 혼잡과 완충재를 사전 차단된 트래픽으로 처리할 수 있다. [19]

참고 항목

참조

  1. ^ "On Packet Switches with Infinite Storage". December 31, 1985.
  2. ^ van Beijnum, Iljitsch (January 7, 2011). "Understanding Bufferbloat and the Network Buffer Arms Race". Ars Technica. Retrieved November 12, 2011.
  3. ^ Guido Appenzeller; Isaac Keslassy; Nick McKeown (2004). "Sizing Router Buffers" (PDF). ACM SIGCOMM. ACM. Retrieved October 15, 2013.
  4. ^ Nichols, Kathleen; Jacobson, Van (May 6, 2012). "Controlling Queue Delay". ACM Queue. ACM Publishing. Retrieved September 27, 2013.
  5. ^ Gettys, Jim (May–June 2011). "Bufferbloat: Dark Buffers in the Internet". IEEE Internet Computing. 15 (3). IEEE: 95–96. doi:10.1109/MIC.2011.56. Archived from the original on October 12, 2012. Retrieved February 20, 2012. {{cite journal}}: Cite 저널은 필요로 한다. journal= (도움말)
  6. ^ "traceroute(8) – Linux man page". die.net. Retrieved September 27, 2013.
  7. ^ Jacobson, Van; Karels, MJ (1988). "Congestion avoidance and control" (PDF). ACM SIGCOMM Computer Communication Review. 18 (4): 314–329. doi:10.1145/52325.52356. Archived from the original (PDF) on June 22, 2004.
  8. ^ "Technical Introduction to Bufferbloat". Bufferbloat.net. Retrieved September 27, 2013.
  9. ^ a b c d Gettys, Jim; Nichols, Kathleen (January 2012). "Bufferbloat: Dark Buffers in the Internet". Communications of the ACM. 55 (1). ACM: 57–65. doi:10.1145/2063176.2063196. Retrieved February 28, 2012. {{cite journal}}: Cite 저널은 필요로 한다. journal= (도움말)
  10. ^ "Speed test - how fast is your internet?". dslreports.com. Retrieved October 26, 2017.
  11. ^ "ICSI Netalyzr". berkeley.edu. Archived from the original on April 7, 2019. Retrieved January 30, 2015.
  12. ^ "Understanding your Netalyzr results". Retrieved October 26, 2017.
  13. ^ "Tests for Bufferbloat". bufferbloat.net. Retrieved October 26, 2017.
  14. ^ "IETF AQM working group". ietf.org. Retrieved October 26, 2017.
  15. ^ Pan, Rong; Natarajan, Preethi; Piglione, Chiara; Prabhu, Mythili; Subramanian, Vijay; Baker, Fred; VerSteeg, Bill (2013). PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem. 2013 IEEE 14th International Conference on High Performance Switching and Routing (HPSR). IEEE. doi:10.1109/HPSR.2013.6602305.
  16. ^ Høiland-Jørgensen, Toke; McKenney, Paul; Taht, Dave; Gettys, Jim; Dumazet, Eric. The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm. doi:10.17487/RFC8290. RFC 8290.
  17. ^ "DOCSIS "Upstream Buffer Control" feature". CableLabs. pp. 554–556. Retrieved August 9, 2012.
  18. ^ Høiland-Jørgensen, 타카, Kazior, Michał, Täht, 데이브, Hurtig,;Brunstrom, 안나(2017년).그 변칙 마무리:WiFi에 저 대기와 방송 시간 공정 완수. 사이버맨이야. 2017년까지 유즈 닉스회 기술 회의(유즈 닉스 ATC17).유즈 닉스-고급 컴퓨팅 시스템 협회를 대신하여 서명함. 139–151.아이 에스비엔 978-1-931971-38-6.Retrieved 9월 28일 2017년. 소스 코드이다.
  19. ^ Hein, Mathias. "Bufferbloat » ADMIN Magazine". ADMIN Magazine. Retrieved June 11, 2020.

외부 링크