<div id="readability-page-1" class="page"><div><h2 id="문제">문제</h2>
<p>TCP 서버와 연결은 되었는데 메시지를 보내도 응답이 없는 상황을 마주합니다. 네트워크에서 메시지를 캡처해보면 메시지 자체는 정상 전송되었고, TCP 프로토콜의  ACK 역시 정상적으로 수신된 것으로 보아 서버의 TCP 계층까지는 분명 메시지가 잘 전달되었습니다.  </p>
<p><img src="https://velog.velcdn.com/images/joosing/post/65dcba21-6389-4323-b79c-b3d588aa3424/image.png"></p>
<p>여기서 문득 궁금해 집니다. ‘서버가 살아있으니까 연결은 성공했는데 내부의 수신 태스크가 메시지를 정상적으로 읽고는 있는걸까?’</p>
<h2 id="아이디어">아이디어</h2>
<p>어떻게 하면 TCP 서버가 내가 보낸 메시지를 읽고 있는지 확인할 수 있을까요? 조금만 생각해보니 간단한 아이디어가 떠오릅니다. TCP 프로토콜에는 Receive Window 라는 메커니즘이 존재합니다. Receive Window 란, 나의 수신 버퍼 가용 공간을 상대측에게 알려서 상대방이 수신 버퍼가 넘치도록 메시지를 보낼 수 없도록 하는 하나의 장치입니다. TCP 는 이를 통해 버퍼가 넘쳐서 데이터 손실되는 것을 방지합니다. Receive Window 는 원격지로부터 데이터를 수신하면 가용 공간이 줄어들고, 애플리케이션에서 데이터를 읽어가면 다시 텅빈 상태로 돌아옵니다. 따라서 내가 메시지를 보냈을 때 서버의 ACK 에 기록된 Receive Window 크기가 계속 줄어들면 서버가 내 메시지를 읽고 있지 않는 비정상 상태인 것입니다. 반면에 Receive Window 가 일정 크기를 유지하고 있다면 내 메시지를 반복해서 읽어가고 있는 것입니다. </p>
<p><img src="https://velog.velcdn.com/images/joosing/post/68893459-94c5-4ced-8610-ce11384ca292/image.png"></p>
<h2 id="확인하기">확인하기</h2>
<p>이제 위의 아이디어를 실제로 확인해 보겠습니다. 문제가 있는 서버로 반복해서 메시지를 보내고, 서버의 TCP ACK 에 실려있는 Receive Window 값이 계속해서 줄어드는지, 아니면 일정 수준을 유지하는지 확인해 보겠습니다. 아래는 Wireshark 로 패킷을 캡처한 결과입니다. 4번 패킷이 7 바이트 데이터를 서버로 전송하고, 5번 TCP 응답의 Receive Window 크기는 17520 바이트입니다. 이어서 다시 6번 패킷이 7 바이트 데이터를 서버로 전송하고, 7번 TCP 응답에는 동일하게 17520 바이트가 수신됩니다. Receive Windows 가 일정크기로 유지되고 있음을 확인할 수 있습니다. 결론적으로 서버 애플리케이션에서 내가 전송한 데이터를 읽어 가서 Receive Window 가 일정 크기로 유지되고 있다는 사실을 확인할 수 있었습니다.</p>
<p><img src="https://velog.velcdn.com/images/joosing/post/007aa2b7-a557-4a31-a8ee-2e9ead4cb8df/image.png"></p>
<p>간혹 Receive Window 가 줄어드는 경우도 확인할 수 있었는데 이때는 서버 애플리케이션이 조금 늦게 데이터를 읽어가기 때문이라고 추측할 수 있습니다.</p>
<p><img src="https://velog.velcdn.com/images/joosing/post/aa5c3e31-6cd4-49dc-b854-2bbd51c56dc3/image.png"></p>
<h2 id="마치며">마치며</h2>
<p>TCP 클라이언트의 오류 상황 덕분에 의미있는 실험을 할 수 있었습니다. 그나저나 TCP 서버는 데이터를 수신하면서 왜 응답을 하지 않는걸까요? 이제 서버를 개발한 회사에 메일을 보내봐야 겠습니다.</p></div></div>

Joo's Work

JooSing

문제
TCP 서버와 연결은 되었는데 메시지를 보내도 응답이 없는 상황을 마주합니다. 네트워크에서 메시지를 캡처해보면 메시지 자체는 정상 전송되었고, TCP 프로토콜의  ACK 역시 정상적으로 수신된 것으로 보아 서버의 TCP 계층까지는 분명 메시지가 잘 전달되었습니다.  
여기서 문득 궁금해 집니다. ‘서버가 살아있으니까 연결은 성공했는데 내부의 수신 태스크가 메시지를 정상적으로 읽고는 있는걸까?’
아이디어
어떻게 하면 TCP 서버가 내가 보낸 메시지를 읽고 있는지 확인할 수 있을까요? 조금만 생각해보니 간단한 아이디어가 떠오릅니다. TCP 프로토콜에는 Receive Window 라는 메커니즘이 존재합니다. Receive Window 란, 나의 수신 버퍼 가용 공간을 상대측에게 알려서 상대방이 수신 버퍼가 넘치도록 메시지를 보낼 수 없도록 하는 하나의 장치입니다. TCP 는 이를 통해 버퍼가 넘쳐서 데이터 손실되는 것을 방지합니다. Receive Window 는 원격지로부터 데이터를 수신하면 가용 공간이 줄어들고, 애플리케이션에서 데이터를 읽어가면 다시 텅빈 상태로 돌아옵니다. 따라서 내가 메시지를 보냈을 때 서버의 ACK 에 기록된 Receive Window 크기가 계속 줄어들면 서버가 내 메시지를 읽고 있지 않는 비정상 상태인 것입니다. 반면에 Receive Window 가 일정 크기를 유지하고 있다면 내 메시지를 반복해서 읽어가고 있는 것입니다. 
확인하기
이제 위의 아이디어를 실제로 확인해 보겠습니다. 문제가 있는 서버로 반복해서 메시지를 보내고, 서버의 TCP ACK 에 실려있는 Receive Window 값이 계속해서 줄어드는지, 아니면 일정 수준을 유지하는지 확인해 보겠습니다. 아래는 Wireshark 로 패킷을 캡처한 결과입니다. 4번 패킷이 7 바이트 데이터를 서버로 전송하고, 5번 TCP 응답의 Receive Window 크기는 17520 바이트입니다. 이어서 다시 6번 패킷이 7 바이트 데이터를 서버로 전송하고, 7번 TCP 응답에는 동일하게 17520 바이트가 수신됩니다. Receive Windows 가 일정크기로 유지되고 있음을 확인할 수 있습니다. 결론적으로 서버 애플리케이션에서 내가 전송한 데이터를 읽어 가서 Receive Window 가 일정 크기로 유지되고 있다는 사실을 확인할 수 있었습니다.
간혹 Receive Window 가 줄어드는 경우도 확인할 수 있었는데 이때는 서버 애플리케이션이 조금 늦게 데이터를 읽어가기 때문이라고 추측할 수 있습니다.
마치며
TCP 클라이언트의 오류 상황 덕분에 의미있는 실험을 할 수 있었습니다. 그나저나 TCP 서버는 데이터를 수신하면서 왜 응답을 하지 않는걸까요? 이제 서버를 개발한 회사에 메일을 보내봐야 겠습니다.

TCP 서버가 내 메시지를 읽고 있는걸까요?

댓글