The Cable GuyTCP 수신 창 자동 조정

Joseph Davies

TechNet Magazine의 첫 번째 The Cable Guy 칼럼에 오신 것을 환영합니다. TechNet 웹 사이트 칼럼을 즐겨 구독하시는 분들은 이미 우리가 네트워킹과 관련된 모든 주제를 다룬다는 것을 알고 있습니다. 이 컬럼에서도 매월 이러한 내용을 다루고자 합니다. 처음 방문하셨거나 이전 칼럼을 찾아보려면 Cable Guy 사이트(영문)를 참조하십시오.

이제 첫 번째 주제인 TCP 수신 창에 대해 살펴보겠습니다.

TCP 연결의 처리량은 송신 및 수신 응용 프로그램, TCP 송신 및 수신 구현 방식, TCP 피어 간의 전송 경로에 의해 제한될 수 있습니다. 이 칼럼에서는 TCP 수신 창과 이 창이 TCP 처리량에 미치는 영향, TCP 창 배율 사용 및 수신된 데이터에 대한 TCP 처리량을 최적화하는 Windows Vista™의 새로운 수신 창 자동 조정 기능에 대해 설명합니다.

TCP 수신 창

TCP 연결에는 중요한 특징이 많이 있습니다. 첫째로, 두 응용 프로그램 계층 프로토콜 간에 논리적인 지점 간 회선이 있습니다. TCP는 일대다 전송 서비스를 제공하지 않으며 일대일 전송만 제공합니다.

둘째로, TCP 연결은 연결 지향적입니다. 데이터를 전송하기 전에 두 응용 프로그램 계층에서 TCP 연결 설정 프로세스를 통해 TCP 연결을 정식으로 협상해야 합니다. 마찬가지로 TCP 연결은 TCP 연결 종료 프로세스를 통해 협상한 후 정식으로 닫힙니다.

셋째로, TCP 연결에서는 데이터의 순서가 지정되어 안정적으로 전송되며 수신 측의 긍정적 승인을 기다립니다. 긍정적 승인이 수신되지 않으면 세그먼트가 다시 전송됩니다. 수신 측에서는 중복된 세그먼트가 제거되고 잘못된 순서로 수신된 세그먼트는 올바른 순서로 위치가 되돌려집니다.

넷째로, TCP 연결은 전이중 방식입니다. 각 TCP 피어 간의 TCP 연결은 송신 파이프와 수신 파이프라는 두 개의 논리적 파이프로 구성됩니다. TCP 헤더에는 송신 데이터의 시퀀스 번호와 수신 데이터의 승인(ACK)이 들어 있습니다.

또한 TCP에서는 송신 및 수신 논리적 파이프를 통해 전송되는 데이터를 연속적인 바이트 스트림으로 간주합니다. 각 TCP 헤더의 시퀀스 번호와 승인 번호는 바이트 단위에 따라 정의됩니다. TCP는 바이트 스트림 내의 레코드 또는 메시지 단위를 인식하지 않습니다. 응용 프로그램 계층 프로토콜에서는 수신 바이트 스트림을 올바르게 구문 분석해야 합니다.

TCP 피어는 한 번에 전송할 수 있는 데이터의 양을 제한하고 수신 측 흐름 제어를 제공하기 위해 창을 사용합니다. 이 창은 송신 측이 수신 측에 보낼 수 있도록 허용된 바이트 스트림상의 데이터 범위를 나타냅니다. 송신 측은 이 창의 범위에 맞는 바이트 스트림의 바이트만 보낼 수 있습니다. 이 창은 송신 측의 아웃바운드 바이트 스트림과 수신 측의 인바운드 바이트 스트림에 따라 이동합니다.

지정된 논리적 파이프(전이중 TCP 연결에서 한쪽 방향)에 대해 송신 측은 전송 창을 유지하고 수신 측은 수신 창을 유지합니다. 전송되는 데이터 또는 ACK 세그먼트가 없으면 논리적 파이프의 전송 및 수신 창이 일치하게 됩니다. 즉, 송신 측에서 보내도록 허용된 아웃바운드 바이트 스트림의 데이터 범위가 수신 측에서 받을 수 있는 인바운드 바이트 스트림의 데이터 범위와 일치하는 것입니다. 그림 1에서는 송신 및 수신 관계를 보여 줍니다.

그림 1 전송 및 수신 창 일치

그림 1** 전송 및 수신 창 일치 **(더 크게 보려면 이미지를 클릭하십시오.)

수신 창의 크기를 지정하기 위해 TCP 헤더에는 16비트의 Window 필드가 들어 있습니다. 데이터를 받은 수신 측에서는 송신 측에 ACK를 보내 성공적으로 수신된 바이트를 알려 줍니다. 각 ACK의 Window 필드에는 수신 창에 남아 있는 바이트 수가 들어 있습니다. 응용 프로그램에서 데이터를 보내고 승인하고 검색하면 전송 및 수신 창도 오른쪽으로 이동합니다. 수신 창은 송신 측에서 수신 측으로 보낼 수 있는 승인되지 않은 데이터의 양을 제어하는 창입니다.

수신 창에는 응용 프로그램에서 아직 검색하지 않은 데이터와 수신은 되었지만 승인되지는 않은 데이터가 있을 수 있으므로 TCP 수신 창은 그림 2와 같은 구조를 갖게 됩니다.

그림 2 TCP 수신 창의 데이터 형식

그림 2** TCP 수신 창의 데이터 형식 **(더 크게 보려면 이미지를 클릭하십시오.)

최대 수신 창과 현재 수신 창 간에는 다른 점이 있습니다. 최대 수신 창은 고정된 크기입니다. 현재 수신 창은 가변 크기이며, 이 크기는 송신 측이 수신 측에 보낼 수 있도록 허용된 남은 데이터 양에 해당합니다. 현재 수신 창의 크기는 송신 측에 전송된 ACK에 들어 있는 Window 필드의 값이며, 응용 프로그램에서 수신하고 승인했지만 아직 검색하지 않은 데이터의 양을 최대 수신 창 크기에서 뺀 값과 같습니다.

TCP 수신 창 및 TCP 처리량

전송 경로에 오류가 없는 것으로 가정할 경우 TCP 처리량을 최적화하려면 송신 측에서 송신 측과 수신 측 간의 논리적 파이프를 충분히 채울 수 있을 정도의 패킷을 보내야 합니다. 논리적 파이프의 용량은 다음 수식을 통해 계산할 수 있습니다.

Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds

용량은 BDP(Bandwidth-Delay Product)라고도 합니다. 파이프는 두껍거나(높은 대역폭) 얇거나(낮은 대역폭) 짧거나(낮은 RTT) 길(높은 RTT) 수 있습니다. 두껍고 긴 파이프의 경우 BDP가 가장 높습니다. BDP가 높은 전송 경로의 예로는 위성 통신 또는 대륙 간 광 섬유 링크가 구축되어 있는 기업의 WAN(Wide Area Network) 등이 있습니다.

높은 BDP 전송에 대한 송신 측 성능 향상

새로운 수신 창 자동 조정 기능은 높은 BDP 링크를 통해 향상된 데이터 수신 성능을 제공하지만 송신 측 성능의 경우에는 어떤 효과가 있을까요?

전송 TCP 피어가 네트워크를 독점하지 못하도록 설계된 기존 알고리즘은 느린 시작(Slow Start) 및 정체 회피(Congestion Avoidance)로 잘 알려져 있습니다. 이 알고리즘은 연결에서 처음 데이터를 보낼 때와 손실된 세그먼트를 복구할 때 전송 창(송신 측에서 보낼 수 있는 세그먼트 수)을 늘립니다.

느린 시작(Slow Start)은 수신된 각 승인 세그먼트(Windows XP 및 Windows Server 2003 TCP의 경우) 또는 승인된 각 세그먼트(Windows Vista 및 Windows Server "Longhorn" TCP의 경우)에 대해 하나의 전체 TCP 세그먼트만큼 전송 창을 늘립니다. 정체 회피(Congestion Avoidance)의 경우 승인된 전체 데이터 창 각각에 대해 하나의 전체 TCP 세그먼트만큼 전송 창을 늘립니다.

이 알고리즘은 BDP가 낮거나 수신 창 크기가 작을수록 잘 작동합니다. 그러나 RTT(왕복 대기 시간)이 100ms인 고속 WAN 링크로 연결된 두 서버 간에 데이터를 복제하는 경우처럼 수신 창 크기가 크고 BDP가 높은 TCP 연결에서 이 알고리즘은 연결의 대역폭을 충분히 활용할 수 있을 정도로 빠르게 전송 창을 늘리지 않습니다.

이러한 상황에서 TCP 연결 대역폭을 효율적으로 활용하기 위해 차세대 TCP/IP 스택에는 CTCP(Compound TCP)가 포함됩니다. CTCP는 수신 창 크기가 크고 BDP가 높은 연결에 대해 전송 창을 보다 적극적으로 늘립니다. CTCP는 지연 시간의 변화와 손실된 패킷을 모니터링하여 이러한 유형의 연결에 대한 처리량을 극대화하려고 시도합니다. 또한 CTCP의 동작은 다른 TCP 연결에 부정적인 영향을 주지 않습니다.

Microsoft 내부적으로 수행된 테스트에서 RTT가 50ms인 1Gbps 연결의 경우 대용량 파일 백업 시간이 거의 절반으로 단축되었습니다. BDP가 높은 연결일수록 더 나은 성능을 기대할 수 있습니다. CTCP 및 수신 창 자동 조정 기능을 함께 사용하면 링크 사용률을 높이고 BDP가 높은 연결의 성능을 크게 향상시킬 수 있습니다.

CTCP는 Windows Server "Longhorn"이 실행되는 컴퓨터의 경우 기본적으로 활성화되고 Windows Vista가 실행되는 컴퓨터의 경우 기본적으로 비활성화되어 있습니다. "netsh interface tcp set global congestionprovider=ctcp" 명령을 사용하여 CTCP를 활성화할 수 있습니다. "netsh interface tcp set global congestionprovider=none" 명령을 사용하여 CTCP를 비활성화할 수 있습니다.

TCP 헤더의 Window 필드 크기는 16비트이므로 TCP 피어는 이 필드를 사용하여 65,535바이트의 최대 수신 창 크기를 알릴 수 있습니다. 다음 수식을 사용하여 지정된 TCP 창 크기에 대한 대략적인 처리량을 계산할 수 있습니다.

Throughput = TCP maximum receive windowsize / RTT

예를 들어 65,535바이트의 수신 창을 사용할 경우 전송 경로의 실제 대역폭에 관계없이 100ms RTT 경로에서 초당 5.24메가비트의 대략적인 처리량만 얻을 수 있습니다. 오늘날과 같이 BDP가 높은 전송 경로에서는 원래 설계된 TCP 창 크기를 최대값으로 사용하더라도 처리량 병목 현상이 발생합니다.

TCP 창 배율

고속 전송 경로에 적합한 대용량 창 크기에 대해 RFC 1323(ietf.org/rfc/rfc1323.txt)에서는 수신 측이 65,535바이트 이상의 창 크기를 알릴 수 있도록 하는 창 배율을 정의합니다. TCP 창 배율 옵션에는 TCP 헤더의 16비트 Window 필드와 결합될 경우 수신 창 크기를 최대 약 1GB로 늘릴 수 있는 창 배율 인수가 있습니다. 창 배율 옵션은 연결 설정 프로세스 동안에 동기화(SYN) 세그먼트로만 전송됩니다. 양쪽 TCP 피어는 수신 창 크기에 사용할 창 배율 인수를 서로 다르게 지정할 수 있습니다. TCP 창 배율을 사용하면 송신 측에서 연결을 통해 더 많은 데이터를 보낼 수 있으므로 TCP 노드에서 BDP가 높은 몇 가지 유형의 전송 경로를 더 효율적으로 활용할 수 있게 됩니다.

수신 창 크기도 TCP 처리량에 중요하지만 최적의 TCP 처리량을 결정하는 중요한 요소는 응용 프로그램에서 수신 창에 누적된 데이터를 검색하는 속도(응용 프로그램 검색 속도)입니다. 응용 프로그램이 데이터를 검색하지 않으면 수신 창이 채우기를 시작할 수 있으므로 수신 측에서는 작아진 현재 창 크기를 알리게 됩니다. 극단적인 경우를 가정할 때 최대 수신 창이 모두 채워지면 수신 측에서는 0바이트의 창 크기를 알리게 됩니다. 이 경우 송신 측에서는 수신 창이 비워질 때까지 데이터 전송을 중단해야 합니다. 따라서 TCP 처리량을 최적화하려면 연결의 전송 경로 BDP와 응용 프로그램 검색 속도가 반영된 값을 연결에 대한 TCP 수신 창의 크기로 설정해야 합니다.

BDP와 응용 프로그램 검색 속도를 올바르게 결정한 경우라도 이 값은 시간이 지남에 따라 변경될 수 있습니다. BDP 속도는 전송 경로의 정체에 따라 달라질 수 있으며 응용 프로그램 검색 속도는 응용 프로그램에서 데이터를 받고 있는 연결의 수에 따라 달라질 수 있습니다.

Windows XP의 수신 창

Windows XP(및 Windows Server® 2003) TCP/IP 스택의 최대 수신 창 크기에는 중요한 특성이 많이 있습니다. 첫째로, 전송 인터페이스의 연결 속도에 따라 기본값이 결정됩니다. 실제 값은 TCP 연결 설정 중에 협상된 MSS(최대 세그먼트 크기)의 증분으로 자동 조정됩니다.

둘째로, 최대 수신 창 크기를 수동으로 구성할 수 있습니다. HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize 및 HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize 레지스트리 값을 최대 65,535바이트(창 배율을 사용하지 않은 경우) 또는 1,073,741,823바이트(창 배율을 사용하는 경우)로 설정할 수 있습니다.

셋째로, 최대 수신 창 크기에서 창 배율을 사용할 있습니다. HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts 레지스트리 값을 1 또는 3으로 설정하여 창 배율을 사용할 수 있습니다. 기본적으로 창 배율은 수신된 SYN 세그먼트에 창 배율 옵션이 들어 있는 연결에서만 사용됩니다.

마지막으로 연결을 시작할 때 응용 프로그램이 SO_RCVBUF Windows 소켓 옵션을 사용하여 최대 수신 창 크기를 지정할 수 있습니다. 창 배율의 경우 응용 프로그램에서는 창 크기를 65,535바이트 이상으로 지정해야 합니다.

Windows XP에서는 창 배율 기능을 지원하지만 최대 수신 창 크기는 응용 프로그램에서 지정하지 않는 한 모든 TCP 연결에 대해 최대 크기로 고정되므로 처리량이 제한될 수 있습니다. 이 경우 일부 연결의 처리량은 높아지고 다른 연결의 처리량은 낮아지는 현상이 발생할 수 있습니다. 또한 TCP 연결에 대한 고정된 최대 수신 창 크기는 응용 프로그램 검색 속도나 전송 경로의 정체에 따라 바뀌지 않습니다.

Windows Vista의 수신 창 자동 조정

특히 BDP가 높은 전송 경로의 경우 TCP 처리량을 최적화하기 위해 Windows Vista 및 Windows Server "Longhorn"의 차세대 TCP/IP 스택에서는 수신 창 자동 조정 기능을 지원합니다. 이 기능은 BDP와 응용 프로그램 검색 속도를 측정한 다음 사용 중인 전송 경로와 응용 프로그램의 조건에 맞게 창 크기를 조정하여 최적의 수신 창 크기를 결정합니다.

수신 창 자동 조정은 기본적으로 TCP 창 배율 기능을 활성화하여 최대 수신 창 크기를 16MB까지 확장합니다. 연결을 통해 데이터가 전송될 때 차세대 TCP/IP 스택은 연결을 모니터링하고 연결의 현재 BDP 및 응용 프로그램 검색 속도를 측정한 다음 수신 창 크기를 조절하여 처리량을 최적화합니다. 차세대 TCP/IP 스택에서는 더 이상 TCPWindowSize 레지스트리 값을 사용하지 않습니다.

수신 창 자동 조정 기능은 여러 가지 이점을 제공합니다. 이 기능은 각 연결에 대해 최적의 수신 창 크기를 자동으로 결정합니다. Windows XP에서는 TCPWindowSize 레지스트리 값이 모든 연결에 적용됩니다. 응용 프로그램에서 더 이상 Windows 소켓 옵션을 통해 TCP 창 크기를 지정하지 않아도 됩니다. 또한 IT 관리자는 특정 컴퓨터의 TCP 수신 창 크기를 수동으로 구성할 필요가 없습니다.

수신 창 자동 조정을 사용하는 Windows Vista 기반의 TCP 피어는 일반적으로 Windows XP 기반의 TCP 피어보다 훨씬 큰 수신 창 크기를 알립니다. 수신 창 크기가 크기 때문에 다른 TCP 피어는 TCP 정체 제어에 따라 ACK를 기다릴 필요 없이 더 많은 TCP 데이터 세그먼트를 보내서 Windows Vista 기반 TCP 피어로 연결되는 파이프를 채울 수 있습니다. 웹 페이지나 전자 메일과 같은 일반적인 클라이언트 기반 네트워킹 트래픽의 경우 웹 서버나 전자 메일 서버에서 클라이언트 컴퓨터에 더 많은 TCP 데이터를 더욱 빠르게 보낼 수 있으므로 결과적으로 네트워크 성능이 전반적으로 향상됩니다. 연결에 대한 BDP와 응용 프로그램 검색 속도가 높을수록 더 나은 성능을 얻을 수 있습니다.

네트워크에 미치는 영향은 일반적으로 낮게 측정되는 속도로 전송되는 TCP 데이터 패킷 스트림이 보다 빠르게 전송되기 때문에 데이터 전송 중 네트워크 사용률이 더 높아진다는 것입니다. 두껍고 긴 파이프를 통해 동일한 데이터를 전송하는 Windows XP 및 Windows Vista 기반 컴퓨터의 경우 동일한 양의 데이터가 전송됩니다. 그러나 Windows Vista 기반 클라이언트 컴퓨터의 경우 수신 창 크기가 커지고 서버에서 클라이언트로 이어지는 파이프를 채우는 서버의 성능이 향상되었기 때문에 데이터 전송 속도가 더 빨라집니다.

수신 창 자동 조정은 BDP가 높은 전송 경로의 네트워크 사용률을 높이기 때문에 최대 용량을 거의 모두 사용하는 전송 경로의 경우 서비스 품질(QoS) 또는 응용 프로그램 전송 속도 제한을 사용하는 것이 중요해질 수 있습니다. 이러한 요구를 해결하기 위해 Windows Vista는 IP 주소 또는 TCP 포트 단위로 전송된 트래픽의 제한 속도를 정의할 수 있는 그룹 정책 기반의 QoS 설정을 지원합니다. 자세한 내용은 정책 기반 QoS의 리소스(영문)를 참조하십시오.

손실률이 높은 네트워크의 TCP 처리량 향상

손실률이 높은 네트워크의 경우 잦은 시간 제한 만료와 재전송으로 인해 TCP 처리량이 급격하게 떨어질 수 있습니다. 손실률이 높은 네트워크의 예로는 IEEE 802.11, GPRS(General Packet Radio Service) 또는 UMTS(Universal Mobile Telecommunications System) 기반의 무선 네트워크 등이 있으며, 이러한 네트워크에서는 네트워크 조건, 신호 감쇠, 전자기 간섭 및 컴퓨터 위치 변경 등에 따라 패킷 손실률이 높아질 수 있습니다.

차세대 TCP/IP 스택은 손실률이 높은 환경의 처리량을 최적화하기 위해 다음 네 가지 RFC를 지원합니다.

RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm

RFC 2001에 정의된 빠른 복구(Fast Recovery) 알고리즘은 빠른 재전송 이벤트로 인해 세그먼트가 다시 전송될 때 송신 측에서 보낼 수 있는 데이터의 양을 늘려주는 Reno 알고리즘을 기반으로 합니다. Reno 알고리즘은 단일 손실 세그먼트의 경우 제대로 작동하지만 손실 세그먼트가 많을 경우에는 잘 작동하지 않습니다. NewReno 알고리즘은 데이터 창의 여러 세그먼트가 손실되고 송신 측에서 부분 승인(일부 성공적으로 수신된 데이터만 승인)을 받은 경우 빠른 복구 동안 송신 측이 전송 속도를 높이는 방법을 변경하여 처리량을 높여 줍니다.

RFC 2883: An Extension to the Selective Acknowledgment (SACK) Option for TCP

RFC 2018에 정의된 SACK는 수신 측에서 SACK TCP 옵션을 사용하여 수신 데이터 중 불연속적인 블록을 4개까지 나타낼 수 있도록 허용합니다. RFC 2883에서는 SACK TCP 옵션의 필드를 추가로 사용하여 중복 패킷을 승인할 수 있도록 정의합니다. 이렇게 하면 송신 측에서 세그먼트 재전송이 필요 없는 경우를 파악하여 향후 불필요한 재전송을 방지할 수 있습니다. 재전송 횟수가 줄어들수록 전반적인 처리량은 향상됩니다.

RFC 3517: A Conservative Selective Acknowledgment-based Loss Recovery Algorithm for TCP

Windows Server 2003 및 Windows XP에 현재 구현되어 있는 TCP/IP에서는 대상에 도달하지 TCP 세그먼트를 확인하는 데만 SACK 정보를 사용합니다. RFC 3517에서는 중복 승인이 수신된 경우 SACK 정보를 사용하여 손실 복구를 수행하는 방법을 정의합니다. 이 방법은 연결에서 SACK가 활성화된 경우 기존의 빠른 복구 알고리즘을 대체합니다. 차세대 TCP/IP 스택에서는 여러 세그먼트가 대상에 도달하지 않은 경우 더 빠르게 복구할 수 있도록 하기 위해 연결 단위로 SACK 정보를 추적하고 들어오는 승인 및 중복 승인을 모니터링합니다.

RFC 4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)

TCP 세그먼트의 의사 재전송으로 인해 RTT가 갑자기 높아질 수 있습니다. 그 이유는 이전에 보낸 세그먼트의 RTO(재전송 시간 제한)가 만료되어 TCP에서 해당 세그먼트를 다시 전송하기 때문입니다. 전체 데이터 창을 보내기 전에 이와 같이 RTT가 증가하는 경우 송신 측에서는 전체 데이터 창을 다시 전송할 수 있습니다. F-RTO 알고리즘은 다음과 같은 동작을 통해 TCP 세그먼트의 의사 재전송을 방지합니다.

여러 세그먼트에 대한 RTO가 만료되면 TCP가 첫 번째 세그먼트만 다시 전송합니다. 첫 번째 승인이 수신되면 TCP가 새 세그먼트를 보내기 시작합니다(알려진 창 크기에서 허용된 경우). 다음 번 승인에서 시간 제한이 만료되었지만 다시 전송되지 않은 다른 세그먼트가 있는 것을 확인한 경우 TCP는 시간 제한이 잘못되었다고 판단하고 시간 제한이 만료된 다른 세그먼트를 재전송하지 않습니다.

결과적으로 무선 클라이언트가 한 액세스 지점에서 다른 액세스 지점으로 로밍하는 경우와 같이 RTT가 갑자기 일시적으로 증가하는 환경에서 F-RTO는 세그먼트의 불필요한 재전송을 방지하고 정상적인 전송 속도로 빠르게 돌아올 수 있습니다. SACK 기반 손실 복구 및 F-RTO는 GPRS 연결을 사용하는 연결에서 사용하는 데 가장 적합합니다.

Joseph Davies는 Microsoft의 기술 전문 저술가로 1992년부터 Windows 네트워킹을 주제로 글을 쓰거나 가르치고 있습니다. Microsoft Press에서 5권의 책을 저술한 그는 월간 TechNet Cable Guy 칼럼(영문)의 저자이기도 합니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..