애초에 리눅스 커널을 공부하고 싶어서 만들었던 스터디였다. 드디어 커널을 손대기 시작했다. 운영체제에 대해서 훑고 시스템 프로그래밍을 공부한 후 네트워크를 공부하더니 커널을 이제 시작하려고 하는 것이다. 지금까지 8개월 걸렸다;; 생각보다 네트워크가 너무 오래 걸린 것 같다. 원래는 2달에 끝내려고 했었는데... 

아무튼 커널 공부 이제 시작합니다. 그러면 조만간 커널에 관한 이야기가 마구 올라오나? 그러지 않는다. 우선 우리가 공부했던 네트워크부터 다 올리고 커널을 올리는데, 그것도 커널을 이해하기 위해서 기본적으로 이해해야하는 배경들도 조금 올라올지도 모른다. 예를 들어 C에서 함수 포인터같은 것은 훑어볼 만 하다고 생각한다.

아무튼 '시작하며'를 조금 이르게 쓴 것이 없지 않아 있지만, 커널 스터디 시작합니다.

휴, 드디어 TCP/UDP가 있는 4계층으로 왔다. 이번 포스팅은 TCP에 대해서 설명하기 보다는 우선적으로 4계층의 역할에 대해서 설명해보도록 하겠다.

4계층에 대해서 이야기하기 위해서 3계층까지는 무슨 일을 하는지 되세겨 보자. 3계층은 end to end communication이다. 즉 패킷을 출발지에서 도착지까지 전달해준다. 그렇다면 2계층은 뭐였냐? 패킷을(정확히 말하면 패킷이 아니라 frame이다.) hop to hop으로 전달해준다.

자, 3계층 덕분에 패킷이 목적지까지 갔다. 그러면 그 다음에 뭘 해야되냐? 목적지에 있는 여러가지 프로그램 중에서 올바른 프로그램으로 데이터가 전달이 되야겠다. 출발지에서는 네이트온에서 쪽지를 보냈는데, 메세지가 도착지의 워드프로세서에 뜨면 안 되겠지?

그렇다. 4계층은 패킷에 들어있는 데이터를 올바른 프로세스에 전달해주기 위한 계층이다. 이제 뭔가 계층이라는 것이 어떤 식으로 작동하는지 알 것 같지 않나? 알았으면 한다. 그래도 한눈에 복습삼아 다시 한번 봐보자.

위와 같은 그림에서 출발지 A에서 도착지 D까지 가려면 아래와 같은 단계를 거친다.

우선, PC A는 보낼 데이터를 가지고 있으면, 거기에 IP헤더가 붙여지고 MAC헤더가 붙여지고 PC를 떠난다.

MAC 헤더는 그 다음 라우터를 알려준다. 중요한 것은 라우터는 MAC을 까보고 IP는 내용만 본다. 그 내용을 참조해서 적당하게 라우팅해주는 것이 라우터이고 이것의 역할이다.

그리고 추가적으로 라우터가 새로운 MAC헤더를 붙여준다.

위의 그림 역시 마찬가지이다.

그리고 마지막으로 목적지인 D에 도달하게되면 IP도 까봐서 데이터를 본다.

지금까지 우리는 3계층만을 본 것이다. 여기에서 4계층을 보면 TCP 개념이 더 들어가는 것이다. 이전에 말했듯이 3계층 개념에서는 하나의 출발지와 도착지를 연결했다. 4계층에서는 출발지에서의 프로세스와 도착지에서의 프로세스를 연결한다.

위의 그림에서 3계층을 까서 얻은 데이터는 아래와 같이 추가적으로 해석된다.

여기에서 4계층 헤더가 해석되는 것이다. 위의 예로 보니까 포트라는게 뭔지는 모르겠지만 도착지가 80포트이다. 포트 번호가 80인 프로세스에 데이터를 전달하라는 뜻이다.

그래 이제는 4계층의 존재의 이유는 알겠다. 기본적으로 process to process communication을 위해서 존재하는 것이다. 현재에는 이러한 4계층 communication을 위해서 OS 단에서 TCP나 UDP 등을 구현하여 사용한다. TCP와 UDP는 어떤 특징을 가질까? 그리고 TCP/UDP가 없을 때는 뭘로 4계층을 구현했을까?

다음 포스팅부터 길게 TCP/UDP에 대해서 설명하고자 한다. 기나긴 여정이 될 것이다. 그 다음 TCP/UDP가 없었을 때를 설명할 생각이다.

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

이번에는 Type of Service에 대해서 이야기 해보려고 한다. 이전 포스팅에서 이야기 했듯이 Type of Service는 IP에서 라우터의 관점에서 각각 패킷들의 우선순위를 나타내는 필드라고 했다. 그런데 실제로 패킷을 분석해보면 Type of Service라는 필드는 눈을 씻고 찾아봐도 없다. 어떻게 된 것일까? 대신에 Differentiated Service가 있다. Differentiated Service 때문에 안 보이는 것이다. Differentiated Service는 이전의 Type of Service가 바뀐 것이다.

Differentiated Service를 설명하기 전에 Type of Service를 먼저 설명하고자 한다. Type of Service 필드는 8비트 필드로 기본적으로 아래와 같이 정의되어 있다. 

처음 3비트는 Precedence 비트로 각 패킷의 우선순위를 나타낸다. 3비트이기 때문에 가질 수 있는 값의 범위는 0부터 7까지이다. 즉, 0부터 7까지의 우선순위 단계를 갖는다는 것이다. 0이 가장 낮은 우선순위이고 7이 가장 높은 우선순위이다. 

다음 4비트는 패킷에 대한 Quality를 정하는 비트이다. 보통 그 패킷의 성격에 따라 중요하게 여겨지는 요소가 다르다. 예를 들어, FTP에서 속도가 중요할까? 신뢰성이 중요할까? 신뢰성이 중요하다. 속도가 아무리 빨라도 내가 다운받은 파일이 실제의 파일과 다르면 무슨 소용이냐?! 이와 같이 그 패킷의 품질을 정하는 것을 이 4비트에서 한다. 여기서 DTRC는 왼쪽부터 오른쪽으로 각각 다음의 의미를 갖는다.

D : Minimize Delay

T : Maximize Throughput

R : Maximize Reliability

C : Minimize Cost

서비스를 평가하는 기준을 위의 4가지로 분류할 수 있다. Delay는 말 그대로 지연이 없도록 하는 것이다. Throughput은 처리량을 뜻하는데, 처리량을 최대로 하라는 의미이다. Reliability는 신뢰성을 최대로 하라는 것이고 Cost는 처리하는데 비용을 최소화하라는 것이다. 흠 그런데 Cost가 뭘 의미하는지 잘 모르겠다. 책들을 조금 뒤져봤는데 안 나온다. 혹시라도 알고 있는 사람은 뎃글 부탁한다. 

각각의 비트들이 1로 세팅되어있을 때 그 의미를 갖는다. 예를 들어 Minimize Delay 비트가 1로 세팅되면 지연을 최소화하겠다는 뜻이다. 여기서 중요한 것은 위의 4비트 중에서 한 비트만이 1로 세팅할 수 있다는 것이다. 따라서 나올 수 있는 경우의 수는 다음의 5가지이다. 

3비트의 Precedence 그리고 4비트의 DTRC. 한 비트 남았다. unused이다. 사용되지 않는 필드이다. 이 부분은 사용되지 않기 때문에 Default로 0으로 세팅되어있다. 

지금까지 ToS를 이야기해봤다. 그렇다면 이 부분이 Differentiated Service 필드로 바뀌면서 어떻게 바뀌었을까? 지금부터 이야기해보자. 우선적으로 당연하지만 구성이 바뀌었다. 아래와 같이 쓰인다.

이 필드는 RFC문서를 뒤져봐도 몇 번째 필드는 무슨 뜻인지 상세하게 나오지 않는다. 그 이유는 이렇다고 추측한다. 

DS compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field by treating the value of the 
field as a table index which is used to select a particular packet handling mechanism which has been implemented 
in that device.

출처 : tools.ietf.org/html/rfc2474

위의 내용은 rfc2474를 참고한 내용이다. 내용인 즉, DS 6비트는 각 장비에 구현되어있는 패킷 처리 메커니즘을 선택하는데 사용된다는 것이다.(조금 의역이 있다.) 각 장비에 구현되어있는!! 이라는 말을 주의해서 보자. 이 말은 정해진 것이 없이 각 장비에서 입맛에 맞게 구현해서 쓰일 수 있다는 것이다. 말이 이상하다. 그러면 지 맘데로 써도 된다고? 가장 기본적인 룰은 지켜지도록 한다는 가정하에 입맛에 맞는 구현이 가능하다는 것이다. 그 기본적인 룰을 우리는 Default PHB(Per Hope Behavior)라고 부른다. 기본적으로 각각의 패킷들을 어떤 방식으로 다룰 것인지에 대한 내용이다. 이 Default PHB가 어떤 경우인가? 

xxx000이다. 제일 왼쪽부터 6개의 미트를 봤을 때, 오른쪽 3비트가 000일 때 이다. 왜 이러한 제한을 만들어놨느냐? ToS 시절에 사용하던 규칙과의 호환성을 위해서이다. 나는 Differentiated Service 필드라며 내 마음대로 구현해놓은 라우터가 있다면 그 라우터는 이전의 ToS를 지원하는 OS에서 만들어진 패킷들은 어떻게 다룰 수가 없는 것이다. 이전의 ToS에서 앞의 3비트는 Precedence 필드로 우선순위로 사용된다고 하였다. 그리고 그 다음 3비트 혹은 4비트는 DTRC로 쓰인다고 했다. 이 비트들은 사실 0이든 1이든 Critical하게 중요하지는 않기 때문에 Differentiated Service 필드에서는 0으로 세팅해버린 것이다. 즉, ToS 환경에서 만들어진 111이라는 우선순위와 0000이라는 DTRC를 세팅한 패킷은 Differentiated Service 필드를 지원해주는 라우터에 도착했을 때 애초의 의도와 같게 해석되어 111이라는 우선순위를 그대로 유지할 수 있게 된다. 즉, 왼쪽부터 xxx000이라는 패턴의 패킷이 들어올 경우에는 너 마음데로 정한 PHB를 사용하지 말고 이전부터 쓰던 그 우선순위 매기는 PHB를 사용해라는 것이다. 만일 ToS 환경의 패킷이 111010이라는 것을 보내면 이것은 111000으로 해석하게 된다. 결국 111010, 111100, 111001이 그냥 모두 111이라는 우선순위를 가진 패킷으로 해석된다. 

여기서 잠깐, 지금까지 말한 xxx000이라는 것은 뒤의 2자리가 0이었을 때이다. 즉 xxx00000일 경우는 위의 규칙을 따른다. 그런데 Differentiated Service 필드 전체 8자리 중 가장 오른쪽 두 자리가 0이 아닐 경우는 어떻게 되는가? 이럴 경우에는 각각의 라우터에서 설정된 PHB를 따르게 된다.

xxxxxx01이나 xxxxxx11은 xxxxxx가 어떤 값이 올지에 따라 자기 입맛데로 해석된다는 것이다. 이와 같은 패킷들은 각각의 라우터가 자기 입맛에 맞게 해석한다는 것이다. 이전에 사용되었던 ToS필드는 마지막 2비트가 무조건 0으로 사용되었기 때문에 ToS를 사용하는 사용자들 입장에서는 '내 패킷이 Differentiated Service 필드를 지원하는 라우터에 도달했을 때 나의 ToS 필드가 잘못 해석되면 어떻하지?'와 같은 걱정을 하지 않아도 된다.

조금 복잡하다. 정리하면 아래와 같다.

위의 표를 보면 내가 복잡하게 설명해놨던 것들이 이해가 갈 것이라고 믿는다. 

이제 다음 포스팅은 TCP에 대해서 이다. 그런데 이전 포스팅에서 Type of Service 부분에 대한 설명은 무기한 연장하겠다고 했으면서 왜 갑자기 이 부분을 특별대우하여 하나의 독립적인 포스팅으로 했는지 의아해하는 있을지 없을지 모르는 독자들이 있을 것이다. 이유는 TCP 공부하면서 든 궁금증 때문이다. 나중에 설명하겠지만 TCP 헤더에도 Flag가 있다. URG PSH 등등과 같은 Flag이다. 이 값들의 의미를 봐도 큐에 빨리 집어넣도록 유도하는 우선순위적인 의미가 있다. 그러면 IP에서의 Type of Service와 무슨 차이지? 라는 생각이 문뜩 들었던 것이다. Type of Service(Differentiated Service) 필드는 매우 중요한 개념은 분명히 아니다. 하지만 전혀 다른 계층인 4계층의 요소와 다름을 못 느끼고 있다는 것은 본질 자체를 이해하지 못 하고 있다는 생각이 들었다. 그래서 이 부분만 따로 특별 우대해서 공부했던 것이다. 

말했듯이 다음 포스팅은 TCP이다. Maybe에서 TCP/IP는 분명 2달을 생각하고 시작했는데 한 4달은 하고 있는 것 같다. 물론 성과가 그렇게 없었던 것은 아니다. 새롭게 공부한 부분이 많다. 하지만 너무 공부 자체가 지체되고 있다는 생각이 많이 들었다. TCP 공부하는 것도 오늘이 마지막이다. 마지막 유종의 미를 잘 살리고 싶다.