IPTV 기본 기술중의 기본, 멀티캐스트(Multicast)는 어떻게 동작하나?
2009/02/13 10:32
IT 이야기/네트워크,보안
첫 번째, 유니캐스트는 상대측 IP주소를 목적지로 하는...(정확히 표현하면 MAC Address기반입니다) 일대일 통신방식입니다. 많은 분들이 유니캐스트에 대해서는 잘 알고 있을겁니다.
두 번째, 브로드캐스트는 내 호스트가 속한 네트웍 전체(로컬 네트웍)를 대상으로 패킷을 전송하는 일대다 통신방식입니다. 데이터를 수신할 필요가 없는 호스트들에게도 데이터가 전송되기 때문에 호스트에서 불필요한 인터럽트가 발생하게 됩니다. 그리고 브로드캐스트 패킷은 로컬네트워크에만 한정되기 때문에 라우터를 경유하지 못하는 단점이 있습니다.
그렇다면 특정그룹으로 로컬네트워크를 넘어서 일대다 통신을 하기 위해서는???
먼저, 유니캐스트 방식을 통해서도 특정 그룹으로만 패킷을 전송할 수 있습니다. 하지만 유니캐스트를 이용하게 되면 특정 그룹에 속한 호스트의 개수만큼 패킷을 복사하여 서버에서 패킷을 송신해야하는 부담이 생기게 됩니다. 같은 이유로 다수의 동일 패킷이 네트워크상에 흘러가기 때문에 네트워크 트래픽을 가중시키게 되어 비효율적입니다.
이와 같은 경우에 사용하는 통신방식이 바로 오늘 정리하고자 하는 것은 멀티캐스트입니다. 멀티캐스트도 브로드캐스트처럼 일대다 통신방식입니다. 하지만 멀티캐스트는 특정 그룹으로만 패킷을 전송하게 됩니다. 또한 브로드캐스트 방식과 달리 로컬네트워크의 경계인 라우터를 통과해서 패킷을 전송할 수 있으며 유니캐스트 방식에 비해 서버나 네트워크 트래픽에 부담을 덜 주게 됩니다. 올해부터 실시간 TV전송을 시작한 IPTV의 기본 기술중에서도 기본이라고 할 수 있습니다.
그럼 이제 멀티캐스트에 대해 좀 더 개괄적으로 정리해보겠습니다.
멀티캐스트는 IP주소체계 중에서 D Class 주소(224.0.0.0~239.255.255.255)를 이용합니다. 즉, 멀티캐스트 IP를 목적지 주소로 사용하는 패킷이 멀티캐스트 통신방식을 사용하는 패킷이 됩니다.
위에서 멀티캐스트는 라우터를 경유해서 전송이 된다고 하였습니다. 그렇다면 라우터는 멀티캐스트 패킷을 어떻게 해당하는 특정 그룹으로 전송을 하는지가 핵심이 되겠습니다. 그 핵심은 바로 IGMP(Internet Group Management Protocol)입니다.
IGMP는 라우터와 로컬네트워크상의 호스트들과의 신호제어 프로토콜로서 query message와 report message로 구성됩니다. 동작방식은 라우터에서 로컬네트워크에 존재하는 호스트들에게 1분 단위로(이 값은 설정하기 나름입니다) '멀티캐스트 그룹에 속한 호스트가 있나요?‘ 라는 의미의 query message를 던지게 됩니다. 그럼 이 메시지를 받은 호스트들은 자신이 멀티캐스트 그룹에 속해있으면 라우터로 report message를 던져서 응답하게 됩니다. 라우터에서는 이 메시지들을 받아 라우팅테이블(routing table)을 관리하게 되며, 1분 단위로 3번의 질의 후에도 응답이 없는 호스트로는 멀티캐스트 패킷을 전송하지 않게 됩니다. 따라서 3분 동안에는 해당 호스트로도 멀티캐스트 패킷이 전송되는 대역폭의 낭비가 발생하게 됩니다. 이를 해결하기 위해서 IGMPv2에서는 leave report message가 추가 되었습니다.
query message는 224.0.0.1을 목적지 주소로 하여 서브 네트워크상의 모든 호스트에게 메시지가 전달되고, report message는 224.0.0.2를 목적지 주소로 하여 서브 네트워크 상의 모든 멀티캐스트 라우터에게 응답을 합니다.
참고적으로, D Class의 주소중 일부는 예약이 되어 있는데 바로 224.0.0.1와 224.0.0.2 등은 IGMP에서 사용하기 위해 예약된 주소입니다. 이외에도 다른 프로토콜에서 사용하기 위해 예약된 주소가 더 있습니다.
| [기타 예약주소들] 224.0.0.4 - 모든 DVMRP 라우터에게 통신할 때 사용합니다. 224.0.0.5 - OSPF(Open Shortest Path First) 라우팅 정보를 로컬 네트워크의 모든 OSPF 라우터로 보내는 데 사용합니다. 224.0.0.6 - OSPF 라우팅 정보를 로컬 네트워크의 OSPF에서 지정한 라우터로 보내는 데 사용합니다. 224.0.0.9 - RIP 라우팅 정보를 로컬 네트워크의 모든 RIPv2 라우터로 보내는 데 사용합니다. 224.0.1.24 - Microsoft WINS 서버 그룹 주소입니다. WINS 서버의 자동 검색 및 복제와 동적 구성을 위해 사용합니다. |
IGMP는 멀티캐스트 그룹에 속한 호스트들을 라우터에 알려주기 위한 것이 목적입니다. 즉, 호스트와 라우터간의 프로토콜입니다. 이외에도 소스 호스트로부터 목적지 호스트로의 멀티캐스트 패킷의 전달 경로를 만들기 위한 라우터간의 프로토콜로 멀티캐스트 라우팅 프로토콜(Multicast Routing Protocol)이 있습니다. 그리고 인터넷 사용자에게 멀티캐스트 데이터를 전달하기 위한 가상의 네트워크로 MBONE(Multicast backBone)도 있습니다.
멀티캐스트 라우팅 프로토콜과 MBONE에 대해서는 나중에 다시 한번 정리하겠습니다. ^^*
| [관련 포스트] 2007/10/05 - [IT 노트/네트워크/보안] - Routing Protocol 2007/09/05 - [IT 노트/네트워크/보안] - IPv6 |
'IT 이야기 > 네트워크,보안' 카테고리의 다른 글
| 무선통신보안기술 (15) | 2009/05/14 |
|---|---|
| PKI(Public Key Infrastructure) (23) | 2009/04/16 |
| IPTV 기본 기술중의 기본, 멀티캐스트(Multicast)는 어떻게 동작하나? (7) | 2009/02/13 |
| SCTP(Stream Control Transmission Protocol) (18) | 2009/01/12 |
| Privacy/Data Protection : APEC Privacy Framework (9) | 2008/12/09 |
| 국제기구의 개인정보보호 가이드라인(Guideline) (0) | 2008/11/26 |
제글이 마음에 드셨다면, 망설이지 말고 RSS로 무료구독하세요. ^^ 
|
|
|
|
|
tv볼 시간이 없어서 iptv자세히는 모르겠네요
전에 메가tv에서 iptv메뉴 눌렀더니 뭐 잘 모르겠더라구요 ㅋ
악 =.= 이거 제가 알고 있던 내용을 더 추가해드리고 싶은데 기억이 안납니다 ㅡ.ㅡ;;;
현재의 IPTV 실시간 방송 추세는 multicast에서 다시 unicast로 가는 분위기 입니다.
그 이유는 기술적인 부분과 함께 성능 때문입니다.
근데! 그 자세한 이유가 생각이 안나요 ㅠ.ㅠ
multicast의 가장 큰 문제점은 join과 뭐였지 뭐였지 ㅡㅡ;;;암튼 탈퇴 하는 과정이 생각보다 오래 걸릴 수 있다는 부분입니다. 그리고 backbone이나 라우터 등이 multicast 중에서 IGMP v2를 지원하지 않는 경우가 있습니다. 이 경우 tunneling 기법을 사용하게 되는데 이게 또 오버해드가 발생하게 됩니다.
아 계속 겉돌기만 합니다 줸장 ort 생각이 안나요 ㅠ.ㅠ
IPTV의 추세가 unicast로 간다는 소리는 처음 들어요. unicast라면 오버헤드가 상당할 터인데... 그런 문제들을 상쇄하기 위한 방법들도 있을 듯 싶네요.
IGMPv1에서는 탈퇴하는 과정에 대역폭의 낭비가 있었지만 v2로 가면서 탈퇴메시지를 통해서 그런 문제들을 해결한 것으로 알고 있습니다.
아무튼 unicast로도 서비스가 되는 추세라면 뭔가 다른 보완기법들이 있을 듯 한데... 한번 소개해주시지 않겠어요? ^^*
그러게요 ㅡ.ㅡ
이게 당췌 휘발성 메모리라 기억이 안납니다.
분명 overhead가 있긴 하지만요. 흠흠흠..
생각이 나면 나중에 =.=
제가 한 때 거의 가입자단에 있던 multicast router를 개발했었는데, 오랜만에 아는 척할 수 있는 글이 포스팅돼서 반갑네요. ^^
오래전 일이라 요즘은 어떤지 모르겠지만 IPTV에서는 channel 전환이 결국 IGMP join/leave로 해결되어야 하는데, 사용자가 채널을 연속해서 바꾸는 경우에는 순간적으로 가입자단 bandwidth가 방송 데이터로 다 차버릴 수 있는 가능성이 있었던 것 같습니다. HD 방송이 채널 당 20Mbps 정도되니깐 100Mbps라도 순간적으로 5채널을 바꾸면 갑자기 화면이 얼어 버릴 것 같군요. 요즘은 어떤지 모르겠네요.
multicast 방식에 그런 문제가 있지만 모든 IPTV 서비스를 unicast로 가는 건 어렵지 않을까 합니다. 물론 요즘 Web에서 동영상 서비스 하는 것들이나 IPTV가 본격적으로 나오기 전에 하나TV는 VOD서비스를 unicast 방식으로 하긴 하지만요.
IPTV 는 결국 지금 방송 서비스를 대체할 수 있을 정도로 massive 서비스(동시 시청자 몇 백만 단위)를 원하는 걸텐데... 그럴 경우에는 unicast 방식은 scalability 측면에서 거의 불가능하리라 생각합니다. 방송 서비스는 multicast 로 하고 VOD 서비스는 unicast로 할 것 같습니다.
참고로 저는 뭐더라... PIM 을 구현했었습니다. 오래된 일이라 기억이 가물가물 하군요. 쩝~
이부분에 대해서 약간(?) 공부하면서 정리할때, 제기하신 문제점들에 대해 잠깐 생각해보긴 했었는데... 그쪽 경험이 없는지라.. ^^;
김윤수님 말처럼 아마도 multicast와 unicast를 어느정도 병행해서 하지 않을까 생각해봤었죠.
좋은 정보 감사합니다. ^^*
ps)요즘 감리중이라 댓글 확인을 자주 못했었네요. ^^;
이쪽 분야로도 상당한 내공이 있으신거 같아요~ 초보라서 봐도 잘 이해가 안되긴하지만 머리속에 잘 담아두겠습니다 ^^