[펌] 전송 프로토콜 [RTP/RTCP(RFC1889, RFC1890), RSVP, RTSP]

http://blog.naver.com/gaetoy/90001134258

전송 프로토콜 [RTP/RTCP(RFC1889, RFC1890), RSVP, RTSP]

RTP/RTCP. RSVP. RTSP의 등장 배경을 살펴보면 지연에 대한 제약이 거의 없거나 아주 없는 기존의 네트웍 응용 서비스들(FTP, Email, etc.)을 위해서는 TCP와 같은 안전한 방법의 전송 프로토콜이 적당하였으나 실시간 멀티미디어 네트웍 응용서비스들이 등장하기 시작하면서 TCP의 지연 유발 정책(재전송 기법, 네트웍 폭주 시 "Slow Start")은 심각한 문제점으로 대두되며 이것은 지연이 오디오나 비디오 같은 실시간 매체들의 적시 재생(On Time Playback)을 불가능하게 하기 때문이다. 이러한 이유로 많은 실시간 응용 서비스들이 TCP 보다는 비교적 지연의 가능성이 적은 UDP를 이용해 왔다. 그러나 UDP의 경우에도 패킷의 분실, 전송 순서 위반과 같은 매체의 품질에 크게 영향을 미치는 문제점들을 가지고 있다.

실시간 응용 서비스들에 대한 수요가 점차로 늘어나면서 IETF와 같은 단체에서는 TCP/UDP를 대신할 수 있는 실시간 응용들을 위한 전용 프로토콜의 개발을 시작하였고, 그 결과가 RTP/RTCP, RSVP, RSTP와 같은 프로토콜들이다. 인터넷을 통한 실시간 데이터 전송 서비스에 RTP/RTCP는 거의 표준처럼 이용되고 있는 실정이다. 그러나 RTP/RTCP는 TCP의 지연 문제를 피하기 위해 UDP 전송 프로토콜로 이용하고 있기 때문에 패킷의 분실과 같은 전송 품질의 문제는 해결하지 못하고 있으며 또한 UDP를 쓴다고 해서 지연 문제가 완전히 해결되는 것은 아니다. 따라서 실시간 데이터 전송을 위한 채널에는 적시 전송과 패킷 분실 방지가 보장되어야 한다. 이를 위해 제시된 프로토콜이 RSVP이다. RSVP는 수신자-송신자 경로상에 위치하는 모든 노드들이 특정 RTP 연결이 요구하고 있는 QoS가 보장될 수 있을 경우에만 연결 설정을 허가하도록 함으로써 위에 언급된 문제점들을 해결할 수 있다. 그러나 RSVP를 실현하기 위해서는 RTP 연결상의 모든 노드들이 RSVP를 구현하고 있어야 한다는 단점이 있다. 이러한 프로토콜과는 접근 방법이 조금은 다른 RTSP는 일-대-다 또는 일-대-일의 단방향 멀티미디어 전송 프로토콜로 송신 측에서 유용 가능한 대역폭에 알맞은 크기로 멀티미디어 데이터를 자른 후 패킷화하여 전송하는 프로토콜이다. 수신 측에서는 일정량의 패킷이 쌓이면 매체의 재생을 시작한다. 이때 매체의 재생과 동시에 수신 및 디코딩이 이루어지기 때문에 수신 측에서는 전체 매체 파일을 받아보지 않고도 연결과 거의 동시에 매체를 재생할 수 있게 된다.

** RTP

RTP는 실시간 데이터를 전송하는 응용들을 지원하기 위한 사용자간 전송 서비스(End-to-End Delivery Service)로 IETF RFC1889에 표준으로 제시되어 1997년 초에 표준화가 완료되었다.

RTP 서비스는 크게 Payload Type Identification, Sequence Numbering, Time Stamping으로 나누어 볼 수 있다. RTP 헤더에는 타이밍 정보와 페이로드 형식이 명시되는데, 전자는 매체들 간의 동기화에 이용되고 후자는 각 패킷에 포함된 매체에 대한 정보와 압축 형식을 표현하는데 이용된다.RTP 세션을 맺기 위해서 응용에서는 하나의 네트워크 주소와 두 개의 포트 번호로 이루어진 한 쌍의 목적지 전송 주소를 정의한다. 두 개의 포트 번호는 각각 RTP와 RTCP를 위한 것이다. 멀티미디어 세션에서 각 매체는 독립된 RTP 세션을 통해서 전송되고 또한 각각의 RTCP 연결을 갖는다. 따라서 특정 매체에 대한 재생 능력이 없는 단말에서는 그 매체를 받지 않도록 선택할 수도 있다.

RTP는 또한 응용들 간의 연동성을 보장하기 위해서 다양한 오디오 및 비디오 인코딩 형식에 대한 RTP Profile과 Payload Format을 정의하고 있다. 각각은 RTP와는 별개의 RFC로 제안되고 있는데 G.711, G.723, H.261, 그리고 H.263에 대한 Profile과 Payload Format 등이 정의되어 있다.

RTP는 UDP위에서 동작하면서 UDP의 다중화(Mulitplexing) 기능과 오류 검출(Checksum) 서비스를 이용하기 때문에 적시 전송이나 전송 순서 위반 방지들을 보장하지 않는다. 따라서 이러한 서비스에 대한 보장이 필요한 응용들은 자원 예약과 같은 부가 서비스들을 이용해야 한다.

** RTCP

RTCP는 RTP와 같이 동작하는 제어 프로토콜로 RTP 세션에 참여한 각 참가자들은 주기적으로 다른 모든 참가자들에게 RTCP 제어 패킷을 전송해야 한다. RTCP는 다음의 네 가지 기능을 가지고 있다.

응용 서비스에 정보 제공 : RTCP는 주기적인 제어 패킷 전송을 통해서 응용 서비스에 RTP 세션의 데이터 전송에 관계되는 정보를 제공한다. 각 RTCP 제어 패킷은 송신자 또는 수신자의 상태 정보를 포함하고 있으며, 이러한 상태 정보에는 전송 패킷 수, 수신 패킷 수, 지터 등이 포함된다.

RTP 소스 식별 : RTCP는 하나의 RTP 소스에 대해 Canonical Name(CNAME)이라 부르는 전송 계층의 식별자를 가진다. 이 CNAME은 RTP 세션의 참가자들을 추적하는데 이용된다.

RTP 전송 간격 제어 : 제어 트래픽이 네트워크 자원을 너무 많이 이용하지 못하도록 하고 RTP 세션에 많은 참가자들이 참가할 수 있도록 하기 위해서 제어 트래픽은 전체 세션 트래픽의 5%를 초과할 수 없도록 한정된다. 이에 대한 내용은 참가자 수의 함수로 결정된다.

최소한의 세션 제어 정보 수송 : 부가적인 기능으로 RTCP는 모든 세션 참가자들에 대해 최소한의 정보를 수송하기 위한 편리한 방법으로 이용될 수 있다.

** RSVP

RTCP가 수신 품질에 대한 보고를 통해서 송신자 측에서 트래픽을 조절할 수 있게는 하지만 송신자와 수신자 간에 적시 전송과 특정 QoS 만족을 성취하기 위해서는 RTCP 이외에 다른 프로토콜 체계가 필요하다. 이러한 필요에 의해 등장한 것이 RSVP이다.

RSVP는 사용자 간 특정 데이터 스트림에 대한 QoS 만족을 위해 네트워크의 자원을 미리 확보해 두기 위해 이용되는 자원 예약 프로토콜이다.

수신자는 RSVP를 이용해서 특정 데이터 스트림을 위해 네트워크으로부터 특정 QoS를 요청한다. 기본적인 RSVP 예약 요청은 요구되는 QoS와 이 QoS를 보장 받을 데이터 패킷에 대한 정의를 포함한다. 멀티캐스트의 경우 호스트는 IGMP 메시지를 보내서 호스트 그룹에 가입한 후 RSVP 메시지를 그 그룹의 전송 경로를 통해서 보내어 자원을 예약한다.

RSVP가 동작하기 위해서는 송신자와 수신자 간의 전송 경로에 위치하는 모든 호스트와 라우터 그리고 다른 네트워크 기반 요소들에서 RSVP를 지원해야만 한다. RSVP를 지원하는 각각의 구성 요소들은 QoS 요청을 만족시키는데 필요한 대역폭, CPU 그리고 메모리 버퍼와 같은 시스템 자원들을 예약한다.QoS는 주어진 서비스 모델을 위한 흐름 명세(Flow Spec)에 의해 정의된다. 서비스 모델에 따라 흐름 명세는 세션 데이터를 위한 전송 속도와 지연의 한계를 명시하거나 전송 속도만을 명시한다. 서비스 모델은 IETF Integrated-Services Working Group에서 정의되고, RSVP는 일반적으로 Guaranteed Service나 Controlled-Load Service 가운데 하나를 구현하고 있다. RSVP 세션은 RSVP를 지원하지 않는 라우터를 통해서 Tunneling할 수도 있다.