[Protocol] Nagle Algorithm

* Nagle Algorithm?

Server의 ACK를 받기 전까지 출력 버퍼에 보낼 패킷을 쌓고 ACK를 받으면 버퍼에 있던 패킷을 한번에 전송하는 TCP 통신 알고리즘

 

* TCP Flow Control

TCP 패킷 흐름 제어 방식에는 Stop-and-wait, Sliding Window 등이 있다.

 

1. Stop-and-wait

Stop-and-wait 같은 경우는 ACK를 수신 받아야 다음 패킷을 보낼 수 있어서 비효율적이다.

 

2. Sliding Window

쉽게 설명하면 Window 사이즈만큼 한번에 패킷을 전송할 수 있는 방법이다. Window 사이즈는 동적으로 변한다.

* 송신했으나 아직 확인 응답을 못받았으면 Window에서 나머지만큼만 전송이 가능하다.

(Window 7칸 중 2개 보냈는데 응답이 없으면 다음에는 2개만큼 송신 측 Window 사이즈 줄어들어 5개만 송신 가능, 응답을 받으면 그만큼 Window 사이즈 증가, 최대 사이즈는 증가하지 않는다.)

 

* Silly Window Syndrome?

수신측에서 데이터를 작은 크기로 받게 된다면 지속적으로 데이터를 조금씩만 주고 받게된다. 결국 실질적인 윈도우 사이즈가 줄어들게 되어 효율이 저하되는 현상이다.

 

3. Nagle Algorithm

위에서 언급한 대로 처음 패킷을 보내고 ACK를 받을 때까지 버퍼에 쌓고, ACK를 받으면 한번에 보낸다.

이 방법은 Silly Window Syndrome을 해결할 수 있다고 한다(?)

 

그런데 뚜둔

 

설명만 보면 Sliding Window와 Nagle Algorithm의 차이가 모호한것 같다. 비스무리한것...

 

차이점은 다음과 같다!

 

Sliding Window는 수신측의 Window 사이즈만큼 연속적으로 패킷을 보낼 수 있다. ACK는 Window 사이즈에 영향을 줄 뿐이다. (물론 수신측 Window 사이즈가 0이되면 ACK를 기다린다.)

 

반면 Nagle Algorithm은 ACK를 기다려야 패킷을 보낼 수 있다. 다만 Stop-and-wait과는 다르게 한번에 여러개를 묶어서 보낼 수 있다는 것이다.

 

요약하자면

Sliding Window : Window 사이즈만큼 연속으로 패킷 보내기 가능

Nagle Algorithm : 한번에 여러 데이터를 묶어서 보냄

 

자, 그럼 Nagle Algorithm은 어떻게 Silly Window Syndrome을 회피할 수 있는 것일까?

 

Silly Window Syndrome은 데이터를 적게 보내는 현상이 계속 이어지는 것이다.

 

그렇다면 당연히 한번에 여러 데이터를 보냄으로서 데이터를 적게 보내는 현상을 회피할 수 있는 것이다!