제퍼넷 로고

Bufferbloat, 인터넷 및 해결 방법

시간

수년간 인터넷 서비스 제공업체를 괴롭히는 무서운 질병이 있습니다. 좋습니다. 아마도 여러 질병이 있을 것입니다. 하지만 오늘 우리는 버퍼블로트. 그것이 무엇인지, 그것을 테스트하는 방법, 마지막으로 그것에 대해 할 수 있는 일. 아, 그리고 이 문제를 해결하는 모든 사람들에게 큰 박수를 보냅니다. Vint Cerf, Dave Taht, Jim Gettys 등과 같은 많은 프로그래머와 엔지니어는 우리의 공동 이익을 위해 이 너트를 깨뜨렸습니다.

컴퓨터가 인터넷의 다른 호스트로 TCP/IP 패킷을 보낼 때 해당 패킷은 컴퓨터, 네트워크 카드, 스위치, 라우터, ISP 모뎀, 몇 개의 ISP 라우터를 거쳐 마지막으로 라우팅됩니다. 데이터 센터로 가는 길에 일부 매우 큰 라우터를 통해. 또는 장치의 복잡한 체인을 역순으로 거쳐 다른 데스크탑에 도달할 수도 있습니다. 정말 모든 것이 전혀 작동하지 않는다는 것이 놀랍습니다. 이러한 각 홉은 문제가 발생하는 또 다른 장소를 나타냅니다. 그리고 실제로 문제가 발생하면 즉시 알 수 있습니다. 페이지가 갑자기 로드되지 않습니다. VoIP 통화가 끊기거나 끊깁니다. 끊어진 연결을 찾아 수정하는 것이 그리 간단하지 않은 경우에도 연결이 끊어진 부분을 찾는 것은 매우 쉽습니다.

그것은 명백한 문제입니다. 명확하지 않은 문제가 있는 경우에는 어떻게 합니까? 사이트가 로드되지만 예전보다 약간 느립니다. 명령줄을 사용하는 방법을 알고 있으므로 ping 테스트. 허, Google.com으로 15.0ms 떨어져 있습니다. XNUMX개의 패킷에 대해 실행하고 기본적으로 패킷 손실이 없도록 합니다. 하지만 뭔가 잘못되었습니다. 다른 사람이 영화를 스트리밍하거나 시스템이 백업을 원격 서버로 푸시하면 모든 것이 무너집니다. 그것은 버퍼블로트이며, 이를 감지하기 위해 간단한 테스트를 수행하는 것은 실제로 매우 쉽습니다. 속도 테스트를 실행하고 연결이 포화 상태일 때 핑 테스트를 실행하십시오. 로드 시 대기 시간이 정상을 넘으면 버퍼 블로트가 발생할 수 있습니다. 현재 버퍼블로트 테스트를 제공하는 대규모 속도 테스트 사이트가 몇 개 있습니다. 그러나 먼저, 약간의 역사.

붕괴의 역사

1980년대의 인터넷은 매우 다른 곳이었습니다. 도메인 이름 시스템 교체 hosts.txt 1982년에 IP 확인에 대한 호스트 이름이 수행된 방식과 같습니다. 1년 1983월 1984일 ARPANET은 인터넷의 탄생일인 TCP/IP를 채택했습니다. 1986년에는 양조에 문제가 있었고 XNUMX년에는 인터넷이 다음과 같은 형태의 심장마비를 겪었습니다. 혼잡 붕괴.

그 당시 최첨단 로컬 네트워크는 초당 10메가비트로 실행되었지만 사이트 간 링크는 기껏해야 초당 56킬로바이트를 전송했습니다. 1986년 후반, 로렌스 버클리 연구소와 버클리 캘리포니아 대학교 사이의 400야드 링크와 같이 링크가 갑자기 급격히 느려졌습니다. 56Kbps 대신 이 링크가 갑자기 초당 유효 40비트로 전송되었습니다. 문제는 혼잡이었다. 너무 많은 자동차가 동일한 고속도로에 있을 때 발생하는 것과 매우 유사한 모델입니다.

BSD 4.3 릴리스에는 몇 가지 흥미로운 작업을 수행하는 TCP 구현이 있습니다. 첫째, 즉시 최대 유선 속도로 패킷을 보내기 시작합니다. 그리고 두 번째로, 패킷이 도중에 떨어졌다면 가능한 한 빨리 그것을 다시 보낼 것입니다. 네트워크 속도가 균일한 근거리 통신망에서는 잘 작동합니다. 초기 인터넷, 특히 이 특정 버클리 링크에서 10Mb/s LAN 연결은 32kbps 또는 56kbps로 하향 조정되었습니다.

이 불일치를 처리하기 위해 링크의 양쪽에 있는 게이트웨이에는 약 30패킷에 해당하는 작은 버퍼가 있습니다. 혼잡 시나리오에서 30개 이상의 패킷이 게이트웨이에서 백업되고 추가 패킷은 방금 삭제되었습니다. 패킷이 삭제되거나 정체로 인해 왕복 시간이 제한 시간 임계값을 초과하면 발신자는 즉시 재전송되어 더 많은 트래픽을 생성합니다. 너무 좁은 연결을 통해 너무 많은 데이터를 보내려는 여러 호스트는 트래픽의 피드백 루프인 혼잡 붕괴를 초래합니다. 초기 인터넷은 의도치 않게 스스로를 DDoS했습니다.

[포함 된 콘텐츠]

해결책은 BSD의 TCP 구현에 추가된 일련의 알고리즘, 이제 표준의 일부로 채택되었습니다. 간단히 말해서 최대한 빨리 전송하려면 트래픽을 지능적으로 줄여야 했습니다. 도입된 첫 번째 기술은 느린 시작이었습니다. 속도 테스트를 실행할 때 이것이 여전히 사용되는 것을 볼 수 있으며 연결은 매우 느린 속도로 시작되었다가 빠르게 증가합니다. 특히, 전송 시작 ​​시 하나의 패킷만 전송됩니다. 수신된 각 패킷에 대해 승인 패킷(ack)이 반환됩니다. ACK를 받으면 두 개의 패킷이 유선으로 더 전송됩니다. 그 결과 연결 체인에서 가장 느린 링크의 최대 속도가 두 배까지 빠르게 증가합니다. 한 번에 "아웃"되는 패킷 수를 혼잡 창 크기라고 합니다. 따라서 문제를 보는 또 다른 방법은 왕복 성공 시 혼잡 기간이 하나씩 증가한다는 것입니다.

느린 시작이 작업을 완료하고 첫 번째 패킷이 삭제되거나 시간 초과되면 TCP 흐름은 정체 방지 알고리즘을 사용하는 것으로 전환됩니다. 이것은 안정적인 데이터 속도를 유지하는 데 중점을 둡니다. 패킷이 드롭되면 창은 반으로 줄어들고 전체 창의 패킷이 수신될 때마다 창은 XNUMX씩 증가합니다. 결과는 전체 데이터 경로의 최대 처리량을 중심으로 지속적으로 튀는 톱니 그래프입니다. 이것은 다소 지나치게 단순화되었으며 알고리즘은 시간이 지남에 따라 더 많이 개발되었지만 요점은 이 확장을 TCP/IP로 롤아웃하면 인터넷이 절약된다는 것입니다. 어떤 경우에는 전체 네트워크를 하드 재부팅하는 방식으로 메일을 통해 테이프에 업데이트가 전송되었습니다.

[포함 된 콘텐츠]

2009 년으로 빨리 감기

인터넷은 1986년 이래로 약간 발전했습니다. 달라진 것 중 하나는 하드웨어 가격은 내리고 기능은 비약적으로 올랐다는 것입니다. 1986년의 게이트웨이는 버퍼를 킬로바이트 단위로 측정하고 100바이트 미만입니다. 오늘날 문제가 있을 때 메가바이트와 기가바이트의 메모리를 사용하는 것은 매우 간단하며 라우터 버퍼도 예외는 아닙니다. 50kB 버퍼 크기로 작성된 알고리즘이 최신 장치에서 50MB 버퍼와 만나면 어떻게 됩니까? 예상대로 일이 잘못됩니다.

큰 FIFO(선입선출) 버퍼가 병목 상태에 있는 경우 해당 버퍼는 패킷이 삭제되기 전에 완전히 채워야 합니다. TCP 흐름은 사용 가능한 대역폭의 최대 2배까지 느리게 시작하고 패킷 삭제를 매우 빠르게 시작하며 대역폭 사용을 절반으로 줄이도록 고안되었습니다. Bufferbloat는 해당 흐름이 버퍼가 채워지기를 기다리면서 사용 가능한 속도로 두 배의 전송을 시도하는 데 너무 많은 시간을 소비할 때 발생합니다. 연결이 안정적인 정체 방지 모드로 전환되면 해당 알고리즘은 손실된 패킷 또는 시간 초과에 따라 달라지며, 여기서 시간 초과 임계값은 관찰된 왕복 시간에서 파생됩니다. 결과적으로 모든 연결의 경우 경로에서 버퍼링된 패킷 수에 따라 왕복 대기 시간이 증가합니다. 그리고 부하가 걸리는 연결의 경우 TCP 혼잡 방지 기술은 혼잡 창을 줄이기 전에 해당 버퍼를 채우도록 설계되었습니다.

얼마나 나쁠 수 있습니까? 로컬 네트워크에서 왕복 시간은 마이크로초 단위로 측정됩니다. 인터넷 호스트에 대한 시간은 밀리초 단위로 측정해야 합니다. Bufferbloat는 이를 몇 초, 최악의 경우 수십 초로 밀어 넣습니다. 이것이 실제로 문제를 일으키는 곳은 트래픽이 애플리케이션 계층에서 시간 초과되는 경우입니다. Bufferbloat는 모든 트래픽을 지연시켜 DNS 시간 초과를 유발하고 VoIP 통화를 엉망으로 만들고 인터넷을 고통스러운 경험으로 만들 수 있습니다.

해결책은 스마트 대기열 관리. 1986년부터 이 개념에 대해 많은 작업이 이루어졌습니다. 공정한 대기열은 중간 버퍼를 스마트하게 만들고 개별 트래픽 흐름을 개별 대기열로 분할하는 최초의 솔루션 중 하나였습니다. 링크가 혼잡할 때 각 대기열은 한 번에 단일 패킷을 해제하므로 Bittorrent를 통해 ISO를 다운로드해도 VoIP 트래픽이 완전히 제거되지는 않습니다. 많은 반복 후에 CAKE 알고리즘이 개발되어 널리 배포되었습니다. 이러한 모든 솔루션은 본질적으로 대기 시간을 크게 줄이기 위해 약간의 최대 처리량을 절충합니다.

당신은 Bufferbloat에 능숙합니까?

버퍼블로트가 해결된 문제이며 네트워크에 문제가 없을 것이라는 점을 말씀드리고 싶습니다. 불행히도 그렇지 않습니다. 문제가 있는지 여부에 대한 대략적인 처리를 위해 속도 테스트를 사용하십시오. dsl 보고서, fast.comspeedtest.net. 이 세 가지 각각과 아마도 다른 것들은 부하 측정 시 일종의 대기 시간을 제공합니다. 거기 파형에 의해 호스팅되는 Bufferbloat 특정 테스트, 그리고 브라우저에서 실행하기에 가장 좋은 것 같습니다. 이상적인 네트워크는 혼잡이 있을 때 여전히 낮은 대기 시간을 보여줍니다. 테스트 중에 대기 시간이 현저히 높아지면 버퍼 블로트가 발생할 수 있습니다.

우리의 멍청이를 위해 명령줄 도구가 있습니다. flent, 심층 버퍼블로트 테스트를 수행합니다. 명령어를 사용했는데, flent rrul -p all_scaled -H flent-fremont.bufferbloat.net 이 차트를 생성하고 로드 상태에서 100ms 이상으로 빠르게 확장되는 대기 시간을 볼 수 있습니다. 이것은 부하 테스트에서 실시간 응답을 실행하고 있으며 내 네트워크에 약간의 버퍼 블로트 문제가 있음을 분명히 나타냅니다. 문제가 확인되었습니다. 어떻게 해야 합니까?

당신은 당신의 케이크를 가질 수 있습니다

우리는 모두 네트워크에서 OpenWRT 라우터를 실행하고 있기 때문에… 오픈 소스 라우터를 실행 중이시죠? 또는 다음이 있습니다. 소수의 상용 라우터 일종의 SQM이 내장되어 있지만 Hackaday에서는 여기에 만족하지 않습니다. 여기서 FOSS 솔루션은 케이크, 대기열 관리 시스템이며 이미 OpenWRT 저장소에서 사용할 수 있습니다. 당신이 찾는 패키지는 luci-app-sqm. 설치하면 네트워크 -> SQM QoS 아래의 웹 인터페이스에 새 페이지가 제공됩니다.

해당 페이지에서 WAN 인터페이스를 다음과 같이 선택하십시오. Interface name. 다음으로, 속도 테스트 결과를 킬로비트/초로 변환하고 약 5%를 깎고 업로드 및 다운로드 속도로 펀치합니다. 로 뒤집기 Queue Discipline 이상적으로 사용하려는 탭 Cakepiece_of_cake.qos 옵션으로. 마지막 탭에는 약간의 숙제 최고의 가치를 결정하지만 Ethernet with overhead22 시작하는 것이 올바른 가치인 것 같습니다. SQM 인스턴스를 활성화한 다음 저장하고 적용합니다.

이제 우리는 조정하고 테스트합니다. 처음 설치할 때 라우터는 실제로 커널 모듈을 로드하기 위해 재부팅이 필요할 수 있습니다. 그러나 버퍼블로트 테스트 중 하나에서 즉각적인 차이를 확인해야 합니다. 업로드 또는 다운로드 버퍼 블로트가 여전히 과도하다면 해당 방향의 속도를 몇 퍼센트 더 낮게 조정하십시오. 버퍼블로트가 0으로 떨어지면 속도를 약간 높여보십시오. 최대 속도에 대한 최소한의 효과와 버퍼 팽창에 대한 최대 효과를 찾고 있습니다. 그리고 그게 다야! 버퍼블로트 야수를 처치했습니다!

[포함 된 콘텐츠]

spot_img

최신 인텔리전스

spot_img