#doip 수정: 2026-05-21 글 Vullean

DoIP 통신이 가끔 끊긴다: Alive Check / TCP Keepalive / Tester Present를 분리해서 보자

DoIP는 TCP라서 붙기만 하면 끝인 줄 아는데, 실무에서는 가만히 두면 어느 순간 세션이 끊기는 경우가 많다. Alive Check, TCP Keepalive, UDS Tester Present는 목적이 다르다. 끊김을 줄이려면 이 셋을 분리해서 설계해야 한다.

DoIP 발행일: 2026-05-21 예상 읽기 시간: 약 4분 작성: Vullean DoIP Tester Present Routing Activation Alive Check TCP Keepalive UDS session timeout

DoIP는 TCP라서 “연결만 되면 됐다”라고 생각하기 쉬운데,
실무에서는 가만히 두면 어느 순간 죽는 경우가 생각보다 많다.

  • 초기 연결 OK
  • Routing Activation OK
  • UDS도 잘 된다
  • 근데 3분/10분/한참 뒤에 갑자기 응답이 안 온다

이때 흔히 하는 실수가 이거다.

Alive Check를 붙이면 UDS 세션도 유지될 거라고 착각한다

결론부터 말하면,
Alive Check / TCP Keepalive / Tester Present는 목적이 다르다.

오늘은 “끊김”을 줄이기 위해
이 3개를 어떻게 나눠서 보면 되는지 정리해본다.

세 가지 keep-alive를 한 줄로 구분

실무에서 끊김 이슈는 대부분 여기 셋 중 하나다.

  • TCP Keepalive: 네트워크/방화벽/NAT 관점에서 “연결이 살아있다”를 유지
  • DoIP Alive Check: DoIP Entity 관점에서 “이 TCP 세션이 유효하다”를 확인
  • UDS Tester Present(0x3E): ECU 진단 세션 관점에서 “진단 세션을 유지” (세션 타이머 리셋)

셋을 섞어서 보면 원인 파악이 늦어진다.

1) TCP Keepalive: “패킷이 안 오면 중간 장비가 끊는다”

DoIP는 기본적으로 TCP 위에서 돈다.
근데 TCP는 “애플리케이션 데이터”가 없으면 조용하다.

이 구간에서 흔히 마주치는 게 이런 것들이다.

  • 스위치/라우터/방화벽의 idle timeout
  • 테스터 PC의 NIC 절전/전원 정책
  • VLAN/게이트웨이 쪽 세션 테이블 정리

이건 DoIP가 아니라 네트워크 레벨 이슈다.

그래서 TCP Keepalive는 “DoIP 기능”이라기보단
네트워크 장비에 의해 세션이 정리되는 걸 줄여주는 쪽이다.

체크 포인트는 단순하다.

  • Wireshark에서 FIN/RST가 누가 보냈는지 본다
  • OS 레벨 TCP keepalive가 켜져 있는지/주기가 너무 긴지 본다

2) DoIP Alive Check: “DoIP Entity가 이 세션을 계속 인정하냐”

Alive Check는 DoIP 레벨의 확인 메시지다.
의미는 대략 이거다.

“너(테스터) 아직 살아있냐?”

실무 포인트는 이거다.

  • TCP는 살아있는데 DoIP Entity가 내부 상태를 정리했을 수 있다
  • 이 경우엔 UDS를 보내도 “무응답”처럼 보이기도 한다

그래서 “TCP 연결은 유지됐는데 DoIP가 먹통” 느낌이면
Alive Check 쪽을 먼저 의심해보는 게 빠르다.

3) UDS Tester Present: “진단 세션 타이머는 따로 돈다”

UDS 세션은 보통 별도 타이머가 있다.
진단 툴이 잠깐 멈추거나, 주기가 느려지면 ECU가 이렇게 판단한다.

“테스터가 떠났네. 세션 닫자”

여기서 중요한 건,
TCP/DoIP가 살아있어도 UDS 세션은 죽을 수 있다는 거다.

즉:

  • Alive Check를 잘 보내도
  • TCP keepalive를 잘 켜도
  • ECU는 세션 타이머로 진단 세션을 종료할 수 있다

그래서 “세션 유지” 목적이라면
결국 Tester Present를 설계에 넣어야 한다.

구현할 때 흔한 함정 3개

1) Tester Present를 무조건 주기 전송

무조건 보내면 편하긴 한데,
ECU/게이트웨이에 따라 부담이 될 수 있다.

실무에서는 보통 이렇게 나눈다.

  • “진단 세션이 열려있는 동안만” 전송
  • 데이터 전송이 활발한 구간에서는 생략 (요청이 곧 keep-alive 역할)

2) 끊김 후에 Routing Activation을 재시도 안 함

끊겼다가 자동 재연결만 해놓고
Routing Activation을 다시 안 하는 경우가 있다.

이러면 UDS를 아무리 보내도
차량 쪽에서 그냥 무시한다.

끊김 복구 플로우는 보통 이거다.

TCP 재연결
→ Routing Activation 재요청
→ UDS 재시작

3) “무응답”을 전부 timeout으로만 처리

무응답이라고 다 같은 무응답이 아니다.

빠르게 분리하는 방법은 이거다.

  • TCP FIN/RST가 보인다 → 네트워크/OS 레벨부터
  • TCP는 살아있는데 DoIP만 먹통 → Alive Check / RA 상태 의심
  • UDS만 죽고 다른 DoIP 메시지는 살아있다 → Tester Present/세션 타이머 의심

디버깅 체크리스트 (짧게)

  1. 끊긴 시점에 Wireshark로 FIN/RST를 확인
  2. TCP 재연결이 됐으면 RA를 다시 했는지 확인
  3. 세션 유지가 목적이면 Tester Present 주기/조건을 확인
  4. “TCP OK + UDS 무응답”이면 Alive Check 응답이 오는지 확인
  5. 멀티 테스터 환경이면 다른 테스터가 세션을 밀어내는지 확인

한 줄 요약

DoIP 끊김은 하나가 아니라 TCP/DoIP/UDS 세 레이어 문제라서, Alive Check, TCP Keepalive, Tester Present를 분리해서 설계/디버깅해야 한다.

추천 키워드

DoIP, Alive Check, TCP Keepalive, Routing Activation, Tester Present, UDS session timeout

광고