TCP Nagle 알고리즘(3) - Per-Send 예제

Nagle 알고리즘으로 인한 효과는 "TCP Nagle 알고리즘(2) - 예제"에서 살펴보았다. 그런데, "TCP Nagle 알고리즘(1) - 파라미터 설정"에서 설명하였듯이, OPNET TCP 모델에서 제공하는 "Nagle Algorithm" 속성값은 "Disabled"나 "Enabled" 외에 "Per-Send"로도 선택 가능하다. Per-Send 방식은 Optimized 버전이라고도 하며, Per-Segment 방식인 표준 Nagle 알고리즘을 개선한 것이다.
5,120bytes 크기의 데이터를 전송하는 경우, Per-Segment 방식과 Per-Send 방식의 동작을 예측해보면 다음과 같다.

 

이제 시뮬레이션을 통해 이 예측이 맞음을 확인해보도록 하자.
Per-Send 방식의 Nagle 알고리즘을 사용하였을 경우의 효과를 확인하기 위하여, "TCP Nagle 알고리즘(2) - 예제"에서 사용한 시나리오를 이용하여 5,120바이트 크기의 패킷을 1개 생성하도록 Task를 수정하고, 이 Task가 15초 간격으로 수행되도록 Profiles를 수정한다.
시뮬레이션을 수행한 후, Per-Segment 방식을 사용한 경우와 Per-Send 방식을 사용한 경우의 결과를 비교해보면, Server 노드에서 전송한 IP 패킷의 수는 동일한 것을 확인할 수 있다.

 

또한, 전송된 데이터의 양에는 차이가 없다. 다음 그림은 전송된 데이터 양이 동일함을 확인하기 위하여, Server 노드와 Discarder_2 노드간 링크에서 측정된 트래픽 양을 비교한 것이다.

 

전송한 패킷 수도 같고 데이터의 양도 같은데, Per-Send 방식에서는 무엇이 개선된 것일까? 그것은 TCP 레벨에서의 전달 지연(Delay)이다. Per-Send 방식에서는 전달해야할 하나의 데이터가 여러 세그먼트로 분할된 후 마지막 세그먼트가 MSS보다 작은 경우, Per-Segment 방식과는 달리 이전 세그먼트의 응답을 기다리지 않고 바로 전송하므로 전달 지연이 평균적으로 작다.
다음 그림은 이를 확인하기 위해서 Glaobal Statistics에서 측정한 TCP 데이터의 지연을 나타낸 것이다. Per-Send 방식(Optimized 버전)을 사용한 경우가 Per-Segment 방식(RFC 버전)을 사용한 경우보다 훨씬 낮은 평균 지연을 가지는 것을 확인할 수 있다.