2013-12-08 3 views
0

IP RFC를 읽고 거기에 IP 헤더의 4 번째 비트가 버전이라고 말합니다. 도면에서 비트 0 ~ 3이 버전임을 보여줍니다.IP 헤더 비트 순서가 확실하지 않습니다.

http://tools.ietf.org/html/rfc791#section-3.1

하지만이 바이트 참조 (PCAP lib 디렉토리를 사용하여 캡처로) 나는 헤더의 첫 번째 바이트를 볼 때 :

0x45

이 버전 4 IP 헤더하지만 분명히을 비트 4 ~ 7은 4와 같고 비트 0 ~ 3이 아닙니다.

비트 단위로 첫 번째 바이트를 수행하고 0x0F는 나에게 버전을 가져다 줄 것으로 예상되지만 0xF0과 함께 사용해야합니다.

내가 누락 된 항목이 있습니까? 잘못 이해하고 계신가요?

+1

endianness (http://en.wikipedia.org/wiki/Endianness) 문제와 비슷합니다. – erenon

+1

나는 엔디안에 대해서도 생각했지만 그가 올바른 결과를 얻고 있음을 깨달았다. @ 모르 메시 올 응답이 맞습니다. –

+2

"endianness"sensu stricto는 바이트 안에 _bits_의 번호 매기기가 아니라 큰 구조 안에서 _bytes_의 순서를 나타냅니다. – Mormegil

답변

4

당신은 RFC의 Appendix B을 읽어야 할 사람 :

옥텟이 숫자 양에게 그림의 가장 왼쪽 비트를 표시 할 때마다

은 상위 또는 최상위 비트입니다. 즉, 0으로 표시된 비트 이 최상위 비트입니다. 예를 들어, 다음 다이어그램은 값 170 (십진수)을 나타냅니다. 모든 것을 의미

     0 1 2 3 4 5 6 7 
         +-+-+-+-+-+-+-+-+ 
         |1 0 1 0 1 0 1 0| 
         +-+-+-+-+-+-+-+-+ 

그가 가장 -significant있는 동안 "처음 4 비트는"가장 -significant 것을 당신의 가정을 제외하고 정확합니다.

예. (더 중요한 왼쪽으로 이동하는 것이

byte flagsAndFragmentHi = packet[6]; 
byte fragmentLo = packet[7]; 
bool flagReserved0 = (flagsAndFragmentHi & 0x80) != 0; 
bool flagDontFragment = (flagsAndFragmentHi & 0x40) != 0; 
bool flagMoreFragments = (flagsAndFragmentHi & 0x20) != 0; 
int fragmentOffset = ((flagsAndFragmentHi & 0x1F) << 8) | (fragmentLo); 

참고 : 7, 8 바이트, 플래그 다음과 같이, 당신은 사람들을 분리 할 수 ​​오프셋 단편을 함유하는 (이 C# .NET을하고있다하더라도, 그 의사를 고려) 8 비트) 부분은 첫 번째 바이트에 있습니다 (IP는 빅 엔디안에서 작동하기 때문에). 일반적으로 다이어그램의 왼쪽에있는 비트는 항상 더 중요합니다.

+0

이것은 숫자 필드에만 적용됩니다. 플래그 필드는 바이트의 왼쪽 비트에 표시 되더라도 하위 비트입니다. 그러나 일곱 번째 바이트는 플래그와 숫자 필드의 일부인 조각 오프셋으로 구성됩니다. 그걸 분명히 해줄 수 있니? – selalerer

+1

예를 추가했습니다. 그리고 아니요, 플래그는 높은 (더 중요한) 비트입니다. 왜냐하면 다이어그램의 왼쪽 (낮은 번호가 매겨진) 비트에 표시되기 때문입니다. – Mormegil

+0

고맙습니다. 그것은 나를 위해 일들을 명확히했습니다 :-) – selalerer

관련 문제