🔒 Secure Reliable Transport (SRT)
Open-Source-Protokoll für zuverlässige, sichere und latenzarme Videoübertragung über öffentliche Netzwerke.
- SRT definieren und von RTMP abgrenzen
- Die drei Verbindungsmodi (Caller, Listener, Rendezvous) erklären
- ARQ und FEC als Fehlerkorrektionsmechanismen erläutern
- SRT Latenz-Einstellung und deren Bedeutung erklären
- Einsatzszenarien für SRT beschreiben
Was ist SRT?
SRT (Secure Reliable Transport) ist ein Open-Source-Protokoll, das 2017 von Haivision veröffentlicht und heute von der SRT Alliance weiterentwickelt wird. Es wurde entwickelt, um Video-Contribution-Links über das öffentliche Internet zu ermöglichen – mit niedriger Latenz und hoher Zuverlässigkeit.
- Basiert auf UDP (nicht TCP)
- Fehlerkorrektur via ARQ + FEC
- Verschlüsselung: AES-128/256-bit
- Einstellbare Latenz (120 ms – mehrere Sekunden)
- NAT Traversal möglich
- Open Source (GitHub)
| SRT | RTMP | |
|---|---|---|
| Protokoll | UDP | TCP |
| Latenz | ~100 ms | ~500 ms |
| Verluste | ARQ/FEC | TCP-Retry |
| Verschlüssl. | AES-256 | Nein |
| Lizenz | Open Source | Proprietär |
Die drei Verbindungsmodi
„Was macht der Caller-Modus bei SRT?" und „Was macht der Listener-Modus bei SRT?" – jeweils 1 Punkt.
📞 Caller
Initiiert aktiv eine Verbindung zu einem Listener. Kennt IP und Port des Ziels. Entspricht einem Client in Client-Server-Architektur.
Einsatz: Encoder/Kamera sendet aktiv zu einem Streaming-Server
👂 Listener
Wartet passiv auf eingehende Verbindungen auf einem definierten Port. Entspricht einem Server. Braucht keine feste IP des Callers.
Einsatz: Streaming-Server empfängt von verschiedenen Quellen
🤝 Rendezvous
Beide Seiten versuchen gleichzeitig eine Verbindung herzustellen. Nützlich bei beidseitigem NAT. Beide müssen IP + Port des anderen kennen.
Einsatz: Peer-to-Peer durch Firewalls
Fehlerkorrektionsmechanismen
„Welche Fehlermechanismen gibt es bei SRT? Wie funktionieren diese? Erläutern Sie kurz." – 2 Punkte
🔄 ARQ – Automatic Repeat reQuest
- Empfänger erkennt fehlende Pakete (via Sequenznummern)
- Sendet NACK (Negative Acknowledgement) an Sender
- Sender überträgt verlorene Pakete erneut
- Funktioniert nur innerhalb des eingestellten Latenz-Fensters
- Pro: Kein Overhead bei gutem Netz
- Con: Erhöht Latenz bei vielen Verlusten
🛡️ FEC – Forward Error Correction
- Sender schickt redundante Pakete mit
- Empfänger kann verlorene Pakete rekonstruieren
- Keine Rückanforderung nötig → niedrigere Latenz
- Overhead: ca. 10–25% mehr Bandbreite
- Pro: Keine Latenz-Erhöhung durch Retransmit
- Con: Immer Bandbreiten-Overhead
Latenz-Einstellung
Die SRT-Latenz (auch receiver latency) ist der Puffer auf der Empfängerseite. Sie muss mindestens so groß sein wie die Round-Trip-Time (RTT) des Netzwerks:
SRT Latenz ≥ 2,5 × RTT
Beispiel: RTT = 80 ms → SRT Latenz = min. 200 ms
Einsatzszenario: Übertragung innerhalb der Hochschule
„Sie wollen eine Übertragung innerhalb der Hochschule machen. Was würden Sie für ein Protokoll benutzen? Erläutern Sie bitte." – 3 Punkte
Antwort: Im LAN der Hochschule wäre SRT oder auch NDI sinnvoll. Bei sehr kurzen Strecken im gleichen Gebäude mit stabilem Netzwerk wäre auch RTP/UDP direkt möglich. SRT bietet gegenüber RTMP niedrigere Latenz und bessere Fehlerkorrektur. Im gesicherten LAN ist die Verschlüsselung optional.