[NW] IP header

Computer Networks 2013. 7. 30. 22:22

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


이번 포스팅에서는 예고했듯이 IP 헤더에 대해서 이야기해보려고 한다. 지난 번 포스팅 이야기는 굉장히 중요한 이야기였다. 인터넷이라는 것이 나오면서 왜 IP가 나올 수 밖에 없었는지도 이야기했다. 이번 포스팅에서는 IP header를 설명하면서 더불어 그 필드가 왜 필요한지도 같이 이야기 해보려고 한다. 단순히 이 필드는 이것을 뜻하는 것입니다 라고 써놓는 것은 내 블로그와는 거리가 멀다.

yy


위의 그림이 IP 헤더이다. 이전 포스팅에서 말했듯이 라우터라는 장비는 이 헤더를 해석하여 패킷들을 라우팅한다. 라우팅할 때는 2계층 헤더를(MAC 헤더) 적절하게 수정하여 패킷을 전송한다. 전부 이전 블로그에서 공부했던 내용이다.


아무튼 우선은 위의 IP 헤더의 각각이 무슨 역할을 하는지부터 설명해보자. 각 필드명을 적고 괄호로 그 필드에 할당된 길이를 적어놨다.)


Version(4 bits) : IP version을 의미한다. 이전에도 말했듯이 IP는 소프트웨어이다. 운영체제에서 구현해놓은 소프트웨어일 뿐이다. 그렇다면 당연히 버전이 존제하겠지? 지금 현재 우리가 사용하고 있는 IP는 version 4(v4)이다. IP v4에서는 IP 주소의 길이가 32비트이다. 즉, 32비트로 이 세상의 모든 컴퓨터를 구별해야하는데(엄밀히 말하면 틀린 말이다. 나중에 자세히 설명하겠다.) 그게 너무 부족하다고 판단하여 IP v6도 나왔지만 현재까지는 IP v4가 사용되고 있다. IPv6로 넘어가지 못 하고 있는 가장 큰 문제는 내 생각에는 호환성이다. v4를 사용하고 있는 시스템과 v6를 사용하고 있는 시스템의 통신이 만만치 않을 것 같다. 이제 자연스럽게 version 정보가 필요한 이유도 정리가 됐다. IP version을 체크함으로서 서로의 호환성을 체크하는 것이다.


Header Length(4 bits) : 헤더 길이이다. 기본적으로 IP 헤더는 20바이트에서 60바이트 사이이다. 대부분이 20바이트로 끝난다. 중요한 것이 있다. IP 헤더는 보통 32비트(4바이트) 단위로 그 길이를 표현한다. IP헤더는 대부분 20바이트이다. 20바이트를 4바이트로 나누면 5이다. 그렇다. 대부분의 IP헤더값은 5이다. 4 bit의 2진수로 표현할 수 있는 최대 숫자는 1111(2)이다. 이는 10진수로 15이고 4바이트단위로 15이면 60바이트이다. 헤더 길이의 최대값이 60바이트가 되는 이유도 header length와 연관이 있네. 그런데 왜 헤더의 길이를 명시해둘 필요가 있을까? 바로 IP 헤더길이의 가변성 때문이다. 헤더 길이가 20바이트가 고정이면 굳이 header length를 표시하는데 4 비트나 쓸 필요가 없다. 운영체제 상에서 4비트로 하드코딩 해두면 되니까. 그런데 헤더 길이가 나중에 말하겠지만 Optional field 때문에 가변적이다. 만일 헤더 길이를 명시해두지 않으면 기나긴 라우팅을 거쳐 도착지로 도착한 시스템이 어디까지가 헤더이고 어디부터가 데이터인지 어떻게 아냐? 모른다! 그것을 위해서 Header length를 명시해둔다.


Type of Service Flags(8 bits) : IP의 역할이 무엇인가? 바로 라우팅이다. 출발지로부터의 패킷을 각각의 목적지로 올바르게 보내주는 것이다. 그런데 가기만 하면 장땡인가? 아니다. 어떤 데이터는 그 특성상 다른 데이터보다 우선적으로 처리되어야 할 가치가 있을 수도 있다. 예를 들어 단순히 비디오 볼 때 발생하는 패킷이 중요한 웹서버로부터의 패킷들보다 중요할까? (굳이 따지면 이렇게 할 수도 이해할 수 있다는 것이다. 실제로 웹서버로부터의 패킷이 비디오 볼 때의 패킷보다 더 중요하게 여겨지거나 하지 않는다.) 이와 같이 각각 패킷의 중요성을 구분하기 위해서 Type of Service 라는 필드를 만든 것이다. 


즉, 패킷이 라우팅될 때 중간 중간 경우하는 라우터들이 이 필드를 보고 그 중요성(우선 순위)을 해석한다. 이것을 이해하기 위한 중요한 개념이 network device queue 이다. device queue에 대해서는 이전에도 설명을 한 바가 있다.


http://operatingsystems.tistory.com/entry/OS-Job-Queue-Ready-Queue-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Device-Queue


위의 링크를 들어가보면, 이전에 포스팅해두었던 것이 있다.  network device queue는 우리가 흔히 말하는 랜카드 상에 존재하는 저장공간을 의미한다. Buffer라고도 불리는 공간이다. 네트워크에서는 크게 두 가지 종류의 버퍼가 존재한다. Sending Buffer 그리고 Receiving Buffer 이다. Type of Service는 Receiving Buffer에서 고려되어지는 것이다. IP 패킷이 라우터를 통해 라우팅될 때 각각의 라우터 또한 Receiving Buffer를 가지고 있을 것이다. 각각의 패킷에 대한 우선 순위를 Receiving Buffer 입장에서 생각해보자. 별로 중요하지 않은 패킷들이 라우팅되고 있는 상황에서 갑자기 중요한 패킷이 왔다. 그러면 라우터는 이 패킷을 우선적으로 처리하게 된다. 


Total Packet Length(16 bits) : 패킷 전체의 길이를 바이트 단위로 나타낸다. 여기에서 말하는 길이는 패킷 헤더와 패킷 바디를 모두 포함한 길이이다. 이 부분은 또 왜 있는 것일까? 이 부분에 대한 필요성은 나중에 Fragmentation Offset field와 같이 따로 설명하겠다.


Fragment Identifier(16 bits) : 이 부분은 통체로 설명을 나중으로 미루는게 나을 것 같다. 

Fragmentation Flags(3 bits) : 이 부분 역시 통체로 설명을 나중으로 미루는게 나을 것 같다.

Fragmentation Offset(13 bits) : 이 부분도;;;


Time-To-Live(8 bits) : 이 부분은 IP의 개념과 밀접하다. IP에서는 여러 개의 라우터를 거치는 라우팅이 가장 중요하다. 예를 들어, 이 때 만일 라우팅이 잘못 되어 무한 루프를 돈다고 하면 어떻하나? 아래의 그림과 같이 말이다.



언젠가는 라우팅을 끝내야 한다. 그렇지 않으면 쓸대없이 네트워크 자원도 낭비할 뿐더러 출발지와 목적지는 그냥 계속 대기상태가된다. 이러한 문제를 해결하기 위한 것이 Time-To-Live(TTL)값이다. TTL값은 기본적으로 시스템마다 고유의 초기값으로 세팅되어있다. 이렇게 세팅되어있는 값은 라우팅을 거치면서 1씩 감소되는데 계속 감소되어 0이 되면 패킷은 버려진다. 


Protocol Identifier (8 bits) : 이 부분은 3계층 IP의 다음 계층인 4계층에서 어떤 프로토콜을 사용하고 있는지를 명시해둔 부분이다. 각각의 4계층 프로토콜에서 아래와 같은 값들을 갖는다.



Header Checksum (16 bits) : IP 헤더의 길이는 매번 달라진다. 적어도 라우터를 거쳐나갈 때마다 Time-To-Live 값은 하나 씩 떨어지니까 IP 헤더의 내용은 달라질 수 밖에 없다. IP datagram을 해석하는 장비들은 이 필드를 확인한 후 자기가 받은 header가 손상되었는지 확인하고 만일 그랬다면 버려버린다. '아~ 그렇구나'라고 넘어가면 안된다. 이 부분에서 질문이 나와야 한다. 왜 IP가 correction check를 하지? IP는 그냥 전송을 담당하는 부분일 뿐, 고치거나 error detection 등은 하지 않는 것으로 알고 있었는데 아닌가? 이 부분은 아직 나도 잘 모르겠다. 이 부분에 대한 답이 나오면 왜 이 필드가 존재해야 하는지도 답이 나오겠지?


Source IP address (32 bits) : 이 부분은 설명할 필요가 없다. 그냥 출발지 주소를 32비트 주소로 표현한 것일 뿐이다.

Destination IP address (32 bits) : 도착지 주소를 32비트 주소로 표현한 것 뿐이다.

options(varies) : 말 그대로 있어도 되고 없어도 되는 부분이다. 헤더의 길이는 20바이트에서 60바이트까지라고 말한 적이 있따. 헤더가 20바이트 이상일 경우가 옵션 필드가 이용되었을 경우이다. 그렇다면 이 헤더 필드는 무슨 용도로 사용되는가? 아까 훝어본 내용인데, IP가 라우팅될 때 특정 라우터를 거쳐서 가게하고 싶거나, IP데이터그램 자체에 보안을 강화하고 싶거나 등등의 꼭 필요하지는 않지만 가능하면 좋은 그런 기능들이 있었다. 그 부분에 대한 포스팅은 아마 안할 것 같다. 없는 경우가 대부분이고 그렇게 중요한 부분도 없기 때문이다.


Padding(varies)헤더 길이를 32비트 단위로 맞추기 위해서 사용된다. 왜 맞출까? 이것은 정답이 아닐 지도 모른다. 그런데 난 이렇게 생각한다. 아까 전에 위에서 IP header length는 32 bits의 단위로 표현된다고 했다. 만일 실제 헤더 길이가 정확히 32비트로 떨어지지 않는다면 header length가 부정확해진다. "header length를 byte단위로 쓰면 되잖아요?" 그렇게 되면 IP header length field의 길이가 4배로 늘어난다. 따라서 IP header length 의 길이는 2비트 더 길어진다. 아래와 같은 그림이 될 것이다. 



그림이 완전히 꼬여진다. 비효율적으로 늘어나는 부분도 많다. 그래서 아마도 padding이라는 것을 놓고 IP header를 조금 더 효율적으로 구성시킨 것이 아닌가 싶다.


Data(varies) : IP 헤더를 padding으로 정확히 32비트 단위로 맞춘 후에는 data가 오게 된다. 여기서 말하는 데이터는 무엇인가? 말 그대로 읽어야 하는 무언가이다. 앞으로 이야기하게 될 TCP나 UDP도 포함하는 어떤 데이터들을 말하는 것이다.


이제 위에서 설명하지 않고 넘어간 IP fragmentation 관련된 필드를 이야기해볼까 한다. 이것에 관해서 이야기 하기 위해서는 MTU라는 개념을 알아야한다. Maximum Transmission Unit 이다. 최대로 전송할 수 있는 Unit의 크기이다. 그렇다. 예를 들어 하나의 그림 파일을 전송한다고 가정하자. 이것은 몇 조각으로 나뉘어져있다. 아래의 그림을 보자.



한번에 전송하기에는 위의 그림이 너무 큰 것이다. 그래서 전송할 수 있는 최대한의 크기로 잘라서 보내는 것이다. 그렇다면 받는 사람은 잘린 것을 어떻게 보냐고? 이어서 본다. 이 작업을 reassemble이라고 한다. 패킷이 reassemble될 때 알아야 하는 것들이 몇 가지 있다. 우선적으로 이 패킷이 fragement된 것인지 확인할 수 있는 무언가가 필요하다. 조각난 패킷들이 하나의 패킷으로부터 온 것인지 확인할 필요가 있다. 또한, 그것들의 순서를 알 수 있어야 한다. 


Fragmentation Flags (3 bits) : IP가 fragment된 것인지 확인하는 부분이다. 이 부분은 3 bits로 표현된다. 첫번째 비트는 그냥 무조건 0이다. 두번째 비트는 may fragment라고 해서 fragment되었는지를 0 혹은 1로 표현한다. 0일 경우, fragment된 것을 의미한다. 1  일 마지막 세번째 비트는 more fragment이다. 하나의 데이터가 fragment될 때 마지막 패킷을 인식하기 위해 쓰인다. 이 field가 0이 면 보낼 패킷이 더 이상 없다는 것이다. 반대로 1이면 무언가 더 보낼 것이 있다는 것이 된다.


Fragmentation Identifier (16 bits) : 하나의 파일이 쪼개졌을 경우, 각각의 fragment된 패킷들이 애초에 하나의 파일로부터 온 것이라는 것을 알리기 위해서 표시가 필요하다. 그것이 바로 fragmentation identifier라는 필드이다. 이 필드는 어떤 특정 숫자를 가지고 있는데 이 숫자가 다는 의미는 fragment되기 전부터 같은 데이터에 속한다 것을 의미한다. 


Fragmentation Offset (13 bits) : 쪼개진 패킷의 순서를 알려주기 위함이다. 패킷의 순서를 알려주는데 어떻게 알려주는가? 상대적인 개념을 사용해서 알려준다. 주의할 것은 이 필드는 항상 바이트를 8로 나눈 값을 사용한다. 1400바이트를 표현하고 싶을 때는 1400/8=175. 175라는 값이 필드에 입력되어있다.


컴퓨터에서 Offset은 매우 중요한 개념이다. IP에서 뿐만 아니라 컴퓨터 전반적으로 Offset이라 함은 Offset이라는 의미는 컴퓨터에서 무슨 말인가? "기준치로부터 얼마나 떨어져있나?"를 의미한다. 

위의 그림을 보아도 전송할 파일의 총 크기가 4000바이트이고 각각 패킷의 MTU가 1400일 때, 첫번째 패킷은 0이고, 두번째 패킷은 175(1400바이트째부터 1400바이트라는 의미), 세번째 패킷은 350(2800바이트부터 1200바이트라는 의미, 보내야하는 패킷의 총 크기가 4000이므로 1200바이트)이다. 각각의 MTU값은 어떻게 아냐고? Header length필드와 Total Packet Length 필드를 보면 알 수 있다. Total packet Length는 헤더를 포함한 길이이기 때문에 "Total Packet Length - Header Length = 순수 데이터 사이즈" 라는 당연한 공식이 나온다. 


이제 무언가 대충 어떤 것인지는 파악했다. 다음 포스팅에서는 위에서 언급한 데로 Type of Service에 대해서 이야기해보도록 하자.


p.s. 아휴, IP 하나 쓰는데 왜 이렇게 오래걸렸는지 모르겠다. 있을지 없을지 모를 독자들에게 죄송하다는 말을 드리고프다.


'Computer Networks' 카테고리의 다른 글

[NW] Transport Layer  (1) 2013.08.25
[NW] Type of Service (Differentiated Service)  (2) 2013.08.21
[NW] Internet Protocol in detail  (0) 2013.07.28
[NW] Internet Protocol  (0) 2013.07.26
[NW] Use of ARP  (0) 2013.06.21
Posted by 빛나유
,