HTTP 에게 신뢰성을 제공하는 TCP 이야기 - (1) Receive Window

시작하며

TCP 프로토콜은 HTTP와 같은 Application Layer 프로토콜에게 신뢰성있는 채널을 제공합니다. 앞으로 몇 개의 글을 통해 TCP가 제공하는 신뢰성 서비스에는 어떤 것들이 있는지 자세히 정리해 보려고 합니다.

1. Receive Window - TCP는 상대방이 들을 준비가 되면 말합니다.
2. Sequence Number - TCP는 상대방이 알아듣도록 순서대로 말합니다.
3. Retransmission - TCP는 상대방이 잘 들었는지 확인하고 다시 말해줍니다.
4. CheckSum - TCP는 상대방의 말을 오해하고 있는건 아닌지 확인합니다.
5. Connection Oriented - TCP는 모든 것에 앞서 상대에게 대화가 가능한지 예의 바르게 묻습니다.

이렇게 글을 작게 나누어서 쓰는 이유는 한 번에 긴 글을 다 쓰려니 글쓰기를 자꾸 포기하게 되어 조금씩 나누어 쓰려고 노력합니다 😆

오늘은 먼저 Receive Window에 대해 정리해봅니다.

1. Receive Window

TCP는 상대방이 들을 준비가 되면 말합니다.

프로토콜 헤더

TCP 프로토콜 헤더에는 Window Size 라는 필드가 있습니다.

Window Size 역할

Window Size란 수신측에서 현재 수신 가능한 데이터 버퍼의 크기를 상대방에게 알리고, 상대는 그 이상의 데이터를 보내지 않도록 하는 장치라고 할 수 있습니다. 다음과 같이 말이죠.

Window Size가 전송하려는 데이터 보다 작으면

TCP는 전송하려는 데이터가 수신 측의 Window Size 보다 큰 경우 수신측 버퍼가 비워져서 전송하려는 데이터를 모두 수신 가능한 상태가 될 때 까지 기다립니다.

그래서 TCP에서는 무리한 전송으로 인한 버퍼 오버플로우 대신 전송 지연이 발생할 수 있습니다.

코딩을 하며 느낄 수 있는 영향

대게 위에서 설명한 것들은 TCP 프로토콜 단에서 처리되기 때문에 프로그램을 작성하는 우리에게 거의 느껴지지 않습니다. 물론 실시간성을 중요하게 생각하여 전송 지연을 직접 측정해보는 경우가 아니라면 말이죠.

우리는 다음과 같은 극한의 상황이 발생하면 프로그래밍을 하다가 Receive Window의 영향을 느낄 수 있습니다.

• 송신측에서 Blocking 소켓을 사용하고 있다.
• 수신측에 문제가 생겨 데이터를 읽지 않고 있다. (수신 쓰레드 Lock 등)
• 송신측에서는 계속 데이터를 보내고 있다.
• 수신측 Window가 Full이 되어, 송신측 TCP 버퍼에 데이터가 쌓이기 시작한다.
• 송신측에서 계속 소켓으로 send() 요청을 한다.
• 송신측 TCP 버퍼도 Full 상태가 된다.
• 이어지는 송신측 send() 호출은 수신측이 살아날 때 까지(데이터를 읽을 때 까지) Blocking 된다.

정리

이렇게 TCP는 Receive Window라는 개념을 사용해 상대방이 데이터를 받을 준비가 되었을 때만 데이터를 보냄으로 신뢰성있는 채널을 만들어갑니다.

다음에는,

다음에는 TCP의 Sequence Number에 대해 정리합니다.

TCP는 상대방이 알아듣도록 순서대로 말합니다.