리얼 타임 메시징 프로토콜: 두 판 사이의 차이
내용 삭제됨 내용 추가됨
443 |
InternetArchiveBot (토론 | 기여) 2 개의 출처 구조, 0 개의 링크를 깨진 것으로 표시 #IABot (v2.0beta2) |
||
9번째 줄:
* RTMFP (Real Time Media Flow Protocol): UDP에서 동작. 기본 RTMP는 TCP에서 동작. 항상 암호화 된 상태로 데이터를 전송.
처음 목표는 오직 [[어도비 플래시|플래시]]에만 쓰이는 것이었다. 그러나 현재는 플래시뿐 아니라 [[어도비 라이브사이클 데이터 서비시즈 ES]]와 같은 다른 응용 프로그램에서 RTMP이 쓰이고 있다. 그리고 RTMP 규격은 2009년 1월 20일에 어도비에서 발표했다.<ref>{{저널 인용|제목=Adobe to Open Flash Platform Messaging Protocol|url=http://www.adobe.com/aboutadobe/pressroom/pressreleases/200901/012009RTMP.html|확인일자=2009-01-23|확인날짜=2009-02-07|보존url=https://web.archive.org/web/20090209235315/http://www.adobe.com/aboutadobe/pressroom/pressreleases/200901/012009RTMP.html|보존날짜=2009-02-09|깨진링크=예}}</ref>
== 동작 ==
16번째 줄:
RTMP 프로토콜은 패킷들을 주고 받을 수 있는 여러 개의 채널들을 정의한다. 각 채널들은 다른 채널에 대해 독립적으로 동작한다. 예를 들어, RPC 요청과 응답에 할당된 채널이 있고, 또 비디오 스트림 데이터에 대한 채널이 있고, 오디오 스트림 데이터에 대한 채널이 있고, 아웃-오브-밴드(out-of-band) 제어 메시지(조각 크기 결정 등)들에 대한 채널이 있는 식이다. 일반적으로 하나의 RTMP 세션 내에, 어떤 시점에서 여러 개의 채널이 동시에 활성화될 수 있다. RTMP 데이터가 패킷화될 때, 패킷 헤더가 생성된다. 패킷 헤더는 채널의 아이디(id), 패킷의 타임스탬프(필요한 경우에는), 패킷 페이로드 크기 등을 담고 있다. 패킷 헤더 다음에는 패킷 페이로드가 온다. 패킷 페이로드는 현재 클라이언트와 서버 간 약속된 조각 크기만큼씩 조각으로 쪼개진다. <!-- 그 다음 한 접속에 대해 직렬화된다. (의역)--> 패킷 헤더 자체가 조각나는 경우는 없다. 패킷의 첫 번째 조각 크기에 헤더 크기가 더해지지 않는다. 다시 말해 실제 패킷 페이로드만이 조각으로 쪼개진다.
더 상위 레벨에서, RTMP 프로토콜은 [[MP3]] 및 [[플래시 비디오]] 멀티미디어 스트림을 캡슐화한다. [[액션 메시지 포맷]]을 이용하여 [[RPC]]를 수행하기도 한다.<ref>{{저널 인용|제목=Using RPC services in Flex Data Services 2|url=http://www.adobe.com/devnet/flex/articles/rpc_service_02.html|확인일자=2007-04-16|확인날짜=2007-04-16|보존url=https://web.archive.org/web/20070403192843/http://www.adobe.com/devnet/flex/articles/rpc_service_02.html|보존날짜=2007-04-03|깨진링크=예}}</ref>
=== HTTP 터널링 ===
| |||