업데이트됨 1개월 전
라즈베리 파이 하나로 월드컵을 백만 명의 시청자에게 스트리밍할 수 있습니다. 특별한 하드웨어가 있어서가 아니라, 멀티캐스트를 사용하면 스트림을 단 한 번만 전송하기 때문입니다. 나머지는 네트워크가 알아서 처리합니다.
이것이 멀티캐스트를 특별하게 만드는 핵심입니다. 발신자의 부담이 수신자 수에 비례해 늘어나지 않습니다. 열 명에게 보내든 만 명에게 보내든 — 같은 작업량, 같은 대역폭, 같은 서버 부하. 네트워크 자체가 지능적으로 동작하며, 수신을 원하는 곳에서만 데이터를 복제하고 전달합니다.
멀티캐스트란?
멀티캐스트는 단일 발신자가 여러 수신자에게 동시에 전송하는 일대다 통신입니다. 발신자는 하나의 스트림을 특수한 멀티캐스트 그룹 주소로 전송합니다. 네트워크 장치는 관심 있는 수신자가 있는 세그먼트에만 이 스트림을 복제해서 전달합니다.
라디오 방송처럼 생각하면 됩니다. 방송국이 한 번 송출하면, 해당 주파수에 맞춘 누구든 신호를 받습니다. 하지만 라디오와 달리, 멀티캐스트 수신자는 그룹에 가입하는 방식으로 명시적으로 구독해야 합니다.
구독하지 않으면 스트림을 받을 수 없습니다. 이는 원하지 않는 트래픽이 네트워크를 채우는 것을 막아줍니다.
유니캐스트, 브로드캐스트, 멀티캐스트
멀티캐스트가 무엇을 해결하는지 이해하려면, 같은 계열의 방식들과 비교해봐야 합니다.
유니캐스트는 두 당사자 간의 대화입니다. 발신자 하나, 수신자 하나. 웹 페이지를 불러오거나 이메일을 보낼 때 사용하는 방식입니다. 일대일 통신에는 효율적이지만, 여러 수신자가 동일한 데이터를 필요로 할 때는 낭비적입니다. 200명의 시청자에게 유니캐스트로 5 Mbps 영상을 스트리밍하려면 1,000 Mbps가 필요합니다 — 200개의 별도 스트림이 필요하기 때문입니다.
브로드캐스트는 원하든 원하지 않든 네트워크 세그먼트의 모든 장치에 전송합니다. 탐색 프로토콜("이 IP 주소를 가진 장치는 어디 있습니까?")에는 유용하지만, 콘텐츠 전달에는 비실용적입니다. 모든 장치가 자신과 무관한 트래픽도 처리해야 하기 때문입니다.
멀티캐스트는 그 균형을 잡습니다. 하나의 스트림이 관심 있는 여러 수신자에게 도달하면서도, 관심 없는 장치에는 부담을 주지 않습니다. 동일한 5 Mbps 영상을 200명의 시청자에게? 여전히 5 Mbps입니다. 효율성이 수신자 수에 비례하지 않고 일정하게 유지됩니다.
주소 공간
IPv4 멀티캐스트
IPv4는 멀티캐스트를 위해 224.0.0.0부터 239.255.255.255까지, 즉 전체 "클래스 D" 범위를 예약합니다. 그 안에서도 역할이 모두 같지는 않습니다.
224.0.0.0부터 224.0.0.255는 로컬에 머뭅니다. 라우터는 이 주소들을 서브넷 밖으로 전달하지 않습니다. 여기에 기본 그룹 주소들이 있습니다.
- 224.0.0.1 — 로컬 세그먼트의 멀티캐스트 가능한 모든 호스트
- 224.0.0.2 — 로컬 세그먼트의 모든 멀티캐스트 라우터
- 224.0.0.251 — 로컬 서비스 탐색을 위한 멀티캐스트 DNS
239.0.0.0/8은 사설 조직 내부 용도로, 유니캐스트에서 10.0.0.0/8이 쓰이는 것과 유사합니다. 회사 내부에서 별도의 조정 없이 이 주소들을 사용할 수 있습니다.
IPv6 멀티캐스트
IPv6는 더 깔끔한 방식을 택했습니다. ff로 시작하는 모든 주소가 멀티캐스트입니다. 다음 니블은 범위를 나타냅니다 — 멀티캐스트가 얼마나 멀리 전파될지를 정합니다.
- ff01:: — 노드 로컬 (단일 장치 내에 머뭄)
- ff02:: — 링크 로컬 (네트워크 세그먼트)
- ff05:: — 사이트 로컬 (캠퍼스 또는 건물)
- ff08:: — 조직 로컬
- ff0e:: — 글로벌
따라서 ff02::1은 "로컬 링크의 모든 노드"를 의미하고, ff0e::1은 "전 세계의 모든 노드"를 의미합니다. 같은 그룹 식별자이지만 도달 범위가 다릅니다.
IPv6는 요청 노드 주소(solicited-node address)도 도입합니다. 장치의 유니캐스트 주소로부터 멀티캐스트 그룹을 유도하는 영리한 방법입니다. 이를 통해 구성원이 매우 적은(흔히 하나뿐인) 그룹이 만들어져, 브로드캐스트 폭풍 없이 효율적인 주소 조회가 가능합니다.
장치가 그룹에 가입하는 방법: IGMP
멀티캐스트에는 닭이 먼저냐 달걀이 먼저냐 같은 문제가 있습니다. 누가 원하는지 모르는 상태에서 네트워크가 스트림을 어디로 보내야 할지 어떻게 알 수 있을까요?
IPv4에서는 IGMP(인터넷 그룹 관리 프로토콜, Internet Group Management Protocol)가 이 문제를 해결합니다. 호스트가 라우터에 "이 그룹의 트래픽을 받고 싶습니다"라고 알리고, 라우터가 어떤 그룹에 관심 있는 구성원이 있는지 파악하는 방법입니다.
동작 방식은 이렇습니다.
- 장치가 멀티캐스트 스트림을 수신하려 하면, 그룹에 가입하기 위해 멤버십 리포트를 전송합니다.
- 라우터는 주기적으로 네트워크에 질의합니다. "아직 관심 있는 호스트가 있습니까?"
- 호스트는 자신이 가입한 그룹에 대해 응답합니다.
- 장치가 더 이상 관심이 없으면 탈퇴 메시지를 전송합니다.
- 라우터는 전달을 중단하기 전에 다른 호스트가 아직 스트림을 원하는지 확인합니다.
세 가지 버전이 있으며, 각각 기능을 추가했습니다.
IGMPv1은 기본적인 질의-응답 모델을 도입했습니다.
IGMPv2는 명시적인 탈퇴 메시지를 추가하여, 라우터가 원치 않는 스트림 전달을 더 빨리 중단할 수 있게 했습니다.
IGMPv3는 소스 필터링을 도입했습니다. 호스트는 원하는 그룹뿐 아니라 해당 그룹 내에서 수용할 소스도 지정할 수 있습니다. 여러 서버가 같은 그룹 주소로 스트리밍할 때 중요한 기능입니다.
IPv6는 IGMP 대신 MLD(멀티캐스트 리스너 탐색, Multicast Listener Discovery)를 사용합니다. 같은 개념이지만 다른 프로토콜로, ICMPv6에 내장되어 있습니다.
스위치 문제: IGMP 스누핑
한 가지 까다로운 문제가 있습니다. 스위치는 레이어 2(이더넷 프레임)에서 동작하지만, IGMP는 레이어 3(IP) 프로토콜입니다. IGMP를 이해하지 못하는 스위치는 멀티캐스트 트래픽을 보고 "누가 원하는지 모르니 어디든 다 보내야겠다"라고 판단합니다. 공들여 최적화한 멀티캐스트가 브로드캐스트로 전락해버립니다.
IGMP 스누핑이 이를 해결합니다. 스위치가 통과하는 IGMP 메시지를 엿들어 테이블을 구축합니다. "포트 5는 그룹 239.1.1.1을 원한다. 포트 12는 그룹 239.1.1.2를 원한다." 이제 스위치는 멀티캐스트를 지능적으로 전달할 수 있습니다.
스누핑 없이는 스위치가 브로드캐스트 릴레이에 불과합니다. 스누핑이 있으면 스위치도 비로소 효율성의 일부가 됩니다.
멀티캐스트가 빛나는 곳
IPTV와 라이브 스트리밍이 가장 대표적인 사용 사례입니다. 호텔, 병원, 대학, 기업들이 멀티캐스트로 TV 채널을 제공합니다. 소스 서버 입장에서는 열 명이 보든 만 명이 보든 부하가 동일합니다.
금융 데이터 피드는 멀티캐스트를 사용해 실시간 주가, 호가 창, 거래 데이터를 수천 개의 단말에 동시에 전송합니다. 밀리초가 중요한 세계에서는 멀티캐스트의 효율성과 일관된 전달 순서가 필수적입니다.
소프트웨어 배포는 대규모 조직에서 수천 대의 컴퓨터에 업데이트를 한 번에 내려보냅니다. 개별 다운로드로 서버를 압도하는 대신, 하나의 스트림이 모두에게 전달됩니다.
화상 회의 시스템은 내부 회의에 멀티캐스트를 사용하여, 대역폭을 배로 늘리지 않고도 고품질 영상을 수십 명의 참가자에게 전달합니다.
게임 서버는 모든 플레이어에게 게임 상태 업데이트를 동시에 전송하여, 모든 플레이어가 같은 게임 세계를 보도록 동기화합니다.
트레이드오프
멀티캐스트는 동시성을 요구합니다. 모두가 같은 순간을 함께 받습니다. 일시 정지할 수 없고, 되감을 수 없으며, 다른 사람이 끝 부분을 볼 때 처음부터 시작할 수도 없습니다. 이것은 결함이 아닙니다. 효율성을 가능하게 하는 근본적인 제약입니다.
멀티캐스트는 또한 경로에 있는 모든 장치의 협력을 필요로 합니다. 가정용 라우터는 대개 지원하지만, ISP는 거의 확실히 공용 인터넷 전체에 걸쳐 라우팅하지 않습니다. 라우팅의 복잡성이 인터넷 규모에서는 비실용적이기 때문입니다. 대부분의 멀티캐스트는 조직의 경계 안에 머뭅니다. 기업 네트워크, 캠퍼스, 데이터 센터.
인터넷 규모의 전달을 위해서는 CDN(콘텐츠 전달 네트워크)이 캐싱과 지리적 분산을 통해 유사한 효율성을 달성합니다. 하지만 주문형 재생이라는 유연성을 갖추고 있습니다. 멀티캐스트는 그 유연성을 포기하는 대신, CDN이 결코 줄 수 없는 것을 선택합니다. 바로 진정한 동시성 — 백만 명의 시청자가 정확히 같은 순간을 공유하는 것입니다.
멀티캐스트에 관한 자주 묻는 질문
IGMP와 MLD의 차이점은 무엇인가요?
IGMP(인터넷 그룹 관리 프로토콜)는 IPv4의 멀티캐스트 그룹 멤버십을 관리합니다. MLD(멀티캐스트 리스너 탐색)는 IPv6에서 동일한 역할을 합니다. 목적은 같지만 별도의 프로토콜로 존재합니다. IPv6가 IGMP를 그대로 채택하는 대신 MLD를 ICMPv6에 내장했기 때문입니다.
스위치에 IGMP 스누핑이 필요한 이유는 무엇인가요?
IGMP 스누핑 없이는 스위치가 멀티캐스트를 브로드캐스트처럼 취급합니다. 어느 포트에 관심 있는 수신자가 있는지 알 수 없어 모든 포트로 트래픽을 퍼뜨립니다. IGMP 스누핑을 통해 스위치는 멤버십 메시지를 수신하고 멀티캐스트 트래픽을 어디로 전달할지 파악할 수 있습니다. 레이어 2에서도 멀티캐스트의 효율성 이점이 유지됩니다.
멀티캐스트 트래픽을 보안 처리할 수 있나요?
멀티캐스트 자체는 암호화를 제공하지 않습니다. 그룹에 가입한 누구든 트래픽을 받을 수 있습니다. 민감한 콘텐츠라면 애플리케이션 계층에서 스트림(콘텐츠 자체)을 암호화하고, 네트워크 접근 제어로 그룹 멤버십을 통제해야 합니다. 멀티캐스트 인프라는 암호화된 페이로드를 전달할 뿐, 그것을 보호하지는 않습니다.
출처
이 페이지가 도움이 되었나요?