WebRTC'yi kullanmaya başlama

Sam Dutton

WebRTC, açık ve kısıtlanmamış bir web için uzun savaşta yeni bir cephedir.

Brendan Eich, JavaScript'in mucidi

Eklenti olmadan gerçek zamanlı iletişim

Telefonunuzun, TV'nizin ve bilgisayarınızın ortak bir platformda iletişim kurabildiği bir dünya hayal edin. Web uygulamanıza görüntülü sohbet ve eşler arası veri paylaşımı eklemenin kolay olduğunu hayal edin. WebRTC'nin vizyonu budur.

Denemek ister misiniz? WebRTC; masaüstü ve mobil cihazlarda Google Chrome, Safari, Firefox ve Opera'da kullanılabilir. appr.tc adresindeki basit görüntülü sohbet uygulamasını kullanarak başlayabilirsiniz:

  1. Tarayıcınızda appr.tc dosyasını açın.
  2. Bir sohbet odasına katılmak ve uygulamanın web kameranızı kullanmasına izin vermek için Katıl'ı tıklayın.
  3. Sayfanın sonunda görüntülenen URL'yi yeni bir sekmede veya daha iyisi, farklı bir bilgisayarda açın.

Hızlı başlangıç

Bu makaleyi okumak için zamanınız yok mu veya yalnızca kod mu istiyorsunuz?

  • WebRTC'ye genel bakış için aşağıdaki Google I/O videosunu izleyin veya bu slaytları görüntüleyin:
  • getUserMedia API'yi kullanmadıysanız HTML5'te ses ve video yakalama ve simpl.info getUserMedia konularına bakın.
  • RTCPeerConnection API hakkında bilgi edinmek için aşağıdaki örneğe ve 'simpl.info RTCPeerConnection' bölümüne bakın.
  • WebRTC'nin sinyal, güvenlik duvarı ve NAT geçişi için sunucuları nasıl kullandığını öğrenmek amacıyla appr.tc adresindeki kod ve konsol günlüklerine bakın.
  • Sabırsızlanıyorsanız WebRTC'yi hemen denemek mi istiyorsunuz? WebRTC JavaScript API'lerini uygulayan 20'den fazla demodan bazılarını deneyebilirsiniz.
  • Makineniz ve WebRTC ile ilgili sorun mu yaşıyorsunuz? WebRTC Sorun Giderici'yi ziyaret edin.

Alternatif olarak, basit bir sinyal sunucusu da dahil olmak üzere eksiksiz bir görüntülü sohbet uygulamasının nasıl oluşturulacağını açıklayan adım adım açıklamalı kılavuz WebRTC codelab'e atlayabilirsiniz.

Çok kısa WebRTC geçmişi

Web'deki son büyük zorluklardan biri, ses ve video aracılığıyla insan iletişimini mümkün kılmaktır: Gerçek zamanlı iletişim, kısaca RTC. RTC, bir web uygulamasında metin girişine metin girmek kadar doğal olmalıdır. Aksi takdirde yenilik yapma ve insanların etkileşim kurması için yeni yollar geliştirme kapasiteniz sınırlıdır.

Geçmişte kurumsal ve karmaşık olan RTC, pahalı ses ve video teknolojilerinin şirket içinde lisanslanmasını veya geliştirilmesini gerektiriyordu. RTC teknolojisinin mevcut içerik, veri ve hizmetlerle entegre edilmesi, özellikle web'de zor ve zaman alan bir süreçti.

Gmail görüntülü sohbet 2008'de popüler hale geldi ve 2011'de Google, Talk'u (Gmail gibi) kullanan Hangouts'u kullanıma sundu. Google, RTC için gereken codec ve yankı giderme teknikleri gibi birçok bileşeni geliştiren şirket olan GIPS'i satın aldı. Google, GIPS tarafından geliştirilen teknolojileri açık kaynaklı hale getirdi ve endüstride fikir birliğine varılmasını sağlamak için İnternet Mühendisliği Görev Gücü (IETF) ve World Wide Web Konsorsiyumu'ndaki (W3C) ilgili standart kuruluşlarıyla işbirliği yaptı. Mayıs 2011'de Ericsson, WebRTC'nin ilk uygulamasını geliştirdi.

WebRTC; gerçek zamanlı, eklentisiz video, ses ve veri iletişimi için açık standartlar uyguladı. İhtiyaç vardı:

  • Birçok web hizmeti RTC'yi kullanıyordu, ancak indirmelere, yerel uygulamalara ve eklentilere ihtiyaç duyuyordu. Skype, Facebook ve Hangouts bunlardan bazılarıdır.
  • Eklentilerin indirilmesi, yüklenmesi ve güncellenmesi karmaşık, hataya açık ve rahatsız edici bir iştir.
  • Eklentilerin dağıtılması, hatalarının giderilmesi, sorun giderme, test edilmesi ve bakımlarının yapılması zordur. Eklentilerin lisanslanması ve karmaşık, pahalı teknolojilerle entegrasyonu da gerekebilir. Kullanıcıları eklenti yüklemeye ikna etmek genellikle zordur.

WebRTC projesinin yol gösterici ilkeleri; API'lerinin açık kaynaklı, ücretsiz, standartlaştırılmış, web tarayıcılarında yerleşik olması ve mevcut teknolojilerden daha verimli olması gerektiğidir.

Şimdi neredeyiz?

WebRTC, Google Meet gibi çeşitli uygulamalarda kullanılır. WebRTC ayrıca WebKitGTK+ ve Qt yerel uygulamalarına entegre edilmiştir.

WebRTC şu üç API'yi uygular: - MediaStream (getUserMedia olarak da bilinir) - RTCPeerConnection - RTCDataChannel

API'ler şu iki spesifikasyonda tanımlanır:

Bu üç API, mobil cihazlarda ve masaüstünde Chrome, Safari, Firefox, Edge ve Opera tarafından desteklenir.

getUserMedia: Demolar ve kod için WebRTC örneklerine bakın veya Chris Wilson'ın web sesi için giriş olarak getUserMedia kullanılan harika örneklerini deneyin.

RTCPeerConnection: Basit bir demo ve tamamen işlevsel bir görüntülü sohbet uygulaması için sırasıyla WebRTC örnekleri benzerler bağlantısı ve appr.tc bölümlerine bakın. Bu uygulama, tarayıcı farklılıklarını ve özellik değişikliklerini soyutlamak için WebRTC topluluğunun yardımıyla Google tarafından yönetilen bir JavaScript dolgusu olan adapter.js'yi kullanır.

RTCDataChannel: Bunun nasıl olduğunu görmek için WebRTC örneklerine bakın ve veri kanalı demolarından birini inceleyin.

WebRTC codelab'i görüntülü sohbet ve dosya paylaşımı için basit bir uygulama oluşturmak amacıyla üç API'nin de nasıl kullanılacağını gösterir.

İlk WebRTC'niz

WebRTC uygulamalarının birkaç şey yapması gerekir:

  • Akışlı ses, video veya diğer verilere ulaşın.
  • IP adresleri ve bağlantı noktaları gibi ağ bilgilerini alın ve NAT ve güvenlik duvarları üzerinden bile bağlantıyı etkinleştirmek için bu bilgileri diğer WebRTC istemcileriyle (eşler olarak bilinir) değiştirebilirsiniz.
  • Hataları bildirmek ve oturumları başlatmak veya kapatmak için sinyal iletişimini koordine edin.
  • Çözünürlük ve codec'ler gibi medya ve istemci özellikleriyle ilgili bilgi alışverişinde bulunun.
  • Ses, video veya veri akışını iletin.

WebRTC, akış verilerini almak ve iletmek için aşağıdaki API'leri uygular:

  • MediaStream, veri akışlarına (ör. kullanıcının kamerası ve mikrofonundan) erişebilir.
  • RTCPeerConnection, şifreleme ve bant genişliği yönetimi özellikleriyle sesli veya görüntülü görüşme yapmaya olanak tanır.
  • RTCDataChannel, genel verilerin eşler arası iletişimini sağlar.

(Ağ ve WebRTC'nin belirli yönleri hakkında ayrıntılı tartışmalar daha sonra ele alınacak.)

MediaStream API (getUserMedia API olarak da bilinir)

MediaStream API'si senkronize edilmiş medya akışlarını temsil eder. Örneğin, kamera ve mikrofon girişinden alınan bir akış video ve ses parçalarını senkronize etmiştir. (MediaStreamTrack ile tamamen farklı olan <track> öğesini karıştırmayın.)

Muhtemelen MediaStream API'yi anlamanın en kolay yolu API'yi doğal ortamında incelemektir:

  1. Tarayıcınızda WebRTC örnekleri getUserMedia sayfasına gidin.
  2. Konsolu açın.
  3. Global kapsamda olan stream değişkenini inceleyin.

Her MediaStream, getUserMedia() tarafından oluşturulan MediaStream olmak üzere bir girişe ve bir video öğesine veya RTCPeerConnection'ye iletilebilecek bir çıkışa sahiptir.

getUserMedia() yöntemi, bir MediaStreamConstraints nesne parametresini alır ve MediaStream nesnesine çözümlenen bir Promise döndürür.

Her MediaStream bir label içerir (ör. 'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ'). getAudioTracks() ve getVideoTracks() yöntemleri tarafından bir MediaStreamTrack dizisi döndürülür.

getUserMedia örneğinde, stream.getAudioTracks() boş bir dizi döndürür (ses olmadığı için) ve çalışan bir web kamerasının bağlı olduğu varsayılırsa stream.getVideoTracks() web kamerasından akışı temsil eden bir MediaStreamTrack dizisi döndürür. Her MediaStreamTrack bir tür ('video' veya 'audio'), label ('FaceTime HD Camera (Built-in)' gibi) içerir ve bir veya daha fazla ses ya da video kanalını temsil eder. Bu örnekte, yalnızca bir video kanalı var ve ses yok. Ancak ön kameradan, arka kameradan, mikrofondan akış alan bir sohbet uygulaması ve ekranını paylaşan bir uygulama gibi daha fazla kullanım alanı olduğunu düşünmek kolaydır.

MediaStream, srcObject özelliği ayarlanarak video öğesine eklenebilir. Daha önce bu işlem, src özelliği URL.createObjectURL() ile oluşturulan bir nesne URL'sine ayarlanarak yapılıyordu, ancak bu özellik kullanımdan kaldırılmıştır.

getUserMedia, Web Audio API için giriş düğümü olarak da kullanılabilir:

// Cope with browser differences.
let audioContext;
if (typeof AudioContext === 'function') {
  audioContext = new AudioContext();
} else if (typeof webkitAudioContext === 'function') {
  audioContext = new webkitAudioContext(); // eslint-disable-line new-cap
} else {
  console.log('Sorry! Web Audio not supported.');
}

// Create a filter node.
var filterNode = audioContext.createBiquadFilter();
// See https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section
filterNode.type = 'highpass';
// Cutoff frequency. For highpass, audio is attenuated below this frequency.
filterNode.frequency.value = 10000;

// Create a gain node to change audio volume.
var gainNode = audioContext.createGain();
// Default is 1 (no change). Less than 1 means audio is attenuated
// and vice versa.
gainNode.gain.value = 0.5;

navigator.mediaDevices.getUserMedia({audio: true}, (stream) => {
  // Create an AudioNode from the stream.
  const mediaStreamSource =
    audioContext.createMediaStreamSource(stream);
  mediaStreamSource.connect(filterNode);
  filterNode.connect(gainNode);
  // Connect the gain node to the destination. For example, play the sound.
  gainNode.connect(audioContext.destination);
});

Chromium tabanlı uygulamalar ve uzantılar da getUserMedia içerebilir. Manifest'e audioCapture ve/veya videoCapture izinleri eklendiğinde, iznin yükleme sonrasında yalnızca bir kez istenmesine ve verilmesine olanak tanınır. Bu işlemin ardından kullanıcıdan kamera veya mikrofon erişimi için izin istenmez.

getUserMedia() için yalnızca bir kez izin verilmesi yeterlidir. İlk seferinde tarayıcının bilgi çubuğunda bir İzin ver düğmesi görüntülenir. Chrome, getUserMedia() için HTTP erişimi Güçlü özellik olarak sınıflandırıldığından 2015'in sonunda kullanımdan kaldırılmıştır.

Amaç, yalnızca kamera veya mikrofon için değil, herhangi bir akış veri kaynağı için bir MediaStream özelliğini etkinleştirmektir. Bu şekilde, depolanan verilerden veya sensörler ya da diğer girişler gibi rastgele veri kaynaklarından akış yapılabilir.

getUserMedia(), diğer JavaScript API'leri ve kitaplıklarıyla birlikte gerçekten hayat buluyor:

  • Web Kamerası Oyuncağı, yerel olarak paylaşılabilecek veya kaydedilebilecek tuhaf ve muhteşem efektler eklemek için WebGL'yi kullanan bir fotoğraf kabini uygulamasıdır.
  • FaceKat, headtrackr.js ile oluşturulmuş bir yüz izleme oyunudur.
  • ASCII Kamera, ASCII görüntüler oluşturmak için Canvas API'yi kullanır.
idevelop.ro/ascii-camera tarafından oluşturulan ASCII resmi
gUM ASCII çizimi

Sınırlamalar

getUserMedia() için video çözünürlüğü değerlerini ayarlamak üzere kısıtlamalar kullanılabilir. Bu sayede en boy oranı; bakma modu (ön veya arka kamera), kare hızı, yükseklik ve genişlik ve applyConstraints() yöntemi gibi diğer kısıtlamaların desteklenmesi de mümkün olur.

Örnek için WebRTC örnekleri getUserMedia: çözünürlük seçin konusuna bakın.

İzin verilmeyen bir kısıtlama değeri ayarlamak, örneğin istenen çözünürlük kullanılabilir değilse DOMException veya OverconstrainedError değerini verir. Bunu uygulamalı olarak görmek için bir demo için WebRTC örnekleri getUserMedia: Çözüm seçin bölümüne bakın.

Ekran ve sekme yakalama

Chrome uygulamaları, chrome.tabCapture ve chrome.desktopCapture API'leri aracılığıyla tek bir tarayıcı sekmesinin veya tüm masaüstünün canlı videosunu paylaşmayı da mümkün kılar. (Demo ve daha fazla bilgi için WebRTC ile ekran paylaşımı başlıklı makaleye bakın. Bu makale birkaç yıllık bir tarih olmasına rağmen ilgi çekicidir.)

Deneysel chromeMediaSource kısıtlamasıyla, Chrome'da ekran görüntüsü alma özelliğini MediaStream kaynağı olarak kullanmak da mümkündür. Ekran görüntüsü alma özelliğinin HTTPS gerektirdiğini ve bu yayında açıklandığı gibi, komut satırı işaretiyle etkinleştirildiği için yalnızca geliştirme amacıyla kullanılması gerektiğini unutmayın.

Sinyal: Oturum kontrolü, ağ ve medya bilgileri

WebRTC, akış verilerini tarayıcılar (eşler olarak da bilinir) arasında iletmek için RTCPeerConnection özelliğini kullanır. Bununla birlikte, iletişimi koordine etmek ve kontrol mesajları göndermek (sinyal oluşturma olarak da bilinir) için bir mekanizmaya da ihtiyacı vardır. Sinyal yöntemleri ve protokolleri WebRTC tarafından belirtilmemiştir. Sinyal, RTCPeerConnection API'nin bir parçası değildir.

Bunun yerine WebRTC uygulama geliştiricileri, SIP veya XMPP gibi tercih ettikleri mesajlaşma protokolünü ve uygun çift yönlü (iki yönlü) iletişim kanallarını seçebilir. appr.tc örneğinde, sinyal mekanizması olarak XHR ve Channel API kullanılır. codelab, Node sunucusunda çalışan Socket.io'yu kullanır.

Sinyal, üç tür bilgi alışverişi için kullanılır:

  • Oturum kontrolü mesajları: İletişimi başlatmak veya kapatmak ve hataları bildirmek için.
  • Ağ yapılandırması: dış dünyaya, bilgisayarınızın IP adresi ve bağlantı noktası nedir?
  • Medya özellikleri: Tarayıcınız ve iletişim kurmak istediği tarayıcı hangi codec'leri ve çözünürlükleri kullanabilir?

Eşler arası yayının başlayabilmesi için sinyal yoluyla bilgi alışverişi başarıyla tamamlanmış olmalıdır.

Diyelim ki Aylin Ali ile iletişim kurmak istiyor. W3C WebRTC spesifikasyonundan, sinyal sürecini çalışırken gösteren bir kod örneğini burada bulabilirsiniz. Kod, createSignalingChannel() yönteminde oluşturulan bazı sinyal mekanizmalarının varlığını varsayar. Ayrıca, Chrome ve Opera'da RTCPeerConnection kodunun şu anda ön eke sahip olduğunu unutmayın.

// handles JSON.stringify/parse
const signaling = new SignalingChannel();
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

// Send any ice candidates to the other peer.
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

// Let the "negotiationneeded" event trigger offer generation.
pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    // Send the offer to the other peer.
    signaling.send({desc: pc.localDescription});
  } catch (err) {
    console.error(err);
  }
};

// Once remote track media arrives, show it in remote video element.
pc.ontrack = (event) => {
  // Don't set srcObject again if it is already set.
  if (remoteView.srcObject) return;
  remoteView.srcObject = event.streams[0];
};

// Call start() to initiate.
async function start() {
  try {
    // Get local stream, show it in self-view, and add it to be sent.
    const stream =
      await navigator.mediaDevices.getUserMedia(constraints);
    stream.getTracks().forEach((track) =>
      pc.addTrack(track, stream));
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({desc, candidate}) => {
  try {
    if (desc) {
      // If you get an offer, you need to reply with an answer.
      if (desc.type === 'offer') {
        await pc.setRemoteDescription(desc);
        const stream =
          await navigator.mediaDevices.getUserMedia(constraints);
        stream.getTracks().forEach((track) =>
          pc.addTrack(track, stream));
        await pc.setLocalDescription(await pc.createAnswer());
        signaling.send({desc: pc.localDescription});
      } else if (desc.type === 'answer') {
        await pc.setRemoteDescription(desc);
      } else {
        console.log('Unsupported SDP type.');
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

İlk olarak, Ayşe ve İbrahim ağ bilgilerini alışverişi yapar. (Aday bulma ifadesi, ICE çerçevesini kullanarak ağ arayüzlerini ve bağlantı noktalarını bulma sürecini ifade eder.)

  1. Ayla, onicecandidate işleyicisiyle bir RTCPeerConnection nesnesi oluşturur. Bu nesne, ağ adayları kullanılabilir olduğunda çalıştırılır.
  2. Ayla, Bülent'e serileştirilmiş aday verilerini kullanmakta oldukları sinyal kanalı (ör. WebSocket veya başka bir mekanizma) üzerinden gönderir.
  3. Ali, Ayşe'den bir aday mesajı aldığında adayı uzaktaki benzerin açıklamasına eklemek için addIceCandidate numarasını arar.

WebRTC istemcileri (eşler veya bu örnekte Alice ve Bob olarak da bilinir), çözünürlük ve codec özellikleri gibi yerel ve uzaktan ses ve video medya bilgilerini de belirleyip alıp vermelidir. Medya yapılandırma bilgileri alışverişi için sinyal, Oturum Açıklama Protokolü (SDP) kullanılarak bir teklif ve yanıt alışverişinde bulunarak gerçekleşir:

  1. Ayla, RTCPeerConnection createOffer() yöntemini çalıştırır. Bunun sonucuna RTCSessionDescription (Ayşe'nin yerel oturum açıklaması) geçildi.
  2. Geri çağırmada Ayla, setLocalDescription() kullanarak yerel açıklamayı belirliyor ve bu oturum açıklamasını kendi sinyal kanalı üzerinden Ali'ye gönderiyor. RTCPeerConnection adlı iş ortağının, setLocalDescription() çağrılana kadar adayları toplamaya başlamayacağını unutmayın. Bu, JSEP IETF taslağında kodlanmıştır.
  3. Bob, Ayşe'nin kendisine gönderdiği açıklamayı setRemoteDescription() uygulamasını kullanarak uzaktan açıklama olarak ayarlar.
  4. Bora, RTCPeerConnection createAnswer() yöntemini çalıştırır ve bunu, Ayşe'den aldığı uzak açıklamaya iletir. Böylece, Ayşe'ninkiyle uyumlu bir yerel oturum oluşturulabilir. createAnswer() geri çağırması RTCSessionDescription ile geçti. Barış, bunu yerel açıklama olarak ayarlayıp Aylin'e gönderir.
  5. Ayşe, Ali'nin oturum açıklamasını aldığında, bunu setRemoteDescription ile uzaktan açıklama olarak ayarlıyor.
  6. Ping!

RTCSessionDescription nesneleri, Oturum Açıklama Protokolü'ne (STP) uygun blob'lardır. Seri hâle getirildi. Bir SDP nesnesi şöyle görünür:

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

Ağ ve medya bilgilerinin alınması ve değişimi eş zamanlı olarak gerçekleştirilebilir, ancak eşler arasında ses ve video akışının başlayabilmesi için her iki işlemin de tamamlanmış olması gerekir.

Daha önce açıklanan teklif/yanıt mimarisi JavaScript Oturum Oluşturma Protokolü veya JSEP olarak adlandırılır. (İlk WebRTC uygulaması için Ericsson'un demo videosunda sinyal ve akış sürecini açıklayan mükemmel bir animasyon bulunmaktadır.)

JSEP mimari şeması
JSEP mimarisi

Sinyal süreci başarıyla tamamlandıktan sonra, veriler arayan ve çağrılan arasında doğrudan eşler arası akışla aktarılabilir. Bu da başarısız olursa ara geçiş sunucusu üzerinden (Daha sonra bununla ilgili daha fazla bilgi edinebilirsiniz) veri akışı gerçekleştirilebilir. Akış RTCPeerConnection adlı iş ortağının işidir.

RTCPeerConnection

RTCPeerConnection, eşler arasında veri akışı konusunda kararlı ve verimli iletişim kuran WebRTC bileşenidir.

Aşağıda, RTCPeerConnection rolünün gösterildiği bir WebRTC mimari diyagramı bulunmaktadır. Fark edeceğiniz üzere, yeşil kısımlar karmaşıktır!

WebRTC mimari şeması
WebRTC mimarisi (webrtc.org kaynağından)

JavaScript açısından, bu şemadan anlaşılması gereken en önemli nokta, RTCPeerConnection uygulamasının web geliştiricilerini altında gizlenen sayısız karmaşıklıktan koruduğudur. WebRTC tarafından kullanılan codec'ler ve protokoller, güvenilir olmayan ağlarda bile gerçek zamanlı iletişimi mümkün kılmak için çok fazla iş yapar:

  • Paket kaybı gizleme
  • Yankı giderme
  • Bant genişliği uyarlaması
  • Dinamik ses dalgalanması arabelleğe alma
  • Otomatik kazanç kontrolü
  • Gürültü azaltma ve azaltma
  • Resim temizleme

Önceki W3C kodu, sinyal açısından WebRTC'nin basitleştirilmiş bir örneğini göstermektedir. Aşağıda, çalışan iki WebRTC uygulamasına ilişkin adım adım açıklamalı kılavuzlar verilmiştir. İlki RTCPeerConnection ile ilgili basit bir örnek, ikincisi ise tamamen işlevsel bir görüntülü sohbet istemcisidir.

Sunucular olmadan RTCPeerConnection

Aşağıdaki kod, tek bir web sayfasında yerel ve uzak RTCPeerConnection (ve yerel ve uzak video) özelliğine sahip olan WebRTC örnekleri Eş bağlantısından alınmıştır. Bu, çok yararlı bir durum teşkil etmez (arayan ve arayan kişi aynı sayfadadır). Ancak sayfadaki RTCPeerConnection nesneleri, aracı sinyal mekanizmaları kullanmak zorunda kalmadan doğrudan veri ve mesaj değiş tokuşu yapabildiğinden RTCPeerConnection API'sinin işleyişini biraz daha netleştirir.

Bu örnekte pc1 yerel eşi (arayan) ve pc2 uzak eşi (çağrılan) temsil eder.

Arayan

  1. Yeni bir RTCPeerConnection oluşturun ve akışı getUserMedia() kaynağından ekleyin: ```js // Sunucular isteğe bağlı bir yapılandırma dosyasıdır. (Daha sonra TURN ve STUN tartışmasına göz atın.) pc1 = new RTCPeerConnection(servers); // ... localStream.getTracks().forEvery((track) => { pc1.addTrack(track, localStream); });
  1. Bir teklif oluşturup pc1 için yerel açıklama ve pc2 için uzaktan açıklama olarak ayarlayın. Hem arayan hem de arayan aynı sayfada olduğu için bu işlem, sinyal kullanmadan doğrudan kod içinde yapılabilir: js pc1.setLocalDescription(desc).then(() => { onSetLocalSuccess(pc1); }, onSetSessionDescriptionError ); trace('pc2 setRemoteDescription start'); pc2.setRemoteDescription(desc).then(() => { onSetRemoteSuccess(pc2); }, onSetSessionDescriptionError );

Arayan

  1. pc2 oluşturun ve pc1 kaynağından akış eklendiğinde bunu bir video öğesinde görüntüleyin: js pc2 = new RTCPeerConnection(servers); pc2.ontrack = gotRemoteStream; //... function gotRemoteStream(e){ vid2.srcObject = e.stream; }

RTCPeerConnection API Plus sunucuları

Gerçek dünyada WebRTC, sunuculara ihtiyaç duyar ancak basitlikte aşağıdakiler gerçekleşebilir:

  • Kullanıcılar birbirlerini keşfeder ve adlar gibi gerçek dünyadan bilgiler alışverişinde bulunurlar.
  • WebRTC istemci uygulamaları (eşler) ağ bilgileri alışverişi yapar.
  • Eşler medya hakkında veri alışverişi yapar (ör. video biçimi ve çözünürlüğü).
  • WebRTC istemci uygulamaları NAT ağ geçitlerinden ve güvenlik duvarlarından geçer.

Başka bir deyişle, WebRTC için dört tür sunucu tarafı işlevi gerekir:

  • Kullanıcı keşfi ve iletişim
  • Sinyal
  • NAT/güvenlik duvarı geçişi
  • Eşler arası iletişimin başarısız olması durumunda geçiş sunucuları

NAT geçişi, eşler arası ağ iletişimi, kullanıcı keşfi ve sinyal iletimi için sunucu uygulaması oluşturma gereksinimleri bu makalenin kapsamı dışındadır. STUN protokolü ve TURN uzantısı, RTCPeerConnection adlı cihazın NAT geçişi ve diğer ağ değişimleriyle başa çıkabilmesi için ICE çerçevesi tarafından kullanılır.

ICE, iki görüntülü sohbet istemcisi gibi meslektaşlar arasında bağlantı kurmak için bir çerçevedir. Başlangıçta ICE, eşleri UDP üzerinden mümkün olan en düşük gecikmeyle doğrudan bağlamaya çalışır. Bu süreçte STUN sunucularının tek bir görevi vardır: NAT arkasındaki eşin, genel adresini ve bağlantı noktasını bulmasını sağlamak. (STUN ve TURN hakkında daha fazla bilgi edinmek için WebRTC uygulaması için gerekli arka uç hizmetlerini derleme başlıklı makaleye bakın.)

Bağlantı adaylarını bulma
Bağlantı adaylarını bulma

UDP başarısız olursa ICE, TCP'yi dener. Doğrudan bağlantı, özellikle de kurumsal NAT geçişi ve güvenlik duvarları nedeniyle başarısız olursa ICE, bir ara (geçiş) TURN sunucusu kullanır. Başka bir deyişle, ICE önce eşleri doğrudan bağlamak için UDP ile STUN'u kullanır, bu da başarısız olursa TURN geçiş sunucusuna döner. Aday bulma ifadesi, ağ arayüzlerini ve bağlantı noktalarını bulma işlemini ifade eder.

WebRTC veri yolları
WebRTC veri yolları

WebRTC mühendisi Justin Uberti, 2013 Google I/O WebRTC sunusunda ICE, STUN ve TURN hakkında daha fazla bilgi sağlamaktadır. (Sunum slaytlarında TURN ve STUN sunucusu uygulamalarına örnekler verilmiştir.)

Basit bir görüntülü sohbet istemcisi

appr.tc adresindeki görüntülü sohbet demosu, WebRTC'yi denemek için iyi bir örnektir. STUN sunucusu kullanarak sinyal ve NAT/güvenlik duvarı geçişi içerir. Bu uygulama, uygulamaları özellik değişikliklerinden ve ön ek farklarından yalıtmak için bir dolgu olan adapter.js'yi kullanır.

Kod, günlük kaydında kasıtlı olarak ayrıntılıdır. Etkinliklerin sırasını anlamak için konsolu kontrol edin. Aşağıda, kodun ayrıntılı bir açıklaması yer almaktadır.

Ağ topolojileri

Şu anda uygulandığı şekliyle WebRTC, yalnızca bire bir iletişimi destekler. Ancak daha karmaşık ağ senaryolarında (örneğin, birden fazla eşle doğrudan iletişim kuran birden fazla eşle birlikte veya çok sayıda katılımcıyı işleyebilen ve seçmeli akış yönlendirme yapabilen, ses ve videoyu karıştırabilen ya da kaydeden bir sunucu olan Çok Noktalı Kontrol Birimi (MCU)) kullanarak kullanılabilir.

Çok Noktalı Kontrol Birimi topoloji şeması
Çok Noktalı Kontrol Birimi topolojisi örneği

Mevcut WebRTC uygulamalarının çoğu yalnızca web tarayıcıları arasındaki iletişimi gösterir, ancak ağ geçidi sunucuları, tarayıcıda çalıştırılan bir WebRTC uygulamasının telefonlar (PSTN olarak da bilinir) ve VOIP sistemleriyle etkileşimde bulunmasını sağlayabilir. Mayıs 2012'de Doubango Telecom, WebRTC ve WebSocket ile oluşturulan sipml5 SIP istemcisini açık kaynaklı hale getirdi. Bu istemci, (diğer olası kullanımların yanı sıra) iOS ve Android'de çalışan tarayıcılar ile uygulamalar arasında video görüşmelerine olanak tanıyor. Google I/O'da Tethr ve Tropo, WebRTC aracılığıyla özellikli telefonlar ve bilgisayarlar arasında iletişim kurulmasını sağlamak için OpenBTS hücresi kullanarak evrak çantasında afet iletişimlerine yönelik bir çerçeve sergiledi. Operatör olmadan telefon iletişimi!

Google I/O 2012&#39;de Tethr/Tropo demosu
Tethr/Tropo: Evrak çantasıyla felaket niteliğinde iletişimler

RTCDataChannel API<

WebRTC, ses ve videonun yanı sıra diğer veri türleri için gerçek zamanlı iletişimi destekler.

RTCDataChannel API, düşük gecikme ve yüksek işleme hızıyla rastgele verilerin eşler arası değişimine olanak tanır. Tek sayfalık demolar ve basit bir dosya aktarma uygulamasının nasıl oluşturulacağını öğrenmek için WebRTC örneklerine ve WebRTC codelab'ine bakın.

API'nin birçok olası kullanım alanı vardır. Örneğin:

  • Oyun
  • Uzaktan masaüstü uygulamaları
  • Gerçek zamanlı metin sohbeti
  • Dosya aktarımı
  • Merkezi olmayan ağlar

API, RTCPeerConnection ürününden en iyi şekilde yararlanmanın yanı sıra güçlü ve esnek eşler arası iletişim olanağı sunan çeşitli özelliklere sahiptir:

  • RTCPeerConnection oturum kurulumundan yararlanma
  • Önceliklendirme ile eş zamanlı olarak birden çok kanal
  • Güvenilir ve güvenilir olmayan yayınlama semantiği
  • Yerleşik güvenlik (DTLS) ve tıkanıklık kontrolü
  • Ses veya görüntü ile veya ses olmadan kullanım olanağı

Söz dizimi, send() yöntemi ve message etkinliğiyle WebSocket'e özel olarak benzer:

const localConnection = new RTCPeerConnection(servers);
const remoteConnection = new RTCPeerConnection(servers);
const sendChannel =
  localConnection.createDataChannel('sendDataChannel');

// ...

remoteConnection.ondatachannel = (event) => {
  receiveChannel = event.channel;
  receiveChannel.onmessage = onReceiveMessage;
  receiveChannel.onopen = onReceiveChannelStateChange;
  receiveChannel.onclose = onReceiveChannelStateChange;
};

function onReceiveMessage(event) {
  document.querySelector("textarea#send").value = event.data;
}

document.querySelector("button#send").onclick = () => {
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};

İletişim doğrudan tarayıcılar arasında gerçekleşir. Bu nedenle, güvenlik duvarlarıyla başa çıkmak ve NAT'lerle başa çıkmak için delik açma işlemi uygulandığında geçiş (TURN) sunucusu gerekli olsa bile RTCDataChannel WebSocket'e göre çok daha hızlı olabilir.

RTCDataChannel; Chrome, Safari, Firefox, Opera ve Samsung Internet'te kullanılabilir. Cube Slam oyunu, oyun durumunu bildirmek için API'yi kullanır. Bir arkadaşla veya ayıyla oyna! Yenilikçi Sharefest platformu RTCDataChannel üzerinden dosya paylaşımını etkinleştirdi ve peerCDN, WebRTC'nin eşler arası içerik dağıtımını nasıl etkinleştirebileceğine dair genel bir bakış sundu.

RTCDataChannel hakkında daha fazla bilgi için IETF'nin taslak protokol spesifikasyonlarına göz atın.

Güvenlik

Gerçek zamanlı bir iletişim uygulaması veya eklentisinin güvenliği tehlikeye atabileceği birkaç durum vardır. Örneğin:

  • Şifrelenmemiş medyaya veya verilere, tarayıcılar veya bir tarayıcı ile sunucu arasında müdahale edilmiş olabilir.
  • Bir uygulama, kullanıcının haberi olmadan video veya ses kaydedip dağıtabilir.
  • Kötü amaçlı yazılım veya virüsler, zararsız olduğu görülen bir eklenti veya uygulamanın yanına yüklenmiş olabilir.

WebRTC, bu sorunları önlemek için çeşitli özelliklere sahiptir:

  • WebRTC uygulamaları, DTLS ve SRTP gibi güvenli protokoller kullanır.
  • Sinyal mekanizmaları dahil olmak üzere tüm WebRTC bileşenleri için şifreleme zorunludur.
  • WebRTC bir eklenti değildir. Bileşenleri ayrı bir işlemde değil, tarayıcı korumalı alanında çalışır. Bileşenler ayrı yükleme gerektirmez ve tarayıcı güncellendiğinde güncellenir.
  • Kamera ve mikrofon erişimine açıkça izin verilmelidir. Kamera veya mikrofon çalışırken bu durum kullanıcı arayüzünde açıkça gösterilmelidir.

Medya akışı güvenliğiyle ilgili kapsamlı bir açıklama bu makalenin kapsamında değildir. Daha fazla bilgi için IETF tarafından önerilen Önerilen WebRTC Güvenlik Mimarisi'ne bakın.

Sonuç

WebRTC'nin API'leri ve standartları, içerik oluşturma ve iletişim için telefon, oyun, video prodüksiyonu, müzik yapma ve haber toplama gibi araçları herkese eşit şekilde dağıtabilir ve merkezi olmayan hale getirebilir.

Teknoloji bundan daha kesintisiz değildir.

Blog yazarı Phil Edholm'un ifade ettiği gibi, "Potansiyel olarak WebRTC ve HTML5, gerçek zamanlı iletişim için orijinal tarayıcının bilgi sağladığı dönüşümü sağlayabilir."

Geliştirici araçları

Daha fazla bilgi

Standartlar ve protokoller

WebRTC destek özeti

MediaStream ve getUserMedia API'leri

  • Chrome masaüstü 18.0.1008 ve sonraki sürümler; Android için Chrome 29 ve sonraki sürümler
  • Opera 18 ve sonraki sürümleri; Android 20 ve sonraki sürümler için Opera
  • Opera 12, Opera Mobile 12 (Presto motoruna dayalı)
  • Firefox 17 ve sonraki sürümler
  • Microsoft Edge 16 ve sonraki sürümler
  • iOS'te Safari 11.2 ve sonraki sürümler, MacOS'te ise 11.1 ve sonraki sürümler
  • Android'de UC 11.8 ve sonraki sürümler
  • Samsung Internet 4 ve daha yenisi

RTCPeerConnection API'sı

  • Chrome masaüstü 20 ve sonraki sürümleri; Android için Chrome 29 ve sonraki sürümleri (işaretsiz)
  • Opera 18 ve sonraki sürümleri (varsayılan olarak açıktır); Android 20 ve sonraki sürümleri için Opera (varsayılan olarak açıktır)
  • Firefox 22 ve üzeri (varsayılan olarak açıktır)
  • Microsoft Edge 16 ve sonraki sürümler
  • iOS'te Safari 11.2 ve sonraki sürümler, MacOS'te ise 11.1 ve sonraki sürümler
  • Samsung Internet 4 ve daha yenisi

RTCDataChannel API'sı

  • Chrome 25'teki deneysel sürüm, ancak Chrome 26 ve sonraki sürümlerde daha kararlı (ve Firefox ile birlikte çalışabilirlik); Android 29 ve sonraki sürümler için Chrome
  • Opera 18 ve sonraki sürümleri; Android 20 ve sonraki sürümleri için Opera'nın kararlı sürümü (ve Firefox ile birlikte çalışabilirlik özelliği bulunur)
  • Firefox 22 ve üzeri (varsayılan olarak açıktır)

getUserMedia ve RTCPeerConnection gibi API'lere yönelik platformlar arası destek hakkında daha ayrıntılı bilgi için caniuse.com ve Chrome Platform Status sayfalarına göz atın.

RTCPeerConnection için yerel API'lere webrtc.org adresindeki belgeler bölümünden de ulaşabilirsiniz.