Un paio di settimane fa, abbiamo attivato silenziosamente il supporto per il tunneling TCP bidirezionale nel Cloud vLine, diventando i primi fornitore di infrastrutture WebRTC per supportare la connessione attraverso firewall che bloccano il protocollo UDP. Questo potrebbe non sembrare interessante o importante, ma in realtà fa la differenza tra avere un servizio che "di solito si connette" e uno che "funziona e basta". Vi spieghiamo perché:
Una delle tante cose fantastiche di WebRTC è che è relativamente facile da avviare. Avvia un'istanza di apprtc backend per la segnalazione, copia e incolla del codice JavaScript e, voilà, puoi effettuare videochiamate nella tua app (in realtà è un po' più complicato, ma un bravo sviluppatore web può facilmente realizzare una video chat dimostrativa funzionante in un giorno o due).
Purtroppo, il passaggio da una demo a un servizio di livello produttivo può essere più impegnativo di quanto si possa immaginare (e più costoso!). Ecco come di solito si svolge:
Livello 1: STORDIMENTO
Si inizia effettuando le prime chiamate tramite una rete locale e tutto funziona alla perfezione. Evviva! Poi si prova a chiamare qualcuno al di fuori del firewall e possono verificarsi due situazioni.
1) Se per caso hai copiato e incollato l'indirizzo del server STUN di Google dal codice sorgente di apprtc, la tua chiamata andrà a buon fine e sarai contento (anche se potresti avere qualche dubbio persistente sul fatto che sia lecito utilizzare un servizio non documentato per il quale Google non ha dato esplicitamente il permesso agli sviluppatori di terze parti di utilizzare. Nota il silenzio di Google su questa discussione).
2) Se non hai configurato un server STUN, la tua chiamata fallirà. Una piccola ricerca rivelerà che STUN è un protocollo che il browser utilizza per determinare il proprio indirizzo IP pubblico e aprire una falla nel firewall. Quindi, se si desidera connettersi attraverso un firewall, sarà necessario un server STUN. Poche ore dopo, avrete un server open source attivo e funzionante su EC2. Una piccola istanza dovrebbe essere sufficiente ($43.92 al mese), ma probabilmente vorrete eseguirne almeno due per garantire la disponibilità, preferibilmente in regioni diverse (quindi $87.84 al mese).
Livello 2: TURNO
Esegui qualche altra chiamata di prova e funziona tutta. Le cose sembrano andare bene. Poi provi a fare una chiamata tra due reti aziendali e fallisce. Grrr. Mentre facevi ricerche su STUN, hai letto di un altro protocollo chiamato TURN Questo protocollo viene utilizzato per inoltrare i dati nei casi in cui il browser non riesce a stabilire una connessione peer-to-peer. Non eri sicuro che fosse strettamente necessario, ma ulteriori ricerche rivelano che STUN è sufficiente solo per gestire circa 80% chiamate. Se questo non ti basta (e probabilmente non lo è), avrai bisogno di un server TURN.
Alcuni discussioni della mailing list più tardi, e avrai un server TURN attivo e funzionante sulla tua istanza EC2. In realtà, la velocità di trasmissione di rete su un'istanza piccola può essere piuttosto imprevedibile, se qualcun altro sta usando la tua interfaccia di rete condivisa, quindi dovresti pensare di ottenere un'istanza più grande. Un'istanza media ($87.84 al mese) funziona abbastanza bene, ma per la massima prevedibilità e il minimo jitter, vorrai un'istanza extra large ($351.36 al mese), che ti darà "“elevate prestazioni di rete”Anzi, facciamo due ($703.52 al mese), per la disponibilità.
Naturalmente, dato che stai trasmettendo video, dovrai considerare anche i costi della larghezza di banda. Il prezzo base su EC2 è $0,12 per GB. Mentre fai i calcoli, potresti iniziare a chiederti cosa impedisce a qualcun altro di utilizzare quel server pubblico che hai appena configurato e di far lievitare le tue bollette di banda. Ecco una buona risposta. discussione sulla mailing list In merito all'argomento. Riassumendo: non esiste un modo efficace per impedirlo, dato il funzionamento del protocollo TURN e il fatto che le credenziali TURN devono essere presenti nel codice JavaScript, dove chiunque può trovarle.
Ma non perdiamoci in dettagli economici. Ora puoi chiamare i tuoi amici che lavorano in altre aziende tecnologiche. Fantastico! Poi provi a chiamare qualcuno di una grande azienda, non tecnologica, e la chiamata fallisce. Accidenti. Pensavi che TURN ti avesse protetto.
20 minuti dopo, dopo un'ulteriore ricerca, scopri che l'implementazione dell'allocazione TURN di Chrome supporta solo l'inoltro di pacchetti UDP. Chrome 28 aggiungerà il supporto per assegnazione un server TURN su TCP, ma i pacchetti verranno comunque inoltrati tramite UDP. Ops, questo non risolve ancora il tuo problema quando il firewall blocca il traffico UDP.
Livello 3: Cloud vLine
È qui che entra in gioco il nostro nuovo supporto per il tunneling TCP. Non si basa sull'implementazione TURN di Chrome, quindi funziona già oggi in Chrome. Inoltre, funziona anche se entrambe le parti si trovano dietro firewall che bloccano UDP. Tutto ciò che serve è l'accesso a Internet tramite la porta 443 (la porta HTTPS), che la stragrande maggioranza dei firewall consente.
Non è necessario fare nulla di speciale per abilitare il tunneling TCP nel tuo servizio vLine. Basta usare vline.js per creare la tua app e ci connetteremo utilizzando il metodo migliore disponibile per ogni chiamata. Eseguiamo un rete globale di server ad alta disponibilità, In questo modo, garantiremo la migliore qualità di chiamata possibile a tutti i vostri utenti, ovunque nel mondo, anche dietro firewall che bloccano tutto tranne il traffico TCP sulla porta HTTPS. Nel caso ve lo stiate chiedendo, utilizziamo ancora la crittografia DTLS end-to-end, quindi i nostri server non visualizzano mai i vostri flussi multimediali non crittografati.
Il nostro obiettivo è un tasso di connessione di 100%. Se disponi di una rete in cui le chiamate non si connettono, per favore facci sapere.
Nota 1: Se vuoi testarlo tu stesso bloccando UDP sul tuo firewall, ricorda di lasciare aperta la porta DNS (53).
Nota 2: Alcuni firewall estremamente restrittivi che eseguono l'ispezione stateful dei pacchetti potrebbero comunque bloccare le connessioni poiché, anche se il browser utilizza la porta HTTPS, in realtà non sta eseguendo SSL/TLS (non abbiamo mai riscontrato un firewall di questo tipo nella pratica, ma esistono). Chrome supporterà presto le connessioni WebRTC su TLS, a quel punto saremo in grado di aggirare anche questi firewall.
