마지막 20대를 알차게 마무리하고, 다가오는 서른을 뜻깊에 맞이하기 위하여휴가동안 "인터넷프로토콜 핵심가이드"를 읽고 학습 및 정리하는 소박한 목표를 세워본다.
이 책은 굉장히 오래된 책이다. (국내 기준 02년 출간..) Network 프로토콜은 다른 기술 보다 변화가 상대적으로 더딘 편이지만... 그래도 감안하고 큰 개념만 익히도록 하자.
책을 읽고 이해한 내용을 바탕으로 정리한것이기 때문에 자의적인 해석이 들어가 있을 수도 있습니다. 잘못된 내용은 지적 부탁드립니다.
/*행사일정*/
String[][] eventSchedule =
{
{ "12월30일", "ARP/IGMP" }
,{ "12월31일", "IP/ICMP" }
,{ "1월1일", "UDP/TCP" }
};
IGMP
IP 멀티캐스팅은 IP 데이터그램이 여러 개의 네트워크에 있는 호스트들로 동시에 전송되게 한다. 이것은 모든 호스트에서 데이터를 처리할 필요가 없다는 것과 원격 네트워크의 호스트도 데이터그램을 수신할 수 있다는 점에서 기존의 브로드캐스트와 다르다. 인터넷 그룹 관리 프로토콜은 IP장비가 멀티캐스트 라우터에 등록하여 자신이 속할 멀티캐스트 그룹을 지정할 수 있는 방법을 제공한다.
어떤 시스템이 로컬 네트워크의 다른 호스트와 통신하려면 일반적으로 브로드 캐스트 하거나, 특정 목적지에 유니캐스트 데이터그램을 보낸다.
시스템이 다른 호스트와 통신할 수 있는 또 다른 방법은 그룹에 패킷을 보내는 '멀티캐스팅'이다. 그 그룹 주소를 감시하고 있는 호스트만이 데이터를 수신하며, 다른 네트워크 장비는 그것을 무시한다.
=> 무시한다는것은 수신은 하지만 Drop한다는걸까. 아니면 수신조차 못하는건가.
==> 이부분만 읽어봤을때는 약간 publish subscribe 모델 비슷한것 같다.
이런 방식은 브로드캐스트의 제한을 피해 한 호스트에서 여러 개의 목적지로 동시에 데이터를 보내야 하는 애플리케이션에 유용하다.
브로드캐스트는 로컬 네트워크에 있는 모든 호스트에 데이터를 보낸다. 하지만 대부분의 라우터가 브로드캐스트를 차단하므로 다른 네트워크에 있는 호스트는 데이터를 수신하지 못한다. 다른 네트워크에 있는 호스트가 데이터를 수신하려면, 브로드캐스트 트래픽은 수신하기를 원하든 그렇지 않든 다른 네트워크의 모든 호스트에 다시 브로드캐스트 되어야 한다.
더 나아가, 브로드캐스트를 사용하면 로컬 네트워크의 모든 장비가 패킷을 감시하고 자신의 애플리케이션에서 필요한 데이터인지 결정해야 한다. 따라서 장비는 그런 판단을 내리려고 데이터가 유용하지 않은 경우에도 그것을 처리해야 한다. 따라서 네트워크의 모든 시스템에서 필요 없는 메시지를 검사하고 소멸시키는 데 많은 자원을 소비하게 한다.
브로드캐스트 대신 멀티캐스트를 사용하면
호스트는 자신이 감시하고자 하는 네트워크 스트림을 선택할 수 있으모 따라서 상위 계층 프로토콜은 자신과 관련된 특정 패킷만을 처리하게 된다. 특정 멀티캐스트 그룹으로부터 데이터의 수신을 원하지 않는 호스트는 아무 것도 처리할 필요가 없다.
"간단하게 말하면, 멀티캐스트는 브로드캐스트와 같이 동작하지만, 원격 호스트와 네트워크를 포함하여 여러 호드스테 선별적으로 데이터를 전송한다."
예를들어 Router Discovery 프로토콜(RFC 1256에 정의된)은 장비들이 자동으로 네트워크의 라우터를 파악하도록 멀티캐스팅을 자주 사용한다. DNS클라이언트도 이같은 방식을 통해 DNS서버를 자동적으로 파악하는 것을 제안하는 draft proposal도 있다. 또 여러 호스트에 데이터를 동시에 보내기 위해 TFTP와 멀티캐스트 전송 방식을 사용하자는 제안도 있었다.
멀티캐스트는 지점간(point-to-point) 방식으로 각 시스템에 데이터를 개별 전송하는 대신 여러 시스템으로 데이터를 동시에 보낼 수 있도록 하여 많은 애플리케이션에서 유용하게 사용된다.
IP 멀티캐스팅과 IGMP 명세
IP멀티캐스팅은 STD5에 포함된 RFC 1112로 문서화되어 있다. IP멀티캐스팅은 STD5의 일부이므로 인터넷 표준 프로토콜로 간주한다. 따라서, 인터넷 표준을 준수하는 모든 호스트는 자신의 IP스택에 멀티캐스팅을 구현해야 한다.
IGMP는 전송프로토콜이 아니며, 멀티캐셔트 데이터를 전달하기 위해 사용되는 것도 아니다. IGMP는 오히려 ICMP와 같은 제어 프로토콜이며, 장비에 네트워크 이벤트와 변화를 알리는 데 사용된다.
모든 호스트가 IP멀티캐스팅을 구현해야 하는 것과는 달리 IGMP는 그렇지 않다. 그러나 시스템이 IGMP를 구현하지 않으면 로컬 멀티캐스트 라우터에 멀티캐스트패킷의 수신을 원한다는 것을 알릴 방법이 없다. 그리고 호스트가 멀티캐스트 그룹 IP주소로 데이터를 보낼 수는 있으나, 멀티캐스트 데이터를 안정적으로 수신하지 못한다. 요즘 멀티캐스트를 인식하는 대부분의 시스템은 IGMP와 멀티캐스트트 위한 기본적인 지원을 구현하였다.
IP멀티캐스팅의 소개
사용자가 분산되어 있는 다양한 호스트로 동시에 음성데이터를 보내고 싶다면, 특정 멀티캐스트 그룹에 결합된 IP주소로 데이터를 보내야 한다. 그 IP주소에 대한 트래픽을 감시하는 호스트는 모두 데이터를 수신하여 처리할 것이며, 그 외의 ㅗ스트는 데이터를 무시한다.
음성메시지를 보내는 데 사용되는 애플리케이션 프로토콜이 UDP 메시지로 IP에 전송되는 RealAudio 스트림이라고 가정하자. UDP 메시지는 하나의 목적지 시스템 또는 로컬 브로드캐스트 주소로 보내지는 데이터와 다를 바가 없다. 멀티캐스트 데이터그램과 유니캐스트 또는 브로드캐스트로 보내는 데이터그램의 단 한가지 차이점은 목적지 주소다.
- 유니캐스트는 하나의 특정 목적지 시스템을 가리킨다.
- 브로드캐스트는 로컬 네트워크의 모든 호스트를
- 멀티캐스트는 그룹 주소를 가리킨다.
IP에서는 멀티캐스트 그룹 주소가 클래스 D로 알려져 있으며, 224.0.0.0부터 239.255.255.255 범위의 모든 IP 주소를 포함한다. 이 범위 내의 개별 주소는 특정 멀티캐스트 그룹을 가리키며, 주소 대부분이 특정 애플리케이션이나 서비스와 결합되어 있다.
IANA에 등록되어 있는 미리 정의된 예약 주소가 몇가지 있다. 예를들어 224.0.0.0에서 224.0.0.255 범위에 속한 주소는 모두 라우팅 프로토콜과 하위 계층의 인프라와 관련된 서비스에 예약되어 있다.
=> 음. 어렵다 ^__^ 클래스 D의 224.0.0.0 부터 224.0.0.255 까지는 멀티캐스트 통신을 위해 예약된 주소라는것 같다.
어떤 애플리케이션이 라우터에 의해 분산된 멀티캐스트 그룹에 가입하려면 애플리케이션은 로컬 시스템의 IP스택과 네트워크 어댑터에 그룹 주소를 감시하도록 알려줘야 한다. 또한 로컬 멀티캐스트 라우터에도 그 그룹 주소의 트래픽을 수신하겠다는 의사를 등록해야 한다. 이 과정은 멀티캐스트 라우터가 그 그룹주소로 가는 원격 멀티캐스트 데이터그램을 로컬 네트워크에 전달하기 위해 필요하다.
로컬 멀티캐스팅
대부분의 공유 매체 네트워크는 아래 세가지 방법으로 주소를 지정할 수 있다.
==> 잘 이해가 안간다. 패킷을 브로드캐스팅- 하는줄 알았는데 갑자기 프레임이 튀어나오고..
- 유니캐스트
한 장비에서 명시한 목적지 주소를 사용하여 다른 장비로 데이터를 전송할 때 사용된다. 네트워크에 연결된 장비들은 네트워크 트래픽을 감시하여, 자신의 로컬하드웨어 주소를 위한 프레임을 찾아야 한다. 이더넷의 겨웅에는 일반적으로 c0:14:3d:22:le:04처럼 16진수로 표현된 48비트 주소이다.
- 브로드캐스트
브로드캐스트 데이터는 한 장비에서 네트워크 토폴로지에 특화된 브로드캐스트 주소를 통해 로컬 네트워크의 다른 모든 장비로 보내진다. 네트워크의 장비들은 네트워크 트래픽을 감시하며 목적지가 브로드캐스트 주소인 프레임을 읽는다.
- 멀티캐스트
멀티캐스트 데이터는 한 호스트에서 특정 멀티캐스트 그룹 주소로 보내진다. 네트워크에 연결된 장비들은 자신이 속할 멀티캐스트 그룹을 선택하고 그 멀티캐스트 그룹중 하나로 향하는 프레임을 찾기위해 네트워크 트래픽을 감시한다.(다른 멀티캐스트 그룹 주소로 보내지는 프레임을 무시한다.)
Membership Report
라우터에 등록하는 과정은
특정 멀티캐스트 그룹에 가입하려는 애플리케이션이 시작되면, 호스트는 그 멀티캐스트 주소로 IGMP 'Membership Reposrt'를 보낸다.
예를들어 SNTP는 멀티캐스트를 이용하는데- SNTP를 실행하고 있는 서버는 224.0.1.1 멀티캐스트 그룹 주소를 통해 네트워크에서 SNTP를 이용하는 클라이언트에 시간 동기화 데이터를 자동으로 전달 할 수 있다.
SNTP 시스템이 시작되면 시스템은 즉시 몇번에 걸쳐 멀티캐스트 주소 224.0.1.1로 IGMP Membership Report를 전송한다. 로컬 네트워크의 멀티캐스트 라우터는 이런 보고서를 수신하여 자신의 멀티캐스트 포워딩 맵을 구축하는 데 사용한다.
Membership Report는 또한 로컬 네트워크에 있는 멀티캐스트 라우터가 여전히 활성화 된 멤버쉽을 가진 멀티캐스트 그룹을 파악하기 위해서 정기적으로 보내오는 IGMP Membership 쿼리에 응답할 때도 사용한다.
Leave Report
많은 멀티캐스트 애플리케이션에서 흔히 사용하는 또 다른 발표 매커니즘은 'Leave Report'이다. Leave Report는 어떤 호스트가 더 이상 특정 그룹으로 보내는 멀티캐스트 트래픽의 수신을 원치 않을 때 사용된다. 즉 어떤 호스트가 네트워크에서 떠나는 경우 로컬 멀티캐스트 라우터에 특정 그룹 주소로 가는 멀티캐스트 데이터를 더 이상 전달할 필요가 없음을 알려준다.
ㅇLeave Report는 현재 탈퇴하려는 해당 멀티캐스트 주소로 보내는 것이 아니라 대신 '모든 라우터' 그룹 주소인 224.0.0.2로 보내진다. 224.0.0.2는 멀티캐스트 라우터에 의해서만 감시를 받는다는 차이 외에는 '모든 호스트' 주소와 비슷하다.
Leave Report 메시지를 이해하지 못하는 장비들은 메시지를 받아도 소멸시킨다.
Membership 질의
이 IGMP 메시지는 멀티캐스트 라우터 보내며, 전달을 받고 있는 각 멀티캐스트 그룹이 로컬 네트워크에 있는수신자를 감시하고 있는지를 확인하기 위해 이 질의를 사용한다. Membership 질의에 응답하는 호스트가 없으면 라우터는 더 이상 수신자가 없는 멀티캐스트 그룹으로 멀티캐스트 데이터그램을 전달하는 것을 멈출 수 있다.
일반적으로 단 하나의 멀티캐스트 라우터만이 이런 질의를 전송한다. 네트워크에 연결된 다른 멀티캐스트 라우터의 경우에는 Membership Report를 감시하지만 질의를 보내지 않는 수동적인 자세를 취한다. '질의 라우터'로는 가장 낮은 IP주소를 가진 라우터가 선택된다. 선택된 라우터가 질의를 멈추면, 다음으로 낮은 IP주소를 가진 라우터가 질의 라우터가 된다.
호스트는 Membership 질의에 표준 Membership Report로 응답하며, 멀티캐스트 라우터는 이 정보를 이용하여 로컬 네트워크에 어느 멀티캐스트 주소가 전달되어야 하는지 한단한다. 만약 전달된 멀티캐스트 주소에 응답하는 호스트가 없으면 멀티캐스트 라우터는 더 이상 아무 호스트도 그 멀티캐스트 트래픽의 수신을 원치 않는다고 판단하여 그 멀티캐스트 주소로 향하는 원격 데이터그램을 로컬 네트워크에 전달하지 않는다.
Membership 질의를 보내는 목적은 특정 그룹을 활동적으로 감시하는 호스트의 존재를 파악하는 것이지 그 그룹을 감시하는 모든 호스트를 파악하기 위한 것이 아니다.
IGMP 메시지
어떤 호스트에서 멀티캐스트 데이터그램을 수신하여 처리할 때는 먼저 두가지 작업을 한다.
1) 호스트는 로컬 네트워크 인터페이스 카드에 특정 멀티캐스트 그룹의 네트워크 프레임을 수신하여 처리하겠다는 의사를 알린다.
2) 로컬 네트워크의 멀티캐스트 라우터에 그 멀티캐스트 그룹을 위한 IP패킷을 수신하겠다는 의사를 알려야 한다.
애플리케이션이 네트워크 인터페이스 카드와 통신하는 방법은 로컬 시스템에서 사용하는 특정 IP구현의 기능 중 하나다. 그러나 로컬 네트워크의 멀티캐스트 라우터에 특정 멀티캐스트 그룹에 가입하겠다는 뜻을 전하기 위해서 IP가 사용하는 매커니즘은 인터넷 그룹 관리 프로토콜(IGMP)의 기능이다.
'Today I learned' 카테고리의 다른 글
[네트워크 프로토콜] 연말행사, 함께떠나요 네트워크 프로토콜 파티 3일차 ICMP (0) | 2020.01.01 |
---|---|
[네트워크 프로토콜] 연말행사, 함께떠나요 네트워크 프로토콜 파티 2일차 (1) IP (0) | 2019.12.31 |
[네트워크 프로토콜] 연말행사, 함께떠나요 네트워크 프로토콜 파티 1일차(1) ARP (0) | 2019.12.30 |
ECMAScript 6 정리 (0) | 2019.12.29 |
[오늘의 코드] 2019월 12월 28일 오늘의 코드 (0) | 2019.12.28 |
댓글