Apa yang lebih baik untuk digunakan ketika mengembangkan perangkat lunak - teknologi asli atau web? Holivar tentang hal ini tidak akan segera berakhir, tetapi beberapa orang akan berpendapat bahwa berguna untuk menduplikasi fungsi asli untuk digunakan di browser atau WebView. Dan jika dulu aplikasi untuk panggilan ada secara terpisah dari peramban, sekarang aplikasi itu mudah diterapkan di web. Pengembang Grigory Kuznetsov menjelaskan cara menggunakan teknologi WebRTC untuk koneksi P2P.
- Seperti yang Anda semua tahu, dalam beberapa tahun terakhir ada cukup banyak aplikasi berdasarkan pertukaran data langsung antara dua browser, yaitu, P2P. Ini semua adalah pengirim pesan instan, obrolan, dialer, konferensi video. Mungkin juga aplikasi yang melakukan semacam komputasi terdistribusi. Batas fantasi tidak terbatas dengan cara apa pun.
Bagaimana kita membuat teknologi seperti itu? Bayangkan kita ingin melakukan panggilan dari satu browser ke browser lainnya. Dan bayangkan langkah apa yang kita butuhkan untuk mencapai tujuan ini. Pertama-tama, tampaknya panggilan itu adalah gambar kita, suara kita, gambar, dan kita perlu mendapatkan akses ke perangkat media yang terhubung ke komputer: ke kamera dan ke mikrofon. Setelah Anda mendapatkan akses, Anda perlu dua browser Anda, dua klien, untuk saling menemukan. Penting untuk membantu mereka entah bagaimana terhubung, menjangkau, menyampaikan metainformation.
Ketika Anda mencapai, Anda harus mulai mentransfer data dalam mode P2P, yaitu untuk memastikan transmisi aliran media. Kami memiliki semua barang yang diperlukan, kami siap menerapkan sepeda baru kami yang keren. Tapi ini lelucon, kami adalah insinyur dan kami mengerti bahwa itu mahal, tidak bisa dibenarkan, dan berisiko. Karena itu, sebagai insinyur klasik, mari kita pikirkan solusi apa yang sudah ada.
Pertama-tama, teknologi lama Adobe Flash sekarat. Dia benar-benar sekarat, dan Adobe akan berhenti mendukungnya pada tahun 2020. Teknologi ini benar-benar akan memungkinkan Anda untuk mengakses perangkat media Anda, di dalamnya Anda dapat menerapkan semua mekanisme yang diperlukan untuk membantu browser terhubung, sehingga mereka mulai mengirimkan informasi P2P, tetapi Anda akan menemukan sepeda Anda lagi, karena tidak ada standar tunggal, satu pendekatan untuk menerapkan metode ini transfer data.
Anda dapat menulis plugin browser. Inilah cara Skype bekerja untuk peramban yang tidak mendukung teknologi yang lebih modern. Anda harus menerapkan sepeda Anda, karena tidak ada standar tunggal, dan itu juga buruk bagi pengguna, karena pengguna harus memasang semacam plug-in di browser-nya, melakukan tindakan tambahan. Pengguna tidak suka ini dan tidak ingin melakukannya.
Dan ada teknologi WebRTC - Google Hangouts, Facebook Messenger bekerja dengannya. Voximplant menggunakannya sehingga Anda dapat melakukan panggilan. Mari kita bahas lebih detail. Ini adalah teknologi berkembang baru, muncul pada 2011 dan terus berkembang. Apa yang dia izinkan untuk dilakukan? Dapatkan akses ke kamera dan mikrofon. Buat koneksi P2P antara dua komputer, dua browser. Secara alami, ini memungkinkan Anda untuk mentransfer aliran media secara langsung. Selain itu, ini memungkinkan Anda untuk mentransfer informasi, yaitu, tanggal biner, Anda juga dapat mengirimkan P2P, Anda dapat membuat sistem komputasi terdistribusi Anda sendiri.
Poin penting: WebRTC tidak menyediakan browser dengan cara untuk menemukan satu sama lain. Kita dapat menghasilkan semua meta-informasi yang diperlukan tentang orang yang kita cintai, tetapi bagaimana satu browser dapat mengetahui tentang yang lain? Bagaimana cara menghubungkannya? Pertimbangkan sebuah contoh.
Ada dua klien. Klien pertama ingin melakukan panggilan ke klien kedua. WebRTC memberi Anda semua informasi yang Anda butuhkan untuk mengidentifikasi diri Anda. Tetapi pertanyaannya tetap bagaimana menemukan browser lain, bagaimana mengirim informasi meta ini, bagaimana menginisialisasi panggilan. Ini diserahkan kepada pengembang, kita dapat menggunakan metode apa pun, mengambil meta-informasi ini, mencetaknya di selembar kertas, mengirimkannya melalui kurir, yang lain akan menggunakannya, dan semuanya akan berfungsi.
Dan kita dapat menemukan beberapa mekanisme pensinyalan. Dalam hal ini, ini adalah mekanisme pihak ketiga yang akan memungkinkan kami, jika kami tahu tentang pelanggan kami, untuk memastikan transfer di antara mereka dari beberapa informasi yang diperlukan untuk membuat koneksi.
Pertimbangkan contoh menggunakan server sinyal. Ada server sinyal yang menjaga koneksi konstan dengan klien kami, misalnya, melalui soket web atau menggunakan HTTP. Klien pertama menghasilkan meta-informasi, dan mengirimkannya ke server sinyal menggunakan soket web atau HTTP. Itu juga mengirimkan beberapa bagian dari informasi dengan siapa ia ingin terhubung, misalnya, nama panggilan atau beberapa informasi lain.
Server sinyal yang menggunakan pengidentifikasi ini menentukan klien mana yang perlu mengarahkan ulang informasi meta kami, dan meneruskannya. Klien kedua mengambilnya, menggunakannya, menginstalnya sendiri, membentuk respons, dan menggunakan mekanisme pensinyalan mengirimkannya ke server sinyal, yang kemudian meneruskannya ke klien pertama. Dengan demikian, kedua klien saat ini memiliki semua tanggal dan meta-informasi yang diperlukan untuk membangun koneksi P2P. Selesai
Mari kita lihat lebih dekat apa yang dipertukarkan oleh klien, mereka bertukar datagram SDP, Session Description Protocol.
Ini pada dasarnya adalah file teks yang berisi semua informasi yang diperlukan untuk membuat koneksi. Ada informasi tentang alamat IP, tentang port yang digunakan, tentang jenis informasi apa yang dikejar di antara klien, apa itu - audio, video, codec mana yang digunakan. Semua yang kita butuhkan ada di sana.
Perhatikan baris kedua. Ini menunjukkan alamat IP klien, 192.168.0.15. Jelas, ini adalah alamat IP komputer yang ada di beberapa jaringan lokal. Jika kami memiliki dua komputer, yang masing-masingnya ada di jaringan lokal, yang masing-masing mengetahui alamat IP-nya di dalam jaringan ini, mereka ingin menelepon. Apakah mereka dapat melakukan ini dengan datagram seperti itu? Jelas tidak, mereka tidak tahu alamat IP eksternal. Bagaimana menjadi
Mari kita minggir dan melihat cara kerja NAT. Di Internet, banyak komputer tersembunyi di belakang router. Ada jaringan lokal di mana komputer mengetahui alamat mereka, ada router yang memiliki alamat IP eksternal, dan semua komputer ini menonjol dengan alamat IP router ini. Ketika sebuah paket dari komputer di jaringan lokal pergi ke router, router melihat di mana ia harus diteruskan. Jika di jaringan lokal yang lain ini, maka ia hanya me-relay-nya, dan jika Anda perlu mengirimnya ke luar, ke Internet, tabel routing dikompilasi.
Kami mengisi alamat IP internal komputer yang ingin meneruskan paket, port-nya, mengatur alamat IP eksternal, alamat IP router, dan juga melakukan perubahan port. Untuk apa ini? Bayangkan dua komputer mengakses sumber daya yang sama, dan kita perlu merutekan paket respons dengan benar. Kami akan mengidentifikasi mereka dengan port, port akan unik untuk masing-masing komputer, sedangkan alamat IP eksternal akan cocok.
Bagaimana cara hidup jika ada NAT, jika komputer nongkrong di bawah alamat IP yang sama, tetapi di dalam mereka tahu tentang satu sama lain oleh yang lain?
Kerangka ICE untuk Pembentukan Konektivitas Internet datang untuk menyelamatkan. Ini menjelaskan cara-cara untuk memotong NAT, bagaimana membangun koneksi jika kita memiliki NAT.
Kerangka kerja ini menggunakan atribut server STUN.
Ini adalah server khusus, merujuk padanya, Anda dapat mengetahui alamat IP eksternal Anda. Jadi, dalam proses membangun koneksi P2P, setiap klien harus membuat permintaan ke server STUN ini untuk mengetahui alamat IP-nya, dan menghasilkan informasi tambahan, IceCandidate, dan bertukar IceCandidate dengan mekanisme pensinyalan. Kemudian klien akan saling mengenal dengan alamat IP yang benar, dan akan dapat membuat koneksi P2P.
Namun, ada kasus yang lebih rumit. Misalnya, ketika komputer tersembunyi di balik NAT ganda. Dalam hal ini, kerangka kerja ICE mengharuskan penggunaan server TURN.
Ini adalah server khusus yang mengubah koneksi klien-klien, P2P, menjadi koneksi klien-server-klien, yaitu bertindak sebagai relay. Kabar baiknya bagi para pengembang adalah terlepas dari mana dari tiga skenario koneksi yang dibuat, apakah kita berada di jaringan lokal, apakah kita perlu beralih ke server STUN atau TURN, teknologi API akan identik untuk kita. Kami hanya menunjukkan di awal konfigurasi server ICE dan MENGHIDUPKAN, menunjukkan cara mengaksesnya, dan setelah itu teknologi melakukan segalanya untuk kita di bawah tenda.
Ringkasan singkat. Untuk membuat koneksi, Anda perlu memilih dan menerapkan semacam mekanisme pensinyalan, perantara tertentu yang akan membantu kami mengirim meta-informasi. WebRTC akan memberi kita semua meta yang diperlukan untuk ini.
Kami harus bertarung dengan NAT, ini adalah musuh utama kami pada tahap ini. Tetapi untuk menyiasatinya, kami menggunakan server STUN untuk mengetahui alamat IP eksternal kami, dan kami menggunakan server TURN sebagai relay.
Apa sebenarnya yang kami transmisikan? Tentang aliran media.
Media stream adalah saluran yang berisi trek di dalam dirinya sendiri. Trek dalam aliran media disinkronkan. Audio dan video tidak akan menyimpang, mereka akan datang dengan waktu tunggal. Anda dapat membuat sejumlah trek di dalam aliran media, trek dapat dikontrol secara terpisah, misalnya, Anda dapat membisukan audio, hanya menyisakan gambar. Anda juga dapat mentransfer sejumlah aliran media, yang memungkinkan Anda, misalnya, untuk mengimplementasikan konferensi.
Bagaimana cara mengakses media dari browser? Mari kita bicara tentang API.
Ada metode getUserMedia yang menerima satu set konstanta sebagai input. Ini adalah objek khusus tempat Anda menunjukkan perangkat mana yang ingin Anda akses, kamera mana, mikrofon mana. Anda menentukan karakteristik yang ingin Anda miliki, resolusi mana, dan ada juga dua argumen - successCallback dan errorCallback, yang disebut jika berhasil atau gagal. Lebih banyak implementasi teknologi modern menggunakan janji.
Ada juga metode enumerateDevices yang nyaman yang mengembalikan daftar semua perangkat media yang terhubung ke komputer Anda, yang memberi Anda kesempatan untuk menunjukkannya kepada pengguna, menggambar semacam pemilih sehingga pengguna memilih kamera tertentu yang ingin ia gunakan.
Objek utama dalam API adalah RTCPeerConnection. Ketika kita membuat koneksi, kita mengambil kelas RTCPeerConnection, yang mengembalikan objek peerConnection. Sebagai konfigurasi, kami menetapkan satu set server ICE, yaitu server STUN dan TURN, yang akan kami akses selama proses instalasi. Dan ada peristiwa onicecandidate penting yang memicu setiap kali kita membutuhkan bantuan dari mekanisme pensinyalan kita. Yaitu, teknologi WebRTC membuat permintaan, misalnya, ke server STUN, kami mengenali alamat IP eksternal kami, muncul ICECandidate baru, dan kami perlu meneruskannya menggunakan mekanisme pihak ketiga, acara ini menjadi strigger.
Ketika kami membuat koneksi dan ingin menginisialisasi panggilan, kami menggunakan metode createOffer () untuk membentuk SDP awal, menawarkan SDP, informasi meta yang sama yang perlu dikirim ke mitra.
Untuk mengaturnya ke PeerConnection, kami menggunakan metode setLocalDescription (). Interlocutor menerima informasi ini dengan mekanisme pensinyalan, menyetelnya sendiri menggunakan metode setRemoteDescription (), dan menghasilkan respons menggunakan metode createAnswer (), yang juga dikirim ke klien pertama menggunakan mekanisme pensinyalan.
Ketika kami mendapatkan akses ke media, mendapatkan aliran media, kami mentransfernya ke koneksi P2P kami menggunakan metode addStream, dan teman bicara kami mengetahuinya, ia memiliki acara onaddstream yang dipangkas. Dia akan menerima aliran kami dan akan dapat menampilkannya.
Anda juga dapat bekerja dengan aliran data. Ini sangat mirip dengan membentuk peerConnection biasa, cukup tentukan RtpDataChannels: true dan panggil metode createDataChannel (). Saya tidak akan membahas hal ini secara rinci, karena pekerjaan seperti itu sangat mirip dengan bekerja dengan soket web.
Beberapa kata tentang keamanan. WebRTC hanya berfungsi di HTTPS, situs Anda harus ditandatangani dengan sertifikat. Media stream juga dienkripsi, menggunakan DTLS. Teknologi ini tidak memerlukan pemasangan apa pun ekstra, tidak ada plug-in, dan itu bagus. Dan itu tidak akan berfungsi untuk membuat aplikasi spyware, situs tidak akan menguping atau memata-matai pengguna, ia akan menunjukkan kepada pengguna permintaan khusus, meminta akses darinya dan menerimanya hanya jika pengguna mengizinkan akses ke perangkat audio dan media.
Adapun dukungan browser - IE tetap dan tetap merah. Pada akhir tahun lalu, dukungan Safari telah ditambahkan, yaitu, semua browser modern sudah dapat bekerja dengan teknologi ini dan kami dapat menggunakannya dengan aman.
Saya ingin berbagi satu set semua jenis utilitas yang akan membantu Anda jika Anda ingin bekerja dengan WebRTC. Ini terutama merupakan
adaptor . Teknologi terus berkembang, dan ada perbedaan dalam API browser. Pustaka adaptor menghilangkan perbedaan ini dan membuat pekerjaan lebih mudah. Pustaka yang nyaman untuk bekerja dengan aliran data adalah
Peerjs . Anda juga dapat melihat implementasi open source dari
server STUN dan
TURN . Serangkaian besar tutorial, contoh, artikel ada di
halaman webrtc yang mengagumkan , saya sangat merekomendasikannya.
Alat terakhir yang bermanfaat untuk debugging adalah webrtc-internal. Selama pengembangan, Anda dapat mengetik perintah khusus di bilah alamat - misalnya, di browser Chrome, ini adalah Chrome: // webrtc-internal. Anda akan melihat halaman dengan semua informasi tentang koneksi WebRTC Anda saat ini. Akan ada urutan panggilan dalam metode, dan semua datagram dipertukarkan antara browser, dan grafik yang entah bagaimana mencirikan koneksi Anda. Secara umum, akan ada semua informasi yang akan dibutuhkan selama proses debug dan pengembangan. Terima kasih atas perhatian anda