WebRTC ve SDK'lar ile görüntülü aramalar ve gerçek zamanlı yayın akışı

Eğer bir şey inşa ediyorsanız JavaScript yan projesi Video görüşmelerine ihtiyacınız varsa, tereddüt etmeniz normal: Saf WebRTC mi kullanmalıyım, Agora, Twilio, Mux veya Zegocloud gibi bir SDK mı kullanmalıyım yoksa React Native'de RN-WebRTC'ye mi geçmeliyim? Kötü haber şu ki, tek bir çözüm yok. İyi haber ise, gerçek zamanlı JavaScript'i anlıyor olmanız; bu da bilinçli bir karar vermenizi ve mimariyi bozmaktan kaçınmanızı sağlayacak ideal bir konumda olmanızı sağlıyor.

Aşağıdaki satırlarda, adım adım nasıl çalıştığını göreceksiniz. WebRTC İçerisindeAgora (ve diğer benzer sağlayıcılar) ne gibi bir rol oynuyor? Kendi altyapınızı kurmak (STUN/TURN, sinyalizasyon, SFU, medya sunucuları...) ne anlama geliyor? Ve video görüşmeleri ve gerçek zamanlı yayın için maliyet, karmaşıklık ve ölçeklenebilirlik arasındaki gerçek denge nedir?

WebRTC nedir ve neden her şeyin temelidir?

WebRTC (Web Gerçek Zamanlı İletişim) Bu, eklentilere veya harici uygulamalara gerek kalmadan, doğrudan bir tarayıcıdan veya yerel uygulamadan gerçek zamanlı ses, video ve veri akışı sağlayan bir dizi açık kaynaklı standart, API ve protokoldür. W3C ve IETF tarafından standartlaştırılmıştır ve tüm modern tarayıcılar tarafından desteklenmektedir: Chrome, Firefox, Safari, Edge, Opera ve birçok mobil tarayıcı.

Felsefeleri açık: iletişimi mümkün kılmak. eşler arası (P2P) Kullanıcılar arasında çok düşük gecikmeyle iletişim kurar ve kodekler, titreşim, yankı, paket kaybı, şifreleme vb. gibi tüm rahatsız edici ağ sorunlarını arka planda halleder. Bu, bire bir görüntülü görüşmeden bir sisteme kadar her şeyi kapsar. etkileşimli yayın Doğru altyapıyla birleştirilirse, yüzlerce hatta binlerce izleyiciye ev sahipliği yapabilir.

İlgili makale:

Android'de Arama Uygulaması Nasıl Kullanılır ve Oluşturulur: Kullanıcılar ve Geliştiriciler İçin Nihai Kılavuz

WebRTC'nin temel API'leri: getUserMedia, RTCPeerConnection ve RTCDataChannel

WebRTC, ister kendi çözümünüzü geliştirin ister Agora gibi bir SDK kullanın, kesinlikle kullanacağınız üç ana tarayıcı tarafı API'sine dayanır:

• MediaStream / getUserMedia: Video ve ses kaydı yapmak için (kamera, mikrofon ve hatta ekran veya tabletler).
• RTCPeerBağlantısı: Ses ve video akışlarını eşler arasında müzakere etmek ve iletmek.
• RTCVeri Kanalıİstemciler arasında düşük gecikmeyle rastgele veri (metin, ikili veri, dosya) göndermek.

ile getUserMedia Tarayıcının kameraya ve mikrofona erişimini talep edebilir ve yanıt alabilirsiniz. MediaStream Daha sonra bunu bir öğeyle ilişkilendirirsiniz. <video> ile video.srcObject = stream. Başvurabilirsiniz kısıtlamalar (çözünürlük, kare hızı, ön/arka kamera vb.) ve bu kriterler karşılanmazsa, aşağıdaki gibi hatalar alırsınız: OverconstrainedErrorAlternatifler sunmayı başarmanız gerekir (örneğin, 1080p'den 720p'ye düşürmek ve ayarlamalar uygulamak gibi). mikrofon sesini iyileştirin).

API'si RTCPeerBağlantısı Bu, görüşmelerin kalbidir: SDP (teklif/yanıt) müzakeresini, ICE (durdurma/döndürme) aday toplamasını, bağlantı kurulmasını ve SRTP üzerinden güvenli iletimi yönetir. Kodunuzdan, bağlantıyı oluşturmanız, medya parçaları eklemeniz ve aşağıdaki gibi olaylara tepki vermeniz yeterlidir: onicecandidate u ontrack Tabela işlerini de sen halledersin.

Son olarak, RTCVeri Kanalı Bu, WebSocket'e benzer ancak noktadan noktaya ve güvenilirlik ile sıralama üzerinde hassas kontrol sağlayan veri kanalları kurmanıza olanak tanır. Video görüşmeleri, dosya paylaşımı, oyun durumu senkronizasyonu veya gerçek zamanlı iş birliği için kullanışlıdır. Sözdizimi tanıdıktır: dataChannel.send() y onmessage alıcıda.

Sinyalleme: WebRTC'nin tanımlamadığı "bağlayıcı unsur"

Tipik bir yanlış anlama: WebRTC tabelaları içermezRTCPeerConnection bilgi alışverişi yapmayı gerektirir, ancak bunun nasıl yapılacağını belirlemez. Bunu kendiniz tanımlamanız gerekir veya üçüncü taraf bir SDK bunu sizin için soyutlayabilir.

Çiftler sinyal yoluyla gönderilir:

• Oturum kontrol mesajları: Çağrı başlatma, sonlandırma, hatalar.
• Ağ bilgileri: ICE adayları (bulunan IP adresleri/portlar).
• Medya meta verileriSDP, codec'ler, çözünürlükler vb. ile ilgili teklifler ve yanıtlar sunar.

Bu işaretleme genellikle şu şekilde uygulanır: WebSocketsSocket.IO, HTTP (polling/long-polling), MQTT veya diğer çift yönlü mekanizmalar. Çok tipik bir örnek, Node.js sunucusudur. Soket.IO "Odaları" yöneten ve mesajları ileten metin/JSON türü Müşteriler arasında:

Sunucu: alır create or joinOda yoksa oda oluşturur, en fazla iki istemciyi destekler (temel bir görüntülü görüşme için) ve mesajları iletir. message Odadaki diğer prizlere. Maksimum kullanıcı sayısını aşmamak veya kendi oda mantığınızı tasarlamak sizin sorumluluğunuzdadır.

MüşteriSayfa yüklenirken oda adı istenir (veya URL'den çıkarılır), ardından şu mesaj görüntülenir: create or joinŞu gibi etkinlikleri dinleyin: created, joined, full, ready ve diğer tarafla görüşmeyi başlatma veya reddetme konusunda anlaşır.

Bu desen, şunlar için mükemmeldir: prototip veya yan projeİhtiyaç duyulduğunda kümeler ve yük dengeleyicilerle ölçeklendirebileceğiniz hafif bir sinyal sunucusu sunar.

STUN, TURN, ICE: Çıldırmadan NAT'lardan ve güvenlik duvarlarından geçmek

İdeal bir dünyada, iki kullanıcı her zaman erişilebilir ağlarda olur ve doğrudan bağlantı kurardı. Gerçek dünyada ise durum farklıdır. NAT'lar, güvenlik duvarları, CGNAT İnternet servis sağlayıcılarından ve paranoyak kurumsal ağlardan. İşte burada ICE devreye giriyor, STUN ve TURN'ü birleştiriyor.

• Sersemletici (NAT için Oturum Geçiş Yardımcı Programları), bir istemcinin kendi oturum geçiş adresini bulmasını sağlar. Genel IP ve portSTUN sunucusu yalnızca bu bilgiyi gönderir.
• DÖNÜŞ (NAT etrafında röleler kullanarak geçiş) şu şekilde işlev görür: röle sunucusu Doğrudan P2P kanalı açmanın bir yolu olmadığında medya aktarımı gerçekleşir. Ses/video trafiği bu kanal üzerinden geçtiği için sunucu bant genişliğini tüketir ve maliyete neden olur.
• ICE (Etkileşimli Bağlantı Kurulumu), geçerli bir rota bulunana kadar tüm olası adayları (STUN, TURN röleleri tarafından yansıtılan yerel adresler) test etmekten sorumludur.

Pratikte, RTCPeerConnection yapılandırma nesnenize bir dizi eklersiniz. buzSunucular STUN/TURN URI'leri ile tarayıcı gerisini halleder. Kendi altyapınızı kurarsanız, STUN/TURN sunucularınızı dağıtmanız ve bakımını yapmanız gerekecektir; Agora, Twilio veya Zegocloud gibi bir SDK kullanıyorsanız, bu iş zaten halledilmiş ve üretime hazır durumdadır.

Düşük gecikmeli gerçek zamanlı yayın: WebRTC ve HLS/DASH karşılaştırması

Biz konuşurken canlı yayın İki ayrı dünya var: HTTP tabanlı protokoller (HLS, DASH) ve WebRTC. HLS/DASH, istemciden video bölümlerini indirip oynatarak çalışır; bu, CDN aracılığıyla ölçeklenebilirlik için mükemmeldir, ancak bazı dezavantajları da beraberinde getirir. birkaç saniyelik gecikmeler (5-30 saniye rahatlıkla).

WebRTC ise bunun tam tersini kullanır. UDP + RTP Video içeriğini kaynaktan oynatıcıya "itme" modunda, çok kısa başlatma süreleriyle ve tipik gecikme süreleriyle iletir. 500 ms (Ağ bağlantısı iyiyse genellikle ~250 ms sürer.) Bunu şu nedenlerle başarır:

• tıkanıklık kontrolü Entegre edilmiş bu sistem, paket kaybına, titreşime veya RTT'ye göre bit hızını ve çözünürlüğü gerçek zamanlı olarak ayarlar.
• Etkin kodeklerin (VP8, VP9, ​​H.264; giderek AV1) kullanımı ile donanım hızlandırma müsait olduğunda.
• Alıcının yalnızca ağının/cihazının destekleyebileceği katmanları almasını sağlamak için SVC (Ölçeklenebilir Video Kodlama) kullanma olasılığı.

Bu nedenle WebRTC doğal bir tercihtir. gerçek zamanlı açık artırmalarCanlı spor bahisleri, alım satım, etkileşimli oyunlar, uzaktan destek, teletıp, katılımcı sanal sınıflar veya birkaç saniyelik gecikmeye tahammül edemeyen finansal gösterge panelleri gibi hizmetler.

Sorun şu ki, saf P2P WebRTC binlerce izleyici için iyi ölçeklenemiyor; bunun için şunlara ihtiyacınız var: SFU'lar, medya sunucuları veya hibrit platformlarİşte tam da bu noktada Flussonic, Agora veya benzeri çözümler devreye giriyor.

P2P'nin Ötesine Geçmek: SFU'lar, Medya Sunucuları ve Hibrit Mimariler

Bire bir görüntülü görüşmede WebRTC kusursuz çalışır. Ancak 10, 20 veya 100 kullanıcı eklemeye başladığınızda işler değişir: her istemci birden fazla akış göndermek/almak zorunda kalır, işlemcisi aşırı ısınır ve ağ çöker. Burada üç klasik durum ortaya çıkar:

• MCU (Çok Noktalı Kontrol Ünitesi)Sunucu tüm akışları alır, karıştırır ve her istemciye tek bir akış gönderir. Avantajı: istemci tarafında düşük kaynak tüketimi. Dezavantajları: ağır sunucu yükü, daha az bireysel kalite kontrolü.
• SFU (Seçici İleri Sevk Birimi)Sunucu, akışları alır ve karıştırmadan seçici olarak iletir. Her izleyici, muhtemelen farklı kalitelerde olmak üzere, ihtiyaç duyduğu akışları alır. Bu, günümüzde en yaygın kullanılan modeldir. çok kullanıcılı video konferans ve ölçeklenebilir etkileşimli yayın.
• Hibrit mimariler WebRTC + HLS/DASHWebRTC, veri alımı ve etkileşim için kullanılırken, HLS/DASH gerçek zamanlı etkileşime ihtiyaç duymayan geniş kitlelere dağıtım yapar. Bu, ikisi arasında bir denge meselesidir. ultra düşük gecikme "Oyuncular" için küçük ölçekli, "izleyiciler" için ise büyük ölçekli bir yapı.

Medya sunucuları gibi Flussonik Diğerleri ise gerekli arka uç altyapısını sağlar: WebRTC akışını alırlar, gerekirse dönüştürürler, WebRTC üzerinden diğer istemcilere iletirler veya toplu dağıtım için HLS tipi protokollere dönüştürürler. Bu tür bir altyapı, pratikte, tekerleği yeniden icat etmeye gerek kalmadan bire bir görüşmelerin ötesine geçmeyi mümkün kılan şeydir.

Tipik kullanım alanları: görüntülü görüşmeler, yayın akışı, Nesnelerin İnterneti (IoT) ve daha fazlası.

WebRTC her yerde karşımıza çıkıyor ve muhtemelen farkında olmadan her gün kullanıyorsunuz. Özellikle iyi uyum sağladığı bazı örnekler şunlardır... video görüşmeleri ve video konferanslar:

• Görüntülü görüşmeler ve görüntülü konferanslarGoogle Meet, Jitsi, Slack, Microsoft Teams ve diğer birçok araç, video, ses ve ekran paylaşımı için (kısmen veya tamamen) WebRTC'ye dayanmaktadır.
• Gerçek zamanlı yayın hizmetleriTwitch, Meta Live, Vimeo Livestream gibi platformlar veya Streamyard gibi araçlar, veri alımı için WebRTC'yi ve toplu dağıtım için diğer teknolojileri bir araya getiriyor.
• Dosya paylaşımı özellikli sohbet ve mesajlaşmaRTCDataChannel sayesinde merkezi medya sunucularına ihtiyaç duymadan gerçek zamanlı sohbet, dosya paylaşımı, durum senkronizasyonu vb. özelliklere sahip olabilirsiniz.
• Bulut oyunları ve çok oyunculu oyunlarGeForce NOW veya Xbox Cloud Gaming gibi hizmetler, etkileşimli video için benzer teknolojilerden yararlanır; birçok P2P oyunu, oyun deneyimini senkronize etmek için WebRTC kullanır.
• Nesnelerin interneti ve gözetimAkıllı kameralar, bebek monitörleri, görüntülü kapı zilleri veya dronlar gönderebilir. gerçek zamanlı video WebRTC kullanarak mobil cihazlara ve tarayıcılara.
• Eğitim ve tele tıpSanal sınıflar (beyaz tahtalar, kısa sınavlar ve çift yönlü video görüşmeleri) veya gecikme süresinin ve güvenliğin çok önemli olduğu çevrimiçi tıbbi konsültasyonlar.

WebRTC güvenliği: şifreleme, izinler ve en iyi uygulamalar

WebRTC'de güvenlik ek bir özellik değil, yerleşik bir özelliktir. tasarımın içine entegre edilmişTüm medya bileşenleri şifrelenmiştir ve API'ler yalnızca güvenli kaynaklardan (HTTPS veya localhost) çalışır, ancak yine de dikkatli olmakta fayda vardır. video görüşmeleri yoluyla yapılan dolandırıcılıklar.

• DTLS (Datagram Taşıma Katmanı Güvenliği) iletim halindeki verileri şifreler.
• SRTP (Güvenli Gerçek Zamanlı İletim Protokolü), ses ve videonun kolayca manipüle edilmesini veya ele geçirilmesini engelleyecek şekilde koruma sağlar.
• Erişim kamera ve mikrofon Bu, görünür görsel göstergelerle (ikonlar, renkli noktalar vb.) açık kullanıcı izni gerektirir.
• Kurulacak eklenti olmadığı için risk şu şekildedir: kötü amaçlı yazılım Üçüncü taraf uzantılar veya ikili dosyalar içinde gizlenmiş.

Yine de kendi katmanınıza dikkat etmelisiniz: kullanın HTTPS üzerindenTalep ettiğiniz izinleri gözden geçirin, tarayıcıları ve kütüphaneleri güncel tutun ve sinyal sunucunuzun veya REST API'lerinizin güvenliğini ihmal etmeyin.

WebRTC ve diğer teknolojiler: VoIP, WebSockets ve tescilli platformlar

Geleneksel VoIP dünyasından geliyorsanız, SIP, PBX, yazılım tabanlı telefonlar ve pahalı sunuculara aşina olacaksınız. WebRTC paradigmayı değiştiriyor: kullanıcının herhangi bir bilgi vermesini gerektirmenize gerek yok. masaüstü istemcisi Özel bir donanıma gerek yok; bir tarayıcı ve nispeten basit bir sinyal sunucusu yeterli.

Karşı Geleneksel VoIPWebRTC, temel altyapı üzerindeki yükü azaltır ve uygulamaların doğrudan web'e entegre edilmesinin önünü açar. Birçok durumda, sinyallemeyi WebRTC'ye çeviren ağ geçitleri aracılığıyla SIP arka ucunuzu yeniden kullanabilirsiniz.

hakkında WebSocketsBunlar daha çok birbirini tamamlayıcı olarak görülmelidir: bildirimler, hafif sohbet veya durum güncellemeleri için idealdirler, ancak yoğun medya için uygun değillerdir. WebRTC ise şunlar için optimize edilmiştir: gerçek zamanlı ses/videoTıkanıklık kontrolü, kodekler, titreşim tamponu vb. ile birlikte. Pratikte, birçok proje sinyalizasyon için WebSockets'i ve medya iletimi için WebRTC'yi kullanır.

Eğer bunları aşağıdaki gibi platformlarla karşılaştırırsanız Zoom, GoToMeeting veya WebExAradaki fark modelde yatıyor: Bu araçlar genellikle zorunlu masaüstü uygulamaları ve özel bir arka uç ile kapalı çözümlerdir. WebRTC ise temel bir teknolojidir; bunun üzerine kendi "mini-Meet"inizi kurabilir veya zaten kullanan hizmetlerle (Google Meet veya Microsoft Teams gibi) entegre edebilirsiniz.

WebRTC ile Geliştirme: Gerçek Karmaşıklık ve Yaygın Tuzaklar

API'ler kağıt üzerinde basit görünse de, WebRTC'yi sıfırdan uygulamak daha karmaşıktır. Şunlarla uğraşmanız gerekecek:

İlgili makale:

Android için Tor Tarayıcı: Gelişmiş ayarlar ve güvenli kullanım

• Özel tabelalarMesajların, odaların tasarlanması, bağlantıların, yeniden denemelerin ve hataların yönetimi.
• BUZ/ŞOK/DÖNÜŞ YönetimiSunucuları devreye alın, TURN kullanımını (bant genişliğini tüketir) izleyin, zaman aşımı sürelerini ayarlayın.
• Hizmet kalitesi (QoS)Veri hızlarını uyarlamak, istikrarsız ağlarla başa çıkmak, kodekler üzerinde anlaşma sağlamak, bağlantının bozulduğunu tespit etmek ve buna göre tepki vermek.
• yükseltilmişBasit P2P'den gruplara, ardından yüzlerce kullanıcıya geçiş yapın, orijinal tasarımı bozmadan SFU'ları veya medya sunucularını devreye alın.
• Gezginlerle UyumlulukDurum iyi olsa da, yine de bazı incelikler bulacaksınız. Kullanın adaptör.js Hâlâ şiddetle tavsiye edilir.

Küçük bir yan projede, Socket.IO ve herkese açık bir STUN ile bir Node sunucusu kurmak, bire bir görüşmeler veya çok küçük gruplar için yeterli olabilir. Ancak fikriniz büyürse ve daha fazlasına ihtiyacınız olursa... büyük kalabalıkİnce kalite kontrolü, kayıtlar, analiz, transkripsiyon veya para kazanma olsun, yakında şunları göz önünde bulundurmanız veya dahil etmeniz gerekecek: kendi medya sunucusuveya uzman bir sağlayıcıya geçin.

SDK'ları olan gerçek zamanlı CDN'ler: Agora, Twilio, Mux, ZEGOCLOUD…

Gibi hizmetler Agora, Twilio, Mux, ZEGOCLOUD veya benzer teknolojiler, WebRTC'nin üzerine değer katan bir katman oluşturarak size aylarca sürecek çalışmadan ve sayısız baş ağrısından tasarruf sağlar:

• sana teklif ediyorlar küresel medya ağı Dünyanın dört bir yanına dağıtılmış, düşük gecikme süresi için optimize edilmiş SFU'lar ile.
• Soyut STUN/TURN, sinyal verme, yeniden denemelerYeniden bağlantılar ve karmaşık ağ yönetimi.
• Bunlar arasında iyi bakımı yapılmış SDK'lar da bulunmaktadır. web, iOS, Android, React Native ve diğer çerçeveler.
• Aşağıdakiler gibi ek hizmetler sunuyorlar: RTMP/HLS'ye kayıt, yayınModerasyon, gerçek zamanlı istatistikler, kalite kontrolleri, kullanıcı rolleri (sunucu, izleyici, konuşmacı) vb.

Tahmin edebileceğiniz gibi, asıl sorun maliyet: az da olsa paranız varsa... birçok dakikalık video Veya, eş zamanlı kullanıcı sayısının önemli ölçüde artması durumunda faturalar fırlayabilir. Dahası, onların platformuna ve fiyat veya API değişikliklerine bağımlı hale gelirsiniz.

Sizin özel durumunuzda, güçlü deneyiminizle birlikte, Gerçek zamanlı JavaScriptGeliştirme sürecini hızlandırmak, ürünü doğrulamak ve oda modeli, roller, akış yaşam döngüsü ve durum yönetimi hakkında bilgi edinmek için öncelikle bir SDK ile başlamak mantıklı bir seçenektir. Daha sonra, proje başarılı olursa ve maliyet bir sorun haline gelirse, çözümün bazı kısımlarını kademeli olarak daha sağlam bir platforma taşıyabilirsiniz. tescilli WebRTC altyapısı Ya da dağıtım katmanını kontrol etmek için Flussonic tipi bir medya sunucusuna güvenebilirsiniz.

WebRTC hata ayıklaması için en iyi uygulamalar ve araçlar

WebRTC'nin karmaşık dünyasında kaybolmamak için, tarayıcılarda ve ekosistemde zaten var olan araçlara güvenmek tavsiye edilir:

• chrome: // webrtc-internals (o hakkında:webrtc (Firefox'ta): Bağlantılar, bit hızları, paket kaybı, aktif kodekler vb. hakkında ayrıntılı istatistikler içeren panel.
• adaptör.js: Tarayıcılar ve sürümler arasındaki farklılıkları yumuşatan, topluluk tarafından sürdürülen bir arayüz katmanı.
• test.webrtc.orgBir makinenin kamera, mikrofon, ağ ve genel uyumluluğunu kontrol etmek.
• Resmi Örnekler webrtc.github.io/samples adresinde: kısıtlamalar, eşler arası bağlantılar, veri kanalları, ekran paylaşımı örnekleri... kalıpları kopyalamak için çok faydalı.

Kodun yapısını, bileşenleri açıkça ayırarak düzenlemek de iyi bir fikirdir. sinyal katmanı (soketler, odalar, mesajlar) katmanının Saf WebRTC (Bağlantı oluşturma, akış yönetimi, olay işleyicileri). Bu, tüm istemci mantığını yeniden yazmadan bir sinyal arka ucunu veya medya sunucusunu değiştirmenize olanak tanır.

İlgili makale:

Android ve Linux: KDE Connect'e En İyi Alternatifler

Yukarıda belirtilenlerin tümü göz önünde bulundurulduğunda, henüz başlangıç ​​aşamasında olan ve çok değer verdiğiniz bir yan proje için... geliştirme zamanı gibi orta vadeli maliyetEn dengeli strateji genellikle, React/React Native'de hızlı bir şekilde yineleme yapmanıza, rolleri, oturumları, akış yaşam döngüsünü ve canlı durumları nasıl ele aldıklarını içselleştirmenize ve paralel olarak WebRTC'yi "temel olarak" (getUserMedia, RTCPeerConnection, RTCDataChannel, Node+Socket.IO ile sinyalleme, STUN/TURN, SFU) daha derinlemesine incelemenize olanak tanıyan WebRTC tabanlı gerçek zamanlı bir SDK ile başlamaktır; böylece tek bir platforma sonsuza dek bağlı kalmaz ve ürün bunu haklı çıkardığında daha özel bir çözüme geçiş yapabilirsiniz.