TCP handshake Deep-dive (4)

Window Size

 

 

수신 버퍼: 네트워크에서 받은 데이터가 애플리케이션이 읽을 때까지 임시로 저장되는 공간.

수신 윈도우: 현재 수신 버퍼에서 남아있는 공간 크기.

-> 만약 수신자의 윈도우 크기보다 더 많은 데이터를 한 번에 보내면, 수신자는 데이터를 제대로 처리하지 못하고 손실이 발생할 수 있음

 

 

TCP 헤더에서 윈도우 크기(Window Size) 필드는 16비트(2바이트) 길이.

즉, 윈도우 크기 값의 최대 크기는 2^16 - 1 = 65,535 바이트(64KB - 1B).

(현재 테스트 사오항은 윈도우 스케일링이 사용되고있지 않음.)

 

 

 

수신측으로 데이터를 보내면 Window Size가 줄어든다. 수신버퍼에 클라이언트가 보낸 데이터가 보관되기 때문이다.

 

 

Zero Window

 

 

 

데이터 "수신자 (Receiver)" 의 "수신 버퍼 (Receive Buffer) 가 "가득 차서 "더 이상 "데이터를 "받아들일 수 없는 상태"

 

"신호 (Signal)": 제로 윈도우 상태는 수신자가 송신자에게 보내는 "명확한 "흐름 제어 "신호" 입니다. 수신자는 ACK (Acknowledgement, 확인 응답) 메시지를 통해 "윈도우 크기 (Window Size) 값" 을 "0으로 "설정하여 "송신자에게 "제로 윈도우 상태임을 "알립니다.

 

 

Zero Window Probe

 

 

• Zero Window Probe는 "송신자가 "수신자에게 "아주 "작은 "데이터 세그먼트 (일반적으로 1바이트)" 를 "주기적으로 "보내서, "수신자의 "윈도우 크기가 "0에서 "증가했는지 "확인하는 "일종의 "정찰 "행위" 입니다. 마치 택배 회사가 드론을 띄워 도로 정체 상황이 해소되었는지 주기적으로 확인해보는 것과 같습니다.
• Zero Window Probe "내용물": "시퀀스 번호만 담은 "빈 메시지": Zero Window Probe는 "실제 "데이터는 "거의 "포함하지 않고 (1바이트 정도의 "더미 데이터)", "주로 "TCP 헤더 정보 (특히 "시퀀스 번호") 만 "담아서 "보냅니다. 이는 "네트워크 "부담을 "최소화하면서, "수신자의 "상태를 "간단하게 "확인하기 위함" 입니다. 정찰 드론이 "최대한 "가볍게 "움직여서 "최소한의 "에너지로 "정찰 임무를 "수행하는 것과 같습니다.
• Zero Window Probe에 대한 "ACK 응답 "필수": Zero Window Probe를 받은 수신자는 "반드시 "ACK (확인 응답) 메시지를 "송신자에게 "응답해야 합니다. "윈도우 크기가 "0인 "상태에서도 "Zero Window Probe에 대한 "ACK 응답은 "예외 없이 "처리" 되어야 합니다.

 

 

그럼 얼마나 주기적으로 보내는건가?

 

최초 "전송 "간격" 은 "일반적으로 "재전송 시간 초과 (Retransmission Timeout, RTO) 값" 을 "사용합니다. RTO는 송신자가 데이터를 보내고 ACK 응답을 기다리는 최대 시간입니다. ACK를 못받을 경우 재전송 시간 초과 (RTO) 가 발생하고, Zero Window Probe 재전송 간격은 점점 늘어나겠지만, 결국 "TCP 연결은 "타임아웃 (Timeout) 되어 "강제로 "종료 (RST 연결 "재설정) 될 가능성이 매우 높습니다.

 

 

How TCP really works // Three-way handshake // TCP/IP Deep Dive - YouTube