IGMP

hi2li·2026년 4월 27일
  • 호스트가 멀티캐스트 그룹에 가입/탈퇴할 때 사용하는 프로토콜
    • 멀티캐스트 : 특정 그룹에게만 데이터를 전송하는 방식.
  • 같은 LAN에 있는 “가장 가까운 라우터 1대”랑만 통신함
  • Report: 호스트가 라우터에게 “나 이 그룹에 참여 중(또는 참여할 것)”을 알리는 메시지
  • Query: 라우터가 호스트에게 “이 멀티캐스트 그룹을 아직 사용 중인지” 확인하는 메시지
  • Leave: 호스트가 라우터에게 “이 그룹에서 탈퇴한다”고 알리는 메시지




네트워크 구조

[멀티캐스트 서버]
        |
        |  멀티캐스트 데이터
        v
[상위 라우터들]
        |
        |  PIM 같은 멀티캐스트 라우팅 프로토콜
        v
**[우리 LAN의 라우터]**
        ^
        |  IGMP
        |  가입 / 탈퇴 / 응답
        v
   ---[스위치]----------
   |        |        |
 [PC1]    [PC2]    [PC3]

핵심:
PC ↔ 우리 LAN의 라우터 : IGMP
라우터 ↔ 라우터       : PIM 등 멀티캐스트 라우팅
서버 → PC             : 실제 멀티캐스트 데이터




시나리오

[멀티캐스트 서버]
        |
        v
[여러 라우터들]
        |
        v
[우리 LAN의 라우터]
        |
        v
      [스위치]
   |      |      |
 [PC1]  [PC2]  [PC3]

1. IGMP Report

처음에 PC1이 어떤 멀티캐스트 방송(예: 239.1.1.1)을 보고 싶다고 하자.

이때 PC1은 네트워크 전체에 말하는 게 아니라, 같은 LAN 안에 있는 라우터에게 신호를 보낸다.

이게 IGMP Report 메시지다.

즉,

“이 네트워크에서 이 방송 보고 싶은 사람 있어요”라고 알리는 단계다.

2. 멀티캐스트 메시지 라우팅 (PIM)

그 다음은 라우터의 역할이다.

LAN에 있는 라우터는 이 메시지를 받고

“아, 이 네트워크에서 이 그룹을 원하는 사람이 있네”라고 판단한다.

그래서 라우터는 자기 위쪽에 있는 다른 라우터들한테 요청을 보낸다.

이때는 IGMP가 아니라 PIM 같은 멀티캐스트 라우팅 프로토콜을 사용한다.

결과적으로 데이터 흐름은 이렇게 만들어진다.

서버 → 상위 라우터 → 우리 LAN의 라우터 → PC1


여기서 중요한 포인트는

PC는 오직 “우리 LAN의 라우터 1대”랑만 대화한다는 점이다.

다른 라우터들과는 직접 아무 통신도 하지 않는다.



3. IGMP Query

시간이 지나면 LAN의 라우터가 다시 확인을 한다.

“아직 이 방송 보는 사람 있어?”라고 물어보는데, 이게 IGMP Query다.

PC1이 계속 보고 있다면 다시 “나 아직 있음”이라고 응답한다.



4. Leave

만약 PC1이 방송을 끄면,

“나 이제 안 봄”이라는 Leave 메시지를 보낸다.

그리고 만약 이 LAN에서 아무도 그 방송을 안 본다면

라우터는 위쪽 라우터들에게 “이제 이 데이터 안 보내도 됨”이라고 알려서

멀티캐스트 트래픽이 끊기게 된다.



정리하면 이 흐름 하나만 기억하면 된다.

PC ──(IGMP)──> 같은 LAN 라우터 ──(PIM)──> 다른 라우터들 ──> 서버
                        

주의해야할 점은 IGMP는 “LAN 안에서 라우터 1대와 그룹 참여를 조율하는 프로토콜”이라는 것이다.

profile
easy come , easy go

0개의 댓글