리얼 타임 메시징 프로토콜

**리얼 타임 메시징 프로토콜**(Real Time Messaging Protocol, 흔히 줄여서 **RTMP**)은 어도비 시스템즈사의 독점 컴퓨터 통신 규약이다. RTMP는 오디오, 비디오 및 기타 데이터를 인터넷을 통해 스트리밍할 때 쓰인다. RTMP는 어도비 플래시 플레이어와 서버 사이의 통신에 이용된다. RTMP 종류는 다음과 같다. * RTMP (기본): 1935번 포트 사용, 암호화되지 않은 RTMP, 혹시나 1935번 포트로 시도해서 실패하면 443 포트(RTMPS)나 80 포트(RTMPT)로 재시도함. * RTMPT (RTMP Tunneled): RTMP 데이터를 HTTP로 감싼 것. 기본 포트는 80번. HTTP 헤더 때문에 RTMP보다는 크기가 큼. * RTMPS (RTMP Secure): RTMP 데이터를 HTTPS로 감싼 것. 플래시 재생기는 SSL 입출력을 지원하므로 그 기능을 사용함. * RTMPE (Encrypted RTMP): 128비트로 암호화된 RTMP. SSL보다는 가볍지만 SSL 인증같은게 없음. 암호화 채널을 사용하기 때문에 기본 RTMP보다 약간 성능에 영향을 줄 수 있음. * RTMPTE (Encrypted RTMP Tunneled): 80번 포트 사용. RTMPT, RTMPE 섞어 놓은 형태. 플래시 플레이어 9,0,115,0 필요. 서버 성능에 영향을 줌. * RTMFP (Real Time Media Flow Protocol): UDP에서 동작. 기본 RTMP는 TCP에서 동작. 항상 암호화 된 상태로 데이터를 전송. 처음 목표는 오직 플래시에만 쓰이는 것이었다. 그러나 현재는 플래시뿐 아니라 어도비 라이브사이클 데이터 서비시즈 ES와 같은 다른 응용 프로그램에서 RTMP이 쓰이고 있다. 그리고 RTMP 규격은 2009년 1월 20일에 어도비에서 발표했다.url-status=dead
# 동작
순수 TCP 기반의 RTMP 프로토콜은 접속을 지속적으로 유지하는 데 기여한다. 또, 실시간 통신을 한다. 더 큰 덩어리의 정보를 보낼 수 있는 능력을 유지하는 동안, 부가적으로 비디오 및 오디오 스트림을 부드럽게 전달하기 위해, 이 프로토콜은 비디오 및 데이터를 여러 조각들(fragments)로 나누기도 한다. 이 조각들의 크기는 클라이언트와 서버 간에 유동적으로 결정된다. 동적 크기 조절은 비활성화될 수 있다. 비디오 및 기타 데이터에 대한 스트림 조각들의 기본 크기는 128 바이트이다. 오디오에 대한 스트림 조각들의 기본 크기는 64 바이트이다. 여러 개의 스트림이 있을 때, 각각의 스트림으로부터 꺼내온 조각들은 인터리빙(interleaving)되며, 한 접속 내에서 다중화된다. 데이터 덩어리(chunk) 크기가 클 경우, RTMP 프로토콜은 조각 당 1 바이트의 헤더만을 실어 보내기도 한다. 그렇게 함으로써 부하를 상당 부분 줄일 수 있다. 그러나 실제로는 조각들은 보통 인터리빙되지 않는다. 대신, 인터리빙과 다중화는 패킷 수준에서 수행된다. 활성화된 여러 다른 채널에 실린 RTMP 패킷들은 각각의 채널의 대역폭 및 레이턴시, 그리고 기타 QoS 요구에 맞게 인터리빙된다. 이렇게 인터리빙된 패킷들은 다시 나눌 수 없으며 조각 수준에서 다시 인터리빙되지 않는다. RTMP 프로토콜은 패킷들을 주고 받을 수 있는 여러 개의 채널들을 정의한다. 각 채널들은 다른 채널에 대해 독립적으로 동작한다. 예를 들어, RPC 요청과 응답에 할당된 채널이 있고, 또 비디오 스트림 데이터에 대한 채널이 있고, 오디오 스트림 데이터에 대한 채널이 있고, 아웃-오브-밴드(out-of-band) 제어 메시지(조각 크기 결정 등)들에 대한 채널이 있는 식이다. 일반적으로 하나의 RTMP 세션 내에, 어떤 시점에서 여러 개의 채널이 동시에 활성화될 수 있다. RTMP 데이터가 패킷화될 때, 패킷 헤더가 생성된다. 패킷 헤더는 채널의 아이디(id), 패킷의 타임스탬프(필요한 경우에는), 패킷 페이로드 크기 등을 담고 있다. 패킷 헤더 다음에는 패킷 페이로드가 온다. 패킷 페이로드는 현재 클라이언트와 서버 간 약속된 조각 크기만큼씩 조각으로 쪼개진다. 패킷 헤더 자체가 조각나는 경우는 없다. 패킷의 첫 번째 조각 크기에 헤더 크기가 더해지지 않는다. 다시 말해 실제 패킷 페이로드만이 조각으로 쪼개진다. 더 상위 레벨에서, RTMP 프로토콜은 MP3 및 플래시 비디오 멀티미디어 스트림을 캡슐화한다. 액션 메시지 포맷을 이용하여 RPC를 수행하기도 한다.url-status=dead
## HTTP 터널링
RTMP 패킷들은 두 종류의 HTTP 터널링 프로토콜을 통해 교환될 수 있다. * RTMP Tunneled (RTMPT): RTMPT에서 RTMP 데이터는 HTTP로 통신하기 위해서 HTTP에 맞게끔 캡슐화된다. 클라이언트(미디어 플레이어)에서 나오는 메시지는 HTTP 기본 포트인 서버의 80번 포트로 들어간다. * RTMP Secure (RTMPS): RTMPS에서 RTMP 데이터는 HTTPS로 교환된다. 클라이언트(미디어 플레이어)에서 나오는 메시지는 HTTPS 기본 포트인 서버의 443번 포트로 들어간다. RTMPT와 RTMPS는 HTTP 헤더가 붙어서 터널링하지 않은 패킷보다는 상당히 더 크다. 그리고 RTMPT와 RTMPS는 방화벽을 통과하기 위해서 HTTP/HTTPS를 사용할 뿐, 터널링하지 않은 프로토콜과 대동소이하다.
# RTMP 클라이언트 소프트웨어
제일 유명한 RTMP 클라이언트는 어도비 플래시 플레이어이다. RTMP 서버에서 비디오 및 오디오를 스트리밍 받아 보여준다. 최근, XBMC라고 이름이 붙은 오픈 소스 미디어 플레이어가 RTMP를 지원하고 있다. (패치). 인기있는 크로스-플랫폼 미디어 플레이어인 비디오랜 (VLC)도 RTMP를 지원하고 있다. 유명게임 리그오브 레전드의 클라이언트도 RTMP로 데이터를 주고받는다.
# RTMP 서버 소프트웨어
현재까지 완벽하게 구현된 RTMP 서버는 어도비 플래시 미디어 서버, Wowza 미디어 서버, WebORB 통합 서버(무료. .NET 및 Java 그리고 ColdFusion 버전)이다. Red5 url=https://web.archive.org/web/20130331194626/http://osflash.org/red5 라고 불리는 리버스 엔지니어링된 오픈 소스 프로젝트가 있기도 하다. 자바 (프로그래밍 언어)로 만들었고, 2007년, 주요한 부분의 기능은 구현되어 있다. 이 프로젝트는 아직 베타 단계이다. 그리고 Google Code url=https://web.archive.org/web/20081216064134/http://code.google.com/search/#q=RTMP%20Server 에 기본 기능만 하는 서버가 올라와 있기도 하다. NGINX기반의 RTMP 미디어 스트리밍 서버 오픈 소스 프로젝트가 있다. NGINX-RTMP