[NW] Flow Control and Error Control

※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

이전 블로깅에서 TCP의 상당한 필드를 다음 포스팅에서 하겠다고 넘어가버렸다. 그 뒷이야기를 지금에서야 시작하게된 점 있을지도 없을지도 모르는 독자들에게 죄송하다고 먼저 말하고 싶다. 앞의 이야기를 살짝 이야기하고 넘어가면 이렇다. TCP와 UDP의 가장 큰 차이점은 reliable함의 여부이다. TCP가 reliable한 이유는 내가 이전에 설명하지 않은 대부분의 TCP 헤더 내부의 필드가 존재하기 때문이다. 이를 전문적으로 Flow Control과  Error Control등을 구현하기 위한 필드로 보면된다.

여기까지가 이전 포스팅의 내용이다. (이전 포스팅에서는 Flow Control과 Congestion Control이라고 적어놨는데 잘못된 내용이다.)

이제 Flow Control과 Error Control에 대한 이야기를 본격적으로 해보자. 우선, Flow Control이다. 이 개념을 알기 위해서는 window size 개념을 우선적으로 알야아 한다. (여기서 말하는 window는 byte 기반임을 알아두자.) 여기서 말하는 window는 sliding window를 말하는 것이다. sliding window는 책에 이렇게 설명되어있다.

the sliding window is an abstract concept that defines the range of sequence numbers that is the concern of the sender and receiver

reference : Data Communications and Networking (Fourth Edition) by McGraw HILL

즉, sender와 receiver에게 존재하는 추상적인 개념으로 그들이 보내거나 받는 데이터들을 쭉 길게 연속적으로(byte 기반으로) 나열해둔 것이다. 10 byte를 5 byte씩 나누어서 받는 sender에게 있어서 window는 아래와 같을 것이다.

receiver에서도 마찬가지이다. TCP에서는 데이터를 주고 받을 때 아래와 같이 데이터를 쭉 나열해서 데이터를 하나하나 관리한다. (여기서 이래서 reliable하겠다라는 생각이 나와야 한다.) 위의 그림에서 보면 10 byte의 데이터를 5 byte씩 나눠서 보내는데 그 5 byte를 sender가 특별히 신경써준다. 그러니까 reliable하겠지. 그렇다면 이거를 어떻게 신경써주느냐에 대해서 이야기할 것인데, 그것이 바로 Flow Control이다.

TCP에서 Flow Control은 Sequence Number와 Acknowledgment number를 통해서 구현된다. Sequence Number는 sender가 보내는 바이트의 가장 첫 바이트를 숫자를 random number에 더하여 표현한 것이다. 가령, 100 byte를 보내야 되는 상황에서 51까지 보낸 상황이라면, 52 + 100000(random number) = 100052 가 된다. 100000는 임의로 내가 정한 random number이므로 출처를 놓고 혼동하지 말기를 바란다. 즉, Sequence Number는 "난 여기서부터 보낼께"라는 의미로 받아들이면 된다. 반면, Acknowledgment number는 그에 대한 응답이다. 이 숫자는 자기가 받은 마지막 데이터의 바이트 수 + 1 + random number이다. 예를 들어, 100 byte 데이터를 받는다고 가정할 때, 62까지 받았다면 +1을 한 63에 random number 100000를 더한 100063 이 된다. 즉, Acknowledgment number는 "난 Acknowledgment number - 1까지는 잘 받았으니까 Acknowledgment number부터 받으면 돼" 라는 뜻이다.

Sequence Number와 Acknowledgment  Number를 통해서 어떻게 Flow Control을 하는지 보자.

제일 처음에 Seq(Sequence Number)가 9001이다. 그렇다면 이전까지 0바이트부터 9000바이트까지 이미 보낸 상황이고 9001부터 보내고 있는 것이다. 그런데 Ack(Acknowledgment Number)가 15001이다. 이 말은 "15000까지는 받았으니까 15001부터 보내줘라"라는 뜻이다. 그렇다면 receiver가 sender에게 보낼 때는 Seq와 Ack가 어떻게 되어있는지 보자. Seq는 15001로 되어있다. 당연하다. 이전에 sender가 Ack를 15001부터 달라고 요구했기 때문이다. 그리고 Ack는 10001로 되어있다. 당연하다. 이전에 sender가 9001부터 10000까지 데이터를 전송했기 때문이다. 따라서 10000까지는 잘 받았으니 10001부터 달라고 요청하는 것이다. 이 때 receiver가 sender에게 보내는 바이트 수가 2000바이트이다. 즉, 15001부터 17000까지이다. 따라서 이 데이터를 잘 받은 sender는 17000까지는 잘 받았으니 17001부터 데이터를 달라고 요청하기 위해 Ack를 17001로 세팅한다. 그렇다면 이때 sender가 보내는 Seq는 뭘까? 10001이다. 왜냐하면, 이전에 9000 byte부터 10000 byte까지 보냈기 때문에 그 다음 byte인 10001 byte부터 11001까지를 보내는 것이다. 

그런데 그냥 얼핏 생각해도 이런 식으로 보낸 모든 패킷에 대해 Ack를 받으면서 데이터를 전송하면 너무 느릴 것 같다. 그래서 TCP는 여러 개의 패킷에 대한 Ack를 한번에 줄 수 있다. 아래와 같다. 

sender가 8001부터 9000까지의 패킷과 9001부터 10000까지의 패킷을 보냈다. receiver는 Ack를 10001으로 세팅해서 패킷을 보낸다. 왜냐하면 10000까지는 받았기 때문이다. 즉, 8001부터 9000까지는 당연히 받았으니까 묻지도 따지지도 말고 10001부터 보내라는 뜻이다. 만일 8001부터 9000까지의 데이터가 손실되고 9001부터 10000까지의 데이터는 도착했다면 receiver는 Ack를 어떻게 해서 보낼까? 8001로 세팅해서 보낸다. 9001부터 10000까지의 데이터를 받았음에도 불구하고 8001부터 9000까지는 못 받았기 때문에 일단 9001부터 10000까지의 데이터는 receiver 쪽에서 임시로 보관하고 있는다. 그러면서 8001부터 보내달라는 패킷(Ack = 8001)을 보낸다. 이 때 sender는 8001을 받고는 "어! 내가 보냈던 8001부터 9000까지가 손실되었나?" 하고 8001부터 9000까지를 다시 보낸다. 아래와 같다. 

TCP의 Flow Control은 이와 같이 이루어진다. 그러니까 그냥 패킷을 마구 보내는 UDP보다는 훨씬 reliable한 것이다. TCP의 reliable함은Error Control을 통해서 이루어지기도 한다. 사실 위에서 말한 패킷이 lost된 상황에 대한 조치 역시 TCP의 Error Control을 통해서 이루어지는 것이다. 전문적인 용어로 Retransmission이라고 한다. TCP의 Error Control를 이야기하기 위해서 Retransmission 이외의 다른 이야기도 할 필요가 있다. 그 이야기를 밑에서 해볼 생각이다.

 

TCP 헤더 중에서 Checksum 부분이 있다. 이 부분은 전송된 데이터가 손상되었는지를 판단해주는 부분이다. 똑똑한 말로 무결성을 체크해주는 부분이다. TCP가 제일 처음에 데이터를 묶을 때 그 데이터를 일련의 규칙을 가지고 숫자를 만든다. 그 숫자가 Checksum이다. 이 숫자를 또 정해진 방법대로 조작하면 애초에 보냈을 때 내용이 무엇이었는지 해독이 가능하다는 것이다. 즉, 일종의 암호같은 것이다. 만일 TCP가 자기가 실제로 받은 데이터와 Checksum을 해독한 값을 비교해봤는데 그 값이 틀리더라? 그것은 중간에 무슨 이유에 의해서 데이터가 변조 또는 손상되었다는 뜻이다.

 

TCP에서 Retransmission이 발생하는 경우는 두 가지이다. 하나는 Retransmission Time Out(RTO)이고 또 하나는 3 duplicated Ack가 발생했을 경우이다. RTO라는 것은 Retransmission Timer가 만료되었을 경우를 의미한다. Retransmission Timer는 receiver가 데이터를 기다리는 시간이다. 이 시간이 없으면 receiver 입장에서는 sender가 패킷을 보냈는지 안 보냈는지 알 방법이 없다. 따라서 가령 500ms 정도의 시간을 세팅해둔 후 그 시간이 지나도 데이터가 오지 않으면 다시 보내라고 한다. 이와 같은 경우는 아래와 같이 설명할 수 있다.

sender에서 처음에 보낸 Seq : 8001, Ack : 15001인 패킷이 중간에 손실되었다.(혹은 아예 보내지 않았던가..) 그래서 receiver는 아무런 패킷을 받지 못 했는데 그래서 RTO가 발생한 후 "8001부터 빨리 달라니깐?!" 하고 sender에게 보내는 것이다. 그렇다면 두 번째Retransmission이 발생하는 경우는 어떤 경우인가? 3 duplicated Ack가 발생한 경우이다. 즉, sender가 3개의 중복된 Ack를 receiver로부터 받았을 경우 Retransmission이 발생한다. 아래의 그림과 같다.

위의 그림의 제일 위의 Seq 8001 패킷이 중간에 손실되었다. 그런데 sender는 그냥 계속 Seq 9001부터 보내고 있다. 그것을 받은 receiver는 8001부터 달라고 보라색 패킷을 보냈다. 그런데 Sender는 또 엉뚱하게 10001부터 보낸다. 그래서 Receiver는 똑같은 보라색 패킷을 또 보냈다. 그런데 또 Sender는 엉뚱하게 Seq 11001부터 보내네? 그래서 Receiver는 똑같이 보라색 패킷을 또 다시 보냈다. 자, Sender는 똑같은 보라색 패킷을 3개나 받았다.(3 duplicated Ack) 이 때 Retransmission이 발생한다.

 

마지막에 설명한 3 Duplicated Ack 경우는 Fast Transmission이라는 개념으로 설명되기도 한다. 같은 개념이니까 용어만 익혀두자.

 

이로서 Flow Control과 Errorl Control에 대한 설명은 끝났다. 그러면서 TCP header에서의 Sequence number 그리고 Acknowledgment Number에 대한 이야기는 모두 끝냈다. 다음 포스팅에서는 TCP Flags에 대한 이야기를 해볼 생각이다.