Real Time Messaging Protocol

Real-Time Messaging Protocol (RTMP) – protokół komunikacyjny służący do przesyłania strumieni audio, wideo oraz danych w czasie zbliżonym do rzeczywistego, opracowany pierwotnie przez firmę Macromedia (na potrzeby platformy Flash), a następnie rozwijany przez Adobe Systems^[1][2]. RTMP został zaprojektowany z myślą o współpracy z technologią Adobe Flash i przez wiele lat był jednym z podstawowych mechanizmów dystrybucji treści multimedialnych w Internecie^[3]. Mimo zakończenia wsparcia dla Flash Playera protokół nadal bywa wykorzystywany jako metoda dostarczania sygnału wejściowego (ingest) do serwerów streamingowych i platform transmisji na żywo^[4][5][6].

RTMP jest protokołem warstwy aplikacji, zapewniającym dwukierunkową multipleksację komunikatów nad niezawodnym transportem strumieniowym (najczęściej TCP)^[1][2]. Domyślnym portem kojarzonym z RTMP jest port 1935, choć w praktyce (zależnie od wdrożenia) możliwe jest używanie innych portów, w tym portów typowo wykorzystywanych dla HTTP/HTTPS^[7][2]. Protokół dzieli przesyłane dane na małe fragmenty (chunki) oraz multipleksuje wiele strumieni logicznych w obrębie jednego połączenia, co umożliwia równoczesny transport danych audio, wideo i komunikatów sterujących^[1][2].

Strumień RTMP może zawierać:

• dane wideo (np. skompresowane przy użyciu H.264/AVC; w niektórych zastosowaniach także H.265/HEVC),
• dane audio (np. AAC, MP3),
• dodatkowe metadane oraz komunikaty sterujące^[1][8].

Protokół wspiera mechanizmy kontroli sesji po stronie odtwarzania (m.in. polecenia odtwarzania, pauzowania i przewijania w obrębie materiału)^[1].

RTMP został wprowadzony przez firmę Macromedia w 2002 r. (m.in. wraz z Flash Player 6 oraz serwerem Flash Communication Server MX), jako element infrastruktury do strumieniowego przesyłania multimediów w ekosystemie Flash^[9]. Po przejęciu Macromedii przez Adobe Systems (2005) rozwój technologii i produktów z nią związanych kontynuowano pod marką Adobe^[10].

W 2012 r. opublikowano specyfikację RTMP (wersja 1.0), co ułatwiło implementację protokołu przez inne podmioty^[1][11]. Po zakończeniu wsparcia dla Flash Playera (31 grudnia 2020) oraz zablokowaniu uruchamiania treści Flash w 2021 r. rola RTMP po stronie odbioru w przeglądarkach internetowych znacząco zmalała^[3]. W praktyce protokół zachował jednak zastosowanie jako format dostarczania strumienia z enkodera do usług i serwerów transmisyjnych (ingest), m.in. w serwisach oferujących transmisje na żywo^[9][4][5][6].

RTMP jest używany przede wszystkim w następujących zastosowaniach:

• transmisje na żywo (publikacja strumienia z programowych i sprzętowych enkoderów do serwerów streamingowych lub usług platformowych)^[9][6],
• strumieniowe przesyłanie materiałów na żądanie (video on demand) w ramach rozwiązań serwerowych obsługujących RTMP^[2],
• przekazywanie sygnału wejściowego do wybranych platform internetowych, które udostępniają punkty ingest w RTMP/RTMPS^[4][5].

Typowe scenariusze obejmują konfigurację enkodera poprzez podanie adresu serwera (URL RTMP/RTMPS) oraz klucza transmisji (stream key), po czym strumień jest przekazywany do usługi lub serwera docelowego^[4][12].

Protokół RTMP występuje w kilku odmianach, różniących się sposobem transportu danych oraz zabezpieczeniami:

• RTMP – podstawowa wersja protokołu działająca bezpośrednio nad TCP; domyślnie kojarzona z portem 1935^[2][7].
• RTMPS – RTMP przesyłany przez TLS/SSL (szyfrowane połączenie); w wielu wdrożeniach domyślnym portem jest 443^[2][13].
• RTMPT – RTMP tunelowany przez HTTP (dane RTMP są enkapsulowane jako poprawny HTTP); domyślnym portem jest 80^[2].
• RTMPE – szyfrowany wariant RTMP (mechanizm odrębny od SSL/TLS) oferowany w ekosystemie Adobe^[2].
• RTMFP – (Real-Time Media Flow Protocol) protokół UDP zaprojektowany przez Adobe jako bezpieczny transport wideo, audio i danych, m.in. z myślą o komunikacji peer-to-peer^[14][15].

W praktyce współcześnie często spotyka się użycie RTMP/RTMPS jako protokołu wejściowego dla transmisji na żywo (ingest)^[6][5].

Strumień RTMP opiera się na koncepcji chunk streamów (kanałów logicznych), w ramach których przesyłane są fragmenty (chunki) wiadomości; po stronie odbiorcy chunki są składane z powrotem w wiadomości na podstawie identyfikatora strumienia (chunk stream ID)^[1]. Taki podział pozwala przeplatać fragmenty wiadomości o różnych priorytetach (np. audio i wideo) w jednym połączeniu, ograniczając ryzyko blokowania mniejszych komunikatów przez duże wiadomości^[1].

Wraz z rozwojem transmisji multimedialnych w internecie RTMP funkcjonuje obok innych protokołów, m.in.:

• RTSP – protokół warstwy aplikacji przeznaczony głównie do sterowania sesjami strumieniowymi (np. komendy odtwarzania i pauzy)^[16].
• HLS – protokół dystrybucji strumieni przez HTTP, opisany w RFC 8216^[17].
• MPEG-DASH – zestaw standardów dla adaptacyjnej transmisji multimediów przez istniejącą infrastrukturę HTTP^[18].

W kontekście transmisji na żywo RTMP/RTMPS bywa wykorzystywany do ingestu (połączenie stałe i niskie opóźnienia), natomiast protokoły segmentowe oparte na HTTP (np. HLS/DASH) są często stosowane do dystrybucji na większą skalę kosztem wyższych opóźnień^[19][20].

SRT (Secure Reliable Transport) jest przykładem protokołu działającego nad UDP, projektowanego z myślą o niezawodności, bezpieczeństwie i niskich opóźnieniach w sieciach o zmiennej jakości^[20].

RTMP jest obsługiwany przez wiele rozwiązań serwerowych i enkoderów; w praktyce „publikacja” strumienia RTMP z enkodera do serwera lub usługi jest wskazywana jako jedno z typowych zastosowań protokołu^[9][6]. W konfiguracjach platformowych często stosuje się adres RTMP/RTMPS oraz klucz transmisji, które identyfikują kanał nadawania i uprawnienia do publikacji strumienia^[4][12].

• Gnash Project Wiki - RTMP/AMF/SOL. wiki.gnashdev.org. [zarchiwizowane z tego adresu (2008-03-13)]. (ang.).