지연시간 – 대역폭 곱

학부 데이터 통신 / 네트워크 수업과 대학원 석사 과정동안 배운 많은 개념 중에 내가 가장 감명 깊게 생각했던 부분 중 하나가 대역폭 지연시간 곱 (bandwidth delay product).

이게 무슨 의민가?

End-to-end에서 아주 간략하게 생각하자면 하나의 링크에 대해 양쪽 끝 단 사이에 “날아가고 있는” 데이터의 총량이다. ((중간이 몇 hop인지는 중요치 않다)) 그러니까 둘 사이에 존재하는, 보냈지만 아직 도착하지 않은 데이터의 ‘용량’이란 의미.  이 이상 넣어봐야 실제로 네트워크 위에 있는게 아니라 양쪽 시스템의 버퍼 위 어딘가가 될 것이란 것. 즉, 양 끝 단 사이의 네트워크 자원을 최대한 활용하려면 이 정도의 데이터가 네트워크 위에 계속 존재한단 소리. 지연 시간에 대해 상대적으로 신경을 덜 써도 되는 시스템이라면 약간의 지연 시간을 감수하고라도, 전송량을 극대화 하기 위해서는 이 값 만큼의 데이터가 네트워크로 계속 흐르게 해줘야 한다.

결론적으로, “best-effort” 트래픽을 처리할 때 여러가지 목표를 적당히 trade-off하는게 아니라, 이 것 단 하나만 최적화하면 된다는 것.

이번에 마무리 지은 파일 전송 프로토콜/프로그램에서도 이 개념만 충실히 지키는 형식으로 만들었다. On-demand로 파일 chunk를 요청하긴 하는데, 특정 크기 — 앞에서 말한 대역폭 — 지연 시간 곱 만큼 — 의 윈도우를 두고, 이 윈도우 만큼의 데이터는 항상 미리 요청하게 한 것.어차피 RTT x 네트워크 대역폭만큼은 미리 요청해야, RTT 후에 요청한 데이터가 NIC를 통해 올라오고, 계속해서 대역폭을 채우게 된다. 실 세계에서도 이걸 최적화 못하면 “굉장히 느린 시스템"처럼 보이게 된다. 총 전송량이 적으면 대역폭 보다 지연 시간이 훨씬 크게 보이기 때문이다. 대역폭이 무한히 커 봐야 데이터는 RTT 후에나 오거든(…). 그래서 광대역 통신으로 해도 RTT가 크면 말짱 꽝. 예를 들어, HTTP같은 프로토콜에서는 한 번에 하나의 요청만 HTTP 연결 위로 오가기 때문에, 충분히 큰 단일 응답을 보내는 경우를 제외하고서는 요청을 보내고 응답을 받는 시간 (= RTT) 동안 이 링크를 채울래야 채울 수가 없다. 그래서 실제로 유저가 느끼는 대역폭이 매우 작다. ((게다가 DNS이름 기준으로 한 호스트에 보내는 연결은 기껏해야 2개. 물론 수 많은 브라우져들이 이걸 어기긴한다)) 덕분에(?) 매우 지연 시간에 예민한 시스템이된다.

그런 의미에서 Google의 HTTP 1.2 SPDY 같은 프로토콜이 나오는 것이기도 하다. 지연 시간이 더 중요하다는 의미로 비슷한 맥락에서 — 이 경우에는 HTTP의 한계가 아니라 TCP slow start의 한계 때문에 — TCP 알고리즘을 수정해서, Slow start의 구현을 사실 상 무시하고, 상대적으로 더 큰 slow-start window를 사용하는 변형(논문도 있다!)을 쓴다.