Zum Hauptinhalt springen

RFC 8835 - Transports for WebRTC

  • Status: Proposed Standard
  • Veröffentlicht: January 2021
  • Stream: IETF
  • Errata: Keine Errata

Grundlegende Informationen​

  • RFC-Nummer: 8835
  • Titel: Transports for WebRTC
  • Deutscher Titel: Transportschicht für WebRTC
  • Veröffentlichungsdatum: Januar 2021
  • Status: PROPOSED STANDARD (Vorgeschlagener Standard)
  • Autor: H. Alvestrand (Google)

Zusammenfassung (Abstract)​

Diese Spezifikation beschreibt den von WebRTC verwendeten Transport-Protokollstapel, einschließlich der Kernkomponenten ICE, DTLS und SRTP. WebRTC überträgt Medien und Daten über UDP, verwendet ICE für NAT-Traversierung, DTLS zum Aufbau sicherer Verbindungen und SRTP zur Verschlüsselung von Medienströmen.

Übersicht über den WebRTC-Transportstapel​

Vollständiger Protokollstapel​

WebRTC-Protokollstapel (von oben nach unten):

┌─────────────────────────────────────────┐
│   Anwendungsschicht (Application)        │
│   - Audio/Video-Streams                  │
│   - Datenkanäle (DataChannel)            │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   RTP/RTCP (Echtzeit-Transportprotokoll) │
│   - Medienübertragung                    │
│   - Steuerungsinformationen              │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   SRTP/SRTCP (Sicheres RTP)             │
│   - Verschlüsselte Medienströme          │
│   - Authentifizierung                    │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   DTLS (Datagram TLS)                   │
│   - Schlüsselaushandlung                 │
│   - Ende-zu-Ende-Verschlüsselung         │
│   - Zertifikatsüberprüfung               │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   ICE (Interactive Connectivity         │
│        Establishment)                    │
│   - NAT-Traversierung                    │
│   - Kandidatensammlung                   │
│   - Konnektivitätsprüfungen              │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   UDP (User Datagram Protocol)          │
│   - Basis-Transport                      │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   IP (Internet Protocol)                │
│   - IPv4 / IPv6                          │
└─────────────────────────────────────────┘

Zusätzlicher Datenkanal-Stapel:

┌─────────────────────────────────────────┐
│   DataChannel API                       │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   SCTP (Stream Control Transmission     │
│          Protocol)                       │
│   - Zuverlässige Übertragung             │
│   - Nachrichtengrenzen                   │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   DTLS                                  │
└─────────────────────────────────────────┘
              ↓
         (ICE + UDP + IP)

Warum UDP?​

UDP vs. TCP für WebRTC:

TCP-Probleme:
❌ Head-of-Line Blocking
   - Ein Paketverlust blockiert den gesamten Stream
   - Inakzeptabel für Echtzeit-Audio/Video

❌ Langsamer Verbindungsaufbau
   - Three-Way-Handshake-Verzögerung
   - TLS-Handshake-Verzögerung

❌ Unflexible Staukontrolle
   - Fester Algorithmus
   - Keine Optimierung für Echtzeitmedien

UDP-Vorteile:
✓ Kein Head-of-Line Blocking
   - Unabhängige Datenpakete
   - Paketverlust beeinflusst nachfolgende Pakete nicht

✓ Niedrige Latenz
   - Keine Wartzeit auf Bestätigung
   - Sofortiges Senden

✓ Flexible Kontrolle
   - Staukontrolle auf Anwendungsebene
   - Optimiert für Medien

WebRTC-Entscheidung:
UDP + Zuverlässigkeit auf Anwendungsebene
→ Medien mit SRTP (unzuverlässig)
→ Daten mit SCTP (optional zuverlässig)

ICE (Interactive Connectivity Establishment)​

Rolle von ICE​

Problem: NAT-Traversierung

Szenario:
Benutzer A (192.168.1.100) ← NAT1 ← Internet → NAT2 → Benutzer B (192.168.1.200)
         Private IP                                      Private IP

Problem:
- A weiß nicht, wie B's private IP erreicht werden kann
- B weiß nicht, wie A's private IP erreicht werden kann
- NAT blockiert externe Verbindungen

ICE-Lösung:
1. Kandidaten sammeln (Candidates)
   - Host-Kandidat: Lokale IP
   - Server Reflexive-Kandidat: NAT öffentliche IP (über STUN)
   - Relay-Kandidat: Relay-Adresse (über TURN)

2. Kandidaten austauschen (über Signalisierung)

3. Konnektivitätsprüfungen (Connectivity Checks)
   - Alle Kandidatenpaare testen
   - Besten Pfad finden

4. Verbindung herstellen

Kandidatentypen​

// Host-Kandidat (lokale Adresse)
{
  type: 'host',
  ip: '192.168.1.100',
  port: 54321,
  protocol: 'udp',
  priority: 2130706431,
  foundation: '1',
  component: 1
}

// Server Reflexive-Kandidat (über STUN erhaltene öffentliche Adresse)
{
  type: 'srflx',
  ip: '203.0.113.1',      // Öffentliche IP
  port: 12345,            // NAT-gemappter Port
  protocol: 'udp',
  priority: 1694498815,
  foundation: '2',
  relatedAddress: '192.168.1.100',  // Lokale IP
  relatedPort: 54321
}

// Relay-Kandidat (TURN-Relay-Adresse)
{
  type: 'relay',
  ip: '198.51.100.1',     // TURN-Server IP
  port: 3478,
  protocol: 'udp',
  priority: 16777215,
  foundation: '3',
  relatedAddress: '203.0.113.1',
  relatedPort: 12345
}

Prioritätsreihenfolge:
Host > Server Reflexive > Relay
(Direkte Verbindung bevorzugt, Relay nur als letztes Mittel)

DTLS (Datagram Transport Layer Security)​

Rolle von DTLS​

Warum DTLS benötigt wird:

Problem:
- UDP ist nicht sicher
- RTP-Medienströme müssen verschlüsselt werden
- Schlüsselaushandlung erforderlich

DTLS-Lösung:
✓ Sichere Verbindung herstellen
✓ Verschlüsselungsschlüssel aushandeln
✓ Gegenstelle authentifizieren
✓ Integritätsschutz

DTLS vs. TLS:
TLS (TCP-basiert):
- Zuverlässiger Transport
- Geordnete Zustellung
- Stream-Transport

DTLS (UDP-basiert):
- Unzuverlässiger Transport
- Möglicherweise ungeordnet
- Datagram-Transport
→ Erfordert zusätzliche Behandlung von Paketverlusten und Neuordnung

DTLS-Version:
WebRTC erfordert: DTLS 1.2 oder höher
Empfohlen: DTLS 1.3

SRTP (Secure RTP)​

SRTP-Verschlüsselung​

SRTP = RTP + Verschlüsselung + Authentifizierung

RTP-Paketstruktur:
┌──────────────────────────────────────┐
│ RTP Header (12+ Bytes)               │
│ - V, P, X, CC, M, PT, Seq, TS, SSRC │
├──────────────────────────────────────┤
│ RTP Payload (Mediendaten)            │
│ - Audio-Samples oder Video-Frames    │
└──────────────────────────────────────┘

SRTP-Paketstruktur:
┌──────────────────────────────────────┐
│ RTP Header (Klartext)                │
├──────────────────────────────────────┤
│ Encrypted Payload (verschlüsselt)    │
│ - Verschlüsselte Mediendaten          │
├──────────────────────────────────────┤
│ Authentication Tag (Authentifizierungs-Tag) │
│ - HMAC-SHA1 oder andere              │
└──────────────────────────────────────┘

Verschlüsselte Inhalte:
✓ RTP Payload (Mediendaten)
✗ RTP Header (nicht verschlüsselt - für Routing)

Authentifizierte Inhalte:
✓ RTP Header + verschlüsselter Payload

Datenkanäle (DataChannel)​

SCTP über DTLS über UDP​

Datenkanal-Protokollstapel:

Anwendungsschicht: DataChannel API
  ↓
Transportschicht: SCTP (Stream Control Transmission Protocol)
  ↓
Sicherheitsschicht: DTLS
  ↓
Netzwerkschicht: ICE + UDP + IP

Warum SCTP?
✓ Nachrichtengrenzen beibehalten (nicht wie TCP-Stream)
✓ Optionale Zuverlässigkeit (Neusendung konfigurierbar)
✓ Optionale Reihenfolge (Sortierung konfigurierbar)
✓ Multi-Stream-Unterstützung (mehrere Streams über eine Verbindung)
✓ Staukontrolle

SCTP-Funktionen:
1. Zuverlässig/Unzuverlässig optional
2. Geordnet/Ungeordnet optional
3. Nachrichtengrenzen
4. Multiplexing

Zusammenfassung​

Kernpunkte​

✓ WebRTC verwendet UDP-Transport
✓ ICE behandelt NAT-Traversierung
✓ DTLS bietet Verschlüsselung
✓ SRTP schützt Medien
✓ SCTP unterstützt Datenkanäle

Transportstapel:
Anwendung → RTP/SCTP → SRTP/DTLS → ICE → UDP → IP

Kandidatentypen:
Host > Server Reflexive > Relay

Verschlüsselung:
DTLS handelt Schlüssel aus → SRTP verschlüsselt Medien

Datenkanäle:
Zuverlässig/Unzuverlässig konfigurierbar
Geordnet/Ungeordnet konfigurierbar

Staukontrolle:
GCC-Algorithmus
Bandbreitenerkennung
Ratenanpassung

Referenzen​

Verwandte RFCs:

  • [RFC 8835] Transports for WebRTC ← Dieses Dokument
  • [RFC 8445] ICE
  • [RFC 6347] DTLS 1.2
  • [RFC 3711] SRTP
  • [RFC 4960] SCTP
  • [RFC 8831] WebRTC Data Channels

Zusammenfassung: Der WebRTC-Transportstapel baut durch die raffinierte Kombination von ICE, DTLS und SRTP auf unzuverlässigem UDP eine sichere und effiziente Echtzeitkommunikationsinfrastruktur auf. Das Verständnis dieser Transportschichtprotokolle ist der Schlüssel zur Beherrschung von WebRTC!