IP헤더

 

미래소년코난 | 미소코난
http://blog.naver.com/impro/2952851

Version number
4비트 크기의 필드로 IP의 버전 번호를 담는다.  현재의 버전은 4이다.

 

Length
이것은 IP 헤더의 길이를 표시한다.  가장 짧은 길이는 5개의 워드로 구성되며 보통의 경우 대부분의 IP 패킷은 45(16)로 시작한다.  선택사항인 항목들이 추가됨에 따라 프로토콜의 헤더의 길이는 증가하며 헤더를 해석하기 위해서는 정확한 길이를 알아야 한다.

 

Type of service
이 항목은 고정된 규칙에 따라 메세지를 처리하도록 하기위한, IP 프로토콜 장치에 대한 입력을 담고 있다. 아래에 자세한 이 항목의 자세한 구조를 보였다. 실제로 두 컴퓨터간에는 질적으로 차이가 나는 서로 다른 경로가 존재하는 경우가 거의 없기 때문에 값 0은 거의 항상 사용된다.  게다가 알려진 바에 의하면 어떠한 UNIX IP 구현들도 이 항목을 검토하도록 하지 않는다(이것은 아마도 이 항목을 채워넣을 프로그램 인터페이스가 없기 때문일 것이다).

 

Bits            If 0                                       If 1
0-2             Precedence        

3                Normal delay                        Low dealy 

4                Normal throughput               High throughput

5                Normal reliability                   High reliability  

6-7             Reserver

                  0     1       2       3       4       5      6      7

                  Precedence       D       T       R      O     O
                      

Packet length
이 항목은 프로토콜 헤더를 포함한 패킷의 길이를 담고 있다.  이 항목은 데이타의 길이를 결정하고 후에 트랜스포트 프로토콜로 건네어진다.  16비트 크기의 항목이므로 IP 패킷은 최대 길이가 65,535(216-1)바이트가 된다.  IP 명세서는 모든 호스트 컴퓨터는 512 바이트의 데이타와 프로토콜 헤더를 첨가한, 576바이트의 패킷들을 수신하여 재결합할 수 있을 것을 요구한다.  일반적으로 컴퓨터들은 이 보다 더 큰 패킷들을 처리할 수 있는데 최소한 그들이 연결되어 있는 네트워크에서의 최대 크기의 패킷을 처리할 수 있다.

 

Identification
이것은 송신 호스트에 의하여 생성되는 유일한 식별자이다.  이 항목은 단편들을 재합성하는데 있어 단편들의 연결 조각을 식별하기 위해 사용된다.

 

Flags
DF(Don't Fragment)와 MF(More Fragment) 두 비트는 단편화의 경우 패킷의 처리를 제어한다.  만약 DF 비트가 세트되면 IP 패킷은 어떠한 상황에서도, 예를 들어 더 이상 전달되지 못하고 버려져야 하는 경우에도 단편화되지 않는다.  MF 비트는 더 이상의 추가적인 서브 패킷이 있는 지를 나타낸다.  이 항목의 첫 비트는 사용되지 않는다.  단편화의 알고리즘은 이 장의 뒷부분에서 더 자세히 알아보겠다.

 

Fargment offset
MF 비트가 세트되었다면 이 항목은 패킷에 든 서브 메세지의 전체 메세지의 시작으로부터의 상대적인 위치를 나타낸다.  수신 호스트는 이 항목을 이용하여 원래의 패킷으로 올바르게 재합성할 수 있다.  위에서 언급한 플래그로 인하여 이 항목은 13비트의 크기를 가진다. 그래서 오프셋은 8바이트 단위로 계산되며 결국 IP 패킷의 최대 길이는 65,535(8*213 - 1)이다.

 

Time to live
송신 호스트는 패킷이 버려지기까지 얼마나 오랫동안 네트워크상에 존재할 수 있는 지를 확정한다.  RFC 791은 이 항목에서 사용되는 단위를 초로 명세하고 있으며 비록 처리 시간이 1초미만이라도 각각 노드는 이 값을 최소한 1 이상 감소할 것을 요구한다.  따라서 TTL은 일반적으로 패킷이 지나갈 수 있는 최대의 노드의 수와 같다.  만약 이 항목이 0의 값을 갖는다면 현재의 처리기에 의해서 이 패킷은 버려져야 한다.  이로서 패킷이 네트워크에서 무한정 회전하는 것을 막을 수 있다.  이 경우 송신 개체는 이 사건(수명이 다한 패킷의 폐기)에 대한 ICMP 메세지를 받게 된다.  대체로 UNIX 시스템은 이 값을 15(4.2BSD)에서 30(4.3BSD)사이의 값으로 설정한다. 4.2BSD에 기반한 오래된 IP 구현에서는 이 항목의 값을 5씩 감소시킨 반면 새로운 버전에서는 단지 1씩만 감소시킨다.

 

Transport protocol
이 항목은 패킷이 전송되어져야 할 트랜스포트 프로토콜의 ID를 담는다.  예를 들어 TCP인 경우 6을, UDP인 경우 17을, ICMP인 경우 1의 값을 갖는다.  이러한 값들은 NIC에 의하여 결정된다.  현재 대략 50개의 공식적인 상위 프로토콜들이 존재한다.  표.3.1에 현재 번호가 할당되어진 트랜스포토 프로토콜들의 예가 나와있다.

 

No                Abbreviation          Name
1                  ICMP                      Internet Control Message
2                  IGMP                      Internet Group Management
3                  GGP                       Gateway-to-Gateway
6                  TCP                        Transmission Control
17                UDP                        User Datagram
29                ISO TP4                  ISO Transport Protocol Class 4
86                DGP                        Dissimiliar Gateway
89                OSPF                      Open Shortest Path First

 

Header checksum
이 항목은 프로토콜 헤더에 대한 체크섬을 갖는다.  이것을 통하여 호스트는 노드들이 잘못된 데이타를 이용하여 작업하는 것을 막을 수 있다.  효율성을 위하여 사용자 데이타에 대한 검사는 하지 않는다.  IP 패킷은 모든 노드에서 TTL 항목을 감소시키기 위하여 변경된다.  따라서 체크섬이 매우 효율적으로 생성되는 것이 매우 중요하다.  TCP/IP 구조에서는 모든 프로토콜에 Internet checksum이라는 방법이 사용된다.  이것은 검사대상이 되는 데이타를 16비트의 크기의 워드로 나누어 합하고 이것의 결과인 16비트 크기의 값에 대하여 다시 1의 보수를 취하여 얻어진다.
이 알고리즘은 간단하고 빨르다. 이것은 노드들의 효율적인 작동을 위하여 필요한 것이다.  그러나 이 방벙의 에러 감지의 능력은 한정되어 있다.  단순히 덧셈으로만 이루어져 있으므로, 예를 들어 0으로만 이루어진 16비트 워드가 분실되는 경우 이것을 감지할 수 없다.  TCP와 UDP의 체크섬은 데이타 항목뿐만 아니라 감지되지 않은 데이타의 분실을 실질적으로 제거하기 위해 다른 항목들(길이, 송신 개체, 수신 개체등등)까지 검사한다.

 

Source and destination address
32비트 크기의 Internet address가 이 부분에 들어간다.

 

Options and padding
특별한 작업(네트워크 관리, 보안)등을 위하여 IP 프로토콜의 헤더는 다음에 알아볼 추가사항들을 포함하도록 확장된다.  IP 프로토콜 헤더의 크기는 4의 배수가 되도록 하기 위하여 필요한 경우 padding 문자들을 삽입한다.

 

[출처] [본문스크랩] IP헤더|작성자 문수