WebRTC ( Web Gerçek Zamanlı İletişim , kelimenin tam anlamıyla " Web için gerçek zamanlı iletişim "), W3C ve IETF içinde geliştirilen bir programlama arabirimi (API) JavaScript'idir . Aynı zamanda , gerçek zamanlı iletişime izin vermek için farklı web tarayıcılarında erken uygulamaları olan bir yazılım tuvalidir . WebRTC'nin amacı, daha önce gerekli olan tescilli uzantı modüllerinden kendisini kurtararak , IP üzerinden ses , eşler arası dosya paylaşımı gibi uygulamaları birbirine bağlamaktır .
API, medya veya veri akışları alışverişinde bulunmak isteyen iki eşi birbirine bağlamak için merkezi bir sunucunun kullanıldığı ve daha sonra daha fazla aktarma olmadan değiş tokuş edildiği üçgen, ardından eşler arası bir mimariye dayanır . Bu mimari ve kullanılan protokol yığını , çoğunlukla IETF ve W3C tarafından çözülmekte olan diğer teknolojilerle ( NAT'lar veya güvenlik duvarları gibi) ilgili güvenlik ve kullanım sorularını gündeme getirmektedir .
WebRTC teknolojisi oldukça yeni, 2011 yılında W3C / IETF çalışma grupları başladı. Tarayıcılar 2013-2014'ten itibaren entegre etmeye başladı. 2019'da farklı tarayıcılarla entegrasyonu hala eşit değil. Bazı tarayıcılar için Temasys'in Internet Explorer ve Safari gibi tescilli uzantıları var .
Tarayıcılar arasındaki doğrudan değiş tokuşlar, W3C ve IETF tarafından sunulan bir yenilik değildir, ancak önceki araştırma ve uygulamalar standart değildi ( Adobe Flash veya Microsoft ActiveX gibi tescilli eklentilerin kullanılması nedeniyle ) ve genellikle yetersiz belgelenmiştir. Bu protokoller ve eklentiler , bu sistemleri kullanan siteler için birlikte çalışabilirlik ve güncelleme zorluklarının kaynağıydı. Bu uygulamalar video konferansa kadar kullanıma izin verse de (Adobe tarafından Gerçek Zamanlı Medya Akış Protokolü (en) ile sunulanlar gibi ), bunlar tescilli eklentilere dayalıydı ve bu nedenle standartlardan yoksundu.
Zengin internet uygulamaları statik web sayfalarının bir evrim olarak görülüyor, hızla işlevselliğini elde etmek için de hareketlendirmek metin ve tarayıcı tarafından sunulan çizimler ama yeteneği sunulan sürükle ve bırak ya gelen akımlar çift yönlü (ses ve video). Bununla birlikte, zengin uygulamalar en azından kısmen tarayıcı tarafından yürütülürken, bunlar yalnızca tarayıcı ile bir (veya bazen daha fazla) web sunucusu arasındaki iletişimi içerir.
WebRTC, ilk taslakları ortaya çıkan World Wide Web Consortium (W3C) standartları dahilinde Google , Mozilla ve Opera tarafından desteklenen birkaç tarayıcı arasında doğrudan (yani bir web sunucusundan geçmeden) ve gerçek zamanlı iletişime izin veren bir teknolojidir. içindeMayıs 2011. Gelişimini sağlamak için, W3C içinde özel bir liste oluşturuldu.nisan 2011 yanı sıra IETF bünyesinde bir çalışma grubu Mayıs 2011.
Ancak bu girişimler, Microsoft'un rakip bir teklif CU-RTC-Web (içinde) sunmasına karşı çıkıyor .8 Ağustos 2012.
WebRTC'yi oluşturacak standart henüz tamamlanmadığından, yine de büyük değişikliklere uğrayabilir. Bu nedenle, geri bildirim almak için tüm deneyler teşvik edilir. API, WHATWG'nin ( ConnectionPeer API'sini ve Ericsson laboratuvarlarındaki çalışmayı temel alan) ön çalışmasına dayanmaktadır .
Çalışma grubu, spesifikasyonların aşağıdaki yollarla yeterli bir şekilde geliştirilmesini umuyor:
WebRTC API'sinin mimarisi, bir sunucu ve iki eş içeren üçgen bir yapıya dayanmaktadır. Her iki tarayıcı da bir sunucudan yerel bağlamlarına bir JavaScript uygulaması indirir . Sunucu, tarayıcılar arasında doğrudan bir bağlantı kurulana kadar tarayıcılar arasındaki alışverişleri koordine etmek için bir buluşma noktası olarak kullanılır. İndirilen uygulama, yerel Bağlam ile iletişim kurmak için WebRTC API'sini kullanır . Amaç, JavaScript ve HTML5'te WebRTC API aracılığıyla tarayıcıyla etkileşime giren bir istemci uygulamasına sahip olmaktır .
Tarayıcılar arasındaki değişim akışları, örneğin güvenlik duvarlarının, proxy'lerin veya NAT'ın geçişine izin vererek, gerektiğinde sinyali değiştirmekten, çevirmekten veya yönetmekten sorumlu olacak çeşitli sunucularla karşılaşabilir .
WebRTC standardını kullanarak bir bağlantı kurmak için, A ve B tarayıcılarının aynı anda hizmet sayfasına bağlanması ve HTML sayfasının yanı sıra bağlantının HTTPS veya soket tarafından açık tutulmasına izin veren JavaScript kodunu indirmesi gerekir . Tarayıcı A, B ile bağlantı kurmak istediğinde, API , oluşturulduktan sonra medya veya veri akışlarının kurulmasına izin veren bir PeerConnection nesnesini başlatır . Örneğin bir video konferans için, A ve B kullanıcılarının kameralarının ve/veya mikrofonlarının paylaşımını kabul etmeleri de gereklidir.
Bu PeerConnection nesnesi A tarafından oluşturulduktan sonra, tarayıcı sunucuya paylaşılan ortam hakkında bilgi içeren bir paket ve ayrıca bağlantıyı A'ya bağlayan bir parmak izi gönderir. Sunucu bu paketin kodunu çözecek ve bunun B'ye bir iletişim olduğunu belirleyecektir ve bu nedenle B'ye bir sinyal gönderecektir. B, A'nın bağlantı kurma isteği ve talebini kabul edip etmediği konusunda bilgilendirilir. Kabul edilirse, bu kez iki yönlü bağlantı kurmak için B ve A arasında aynı işlem gerçekleşir. Kurulduktan sonra medya veya veri akışları bağlantıya serbestçe eklenebilir.
Örneğin , tarayıcılar arasında eşler arası video akışı bağlamında , kullanıcı bir sunucudan izlemek istediği videonun meta verilerini ve videonun tamamına veya bir kısmına sahip olan mevcut eşlerin bir listesini indirir . Eşler ile bağlantı kurulması, veri akışıyla, bütünlükleri kontrol edildikten sonra yeniden birleştirilen video parçalarının indirilmesine ve ardından videoyu bir HTML5 oynatıcısında başlatmasına izin verir.
webRTC API, libjingle projesinden kaynaklanan parçalardaki STUN , ICE , TURN , DTLS ve hatta SRTP gibi mevcut standartları temel alır .
RTCPeerconnection API , UDP protokolüne (genellikle uzak istemcide çalışan aynı JavaScript uygulamasının başka bir örneği) dayalı olarak uzak bir tarayıcıyla kurulan bağlantıyı temsil eder . Bu eşler arası bağlantıyı kurmak için, bir web sunucusu tarafından kurulan ve örneğin bir XMLHttpRequest nesnesi veya bir WebSocket kullanan bir iletişim kanalına güvenmek gerekir . Mozilla ve Google teknik bir gösteri yaptıŞubat 2013.
Bağlantı kurmak için eşlerden birinin yerel bilgileri (ses veya video için desteklenen protokoller gibi) alması gerekir. Bu adım, API tarafından Oturum Açıklama Protokolü aracılığıyla etkinleştirilir . SDP, bir istek/yanıt yaklaşımını tanımlayan IETF RFC 3264'ü temel alır . Bir oturum oluştururken, bir eş ne yapmak istediğini açıklayan bir istek oluşturur ve diğeri seçilen seçenekleri belirterek yanıt verir. Bununla birlikte, SDP kullanımı, SDP aktarma formatı, yarattığı sorunların bilhassa, JSEP protokolü ile WebRTC standart içinde değiştirilmektedir bilgi damla .
WebRTC çerçevesinde, bu isteklerin ve yanıtların SDP tarafından değişimi, uygulamanın seçimine bırakılan bir mekanizma (tipik olarak bir soket kullanan bir Web sunucusu ) tarafından yapılır.
SDP kullanan bu süreç, hem RTP (medya aktarımı) hem de SCTP (veri aktarımına izin vererek ) için anlaşmaya izin verir.
NAT tarafından adres dönüşümü yapılması durumunda bağlantının sürekliliğini sağlamak ve güvenlik duvarları tarafından (özellikle şirketlerde) bloke edilmemek için PeerConnection nesnesi UDP , STUN ve ICE protokollerini kullanır .
Bu eşler arası bağlantı kurulduğunda, her bir taraf bunu kullanarak MediaStreams veya DataStreams kurabilir.
DATA kanalları API , iki yönlü, eşler arası genel bir veri alışverişi ortamı sağlar. webRTC'nin bu bileşeni, resim veya metin gibi verilerin değiş tokuşuna izin verir. Mozilla'nın ilk gösterisiKasım 2012.
Bu veri kanalları, PeerConnection nesnesi kullanılarak eşler arasında oluşturulur . Medya akışları dışındaki bu veriler , kendisi DTLS içinde kapsüllenmiş SCTP protokolü aracılığıyla değiştirilir . Bu çözüm, veri akışının medya akışlarıyla aynı pakete entegre edilmesini ve dolayısıyla değiş tokuşlar için aynı port numarasının paylaşılmasını sağlar.
SCTP, bir SCTP ilişkisi içinde birkaç veri akışını çift yönlü (her yönde 65536'ya kadar) yerel olarak destekler ve öncelikleri yönetir. Bu şekilde, yüksek öncelikli mesajları büyük, düşük öncelikli nesnelere tercih etmek mümkündür. Her akış, tek yönlü bir mantıksal bağlantıyı temsil eder.
Değiştirilen SCTP paketlerinin gizliliğini ve gerçekliğini sağlamak için her akış DTLS protokolüne dayalıdır.
Bir veri kanalı içinde uygulamalar mesajları düzenli veya gelişigüzel bir şekilde iletebilir. Teslimat sırası, yalnızca aynı veri bağlantısı üzerinden gönderilen sıralı paketlerin iletimi durumunda korunur.
Eşlerden biri bir PeerConnection nesnesi oluşturduktan sonra ilk kez CreateDataChannel() yöntemini çağırdığında bir veri akışı oluşturulur . CreateDataChannel () öğesine yapılan sonraki her çağrı , mevcut SCTP bağlantısı içinde yeni bir veri akışı oluşturacaktır.
DTLS protokolü, SCTP paketlerini kapsülleme rolüne sahip değildir. Medya akışlarıyla çoğullama bağlamında, DTLS protokolü, medya akışlarının yönetimi için kullanılan SRTP protokolü için anahtarların yönetimini ve parametrelerin anlaşmasını kapsar. Bu nedenle, medya akışının veri akışına bağımlılığı vardır.
Bir medya akışı belirli bir ses ya da video veri akışı bir temsilidir. Görüntüleme, kaydetme ve uzak bir eşe gönderme gibi medya akışındaki eylemler için destek sağlar. Bir MediaStream'i yerel veya uzak olabilir. MediaStream API, ses ve video akışlarını yönetir ve uygulamaya kamera , hoparlör ve mikrofona erişim sağlamasını söyler ;
Amacıyla, bir kullanılmak üzere yerel MediaStream'i kullanıcının medya kaynaklarına zorunluluk isteği erişimi yoluyla getUserMedia () fonksiyonu . Uygulama, erişmek istediği ortam türünü (ses veya video) belirtir ve tarayıcı, istenen kaynağa erişime izin verir veya erişimi reddeder. Medya artık kullanılmadığında, uygulama yerel medya akışındaki stop () yöntemiyle kendi erişimini iptal edebilir .
Medya akışları, bir datagram soyutlaması (örneğin UDP) uygulayan herhangi bir taşıma protokolünde kullanılabilen RTP protokolü aracılığıyla taşınır . Gizlilik, mesaj doğrulama ve tekrar koruma, RTP, SRTP'nin güvenli kullanımı ile sağlanır.
SRTP için anahtar yönetimi, DTLS ve dolayısıyla veri akışı tarafından gerçekleştirilir. Bu nedenle, tersinin mümkün olduğu bir veri akışından bağımsız bir medya akışına sahip olmak imkansızdır.
Aynı SRTP bağlantısı üzerinde farklı medya kaynakları kullanabilen veya kullanamayan birkaç medya akışını ilişkilendirmek mümkündür. Bu durumda, her akışın kaynakları açıkça SSRC'ler olarak tanımlanır.
WebRTC API, tek bir aktarım düzeyi bağlantısına dayalı olarak veri veya medya akışlarının çoğullanmasını sağlar . Bu çoğullama, STUN, SRTP ve DTLS protokollerinin modelin aynı seviyesinde bir arada var olduğu ve gelen paketlerin çoğullamalarının çözülmesinin gerekli olduğu anlamına gelir. Bunun için hangi protokol olduğunu belirlemek için UDP içeriğinin niteliğini gösteren ilk sekizli kullanılır. 0 veya 1 değeri bir STUN paketini, 20 ile 63 arasındaki bir değer bir DTLS paketini, 128 ile 191 arasındaki bir değer bir SRTP paketini belirtir.
Bu çoğullamanın ana avantajı, aynı taşıma seviyesi paketini paylaşarak, medya ve veri akışlarının, örneğin bir medya akışını taşıyan bir paketten kaçınarak NAT'ları veya güvenlik duvarlarını daha kolay geçmesidir. bir veri paketi geçerken bloke edilir.
itibaren Mart 2012, IETF WebRTC çalışma taslağı en azından aşağıdaki ses kodeklerini gerektirir:
Video codec bileşenleri henüz tanımlanmadı ancak belirli kriterleri karşılaması gerekiyor. Bir codec bileşeninin kabul edilebilmesi için diğer şeylerin yanı sıra en az 10 kare/saniye (fps) ve en fazla 30 kareyi desteklemesi gerekir ; ayrıca minimum 320x240 piksel çözünürlüğü desteklemesi gerekir; VP8 codec bileşeni ile ilgili olarak, görüntü işlemenin bilineer algoritmasını destekleyebilmeli ve herhangi bir yeniden yapılandırma filtresi uygulamamalıdır.
WebRTC kullanırken birkaç güvenlik sorunu ortaya çıkar:
Bu sorunlardan bazıları İnternet üzerinden tüm iletişimin doğasında varken, diğer sorunlar WebRTC'nin uygulanmasıyla çözülmüştür. Böylece, medya alışverişleri SRTP protokolü ile güvence altına alınır.
WebRTC, bir VPN kullanırken bile gerçek yerel IP adresinizi açığa çıkarmanıza olanak tanır.
UDP protokolünün bağlantısının kesilmesi ve paket alım doğrulama sistemi kullanılmaması ( örneğin TCP protokolünün aksine ), paket kaybı, medya akışlarının eşler arası iletimleri sırasında ortaya çıkabilecek bir sorundur. Ağ sorunları nedeniyle paket kaybını sınırlamak için iki yöntem sunulmuştur:
Bir medya akışı gönderirken, gönderen akışı keser ve bu paketlerle gönderilen bir sağlama toplamını (FEC) hesaplar. Alındıktan sonra, FEC'ler hata olmadığını ve verilerin bir arabellekte saklandığını doğrulamak için yeniden hesaplanır . Eksik paketler varsa tekrar talep edilir.
WebRTC API'nin bir parçası olarak, videonun kalitesini, akışkanlığını ve bağlantının bir ucundan diğer ucuna yanıt süresini dengelemek için zamanlama kontrolleriyle birlikte NACK ve FEC arasında hibrit bir çözüm uygulandı.
Bu nedenle, bir medya aktarımı bağlamında, görüntülerin oluşturulması için kullanılan ara bellek, paketlerin uzunluğuna ve uygulama tarafından hesaplanan optimal işleme akışkanlığına bağlı olarak değişken boyuttadır. Gönderici tarafında, bir akış optimize edici, ağdaki trafiğin kalitesini periyodik olarak hesaplar ve çarpışmaları ve kayıpları mümkün olduğunca önlemek için paketlerin boyutunu dinamik olarak uyarlar.
Ek olarak, FEC'nin hesaplanması işlemin en uzun kısmı olduğundan, akış optimizasyonu frekansın değiştirilmesine izin verir, böylece iletim sırasında karşılaşılan sorunları en iyi şekilde ele alan uyarlanabilir bir FEC / NACK oluşturur.
WebRTC, genellikle API gereksinimleriyle uyumlu olmayan BT güvenlik ilkelerine sahip olduklarından kuruluşlarda kullanımı zor olabilir. Bunun nedeni, WebRTC'nin tarayıcılar arasındaki eşler arası akışlara dayanmasıdır ve bu akışlar, medya akışları söz konusu olduğunda gecikmeye karşı çok hassastır . Ek olarak, paketleri iletmek için kullanılan sunucular, iletişim kuran eşlerden coğrafi olarak uzak olabilir veya paketlerin doğru geçişine izin vermek için çok düşük bir bant genişliğine sahip olabilir.
Bir güvenlik duvarını geçmek için zaten yaklaşımlar var:
Bununla birlikte, şirketler giderek daha fazla SBC'ler , uygulama düzeyinde güvenlik duvarları, sinyal ve medya akış kontrolü (ALG) kullanıyor. Bu SBC'ler, sinyal akışı API tarafından standartlaştırılmadığından ve uygulama serbest bırakıldığından WebRTC için zorluklar yaratır. Ek olarak, SBC'ler istemciden sunucuya aktarımda aracı olarak yerleştirilir, ancak WebRTC tarafından kullanılan DTLS protokolü , şifrelemesi nedeniyle üçüncü bir taraf tarafından gözlemlenmesine izin vermez. Son olarak, SBC'ler veri akışlarının kimliğini doğrulamak için sinyal akışlarını kullanır, ancak WebRTC API'si sinyal akışlarını standartlaştırmaz, bu nedenle tanımlama amacıyla kullanımları mümkün değildir.
SBC'lerin yarattığı zorlukların üstesinden gelmek için çözümlerden biri, şirketlerin gelen akışları SIP oturumlarına dönüştürmesi, bu kapsüllemeyi SBC'den geçmek için kullanması ve ardından akışı uygulamaya geçirmek için dekapsüle etmesi olacaktır. Ancak, bu ortadaki adam saldırısı ilkesi , WebRTC ve API'nin kontrol ve medya akışı şifrelemesinin çeşitli kullanımları nedeniyle zorlaşmaktadır.
NAT üzerinden geçişWebRTC, eşlerden biri bir NAT arkasındaysa kullanılabilir olması için ICE protokolünü kullanır. Bu tür bir zorluğun üstesinden gelmek için iki ana teknik kullanılır.
Göreceli yeniliğine rağmen, webRTC standardı 2011'den beri birçok projenin parçası olarak uygulanmaktadır. Mayıs 2011, Ericsson laboratuvarları API'nin ilk uygulamasını önerdi veMayıs 2012Doubango Telecom, WebRTC kullanarak ilk açık kaynak SIP HTML5 istemcisini sundu. Aynı yılın Eylül ayında, JsSIP adlı SIP protokolünü çalıştırmak için JavaScript'e dayalı bir yazılım tuvali , WebSockets üzerindeki çalışma taslağının başlangıcında bulunan bir ekip olan Versatica tarafından başlatıldı .
İnternetteki çeşitli uygulamalar WebRTC'nin sunduğu araçları kullanır. Örneğin, tawk.com, look.in, Talky.io, vroom.im ve hatta video konferans hizmetleri sunan Bistri.com siteleri için durum böyledir. Aynı şekilde,Kasım 2012, ToxBox, geliştiricilerin doğrudan web siteleri veya IOS (Apple) ve Android uygulamaları içinde video konferans yapmalarına olanak tanıyan OpenTok'u piyasaya sürdü . Bu çözüm, tarayıcıda veya Flash'ta mevcut olduğunda WebRTC'yi temel alır. Aynı şekilde veri alışverişi rtccopy gibi siteler tarafından DataChannels'a güvenilerek sunulmaktadır .
Bu uygulamalara rağmen, çeşitli web oyuncuları teknoloji üzerinde çalışmaya devam ediyor. İçindeŞubat 2013, Mobil Dünya Kongresi sırasında Mozilla , Ericsson ve AT&T ürünleriyle WebRTC'yi sergilediler. Google'ın sohbet hizmeti Google Talk da devam eden çalışmalarla WebRTC'ye geçebilir.
İçinde Ağustos 2012, Microsoft (CU-RTC-WEB adı verilen alternatif bir öneri sundular Web üzerinden Özelleştirilebilir Ubiquitous Gerçek Zamanlı İletişimi , W3C WebRTC grubuna) bildirildiğine ile birlikte 2010 yılında girmiştir olduğu bir teknoloji Skype (Microsoft 2011 yılında aldım).
Google'ın önerisi, patent telif ücretine tabi olmayan VP8 codec bileşeni üzerine kuruluyken , Microsoft'un teklifi, yaygın olarak kullanılan ISO / IEC H.264 standardını kullanır , ancak birçok patent telif ücretine tabidir.
2016'da Opera ve Google Chrome yalnızca VP8, firefox ve Bowser H.264 ve VP8'i ve Edge kısmen H.264'ü destekler.
Bu Yazı İçin Teşekkür Ederiz
Windows, Linux ve Mac için mevcut ” , 01net'te ( 31 Ekim 2019'da erişildi )