Bezpieczny niezawodny transport
| Zestaw protokołów internetowych |
|---|
| Warstwa aplikacji |
| Warstwa transportowa |
| warstwa internetowa |
| Warstwa łącza |
Secure Reliable Transport ( SRT ) to protokół transportu wideo typu open source, który wykorzystuje protokół transportowy UDP .
Przegląd
SRT zapewnia połączenie i kontrolę, niezawodną transmisję podobną do TCP ; robi to jednak w warstwie aplikacji , używając protokołu UDP jako podstawowej warstwy transportowej. Obsługuje odzyskiwanie pakietów przy zachowaniu niskich opóźnień (domyślnie: 120 ms). SRT obsługuje również szyfrowanie przy użyciu AES .
Protokół wywodzi się z projektu UDT , który został zaprojektowany z myślą o szybkiej transmisji plików. Zapewnił mechanizm niezawodności, wykorzystując podobne metody łączenia, numerów sekwencyjnych, potwierdzeń i retransmisji utraconych pakietów. Wykorzystuje selektywną i natychmiastową (opartą na NAK) retransmisję.
SRT dodał ponadto kilka funkcji w celu obsługi trybu transmisji na żywo:
- Kontrolowane opóźnienie z transmisją czasu źródła (dostarczanie pakietów na podstawie znacznika czasu)
- Zrelaksowana kontrola prędkości nadawcy
- Warunkowe odrzucanie pakietów „zbyt późno” (zapobiega blokowaniu początku linii spowodowanemu przez utracony pakiet, który nie został odzyskany na czas)
- Gorąca retransmisja pakietów (okresowy raport NAK)
Nagłówek pakietu
Pakiety SRT są tworzone w warstwie aplikacji i przekazywane do warstwy transportowej w celu dostarczenia. Każda jednostka nośnika SRT lub danych sterujących utworzona przez aplikację zaczyna się od nagłówka pakietu SRT.
| przesunięcia | Oktet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Oktet | Fragment | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | F | Znaczenie pola zależy od typu pakietu | ||||||||||||||||||||||||||||||
| 4 | 32 | Znaczenie pola zależy od typu pakietu | |||||||||||||||||||||||||||||||
| 8 | 64 | Znak czasu | |||||||||||||||||||||||||||||||
| 12 | 96 | Identyfikator gniazda docelowego | |||||||||||||||||||||||||||||||
| ... | ... |
Zawartość pakietu (w zależności od typu pakietu) |
|||||||||||||||||||||||||||||||
Pakiet danych
| przesunięcia | Oktet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Oktet | Fragment | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | 0 | Numer sekwencyjny pakietu | ||||||||||||||||||||||||||||||
| 4 | 32 | PP | O | KK | R | Numer wiadomości | |||||||||||||||||||||||||||
| 8 | 64 | Znak czasu | |||||||||||||||||||||||||||||||
| 12 | 96 | Identyfikator gniazda docelowego | |||||||||||||||||||||||||||||||
| ... | ... | Dane | |||||||||||||||||||||||||||||||
Pola w nagłówku są następujące:
- Numer sekwencyjny pakietu (31 bitów)
- PP (2 bity): flaga pozycji pakietu
- O (1 bit): flaga zamówienia
- KK (2 bity): flaga szyfrowania oparta na kluczach
- R (1 bit): flaga retransmitowanego pakietu
- Numer wiadomości (26 bitów)
- Dane (zmienna długość)
Pakiet kontrolny
| przesunięcia | Oktet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Oktet | Fragment | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | 1 | Typ kontroli | Podtyp | |||||||||||||||||||||||||||||
| 4 | 32 | Informacje specyficzne dla typu | |||||||||||||||||||||||||||||||
| 8 | 64 | Znak czasu | |||||||||||||||||||||||||||||||
| 12 | 96 | Identyfikator gniazda docelowego | |||||||||||||||||||||||||||||||
| ... | ... | Pole informacji kontrolnych (CIF) | |||||||||||||||||||||||||||||||
Pola w nagłówku są następujące:
- Typ kontrolny (15 bitów): Typ pakietu kontrolnego
- Podtyp (16 bitów)
- Informacje specyficzne dla typu (32 bity)
- Pole informacji kontrolnych (zmienna długość)
Historia
Secure Reliable Transport to protokół transportu wideo typu open source opracowany pierwotnie przez firmę Haivision. Według SRT Alliance , organizacji promującej technologię, optymalizuje ona wydajność przesyłania strumieniowego. Pomaga to zminimalizować skutki fluktuacji i zmian przepustowości, a mechanizmy korekcji błędów pomagają zminimalizować utratę pakietów. SRT obsługuje kompleksowe szyfrowanie za pomocą AES. Podczas wykonywania retransmisji SRT próbuje retransmitować pakiety tylko przez ograniczony czas w oparciu o opóźnienie skonfigurowane przez aplikację.
Według Marca Cymontkowskiego, architekta SRT, oprócz przesyłania strumieni transportowych MPEG przez publiczny Internet, jest on również wykorzystywany do łączności IoT, wymiany metadanych, jako protokół komunikacyjny, a także do dostarczania nieskompresowanych danych.
Referencyjna implementacja protokołu została pierwotnie opublikowana na licencji Lesser General Public License w wersji 2.1, ale 22 marca 2018 r. została ponownie wydana na licencji Mozilla Public License .
SRT jest obsługiwany w darmowych platformach multimedialnych GStreamer , FFmpeg , OBS Studio oraz w darmowym odtwarzaczu multimedialnym VLC .
Projekt Data Transfer Protocol (UDT) oparty na UDP był podstawą projektu SRT. Interfejs API SRT C jest w dużej mierze oparty na interfejsie API UDT
SRT został zaprojektowany do transmisji wideo na żywo z niskimi opóźnieniami.
Haivision udostępnił protokół SRT i implementację referencyjną jako open source na targach NAB Show 2017 .
W marcu 2020 r. Indywidualny Internet-Draft, draft-sharabayko-mops-srt, został przedłożony do rozpatrzenia grupie roboczej Media OPerationS (MOPS) Internet Engineering Task Force .
Sojusz SRT
SRT Alliance to organizacja, której członkowie opracowują, wykorzystują i promują protokół Secure Reliable Transport oraz oparte na nim oprogramowanie. Członkami założycielami sojuszu są Haivision i Wowza Streaming Engine .
Implementacje
Obecnie dostępna jest jedna implementacja, którą jest biblioteka SRT o otwartym kodzie źródłowym.
Interfejs API języka C jest oparty głównie na poprzednim interfejsie API UDT, z dalszymi zmianami w miarę dodawania nowych funkcji. Interfejs API jest bardzo podobny do interfejsu TCP.
SRT oferuje właściwie trzy tryby pracy, z których dwa pierwsze wywodzą się z UDT:
- Tryb strumienia plików: jak TCP
- Tryb przesyłania wiadomości: podobny do protokołu SCTP – wysyłanie bloków danych z jasno określonymi granicami
- Tryb na żywo: dane powinny być przesyłane w małych pakietach (zwykle do 1316 bajtów, jeśli przesyłany strumień to MPEG-TS ) z zachowaniem odpowiednich odstępów czasowych między nimi. Te same pojedyncze pakiety z tymi samymi odstępami czasu między nimi są następnie dostarczane po stronie odbiorcy.
Biblioteka SRT oferuje również następujące funkcje:
- Szyfrowanie przy użyciu klucza wstępnego. Obsługa szyfrowania była pierwotnie zapewniana przez OpenSSL, teraz alternatywnie można użyć Nettle (GNU TLS) lub mbedTLS.
- Kontrola dostępu SRT (inaczej „StreamID”) może być używana przez aplikacje do identyfikowania zasobów i korzystania z metody dostępu za pomocą hasła użytkownika, przy użyciu tego samego numeru portu usługi do wielu celów.
- Opcjonalny mechanizm korekcji błędów w przód .
Dalszą i bardziej szczegółową dokumentację można znaleźć w dokumentacji kodu źródłowego .
Zobacz też
- Niezawodny Internet Stream Transport , mający wypełnić lukę na rynku profesjonalnych protokołów w przeciwieństwie do „prosumenckiego” SRT.