※ 질문/내용오류/공유할 내용이 있다면 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에 대한 이야기를 해볼 생각이다.

Flow Control과 Congestion Control이 TCP의 reliable함을 지원해준다고 적었는데, 공부해보니 틀렸다. Flow Control과 Error Control이다. 이 포스팅의 주소는 아래와 같다.

http://operatingsystems.tistory.com/entry/NW-TCP-and-UDP

수정해놨으니 있을지 없을지 모르는 독자분들께서는 참고하시길 바란다.

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

우선 TCP와 UDP의 차이부터 설명하고자 한다. 가장 큰 차이점은 뭐니뭐니해도 reliable한 프로토콜인지 unreliable한 프로토콜인지에 대한 여부이다. 왜 reliable/unreliable 개념을 만들어놨을까? 모두다 reliable하면 좋은 것 아닌가? 굳이 왜 unreliable한 것까지 만들었을까?

속도 때문이다. 아무레도 이 동네에서도 trade-off는 발생하기 마련인가보다. 여러분은 여러분들이 모르면서도 UDP를 사용하고 있다. 동영상이나 음악 등을 웹사이트로부터 들을 때도 UDP를 사용한다. 프레임 하나가 살짝 깨져도 전체적으로 동영상 보는데는 영향이 없다. 만일 reliable한 TCP같은 경우에는 그런 일이 없겠지만 UDP는 unreliable하기 때문에 이런 일이 발생하는 것이다.

이번 포스팅에서는 우선 TCP와 UDP의 헤더를 설명하고 그 차이를 설명할 예정이다. 그 차이를 설명하면서 왜 TCP는 reliable한 프로토콜이고 왜 UDP는 unreliable한 프로토콜인지 설명할 것이다. 우선 UDP 헤더를 먼저 보자.

해당 필드를 하나하나 설명해보자.

source port number : 출발지 포트 번호를 의미한다.

destination port number : 도착지 포트 번호를 의미한다.

출발지/도착지 포트 번호를 의미한다. 포트 번호란 무엇인가? 포트 번호는 각각의 프로그램에 부여된 번호이다. 하나의 컴퓨터에 몇 개의 프로그램이 동작하고 있는가? 무수히 많다. 네트워크 상에서는 한 쪽 PC의 프로그램과 다른 쪽 PC의 프로그램을 적절하게 연결해야한다. 그렇게 하기 위해서는 해당 프로그램 혹은 프로세스의 identifier 같은 것이 필요하지 않겠나? 그것이 바로 포트 번호이다.

여기서 잠깐, 프로그램 혹은 프로세스의 identifier 같은 것이 포트 번호라고? 그러면 PID(process ID)와는 무슨 차이인가? 이 부분은 나도 잘 모르겠다. 하지만 한 가지는 확실히 할 수 있다. 두 개는 다른 것이다. 진정한 의미에서 프로세스 identifier는 PID이다. 지금 커널 공부도 하고 있으니까 언젠가 두 개가 어떻게 다른지 확실하게 알면 포스팅할 예정이다.

커널에서 PID와 포트 번호가 다르다는 것에 대한 증명은 아래와 같이 할 수 있다. SSH 프로토콜에 대한 PID와 포트번호를 확인해보자.

위의 그림을 보면 PID를 저장하는 변수의 구조체와 포트번호를 저장하는 변수의 구조체가 완전히 다른 구조체라는 것을 알 수 있다. 또한 netstat 명령어와 ps 명령어를 통해 구별도 가능하다.

아무튼 source port number와 destination port number는 그런거다.

그 다음은 length 필드이다.

length : UDP header와 data를 합친 것의 길이이다. IP header에도 비슷한 필드가 있었던 것을 기억해보면 좋다.

UDP checksum : checksum... 어디에서 많이 들어봤다. IP header에서 header checksum이라는 필드가 있었다. 이 필드의 역할을 생각해보니, header가 변조되었는지 확인하는 역할이었다. 그렇다면 UDP checksum에서 checksum의 역할은 무엇일까? 데이터가 변조되었는지 확인하는 것이다. 어? 이상하다. 분명히 UDP는 unreliable 하기 때문에 데이터가 변조되는지 여부는 신경쓰지 않을 것 같은데 이런 기능이 있네? 

이 부분을 해명?하자면 이렇다. 이 필드는 option 이다. UDP를 사용하는 프로그램을 만들 때 설정해줄 수 있는 부분이라고 이해하면 편하다. "내가 만들 프로그램이 UDP를 사용하는데 나는 이 프로그램이 reliable했으면 좋겠다." 이렇게 생각하는 사람이 코드를 작성할 때 UDP checksum을 enable 시키겠지?

크~ 아주 간단하다. UDP 헤더에 대한 설명이 모두 끝났다. 이제 TCP 헤더를 보자. TCP 헤더는 조금 더 복잡하다.

source port number : 출발지 포트 번호

destination port number : 도착지 포트 번호

포트 번호를 알려주는 필드는 TCP든 UDP든 존재해야겠지? 당연하다 4계층의 역할을 생각해보면 당연한거다.

Sequence number : TCP에서 굉장히 중요한 필드이다. 중요하기 때문에 따로 설명하겠다.

Acknowledgement number : 역시나 굉장히 중요한 필드이다. 따로 설명하겠다.

Header length : 헤더 길이를 4비트 길이로 나타낸다.

Reserved : 아무런 용도로 사용되지 않는 필드이다. 그냥 000000으로 초기화되어있다.

Flags : URG, ACK, PSH, RST, SYN, FIN 등을 묶어서 Flags 필드라고 한다. 이 부분은 이전에 IP 설명할 때 포스팅했던 아래의 링크를 같이 복습하면서 보길 바란다.

http://operatingsystems.tistory.com/entry/Type-of-Service-Differentiated-Service

우선 URG 비트는 다른 패킷들보다 우선적으로 어플리케이션에 전달해달라는 의미이다. 어라? 뭔가 많이 들어본 것 같다. 이전에 IP header에서도 이러한 역할을 하는 필드가 있었다고 했던 것 같은데? 그렇다. ToS필드이다. 

IP header의 DS(Differentiated Service) 필드의 역할과 TCP header에서 Flags의 URG 비트 역할의 가장 큰 차이점은 그 비트들이 해석되는 위치이다. IP header의 DS는 각각의 라우터와 end point PC에서 해석되는 반면, TCP header의 Flags 비트는 오로지 end point PC에서만 해석된다.

ACK, PSH, RST, SYN, FIN 등등은 sliding window를 통해 혹은 그 외의 개념을 통해 설명하겠다. 이번 포스팅에서 설명하기에는 너무나도 많은 이야기가 담겨있다.

Window size : 여기서 말하는 window란 무엇일까? 위에서 sliding window를 나중에 설명하겠다고 했는데 그 window이다. 여기까지만 알고 다음에 알아보자. 

TCP checksum : TCP data를 전부 받았을 때 그 받은 데이터에 오류가 있는지를 검사하는 checksum 이다. 이 부분은 이상없이 이해할 수 있으리라 믿는다.

Options : 이 부분은 필요하다고 느껴질때까지 무기한 연기하도록 하겠다.

뭐하는거야 지금? 이렇게 말씀하실지도 모른다. 맞다!! TCP header의 대부분을 나중에 설명하겠다고 하고 넘기고 있다. 그런데 그렇게 할 수 밖에 없다. 왜냐하면 나도 스스로 준비가 제대로 안 되어있고 그 부분을 설명하려면 error control, flow control 개념을 설명해야하기 때문이다. TCP가 UDP와 가장 근본적으로 다른 것은 reliable인지 unreliable인지에 대한 여부이다. 그것을 구현한다고 생각해보라. 꽤나 복잡한 일이 될 수도 있다. 실제로 그러하다. 그것들이 모두 error control, flow control를 통해 구현되는 것이다. 이것들을 모두 설명하기 위해서는 TCP header에 많은 필드들이 필요한데 그것들이 바로 위에서 내가 설명하지 않고 넘어간 그 모든 것들이다. 따라서 다음 포스팅은 당연히 error control, flow control에 대한 내용이 되겠다.

그렇다 다음 포스팅에서는 error control, flow control를 설명하겠다. 조금은 시간이 걸릴지도 모르지만 최대한 빠르게 포스팅을 하도록 하겠다. 

p.s. 오늘 메일 보내주신 분(netxxxx..xx@naver.com) 너무 감사드려요. 앞으로도 자주 이것 저것 공유했으면 합니다 :-)