일반적으로 생각하기에 '실시간 전송 프로토콜'이라는 단어를 말하면 A라는 호스트에서 어떤 이벤트가 발생하면 그와 동시에 B라는 상대편에서도 그 이벤트에 대한 인식을 할 수있을 것을 생각하곤 한다. 하지만 네트워크 상에서의 물리적인 제약으로 그런 실시간은 불가능하다. 아주 좋게 가정해서 전파가 빛의 속도로 전송 된다고 가정하자. 빛은 1초에 지구를 7바퀴 반을 돈다고 한다. 계산을 편하게 하기 위해서 1초에 10바퀴를 돈다고 하자. 그럼 우리 나라에서 지구 반대 편에 있는 미국으로 데이터를 전송하기 위해서는 1/10의 초의 절반 1/20초가 걸린다. 이것는 우리 나라에서 미국으로 직선으로 아무런 방해도 받지 않고 날아가는 아주 나이스한 경우의 이야기고, 미국 까지 가는 도중에는 수많은(?) 라우터를 거쳐 가야 하고 그 과정에서 버퍼링이라던지 라우팅이라던지 기타등등의 시간을 잡아 먹는 일들이 우리를 기다리고 있다. 물리적인 한계로 우리가 일반적으로 생각하는 '실시간 전송'이라는 것은 불가능하다는 뜻이다. 이런 의미의 실시간 전송을 가능하게 하는 사람이라면(아직 이 세상에 빛 보다 빠른 것은 발견되지 않았으므로) 노벨상을 받을 것이다.
그렇다면 '실시간 전송 프로토콜'이라는 것은 과연 무엇이란 말인가? 실시간 전송을 설명하기 쉽게하기 위해 실시간 전송이 아닌 것에 대한 예를 들어 보자. 대표적인 예로 FTP 같은 것이 있다. 100M가 짜리 압축된 파일을 하나 다운 받는데 이것은 시간이 얼마가 걸리든 상관 없다. 1분내로 다운 받을 수 있으면 좋고, 1시간이 걸리든, 10시간이 걸리든 언젠가 모든 데이터를 순서에 맞게, 누락 없이 다 다운로드 받기만 하면 되는 것이다. 시간에 관계 없다는 소리다. 하지만 1시간 짜리 실시간 동영상을 본다고 하자. 이것은 모두 다운로드 받고 영화를 감상하는 것이 아니라 다운로드를 받으면서 감상을 하는 것이기 때문에 영화가 끝나기 전에는 모든 데이터들이 다운로드 완료 되어 있어야만 한다. 만일 밴드폭이 작어서 전송이 원활하지 못 하다면 유효기간이 지난(이미 지나간 장면의) 데이터는 전송을 하지 않으므로써 보다 원활하게 서비스 할 수 있다(물론 영화는 끊기겠지만).
위와 같은 실시간 전송을 위해 고안된 프로토콜이 RealTime Transfer Protocol(이하 RTP)다. 실시간 전송의 특징(일반적으로 패킷 손실에 덜 민감하고, 딜레이 발생을 최대한 방지해야 함)에 맞게끔 보다 빠른 전송을 위해 TCP 보다는 UDP기반으로 구현 되었으며 UDP의 특성 답게 데이터의 무결성을 보장 하지 않는다.
특징은 Pay-load type(어떤 타입의 컨텐츠가 전송 되는지를 나타내는 플래그), Sequence number(각 데이터그램에 붙여져 re-ordering에 사용), Time stamp(컨텐츠가 전송되는 시간 기록), Delivery monitoring 네 가지다.
RTP는 아무런 QoS를 보장하지 않으므로 이를 보완 할 수 있는 메커니즘이 필요한데 여기에 RTCP(RTP Control Porotocol)이 사용된다. 사실 RTCP는 자체는 QoS를 보장하는 것이 아니라, 보장에 필요한 데이터들을 제공 할 뿐이다. 보통 RTCP는 RTP포트의 다음 포트를 사용하며, 일정 시간마다 한번씩 세션 내의 클라이언트(participant 라고 원문에는 되어있다)들에게 RTCP메시지가 보내어 진다. 이 메시지를 받는 클라이언트들은 그에 대한 응답을 보내 주고 이 데이터가 RTP를 사용하는 사람에게 제공 된다. 이 데이터들을 이용해서 어떻게 QoS를 보장 할 것인가는 사용자의 몫으로 남겨진다.
한 가지 시나리오를 가정해 보자면 서버측에서 send byte를 세션내의 클라이언트들에게 보내고 클라이언트들은 자신이 받은 receive byte를 서버로 응답한다. 서버측에서는 그 값을 판단하여 클라언트들이 자신이 보낸 것에 비해 적은 양을 받고 있으면 데이터들을 보다 띄엄띄엄 보내 클라이언트에게 가해지는 부담을 덜어 주는 형식으로 flow control을 할 수있다. 이 외에도 많은 QoS 보장 방법이 있지만 그것은 구현에 따라 달라지므로 더 이상 언급하지는 않겠다.
이 외에도 실시간 전송을 위해 사용되는 프로토콜들이 많이 있지만 나의 귀차니즘으로 인하여 여기서 이번 포스팅은 완료 하겠다. 보다 자세한 사항은 아래의 문서들을 참고 하길 바란다(무책임~)
참고 : RTP - http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
RTPC - http://en.wikipedia.org/wiki/Real_time_control_protocol
http://blog.naver.com/dldbrud84/120025248792
http://blog.naver.com/jejezz/50016197113
그렇다면 '실시간 전송 프로토콜'이라는 것은 과연 무엇이란 말인가? 실시간 전송을 설명하기 쉽게하기 위해 실시간 전송이 아닌 것에 대한 예를 들어 보자. 대표적인 예로 FTP 같은 것이 있다. 100M가 짜리 압축된 파일을 하나 다운 받는데 이것은 시간이 얼마가 걸리든 상관 없다. 1분내로 다운 받을 수 있으면 좋고, 1시간이 걸리든, 10시간이 걸리든 언젠가 모든 데이터를 순서에 맞게, 누락 없이 다 다운로드 받기만 하면 되는 것이다. 시간에 관계 없다는 소리다. 하지만 1시간 짜리 실시간 동영상을 본다고 하자. 이것은 모두 다운로드 받고 영화를 감상하는 것이 아니라 다운로드를 받으면서 감상을 하는 것이기 때문에 영화가 끝나기 전에는 모든 데이터들이 다운로드 완료 되어 있어야만 한다. 만일 밴드폭이 작어서 전송이 원활하지 못 하다면 유효기간이 지난(이미 지나간 장면의) 데이터는 전송을 하지 않으므로써 보다 원활하게 서비스 할 수 있다(물론 영화는 끊기겠지만).
위와 같은 실시간 전송을 위해 고안된 프로토콜이 RealTime Transfer Protocol(이하 RTP)다. 실시간 전송의 특징(일반적으로 패킷 손실에 덜 민감하고, 딜레이 발생을 최대한 방지해야 함)에 맞게끔 보다 빠른 전송을 위해 TCP 보다는 UDP기반으로 구현 되었으며 UDP의 특성 답게 데이터의 무결성을 보장 하지 않는다.
특징은 Pay-load type(어떤 타입의 컨텐츠가 전송 되는지를 나타내는 플래그), Sequence number(각 데이터그램에 붙여져 re-ordering에 사용), Time stamp(컨텐츠가 전송되는 시간 기록), Delivery monitoring 네 가지다.
RTP는 아무런 QoS를 보장하지 않으므로 이를 보완 할 수 있는 메커니즘이 필요한데 여기에 RTCP(RTP Control Porotocol)이 사용된다. 사실 RTCP는 자체는 QoS를 보장하는 것이 아니라, 보장에 필요한 데이터들을 제공 할 뿐이다. 보통 RTCP는 RTP포트의 다음 포트를 사용하며, 일정 시간마다 한번씩 세션 내의 클라이언트(participant 라고 원문에는 되어있다)들에게 RTCP메시지가 보내어 진다. 이 메시지를 받는 클라이언트들은 그에 대한 응답을 보내 주고 이 데이터가 RTP를 사용하는 사람에게 제공 된다. 이 데이터들을 이용해서 어떻게 QoS를 보장 할 것인가는 사용자의 몫으로 남겨진다.
한 가지 시나리오를 가정해 보자면 서버측에서 send byte를 세션내의 클라이언트들에게 보내고 클라이언트들은 자신이 받은 receive byte를 서버로 응답한다. 서버측에서는 그 값을 판단하여 클라언트들이 자신이 보낸 것에 비해 적은 양을 받고 있으면 데이터들을 보다 띄엄띄엄 보내 클라이언트에게 가해지는 부담을 덜어 주는 형식으로 flow control을 할 수있다. 이 외에도 많은 QoS 보장 방법이 있지만 그것은 구현에 따라 달라지므로 더 이상 언급하지는 않겠다.
이 외에도 실시간 전송을 위해 사용되는 프로토콜들이 많이 있지만 나의 귀차니즘으로 인하여 여기서 이번 포스팅은 완료 하겠다. 보다 자세한 사항은 아래의 문서들을 참고 하길 바란다(무책임~)
참고 : RTP - http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
RTPC - http://en.wikipedia.org/wiki/Real_time_control_protocol
http://blog.naver.com/dldbrud84/120025248792
http://blog.naver.com/jejezz/50016197113
