WebRTC'ye dayalı eşler arası görüntülü sohbet. WebRTC Webrtc kurulumuna dayalı P2P görüntülü sohbet

Avrupalı ​​İnternet kullanıcıları iki kısma ayrılıyor: Allenbach'taki (Almanya) Kamuoyu Analizi Enstitüsü tarafından yapılan bir araştırmaya göre, Skype, sohbet ve anlık mesajlaşma sistemleri internetin ayrılmaz bir parçası haline geldi. Gündelik Yaşam 16,5 milyon yetişkin ve çocuktan 9 milyonu ara sıra bu hizmetleri kullanıyor, 28 milyonu ise bunlara dokunmuyor.

Firefox artık entegre olduğundan bu durum değişebilir gerçek zamanlı iletişim teknolojisi (WebRTC) ve müşterinin kendisi. Sesli ve görüntülü sohbet başlatmak artık web sitesi açmaktan daha zor değil. Facebook ve Skype gibi hizmetler ise ayrı bir istemci kullanan ve hesap oluşturan çözümlere dayanıyor.

WebRTC yalnızca kullanım kolaylığıyla öne çıkmıyor. Bu yöntem yüklemenize bile izin verir iki tarayıcı arasında doğrudan bağlantı. Bu şekilde, ses ve video verileri, aşırı yüklemenin olabileceği veya yöneticinin gizlilik veya veri koruması konusunda özellikle hassas olmadığı bir sunucudan geçmez. Doğrudan bağlantı sayesinde WebRTC ne kayıt ne de Hesap herhangi bir hizmette.

Bir sohbet başlatmak için yalnızca bağlantıyı takip etmeniz yeterlidir. İletişim gizli kalır, çünkü veri akışı şifrelenmiştir. Google, WebRTC uygulamasının kaynak kodunu yayınladığı 2011 yılında tarayıcı aracılığıyla gerçek zamanlı iletişimde aktif olarak yer almaya başladı.

Bundan kısa bir süre sonra Chrome ve Firefox kendi WebRTC motorlarını aldı. Şu anda mobil versiyonları hem bu teknolojiyle hem de uygulamalar tarafından kullanılan Android 5.0 yüklü WebView 3.6 motoruyla donatılmıştır.

Gerçek zamanlı iletişim için web görüntüleyicide uygun JavaScript arayüzlerinin uygulanması gerekir. GetUserMedia'yı kullanma yazılım ses ve video kaynaklarından, yani web kamerasından ve mikrofondan yakalamayı etkinleştirir. RTCPeerConnection, bağlantının yanı sıra iletişimin kendisinden de sorumludur.

Tarayıcıya entegrasyona paralel olarak Konsorsiyum çalışma grubu Dünya çapında Ağ(W3C), WebRTC standardizasyon sürecini hızlandırdı. 2015 yılında tamamlanması gerekiyor.

WebRTC çok az şeyden memnun

Sunucu yalnızca muhatapları bağladığı için WebRTC hizmetini kullanmak çok fazla kaynak gerektirmez. Bağlantı kurmak da özellikle zor değil. İlk olarak tarayıcı, WebRTC sunucusuna bir çağrı başlatmayı planladığını bildirir. Sunucudan bir HTTPS bağlantısı alır; iletişim şifrelenir. Kullanıcı bu bağlantıyı muhatabına gönderir. Tarayıcı daha sonra kullanıcıdan web kamerasına ve mikrofona erişim izni ister.

Muhatapla doğrudan akış bağlantısı kurmak için tarayıcı, IP adresini ve yapılandırma verilerini WebRTC hizmetinden alır. Diğer kişinin web görüntüleyicisi de aynısını yapar.

Yayın bağlantısının sorunsuz ve kaliteli çalışması için tarayıcıda üç motor çalışır. Bunlardan ikisi ses ve video verilerini optimize edip sıkıştırıyor, üçüncüsü bunların taşınmasından sorumlu. Verileri şu şekilde gönderir: SRTP protokolü(Güvenli Gerçek Zamanlı Aktarım Protokolü), şifrelenmiş gerçek zamanlı akışa olanak tanır.

Doğrudan bağlantı kurulamazsa WebRTC başka bir yol arar. Örneğin, bu şu durumlarda olur: ağ ayarları STUN sunucusunun IP adresini raporlamasını önleyin. WebRTC standardı, bu durumda görüşmenin, TURN sunucusunun ara aktivasyonuyla (NAT Çevresindeki Röleleri Kullanarak Geçiş) gerçekleşeceğini öngörmektedir. Böylece netscan.co web sitesinde WebRTC'nin bilgisayarınızda ve Ağ erişiminizde uygulanıp uygulanmadığını kontrol edebilirsiniz.

Bağlantı nasıl yapılır?

Öncelikle konuşmayı kaydetmeniz gerekir (1). WebRTC hizmeti muhataplara gönderilmesi gereken bir bağlantı sağlar. Tarayıcı, STUN sunucusunu kullanarak kendi IP adresini (2) bulur, bunu hizmete gönderir ve doğrudan bağlantı kurmak için ortağın IP'sini alır (3). STUN başarısız olursa, görüşme TURN sunucusu (4) kullanılarak yeniden yönlendirilir.

Tarayıcıda WebRTC teknolojisini kullanan iletişim, JavaScript kodu kullanılarak başlatılır. Bundan sonra iletişimden üç motor sorumludur: ses ve video motorları web kamerasından ve mikrofondan multimedya verilerini toplar ve taşıma motoru bilgileri birleştirir ve SRTP'yi (Güvenli Gerçek Zamanlı Protokol) kullanarak akışı şifrelenmiş biçimde gönderir.

WebRTC ile hangi tarayıcılar çalışır?

Chrome ve Firefox'ta talky.io gibi hizmetleri kullanan bir WebRTC motoru vardır. Mozilla'nın tarayıcısı doğrudan kendi istemcisiyle çalışabilir.

Google ve Mozilla, gerçek zamanlı iletişim fikrini geliştirmeye devam ediyor: Chrome, birden fazla katılımcının yer aldığı bir WebRTC konferansına ev sahipliği yapabilir ve Firefox'taki yeni Hello istemcisi, telekom devi Telefonica'nın bir yan kuruluşuyla işbirliği içinde geliştirildi. Apple şimdilik kenarda duruyor; henüz Safari'de WebRTC'yi beklememelisiniz. Ancak çok sayıda var alternatif uygulamalar iOS için ve Safari için eklentiler.

Microsoft biraz farklı bir yol izliyor. Rekabetçi bir firmanın sahibi olarak Skype hizmeti bu şirket WebRTC'ye bu kadar kolay teslim olmayacak. Bunun yerine Microsoft, ORTC (Nesne Gerçek Zamanlı İletişim) adı verilen bir teknoloji geliştiriyor. İnternet Explorer.

Sunucuyla iletişim kurmaya yönelik farklı codec bileşenleri ve protokoller gibi WebRTC'den farklılıklar küçüktür ve zaman içinde büyük olasılıkla WebRTC standardına bu farklılıkları içeren bir eklentiye dönüşecektir. Böylece geride her zamanki gibi yalnızca Apple kalıyor.

Fotoğraf:Üretim şirketleri; goodluz/Fotolia.com

Üzerindeki malzemenin çoğu WebRTC kodlamanın uygulama düzeyine odaklanır ve teknolojinin anlaşılmasına katkıda bulunmaz. Daha derine inmeye çalışalım ve bağlantının nasıl oluştuğunu, oturum tanımlayıcısının ve adayların ne olduğunu, ne için gerekli olduklarını öğrenelim. Sersemletme Ve DÖNÜŞ sunucu.

WebRTC

giriiş

WebRTC, video veri aktarımı için iki istemciyi birbirine bağlamanıza olanak tanıyan tarayıcı odaklı bir teknolojidir. Ana özellikler: dahili tarayıcı desteği (üçüncü tarafların uyguladığı teknolojilere gerek yoktur) Adobe Flash ) ve istemcileri ek sunucular kullanmadan bağlama yeteneği - bağlantı Eşler arası(Daha öte, p2p).

Bağlantı kurun p2p- bilgisayarlar her zaman halka açık olmadığından oldukça zor bir görev IP adresler, yani internetteki adresler. Küçük miktardan dolayı IPv4 adresleri (ve güvenlik amacıyla) için bir mekanizma geliştirildi NATörneğin ev kullanımı için özel ağlar oluşturmanıza olanak tanır. Artık birçok ev yönlendiricisi destekliyor NAT ve bu sayede tüm ev cihazlarının İnternet'e erişimi var, ancak İnternet sağlayıcıları genellikle bir tane sağlıyor IP adres. Halk IP Adresler İnternette benzersizdir, ancak özel adresler değildir. Bu nedenle bağlanın p2p- zor.

Bunu daha iyi anlamak için üç durumu düşünün: her iki düğüm de aynı ağdadır (Resim 1), her iki düğüm de farklı ağlardadır (biri özel, diğeri geneldir) (Şekil 2) ve her iki düğüm de aynı özelliklere sahip farklı özel ağlardadır IP adresler (Figür 3).

Şekil 1: Aynı ağdaki her iki düğüm

Şekil 2: Farklı ağlardaki düğümler (biri özel, biri genel)

Şekil 3: Farklı özel ağlardaki ancak sayısal olarak eşit adreslere sahip düğümler

Yukarıdaki şekillerde iki karakterli gösterimdeki ilk harf düğüm tipini belirtmektedir (p = akran, r = yönlendirici). İlk şekilde durum olumlu: ağlarındaki düğümler tamamen ağ tarafından tanımlanıyor IP adreslerdir ve bu nedenle birbirlerine doğrudan bağlanabilirler. İkinci şekilde benzer düğüm numaralarına sahip iki farklı ağımız var. Burası iki yönlendiriciye sahip yönlendiricilerin (yönlendiricilerin) göründüğü yerdir. ağ Arayüzü– ağınızın içinde ve ağınızın dışında. Bu yüzden iki tane var IP adresler. Normal düğümlerin yalnızca kendi ağları içinde iletişim kurabilecekleri tek bir arayüzü vardır. Verileri ağları dışındaki birine aktarırlarsa, yalnızca NAT yönlendiricinin (yönlendiricinin) içindedir ve bu nedenle aşağıda başkaları tarafından görülebilir. IP yönlendirici adresi onlarındır harici IP adres. Böylece düğüm noktasında p1 Orada iç mekan IP = 192.168.0.200 Ve harici IP = 10.50.200.5 ve son adres aynı zamanda ağındaki tüm diğer düğümlerin dışında olacaktır. Düğüm için de benzer bir durum p2. Bu nedenle, yalnızca iç kısımları kullanılırsa bağlantıları imkansızdır. IP adresler. Harici adresleri yani yönlendirici adreslerini kullanabilirsiniz ancak aynı özel ağdaki tüm düğümler aynı harici adrese sahip olduğundan bu oldukça zordur. Bu sorun mekanizma kullanılarak çözüldü NAT

Düğümleri iç adresleri aracılığıyla bağlamaya karar verirsek ne olur? Veriler ağdan ayrılmayacak. Efekti arttırmak için son şekilde gösterilen durumu hayal edebilirsiniz - her iki düğüm de aynı dahili adreslere sahiptir. Bunları iletişim kurmak için kullanırlarsa, her düğüm kendisiyle iletişim kuracaktır.

WebRTC protokolü kullanarak bu tür sorunlarla başarılı bir şekilde başa çıkıyor BUZ ancak bu, ek sunucuların kullanılmasını gerektirir ( Sersemletme, DÖNÜŞ). Aşağıda tüm bunlar hakkında daha fazla bilgi bulacaksınız.

WebRTC'nin iki aşaması

İki düğümü bir protokol aracılığıyla bağlamak için WebRTC(ya da sadece RTC eğer ikisi iletişim kurarsa iPhone‘a) Bağlantı kurmak için bazı ön adımların atılması gerekir. Bu ilk aşamadır; bağlantı kurma. İkinci aşama video veri iletimidir.

Hemen şunu söylemeye değer, ancak teknoloji WebRTC birçok eserinde kullanıyor çeşitli şekillerde iletişim ( TCP Ve UDP) ve aralarında esnek geçişe sahip olan bu teknoloji bağlantı verilerini iletmek için bir protokol yok. Şaşırtıcı değil çünkü iki düğümü birbirine bağlayın p2pçok kolay değil. Bu nedenle biraz sahip olmak gerekir ek olarak hiçbir şekilde ilişkili olmayan bir veri aktarım yöntemi WebRTC. Bir soket aktarımı, protokol olabilir HTTP hatta bir protokol bile olabilir SMTP veya Rus Postası. Bu aktarım mekanizması ilk veri denir sinyal. Çok fazla bilginin aktarılmasına gerek yok. Tüm veriler metin biçiminde iletilir ve iki türe ayrılır - SDP Ve Buz Adayı. İlk tür mantıksal bir bağlantı kurmak için, ikincisi ise fiziksel bir bağlantı kurmak için kullanılır. Bunların hepsine daha sonra değineceğim, ancak şimdilik şunu hatırlamak önemli: WebRTC bize başka bir düğüme iletilmesi gereken bazı bilgiler verecektir. Gerekli tüm bilgileri ilettiğimiz anda düğümler bağlanabilecek ve artık yardımımıza ihtiyaç kalmayacak. Yani uygulamamız gereken sinyalleşme mekanizması: ayrı ayrı, kullanılacak yalnızca bağlandığında ancak video verileri aktarılırken kullanılmayacaktır.

Öyleyse ilk aşamayı, yani bağlantı kurma aşamasını ele alalım. Birkaç noktadan oluşur. Önce bağlantıyı başlatan düğüm için, sonra da bekleyen düğüm için bu aşamaya bakalım.

• Başlatıcı (arayan - arayan):
  1. Video veri aktarımını başlatmayı teklif et (createOffer)
  2. Seninkini alıyorum SDP SDP)
  3. Seninkini alıyorum Buz adayı Buz adayı)
• Görüşme beklemede ( Aranan kişi):
  1. Yerel (sizin) medya akışınızı alma ve aktarım için ayarlama (getUserMediaStream)
  2. Video veri aktarımını başlatmak için teklif alma ve yanıt oluşturma (createAnswer)
  3. Seninkini alıyorum SDP nesneyi bir sinyal mekanizması aracılığıyla iletmek ( SDP)
  4. Seninkini alıyorum Buz adayı nesneler ve bunların bir sinyal mekanizması aracılığıyla iletilmesi ( Buz adayı)
  5. Uzak (yabancı) bir medya akışının alınması ve ekranda görüntülenmesi (onAddStream)

Tek fark ikinci noktadadır.

Adımların görünürdeki karmaşıklığına rağmen aslında üç tane var: kendi medya akışınızı göndermek (madde 1), bağlantı parametrelerini ayarlamak (maddeler 2-4), başka birinin medya akışını almak (madde 5). En zor adım ikinci adımdır çünkü iki bölümden oluşur: fiziksel Ve mantıklı bağlantılar. İlki şunu belirtir yol Paketlerin bir ağ düğümünden diğerine geçmek için bu yol boyunca seyahat etmesi gerekir. İkincisi şunu belirtir video/ses parametreleri– hangi kalitenin kullanılacağı, hangi kodeklerin kullanılacağı.

Zihinsel aşama teklif oluştur veya cevap oluştur iletim aşamalarına bağlanmalıdır SDP Ve Buz adayı nesneler.

Çekirdek Varlıklar

Medya akışları (MediaStream)

Esas olan medya akışıdır, yani video ve ses verilerinin, resim ve sesin akışıdır. Yerel ve uzak olmak üzere iki tür medya akışı vardır. Yerel olan, giriş cihazlarından (kamera, mikrofon) ve uzak olandan ağ üzerinden veri alır. Böylece her düğümün hem yerel hem de uzak iş parçacığı bulunur. İÇİNDE WebRTC iş parçacıkları için bir arayüz var Medya Akışı ve ayrıca bir alt arayüz var Yerel Medya Akışıözellikle yerel iş parçacığı için. İÇİNDE JavaScript yalnızca ilkiyle karşılaşabilirsiniz ve eğer kullanırsanız libjingle o zaman ikincisiyle karşılaşabilirsiniz.

İÇİNDE WebRTC Konunun içinde oldukça kafa karıştırıcı bir hiyerarşi var. Her akış birden fazla medya parçasından oluşabilir ( Medya Takip), bu da birkaç medya kanalından oluşabilir ( Medya Kanalı). Ayrıca birkaç medya akışının kendisi de olabilir.

Her şeye sırayla bakalım. Bunu yapmak için bazı örnekleri aklımızda tutalım. Diyelim ki sadece kendimizin videosunu değil, üzerine bir şeyler yazacağımız kağıt parçasının bulunduğu masamızın videosunu da iletmek istiyoruz. İki videoya (biz + masa) ve bir sese (biz) ihtiyacımız olacak. Bizim ve tablonun farklı konulara bölünmesi gerektiği açıktır, çünkü bu veriler muhtemelen zayıf bir şekilde birbirine bağlıdır. Bu nedenle iki tane olacak Medya Akışı‘a – biri bizim için, biri de masa için. Birincisi hem video hem de ses verilerini içerecek, ikincisi ise yalnızca videoyu içerecektir (Şekil 4).

Şekil 4: İki farklı medya akışı. Biri bize biri masamıza

Bir medya akışının en azından veri içerme özelliğini içermesi gerektiği hemen anlaşılıyor. farklı şekiller- video ve ses. Bu, teknolojide dikkate alınır ve bu nedenle her veri türü, bir medya kanalı aracılığıyla uygulanır. Medya Takip. Medya parçasının özel bir özelliği var türönümüzde ne olduğunu belirler – video veya ses (Şekil 5)

Şekil 5: Medya akışları medya parçalarından oluşur

Programda her şey nasıl olacak? İki medya akışı oluşturacağız. Daha sonra iki video parçası ve bir ses parçası oluşturacağız. Kameralara ve mikrofona erişelim. Her parçaya hangi cihazın kullanılacağını söyleyelim. İlk medya akışına bir video ve ses parçası, ikinci medya akışına ise başka bir kameradan bir video parçası ekleyelim.

Peki bağlantının diğer ucundaki medya akışlarını nasıl ayırt edeceğiz? Bunu yapmak için her medya akışının özelliği vardır etiket– akış etiketi, adı (Şekil 6). Medya parçaları aynı özelliğe sahiptir. Her ne kadar ilk bakışta videonun sesten başka şekillerde ayırt edilebileceği görülüyor.

Şekil 6: Medya akışları ve parçaları etiketlerle tanımlanır

Peki, eğer medya parçaları bir etiket aracılığıyla tanımlanabiliyorsa, örneğimiz için neden bir yerine iki medya akışı kullanmamız gerekiyor? Sonuçta, bir medya akışını iletebilirsiniz ancak içinde farklı parçalar kullanabilirsiniz. Medya akışlarının önemli bir özelliğine ulaştık; onlar senkronize etmek medya izleri. Farklı medya akışları birbiriyle senkronize edilmez ancak her medya akışındaki tüm parçalar senkronize edilir aynı anda oynanır.

Bu nedenle, sözlerimizin, yüz ifadelerimizin ve kağıt parçamızın aynı anda oynatılmasını istiyorsak, tek bir medya akışını kullanmaya değer. Bu o kadar önemli değilse, farklı akışları kullanmak daha karlı olur - resim daha düzgün olacaktır.

İletim sırasında bazı parçaların kapatılması gerekiyorsa bu özelliği kullanabilirsiniz. etkinleştirilmiş medya izleri.

Son olarak stereo ses hakkında düşünmeye değer. Bildiğiniz gibi stereo ses iki farklı sesler. Ayrıca ayrı olarak aktarılmaları gerekir. Bunun için kanallar kullanılıyor Medya Kanalı. Bir medya ses parçasının birçok kanalı olabilir (örneğin, 5+1 sese ihtiyacınız varsa 6). Medya kanallarının içinde de kanallar var elbette. senkronize. Video için genellikle yalnızca bir kanal kullanılır, ancak örneğin reklamların üst üste bindirilmesi için birkaç kanal da kullanılabilir.

Özetlemek: Video ve ses verilerini iletmek için bir medya akışı kullanıyoruz. Her medya akışında veriler senkronize edilir. Senkronizasyona ihtiyacımız yoksa birden fazla medya akışı kullanabiliriz. Her medya akışının içinde video ve ses için olmak üzere iki tür medya parçası bulunur. Genellikle ikiden fazla parça yoktur, ancak birkaç farklı videoyu (muhatap ve masasının) iletmeniz gerekiyorsa daha fazla parça olabilir. Her parça, genellikle yalnızca stereo ses için kullanılan birkaç kanaldan oluşabilir.

En basit görüntülü sohbet durumunda, her biri bir ana kanaldan oluşacak bir video parçası ve bir ses parçası olmak üzere iki parçadan oluşacak bir yerel medya akışımız olacak. Video parçası kameradan, ses parçası mikrofondan ve medya akışı ise her ikisinin de taşıyıcısıdır.

Oturum Tanımlayıcısı (SDP)

Farklı bilgisayarlarda her zaman farklı kameralar, mikrofonlar, video kartları ve diğer ekipmanlar bulunur. Sahip oldukları birçok seçenek var. İki ağ düğümü arasındaki verilerin medya aktarımı için tüm bunların koordine edilmesi gerekir. WebRTC otomatik olarak yapar ve oluşturur özel nesne– oturum tanımlayıcı SDP. Bu nesneyi başka bir düğüme aktardığınızda medya verileri aktarılabilir. Ancak henüz başka bir düğümle bağlantı yok.

Bunun için her türlü sinyal mekanizması kullanılır. SDP soketler aracılığıyla veya şahsen (bunu başka bir düğüme telefonla söyleyin) veya Rus Posta yoluyla iletilebilir. Çok basit; size hazır bir ürün verecekler SDP ve gönderilmesi gerekiyor. Ve diğer taraftan alındıktan sonra - departmana transfer WebRTC. Oturum tanımlayıcı metin olarak saklanır ve uygulamalarınızda değiştirilebilir ancak bu genellikle gerekli değildir. Örnek olarak, masaüstü ↔ telefonu bağlarken bazen istediğiniz ses codec bileşeninin seçimini zorlamanız gerekir.

Genellikle bir bağlantı kurarken bir tür adres belirtmeniz gerekir; örneğin URL'si. Burada bu gerekli değildir, çünkü sinyal mekanizması aracılığıyla verileri hedefine kendiniz göndereceksiniz. Belirtmek için WebRTC yüklemek istediğimiz şey p2p bağlantı oluşturmak için createOffer işlevini çağırmanız gerekir. Bu işlevi çağırıp ona özel bir değer verdikten sonra geri çağırmak‘bir yaratılacak SDP nesne ve aynı yere aktarıldı geri çağırmak. Sizden gereken tek şey bu nesneyi ağ üzerinden başka bir düğüme (muhatap) aktarmaktır. Bundan sonra veri diğer uca sinyalleşme mekanizmasıyla ulaşacak yani bu SDP bir obje. Bu oturum tanımlayıcısı bu düğüme yabancıdır ve bu nedenle yararlı bilgiler taşır. Bu nesnenin alınması bağlantıyı başlatmak için bir sinyaldir. Bu nedenle bunu kabul etmeli ve createAnswer işlevini çağırmalısınız. CreateOffer'ın tam bir benzeridir. Seninkine geri dön geri çağırmak yerel oturum tanımlayıcısını iletecek ve sinyalleşme mekanizması yoluyla geri iletilmesi gerekecektir.

createAnswer işlevini ancak başkasının yanıtını aldıktan sonra arayabileceğinizi belirtmekte fayda var. SDP nesne. Neden? Çünkü yerel SDP createAnswer çağrıldığında oluşturulacak nesnenin uzaktan kumandaya bağlı olması gerekir SDP bir obje. Ancak bu durumda video ayarlarınızı muhatabınızın ayarlarıyla koordine etmek mümkündür. Ayrıca, yerel medya akışını almadan createAnswer ve createOffer'ı çağırmamalısınız; yazacakları hiçbir şey olmayacaktır. SDP bir obje .

Beri WebRTC düzenlemek mümkündür SDP nesne, yerel tanıtıcıyı aldıktan sonra kurulmalıdır. Bunu anlatmak biraz garip görünebilir WebRTC bize kendisinin verdiği şey, ama protokol bu. Bir uzaktan tanıtıcı alındığında, bunun da kurulması gerekir. Bu nedenle, bir düğüme iki tanımlayıcı yüklemeniz gerekir - sizin ve bir başkasının (yani yerel ve uzak).

Bundan sonra el sıkışmalar Düğümler birbirlerinin isteklerini bilir. Örneğin, eğer düğüm 1 codec bileşenlerini destekler A Ve B ve düğüm 2 codec bileşenlerini destekler B Ve C Bu durumda, her düğüm kendisinin ve diğerlerinin tanımlayıcılarını bildiğinden, her iki düğüm de codec bileşenini seçecektir. B(Şekil 7). Bağlantı mantığı artık kurulmuştur ve medya akışları aktarılabilmektedir, ancak başka bir sorun daha vardır; düğümler hâlâ yalnızca bir sinyalleşme mekanizmasıyla birbirine bağlıdır.

Şekil 7: Codec anlaşması

Buz adayı

Teknoloji WebRTC yeni metodolojisiyle kafamızı karıştırmaya çalışıyor. Bağlantı kurarken bağlanmak istediğiniz düğümün adresi belirtilmez. İlk önce yüklendi mantıklı bağlantı değil fiziksel, her zaman tam tersi yapılmasına rağmen. Ancak üçüncü taraf bir sinyalleşme mekanizması kullandığımızı unutmazsak bu durum garip görünmeyecektir.

Yani bağlantı zaten kuruldu (mantıksal bağlantı), ancak ağ düğümlerinin veri iletebileceği bir yol henüz yok. Her şey o kadar basit değil ama basit bir şekilde başlayalım. Düğümlerin aynı özel ağda olmasına izin verin. Zaten bildiğimiz gibi iç yapılarına göre birbirleriyle kolaylıkla bağlantı kurabilirler. IP adreslere (veya eğer kullanılmıyorsa belki başka birine) TCP/IP).

Biraz sonra geri çağırmak'Ve WebRTC bize söyler Buz adayı nesneler. Ayrıca metin biçiminde gelirler ve oturum tanımlayıcıları gibi, yalnızca bir sinyalleşme mekanizması yoluyla gönderilmeleri gerekir. Oturum tanımlayıcı, kamera ve mikrofon düzeyindeki ayarlarımızla ilgili bilgiler içeriyorsa, adaylar da ağdaki konumumuzla ilgili bilgileri içerir. Bunları başka bir düğüme aktardığınızda bize fiziksel olarak bağlanabilecek ve zaten bir oturum tanımlayıcısına sahip olduğundan mantıksal olarak bağlanabilecek ve veriler "akacak". Aday nesnesini, yani kendisinin ağda nerede olduğuna ilişkin bilgileri bize göndermeyi hatırlarsa, o zaman onunla bağlantı kurabileceğiz. Burada klasik istemci-sunucu etkileşiminden bir farklılığa daha değinelim. HTTP sunucusuyla iletişim, istek-yanıt şemasına göre gerçekleşir; istemci, verileri sunucuya gönderir, sunucu da onu işler ve aracılığıyla gönderir. istek paketinde belirtilen adres. İÇİNDE WebRTC bilmem gerek iki adres ve onları her iki tarafa bağlayın.

Oturum tanımlayıcılardan farkı, yalnızca uzak adayların yüklenmesinin gerekmesidir. Burada düzenleme yapmak yasaktır ve herhangi bir fayda sağlamaz. Bazı uygulamalarda WebRTC adayların yalnızca oturum tanımlayıcıları ayarlandıktan sonra yüklenmesi gerekir.

Neden tek bir oturum tanımlayıcısı vardı ama çok sayıda aday olabiliyordu? Çünkü ağdaki konum yalnızca dahili olarak belirlenemez. IP adres, aynı zamanda yönlendiricinin harici adresi ve adreslerin yanı sıra yalnızca bir adres olması da gerekmez DÖNÜŞ sunucular. Paragrafın geri kalanı adayların ayrıntılı bir tartışmasına ve farklı özel ağlardan düğümlerin nasıl bağlanacağına ayrılacaktır.

Yani iki düğüm aynı ağ üzerindedir (Şekil 8). Onları nasıl tanımlayabiliriz? Kullanarak IP adresler. Başka yol yok. Doğru, yine de farklı taşımaları kullanabilirsiniz ( TCP Ve UDP) ve farklı bağlantı noktaları. Bu, aday nesnede yer alan bilgidir - IP, LİMAN, ULAŞIM ve bir tane daha. Örneğin şunu kullanalım UDP ulaşım ve 531 liman.

Şekil 8: İki düğüm aynı ağ üzerindedir

O zaman eğer düğümdeysek p1, O WebRTC bize böyle bir aday nesneyi iletecek - . Bu kesin bir format değil, sadece bir diyagram. Eğer bir düğüm içindeysek p2, o zaman aday – . Bir sinyal mekanizması aracılığıyla p1 bir aday alacak p2(yani düğüm konumu p2 yani onun IP Ve LİMAN). Daha sonra p1 ile bağlantı kurabilir p2 direkt olarak. Daha doğru, p1 adrese veri gönderecek 10.50.150.3:531 ulaşmaları ümidiyle p2. Adresin düğüme ait olması önemli değil p2 ya da bir aracı. Önemli olan verilerin bu adres üzerinden iletilmesi ve ulaşılabilmesidir. p2.

Düğümler aynı ağ üzerinde olduğu sürece her şey basit ve kolaydır; her düğümün yalnızca bir aday nesnesi vardır (her zaman kendine ait olduğu, yani ağdaki konumu anlamına gelir). Ancak düğümler devreye girdiğinde çok daha fazla aday olacak farklı ağlar.

Daha karmaşık bir duruma geçelim. Bir düğüm yönlendiricinin arkasında (daha doğrusu NAT'ın arkasında) yer alacak ve ikinci düğüm bu yönlendiriciyle aynı ağda (örneğin İnternette) bulunacaktır (Şekil 9).

Şekil 9: Bir düğüm NAT'ın arkasında, diğeri değil

Bu vakanın, şimdi ele alacağımız soruna özel bir çözümü var. Ev yönlendiricisi genellikle bir tablo içerir NAT. Bu, yönlendiricinin özel ağındaki düğümlerin örneğin web sitelerine erişmesine izin vermek için tasarlanmış özel bir mekanizmadır.

Web sunucusunun doğrudan internete bağlı olduğunu, yani halka açık bir ağ bağlantısına sahip olduğunu varsayalım. IP* adres. Bu bir düğüm olsun p2. Düğüm p1(web istemcisi) adrese bir istek gönderir 10.50.200.10 . İlk önce veriler yönlendiriciye gider r1 daha doğrusu onun üzerinde iç mekan arayüz 192.168.0.1 . Bundan sonra yönlendirici kaynak adresini hatırlar (adres p1) ve onu özel bir tabloya girer NAT, ardından kaynak adresini sizinkiyle değiştirir ( p1 → r1). Üstelik kendi yöntemimle harici arayüz, yönlendirici verileri doğrudan web sunucusuna gönderir p2. Web sunucusu verileri işler, bir yanıt oluşturur ve geri gönderir. Yönlendiriciye gönderir r1, dönüş adresindeki o olduğu için (yönlendirici adresi kendi adresiyle değiştirdi). Yönlendirici verileri alır ve tabloya bakar NAT ve verileri düğüme iletir p1. Yönlendirici burada aracı görevi görür.

Peki ya iç ağdaki birden fazla düğüm aynı anda dış ağa erişirse? Yönlendirici yanıtı kime geri göndereceğini nasıl anlayacak? Bu sorun kullanılarak çözüldü limanlar. Bir yönlendirici, ana bilgisayar adresini kendi adresiyle değiştirdiğinde, bağlantı noktasının da yerini alır. Eğer iki düğüm İnternet'e erişiyorsa, yönlendirici bunların kaynak bağlantı noktalarını farklı. Daha sonra web sunucusundan gelen paket yönlendiriciye geri geldiğinde yönlendirici paketin kime atandığını porttan anlayacaktır. Aşağıdaki örnek.

Teknolojiye dönelim WebRTC daha doğrusu, onu kullanan kısmına BUZ protokol (dolayısıyla buz adaylar). Düğüm p2 bir adayı var (ağdaki konumu – 10.50.200.10 ) ve düğüm p1 NAT'lı bir yönlendiricinin arkasında bulunan iki aday olacaktır - yerel ( 192.168.0.200 ) ve yönlendirici adayı ( 10.50.200.5 ). İlki kullanışlı değildir ancak yine de oluşturulmuştur, çünkü WebRTC uzak düğüm hakkında henüz hiçbir şey bilmiyor; aynı ağda olabilir veya olmayabilir. İkinci aday işe yarayacak ve zaten bildiğimiz gibi liman önemli bir rol oynayacak (geçiş için) NAT).

Tablo girişi NAT yalnızca veriler dahili ağdan çıktığında oluşturulur. Bu nedenle düğüm p1 Verileri ilk ve ancak bundan sonra düğüm verileri iletmelidir p2 düğüme ulaşabilecek p1.

Pratikte her iki düğüm geride kalacak NAT. Tabloda kayıt oluşturmak için NAT Her yönlendiricide, düğümlerin uzaktaki düğüme bir şeyler göndermesi gerekir, ancak bu sefer ne birincisi ikinciye ulaşabiliyor, ne de tam tersi. Bunun nedeni düğümlerin dışsal durumlarını bilmemeleridir. IP adresler ve dahili adreslere veri göndermek anlamsızdır.

Ancak dış adreslerin bilinmesi durumunda bağlantı kolaylıkla kurulacaktır. İlk düğüm ikinci düğümün yönlendiricisine veri gönderirse, yönlendirici bunu yok sayacaktır çünkü tablosu NATşimdilik boş. Ancak tablodaki ilk düğümün yönlendiricisinde NAT Bir kayda ihtiyacım var. Şimdi ikinci düğüm, ilk düğümün yönlendiricisine veri gönderirse, yönlendirici bunu başarıyla ilk düğüme aktaracaktır. Şimdi masa NAT ikinci yönlendiricinin verilere ihtiyacı var.

Sorun şu ki, dışsallığınızı tanımak için IP adreste bulunan bir düğüme ihtiyacınız var paylaşılan ağ. Bu sorunu çözmek için doğrudan internete bağlı ek sunucular kullanılır. Onların yardımıyla tablodaki değerli girişler de yaratılıyor NAT.

STUN ve TURN sunucuları

Başlatma üzerine WebRTC mevcut olanı belirtmelisiniz Sersemletme Ve DÖNÜŞ daha sonra arayacağımız sunucular BUZ sunucular. Sunucular belirtilmemişse, yalnızca aynı ağdaki düğümler (ona bağlı) NAT). Şunu hemen belirtmekte yarar var 3g-ağlar kullanılmalıdır DÖNÜŞ sunucular.

Sersemletme sunucu Basitçe İnternet üzerindeki bir dönüş adresini, yani gönderenin düğümünün adresini döndüren bir sunucudur. Yönlendiricinin arkasında bulunan düğüm erişim sağlar Sersemletme geçilecek sunucu NAT. Paket elime ulaştı Sersemletme sunucu, kaynak adresini - yönlendirici adresini, yani düğümümüzün harici adresini içerir. Bu adres Sersemletme sunucuya geri gönderir. Böylece düğüm dışsallığını alır. IP ağdan erişilebildiği adres ve bağlantı noktası. Daha öte, WebRTC bu adresin kullanılması ek bir aday oluşturur (harici yönlendirici adresi ve bağlantı noktası). Şimdi tabloda NAT Yönlendiricinin, gerekli bağlantı noktasında yönlendiriciye gönderilen paketlerin düğümümüze geçmesine izin veren bir girişi vardır.

Bu sürece bir örnekle bakalım.

Örnek (STUN sunucu işlemi)

Sersemletme sunucuyu şu şekilde belirteceğiz: s1. Yönlendirici, daha önce olduğu gibi, r1 ve düğüm – aracılığıyla p1. Ayrıca tabloyu takip etmeniz gerekecek NAT– olarak belirtelim r1_nat. Ayrıca, bu tablo genellikle farklı alt ağ düğümlerinden birçok kayıt içerir - bunlar verilmeyecektir.

Yani başlangıçta boş bir masamız var r1_nat.

Tablo 2: Paket Başlığı

Düğüm p1 bu paketi yönlendiriciye gönderir r1(nasıl olursa olsun farklı alt ağlarda kullanılabilirler) farklı teknolojiler). Yönlendiricinin kaynak adresini değiştirmesi gerekiyor Kaynak IP'si pakette belirtilen adres açıkça harici bir alt ağ için uygun olmadığından, böyle bir aralıktaki adresler ayrılmıştır ve İnternette tek bir adres böyle bir adrese sahip değildir. Yönlendirici pakette bir değişiklik yapar ve Yeni giriş senin masanda r1_nat. Bunu yapmak için bir port numarası bulması gerekiyor. Bir alt ağdaki birden fazla düğümün harici ağa erişebildiğinden, tabloda NAT saklanmalı Ek Bilgiler böylece yönlendirici bu birkaç düğümden hangisinin sunucudan dönüş paketi için yönlendirildiğini belirleyebilir. Yönlendiricinin bir bağlantı noktası bulmasına izin verin 888 .

Paket başlığı değiştirildi:

Tablo 4: NAT tablosu yeni bir girişle güncellendi

Burada IP alt ağın adresi ve bağlantı noktası orijinal paketle tamamen aynıdır. Aslında geri gönderme yaparken bunları tamamen geri yüklemenin bir yolunu bulmamız gerekir. IP harici ağın adresi yönlendiricinin adresidir ve bağlantı noktası, yönlendirici tarafından icat edilen bağlantı noktasıyla değiştirildi.

Düğümün bağlanacağı gerçek bağlantı noktası p1 bağlantıyı kabul eder - bu elbette 35777 , ancak sunucu şuraya veri gönderir: hayali liman 888 , yönlendirici tarafından gerçek olana değiştirilecek 35777 .

Böylece yönlendirici, paket başlığındaki kaynak adresini ve bağlantı noktasını değiştirdi ve tabloya bir giriş ekledi. NAT. Artık paket ağ üzerinden sunucuya yani düğüme gönderilir. s1. Girişte, s1 bu pakete sahip:

Kaynak IP'si	Kaynak Bağlantı Noktası	Hedef IP	Hedef LİMANI
10.50.200.5	888	12.62.100.200	6000

Tablo 5: STUN sunucusu alınan paket

Toplam Sersemletme sunucu adresten bir paket aldığını biliyor 10.50.200.5:888 . Artık sunucu bu adresi geri gönderir. Burada durup az önce baktığımız şeye bir kez daha bakmakta fayda var. Yukarıdaki tablolar bir kesittir başlık paket, ondan hiç değil içerik. İçerikler hakkında konuşmadık çünkü o kadar önemli değil - protokolde bir şekilde anlatılıyor Sersemletme. Şimdi başlığın yanı sıra içeriği de ele alacağız. Basit olacak ve yönlendirici adresini içerecektir - 10.50.200.5:888 , onu oradan almamıza rağmen başlık paket. Bu pek sık yapılmaz; protokoller genellikle düğüm adresleriyle ilgili bilgileri umursamaz; yalnızca paketlerin amaçlanan varış noktasına teslim edilmesi önemlidir. Burada iki düğüm arasında yol kuran bir protokole bakıyoruz.

Artık ters yöne giden ikinci bir paketimiz var:

Tablo 7: STUN sunucusu bu içeriğe sahip bir paket gönderir

Daha sonra paket, yönlendiricinin harici arayüzüne ulaşana kadar ağ boyunca dolaşır. r1. Yönlendirici, paketin kendisine yönelik olmadığını anlıyor. Bunu nasıl anlıyor? Bu yalnızca bağlantı noktası tarafından belirlenebilir. Liman 888 bunu kişisel amaçları için kullanmaz, mekanizma için kullanır NAT. Bu nedenle yönlendirici bu tabloya bakar. Sütuna bakar Harici PORT ve eşleşen bir dize arar Hedef LİMANI gelen paketten yani 888 .

Dahili IP	Dahili PORT	Harici IP	Harici PORT
192.168.0.200	35777	10.50.200.5	888

Tablo 8: NAT Tablosu

Şanslıyız ki böyle bir çizgi var. Eğer şanssız olsaydık, paket basitçe atılırdı. Şimdi bu paketi alt ağdaki hangi düğümün göndermesi gerektiğini anlamanız gerekiyor. Acele etmeye gerek yok, bu mekanizmada limanların önemini bir kez daha hatırlayalım. Aynı anda alt ağdaki iki düğüm, dış ağa istek gönderebilir. Daha sonra, yönlendirici ilk düğüm için bir bağlantı noktası bulursa 888 sonra ikinci olarak bir liman bulurdu 889 . Bunun gerçekleştiğini varsayalım, yani tablo r1_natöyle görünüyor:

Tablo 10: Yönlendirici, alıcı adresinin yerini alır

Kaynak IP'si	Kaynak Bağlantı Noktası	Hedef IP	Hedef LİMANI
12.62.100.200	6000	192.168.0.200	35777

Tablo 11: Yönlendirici alıcı adresini değiştirdi

Paket düğüme başarıyla ulaştı p1 ve paketin içeriğine bakarak düğüm, dış paketini öğrenir. IP adres, yani yönlendiricinin harici ağdaki adresi. Ayrıca yönlendiricinin geçtiği bağlantı noktasını da biliyor NAT.

Sıradaki ne? Bütün bunların ne faydası var? Fayda, tablodaki bir giriştir r1_nat. Şimdi herhangi biri yönlendiriciye gönderirse r1 portlu paket 888 , daha sonra yönlendirici bu paketi düğüme iletecektir. p1. Böylece gizli düğüme küçük ve dar bir geçit oluşturuldu p1.

Yukarıdaki örnekten nasıl çalıştığına dair bir fikir edinebilirsiniz NAT ve öz Sersemletme sunucu. Genel olarak mekanizma BUZ Ve Sersemletme/dönüş sunucular tam olarak sınırlamaların üstesinden gelmeyi amaçlamaktadır NAT.

Düğüm ile sunucu arasında bir değil birkaç yönlendirici olabilir. Bu durumda düğüm, sunucuyla aynı ağa ilk erişen yönlendiricinin adresini alacaktır. Başka bir deyişle, bağlı olduğumuz yönlendiricinin adresini alıyoruz. Sersemletme sunucu. İçin p2p Her yönlendiricinin ihtiyacımız olan satırı tabloya ekleyeceği gerçeğini unutmazsak, iletişim tam olarak ihtiyacımız olan şeydir. NAT. Bu nedenle dönüş yolu yine sorunsuz olacak.

DÖNÜŞ sunucu geliştirildi Sersemletme sunucu. Buradan hemen öğrenilmelidir ki herhangi bir DÖNÜŞ sunucu çalışabilir ve nasıl Sersemletme sunucu. Ancak avantajları da var. Eğer p2p iletişim imkansız (örneğin 3g ağlar), ardından sunucu tekrarlayıcı moduna geçer ( röle), yani aracı görevi görmektedir. Tabii ki hiçbir şey hakkında p2p o zaman sorun yok ama mekanizmanın çerçevesi dışında BUZ Düğümler doğrudan iletişim kurduklarını düşünüyor.

Hangi durumlarda gereklidir DÖNÜŞ sunucu? Neden yeterli değil Sersemletme sunucular? Gerçek şu ki, birkaç çeşit var NAT. Eşit olarak yer değiştiriyorlar IP adres ve bağlantı noktası, ancak bazılarında yerleşik "sahtecilik"e karşı ek koruma bulunur. Örneğin, simetrik masa NAT 2 parametre daha kaydedildi - IP ve uzak düğümün bağlantı noktası. Harici ağdan bir paket geçiyor NAT yalnızca kaynak adresi ve bağlantı noktası tabloda kayıtlı olanlarla eşleşiyorsa dahili ağa bağlanır. Bu nedenle odak Sersemletme sunucu başarısız oluyor - tablo NAT adresi ve bağlantı noktasını saklar Sersemletme sunucu ve yönlendirici bir paket aldığında WebRTC muhatap, "sahte" olduğu için onu atıyor. O nereden gelmedi Sersemletme sunucu.

Böylece DÖNÜŞ her iki muhatap da bulunduğunda bir sunucuya ihtiyaç vardır simetrik NAT(her biri kendi başına).

Kısa özet

İşte varlıklarla ilgili bazı ifadeler WebRTC her zaman akılda tutulması gereken bir şey. Bunlar yukarıda ayrıntılı olarak açıklanmıştır. İfadelerden herhangi biri size tam olarak açık gelmiyorsa ilgili paragrafları tekrar okuyun.

• Medya akışı
  • Video ve ses verileri medya akışları halinde paketlenir
  • Medya akışları, oluşan medya parçalarını senkronize eder
  • Farklı medya akışları birbiriyle senkronize edilmez
  • Medya akışları yerel ve uzak olabilir, yerel olan genellikle bir kamera ve mikrofona bağlanır, uzak olanlar ağdan şifrelenmiş biçimde veri alır
  • Video ve ses için olmak üzere iki tür medya parçası vardır.
  • Medya parçaları açma/kapama özelliğine sahiptir
  • Medya parçaları medya kanallarından oluşur
  • Medya parçaları, onları oluşturan medya kanallarını senkronize eder
  • Medya akışları ve medya parçaları, ayırt edilebilecekleri etiketlere sahiptir
• Oturum tanıtıcısı
  • Oturum tanımlayıcısı iki ağ düğümünü mantıksal olarak bağlamak için kullanılır
  • Oturum tanımlayıcısı aşağıdakilerle ilgili bilgileri saklar: mevcut yollar video ve ses verilerini kodlama
  • WebRTC harici bir sinyalleşme mekanizması kullanır - oturum tanımlayıcılarını iletme görevi ( SDP) başvuruya düşüyor
  • Mantıksal bağlantı mekanizması iki aşamadan oluşur - cümleler ( teklif) ve cevap ( cevap)
  • Teklif durumunda yerel medya akışı kullanılmadan oturum tanımlayıcısının oluşturulması mümkün değildir ( teklif) ve yanıt durumunda uzak oturum tanıtıcısı kullanılmadan mümkün değildir ( cevap)
  • Ortaya çıkan tanımlayıcı uygulamaya verilmelidir. WebRTC ve bu tanımlayıcının aynı uygulamadan uzaktan mı yoksa yerel olarak mı elde edildiği önemli değildir WebRTC
  • Oturum tanımlayıcısını biraz düzenlemek mümkündür
• Adaylar
  • Aday ( Buz adayı) ağdaki düğümün adresidir
  • Düğüm adresi size ait olabileceği gibi bir yönlendiricinin adresi de olabilir. DÖNÜŞ sunucular
  • Her zaman birçok aday vardır
  • Aday şunlardan oluşur: IP adres, liman ve ulaşım türü ( TCP veya UDP)
  • Adaylar bir ağdaki iki düğüm arasında fiziksel bir bağlantı kurmak için kullanılır
  • Adayların ayrıca bir sinyalizasyon mekanizması aracılığıyla gönderilmesi gerekmektedir.
  • Adayların ayrıca uygulamalara aktarılması gerekiyor WebRTC ancak yalnızca uzak
  • Bazı uygulamalarda WebRTC adaylar yalnızca oturum tanımlayıcı ayarlandıktan sonra iletilebilir
• STUN/DÖNÜŞ/BUZ/NAT
  • NAT– harici ağa erişim sağlama mekanizması
  • Ev yönlendiricileri özel bir tabloyu destekler NAT
  • Yönlendirici, paketlerdeki adresleri değiştirir - paket harici bir ağa gidiyorsa kaynak adresi kendisininkiyle ve paket harici bir ağdan geldiyse hedef adresi dahili ağdaki ana bilgisayar adresiyle değiştirir.
  • Harici ağa çok kanallı erişim sağlamak için NAT bağlantı noktalarını kullanır
  • BUZ– baypas mekanizması NAT
  • Sersemletme Ve DÖNÜŞ sunucular – bypass için yardımcı sunucular NAT
  • Sersemletme sunucu tabloda gerekli kayıtları oluşturmanıza olanak sağlar NAT ve ayrıca düğümün harici adresini döndürür
  • DÖNÜŞ sunucu genelleştirir Sersemletme mekanizmayı çalıştırır ve her zaman çalışmasını sağlar
  • En kötü durumlarda DÖNÜŞ sunucu aracı olarak kullanılır ( röle), yani p2p istemci-sunucu-istemci iletişimine dönüşür.

WebRTC (Web Gerçek Zamanlı İletişim), eklentiler veya diğer uzantılar yüklenmeden ses verilerinin, video verilerinin ve içeriğin gerçek zamanlı olarak tarayıcıdan ve tarayıcıya aktarımını tanımlayan bir standarttır. Standart, tarayıcınızı bir video konferans terminaline dönüştürmenize olanak tanır; iletişim kurmaya başlamak için yalnızca bir web sayfası açmanız yeterlidir.

WebRTC nedir?

Bu yazımızda WebRTC teknolojisi hakkında bilmeniz gereken her şeye bakacağız. düzenli kullanıcı. Projenin avantajlarına ve dezavantajlarına bakalım, bazı sırları açığa çıkaralım, nasıl çalıştığını, WebRTC'nin nerede ve ne için kullanıldığını anlatalım.

WebRTC hakkında bilmeniz gerekenler?

Video iletişim standartlarının ve teknolojilerinin gelişimi

Sergey Yutsaitis, Cisco, Video+Konferans 2016

WebRTC nasıl çalışır?

Müşteri tarafı

• Kullanıcı HTML5 etiketi içeren bir sayfayı açar
• Tarayıcı, kullanıcının web kamerasına ve mikrofonuna erişim ister.
• Kullanıcı sayfasındaki JavaScript kodu, NAT ve Güvenlik Duvarını atlamak için bağlantı parametrelerini (WebRTC sunucusunun veya diğer WebRTC istemcilerinin IP adresleri ve bağlantı noktaları) kontrol eder.
• Sunucuda karıştırılan konferanstan muhatap veya akış hakkında bilgi alırken, tarayıcı kullanılan ses ve video codec bileşenlerini müzakere etmeye başlar.
• Kodlama işlemi başlar ve WebRTC istemcileri arasında (bizim durumumuzda, tarayıcı ile sunucu arasında) akış verilerinin aktarımı başlar.

WebRTC sunucusu tarafında

İki katılımcı arasında veri alışverişi yapmak için bir video sunucusuna gerek yoktur, ancak birden fazla katılımcıyı bir konferansta birleştirmeniz gerekiyorsa bir sunucu gerekir.

Video sunucusu, çeşitli kaynaklardan medya trafiğini alacak, dönüştürecek ve WebRTC'yi terminal olarak kullanan kullanıcılara gönderecektir.

Ayrıca WebRTC sunucusu, WebRTC eşlerinden medya trafiğini alacak ve bunu, uygulamaları kullanan konferans katılımcılarına iletecektir. masaüstü bilgisayarlar veya mobil cihazlar, varsa.

Standardın avantajları

• Yazılım kurulumu gerekmez.
• Aşağıdakiler sayesinde çok yüksek iletişim kalitesi:
  • Modern video (VP8, H.264) ve ses kodeklerinin (Opus) kullanımı.
  • Akış kalitesinin bağlantı koşullarına göre otomatik olarak ayarlanması.
  • Dahili yankı ve gürültü azaltma sistemi.
  • Katılımcı mikrofonlarının (AGC) hassasiyet seviyesinin otomatik olarak ayarlanması.
• Yüksek düzeyde güvenlik: Tüm bağlantılar TLS ve SRTP protokolleri kullanılarak korunur ve şifrelenir.
• Masaüstü gibi içeriği yakalamak için yerleşik bir mekanizma vardır.
• HTML5 ve JavaScript'e dayalı herhangi bir yönetim arayüzünü uygulama imkanı.
• Arayüzü WebSockets kullanarak herhangi bir arka uç sistemle entegre etme yeteneği.
• Açık olan proje kaynak kodu— ürününüze veya hizmetinize uygulanabilir.
• Gerçek çapraz platform: Aynı WebRTC uygulaması tüm platformlarda eşit derecede iyi çalışır işletim sistemi Tarayıcının WebRTC'yi desteklemesi koşuluyla masaüstü veya mobil. Bu, yazılım geliştirme kaynaklarından önemli ölçüde tasarruf sağlar.

Standardın dezavantajları

• Grup sesli ve görüntülü konferansları düzenlemek için, katılımcılardan gelen görüntü ve sesi karıştıracak bir video konferans sunucusu gereklidir, çünkü Tarayıcı, birden fazla gelen akışın birbiriyle nasıl senkronize edileceğini bilmiyor.
• Tüm WebRTC çözümleri birbiriyle uyumsuzdur çünkü... standart yalnızca video ve ses aktarımına yönelik yöntemleri açıklar; abonelere hitap etme, uygunluk durumlarını takip etme, mesaj ve dosya alışverişi, planlama ve diğer şeyler için yöntemlerin uygulanmasını satıcıya bırakır.
• Yani bir geliştiricinin WebRTC uygulamasından başka bir geliştiricinin WebRTC uygulamasına arama yapamayacaksınız.
• Grup konferanslarını karıştırmak büyük bilgi işlem kaynakları gerektirir; dolayısıyla bu tür video iletişimi, ücretli bir abonelik satın almayı veya her konferansın modern bir işlemcinin 1 fiziksel çekirdeğini gerektirdiği altyapınıza yatırım yapmayı gerektirir.

WebRTC Sırları: Satıcılar Çığır Açan Web Teknolojisinden Nasıl Yararlanıyor?

Tzachi Levent-Levi, Bloggeek.me, Video+Konferans 2015

Video konferans pazarı için WebRTC

Video konferans terminallerinin sayısının arttırılması

WebRTC teknolojisinin video konferans pazarının gelişimi üzerinde güçlü bir etkisi oldu. 2013 yılında WebRTC destekli ilk tarayıcıların piyasaya sürülmesinin ardından, dünya çapındaki potansiyel video konferans terminallerinin sayısı anında 1 milyar cihaz arttı. Aslında her tarayıcı, iletişim kalitesi açısından donanım benzerlerinden daha aşağı olmayan bir video konferans terminali haline geldi.

Özel çözümlerde kullanın

Çeşitli JavaScript kitaplıklarını ve bulut hizmeti API'lerini WebRTC desteğiyle kullanmak, herhangi bir web projesine video iletişim desteği eklemeyi kolaylaştırır. Daha önce, verileri gerçek zamanlı olarak iletmek için geliştiricilerin protokolün işleyişinin ilkelerini incelemesi ve çoğu zaman ek lisans gerektiren ve maliyetleri artıran diğer şirketlerin gelişmelerini kullanması gerekiyordu. WebRTC halihazırda “Siteden arama”, “Çevrimiçi sohbet desteği” vb. hizmetlerde aktif olarak kullanılıyor.

Linux için Skype'ın eski kullanıcıları

2014 yılında Microsoft, BT uzmanları arasında büyük rahatsızlık yaratan Linux için Skype projesine verdiği desteğin sona erdiğini duyurdu. WebRTC teknolojisi işletim sistemine bağlı değildir ancak tarayıcı düzeyinde uygulanır. Linux kullanıcıları Skype'ın tam teşekküllü bir alternatifi olarak WebRTC tabanlı ürün ve hizmetleri görebilecek.

Flash ile Rekabet

WebRTC ve HTML5, zaten en kötü yıllarını yaşayan Flash teknolojisine öldürücü bir darbe oldu. 2017'den bu yana önde gelen tarayıcılar Flash'ı desteklemeyi resmi olarak durdurdu ve teknoloji piyasadan tamamen silindi. Ancak Flash'a hakkını vermeliyiz çünkü web konferansı pazarını yaratan ve teklif eden oydu. Tekniksel kabiliyetler tarayıcılarda canlı iletişim için.

WebRTC video sunumları

Dmitry Odintsov, TrueConf, Video+Konferans Ekim 2017

WebRTC'deki Codec'ler

Ses kodekleri

WebRTC, ses trafiğini sıkıştırmak için Opus ve G.711 codec bileşenlerini kullanır.

G.711- En sık geleneksel telefon sistemlerinde kullanılan, yüksek bit hızına (64 kbps) sahip en eski ses codec'i. Başlıca avantajı, hafif sıkıştırma algoritmalarının kullanılması nedeniyle minimum hesaplama yüküdür. Codec, ses sinyallerini düşük düzeyde sıkıştırır ve kullanıcılar arasındaki iletişim sırasında ek ses gecikmesine neden olmaz.

G.711 çok sayıda cihaz tarafından desteklenmektedir. Bu codec bileşenini kullanan sistemlerin kullanımı, diğer ses codec bileşenlerini (G.723, G.726, G.728 vb.) temel alan sistemlere göre daha kolaydır. Kalite açısından G.711, MOS testinde 4,2 puan aldı (4-5 arası puan en yüksek puandır ve iyi kalite, ISDN'deki ses trafiği aktarımının kalitesine benzer ve hatta daha yüksek).

başyapıt düşük kodlama gecikmesine (2,5 ms'den 60 ms'ye kadar), değişken bit hızlarını ve yüksek sıkıştırma seviyelerini destekleyen, değişken bit hızlarına sahip ağlarda akışlı ses sinyallerinin iletilmesi için ideal olan bir codec bileşenidir. verim. Opus, SILK (ses sıkıştırma, insan konuşmasındaki bozulmanın ortadan kaldırılması) ve CELT (ses veri kodlama) kodeklerinin en iyi özelliklerini birleştiren hibrit bir çözümdür. Codec ücretsiz olarak mevcuttur; onu kullanan geliştiricilerin telif hakkı sahiplerine telif ücreti ödemesine gerek yoktur. Diğer ses codec bileşenleriyle karşılaştırıldığında Opus şüphesiz birçok açıdan kazanır. MP3, Vorbis, AAC LC gibi oldukça popüler düşük bit hızlı codec bileşenlerini gölgede bıraktı. Opus, ses "görüntüsünü" orijinaline AMR-WB ve Speex'ten daha yakın hale getirir. Bu codec bileşeni geleceğin ta kendisidir, bu nedenle WebRTC teknolojisinin yaratıcıları onu desteklenen ses standartlarının zorunlu aralığına dahil etmiştir.

Video codec bileşenleri

WebRTC için bir video codec bileşeni seçme meselesi geliştiricilerin birkaç yılını aldı ve sonunda H.264 ve VP8 kullanmaya karar verdiler. Hemen hemen tüm modern tarayıcılar her iki codec bileşenini de destekler. Video konferans sunucularının WebRTC ile çalışması için yalnızca birini desteklemesi gerekir.

VP8- yüksek video akışı kod çözme hızı ve çerçeve kaybına karşı artan direnç ile karakterize edilen, açık lisansa sahip ücretsiz bir video codec bileşeni. Codec evrenseldir ve donanım platformlarına uygulanması kolaydır; bu nedenle video konferans sistemi geliştiricileri bunu ürünlerinde sıklıkla kullanır.

Ücretli video codec'i H.264 kardeşinden çok daha erken ünlü oldu. Bu, kaydederken video akışının yüksek derecede sıkıştırıldığı bir codec bileşenidir Yüksek kalite video. Bu codec bileşeninin donanım video konferans sistemleri arasında yüksek yaygınlığı, WebRTC standardında kullanıldığını göstermektedir.

Google ve Mozilla, VP8 codec bileşenini aktif olarak tanıtıyor ve Microsoft, Apple ve Cisco, H.264'ü aktif olarak tanıtıyor (geleneksel video konferans sistemleriyle uyumluluğu sağlamak için). Ve burada bulut WebRTC çözümlerinin geliştiricileri için çok büyük bir sorun ortaya çıkıyor, çünkü bir konferanstaki tüm katılımcılar aynı tarayıcıyı kullanıyorsa, o zaman konferansı bir kez tek codec ile karıştırmak yeterlidir ve tarayıcılar farklıysa ve Safari / Edge ise bunlar arasında, konferansın iki kez farklı codec bileşenleriyle kodlanması gerekecektir, bu da maliyeti iki katına çıkaracaktır. sistem gereksinimleri medya sunucusuna ve bunun sonucunda WebRTC hizmetlerine aboneliklerin maliyeti.

WebRTC API'si

WebRTC teknolojisi üç ana API'ye dayanmaktadır:

• (web tarayıcısının kameralardan veya kullanıcının masaüstünden ses ve video sinyallerini almasından sorumludur).
• RTCPeer Bağlantısı(kameradan, mikrofondan ve masaüstünden alınan medya verilerinin "alışverişi" için tarayıcılar arasındaki bağlantıdan sorumludur. Ayrıca, bu API'nin "sorumlulukları" arasında sinyal işleme (yabancı gürültüden temizleme, mikrofon ses düzeyini ayarlama) ve kullanılan ses ve video codec bileşenleri).
• RTCVeri Kanalı(kurulu bir bağlantı üzerinden iki yönlü veri aktarımı sağlar).

Kullanıcının mikrofonuna ve kamerasına erişmeden önce tarayıcı bunun için izin ister. İÇİNDE Google Chrome Erişimi önceden "Ayarlar" bölümünde yapılandırabilirsiniz; Opera ve Firefox'ta cihazlar, erişim elde edilirken doğrudan açılır listeden seçilir. İzin isteği, HTTP protokolü kullanıldığında her zaman ve HTTPS kullanıldığında yalnızca bir kez görünecektir:

RTCPeer Bağlantısı. WebRTC konferansına katılan her tarayıcının şunlara erişimi olmalıdır: bu nesne. RTCPeerConnection kullanımı sayesinde, bir tarayıcıdan diğerine medya verileri NAT üzerinden bile geçebilir ve güvenlik duvarları. Medya akışlarını başarılı bir şekilde iletmek için katılımcıların web soketleri gibi bir aktarım kullanarak aşağıdaki verileri alışverişinde bulunmaları gerekir:

• başlatan katılımcı ikinci katılımcıya bir Teklif-SDP (ileteceği medya akışının özelliklerini içeren veri yapısı) gönderir;
• ikinci katılımcı bir "yanıt" - Cevap-SDP oluşturur ve bunu başlatıcıya gönderir;
• daha sonra eğer tespit edilirse (katılımcılar NAT veya güvenlik duvarı arkasındaysa) katılımcılar arasında ICE aday değişimi düzenlenir.

Bu alışverişin başarıyla tamamlanmasının ardından katılımcılar arasında medya akışlarının (ses ve video) doğrudan aktarımı organize edilir.

RTCVeri Kanalı. Veri Kanalı protokolü desteği tarayıcılarda nispeten yakın zamanda ortaya çıktı, bu nedenle bu API yalnızca tarayıcılarda WebRTC kullanılması durumunda dikkate alınabilir. Mozilla Firefox 22+ ve Google Chrome 26+. Onun yardımıyla katılımcılar alışveriş yapabilir Metin mesajları tarayıcıda.

WebRTC aracılığıyla bağlantı

Desteklenen masaüstü tarayıcılar

• Google Chrome (17+) ve Chromium motorunu temel alan tüm tarayıcılar;
• Mozilla FireFox (18+);
• Opera (12+);
• Safari (11+);

Android için desteklenen mobil tarayıcılar

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobil (12+);
• Safari (11+).

WebRTC, Microsoft ve Internet Explorer

Microsoft, Internet Explorer ve yeni Edge tarayıcısındaki WebRTC desteği konusunda çok uzun bir süre sessiz kaldı. Redmond'lu adamlar kontrol etmedikleri teknolojileri kullanıcıların eline vermekten pek hoşlanmazlar, bu onların politikasıdır. Ama yavaş yavaş mesele çıkmaz bir noktadan çıktı çünkü Artık WebRTC'yi göz ardı etmek mümkün değildi ve WebRTC standardının bir türevi olan ORTC projesi duyuruldu.

Geliştiricilere göre ORTC, WebRTC standardının JavaScript ve HTML5'e dayalı geliştirilmiş bir API kümesine sahip bir uzantısıdır; bu, sıradan dile çevrildiğinde her şeyin aynı olacağı, standardı Google'ın değil yalnızca Microsoft'un kontrol edeceği anlamına gelir. ve gelişimi. Codec seti, H.264 desteği ve telefon ve donanım video konferans sistemlerinde kullanılan G.7ХХ serisinin bazı ses codec bileşenleri ile genişletildi. RDP (içerik aktarımı için) ve mesajlaşma için yerleşik destek bulunabilir. Bu arada, Internet Explorer kullanıcılarının şansı yaver gitti; ORTC desteği yalnızca Edge'de mevcut olacak. Ve elbette, böyle bir protokol ve codec kümesi Skype Kurumsal ile kolayca arayüz oluşturulabilir ve bu da WebRTC için daha da fazla iş uygulamasının önünü açar.

Bu makalenin amacı, eşler arası görüntülü sohbetin (p2p görüntülü sohbet) demo örneğini kullanarak yapısını ve çalışma prensibini öğrenmektir. Bu amaçla çok kullanıcılı eşler arası görüntülü sohbet demosu webrtc.io-demo'yu kullanacağız. Bağlantıdan indirilebilir: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

GitHub'un Web projelerinin işbirliğine dayalı olarak geliştirilmesine yönelik bir site veya web hizmeti olduğu unutulmamalıdır. Geliştiriciler bunun üzerinde geliştirmelerinin kodlarını yayınlayabilir, tartışabilir ve birbirleriyle iletişim kurabilirler. Ayrıca bazı büyük BT şirketleri resmi depolarını bu sitede yayınlamaktadır. Hizmet açık kaynaklı projeler için ücretsizdir. GitHub açık, ücretsiz kaynak kodu kitaplıkları için bir depodur.

Bu nedenle, GitHub'dan indirilen eşler arası görüntülü sohbetin demo örneğini C sürücüsüne yerleştireceğiz. kişisel bilgisayar"webrtc_demo" uygulamamız için oluşturulan dizinde.

Pirinç. 1

Yapıdan da anlaşılacağı gibi (Şekil 1), eşler arası görüntülü sohbet, JavaScript programlama dilinde uygulanan istemci script.js ve sunucu server.js komut dosyalarından oluşur. Komut Dosyası (kütüphane) webrtc.io.js (İSTEMCİ) - eşler arası bir şema kullanarak tarayıcılar arasında gerçek zamanlı iletişimin organizasyonunu sağlar: "istemci-istemci" ve webrtc.io.js (İSTEMCİ) ve webrtc. io.js (SERVER), WebSocket protokolünü kullanarak, istemci-sunucu mimarisini kullanarak tarayıcı ile web sunucusu arasında çift yönlü iletişim sağlar.

webrtc.io.js (SERVER) betiği webrtc.io kitaplığında bulunur ve node_modules\webrtc.io\lib dizininde bulunur. Görüntülü sohbet arayüzü index.html, HTML5 ve CSS3'te uygulanmıştır. webrtc_demo uygulama dosyalarının içeriği, html editörlerinden biri, örneğin "Notepad++" kullanılarak görüntülenebilir.

Görüntülü sohbetin çalışma prensibini kontrol edeceğiz. dosya sistemi PC. Sunucuyu (server.js) bir bilgisayarda çalıştırmak için node.js çalışma zamanı ortamını yüklemeniz gerekir. Node.js, JavaScript kodunu tarayıcının dışında çalıştırmanıza olanak tanır. Node.js'yi şu bağlantıdan indirebilirsiniz: http://nodejs.org/ (07/15/13 itibarıyla sürüm v0.10.13). Node.org web sitesinin ana sayfasında indirme düğmesine tıklayın ve http://nodejs.org/download/ adresine gidin. Windows kullanıcıları için önce win.installer'ı (.msi) indirin, ardından bilgisayarda win.installer'ı (.msi) çalıştırın ve Program Dosyaları dizinine nodejs ve "npm paket yöneticisini" yükleyin.

Pirinç. 2

Böylece node.js, JavaScript kodunu geliştirmek ve çalıştırmak için bir ortamın yanı sıra yönetici veya npm paket yöneticisi kullanılarak kurulabilen bir dizi dahili modülden oluşur.

Modülleri kurmak için yapmanız gerekenler Komut satırı Uygulama dizininden (örneğin, "webrtc_demo") şu komutu çalıştırın: npm kurulum modülü_adı. Modüllerin kurulum işlemi sırasında npm yöneticisi, kurulumun gerçekleştirildiği dizinde bir node_modules klasörü oluşturur. Çalışma sırasında nodejs, modülleri node_modules dizininden otomatik olarak bağlar.

Bu nedenle, node.js'yi yükledikten sonra komut satırını açın ve npm paket yöneticisini kullanarak webrtc_demo dizinindeki node_modules klasöründeki express modülünü güncelleyin:

C:\webrtc_demo>npm hızlı kurulum

Express modülü, node.js için bir web çerçevesi veya uygulama geliştirmeye yönelik bir web platformudur. Express'e küresel erişime sahip olmak için onu şu şekilde yükleyebilirsiniz: npm kurulumu -g ekspres.

Ardından webrtc.io modülünü güncelleyin:

C:\webrtc_demo>npm webrtc.io'yu yükleyin

Daha sonra komut satırında sunucuyu başlatıyoruz: server.js:

C:\webrtc_demo>düğüm sunucusu.js

Pirinç. 3

İşte bu, sunucu başarıyla çalışıyor (Şekil 3). Artık bir web tarayıcısı kullanarak, sunucuyla IP adresiyle iletişim kurabilir ve web tarayıcısının istemci komut dosyası kodunu (script.js ve webrtc.io.js komut dosyası kodunu) çıkaracağı index.html web sayfasını yükleyebilirsiniz ve onları infaz et. Eşler arası görüntülü sohbeti çalıştırmak için (iki tarayıcı arasında bağlantı kurmak için), webrtc'yi destekleyen iki tarayıcıdan node.js üzerinde çalışan sinyal sunucusuyla iletişime geçmeniz gerekir.

Sonuç olarak, iletişim uygulamasının istemci kısmının arayüzü (görüntülü sohbet), kameraya ve mikrofona erişim izni talebiyle açılacaktır (Şekil 4).

Pirinç. 4

"İzin Ver" düğmesine tıkladıktan sonra multimedya iletişimi için kamera ve mikrofon bağlanır. Ayrıca görüntülü sohbet arayüzü aracılığıyla metin verileri aracılığıyla da iletişim kurabilirsiniz (Şek. 5).

Pirinç. 5

Bu not alınmalı. Sunucu bir sinyal sunucusudur ve esas olarak kullanıcı tarayıcıları arasında bağlantı kurmak için tasarlanmıştır. Node.js, WebRTC sinyali sağlayan server.js sunucu komut dosyasını çalıştırmak için kullanılır.