Windows Server 2008이 나오면... (22) - Network Auto-Tuning (2)

http://blogs.technet.com/koalra/archive/2007/05/16/windows-server-2008-22-network-auto-tuning.aspx

어제 21편에서는 Network, TCP에 대한 기본적인 사항을 알아보았습니다. 꼭 Windows뿐만 아니라, 모든 네트워크 관련 사항을 진행할 때, 반드시 아셔야할 내용이었습니다. 자 그럼 어제에 이어서...

TCP Receive Window 제한은 TCP 연결시 사용할 수 있는 처리량에 제한을 가하게 됩니다. 이론적으로 Receive Window를 R이라고 하고, 양 종단간의 RTT(Rount Trip Time)을 T라고 했을 때...

Throughput =  R/T

가 되게 됩니다. 저도 처음에 잘 이해가 안가는 공식이었지만(Bandwidth-Latency 기술을 공부할 때 봤었던 공식이었습니다.), 조금 이해를 돕기 위해.. 다시 공식을 바꿔 써보면..

Throughput X T = R

최대 처리량은 초당 전송량이기 때문에, 실제 전송되기 까지의 지연(시간이죠)을 곱해주면 상대방이 받을 수 있는 한번에 수신할 수 있는 최대 처리량.. = TCP가 받을 수 있는 최대 Window 크기가 되게 됩니다.

예를 들어, Windows Server 2003, XP의 TCP Receive Window 기본 크기는 64KB였었습니다. 양단간의 RTT가 100ms 일 때, 최대 처리량은 64KB/100ms = 5.12Mbps가 되게 됩니다. 사용 응용 프로그램이 어떠한 제한 사항도 없다면, TCP 송신자는 네트워크에 가용할 수 있는 최대 대역폭을 다 사용할 수 있습니다.

이미 언급한 데로, 기존의 Windows는 전체 시스템에 대해서 TCP Receive Window가 64KB로 고정되어져 있었습니다. 이러한 접근 방식은 대역폭이 점점 커져가는 현실에, 처리량을 제한하는 요소중 하나였습니다. 레지스트리 키중에 TCPWindowSize가 원하는 값으로 Receive Window 크기를 입력할 수 있었지만, 이러한 입력은 시스템 전체에 영향을 주었기 때문에, 특정한 TCP 연결, 다시 말해, 무선에 대한 설정, 유선에 대한 설정은 할 수 없었습니다.

위의 그림은 Receive Window 크기와 RTT값에 따른 최대 처리량을 보여주는 그래프입니다. 보시는 데로, 기본 크기인 64KB로 Receive Window 크기를 사용했을 경우, RTT 값이 커질 수록(다시 말해, 거리가 멀어질 수록) 사용가능한 최대 처리량이 줄어들어는 것을 볼 수 있습니다. 거의 5Mbps 밑이죠. 두 지점간 대역폭이 아무리 좋더라도 실제 사용 가능한 대역폭은 5Mbps이상을 쓰기가 어려웠다는 것입니다. 그렇다고 무조건 Receiving Window 크기가 커야 한다는 의미는 아닙니다. 시스템간이 단일 스위치, 다시 말해, 매우 거리가 가까운 경우에는 RTT값이 매우 작으므로, 무조건 크기를 키우는 것이 능사만은 아닙니다.

이에, Windows Server 2008, Windows Vista에서는 Receive Window 크기에 대해 자동으로 튜닝하는 기능이 추가되었습니다. 모든 연결시, 환경을 파악하여, TCP가 Receive Window 크기를 조절합니다. 이러한 기능을 통해, 네트워크로 더 많은 양의 데이터를 전송하고, 이를 통해 사용자는 빠른 처리 시간을 기대할 수 있습니다. 높은 대역폭, 높은 지연률을 가진, 대륙간, 지역간 네트워크일수록 Windows Server 2008, Windows Vista의 네트워크 튜닝 기능이 매우 유용해질 수 있습니다. Receive Window가 커져서, 네트워크에 문제가 발생할 수 있지 않냐는 질문을 하시지만, 이미 이전 포스팅에 언급드린 데로, TCP는 Congestion Control도 역시 메커니즘의 하나로 가지고 있었습니다.

TCP의 Receive Windows 제어는 송신자가 수신자에게 데이터를 보낼때, 얼마나 많은 양의 확인되지 않은(Unacknowledged) 데이터를 보낼 수 있느냐의 의미입니다.

응답이 빠르다면(거리가 가깝다면), 구지 Receiving Window 크기를 키울 필요가 없다는 것도 이제는 이해가 되실 것입니다. 그러나, RTT가 커졌을 경우, 데이터를 보냈을 때, 이에 대한 확인을 받는 시간이 오래걸리므로, 그만큼 송신자는 네트워크 파이프를 채울 수 있는 많은 시간이 남게 됩니다, 이 경우, Receiving Window 값이 네트워크 파이프를 다 사용하지 못하는 팩터가 된다.. 는 의미입니다. 헥헥..

가장 최적의 크기는 송신자가 네트워크가 유지되는 한도에서 보낼 수 있는 크기라고 볼 수 있습니다. Windows Vista에서부터 해당 기능은 이미 사용중에 있습니다. 이러한 자동 튜닝이 적용되기 위해서는 아래의 몇가지 사항이 만족되어야 합니다.

1. 연결에 대한 지연 > 10ms (RTT)
2. Bandwidth * Latency > 64KB
3. 응용 프로그램에 수신 버퍼 크기가 지정되지 않은 경우
4. 응용 프로그램이 보내주는 데이터의 크기에 상관없이 처리가 되는 경우

이제 또하나의 문제를 제기해야 합니다. TCP의 Receive Window 크기를 지정하는 레지스트리는 16비트입니다. 2에 16승이 65535.. 64KB이므로, Window 크기를 더 늘리려면 레지스트리의 비트가 늘어나던지, 무언가 다른 방법론이 취해져야 합니다. 이에 Windows는 TCP Receive Window Scailing에 관련된 레지스트리를 추가적으로 사용합니다. Window Scailing 옵션을 Windows Vista, Windows Server 2008은 기본적으로 사용합니다.

TCP 연결 시도를 하는 동안, 송신자와 수신자는 Scailing 옵션을 상호 교섭합니다. 만약 원격지에서 이를 지원한다면, Window Scailing 옵션이 사용되게 됩니다, Windows Vista는 Scale 팩터로 8 (2에 8승 = 256)을 사용합니다. 256배가 된다는 뜻이죠.. 64KB X 256 = 16MB의 Receiving Window가 되죠.. 기존값에 비하면 매우 높은 값이며, 이러한 값을 무작정 사용하는 것이 아니라, 원격지 시스템, 네트워크 상태에 따라 자동으로 조절하게 된다는 뜻입니다.