LANShare 파일 전송 프로토콜 구축 - 문제점 발생

이전에 설계 했던 프로토콜의 문제점이 한가지 있다.

이런 형태로 정보를 송신할 경우 다음과 같은 문제가 생긴다.

 

데이터를 보내는건 좋은데, 문제점이 소켓 내부적으로 처리하는 방법이 다르다.

TCP 통신에서는 Application이 메세지를 보낸다고(Send) 하더라도 바로 전송되는 것이 아니다.

소켓 버퍼(Send Socket Buffer) 라는 버퍼에 쌓인 후 적절한 시기에 상대방에세 메세지가 전송되고 버퍼가 지워진다.

 

받는쪽에서도 마찬가지로 메세지가 오면 일단, 소켓버퍼에 저장된 후 Application에서 Read 함수를 호출 할 때 소켓 버퍼에 쌓인 메세지를 읽어들인다.

 

그럼 저런식으로 보낸 메세지가 만약 8바이트라고 가정해보자.

1. 앞에 4바이트는 명령어 정보

2. 뒤에 4바이트는 추가적인 정보

 

위 사진에서 보다 싶이, 서버쪽에서 Send를 하면 해당 데이터가 송신버퍼에 어느정도 쌓이면 그때 한번에 전송한다.

물론 받는 쪽도 동일하게, 수신버퍼에 쌓였다가 원하는 데이터 크기만큼 수신한다.

만약 수신측에서 1024바이트 만큼 Recv 했을 때, 수신버퍼에 500밖에 없으면 500만 불러온다.

 

물론 보낼 때, 받을 때도 TCP 같은경우 Ack 라는것이 존재해서 내부적으로 갖고 있는 프로토콜이 있다.

송신자는 수신자가 수신가능한 만큼의 데이터만 보낼 수 있는데, 이걸 "슬라이딩 윈도우 프로토콜" 이라고 부른다.

이러한 슬라이딩 윈도우 프로토콜 덕에 TCP 통신에서 흐름제어가 가능하다.

 

사실 저기서 핵심은 슬라이딩 윈도우 인데, 창문이 슬라이딩한다고 보면된다.

TCP 연결이 되면, 통신을 할 때 서버/클라이언트 서로의 호스트에게 윈도우 크기(Window Size)를 알려주게 된다.

그럼 상대방은 그만큼의 양을 한번에 전송하고,

상대방이 다 처리했다면 다음 데이터를 전송한다.

이게 끝이다.. 

 

이 부분을 제대로 인지를 안 한 상태에서

"뭐 앞에 명령어 주고 뒤에 정보 주면 그 만큼 보내면 받는쪽도 딱 그 만큼 받겠지?"

라는 멍청한 생각을 했다.

덕분에 공부 다시했다 .. 

 

 

패킷이 송수신 될 때, 와이어샤크를 떠보면 다음과 같다.

 

송신측과 수신측의 송수신버퍼의 크기가 동일하다면 위에 사진처럼 모든 데이터를 전송했을 때 TCP 윈도우 크기가 0으로 나타난다.

 

이거에 대한 내용은 추가적으로 Wireshark를 써보면서 다음 포스팅에 해볼 예정이다.