티스토리 뷰
이 포스팅은 오리뎅이님의 야학(?)을 정리한 내용입니다.
병목구간(bottleneck)이란, 인터넷을 이용하는 Client와 인터넷 Server 사이에 존재하는 네트워크 구간 중 가장 bandwidth가 작은 구간을 말한다.
인터넷 초창기엔 서버의 media speed/스위치나 라우터의 interface/home edge단 link가 모두 100Mbps(Fast Ethernet)이었기에 병목구간이 큰 문제로 부각되지 않았다. 하지만 Gigabit ethernet이 나오면서 상황이 달라졌다.
이전에는 64Kbyte의 window size로 충분히 성능을 낼 수 있었지만, 이후 인터넷 속도가 올라감에 따라 window size를 올릴 수 밖에 없었기 때문이다. (RFC 1323)
서버의 media speed나 상위 네트워크가 1G로 바뀜에 따라 WiFi AP/Microwave 장비 등이 병목구간이 되었다. 이에 Speed mismatch에 의한 buffer overflow가 빈번히 발생하면서 Throughput 저하, 잦은 재전송 등 link 효율이 감소하게 되었다. 특히, packet drop의 경우 TCP 통신상의 속도(Throughput)에 치명적일 수 있었다.
이에 제조사들은 메모리 가격 하락 등의 외부 요인을 반영하여 Buffer 메모리를 크게 늘리는 형태로 대응하였지만 이는 또다른 문제를 낳았다. 여러명이 동시 접속해서 사용하는 WiFi의 경우 buffer는 큰 데 비해 bandwidth가 작아, 한 유저가 file을 다운로드 받는 경우에 WiFi AP의 buffer가 그 유저의 데이터로 가득 차버리는 등의 문제가 발생하였다. 이에 다른 유저가 동일 WiFi를 사용할 경우 인터넷 접속 Ack가 buffer의 맨 뒤에 쌓여, 최대 buffering delay가 수백 ms에서 수초까지 발생하는 등 지연 현상이 발생하였다. 이런 현상을 Bufferbloat이라 한다.
처리량 = (한번에 보낼수 있는 양) * (단위시간/왕복에 걸리는 시간) 으로 가정할 경우, Throughput = Window Size / RTT
예를 들어,
병목구간이 100Mbps Ethernet이고, Client와 서버의 RTT는 40ms 상황을 가정해보자
100Mbps(bandwidth) * 40ms(delay) = 10000000 * 0.04 = 4000000 bits = 500Kbytes
BDP(Bandwidth Delay Product)는 병목구간의 bandwidth를 최대한 다 사용할 수 있는 window size를 의미한다.
즉, 이 경우 100Mbps 속도로 40ms 동안 보낼 수 있는 데이터가 500Kbytes이기 때문에 Window size가 500Kbytes로 끊김없이 서버에서 계속 데이터를 보낼 경우, 병목구간 100Mbps를 하나의 세션이 모두 사용하게 된다.
기존의 CUBIC 알고리즘의 경우, 사용자가 몰리는 등의 트래픽 증가로 패킷손실이 발생할 당시의 window size를 기준으로 cwnd(congestion window)를 계산하여 패킷 손실을 방지하였다.
이에 반해, Google의 BBR은 패킷 손실보다는 최근 network's delivery rate과 round-trip time을 활용하여 허용할 수 있는 데이터 양을 제어한다.
BBR: Congestion-based congestion control
반면, buffer가 매우 작은 경우, 가령 위의 예에서 병목구간의 buffer가 64KBytes인 경우 buffer overflow가 발생한다.
Throughput = 64KB / 0.04(sec) = 12.8Mbps 이므로, 100Mbps link를 최대한 활용하지 않을 뿐더러 서버의 media bandwidth가 1G 일 경우 speed mismatch에 의한 buffer overflow가 발생한다. (구글의 BBR은 buffer가 작을 경우를 고려하진 않았다고 보인다.)
앞으로 상이한 네트워크 환경(IoT vs 100G 이상)이 공존하게 될 것을 고려해보면, 해당 이슈들에 대한 논의도 많이 다루게 되지 않을까 싶다.
'Infra Structure > .system' 카테고리의 다른 글
Reverse Proxy란? (0) | 2019.04.06 |
---|---|
다중화란? (0) | 2019.03.24 |
Elastic Stack #1 (0) | 2019.02.10 |
DevOps란 ? (0) | 2018.02.27 |
윈도우 특정 프로세스 죽이기 (0) | 2017.10.24 |