안녕하세요? Yoo님,
답변이 늦었습니다. (답변이 늦어져 "자삭" 하셨군요 ^^*)
질문1)
TCP에는 Window Size가 존재하여 상대방에게 자신의 처리가능한 Buffer Size 만큼을 Window Size 값으로 알려주면 수신측에서는 해당 크기만큼은 Ack를 받지 않고 한번에 데이터를 송신할수 있다고 알고 있습니다.
모든 OS별 버전별로 크기가 틀리며 XP는 기본적으로 최대값이 64K이며, 윈도우7은 몇메가까지 늘어날수 있습니다.
또한 Congestion Window Size 라는 개념이 존재하며, 이또한 자기 자신이 한번에 보낼수 있는 데이터 사이즈 입니다.
1->2->4->8->16 식으로 값이 증가하며, Congestion이 발생시 (Timeout등) 사이즈가 줄어듭니다. (이 값또한 OS별로 상이함)
그렇다면 실제로 송신측이 한번에 보내는 데이터 사이즈는 min(rcv_win_size, cong_win_size) 값중 한개를 선택하여 사용합니다. 여기서 rcv_win_size의 단위는 Kbps이며, cong_win_size의 단위는 패킷의 개수인가요?
아니면 제가 설명한 글에서 틀린부분이 있다면 설명부탁드립니다.
답변>
Receive Window와 Congestion Window의 개념에 대해 정확하게 알고 계신듯 합니다. 다시 한번 정리하자면
TCP Receive Window (RWIN) : 수신측이 Ack 없이 한번에 data를 받을수 있는 크기. (가용 가능한 Buffer Size)
TCP Congestion Window (CWND) : 송신측이 Ack 없이 한번에 data를 보내는 크기. (Congestion Control을 위하여 계속 변동)
CWND 값은 1부터 시작하여 증가/감소 하게 되는데요, 해당 방법은 TCP 버전별로 다릅니다. (OS마다 다르다고 보시면 됩니다.)
말씀하신대로 송신측이 보내는 데이터 사이즈는 min(RWIN, CWND)이 되겠네요. 그리고 RWIN, CWND은 TCP Packet Header에 명시적으로 표기되며 각 값들은 Bytes 단위로 표시됩니다.
참고로 TCP Header가 표시할 수 있는 총 RWIN, CWND의 크기는 64K 이지만,
TCP option (TCP WINDOW SCALE OPTION - RFC 1323)을 사용하며, 여기에 표시된 크기(최대 2^14) 만큼 표기된 window size에 곱하여 사용됩니다. (64K * 2^14 = 약 1기가까지 사용가능)
질문2)
아래는 Wdows XP 환경에서 FTP로 파일을 다운로드 할때 Wireshark로 패킷을 잡은 화면입니다.
서버로부터 정확히 두개의 패킷을 다운받을때마다 Ack를 송신합니다.
테스트한 네트웍 환경은 물리적으로 매우 가까운 거리이며, 상황이 좋으므로 time out등의 congestion은 발생하지 않습니다.
제가 위에서 적은 글대로라면 Window Size 만큼 데이터를 송신하고 Ack를 받아야 하는거 아닌가요?
이유를 찾아보니 Delayed Ack라는 기능이 있어서 매번 패킷을 수신시 Ack를 송신하는것이 아니라 정해진 Timer 시간동안 (XP는 200ms)
한번 더 패킷이 수신되거나 Timeout이 발생하면 Ack를 보내게 되어 있습니다.
그렇다면 Window Size와 Delayed Ack간의 상관관계가 궁금합니다. 서로 상관관계는 없이 그냥 송신측은 상대방이 알려준 Window Size만큼
한번에 전송하려고 하겠지만 수신측에서는 Delayed Ack 설정값대로 패킷을 두번 수신시 Ack를 전송하는건가요?
또하나 궁금한점은 Windows 7에서 테스트하면 결과가 틀립니다. 똑같은 테스트 시 Windows 7에서는 4~5개 패킷을 한꺼번에
수신후에 Ack를 전송합니다. 아마도 Window Size 값이 틀린것과 관련이 있어 보이는데 정확한 이유를 모르겠습니다.
답변>
정확한 내용은 Packet을 분석해봐야 알겠습니다만, TCP Window Size는 응용프로그램이 설정이 가능한 값입니다.
제 경험상 A사의 FTP 프로그램으로 테스트를 했을때 Window Size를 약 8K로 사용하고 있는것을 본적이 있습니다.
해당 질문은 FTP 프로그램도 확인을 해봐야 할 것 같습니다.
또한, Delayed ACK의 개념은 수신측에서 자신이 보내야할 데이터가 있을때 (약 200ms를 기다림) 데이터와 함께 Ack를 보내는 개념으로 알고있습니다.
HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet\\Services Tcpip Parameters Interfaces {Adapter-id}TcpAckFrequency
의 값을 1로 변경하시고 테스트를 해보시면 Delayed ACK를 해제할수 있으므로 설정을 변경하고 테스트 해보시기 바랍니다.
위의 답변 1. 2번 보고 각각 질문이 있는데요.
1. RWND, CWND 둘다 TCP Header에 포함되는게 맞나요?
TCP Header에 들어가는 값은 상대방이 알려주는 RWND 정보이고, CWND는 패킷에 포함하여 전송하는
정보가 아니라 내부적으로 계산하여 보유하는 값이라고 알고 있었는데요. 그게 아닌가요?
2. 송신측에서는 min(RWND, CWND) 값을 선택하여 Window Size만큼 전송을 시도하겠지만 수신측에서는
Delayed Ack 의 설정된 카운트값 대로 Ack를 송신합니다.
즉, 송신측에서 Window Size가 크다면 큰만큼 전송을 시도는 하겠으나 수신측에서는 그와는 별개로 패킷
두개를 수신할때마다 Ack로 응답을 하는거죠. 전 그냥 이렇게 이해를 하고 있었는데요.
여기 Blog의 [LG U+와 KT의 YouTube 다운로드 속도 비교 시험 (3탄) - Windows 7을 이용한 시간대별
속도 테스트] 글에서 XP에서 다운로드 하는 캡쳐화면을 보더라도 대부분 2개의 패킷 송신후 Ack를 받고
있습니다. 그런데 이 화면에서도 그렇지만 제가 테스트한 경우에도 100% 모두 정확히 2개의 패킷후
Ack를 받은건 아니거든요.
이런 상황으로 유추해보면 송신측 Window Size와 수신측 Delayed Ack는 서로 별개로 동작하는것 같습니다.
예를들면 송신측 Window Size가 4(MSS)일때, 송신측은 4개의 패킷을 전송을 시도하겠죠. 두번째 패킷을
전송후에 세번째 패킷을 전송하려는 순간 상대방의 Ack가 먼저 도착해서 Window Size 재계산..
또다시 두개의 패킷 전송후 상대방의 Ack 수신.. 이런 패턴의 반복.
그러다보니 Ack가 약간 늦게 도착할수도 있고..
넷매니아즈님 생각은 어떠신지요?
2. Windows XP의 구현상(http://support.microsoft.com/kb/328890 참조) Delayed ACK는 아래와 같은 특징을 가집니다.
1) 수신된 이전 세그먼트에 대해 응답이 보내지지 않았을 경우
2) 한 세그먼트가 수신되지만 다른 세그먼트는 해당 연결에 대해 200밀리초 내에 도착하지 않는 경우
테스트하신 환경에서 Receiver는 첫번째 패킷을 전달받고 두번째 패킷을 바로 전달 받기때문에 1)번 항목에 부합되어 Ack를 즉시 전달하는것으로 보입니다.
말씀하신대로 ACK의 동작 방식은 Receiver의 Delayed ACK 설정에 따라 동작합니다.
단, 해당 ACK를 받은 Sender는 CWND를 계속 증가시키기 때문에 Delayed ACK의 동작에 따라 속도에 변화가 있을것 같지는 않습니다.
제가 위에 말을 좀 복잡하게 적어서 그렇지 저랑 의미는 거의 동일한것 같습니다.
그런데 맨 마지막 문구 [단, 해당 ACK를 받은 Sender는 CWND를 계속 증가시키기 때문에 Delayed ACK의 동작에 따라 속도에 변화가 있을것 같지는 않습니다] 의 의미는 Sender는 CWND를 계속 증가시키지만 상대방의 Delayed ACK의 동작에 따라 속도 변화는 없을거라는 의미가 맞으시죠?
지나가다 이글을 보고 질문드립니다 Windows XP와 Windows 7이 다른게 구현방식때문인가요?
Windows 7에서 XP와같은 환경으로 ACK응답을 할순없을까요