protocol_2주차(3) RTMP&RTSP

2. RTMP

순수 TCP 기반의 RTMP 프로토콜은 접속을 지속적으로 유지하는 데 기여한다. 또, 실시간 통신을 한다. 더 큰 덩어리의 정보를 보낼 수 있는 능력을 유지하는 동안, 부가적으로 비디오 및 오디오 스트림을 부드럽게 전달하기 위해, 이 프로토콜은 비디오 및 데이터를 여러 조각들(fragments)로 나누기도 한다. 이 조각들의 크기는 클라이언트와 서버 간에 유동적으로 결정된다. 동적 크기 조절은 비활성화될 수 있다. 비디오 및 기타 데이터에 대한 스트림 조각들의 기본 크기는 128 바이트이다. 오디오에 대한 스트림 조각들의 기본 크기는 64 바이트이다. 여러 개의 스트림이 있을 때, 각각의 스트림으로부터 꺼내온 조각들은 인터리빙(interleaving)되며, 한 접속 내에서 다중화된다. 데이터 덩어리(chunk) 크기가 클 경우, RTMP 프로토콜은 조각 당 1 바이트의 헤더만을 실어 보내기도 한다. 그렇게 함으로써 부하를 상당 부분 줄일 수 있다. 그러나 실제로는 조각들은 보통 인터리빙되지 않는다. 대신, 인터리빙과 다중화는 패킷 수준에서 수행된다. 활성화된 여러 다른 채널에 실린 RTMP 패킷들은 각각의 채널의 대역폭 및 레이턴시, 그리고 기타 QoS 요구에 맞게 인터리빙된다. 이렇게 인터리빙된 패킷들은 다시 나눌 수 없으며 조각 수준에서 다시 인터리빙되지 않는다.

RTMP 프로토콜은 패킷들을 주고 받을 수 있는 여러 개의 채널들을 정의한다. 각 채널들은 다른 채널에 대해 독립적으로 동작한다. 예를 들어, RPC 요청과 응답에 할당된 채널이 있고, 또 비디오 스트림 데이터에 대한 채널이 있고, 오디오 스트림 데이터에 대한 채널이 있고, 아웃-오브-밴드(out-of-band) 제어 메시지(조각 크기 결정 등)들에 대한 채널이 있는 식이다. 일반적으로 하나의 RTMP 세션 내에, 어떤 시점에서 여러 개의 채널이 동시에 활성화될 수 있다. RTMP 데이터가 패킷화될 때, 패킷 헤더가 생성된다. 패킷 헤더는 채널의 아이디(id), 패킷의 타임스탬프(필요한 경우에는), 패킷 페이로드 크기 등을 담고 있다. 패킷 헤더 다음에는 패킷 페이로드가 온다. 패킷 페이로드는 현재 클라이언트와 서버 간 약속된 조각 크기만큼씩 조각으로 쪼개진다. 패킷 헤더 자체가 조각나는 경우는 없다. 패킷의 첫 번째 조각 크기에 헤더 크기가 더해지지 않는다. 다시 말해 실제 패킷 페이로드만이 조각으로 쪼개진다.

더 상위 레벨에서, RTMP 프로토콜은 MP3 및 플래시 비디오 멀티미디어 스트림을 캡슐화한다. 액션 메시지 포맷을 이용하여 RPC를 수행하기도 한다.^[2]

실시간 메시징 프로토콜 (RTMP)은 Flash Player에서 주문형 및 라이브 스트림을 재생할 때 사용하는 지연 시간이 짧은 스트리밍 프로토콜입니다. Wowza Streaming Engine은 실시간 및 주문형 스트림을 RTMP를 통해 스트리밍 할 수 있으며 비디오, 오디오 및 데이터의 다중 채널을 포함 할 수 있습니다. RTMP는 지속적인 연결을 유지하므로 오디오, 비디오 및 데이터를 Wowza와 Flash 클라이언트간에 이동할 수 있으므로 다음과 같은 용도로 사용할 수 있습니다.

• 영상 채팅
• 광고 삽입
• 유료 시청
• 스트림 내용과 동기화 된 풍부한 사용자 경험 응용 프로그램

참고 : https://www.wowza.com/blog/the-role-of-webrtc-in-low-latency-media-streaming

# 용어 설명

# payload : 오디오 샘플이나 압축된 비디오 데이터와 같은 패킷이 포함된 데이터.  

(payload format과 해석은 이 문서의 범위를 뛰어넘는다=>볼필요x )

# packet : 고정된 헤더와 payload data로 구성된 data 패킷

# port :

TCP / IP 프로토콜은 작은 양의 정수를 사용하여 포트를 식별합니다. "전송 프로토콜이 주어진 호스트 컴퓨터 내의 여러 대상을 구별하기 위해 사용하는 추상화" OSI 전송 계층에서 사용되는 전송 선택자 (TSEL)는 포트와 같습니다.

message stream ID : 각 메시지에는 연결된 메시지 스트림을 식별하기 위해 연관된 ID가 있습니다.

# RTMP Chunk Stream

이 섹션에서는 실시간 메시징 프로토콜 청크 스트림 (RTMP 청크 스트림)을 지정합니다. 

상위 멀티미디어 스트림 프로토콜을 위한 다중화 및 패킷 화 서비스를 제공합니다.

RTMP 청크 스트림은 실시간 메시징 프로토콜 (섹션 6)과 함께 작동하도록 설계되었지만 메시지 스트림을 보내는 모든 프로토콜을 처리 할 수 ​​있습니다. 각 메시지는 타임 스탬프와 페이로드 유형 식별을 포함합니다. RTMP 청크 스트림과 RTMP는 일대일 및 일대 다 실시간 방송에서 주문형 비디오 서비스, 대화 형 회의 응용 프로그램에 이르기까지 다양한 오디오 비디오 응용 프로그램에 적합합니다.

# handshake

RTMP 연결은 핸드 셰이크로 시작됩니다. 핸드 셰이크는 나머지 프로토콜과 다릅니다. 헤더가 있는 가변 크기 청크로 구성되는 대신 정적 크기의 세 청크로 구성됩니다.

클라이언트 (연결을 시작한 엔드 포인트)와 서버는 각각 동일한 세 개의 청크를 보냅니다. 설명을 위해 클라이언트에서 클라이언트를 보낼 때 이러한 청크는 C0, C1 및 C2로 지정됩니다. S0, S1 및 S2 서버에서 전송할 때.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

RTMP vs RTSP

<RTMP>

- Real Time Messaging Protocol

- TCP 기반

- 대역폭 찾기 쉬움

- HTTP Tunnelling for Firewall Through path

- PC는 어도비 플래시 플레이어, Mobile은 HTML5

- 스트리밍 서버 비용이 비쌈

<RTSP>

- Real Time Streaming Protocol

- RTP 전송 프로토콜 기반

- RTSP는 HTTP 프로토콜과 유사하지만 stateful임

- 단점은 비싼 스트리밍 서버 비용, HTML5가 RTSP 지원하지 않으므로 ActiveX or Plugin 이 필요

=> HTML5는 ActiveX 없이 브라우저에서 실행가능

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

2. QUIC (빠른 UDP 인터넷 연결)

QUIC ( Q의 요 약 U DP가 나는 이나 인터넷 C의 onnections는 발음 빠른 ) 구글에 의해 설계된 실험 수송층 네트워크 프로토콜이다. 전반적인 목표는 TCP에 비해 대기 시간을 줄이는 것입니다. QUIC는 UDP에서 구현 된 TCP + TLS + HTTP / 2와 비슷한 것으로 생각하십시오. TCP는 가장 낮은 수준의 기계 장치 (운영 체제, 라우팅 펌웨어)에서 구현되기 때문에 발생할 필요가있는 업그레이드의 양을 감안할 때 TCP를 변경하는 것은 불가능합니다. QUIC는 UDP 위에 구축되기 때문에 이러한 제한이 없으며 최종 호스트 응용 프로그램에 통합 될 수 있습니다.  

현재 클라이언트 측 구현은 Chromium 및 Android의 일부로 존재하며이를 지원하는 서버 측 응용 프로그램 (예 : Google 워드 프로세서 및 드라이브, YouTube 등)에 액세스 할 때 사용됩니다. Android 및 Chrome 데스크톱의 트래픽 중 88 %가 QUIC를 기반으로하고 있으며 Google 백엔드와의 상호 작용으로 인해 성능이 5 % 향상되고 스트리밍 응용 프로그램이 30 % 정도 재 버퍼링 될 수 있습니다. 실제로이 프로토콜을 사용하면 브라우저 수준에서 속도가 향상되지만 주 용도는 100s의 Mbps 범위에서 측정 된 연결 속도의 가정용입니다.