Netflix, Spotify와 같은 스트리밍 서비스의 대성공 이후 IP 멀티캐스팅은 인터넷에서 없어서는 안될 전송 방식이 되었습니다. 이 기술 절차를 통해 발신자는 데이터 스트림을 전체 수신자 그룹에 보낼 수 있으므로 전송 및 라우팅 용량을 최적으로 사용할 수 있습니다 . 이 전송 방법이 없으면 발신자는 각 수신 장치에 별도의 데이터 패킷을 보내야 하므로 엄청난 대역폭이 필요하고 빠르게 과부하가 발생합니다. 이렇게 하면 서비스를 영구적으로 사용 가능한 상태로 유지하는 것이 사실상 불가능합니다.
IGMP(Internet Group Management Protocol)는 IPv4 네트워크에서 이러한 멀티캐스트 수신기 그룹을 구성 하는 데 중요한 역할을 하는 프로토콜입니다 .
인터넷 그룹 관리 프로토콜이란 무엇입니까?
인터넷 그룹 관리 프로토콜은 스탠포드 대학에서 개발된 TCP/IP 계열 통신 프로토콜 로 1989년 RFC 1112 에 처음 지정되었습니다 . 첫 번째 프로토콜 버전 IGMPv1에 이어 개정된 버전 IGMPv2( RFC 2236 ) 및 IGMPv3( RFC 3376 , RFC 4604 )이 뒤따랐습니다. 버전은 항상 이전 버전과 호환됩니다. 즉, IGMPv3 장치는 자동으로 버전 1 및 2를 지원합니다. 인터넷 그룹 관리 프로토콜은 IPv4 네트워크를 독점적으로 담당합니다. IPv6 네트워크에서는 유사한 MLD(Multicast Listener Discovery) 가 기능을 인수합니다.
IGMP의 기본 작업은 IP 멀티캐스트 전송을 위한 동적 그룹을 관리 하는 것이므로 이 관리는 전송 장치 자체를 통해 실행되지 않고 통합 라우터를 통해 실행됩니다. 한편으로 이들은 수신기 장치(또는 각각의 하위 라우터)로부터 특정 멀티캐스트 그룹에 포함하기 위한 요청을 수신합니다. 반면에 적절한 멀티캐스트 데이터 패킷을 수신하면 IGMP 메시지 를 적절한 상위 라우터로 전달합니다. 송신 스테이션은 단일 데이터 패킷 만 상위 라우터로 전달하기 때문에 어떤 엔드 스테이션과 얼마나 많은 송신 패킷이 도달했는지에 대한 정보를 수신하지 않습니다 .
IGMP는 어떻게 작동합니까?
IGMP를 통한 그룹 관리는 소포 발송인의 책임이 아님을 이미 언급했습니다. 그러나 관련된 네트워크의 다른 모든 스테이션(수신기 포함)과 마찬가지로 이 출력 호스트는 멀티캐스트 연결을 지원 해야 합니다 . 특정 멀티캐스트 그룹에 포함하기 위한 클라이언트 요청을 수신하고 멀티캐스트 데이터 스트림이 들어오는 경우 클라이언트에 알리는 것은 발신자와 수신자 사이의 경로에 있는 개별 네트워크 라우터에 의해 처리됩니다.
이를 위해 인터넷 그룹 관리 프로토콜은 스테이션이 할당된 라우터에 멀티캐스트 그룹에 포함될 것임을 알리는 데 사용할 수 있는 기능을 제공합니다. 반면에 라우터는 특정 IP 멀티캐스트 데이터 스트림을 수신하는 수신기 장치의 나가는 인터페이스 를 기억 하여 해당 데이터가 수신되는 즉시 특정 보고서를 보낼 수 있습니다. 멀티캐스트 그룹은 224.0.0x 범위 의 특정 주소가 특징 입니다. 대부분의 경우 장치에 대한 첫 번째 접촉 지점은 홈 인터넷 라우터 이며, 이 라우터는 멤버십 애플리케이션을 수신하고 이를 다음 네트워크 노드(일반적으로 인터넷 서비스 제공업체의 라우터)로 전달합니다. 이것통신 체인은 데이터 스트림 송신기의 라우터로 끝납니다. 라우터는 서비스할 나가는 인터페이스가 여러 개 있는 경우 필요한 경우 IP 패킷을 차례로 복제합니다.
개별 IGMP 버전은 어떻게 다릅니까?
세 가지 출판된 인터넷 그룹 관리 프로토콜 버전은 공통점이 많습니다. IGMPv2와 IGMPv3는 주로 기능적으로 전임자를 확장한 반면, 일반 요청에 대한 그룹 주소(0.0.0.0)와 같은 기본 기능은 그대로 유지했습니다. 그러나 각각의 확장은 어떻게 생겼습니까?
IGMPv1: 인터넷 그룹 관리 프로토콜의 기초
IGMPv1은 몇 가지 기본 기능을 포함하는 통신 프로토콜의 최초 공개 버전이며, 그 중 많은 기능은 최신 버전에서도 찾아볼 수 있습니다. 0.0.0.0은 이미 IGMPv1에 대해 그룹 주소 로 정의되어 있고 224.0.0.1은 일반 IGMP 요청에 대한 대상 주소로 정의되어 있습니다. 라우터에서 자동으로 보내는 이러한 요청의 기본 간격은 60초 입니다. IGMPv1을 사용하면 모든 지원 호스트가 적절한 멀티캐스트 그룹에 참여할 수 있습니다. 멤버십 요청은 보고서 형식으로 해당 IP 멀티캐스트 주소로 전송됩니다. 후속 프로토콜과 달리 IGMPv1에는 호스트가 스스로 그룹을 떠날 수 있는 기능이 여전히 부족합니다. 시간 초과만 해당 호스트를 속한 그룹에서 제거합니다.
모든 IGMP 메시지는 IP 프로토콜 번호 2(Hex: 0x02)를 사용하는 단순 IP 패킷으로 전송됩니다. 첫 번째 프로토콜 버전의 IGMP 헤더는 다음과 같습니다.
IGMP 헤더의 총 길이는 64비트 입니다. 처음 8비트는 항상 프로토콜 버전 IGMPv1과 메시지 유형을 지정합니다. 필드(유형)에는 "1"(멤버십 요청용) 및 "2"(멀티캐스트 데이터 스트림에 대한 알림용)의 두 가지 옵션이 있습니다. 비트 8~15가 뒤따르지만 기능이 없고 0으로만 구성됩니다. 첫 번째 32비트 블록은 체크섬 으로 끝납니다 . IGMP 알림 패키지인 경우 32비트 길이의 그룹 주소 가 뒤따릅니다.
프로토콜 라인 자체의 원래 버전은 멀티캐스트 쿼리에 사용해야 하는 라우터를 지정하지 않습니다 (멀티캐스트 라우팅 프로토콜에 의해 규제됨).
IGMPv2: 탈퇴 메시지 및 그룹별 메시지 유형 도입
IGMPv2 사양은 1997년부터 시작되었으며, 이는 프로토콜의 첫 번째 출판 이후 약 8년 후에 표준의 첫 번째 개정판이 등장했음을 의미합니다. 자동 요청에 대한 그룹(0.0.0.0) 및 대상(224.0.0.1) 주소는 변경되지 않았지만 기본 내부 기간은 125초로 증가했습니다 . 그러나 IGMPv2의 가장 중요한 새 기능은 로그오프 프로세스의 속도가 빨라졌다는 것입니다. 첫 번째 프로토콜 변형에 필요한 시간 초과는 호스트가 "퇴장" 메시지 를 통해 시작한 로그오프 프로세스로 대체됩니다 . 이 메시지 유형의 대상 주소는 224.0.0.2 입니다.
두 번째 버전의 통신 프로토콜의 또 다른 새로운 기능: 그룹별 메시지를 사용하여 특정 멀티캐스트 주소의 수신 상태를 결정할 수 있습니다.
IGMPv2 메시지 는 IP 프로토콜 번호가 2인 단순 IP 패킷으로 도 캡슐화됩니다 . 그러나 IGMP 헤더 가 약간 변경되었습니다 .
헤더 행은 첫 번째 로그 버전과 유사하게 시작하지만 버전 번호를 지정하지 않습니다. 가능한 유형 코드 는 "0x11"(요청용), "0x16"(알림용) 및 "0x17"(메시지 남기기)입니다. 이전 버전과의 호환성 을 위해 IGMPv1 알림에 대한 코드 "0x12"도 있습니다. 비트 8 ~ 15는 IGMPv2의 구체적인 기능(적어도 회원 요청에 대해서는)을 수신하고 허용되는 최대 응답 시간 을 정의합니다 . 그 다음에는 체크섬(16비트)과 그룹 주소(32비트)가 따르며, 이는 차례로 일반 요청의 경우 일반적인 프로토콜 형식 0.0.0.0을 갖습니다.
IGMPv2 는 서브넷에서 가장 낮은 IP 주소를 가진 라우터가 멀티캐스트 쿼리에 사용되는 규칙을 지정합니다.
IGMPv3: 선택 가능한 멀티캐스트 소스를 통한 보안 강화
Internet Group Management Protocol의 세 번째 버전인 IGMPv3는 2002년 10월에 릴리스되었습니다. 0.0.0.0은 그룹 주소이고 224.0.0.1은 일반 요청의 대상 주소입니다. 표준 간격 과 관련하여 프로토콜 버전은 125초의 직접적인 이전 버전을 기반으로 합니다 . 새로운 기능은 멀티캐스트 스트림의 소스를 선택 하는 옵션 입니다. 이러한 소위 소스별 멀티캐스팅은 네트워크에 대한 요구를 크게 줄이고 전송 중 보안을 강화 합니다 . 왜냐하면 어떤 소스나 알 수 없는 소스가 사용되지 않기 때문입니다.
IGMP 헤더는 IP 패킷(프로토콜 번호 2)의 IGMPv3에도 통합되어 있지만 소스 주소를 지정할 가능성이 있기 때문에 두 개의 이전 프로토콜보다 훨씬 더 복잡합니다. 요청과 알림 간에도 구체적인 차이점이 있습니다. IGMPv3 그룹 요청 의 헤더는 다음과 같습니다.
처음 두 개의 32비트 시퀀스는 IGMPv2 헤더의 유형, 최대 응답 시간, 체크섬 및 그룹 주소와 동일합니다. IGMPv3는 또한 이전 프로토콜 버전과 교환할 수 있는 가능성을 제공 합니다. 이 목적을 위해 버전 1의 경우 "0x12" 코드 및 버전 2의 경우 "0x16" 코드를 호스트에서 사용할 수 있습니다. 그룹 주소 이후에 IGMPv3 쿼리별 헤더 부분 이 시작되며, 그 중 처음 32비트는 다음과 같이 구성됩니다.
- Res: 기능이 없고 0만 포함하는 예약된 4비트 필드
- S (suppress router-side processing) : 라우터를 "1"로 설정하여 요청을 수신할 때 정상적인 업데이트를 억제해야 함을 나타내는 S 플래그(값이 "0"인 경우 필드는 비활성화됨)
- QRV(Querier's Robustness Variable) : 3비트, 요청 호스트에서 사용하는 "강력성 변수" 값을 포함할 수 있음
- QQIC(Querier's Query Interval Code) : IGMPV3 쿼리의 간격을 지정하는 데 사용되는 8비트 필드
- Number of source addresses : 아래 나열된 발신지 주소 수
여러 소스를 정의해야 하는 경우 이 매우 구체적인 정보 뒤에 소스 주소 또는 개별 소스 주소 목록 (각각 32비트)이 옵니다.
이전 버전과 달리 IGMPv3에서는 호스트가 한 그룹에 가입하고 다른 그룹을 단일 트랜잭션으로 남길 수 있습니다. IGMPv2는 여전히 두 개의 개별 메시지가 필요합니다.
인터넷 그룹 관리 프로토콜은 언제 사용됩니까?
IGMP의 역할은 명확하게 정의 되어 있습니다. 인터넷과 같은 IPv4 네트워크에서 멀티캐스트 전송이 필요한 경우 통신 프로토콜이 항상 사용됩니다. 클래식 배포 시나리오는 웹 회의 도구 또는 라이브 스트리밍 서비스 와 같은 다중 지점 연결을 통해 실행되는 실시간 응용 프로그램 입니다 . 모든 클라이언트에 필요한 데이터 스트림을 개별적으로 제공해야 하는 것은 아닙니다. 이렇게 하면 출력 서버와 네트워크 노드가 빠르게 과부하될 수 있기 때문입니다.
댓글