Passa al contenuto principale

RFC 8835 - Transports for WebRTC

  • Stato: Proposed Standard
  • Pubblicato: January 2021
  • Stream: IETF
  • Errata: Nessun errata

Informazioni di Base​

  • Numero RFC: 8835
  • Titolo: Transports for WebRTC
  • Titolo Italiano: Trasporti per WebRTC
  • Data di Pubblicazione: Gennaio 2021
  • Stato: PROPOSED STANDARD (Standard Proposto)
  • Autore: H. Alvestrand (Google)

Sommario (Abstract)​

Questa specifica descrive lo stack di protocolli di trasporto utilizzato da WebRTC, inclusi i componenti principali ICE, DTLS e SRTP. WebRTC trasmette media e dati tramite UDP, utilizza ICE per l'attraversamento NAT, DTLS per stabilire connessioni sicure e SRTP per crittografare i flussi multimediali.

Panoramica dello Stack di Trasporto WebRTC​

Stack di Protocolli Completo​

Stack di Protocolli WebRTC (dall'alto verso il basso):

┌─────────────────────────────────────────┐
│   Livello Applicazione (Application)     │
│   - Flussi Audio/Video                   │
│   - Canali Dati (DataChannel)            │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   RTP/RTCP (Protocollo di Trasporto     │
│             in Tempo Reale)              │
│   - Trasmissione Media                   │
│   - Informazioni di Controllo            │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   SRTP/SRTCP (RTP Sicuro)               │
│   - Flussi Media Crittografati           │
│   - Autenticazione                       │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   DTLS (TLS per Datagrammi)             │
│   - Negoziazione delle Chiavi            │
│   - Crittografia End-to-End              │
│   - Verifica dei Certificati             │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   ICE (Stabilimento di Connettività     │
│        Interattiva)                      │
│   - Attraversamento NAT                  │
│   - Raccolta Candidati                   │
│   - Verifiche di Connettività            │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   UDP (User Datagram Protocol)          │
│   - Trasporto di Base                    │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   IP (Internet Protocol)                │
│   - IPv4 / IPv6                          │
└─────────────────────────────────────────┘

Stack Aggiuntivo per Canali Dati:

┌─────────────────────────────────────────┐
│   DataChannel API                       │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   SCTP (Stream Control Transmission     │
│          Protocol)                       │
│   - Trasmissione Affidabile              │
│   - Confini dei Messaggi                 │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   DTLS                                  │
└─────────────────────────────────────────┘
              ↓
         (ICE + UDP + IP)

Perché UDP?​

UDP vs TCP per WebRTC:

Problemi TCP:
❌ Blocco Head-of-Line (Head-of-Line Blocking)
   - Una perdita di pacchetto blocca l'intero flusso
   - Inaccettabile per audio/video in tempo reale

❌ Stabilimento Connessione Lento
   - Ritardo Three-Way Handshake
   - Ritardo Handshake TLS

❌ Controllo della Congestione Inflessibile
   - Algoritmo Fisso
   - Nessuna ottimizzazione per media in tempo reale

Vantaggi UDP:
✓ Nessun Blocco Head-of-Line
   - Pacchetti indipendenti
   - Perdita di pacchetto non influenza i pacchetti successivi

✓ Bassa Latenza
   - Nessuna attesa per conferma
   - Invio immediato

✓ Controllo Flessibile
   - Controllo della congestione a livello applicazione
   - Ottimizzato per media

Scelta WebRTC:
UDP + Affidabilità a livello applicazione
→ Media con SRTP (non affidabile)
→ Dati con SCTP (affidabilità opzionale)

ICE (Interactive Connectivity Establishment)​

Ruolo di ICE​

Problema: Attraversamento NAT

Scenario:
Utente A (192.168.1.100) ← NAT1 ← Internet → NAT2 → Utente B (192.168.1.200)
         IP Privato                                      IP Privato

Problema:
- A non sa come raggiungere l'IP privato di B
- B non sa come raggiungere l'IP privato di A
- NAT blocca connessioni esterne

Soluzione ICE:
1. Raccogliere Candidati (Candidates)
   - Candidato Host: IP locale
   - Candidato Server Reflexive: IP pubblica NAT (tramite STUN)
   - Candidato Relay: Indirizzo relay (tramite TURN)

2. Scambiare Candidati (tramite segnalazione)

3. Verifiche di Connettività (Connectivity Checks)
   - Testare tutte le coppie di candidati
   - Trovare il percorso migliore

4. Stabilire la Connessione

Tipi di Candidati​

// Candidato Host (indirizzo locale)
{
  type: 'host',
  ip: '192.168.1.100',
  port: 54321,
  protocol: 'udp',
  priority: 2130706431,
  foundation: '1',
  component: 1
}

// Candidato Server Reflexive (indirizzo pubblico ottenuto tramite STUN)
{
  type: 'srflx',
  ip: '203.0.113.1',      // IP Pubblico
  port: 12345,            // Porta mappata da NAT
  protocol: 'udp',
  priority: 1694498815,
  foundation: '2',
  relatedAddress: '192.168.1.100',  // IP Locale
  relatedPort: 54321
}

// Candidato Relay (indirizzo relay TURN)
{
  type: 'relay',
  ip: '198.51.100.1',     // IP del server TURN
  port: 3478,
  protocol: 'udp',
  priority: 16777215,
  foundation: '3',
  relatedAddress: '203.0.113.1',
  relatedPort: 12345
}

Ordine di Priorità:
Host > Server Reflexive > Relay
(Connessione diretta preferita, relay come ultima risorsa)

DTLS (Datagram Transport Layer Security)​

Ruolo di DTLS​

Perché DTLS è necessario:

Problema:
- UDP non è sicuro
- I flussi media RTP devono essere crittografati
- Necessaria negoziazione delle chiavi

Soluzione DTLS:
✓ Stabilire connessione sicura
✓ Negoziare chiavi di crittografia
✓ Autenticare la parte remota
✓ Protezione dell'integrità

DTLS vs TLS:
TLS (basato su TCP):
- Trasporto affidabile
- Consegna ordinata
- Trasporto a flusso

DTLS (basato su UDP):
- Trasporto non affidabile
- Possibilmente disordinato
- Trasporto a datagramma
→ Richiede gestione aggiuntiva delle perdite e riordinamento

Versione DTLS:
WebRTC richiede: DTLS 1.2 o superiore
Raccomandato: DTLS 1.3

SRTP (Secure RTP)​

Crittografia SRTP​

SRTP = RTP + Crittografia + Autenticazione

Struttura Pacchetto RTP:
┌──────────────────────────────────────┐
│ Intestazione RTP (12+ byte)          │
│ - V, P, X, CC, M, PT, Seq, TS, SSRC │
├──────────────────────────────────────┤
│ Payload RTP (dati media)             │
│ - Campioni audio o frame video       │
└──────────────────────────────────────┘

Struttura Pacchetto SRTP:
┌──────────────────────────────────────┐
│ Intestazione RTP (testo chiaro)      │
├──────────────────────────────────────┤
│ Payload Crittografato (crittografato)│
│ - Dati media crittografati            │
├──────────────────────────────────────┤
│ Tag di Autenticazione                │
│ - HMAC-SHA1 o altro                  │
└──────────────────────────────────────┘

Contenuto Crittografato:
✓ Payload RTP (dati media)
✗ Intestazione RTP (non crittografata - per routing)

Contenuto Autenticato:
✓ Intestazione RTP + payload crittografato

Canali Dati (DataChannel)​

SCTP su DTLS su UDP​

Stack di Protocolli dei Canali Dati:

Livello Applicazione: DataChannel API
  ↓
Livello Trasporto: SCTP (Stream Control Transmission Protocol)
  ↓
Livello Sicurezza: DTLS
  ↓
Livello Rete: ICE + UDP + IP

Perché SCTP?
✓ Preservare i confini dei messaggi (non come flusso TCP)
✓ Affidabilità opzionale (ritrasmissione configurabile)
✓ Ordine opzionale (ordinamento configurabile)
✓ Supporto multi-flusso (più flussi su una connessione)
✓ Controllo della congestione

Funzionalità SCTP:
1. Affidabile/Non affidabile opzionale
2. Ordinato/Disordinato opzionale
3. Confini dei messaggi
4. Multiplexing

Punti Chiave​

✓ WebRTC utilizza trasporto UDP
✓ ICE gestisce l'attraversamento NAT
✓ DTLS fornisce crittografia
✓ SRTP protegge i media
✓ SCTP supporta i canali dati

Stack di Trasporto:
Applicazione → RTP/SCTP → SRTP/DTLS → ICE → UDP → IP

Tipi di Candidati:
Host > Server Reflexive > Relay

Crittografia:
DTLS negozia chiavi → SRTP crittografa media

Canali Dati:
Affidabile/Non affidabile configurabile
Ordinato/Disordinato configurabile

Controllo della Congestione:
Algoritmo GCC
Sondaggio della larghezza di banda
Adattamento del tasso

Riferimenti​

RFC Correlati:

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

Riepilogo: Lo stack di trasporto WebRTC costruisce un'infrastruttura di comunicazione in tempo reale sicura ed efficiente su UDP non affidabile attraverso la sofisticata combinazione di ICE, DTLS e SRTP. Comprendere questi protocolli di livello trasporto è la chiave per padroneggiare WebRTC!