Vor einigen Wochen haben wir stillschweigend die Unterstützung für bidirektionales TCP-Tunneling in der vLine Cloud aktiviert und sind damit der erste Anbieter geworden, der dies ermöglicht. WebRTC-Infrastrukturanbieter Um Verbindungen durch Firewalls zu ermöglichen, die UDP blockieren. Das mag zunächst uninteressant oder unwichtig klingen, macht aber tatsächlich den Unterschied zwischen einem Dienst, der “meistens eine Verbindung herstellt”, und einem, der “einfach funktioniert”. Wir erklären es Ihnen:
Einer der vielen Vorteile von WebRTC ist der relativ einfache Einstieg. Starten Sie eine Instanz von apprtc Sie benötigen ein Backend für die Signalisierung, müssen nur etwas JavaScript kopieren und einfügen, und schon können Sie Videoanrufe in Ihrer App tätigen (eigentlich ist es etwas schwieriger, aber ein guter Webentwickler kann innerhalb von ein bis zwei Tagen eine vorführbare Video-Chat-Funktion bereitstellen).
Leider kann der Weg von der Demoversion zum produktionsreifen Service schwieriger (und teurer!) sein als erwartet. So läuft es üblicherweise ab:
Stufe 1: BELASTUNG
Sie beginnen mit Ihren ersten Anrufen über ein lokales Netzwerk, und alles funktioniert einwandfrei. Hurra! Dann versuchen Sie, jemanden außerhalb Ihrer Firewall anzurufen, und eines von zwei Dingen wird passieren.
1) Falls Sie die Adresse des Google STUN-Servers aus dem apprtc-Quellcode kopiert haben, wird Ihr Anruf erfolgreich durchgeführt und Sie werden zufrieden sein (obwohl Sie möglicherweise Zweifel haben, ob die Nutzung eines undokumentierten Dienstes, für den Google Drittanbietern keine ausdrückliche Genehmigung erteilt hat, zulässig ist). Beachten Sie das Schweigen von Google zu diesem Thema. dieser Thread).
2) Wenn kein STUN-Server konfiguriert ist, schlägt Ihr Anruf fehl. Eine kurze Recherche wird zeigen, dass STUN ist ein Protokoll Der Browser verwendet STUN, um seine öffentliche IP-Adresse zu ermitteln und die Firewall zu umgehen. Um also eine Verbindung durch eine Firewall herzustellen, benötigen Sie einen STUN-Server. Wenige Stunden später ist Ihr Open-Source-Server auf EC2 betriebsbereit. Eine kleine Instanz reicht in der Regel aus (1.420 £ 43,92 pro Monat), aber für eine höhere Verfügbarkeit empfiehlt es sich, mindestens zwei Instanzen zu betreiben, idealerweise in verschiedenen Regionen (dafür 1.420 £ 87,84 pro Monat).
Level 2: RUNDE
Sie führen einige weitere Testanrufe durch, und alle funktionieren. Alles sieht gut aus. Dann versuchen Sie, einen Anruf zwischen zwei Firmennetzwerken zu tätigen, und er schlägt fehl. Ärgerlich! Bei Ihrer Recherche zu STUN haben Sie Folgendes gelesen: ein weiteres Protokoll namens TURN Das dient der Datenübertragung, wenn der Browser keine Peer-to-Peer-Verbindung herstellen kann. Sie waren sich nicht sicher, ob das unbedingt nötig ist, aber weitere Recherchen zeigen, dass STUN nur für etwa 80% Anrufe ausreicht. Falls Ihnen das nicht genügt (und das tut es wahrscheinlich), benötigen Sie einen TURN-Server.
Ein paar Threads in der Mailingliste Später haben Sie einen TURN-Server auf Ihrer EC2-Instanz eingerichtet und in Betrieb. Tatsächlich kann der Netzwerkdurchsatz einer kleinen Instanz ziemlich unvorhersehbar sein, wenn jemand anderes Ihre gemeinsam genutzte Netzwerkschnittstelle verwendet. Daher sollten Sie über eine größere Instanz nachdenken. Eine mittlere Instanz ($87,84 pro Monat) funktioniert recht gut, aber für maximale Vorhersagbarkeit und geringsten Jitter benötigen Sie eine extra große Instanz ($351,36 pro Monat), die Ihnen …“hohe Netzwerkleistung”Tatsächlich sollten es zwei sein ($703.52 pro Monat), um die Verfügbarkeit zu gewährleisten.
Da Sie Videos übertragen, müssen Sie natürlich auch die Bandbreitenkosten berücksichtigen. Die Basispreise für EC2 betragen $0,12 pro GB. Während Sie die Zahlen durchrechnen, fragen Sie sich vielleicht, was jemand anderen daran hindert, den gerade eingerichteten öffentlichen Server zu nutzen und Ihre Bandbreitenkosten in die Höhe zu treiben. Hier ist ein guter Mailinglistenthread Zum Thema: Zusammenfassend lässt sich sagen, dass es aufgrund der Funktionsweise des TURN-Protokolls und der Tatsache, dass die TURN-Zugangsdaten in Ihrem JavaScript-Code vorhanden sein müssen und somit für jeden zugänglich sind, keine optimale Möglichkeit gibt, dies zu verhindern.
Aber lassen wir die Kosten mal beiseite. Man kann jetzt Freunde bei anderen Tech-Firmen anrufen. Super! Dann versucht man, jemanden bei einem großen Konzern außerhalb der Tech-Branche anzurufen, und es klappt nicht. Mist! Man dachte, TURN hätte alles abgedeckt.
20 Minuten später, nach weiterer Recherche, stellen Sie fest, dass die TURN-Zuweisung in Chrome nur die Weiterleitung von UDP-Paketen unterstützt. Chrome 28 wird diese Unterstützung hinzufügen. Zuteilung Ein TURN-Server über TCP, aber die Pakete werden trotzdem über UDP weitergeleitet. Ups, das löst Ihr Problem leider noch nicht, wenn die Firewall den UDP-Verkehr blockiert.
Stufe 3: vLine Cloud
Hier kommt unsere neue TCP-Tunneling-Unterstützung ins Spiel. Sie benötigt nicht die TURN-Implementierung von Chrome und funktioniert daher bereits jetzt in Chrome. Außerdem funktioniert sie selbst dann, wenn sich beide Parteien hinter Firewalls befinden, die UDP blockieren. Alles, was erforderlich ist, ist ein Internetzugang über Port 443 (den HTTPS-Port), den die allermeisten Firewalls zulassen.
Sie müssen nichts Besonderes tun, um TCP-Tunneling in Ihrem vLine-Dienst zu aktivieren. Verwenden Sie einfach vline.js zum Erstellen Ihrer Anwendung, und wir stellen die Verbindung über die jeweils beste verfügbare Methode her. Wir führen einen hochverfügbares globales Servernetzwerk, Wir bieten Ihren Nutzern weltweit die bestmögliche Gesprächsqualität, selbst hinter Firewalls, die ausschließlich TCP-Verkehr über den HTTPS-Port blockieren. Und falls Sie sich fragen: Ja, wir verwenden weiterhin Ende-zu-Ende-DTLS, sodass unsere Server Ihre unverschlüsselten Mediendatenströme niemals einsehen können.
Unser Ziel ist eine Verbindungsrate von 1001 TP41T. Falls in Ihrem Netzwerk keine Anrufe zustande kommen, wenden Sie sich bitte an uns. Lassen Sie es uns wissen.
Hinweis 1: Wenn Sie dies selbst testen möchten, indem Sie UDP auf Ihrer Firewall blockieren, denken Sie daran, den DNS-Port (53) offen zu lassen.
Hinweis 2: Einige sehr restriktive Firewalls, die eine zustandsbehaftete Paketprüfung durchführen, können Verbindungen weiterhin blockieren, da der Browser zwar den HTTPS-Port verwendet, aber tatsächlich kein SSL/TLS nutzt (wir sind zwar noch nie auf eine solche Firewall gestoßen, aber sie existieren). Chrome wird in Kürze WebRTC-Verbindungen über TLS unterstützen; ab diesem Zeitpunkt werden wir auch diese Firewalls umgehen können.