리얼 타임 메시징 프로토콜: 두 판 사이의 차이
내용 삭제됨 내용 추가됨
잔글 _다듬기 |
|||
14번째 줄:
생(raw) TCP 기반의 RTMP 프로토콜은 지속되는(persistent) 접속 하나를 유지한다. 또한 리얼 타임(실시간) 통신을 한다. 더 큰 덩어리의 정보를 보낼 수 있는 능력을 유지한 상태에서, 부가적으로 비디오 및 오디오 스트림을 부드럽게 전달하기 위해, 이 프로토콜은 비디오 및 데이터를 조각들(fragments)로 나누기도 한다. 조각들의 크기(the size of the fragments)는 클라이언트와 서버간 동적으로(dynamically) 조절(negotiated)된다. 동적 크기 조절은 비활성화될 수 있다. 비디오 및 기타 데이터에 대한 스트림 조각들의 기본 크기는 128 바이트이다. 오디오에 대한 스트림 조각들의 기본 크기는 64 바이트이다. 여러 개의 스트림이 있을 때, 각각의 스트림으로부터 꺼내온 조각들은 인터리빙(interleaving)되며, 한 접속 내에서 [[멀티플렉스|멀티플렉싱]]된다. 데이터 덩어리(chunk) 크기가 클 경우, RTMP 프로토콜은 조각 당 1 바이트의 헤더만을 실어 보내기도 한다. 그렇게 함으로써 오버헤드를 매우 많이 줄일 수 있다. 하지만 실제로는 조각들은 보통 인터리빙되지 않는다. 대신, 인터리빙과 멀티플렉싱은 패킷(packet) 레벨에서 행해진다. 여러 다른 액티브 채널에 실린 RTMP 패킷들은 각각의 채널의 밴드위스 및 레이턴시, 그리고 기타 QOS 요구사양에 맞게 인터리빙된다. 이렇게 인터리빙된 패킷들은 다시 나눌 수 없으며 조각(fragment) 레벨에서 다시 인터리빙되지 않는다.
RTMP 프로토콜은 패킷들을 주고 받을 수 있는 여러 개의 채널(channel)들을 정의(define)한다. 각 채널들은 다른 채널에 대해 독립적으로 동작한다. 예를 들어, RPC 요청과 응답에 할당된 채널이 있고, 또 비디오 스트림 데이터에 대한 채널이 있고, 오디오 스트림 데이터에 대한 채널이 있고, 아웃-오브-밴드(out-of-band) 제어 메시지(조각 크기(fragment size) 협상 등등)들에 대한 채널이 있는 식이다. 일반적으로 하나의 RTMP 세션 내에, 어떤 시점에서 여러 개의 채널이 동시에 활성화될 수 있다. RTMP 데이터가 패킥화될 때, 패킷 헤더가 생성된다. 패킷 헤더는 채널의 아이디(id), 패킷의 타임스탬프(필요한 경우에는), 패킷 페이로드 크기 등을 담고 있다. 패킷 헤더 다음에는 패킷 페이로드가 온다. 패킷 페이로드는 현재 클라이언트와 서버 간 약속된 조각 크기(fragment size)만큼씩 조각으로 쪼개진다. <!-- 그 다음 한 접속에 대해 직렬화된다. (의역)--> 패킷 헤더 자체는 절대로 조각나지 않는다. 패킷의
더 상위 레벨에서, 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}}</ref>
| |||