출처: https://japan.zdnet.com/article/35086196/ 

Microsoft 는네트워크 성능을 올리기 위해  "Windows 10" 와 "Windows Server 2016"의 TCP/IP 스택을 새롭게 시도하고있다 .

도입 된 개선 내용은 TCP 연결을 설정하는 데 걸리는 시간을 단축하고, TCP의 대역폭 상승의 개선, 패킷 손실 복귀에 걸리는 시간 감소를 실현하도록 설계되어 있다.

구체적으로는 Windows의 "Redstone"릴리스에는 다음의 내용이 포함되어 있다.

• TCP 연결을 설정하는 데 걸리는 RTT를 제로로 하는 "TCP Fast Open"(TFO) (RFC 7413)
• TCP 슬로우 스타트를 고속화 하는 "Initial Congestion Window 10"(ICW10)을 기본적으로 사용
• 패킷 손실에서 복귀를 앞 당기는 "TCP Recent ACKnowledgement"(RACK) (상태가 Experimental인 인터넷 초안)
• 재전송 타임 아웃 응답을 개선하는 'Tail Loss Probe "(TLP) (상태가 Experimental 인터넷 초안)
• 백그라운드 연결을 위한 "TCP LEDBAT"(RFC 6817)

Microsoft에서 제공하는 개선 내용이라고 암시하고 있지만, 사실 이 대부분은 Google이 제안하고 있는 기술이다. 다음은 이 기술이 어떻게 개선으로 이어질지를 간단하게 정리해 본다.

TCP Fast Open은 Google이 제안한, Internet Engineering Task Force(IETF)의 RFC 7413(상태 Experimental)를 기반하는 기술이다.

TFO는 SYN 및 SYN-ACK 패킷에서 데이터를 전송하고 연결 핸드 셰이크 확립 시에 수신 측에서 사용하는 것이 허락된다.

이를 통해 데이터의 송수신을 시작하기 전에 3 방향 핸드 셰이크가 필요한 일반 TCP에 비해 RTT 1 회분의 시간을 절약 할 수 있다.

이것이 그다지 크다고 들리지 않을지도 모르지만, 평균 지연 시간이 40밀리초 대의 인터넷에서 단시간 연결을 많이 하는 웹 페이지의 전송에 매우 큰 차이가 온다. 많은 요소가 포함된 웹 페이지에서는 이 기능으로 상당한 시간을 절약 할 수 있다.

Windows 10의 "Anniversary Update"는 TFO에 대응하는 클라이언트의 구현이 포함되어 있다. 브라우저 "Microsoft Edge'는 "About : Flags" 설정 페이지에  TCP Fast Open을 활성화 하는 설정 항목이 추가 될 예정이다(기본적으로 비활성화).

Microsoft에 의하면, 궁극적으로는 미래의 Windows 10에서 "Internet Explorer"과 Edge에서 이 기능을 기본적으로 활성화 할 예정이라고 한다.

앞으로 Microsoft는 회사의 Web 서버 「IIS」에도 서버 측 구현을 통합 할 계획이다. 서버 측의 구현은 기본적으로 비활성화 된다.

Edge에서 TFO를 사용할지 여부를 설정하려면 "about : flags '나 'about : config" 페이지에서 "TCP Fast Open을 사용" 확인 란을 선택하거나 "netsh int tcp set global fastopen =" 명령을 사용한다.

Initial Congestion Window 10은 Google이 제안한 「RFC 6928」에 근거한다.

TCP 흐름 제어는 역사적으로 초기 window 크기를 최대 4세그먼트 (약 4K 바이트)로 하였다.

대부분의 웹 트랜잭션은 매우 짧기 때문에 초기 window 크기는 흐름이 완료 될 때까지 걸리는 시간에 큰 영향을 미친다.

인터넷의 통신 속도는 극적으로 고속화 하고 있지만, TCP의 초기 window 크기는 지금까지 변경 되지 않았다.

Google은 TCP 슬라이딩 윈도우의 초기 크기를 최소한 10세그먼트 (약 15K바이트)까지 늘릴 것을 제안하고 있다.

Microsoft는 이 Google의 제안을 구현했다. Windows 10 및 Server 2016에서 기본값은 10 세그먼트로 변경된다.

이러한 변경으로 인해 슬로우 스타트 시의 통신 속도는 기존의 기본값인 4세그먼트의 경우보다 개선된다.

작은 크기의 데이터 스트림은 현재의 약 2 분의 1의 시간으로 보낼 수 있게 될 것이다.

Tail Loss Probe (TLP)도 Google이 제안하고 있는 인터넷 초안의 하나이며, TCP 패킷 손실이 발생했을 때의 복귀 속도를 개선하도록 설계되어 있다.

TLP는 패킷 손실 발생 시 재전송 타임 아웃에 의한 재전송이 아니라 Fast Retransmit를 사용하여 패킷 손실에서 복귀를 앞당긴다.

TLP는 연결에 보내지 않은 데이터가 남아 있어 ACK를 받지 못한 경우 RTT의 2배의 시간이 경과 할 때마다 하나의 패킷을 전송한다.

이 때 전송되는 패킷(로스 프로브)은 새로운 패킷도 재전송 패킷도 괜찮다. 연결의 끝에 있는 패킷이 손실된 경우 손실 프로브에 대한 ACK가 수신되면 선택적 ACK(SACK) 및 포워드 ACK(FACK)을 사용하여 Fast Recovery가 트리거 되고 비용이 큰 재전송 타임 아웃 발생이 방지 된다.

Windows에서는 TLP는 RTT가 10 밀리초 이상 연결에서만 활성화 된다. 이것은 낮은 대기 시간 연결에서 불필요한 재전송을 피하기 위해서 이다.

TLP가 가장 유리하게 작용하는 시나리오는 광역 네트워크에서 웹의 짧은 데이터를 전송하는 경우이다.

Recent ACKnowledgement (RACK) 는 TCP에 새로운 패킷 손실 검출 알고리즘을 구현하기 위해 Google이 제안한 인터넷 초안이다.

이 알고리즘은 데이터 손실이 발생했는지 여부를 확인하기 위하여 중복 ACK를 계산하는 대신 패킷의 타임 스탬프를 조사한다.

Windows에서는 Windows 10에서도 Windows Server 2016에도 RTT가 10 밀리초 이상 연결에서만 RACK가 활성화 된다.

이것은 낮은 대기 시간 연결에서 불필요한 재전송을 피하기 위해서 이다. RACK 또한 SACK의 협상에 성공한 연결에서만 사용된다.

마지막 요소인 Windows Low Extra Delay BAckground Transport(LEDBAT)는 연구 기관 및 BitTorrent가 제안한 RFC 6817에 근거한다. 이것은 종점 사이에서 사용할 수 있는 대역폭을 최대한 많이 이용하면서, 이것에 의한 큐잉 지연을 최소화 하는 것을 목표로 지연 정보에 기반한 혼잡 제어 알고리즘이다.

이것은에 의해 다른 TCP 연결을 방해하지 않으면서 백그라운드 연결이 가능하게 된다. Windows LEDBAT는 실험적인 "Windows TCP Congestion Control Module"(CCM)로 구현되어 있다.

(LEDBAT가 Windows Server 2019에서 정식으로 들어왔다. Top 10 Networking Features in Windows Server 2019: #9 LEDBAT – Latency Optimized Background Transport )

Windows LEDBAT는 데이터를 백그라운드로 보내고 다른 TCP 연결을 방해하지 않도록 되어있다. LEDBAT은 사용되지 않은 대역만을 소비하도록 함으로써 이를 실현하고 있다.

LEDBAT가 다른 TCP 연결이 대역폭을 소비하고 있는지를 나타내는 지연의 증가를 감지하면 다른 TCP 연결에 대한 간섭을 방지하기 위해 자신의 대역폭 소비를 감소시킨다.

지연이 감소하면 LEDBAT 다시 사용 대역폭을 늘리고, 사용되지 않은 대역폭을 소비하게 된다. 이것은 BitTorrent 및 기타 우선 순위가 낮은 네트워크에서 사용하기에 이상적인 알고리즘이다.

전체적으로 Windows 사용자는 즉시 네트워크 성능 향상을 느낄 수 있게 될 것이다. 이러한 새로운 기술은 아직 구현 과정에 있기 때문에 미래는 더욱 성능이 향상 될 것으로 예상된다.