BDP(Bandwidth-delay product)와 TCP Receive Window
TCP Receive Window에 대해서는 지난 글에 설명했는데요,
Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
; https://www.sysnet.pe.kr/2/0/12530
그럼, 적정 값의 Window 크기는 어떻게 산정할 수 있을까요? 검색해 보면, 이에 대한 근거의 하나로 BDP라는 값이 나옵니다.
Bandwidth-delay product
; https://en.wikipedia.org/wiki/Bandwidth-delay_product
번역이 좀 원시적인데, 그냥 개별 영단어 그대로 "대역폭 지연 곱"이라고 합니다. 말이 좀 어렵고 심지어 BDP라고 줄여서도 말하기 때문에 눈에 잘 들어오지 않는데요, 사실 이 영어 단어조차도 구하는 공식을 그대로 단어화 시킨 것이나 다름없습니다. ^^;
대역폭 지연 곱 = 대역폭(bandwidth) x 지연(delay)
일반적으로 우리는 컴퓨터가 연결된 네트워크 속도에 관심이 있는데, 이때의 속도가 바로 대역폭(bandwidth)입니다. 여기에 지연 값을 곱하면 "The result is equivalent to the maximum amount of data on the network circuit at any given time"으로 설명하는 값이 나오는데요, 이것도 말이 좀 어려울 수 있지만 간단히 말해서 이상적인 TCP Receive Window 크기라고 보면 됩니다.
일단 직접적인 이해는 접어두고, 실제로 공식에 따라 직접 구해 볼까요? 우선,
대역폭은 제어판의 네트워크 및 공유 센터를 통해 알 수 있는 것으로, 우리가 그동안 알아왔던 KT, SKT, LG에 가입했을 때의 그 네트워크 속도입니다.
그리고 "지연(delay)"은 대상 컴퓨터와의 RTT(Round Trip Time)로, 이 값은 ping(또는
GetRTTAndHopCount)을 이용해 간단하게 구할 수 있습니다. 가령 마이크로소프트 웹 서버와의 ping을 보면,
C:\temp> ping www.microsoft.com
Pinging e13678.dscb.akamaiedge.net [23.201.37.168] with 32 bytes of data:
Reply from 23.201.37.168: bytes=32 time=3ms TTL=56
Reply from 23.201.37.168: bytes=32 time=4ms TTL=56
Reply from 23.201.37.168: bytes=32 time=3ms TTL=56
Reply from 23.201.37.168: bytes=32 time=3ms TTL=56
Ping statistics for 23.201.37.168:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 4ms, Average = 3ms
평균 3ms가 걸렸으므로 다음과 같이 계산할 수 있습니다.
대역폭 지연 곱 = 1Gbps * 0.003
= 1,000,000,000 bit/sec * 0.003 sec = 3,000,000 bit = 3 Mbit
=> 3,000,000 bit / 8 = 375 Kbytes
하지만 위의 계산은 다소 이상적인 가정을 포함하는데, 바로 대상 컴퓨터와의 모든 경로의 속도가 내가 속한 네트워크의 대역폭과 동일하거나 그 이상의 네트워크 대역폭을 지녀야 한다는 점입니다. 가령 위의 마이크로소프트 서버가 (극단적으로) 1Mbps 망에 있거나, 그 사이에 거쳐오는 네트워크 일부 선로의 대역폭이 1Mbps라면 당연히 저 값이 나올 수 없습니다.
그건 그렇고, 대역폭 지연 곱은 숫자가 클수록 좋을까요? 가령, 위의 공식에서 RTT 시간, 즉 네트워크 사이의 delay 시간을 10배 늘려보면 어떤 느낌인지 알 수 있습니다.
3ms = 375 KB
30ms = 3,750 KB (지연 시간이 10배로 느려지면서, BDP가 10배가 됨)
위의 결과를 놓고 "The result is equivalent to the maximum amount of data on the network circuit at any given time"라는 설명을 보면 이제 이해가 쉽게 될 것입니다.
즉, BDP는 상대와의 통신에서 네트워크 구간에 흐르는 최대 데이터량을 의미합니다. 그래도 어려운가요? 그럼 좀 더 쉬운 예를 들어 보겠습니다. ^^ 가령 초당 10개씩 공을 던질 수 있는 기계가 있고 그렇게 던진 공이 2초 후에 땅에 떨어진다고 가정해 보겠습니다. 그럼, 처음 그 기계를 켜고 나서 2초가 되었을 때 바닥과 허공 사이에 몇 개의 공이 있을까요? 해당 기계는 초당 10개씩 계속 공을 쏘고 있을 테니 20개의 공이 있을 것입니다. 그런데, 공이 4초 후에 떨어진다면 어떨까요? 여전히 기계는 초당 10개씩 공을 쏘기 때문에 이번에는 40개의 공이 있게 됩니다. 개념이 머릿속에 그려지시죠? ^^
위의 설명에서는 공이 닿기까지의 시간, 즉 단방향 시간을 계산한 것인데 BDP는 RTT 시간, 즉 돌아오는 시간까지 계산했다는 차이가 있습니다. 왜냐하면, 실제 TCP 통신에서는 패킷을 계속 보낼 수만은 없고 반드시 해당 패킷이 정상적으로 도착했는지 ACK를 받아야 하기 때문입니다. 그렇기 때문에 BDP로 계산한 (마이크로소프트의 경우 375KB) 값을 TCP Receive Window 크기로 설정해 놓으면 적어도 현재 네트워크 상에 흘러오고 있는 데이터 정도는 ACK 없이 종단에서 받아들일 수 있는 것입니다.
이미 눈치채셨겠지만, 사실 BDP에 따라 Receive Window를 지정하는 것은 패킷 유실이 없고 동일한 대역폭을 가정하는 등의 이상적인 환경에서나 유효합니다. 게다가 이 값은 종단 간의 계산 값이므로 시스템 전체의 TCP 설정이 아닌, TCP 연결 개체 수준에서 개별적으로 설정되어야 하는 것인데, 적어도
윈도우 소켓의 setsockopt에서는 이를 위한 방법이 없습니다.
이래저래 현실적으로 보면 BDP를 계산한 값을 설정하기보다는, 역시나 운영체제의 TCP layer가 스스로 Receive Window에 대한 크기 조절을 하는 것이 맞을 것입니다. 그래서 이런 것도 구현해놨을 것이고. ^^
The Cable Guy TCP Receive Window Auto-Tuning
; https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc162519(v=msdn.10)
마지막으로, BDP에 대해 설명한 다음의 글들도 보시면 좋겠습니다. ^^
Bandwidth-delay product
; https://hoonheui.tistory.com/entry/Bandwidth-delay-product
[오리뎅이의 TCP 이야기 - 0] TCP 속도(Throughput)는 어떻게 구해지나요?
; https://blog.naver.com/goduck2/220076011565
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]