TCP/IP Protocol 03

TCP/IP Sliding Window

TCP/IP Protocol Suite중의 하나인 TCP는 TCP Host간에 효율적인 데이터 전송을 위하여 "Window"라고 부르는 Buffer를 이용한다. Window는 TCP/IP통신을 원하는 컴퓨터(일반적으로 Host라고 부른다)가 송신, 혹은 수신할 수 있는 size를 가리켜 준다.

이러한 window라는 것을 이용하여 호스트간에 전송을 하고 받는 과정중에, 네트워크의 트래픽 혹은 호스트의 불안한 요소등 여러 가지 원인에 의하여 전송되는 데이터의 손실이 생길 수 있는 경우가 발생하게 된다. 반대로 안정적인 네트워크 상황하에서 보다 많은 데이터를 전송할 수 있음에도 TCP가 제공하는 가장 큰 특징중의 하나인 "확실한 전송"이라는 책임 때문에 오히려 비효율적인 전송을 하게 되는 경우도 있게 될 것이다. 이러한 요소들을 모두 고려하여 가장 효율적인 데이터 전송방법으로써 "Sliding Windows" 라는 기법을 사용하여 호스트 간의 통신에서 최적의 성능을 제공할 수 있게 된다.

그러면, 실제로 호스트간의 TCP/IP통신 중에서 "TCP Sliding windows"라는 기법이 무엇인지, 어떻게 동작을 하는지 차근차근 접근해 보도록 하자.

TCP/IP를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다. 하나는 보내기 위한 window, 또 다른 하나는 받기 위한 Window이다.
호스트들은 실제 데이터를 보내기 전에 먼저 "TCP 3-way handshaking"을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다. 상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

 "A"컴퓨터가 "B"컴퓨터에게 10K byte size의 데이터를 전송하려 한다고 가정을 해 보자.

또, 이 컴퓨터의 "window size"는 8K이고, "TCP Segment Size"는 1K라고 가정을 한다. 사실 이것은 우리가 가장 많이 사용하는 Ethernet환경에 최적화된 size이기 때문에 NT는 기본적으로 위와 같은 windows와 segment size를 이용한다."TCP Segment Size"는 Application이 만든 데이터를 TCP가 받아서 IP에게 전달해서 통신을 하려고 할 때, IP에게 전달해 주는 데이터 패킷의 크기이다. 결과적으로는 실제 데이터를 TCP가 보다 작은 크기로 나누게 되는데, 이 때 나누게 되는 크기를 가리켜서 "TCP Segment Size"라고 부른다.예제의 경우와 같을 때, "A"컴퓨터는 "B"컴퓨터에게 데이터를 전송하기 위해서 먼저 10K크기의 데이터를 1K크기로 나누게 된다. 당연히 10개의 패킷으로 데이터가 나뉘게 될 것이다. TCP는 1K로 나눈 데이터마다 순서를 붙이게 된다. 1번부터 10번까지 번호를 붙이고, 1번부터 데이터 전송을 시작하게 된다.

TCP의 특징은 "신뢰성있는 전송"을 보장한다는 데 있다. 1번을 보내고, "A"컴퓨터는 "B"컴퓨터로부터 잘 받았다는 확인 메시지(Acknowledgement)를 받을 때까지 기다리게 된다. 마침내 Acknowledgement 메시지가 오면 "A"컴퓨터는 그 다음 순서인 2번 데이터를 전송한다. 생각하기에는 당연한 이야기고 그런대로 쓸 만한 방법이라고 생각할 수도 있겠지만 지극히 비효율적인 방법이다. "A"컴퓨터는 1번 데이터를 보내고 나서도 충분히 다음 데이터를 보낼 여유가 있지만, 응답을 받을 때까지 기다리고만 있어야 한다는 것이다. 만일 회선상의 문제가 있어서 Ack신호가 더욱 지연된다면 그 결과는 당연히 영 아닌 상태의 네트워크 통신을 지켜 봐야만 할 것이다. 이러한 문제점을 해결하기 위해서 TCP는 데이터를 낱개단위로만 처리하지는 않는다는 것이며, 그때 한꺼번에 전송하는 데이터의 크기를 바로 "Window Size"라고 부르는 것이다.
호스트는 자신이 보내야할 전체 데이터 중에서 사용가능한 Window size만큼 데이터를 전송하기 시작한다.

위의 예제에서 window size는 8K이다. 1번부터 8번까지 순차적으로 계속해서 데이터를 내 보내게 되는 것이다. 그리고 나서 이 호스트는 상대방의 응답을 기다리게 된다. 단순하게 생각해도 일단은 하나씩 보내고 응답을 기다리는 것보다는 효율적인 방법일 것이다. 성공적으로 통신이 되어서 상대방으로부터 응답이 온다면 그때 "A"호스트는 나머지 남은 9번, 10번의 데이터를 전송한다.이것이 "TCP Sliding Windows"라는 기법이다. window size만큼 데이터를 전송하고, 상대방으로부터 Ack신호가 올 때까지 기다렸다가 Ack신호가 오면, window를 이동(Slide)시켜 다음 순서의 TCP데이터를 전송하는 방식을 말한다.

하지만, 역시 이것만으로는 뭔가 비효율적인 면이 여전히 남아있다. 1번부터 8번까지 데이터를 전송하고 상대방으로부터 1번부터 시작하여 자신이 보낸 데이터의 마지막인 8번까지의 데이터에 대한 Ack신호가 올 때까지 기다려야 한다면 어리석은 일이 아닐 수 없다. 우리가 생각하는 정도는 이미 TCP/IP를 개발한 개발자들도 충분히 고려했던 부분이었기에 그것에 대한 생각도 물론 했을 것이다. 그렇기 때문에 보다 효율적인 방법을 채택했다.

일단 보내는 쪽의 TCP는 window size만큼 한꺼번에 데이터를 전송하고, 받는 쪽에서의 Ack신호가 오면 오는대로 바로바로 window를 Sliding시키는 방법이 그것이다. 다시 말하면 굳이 자신이 발송한 마지막 데이터에 대한 Ack신호가 오지 않더라고 일단 그 전의 데이터에 대한 Ack가 오게 되면 그만큼은 여분의 window size가 생긴 것이기 때문에 추가로 더 전송할 여유가 생겼다는 의미이다.

window가 이동한 그림을 볼 수 있다.

예제의 경우는 받는 쪽에서 2번까지의 데이터를 잘 받았다는 Ack신호를 발송해 주게 되면 그때 "A"컴퓨터는 1,2번 데이터는 제대로 전송해야 할 책임을 완수했기 때문에 window를 이동시켜서 그 다음 순서의 데이터인 9번과 10번을 전송할 수가 있게 되었다. 추가로, 받는 측인 "B"컴퓨터는 패킷 하나마다 계속해서 Ack신호를 전송한다는 것은 역시 그것도 하나의 트래픽을 발생시키는 것이기에 약속을 해 두었다. 적어도 2개 이상의 연속된 패킷이 들어왔을 때 Ack신호를 전송하도록 한 것이 그것이다.
1번과 3번 패킷이 도착을 했지만, 중간에 이빨이 빠진 채로 2번이 아직 도착을 하지 않았다라고 가정을 해 보자. 그렇게 되면, 받는 측의 TCP는 2개이상의 연속된 패킷이 도착하면 전송을 하자는 약속을 해 두었기에 마냥 기다려야 할 것이다.

그래서 만일의 경우를 대비하여 한가지 해결책을 강구해 두었다. 받는 측의 컴퓨터는 패킷이 도착하였을 때, "Delay Acknowledgement Timer"라고 부르는 Timer를 설치하게 된다. 이 Timer의 시간이 만료될 때까지 2번 패킷이 도착하지 않는다면, 받은 1번 패킷에 대한 Ack신호만이라도 전송을 해 주는 것이 보다 효율적이기 때문이다.
받는 측의 TCP는 1번 패킷에 설치해 둔 Timer가 만료되었고, Ack신호를 전송하고 있다.
송신컴퓨터는 이렇게 수신컴퓨터의 Ack신호를 받고, window를 sliding시켜서 다음 신호를 전송하는 방식을 쓰고 있지만, 또 한가지 문제가 여전히 남아 있다. 만일 무슨 이유에선지 Ack신호가 전혀 오지 않는 상황이라면 어떻게 해야 할까? 이러한 문제를 해결하기 위해서 송신컴퓨터의 TCP는 자신이 보낼 수 있는 Window Size만큼 데이터를 전송하고 자신이 보낸 데이터에 대해서 각 Segment마다 "Retransmission Timer"라고 불리우는 timer를 설치 해 둔다. 만일 이 timer의 시간이 만료될 때까지 Ack신호가 도착하지 않으면 재전송을 하기 위한 배려이다.
결국, TCP는 window size를 이용해서 한꺼번에 일정량의 데이터를 전송하며, 보다 효율을 기하기 위해서 이러한 window를 Sliding시키는 방식을 이용하여 계속적인 데이터 전송을 할 수 있도록 하고 있다. 여기에서 생길 수 있는 문제점들을 "Delay Acknowledgement Timer"와 "Retransmission Timer"를 이용해서 대비책을 마련해 두고 있는 것이다.

이상 TCP Sliding windows에 대해서 정리해 보았다. 다음엔 이어서 TCP Window Size가 네트워크에 미치는 Performance에 대해서 알아보도록 하자.  

 

Windows Size의 크기에 따른 영향

앞에서 우리는 TCP Sliding Windows에 대해서 알아 보았다. 그러면, 이러한 TCP Window라고 하는 것의 Size의 크기 여부가 네트워크에서 가지는 영향에 대해서 정리를 해 보도록 한다.먼저 정리를 해 보면, NT는 "Window size"는 8K, "Segment Size"는 1K로 설정이 되어 있다. 물론 NT의 Registry를 편집함으로써 수정은 가능하지만 권장하지는 않는다. 이미 우리의 선배들이 시행착오를 거쳐서 최적의 size로서 설정이 되어 있기 때문에 우리는 그러한 문제를 고민하는 것보다는 효율적으로 운영하는데 초점을 두는 것이 바람직하겠다. window size가 너무 작을 경우와 너무 클 경우 어떠한 일이 생길 것인지 알아보자.

(1) Window size가 작은 경우
Window size가 1K라고 가정을 해 보면 어떻게 될까? 이제 앞에서 보았던 전송과 응답과정을 이해했다면 금방 알 수 있는 문제다.송신측의 컴퓨터는 1K의 데이터를 전송하고 그것에 대한 응답을 기다릴 것이다. Ack신호가 오면 그 다음 차례인 2번으로 window를 sliding시켜서 또 전송을 시작할 것이다.

하나를 보내고 하나를 받고, 좋아 보이지만 답답한 방법이 아닐 수 없다.

(2) Window size가 큰 경우

Window size가 크다 혹은 작다는 것은 상대적인 개념이다. 네트워크가 얼마나 안정적이며, 또 LAN에서의 통신인지 WAN에서의 통신인지에 따라서 달라질 것이다. 또, WAN구간이라고 할 지라도 56K의 모뎀을 이용하는지 아니면 T3의 빠른 회선을 이용하는 지에 따라서 달라질 수 있다.예제를 통해서 느린 네트워크에서 window size가 큰 경우의 문제를 알아보도록 하자.[그림4]에서는 8K의 window size를 사용하고 있다. 하지만, 문제는 네트워크가 느리다는 데 있다. 속도가 느려서 혹은 트래픽이 많아서 기대되는 응답시간보다 더 오랜시간이 걸려야만 Ack신호를 받을 수 있다고 한다면, 결국엔 송신측 컴퓨터는 미처 Ack신호를 받지 못하고 "Retransmission Timer"의 시간이 만료되어 같은 데이터를 재전송해야 하는 일이 많아지게 될 것이다. 당연히 비효율적인 네트워크가 운영이 될 것이다..

이런 경우라면 오히려 window size를 보다 작은 size로 줄이는 것이 현명한 방법일 것이다. 위의 2가지 예제의 경우에 TCP는 "Connection Oriented protocol"이라는 가장 큰 장점이 오히려 적절하지 못한 window size로 인해서 비효율적인 Protocol이 될 수도 있다. 적절한 window size를 사용하게 된다면 TCP의 장점을 극대화한 최적의 네트워크를 구성하게 될 것이다.