TCP Nagle 알고리즘(2) - 예제

512bytes 크기의 데이터가 30ms 간격으로 발생하며 TCP Ack를 응답받는데 걸리는 시간이 충분히 큰 경우, TCP Nagle 알고리즘을 사용하지 않은 경우와 사용한 경우의 동작을 예측해보면 다음과 같다.

 

이제 시뮬레이션을 통해 이 예측이 맞음을 확인해보도록 하자. 다음 그림은 TCP Nagle 알고리즘의 동작을 시험하기 위해서 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

 

Nagle 알고리즘을 사용하지 않은 경우와 사용한 경우의 비교를 위하여, Server 노드와 STA 노드의 "Nagle Algorithm" 속성값을 다음 그림과 같이 Disabled로 설정한 시나리오와 Enabled로 설정한 시나리오를 작성한다.

 

시뮬레이션을 수행한 후, Nagle 알고리즘이 실제로 수행되었음은 다음 그림처럼 TCP 송신측(이 시나리오에서는 Server 노드)에서 측정된 "Send Delay (Nagle's) (sec)" 결과항목값을 관찰하여 확인할 수 있다. ("Nagle Algorithm" 속성값을 Disabled로 설정한 시나리오에서는 값이 기록되지 않는다)

 

"Send Delay (Nagle's) (sec)" 결과항목값은 Nagle 알고리즘의 수행여부를 확인하는데는 유용하지만, Nagle 알고리즘의 효과를 확인하기에는 충분하지 않다.
Nagle 알고리즘으로 인한 효과를 확인하기 위해서, Server 노드에서 전송한 IP 패킷의 수를 비교해보면 Nagle 알고리즘을 사용한 경우에 네트워크로 내보낸 패킷의 수가 다음 그림처럼 크게(이 시나리오에서는 약 1/3 수준으로) 감소하였음을 확인할 수 있다.

 

패킷의 수는 이처럼 크게 감소하지만 전송된 데이터의 양에는 차이가 없다. 다음 그림은 전송된 데이터 양이 동일함을 확인하기 위하여, STA 노드의 TCP 단에서 수신한 트래픽 양을 비교한 것이다.

 

동일한 양의 데이터를 훨씬 작은 수의 패킷으로 전달 할 수 있다면, Nagle 알고리즘을 사용하는 것이 항상 유리한 것일까? 그렇지는 않다. Nagle 알고리즘은 네트워크로 내보내는 패킷의 수를 줄이기 위해 작은 크기의 패킷 전송을 제한하므로, 지연(Delay) 측면에서는 불리하다. 다음 그림은 이를 확인하기 위해서 STA 노드에서 측정한 TCP 데이터의 지연을 나타낸 것이다. Nagle 알고리즘을 사용한 경우가 사용하지 않은 경우보다 큰(이 시나리오에서는 2배 이상) 지연을 가지는 것을 확인할 수 있다.