요즘 실시간으로 멀티미디어 데이터를 주고받는 화상회의, 인터넷 방송, 실시간 교육 등의 서비스가 많아지고 있다.
이런 서비스를 가능하게 하는 것이 MBone(Multicast backbone)에서의 RTP(Realtime Transfer Protocol)다.
기존 네트워크에서 TCP/IP 프로토콜을 사용하는 것과 다른 점은 무엇일까? 인터넷에 연결된 호스트들의 수가 많아지고 텍스트 뿐만 아니라 오디오·비디오 등 대용량 데이터 전송이 필요함에 따라 등장한 것이 MBone이다.
MBone에서는 호스트끼리 연결돼있는 것처럼 가상네트워크를 만들고 이를 이용해 멀티캐스트 방식으로 메시지를 전달한다.
멀티캐스트는 하나의 패킷으로 여러 목적지에 도달하도록 전송하는 방법으로 한개의 목적지마다 패킷을 만들어 전송하는 유니캐스트와는 다르다.
이렇게 만들어진 패킷은 특정 호스트에 도착했을 때 호스트그룹에 속하는지 비교하고, 해당 그룹이라고 판단하면 수신을 계속한다.
해당 그룹이 아니면 반대편 멀티캐스트 라우터에 넘기는데, 이 과정을 '터널링(tunneling)'이라고 한다.
이를 통해 한 개의 패킷으로 여러 호스트에 전달할 수 있게 되는 것이다.
멀티캐스트 라우터에게 알려주기만 하면 특정 호스트 그룹의 수신자로 등록할 수 있고 수신자가 누구인지 드러나지 않게 할 수도 있어 일반 TV 방송국의 원리와 비슷한 점이 많다.
송신 호스트가 많으면 서버의 부하를 줄여주므로 멀티캐스트가 효율적이지만, 수신 호스트가 흩어져 있으면 전달을 위해 네트워크에서 패킷이 돌아다녀야 하므로 대역폭을 낭비할 수도 있다.
TCP/IP 프로토콜은 송수신자를 직접 연결해 데이터 전송을 보장한다는 장점이 있다.하지만, 화상회의에 필요한 이미지의 경우 한 프레임이 네트워크 오류로 지연되고 있다면 이것이 전송완료 되기 전까지 다른 데이터 전송이 미뤄진다.
그러면 네트워크 환경에 따라 끊어져 보이는 현상이 심하게 나타날 것이다.
이 때 어느 정도의 손실을 무시하면서 실시간에 가깝게 전송하는 방법이 필요한데 이를 처리해주는 전송방법이 RTP다.
RTP는 패킷이 순서대로 전송되는지, 없어졌는지 등은 신경을 쓰지 않는 UDP(User Datagram Protocol) 전송 프로토콜 바로 위의 프로토콜이다.
RTP 데이터 패킷에는 JPEG, H261 등등 다양한 오디오·비디오 데이터 인코딩 방식이 표시돼 있고 순서 번호, 전송시간 등의 자료가 포함돼 있다.
따라서, RTP로 송신하는 측에서는 UDP와 비슷한 방식으로 '실시간'의 성격에 맞도록 패킷을 보낸다.
음성 데이터의 경우 전송 메시지의 7% 이상이 제시간에 도착하지 않으면 알아듣기 힘드므로 '실시간'에 가깝게 패킷을 주고받으면서 이에 대한 QoS(Quality of Service)를 고려해야한다.
기본적으로 RTP는 패킷이 제대로 도착했는지 보장하지 않으므로 RTCP(Realtime Transport Control Protocol)를 사용해 메시지 손실률, 최근 받은 메시지 번호, 받은 시간 등의 컨트롤 정보를 담아두어 전송 서비스를 보장한다.
이런 서비스를 가능하게 하는 것이 MBone(Multicast backbone)에서의 RTP(Realtime Transfer Protocol)다.
기존 네트워크에서 TCP/IP 프로토콜을 사용하는 것과 다른 점은 무엇일까? 인터넷에 연결된 호스트들의 수가 많아지고 텍스트 뿐만 아니라 오디오·비디오 등 대용량 데이터 전송이 필요함에 따라 등장한 것이 MBone이다.
MBone에서는 호스트끼리 연결돼있는 것처럼 가상네트워크를 만들고 이를 이용해 멀티캐스트 방식으로 메시지를 전달한다.
멀티캐스트는 하나의 패킷으로 여러 목적지에 도달하도록 전송하는 방법으로 한개의 목적지마다 패킷을 만들어 전송하는 유니캐스트와는 다르다.
이렇게 만들어진 패킷은 특정 호스트에 도착했을 때 호스트그룹에 속하는지 비교하고, 해당 그룹이라고 판단하면 수신을 계속한다.
해당 그룹이 아니면 반대편 멀티캐스트 라우터에 넘기는데, 이 과정을 '터널링(tunneling)'이라고 한다.
이를 통해 한 개의 패킷으로 여러 호스트에 전달할 수 있게 되는 것이다.
멀티캐스트 라우터에게 알려주기만 하면 특정 호스트 그룹의 수신자로 등록할 수 있고 수신자가 누구인지 드러나지 않게 할 수도 있어 일반 TV 방송국의 원리와 비슷한 점이 많다.
송신 호스트가 많으면 서버의 부하를 줄여주므로 멀티캐스트가 효율적이지만, 수신 호스트가 흩어져 있으면 전달을 위해 네트워크에서 패킷이 돌아다녀야 하므로 대역폭을 낭비할 수도 있다.
TCP/IP 프로토콜은 송수신자를 직접 연결해 데이터 전송을 보장한다는 장점이 있다.하지만, 화상회의에 필요한 이미지의 경우 한 프레임이 네트워크 오류로 지연되고 있다면 이것이 전송완료 되기 전까지 다른 데이터 전송이 미뤄진다.
그러면 네트워크 환경에 따라 끊어져 보이는 현상이 심하게 나타날 것이다.
이 때 어느 정도의 손실을 무시하면서 실시간에 가깝게 전송하는 방법이 필요한데 이를 처리해주는 전송방법이 RTP다.
RTP는 패킷이 순서대로 전송되는지, 없어졌는지 등은 신경을 쓰지 않는 UDP(User Datagram Protocol) 전송 프로토콜 바로 위의 프로토콜이다.
RTP 데이터 패킷에는 JPEG, H261 등등 다양한 오디오·비디오 데이터 인코딩 방식이 표시돼 있고 순서 번호, 전송시간 등의 자료가 포함돼 있다.
따라서, RTP로 송신하는 측에서는 UDP와 비슷한 방식으로 '실시간'의 성격에 맞도록 패킷을 보낸다.
음성 데이터의 경우 전송 메시지의 7% 이상이 제시간에 도착하지 않으면 알아듣기 힘드므로 '실시간'에 가깝게 패킷을 주고받으면서 이에 대한 QoS(Quality of Service)를 고려해야한다.
기본적으로 RTP는 패킷이 제대로 도착했는지 보장하지 않으므로 RTCP(Realtime Transport Control Protocol)를 사용해 메시지 손실률, 최근 받은 메시지 번호, 받은 시간 등의 컨트롤 정보를 담아두어 전송 서비스를 보장한다.
