TCP Handshake에서 보이는 window size / wscale 값, win 값

TCP Window size란?

TCP에서 window size(win)는 수신 측이 “내가 지금 더 받을 수 있는 버퍼 여유”를 광고(advertise)하는 값입니다.

• win이 크다 → 수신 측 버퍼 여유가 많다 → 송신 측이 더 많이 보낼 수 있다
• win이 작다 → 수신 측 버퍼 여유가 적다 → 송신 측이 천천히 보내야 한다

즉, win은 네트워크 장비의 “대역폭” 같은 개념이 아니라, TCP 수신 버퍼(흐름 제어) 관점의 값입니다.

 

왜 wscale(Window Scaling)이 필요할까?

TCP 헤더의 window 필드는 16비트라서 최대가 65,535입니다.

요즘 환경(클라우드, DC, 고대역폭/지연 구간 등)에서는 64KB로는 부족할 수 있기 때문에, TCP는 Handshake(SYN / SYN-ACK)에서 Window Scale 옵션(wscale) 을 협상합니다.

• wscale 6 → 실제 윈도우 = win × 2^6 = win × 64
• wscale 9 → 실제 윈도우 = win × 2^9 = win × 512

여기서 핵심은 하나입니다.

Handshake 이후 tcpdump에 보이는 win 값은 “스케일 적용 전(raw) 숫자”로 찍히는 경우가 많다

그래서 wscale을 곱해서 실제 값을 계산해야 합니다. 

 

예시 tcpdump로 이해하기 (Handshake vs Handshake 이후 win 값)

이번 예시는 아래 tcpdump 캡처를 기준으로 설명합니다.

• 클라이언트(로컬): 172.22.215.151:60732
• 서버(원격): 104.18.26.120:443

 

1) Handshake에서 wscale 협상 확인

가장 먼저 봐야 하는 건 SYN / SYN-ACK에 들어있는 wscale 값입니다.

14:55:09.588686 IP 172.22.215.151.60732 > 104.18.26.120.443: Flags [S],  win 64240, ... wscale 7
14:55:09.600708 IP 104.18.26.120.443 > 172.22.215.151.60732: Flags [S.], win 65535, ... wscale 13

• 클라이언트 SYN에 wscale 7
  • 클라이언트가 광고하는 win 값은 이후 ×2^7(=×128)로 해석

• 서버 SYN-ACK에 wscale 13
  • 서버가 광고하는 win 값은 이후 ×2^13(=×8192)로 해석

즉, 이 연결에서는 양쪽 모두 Window Scale을 사용하고 있고, Handshake 이후에 보이는 win 숫자는 “raw 값”으로 찍힐 수 있으니 반드시 곱해서 해석해야 합니다.

 

2) Handshake 이후에 win이 갑자기 작아 보이는 구간

Handshake가 끝난 직후 라인을 보면, 클라이언트 ACK에 win 502가 찍힙니다.

14:55:09.600771 IP 172.22.215.151.60732 > 104.18.26.120.443: Flags [.], ack 1, win 502, ...

이건 클라이언트가 광고하는 수신 윈도우이고, 클라이언트 wscale은 7이기 때문에 

실제 수신 윈도우를 계산하면 다음과 같습니다.

rwnd = 502 × 2^7 = 502 × 128 = 64,256 bytes (약 62.8KB)

즉, win 502 자체만 보면 “502바이트?”처럼 보이지만, 실제로는 약 64KB 정도로 수신 윈도우를 광고한다고 보면 됩니다.

 

서버의 값도 마찬가지로,  win 16이 찍혔지만, 동일한 방식으로 실제 수신 윈도우를 계산하면 다음과 같습니다.

실제 rwnd = 16 × 2^13 = 16 × 8192 = 131,072 bytes (약 128KB)