Le due rive

Ciao e benvenuti alla stagione novantaquattro. Per i prossimi dieci episodi parliamo di WebRTC, la tecnologia che permette a due browser di parlarsi direttamente, con audio, video e dati, senza che i contenuti passino per forza da un server.

Ogni volta che avete fatto una videochiamata da una pagina web senza installare nulla, c'era WebRTC sotto. Google Meet, Microsoft Teams nella versione web, Jitsi, Discord nel browser, le piattaforme per le telefonate di assistenza clienti, perfino molti strumenti per registrare podcast a distanza. Tutti usano gli stessi mattoni.

In questa stagione apriamo quei mattoni uno per uno. E per tenerli insieme useremo un'immagine: due rive di un fiume, e un ponte da costruire tra di loro.

Partiamo da come funziona il web di tutti i giorni.

Il web che conosciamo è fatto di client e server. Il browser chiede, il server risponde. Anche quando due persone chattano su una pagina web, i messaggi di solito vanno dal primo browser a un server e dal server al secondo browser. Il server sta sempre in mezzo: riceve, conserva, inoltra.

WebRTC rompe questo schema. Il suo obiettivo è che due browser, che chiameremo pari, dall'inglese peer, si scambino i dati direttamente. Il video della vostra videocamera non va su un server per poi essere scaricato dall'altra parte: viaggia, quando è possibile, dalla vostra rete alla rete dell'altra persona, per la strada più corta.

Perché è importante? Per tre ragioni. La prima è la latenza: in una conversazione, ogni decina di millisecondi conta, e un passaggio in meno è un ritardo in meno. La seconda è il costo: se il video non passa dal vostro server, non pagate quella banda. La terza è la riservatezza: quello che non passa dal vostro server, il vostro server non lo vede.

Ecco la nostra metafora. Due villaggi su due rive opposte di un fiume. Fino a ieri, per comunicare, dovevano mandare tutto alla città più vicina, che smistava. WebRTC è il progetto di costruire un ponte diretto tra le due rive. Sembra semplice. Vedremo che non lo è affatto.

Come per molte tecnologie del web, la storia parte da un'acquisizione.

Nel 2010 Google compra Global IP Solutions, un'azienda svedese che produceva i motori audio e video usati da molti software di telefonia via internet. Quei motori contenevano anni di lavoro su problemi difficilissimi: cancellare l'eco, ridurre il rumore di fondo, adattarsi a una rete che perde pacchetti.

Nella primavera del 2011 Google rende tutto quel codice open source, con un'idea precisa: portarlo dentro il browser e farne uno standard. Nasce così il progetto WebRTC. E c'è un dettaglio che chi ha seguito la stagione scorsa riconoscerà: tra i codec video scelti fin dall'inizio c'era VP8, lo stesso codec da cui WebP aveva preso in prestito le sue tessere. Stesso anno, stessa azienda, stessa strategia: rendere aperte tecnologie che prima erano chiuse.

La standardizzazione è stata lunga. Da una parte il W3C, che definisce le API JavaScript. Dall'altra la IETF, che definisce i protocolli di rete. Le due organizzazioni hanno lavorato in parallelo per quasi dieci anni. A gennaio 2021 il W3C pubblica WebRTC uno punto zero come raccomandazione, e nello stesso mese la IETF pubblica il gruppo di documenti che va dalla RFC 8825 alla RFC 8835. Da quel momento WebRTC è uno standard a tutti gli effetti.

Nel frattempo i browser si erano già mossi. Chrome e Firefox lo supportano tra la fine del 2012 e il 2013, Safari arriva con la versione 11 nel 2017, e oggi è disponibile ovunque, anche nelle applicazioni mobili, grazie alla libreria nativa che Google mantiene.

Dal punto di vista di chi scrive codice, WebRTC si presenta con tre API.

La prima è getUserMedia, che appartiene in realtà a una specifica vicina. Chiede all'utente il permesso di usare microfono e videocamera e restituisce un flusso, un MediaStream, fatto di tracce: una traccia audio, una traccia video. Sono il carico che vogliamo far passare sul ponte.

La seconda è RTCPeerConnection, il cuore di tutto. È l'oggetto che rappresenta il ponte verso l'altro pari. Gli aggiungete le tracce, lui si occupa di trovare una strada, di cifrare tutto, di adattare la qualità alla rete.

La terza è RTCDataChannel, un canale per i dati arbitrari: testo, file, comandi di un gioco. È una passerella accanto alla carreggiata principale, e le dedicheremo un intero episodio.

C'è un dettaglio pratico da sapere subito: queste API funzionano solo in un contesto sicuro. La pagina deve essere servita in HTTPS, oppure da localhost durante lo sviluppo. Se provate getUserMedia su una pagina in HTTP semplice, l'API non c'è proprio.

E qui arriva la parte che sorprende chi si avvicina a WebRTC per la prima volta.

Il browser vi dà gli attrezzi per costruire il ponte, ma alcune parti del cantiere restano a voi. La prima: le due rive devono mettersi d'accordo sul progetto prima di cominciare. Devono scambiarsi informazioni su quali codec sanno usare, quali indirizzi hanno, quali chiavi useranno. Questo scambio si chiama segnalazione, e WebRTC non lo standardizza. Non dice come farlo. Potete usare WebSocket, richieste HTTP, perfino un messaggio copiato a mano. È il messaggero, e lo dovete costruire voi.

La seconda: la maggior parte dei dispositivi su internet non ha un indirizzo pubblico. Sta dietro a un router, dietro a un firewall, dietro alle mura della propria città. Per scoprire come ci vedono da fuori servono server chiamati STUN. E quando le mura sono troppo alte servono server chiamati TURN, che fanno da traghetto. Anche questi, li dovete mettere in piedi voi, o noleggiarli.

La terza: se i partecipanti sono più di due, il ponte diretto per ogni coppia smette di funzionare. Servono server multimediali che stanno in mezzo al fiume. Anche qui, una scelta architetturale tutta vostra.

Ecco perché tanti progetti WebRTC funzionano perfettamente in sviluppo, tra due finestre dello stesso computer, e poi falliscono in produzione. Le parti invisibili sono quelle che fanno la differenza.

Per completezza, diamo un nome ai protocolli che incontreremo.

ICE è il procedimento che cerca una strada tra i due pari, provando tutte le combinazioni possibili. DTLS è la versione per datagrammi del protocollo che cifra il web, e serve a scambiare le chiavi. SRTP trasporta audio e video cifrati. SCTP trasporta i dati dei canali dati. E tutto questo viaggia quasi sempre su UDP, non su TCP, perché in una conversazione un pacchetto in ritardo vale meno di un pacchetto perso: meglio andare avanti che aspettare.

Non dovete memorizzarli oggi. Ogni sigla avrà il suo posto nella metafora.

Ecco il percorso.

Nel secondo episodio incontriamo il messaggero: la segnalazione e il formato SDP con cui le rive si scambiano il progetto. Nel terzo i cancelli e la vedetta: le mura dei router, ICE e STUN. Nel quarto il traghetto: TURN, quando serve e come configurarlo. Nel quinto la parola d'ordine: la sicurezza, la cifratura obbligatoria e quella da un capo all'altro.

Poi il carico. Nel sesto episodio i carri sul ponte: audio, video, codec e controllo della congestione. Nel settimo la passerella: i canali dati. Nell'ottavo l'isola in mezzo al fiume: le architetture con più partecipanti e i server multimediali. Nel nono il cantiere: il codice, con un server di segnalazione in Go e un client in JavaScript. E nel decimo il collaudo e l'orizzonte: come si diagnostica una chiamata che non va, e cosa sta arrivando dopo WebRTC.

Quindi, ricapitolando: WebRTC è il modo in cui due browser si parlano direttamente, nato nel 2011 dal codice di Global IP Solutions e diventato standard nel 2021. Vi dà tre API, ma lascia a voi la segnalazione, i server per attraversare le mura e l'architettura con più partecipanti.

Nel prossimo episodio partiamo dal primo pezzo che il browser non fa: il messaggero che porta il progetto del ponte da una riva all'altra. Ci sentiamo lì.