DoIP 프로토콜 구조 뜯어보기, 헤더와 필드는 어떻게 생겼나

지난 글에서는 DoIP를 큰 그림으로만 봤죠.
이번엔 진짜로 프로토콜 구조 쪽으로 들어가보려 합니다.

DoIP 처음 볼 때 제일 헷갈리는 건
용어보다도 패킷을 어디서부터 읽어야 하는지인 느낌이 팍팍 옵니다.

와 이게 단순히 “이더넷 진단이다” 수준이 아니라,
실제로는 헤더부터 payload까지 순서대로 보는 감각이 필요하더라고요.

이번 글은 그쪽만 딱 봅니다.
길게 안 가고,
DoIP Generic Header,
핵심 필드 의미,
어디를 먼저 봐야 하는지
이 정도로만 정리해보겠습니다.

먼저, DoIP 패킷은 이런 틀로 본다

가장 먼저 눈에 익혀야 하는 건 이 구조입니다.

DoIP Generic Header

+------------------------+
| Protocol Version       | 1 byte
+------------------------+
| Inverse Version        | 1 byte
+------------------------+
| Payload Type           | 2 bytes
+------------------------+
| Payload Length         | 4 bytes
+------------------------+
| Payload                | N bytes
+------------------------+

한 문장부터 가보면 이겁니다.

DoIP는 앞에 공통 헤더가 붙고, 그 뒤 payload가 메시지 타입에 따라 달라지는 구조입니다.

즉 패킷을 볼 때
무조건 앞에서부터 순서대로 보면 됩니다.

버전 확인
반전 버전 확인
이 메시지가 무슨 타입인지 확인
길이 확인
그다음 payload 해석

이 순서가 기본입니다.

Protocol Version은 말 그대로 버전이다

이건 이름 그대로입니다.
현재 DoIP 프로토콜 버전을 나타내는 필드죠.

처음 보면 별거 아닌데,
실제로는 상대가 어떤 버전으로 말하고 있는지 보는 기본 정보라서 중요합니다.

패킷 볼 때 맨 앞 1바이트라
구조를 잡을 때 기준점 역할도 합니다.

Inverse Version은 왜 붙어 있냐

이 부분에서 처음에 한 번 멈칫하죠.

“버전은 알겠는데 반전 버전은 또 뭐지?”

쉽게 말하면
버전 필드를 한 번 더 검증하는 느낌으로 보면 됩니다.

즉 Protocol Version과 서로 반대값 관계를 가지도록 해서
헤더가 정상인지 빠르게 확인하는 데 도움을 줍니다.

예를 들어 이런 식이죠.

Protocol Version        = 0x02
Inverse Protocol Version= 0xFD

이런 구조는 실무에서 꽤 익숙합니다.
헤더 일부가 깨졌거나 해석이 꼬였을 때
이런 반전 값이 있으면 이상 여부를 빨리 감지하기 좋죠.

강력 추천합니다!
처음 패킷 볼 때는 이 필드도 같이 보는 습관을 들이면 좋습니다.

Payload Type이 진짜 핵심이다

여기서부터 패킷 성격이 갈립니다.

Payload Type은
뒤에 오는 payload가 어떤 메시지인지 알려주는 필드입니다.

즉 같은 DoIP 패킷이어도
이 값에 따라 의미가 달라집니다.

예를 들면 큰 분류만 봐도 이런 메시지들이 있죠.

Vehicle Identification 관련
Routing Activation 관련
Alive Check 관련
Diagnostic Message 관련

즉 실무에서는 패킷을 봤을 때
제일 먼저 “아 이게 무슨 용도의 패킷이구나”를 알려주는 게 Payload Type입니다.

한마디로
Payload Type은 DoIP 패킷 해석의 분기점입니다.

Payload Length는 생각보다 더 중요하다

이건 뒤 payload 길이를 나타내는 필드입니다.

말만 보면 단순하죠.
근데 실제로는 이게 꽤 중요합니다.

왜냐면 패킷 볼 때 이런 걸 바로 판단할 수 있기 때문입니다.

길이가 정상인가
실제 캡처 길이와 맞는가
payload 해석 범위가 어디까지인가
잘린 패킷인지 아닌지

예를 들어 헤더는 맞는데 길이가 이상하면
뒤 해석이 전부 꼬일 수 있습니다.

그래서 저는 패킷 볼 때
Payload Type만큼이나 Payload Length도 꼭 같이 봅니다.

아주 단순한 예로 보면 이런 느낌이다

예시를 아주 단순화해서 보면 이렇습니다.

02 FD 00 05 00 00 00 0C ...

이걸 RFC 느낌으로 끊어보면:

+------------------------+
| 0x02                   | Protocol Version
+------------------------+
| 0xFD                   | Inverse Version
+------------------------+
| 0x0005                 | Payload Type
+------------------------+
| 0x0000000C             | Payload Length
+------------------------+
| ...                    | Payload
+------------------------+

이런 식으로 보면 훨씬 덜 무섭습니다.

처음엔 hex만 길게 보면 머리가 아픈데,
필드 단위로 끊어보면
“아 앞 8바이트는 공통 헤더구나”
이 감각이 생깁니다.

그래서 패킷을 실제로 볼 때는 뭘 먼저 보냐

저는 보통 이 순서로 봅니다.

1) Protocol Version / Inverse Version

헤더가 정상 구조인지 먼저 봅니다.

2) Payload Type

이 패킷이 무슨 목적의 메시지인지 확인합니다.

3) Payload Length

길이가 정상인지 확인합니다.

4) Payload 해석

이제 메시지 타입에 맞춰 뒤 payload를 봅니다.

이 순서가 좋은 이유는 단순합니다.
앞 헤더가 이상한데 뒤를 열심히 읽어봐야 시간만 날리거든요.

정말로 말이야,
패킷 분석은 앞에서부터 보는 습관이 중요합니다.

메시지 타입별 payload는 왜 다음 단계로 미뤄야 하냐

여기서 욕심내면 한 글이 너무 길어집니다 ^^;;

Payload Type까지만 봐도
뒤에 해석할 구조가 꽤 갈리기 때문이죠.

예를 들어 payload는 타입에 따라 전혀 성격이 달라집니다.

Vehicle Identification이면 식별 정보 쪽
Routing Activation이면 활성화 요청/응답 쪽
Alive Check면 연결 상태 확인 쪽
Diagnostic Message면 실제 진단 데이터 쪽

즉 공통 헤더까지는 같은데,
그 뒤는 메시지 성격에 따라 갈라집니다.

그래서 이번 글은
공통 헤더를 읽는 감각까지만 잡는 게 맞습니다.

나쁜 접근 vs 좋은 접근

이것도 차이가 큽니다.

나쁜 접근

hex dump 전체를 한 번에 보려 함
Payload Type 확인 안 하고 뒤부터 읽음
길이 체크 없이 payload 해석 시작
버전 필드를 무시함

좋은 접근

공통 헤더부터 끊어봄
Protocol Version / Inverse Version 확인
Payload Type으로 분기
Payload Length 확인 후 payload 해석

패킷 분석은 이런 기본 순서만 잡아도
헷갈림이 확 줄어듭니다.

실무에서 제일 먼저 익숙해져야 하는 건 “헤더 8바이트”다

이 글에서 진짜 핵심은 이겁니다.

DoIP를 보다가 복잡해지는 이유 중 하나가
payload 구조까지 한 번에 다 보려 하기 때문입니다.

근데 실제로는
앞 8바이트 Generic Header부터 익숙해지는 게 먼저입니다.

+------------------------+
| Protocol Version       | 1 byte
+------------------------+
| Inverse Version        | 1 byte
+------------------------+
| Payload Type           | 2 bytes
+------------------------+
| Payload Length         | 4 bytes
+------------------------+

이거만 눈에 익어도
패킷을 볼 때 훨씬 덜 막막해집니다.

며칠 밤을 새웠던 기억까지는 아니지만 ^^;;
저도 프로토콜 볼 때 처음부터 payload 세부 필드 다 외우려다가 더 헷갈렸던 적이 있습니다.
오히려 공통 헤더부터 손에 익히는 쪽이 훨씬 빨랐습니다.

다음 글에서는 뭘 보면 좋냐

여기까지 왔으면 그다음은 자연스럽습니다.

다음엔 이런 쪽으로 더 들어가면 됩니다.

Vehicle Identification payload 구조
Routing Activation request / response 구조
Diagnostic Message payload 구성
실제 캡처 예시 기반 해석

즉 이제부터는
“공통 헤더 뒤에 각 메시지 타입이 어떻게 붙는지”
그걸 보면 됩니다.

한 줄 요약

DoIP 패킷은 공통 헤더 8바이트부터 읽고, 그다음 Payload Type과 Length를 기준으로 payload를 해석하면 훨씬 정리가 잘 된다.