소켓 프로그래밍 5 - Sliding Window

TCP Socket Buffer 와 Sliding Window

TCP 는 Send, Receive Buffer가 존재 합니다. UDP는 따로 존재하지 않는데....왜 그럴까요?
바로 Sliding Window 기법 때문입니다.

TCP Socket은 송, 수신측에 Socket Buffer를 관리하고 있습니다. 크기는 개발자가 정할 수 있구요.
위 그림처럼 데이터를 보내는 Socket의 Buffer를 Send Buffer라고 받는쪽을 Receive Buffer로 하고 설명을 하겠습니다.
위 그림은 마치 긴 창틀에 왼쪽부터 오른쪽으로 유리창을 밀어 넣는 것과 비슷하니 Sliding Window라고 합니다.
중간에 Network 부분은 생략하고 보내고 받는 2개의 Socket Buffer를 위 그림처럼 붙여서 생각해 봅시다.

TCP는, 보내는 데이터가 위 그림처럼 왼쪽에서 밀려 들어와서 오른쪽 수신측 Buffer로 밀려 들어가는 방법으로 데이터를 주고 받습니다. 그런데 보내는 쪽에서는 데이터를 계속 보내고 받는 쪽의 데이터가 오른쪽으로 빠져 나가지 못한다면 어떻게 될까요?

위 그림은 받는쪽의 Socket Buffer가 꽉 차서 보내는 쪽의 데이터가 더 이상 오른 쪽으로 전달되지 않는 상황이 됩니다.
TCP는 받는 쪽이 가용한 Socket Buffer 크기를 보내는 쪽으로 회신해 줍니다. 위 그림의 경우는 보내는 쪽은 전송되지 않은 데이터가 남아 있게 되고 가용한 Buffer의 크기도 줄어들겠죠.

이때에 보내는 쪽이 Buffer의 상태를 신경쓰지 않고 데이터를 보내 버리면 어떻게 될까요?

위 그림의 회색 크기 만큼의 데이터가 Socket Buffer로 밀려 들어가지 못하고 오류가 발생하게 됩니다.
TCP기반의 Socket Programming시에는 개발자는 항상 이 경우를 염두에 두고 처리해야 합니다.
가장 좋은 방법은 받는쪽이 Buffer에서 데이터를 매우 빠르게 꺼내 쓰는 것인데... 만약 받는 쪽이 서버측이고 클라이언트가 매우 많이 연결된 상태라면 쉽지 않겠죠.
TCP에서는 수신한 데이터는 가능한 빨리 Buffer에서 꺼내는 것이 좋고 보내는 쪽에서는 예외 경우를 항상 염두에 두고 개발해야 합니다.

이런 오류 상황에는 보통 EWOULDBLOCK 이나 EAGAIN 오류가 발생하게 됩니다.

UDP 는 왜 Send Buffer가 없나요?

TCP처럼 Sliding Window 방식이 아니고 수신측이 데이터를 받아서 처리 하는지 않하는지 신경쓸 필요가 없기 때문에 그냥 보내버리고 마는 거죠.

TO BE CONTINUED...